Add test-tls program that can be used for fuzzing the internal TLS
client and server implementations. This tool can write client or server
messages into a file as an initialization step and for the fuzzing step,
that file (with potential modifications) can be used to replace the
internally generated message contents.
The TEST_FUZZ=y build parameter is used to make a special build where a
hardcoded random number generator and hardcoded timestamp are used to
force deterministic behavior for the TLS operations.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows hostapd with the internal TLS server implementation to
support the extended OCSP stapling mechanism with multiple responses
(ocsp_stapling_response_multi).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds support for hostapd-as-authentication-server to be build with
the internal TLS implementation and OCSP stapling server side support.
This is more or less identical to the design used with OpenSSL, i.e.,
the cached response is read from the ocsp_stapling_response=<file> and
sent as a response if the client requests it during the TLS handshake.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This extends the internal TLS client implementation to support signature
algorithms SHA384 and SHA512 in addition to the previously supported
SHA256.
Signed-off-by: Jouni Malinen <j@w1.fi>
Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
test-tls-4: Short 511-bit RSA-DHE prime
test-tls-5: Short 767-bit RSA-DHE prime
test-tls-6: Bogus RSA-DHE "prime" 15
test-tls-7: Very short 58-bit RSA-DHE prime in a long container
test-tls-8: Non-prime as RSA-DHE prime
Signed-off-by: Jouni Malinen <j@w1.fi>
The internal TLS server implementation and RADIUS server implementation
in hostapd can be configured to allow EAP clients to be tested to
perform TLS validation steps correctly. This functionality is not
included in the default build; CONFIG_TESTING_OPTIONS=y in
hostapd/.config can be used to enable this.
When enabled, the RADIUS server will configure special TLS test modes
based on the received User-Name attribute value in this format:
<user>@test-tls-<id>.<rest-of-realm>. For example,
anonymous@test-tls-1.example.com. When this special format is used, TLS
test modes are enabled. For other cases, the RADIUS server works
normally.
The following TLS test cases are enabled in this commit:
1 - break verify_data in the server Finished message
2 - break signed_params hash in ServerKeyExchange
3 - break Signature in ServerKeyExchange
Correctly behaving TLS client must abort connection if any of these
failures is detected and as such, shall not transmit continue the
session.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows the internal TLS implementation to write log entries to the
same authlog with rest of the RADIUS server and EAP server
functionality.
Signed-off-by: Jouni Malinen <j@w1.fi>
Instead of separate server and client side implementations, use a common
set of helper functions for calculating the ServerParams hash for
ServerKeyExchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
Clean up the internal TLS implementation by removing conditional
build blocks for (mostly) EAP-FAST specific functionality. This
will increase the size a big for non-EAP-FAST builds, but is quite
helpful in making src/tls/libtls.a with single build options. If
the potential size reduction is considered significant in the future,
this can be reconsider with a more library compatible way (e.g.,
external file with registration function, etc.).
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
