[openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method

[Jouni Malinen]

I reported the same issue on openssl-user last year without getting
any response and based on the response I just got when trying to send
this from gmail, I guess the reason was in the message getting rejected
for some reason.. Lovely, I guess I need to go through all my past
messages to see if some other questions were dropped as well.. Here's a
copy of that message for reference, should there be any additional
details. I would also be quite interested in getting this resolved. For
now, I have had to add a workaround where TLS v1.0 is forced for
EAP-FAST while other TLS-based EAP methods can negotiate TLS v1.1 or
v1.2..


That email from December:

TLS v1.x negotiation when using SSL_set_session_ticket_ext()

I used to use SSL_CTX_new(TLSv1_method()) to initialize SSL_CTX for
various TLS-based EAP methods. This worked fine with EAP-TLS,
EAP-PEAP, EAP-TTLS, and EAP-FAST. However, it did not allow OpenSSL to
negotiate TLS v1.1 or v1.2 to be used. Consequently, there seemed to
be need to change from TLSv1_method() to SSLv23_method() with
SSL_OP_NO_SSLv2 and SSL_OP_NO_v3. Initially, this seemed to work fine,
but I found an issue with EAP-FAST peer (i.e., TLS client).

It looks like there is a difference in what can be included in
ClientHello message between TLSv1_method() and SSLv23_method() even if
TLS v1.0 ends up getting used in both cases. With TLSv1_method(), the
TLS session ticket extension set by SSL_set_session_ticket_ext() gets
used while with SSLv23_method() that does not happen and this is the
part that breaks EAP-FAST.

Looking at the differences between ssl3_connect() and ssl23_connect(),
it seems clear that the issue is caused by different handling of
s->session. In case of ssl3_connect() (which is used by
TLSv1_method()), s->session gets initialized before a call to
ssl_add_clienthello_tlsext() while this does not happen with
ssl23_connect(); quite the opposite, s->session is even verified to be
NULL and a place to call ssl_get_new_session() is #if 0'ed out.

Is there a way to use SSLv23_method() or some other means to configure
OpenSSL as the TLS clients to allow TLS v1.0, v1.1, v1.2 to be
negotiated while still allowing SSL_set_session_ticket_ext() to be
used? If not, can such mechanism be added?

So far, the only option of how to potentially handle this is by
creating two SSL_CTX instances. One with SSLv23_method() for EAP-TLS,
EAP-PEAP, and EAP-TTLS (which do not use SSL_set_session_ticket_ext())
and another one for EAP-FAST with TLSv1_method() to allow
SSL_set_session_ticket_ext() to be used. The drawback here is that
this is more complex and in addition, would continue to force TLS v1.0
to be used with EAP-FAST. TLSv1_1_method() or TLSv1_2_method() would
not be much help either since those would seem to require known
beforehand what the server supports. (Or well, with even more
complexity, I guess those could be probed for and the results cached
for future uses, but I don't think I really want to go that far in
extra complexity.)

-- 
Jouni Malinen                                            PGP id EFC895FA