This is a discussion on Session ticket and Session ID validation change in 0.9.8h - Openssl ; Session ID validation for the case where a session ticket is used was changed in 0.9.8h. To be more exact, ssl3_check_finished() function in ssl/s3_clnt.c was modified (CVS rev 126.96.36.199) to return 1 if session ID has non-zero length. It looks ...
Session ID validation for the case where a session ticket is used was
changed in 0.9.8h. To be more exact, ssl3_check_finished() function in
ssl/s3_clnt.c was modified (CVS rev 188.8.131.52) to return 1 if session ID
has non-zero length. It looks like this change broke the EAP-FAST
functionality for client side (using an external patch I maintain for
allowing EAP-FAST to be used with OpenSSL).
I'm trying to understand the reason for this change, but cannot fully
see why it would be needed. RFC 5077 chapter 3.4 allows the server to
reply with a non-empty Session ID even when session ticket is used. Why
would the client reject this case of session ticket use based on just
the ServerHello? The last couple of sentences in RFC 5077, 3.4 describe
this with: "Alternatively, the client MAY include an empty Session ID in
the ClientHello. In this case, the client ignores the Session ID sent
in the ServerHello and determines if the server is resuming a session by
the subsequent handshake messages." and this is the part that I think
the CVS rev 184.108.40.206 change prevents from happening properly.
If the client uses a zero-length session ID in ClientHello and server
replies with non-empty Session ID in ServerHello (which is what seems to
happen here when using OpenSSL for EAP-FAST), ssl3_check_finished() in
0.9.8h returns 1 whereas 0.9.8g returns 2. As the end result, 0.9.8h
expects Certificate to follow ServerHello, but it does not in this case
since session ticket is used and abbreviated handshake continues with
ChangeCipherSpec. 0.9.8g allows this case to be handled since
ssl3_connect() has special processing for the case where
ssl3_check_finished() returns 2. 0.9.8h ends up rejecting the handshake
with bad message type error (unexpected_message fatal alert).
Am I missing something here or should the CVS rev 220.127.116.11 for
ssl/s3_clnt.c be reverted? I'm going to be doing that at least for the
EAP-FAST patch, so that the latest OpenSSL version can still be used for
EAP-FAST authentication. However, I would like to understand better the
reason for this particular change and would welcome any recommendations
on how to handle this issue for EAP-FAST (RFC 4851).
Jouni Malinen PGP id EFC895FA
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com