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.
Recognize the PEM header "BEGIN PRIVATE KEY" as base64-decode the data
to be able to use PEM encoded, unencrypted PKCS#8 private keys with the
internal TLS implementation. Previously, only DER encoding of the
PKCS#8 private key was supported.
These could, at least in theory, be used to generate unexpected common
name or subject alternative name matches should a CA sign strings with
NUL (C string termination) in them. For now, just reject the certificate
if an embedded NUL is detected. In theory, all the comparison routines
could be made to compare these strings as binary blobs (with additional
X.509 rules to handle some exceptions) and display NUL characters
somehow. Anyway, just rejecting the certificate will get rid of
potential problems with the C string getting terminated and it should
not really be used in certificates, so this should not break valid use
cases.
