This allows external programs (e.g., UI) to get more information
about server certificate chain used during TLS handshake. This can
be used both to automatically probe the authentication server to
figure out most likely network configuration and to get information
about reasons for failed authentications.
The follow new control interface events are used for this:
CTRL-EVENT-EAP-PEER-CERT
CTRL-EVENT-EAP-TLS-CERT-ERROR
In addition, there is now an option for matching the server certificate
instead of the full certificate chain for cases where a trusted CA is
not configured or even known. This can be used, e.g., by first probing
the network and learning the server certificate hash based on the new
events and then adding a network configuration with the server
certificate hash after user have accepted it. Future connections will
then be allowed as long as the same server certificate is used.
Authentication server probing can be done, e.g., with following
configuration options:
eap=TTLS PEAP TLS
identity=""
ca_cert="probe://"
Example set of control events for this:
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=US/ST=California/L=San Francisco/CN=Server/emailAddress=server@kir.nu' hash=5a1bc1296205e6fdbe3979728efe3920798885c1c4590b5f90f43222d239ca6a
CTRL-EVENT-EAP-TLS-CERT-ERROR reason=8 depth=0 subject='/C=US/ST=California/L=San Francisco/CN=Server/emailAddress=server@kir.nu' err='Server certificate chain probe'
CTRL-EVENT-EAP-FAILURE EAP authentication failed
Server certificate matching is configured with ca_cert, e.g.:
ca_cert="hash://server/sha256/5a1bc1296205e6fdbe3979728efe3920798885c1c4590b5f90f43222d239ca6a"
This functionality is currently available only with OpenSSL. Other
TLS libraries (including internal implementation) may be added in
the future.
Undocumented (at least for the time being) TLS parameters can now
be provided in wpa_supplicant configuration to enable some workarounds
for being able to connect insecurely to some networks. phase1 and
phase2 network parameters can use following options:
tls_allow_md5=1
- allow MD5 signature to be used (disabled by default with GnuTLS)
tls_disable_time_checks=1
- ignore certificate expiration time
For now, only the GnuTLS TLS wrapper implements support for these.
This converts tls_connection_handshake(),
tls_connection_server_handshake(), tls_connection_encrypt(), and
tls_connection_decrypt() to use struct wpa_buf to allow higher layer
code to be cleaned up with consistent struct wpabuf use.
This message from tls_connection_handshake() is not really an error in
most cases, so do not show it if there was indeed no Application Data
available (which is a normal scenario and not an indication of any
error).
This allows libeap.a and libeap.so to be built by merging in multiple
libraries from src subdirectories. In addition, this avoids wasting
extra space and time for local builds.
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
Mainly, this is including header files to get definitions for functions
which is good to verify that the parameters match. None of these are
issues that would have shown as incorrect behavior of the program.
The current MinGW/w32api versions seem to provide all the needed CryptoAPI
functions, so the code for loading these dynamically from the DLL can be
removed.
Need to define the workspace buffer properly to allow compiler to handle
strict aliasing between the incoming unsigned char[64] buffer as an u32
array. The previous version built with strict aliasing enabled can
result in SHA-1 producing incorrect results and consequently, with
4-way handshake failing.
This is based on a report and patch from Dan Williams <dcbw@redhat.com>
but with a different type (the union) used as a fix to avoid needing
extra type casting.
Discovered as part of the investigation of:
https://bugzilla.redhat.com/show_bug.cgi?id=494262#c32
if sha1 is built with gcc without turning off strict aliasing, it will
fail to correctly generate the hashes and will fail its own testcases as
well.
Signed-off-by: Dan Williams <dcbw@redhat.com>
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.
OpenSSL 0.9.7 does not include get_rfc3526_prime_1536() function, so
provide that functionality internally if needed. In addition, make
sha256_vector() building depend on whether SHA256 support is included
in the OpenSSL library. This with CONFIG_INTERNAL_SHA256=y in .config
allows OpenSSL without SHA256 support to be used.
Reorganize the TLS/crypto library segments into a single set of blocks
for each library instead of multiple locations handling library-specific
operations. Group crypto functionality together and get wpa_supplicant
and hostapd Makefile closer to eachother in order to make it easier to
eventually move this into a shared makefile.
Crypto library wrappers can now override the internal DH (group 5)
implementation. As a starting point, this is done with OpenSSL. The
new mechanism is currently available only for WPS (i.e., IKEv2 still
depends on the internal DH implementation).
This allows NSS to be used to derive EAP-TLS/PEAP/TTLS keying material.
NSS requires a patch from
https://bugzilla.mozilla.org/show_bug.cgi?id=507359
to provide the new API. In addition, that patch needs to be modified to
add the 16-bit context length value in SSL_ExportKeyingMaterial() only if
contextlen != 0 in order to match with the EAP-TLS/PEAP/TTLS use cases.
This issue seems to be coming from the unfortunate incompatibility in
draft-ietf-tls-extractor-07.txt (draft-ietf-tls-extractor-00.txt would
have used compatible PRF construction).
At this point, it is unclear how this will be resolved eventually, but
anyway, this shows a mechanism that can be used to implement EAP key
derivation with NSS with a small patch to NSS.
This brings in the first step in adding support for using NSS
(Mozilla Network Security Services) as the crypto and TLS library
with wpa_supplicant. This version is able to run through EAP-PEAP
and EAP-TTLS authentication, but does not yet implement any
certificate/private key configuration. In addition, this does not
implement proper key fetching functions either, so the end result
is not really of much use in real world yet.
The BLOCK_SIZE define can be made more specific by using AES_ prefix and
by moving it to aes.h. After this, most aes-*.c do not really need to
include anything from the internal aes_i.h header file. In other words,
aes_i.h can now be used only for the code that uses the internal AES
block operation implementation and none of the code that can use AES
implementation from an external library do not need to include this
header file.
Better not specify EVP_CIPHER again for the second init call since that
will override key length with the default value. The previous version
was likely to work since most use cases would be likely to use the
default key length. Anyway, better make this handle variable length
ciphers (mainly, RC4), too, just in case it is needed in the future.
This is not really of that much use since rc4_skip() can be used as
easily. In addition, rc4 has caused some symbol conflicts in the past,
so it is easier to live without that as an exported symbol.
wpa_supplicant can now be built with FIPS capable OpenSSL for FIPS mode
operation. Currently, this is only enabling the FIPS mode in OpenSSL
without providing any higher level enforcement in wpa_supplicant.
Consequently, invalid configuration will fail during the authentication
run. Proper configuration (e.g., WPA2-Enterprise with EAP-TLS) allows
the connection to be completed.
