[openssl-dev] OpenSSL version 1.1.0 pre release 2 published

[Jouni Malinen]

On Thu, Jan 14, 2016 at 03:44:18PM +0100, Richard Levitte wrote:
>    OpenSSL version 1.1.0 pre release 2 (alpha)

>    OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now
>    been made available. For details of changes and known issues see the
>    release notes at:
> 
>         http://www.openssl.org/news/openssl-1.1.0-notes.html

I needed to do following updates to hostapd/wpa_supplicant to build
against this (to a snapshot that worked with 1.1.0 pre release 1):
- use EVP_CIPHER_CTX_new() and dynamic allocation instead of having
  EVP_CIPHER_CTX ctx on stack and using EVP_CIPHER_CTX_init(&ctx)
  (I guess this was an expected change, but for some reason, pre release
   1 did not force this)
- replace "SSL_CIPHER **cipher" with "const SSL_CIPHER **cipher" in the
  SSL_set_session_secret_cb() callback function
  (I did not notice any comment about this in the changelog; was there
   supposed to be something? This broke API compatibility.. The change
   itself is fine and I already had to do some with BoringSSL, but it
   would be nice to get this type of incompatible API changes noted
   clearly)

As far as functionality is concerned, I did see number of new issues
when running through my automated test setup and especially the EAP test
cases. I haven't yet looked at what exactly caused these, but these did
not look exactly good, so that's why a quick note here first to see if
anything sounds familiar and someone would already know why the behavior
changed between pre release 1 and 2.

Many of the negative test cases that verify that server certificate
chain validation works by using mismatching trust roots (i.e., server
certificate is not issued by any of the trusted CA certificates) are
failing. OpenSSL allows the TLS handshake to be completed with the
verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func))
reports preverify_ok=1 and err=0 for the root CA and the server
certificate even though the client side has not configured that root CA
as trusted. This worked fine with pre release 1, so I'm quite concerned
about the change in behavior when nothing in the application side
changed and an untrusted server certificate suddenly became trusted by
OpenSSL update.. Is there really an intentional change in OpenSSL
requiring something additional to be done to configure peer certificate
validation to result in failure with the latest pre release?

EAP server side is crashing (segmentation fault) in a pretty strange way
when using CRL validation as part of the TLS handshake. This is my test
case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the
hostapd process that went through the TLS server side exchange. It looks
like a crash in OpenSSL check_revocation(), but I guess I'll need to
enable more debug symbols somewhere to get bit more helpful output. This
same test case worked fine with pre release 1. The test case ends up
using a code path that executes cs = SSL_CTX_get_cert_store() and
X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK).

==627== Conditional jump or move depends on uninitialised value(s)
==627==    at 0x6174D5: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x55782F: ssl_add_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x575157: ssl3_output_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x569D3C: ossl_statem_server_construct_message (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x50AF9C: openssl_handshake (tls_openssl.c:3180)
==627==    by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273)
==627==    by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316)
==627==    by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247)
==627==    by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468)
==627==    by 0x4C40C3: eap_tls_process (eap_server_tls.c:259)
==627== 
==627== Use of uninitialised value of size 8
==627==    at 0x61742D: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0x662C55F: ???
==627==    by 0xEFFFFFFFF: ???
==627==    by 0x654653F: ???
==627== 
vex amd64->IR: unhandled instruction bytes: 0x6E 0x6F 0x6E 0x65 0x0 0x52 0x53 0x41
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==627== Invalid read of size 4
==627==    at 0x75FFEA: ??? (in /home/jm/Git/hostap/hostapd/hostapd)
==627==    by 0xFFF00038F: ???
==627==    by 0x20441A6D1E48C1FF: ???
==627==    by 0xFFF00038F: ???
==627==    by 0xFFF00038F: ???
==627==    by 0x1: ???
==627==    by 0x654653F: ???
==627==  Address 0x1003029407 is not stack'd, malloc'd or (recently) free'd

-- 
Jouni Malinen                                            PGP id EFC895FA