On Thu, Sep 16, 2004 at 09:51:24PM +0200, Fr�d�ric Giudicelli wrote:
Then is there some additional bug? SSL session resumption requires
C->S: ClientHello w/session_id S->C: ServerHello w/same session_id ChangeCipherSpec Finished C->S: ChangeCipherSpec Finished
The session is not resumed before all of these messages have been processed. In this scenario, the client (the attacker) would not be able to produce an acceptable Finished message because it does not have access to the master_secret. Even if the Finished message is not encrypted, the contents are dependent upon the master_secret. i.e. for SSLv3 we have
MD5(master_secret + padding + MD5(messages + client + master_secret + padding)) SHA1(master_secret + padding + SHA1(messages + client + master_secret + padding))
Thanks! What did you use for this test? If you are using OpenSSL, did the client do SSL_get_session and SSL_set_session? I'm assuming that the handshake completed because your second connection used the previously generated master_secret.
You're right, when I unset the master key, the connection fails !
But there is still a question I wonder about, how come when SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG is set, the list of acceptable ciphers is ignored ?
If I did set "ALL:!NULL", do I really want the user to be allowed to specify RSA-NULL as the new cipher ?
Thanks a lot for your information. -- Fr�d�ric Giudicelli http://www.newpki.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
