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 1.88.2.13) 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 1.88.2.13 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 1.88.2.13 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
