This allows the internal TLS client implementation to accept
CertificateStatus message from the server when trying to use OCSP
stapling. The actual OCSPResponse is not yet processed in this commit,
but the CertificateStatus message is accepted to allow the TLS handshake
to continue.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows the internal TLS implementation to request server
certificate status using OCSP stapling. This commit is only adding code
to add the request. The response is not yet used.
Signed-off-by: Jouni Malinen <j@w1.fi>
This prints the received ServerHello extensions into the debug log and
allows handshake to continue even if such extensions are included.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows the internal TLS implementation to parse a private key and a
certificate from a PKCS #12 file protected with
pbeWithSHAAnd3-KeyTripleDES-CBC.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds support for decrypting private keys protected with the old
PKCS #12 mechanism using OID pbeWithSHAAnd3-KeyTripleDES-CBC.
Signed-off-by: Jouni Malinen <j@w1.fi>
This extends the internal TLS support for PKCS #5 v2.0 PBES2 private key
format with des-ede3-cbc encryption and PBKDF2 SHA-1.
Signed-off-by: Jouni Malinen <j@w1.fi>
conn->session_resumed was not set to 1 after successful use of a TLS
session ticket with EAP-FAST. This resulted in the wpa_supplicant STATUS
tls_session_reused showing incorrect value (0 instead of 1) when
EAP-FAST PAC was used. Fix this by setting conn->session_resumed = 1
when TLS handshake using the session ticket succeeds.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the server/client certificate includes the extKeyUsage extension,
verify that the listed key purposes include either the
anyExtendedKeyUsage wildcard or id-kp-serverAuth/id-kp-clientAuth,
respectively.
Signed-off-by: Jouni Malinen <j@w1.fi>
The internal TLS client implementation in wpa_supplicant can now be used
with the phase2 parameters tls_disable_tlsv1_0=1, tls_disable_tlsv1_1=1,
and tls_disable_tlsv1_2=1 to disable the specified TLS version(s).
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes it simpler to add support for new TLS_CONN_* flags without
having to add a new configuration function for each flag.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows wpa_supplicant to return eap_tls_version STATUS information
when using the internal TLS client implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
The internal TLS client implementation can now be used with
ca_cert="probe://" to probe the server certificate chain. This is also
adding the related CTRL-EVENT-EAP-TLS-CERT-ERROR and
CTRL-EVENT-EAP-PEER-CERT events.
Signed-off-by: Jouni Malinen <j@w1.fi>
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>
Since we support only SHA256 (and not the default SHA1) with TLS v1.2,
the signature_algorithms extensions needs to be added into ClientHello.
This fixes interop issues with the current version of OpenSSL that uses
the default SHA1 hash if ClientHello does not specify allowed signature
algorithms.
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit adds support for validating certificates with SHA384 and
SHA512 hashes. Those certificates are now very common so wpa_supplicant
needs support for them.
SHA384 and SHA512 hash functions are included in the previous commit.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
This commit adds support for "hash://server/sha256/cert_hash_in_hex"
scheme in ca_cert property for the internal TLS implementation.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
In documentation is written: "If ca_cert and ca_path are not included,
server certificate will not be verified". This is the case when
wpa_supplicant is compiled with OpenSSL library, but when using the
internal TLS implementation and some certificates in CA chain are in
unsupported format (e.g., use SHA384 or SHA512 hash functions) then
verification fails even if ca_cert property is not specified.
This commit changes behavior so that certificate verification in
internal TLS implementation is really skipped when ca_cert is not
specified.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
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>
Commit 94f1fe6f63 ('Remove master key
extraction from tls_connection_get_keys()') left only fetching of
server/client random, but did not rename the function and structure to
minimize code changes. The only name is quite confusing, so rename this
through the repository to match the new purpose.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, it would have been possible for va_end(args) to be called
twice in case mp_init() fails. While that may not cause issues on number
of platforms, that is not how va_start()/va_end() are supposed to be
used. Fix this by returning from the function without using va_end()
twice on the same va_list args.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the mp_init_multi() call had failed due to memory allocation failure,
mp_div() would have returned 1 instead of MP_MEM (-2). It looks like all
callers are checking the return value against MP_OKAY instead of <1
(etc.), so this does not seem to result in difference in behavior.
Anyway, it's best to fix the mp_div() return value for the MP_MEM error
case to avoid unexpected behavior.
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
This is not needed anymore with the tls_connection_prf() being used to
handle all key derivation needs. tls_connection_get_keys() is a bit
misnamed for now, but it is only used to fetch the client and server
random for Session-Id derivation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It does not look likely that the old DSA design would be added into the
internal TLS implement, so remove this otherwise dead code.
Signed-off-by: Jouni Malinen <j@w1.fi>
For some reason, "pos + len > end" is not clear enough, but "len > end -
pos" is recognized. Use that to get rid of a false positive from a
static analyzer (CID 72697).
Signed-off-by: Jouni Malinen <j@w1.fi>
Use a temporary, local variable to check the DH parameters received from
the server before assigning the length to the struct tlsv1_client
variables. This will hopefully make it easier for static analyzers to
figure out that there is bounds checking for the value. (CID 72699)
Signed-off-by: Jouni Malinen <j@w1.fi>
The dh_p_len, dh_g_len, and dh_ys_len parameters were validated against
the received message structure, but that did not seem to be done in a
way that some static analyzers would understand this (CID 72699).
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes the implementation less likely to provide useful timing
information to potential attackers from comparisons of information
received from a remote device and private material known only by the
authorized devices.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is similar to the existing functionality that parsed ASN.1-encoded
RSA public key by generating a similar public key instance from already
parsed n and e parameters.
Signed-off-by: Jouni Malinen <j@w1.fi>
Follow the PKCS #1 v1.5, 8.1 constraint of at least eight octets long PS
for the case where the internal TLS implementation decrypts PKCS #1
formatted data. Similar limit was already in place for signature
validation, but not for this decryption routine.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Based on PKCS #1, v1.5, 10.1.3, the block type shall be 01 for a
signature. This avoids a potential attack vector for internal TLS/X.509
implementation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Verify that there is no extra data after the hash field. This is needed
to avoid potential attacks using additional data to construct a value
that passes the RSA operation and allows the hash value to be forged.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The current position pointer was not updated when issuerUniqueID or
subjectUniqueID were present. This could result in extensions being
ignored.
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>
Previously, this was silently dropped which left the connection waiting
for timeout. decrypt_error alert can be used here to avoid that.
Signed-off-by: Jouni Malinen <j@w1.fi>
This same design is used in both the server and the client roles in the
internal TLS implementation. Instead of duplicated implementation, use a
helper function.
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>
The SHA256-based RSA-AES-128/256 cipher suites were already implemented
and enabled for the internal TLS client, but they had not been enabled
for the server.
Signed-off-by: Jouni Malinen <j@w1.fi>
There are quite a few places in the current implementation where a nul
terminated string is generated from binary data. Add a helper function
to simplify the code a bit.
Signed-hostap: Jouni Malinen <j@w1.fi>
Now that the internal AES implementation supports 256-bit keys, enable
use of the TLS cipher suites that use AES-256 regardless of which crypto
implementation is used.
Signed-hostap: Jouni Malinen <j@w1.fi>
Add support for generating and verifying RFC 3447 RSASSA-PKCS1-v1_5
style DigestInfo for TLS v1.2 CertificateVerify. For now, this is
hardcoded to only support SHA256-based digest.
Signed-hostap: Jouni Malinen <j@w1.fi>
This allows the internal TLS implementation to be built for TLS v1.2
support. In addition to the build option, this changes the TLS PRF
based on the negotiated version number. Though, this commit does not
yet complete support for TLS v1.2.
Signed-hostap: Jouni Malinen <j@w1.fi>
Prepare for multiple TLS PRF functions by renaming the SHA1+MD5 based
TLS PRF function to more specific name and add tls_prf() within the
internal TLS implementation as a wrapper for this for now.
Signed-hostap: Jouni Malinen <j@w1.fi>
Reassemble partial TLS records to make the internal TLS client
implementation more convenient for stream sockets.
Signed-hostap: Jouni Malinen <j@w1.fi>
The padding validation was done on the last padding-length octets in the
buffer which misses the first padding octet (the last octet is the
padding length). Fix the starting offset for the comparison loop to get
the first octet verified. [Bug 420]
Signed-hostap: Jouni Malinen <j@w1.fi>
Return number of user input bytes from tlsv1_record_receive() to
move this detail into the proper record layer processing. In addition,
ignore unknown content types at record layer and allow processing to
continue after warning level TLS alerts to provide minimal workaround
for closure alerts.
Signed-hostap: Jouni Malinen <j@w1.fi>
Instead of using separate bad_record_mac and decryption_failed alerts,
use only bad_record_mac alert regardless of how the CBC decryption
failed. This provides less information to attackers that could modify
packets. In addition, instead of returning immediately on error, run
through the MAC check to make timing attacks more difficult.
When the received data will be decrypted, there is no need to first
copy it and then handle decryption in-place when decryption step can
take care of both operations.
TLS v1.0 and v1.1 RFCs were not exactly clear on the use of the
protocol version in record later. As such, accept any {03,xx} value
to remain compatible with existing implementations and new protocol
versions.
The internal TLS implementation assumes that the certificate chain
is ordered by issuer certificate following the certificate that it
signed. Add the certificates to the chain in suitable order when
loading multiple certificates.
This phase1 parameter for TLS-based EAP methods was already supported
with GnuTLS and this commit extends that support for OpenSSL and the
internal TLS implementation.
This patch fixes a problem I had when I tried to connect
an embedded system [wpa_supplicant, CONFIG_TLS=internal]
to my TLS secured network.
TLSv1: Send CertificateVerify
TLSv1: CertificateVerify hash - hexdump(len=36): ha .. ha
PKCS #1: pkcs1_generate_encryption_block - Invalid buffer lengths \
(modlen=512 outlen=454 inlen=36)
It turned out that a fixed 1000 byte message buffer was just
a little bit too small for the 4096 bit RSA certificates
I'm using.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
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.
There may be more than one attribute of same type (e.g., multiple DC
attributes), so the code needs to be able to handle that. Replace the
fixed structure with an array of attributes.
There are no subdirectories in any of these directories or plans
for adding ones. As such, there is no point in running the loop
that does not do anything and can cause problems with some shells.
The new test-asn1 and test-x509 tools are built using libraries
from src/{utils,crypto,tls}. Currently, cross dependencies between
crypto and tls are still preventing the test-x509 from being linked
properly.
eap_example is now using src/crypto/libcrypto.a and src/tls/libtls.a
instead of providing own rules for building the files for these
components. TLS library selection is temporarily disabled for
eap_example (it will be built using internal crypto/TLS), but the
configuration option for this will eventually be restored with a new
libcrypto.a configuration option.
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.).
The following defines are not really needed in most places, so
remove them to clean up source code and build scripts:
EAP_TLS_FUNCS
EAP_TLS_OPENSSL
EAP_TLS_GNUTLS
CONFIG_TLS_INTERNAL
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.
This functionality fits better with src/tls (i.e., internal TLS
implementation), so move it there to make crypto_internal.c more
of a wrapper like other crypto_*.c files.
Private keys can now be used in either unencrypted or encrypted
PKCS #8 encoding. Only the pbeWithMD5AndDES-CBC algorithm (PKCS #5)
is currently supported.
