Re: SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??
On Fri, Sep 17, 2004 at 12:39:23AM +0200, Frédéric Giudicelli wrote: Jacques A. Vidrine wrote: 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 ! Oh good, then the behavior is as expected. 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 ? Actually, I am not familiar with the history, but I assume that it is required to work around quirks in some version of Netscape. Maybe someone else will be able to tell us more. Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??
Target: openssl-0.9.7d Hi, In ssl/ssl.h, SSL_OP_ALL is defined as various bug workarounds that should be rather harmless, however it includes the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option, which is rather not a harmless option, since it allows a user to change the cipher during a session resuming. The problem is that it by-passes the verification of acceptable ciphers on server side. Therefore, if some one is able to get a valid session id from another user (by sniffing or whatever other way), it will be able to connect to the server and specify the RSA-NULL cipher, therefore the previous session won't be needed, and there won't be any proof that the current user is the previous one (ssl session hijacking). SSL_OP_ALL is defined as 0x0FFFL, could it be possible to define it in ssl/ssl.h as (SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG | SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER | ... )? Could it be possible, as well, to comment, in ssl/ssl.h, the options used in SSL_OP_ALL, eg. specify what SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG exactly does ? I know that these options are documented in the man page of SSL_(CTX)_set_options, however it doesn't explicitly explain the potential problems arising when using them. The problem is that most programs that use openssl will do a SSL_(CTX)_set_options(ctx, SSL_OP_ALL) (mod_ssl, newpki, etc.) without knowing what the consequences are. Regards, -- Frédéric Giudicelli http://www.newpki.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??
On Thu, Sep 16, 2004 at 10:55:46AM +0200, Frédéric Giudicelli wrote: Target: openssl-0.9.7d Hi, In ssl/ssl.h, SSL_OP_ALL is defined as various bug workarounds that should be rather harmless, however it includes the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option, which is rather not a harmless option, since it allows a user to change the cipher during a session resuming. The problem is that it by-passes the verification of acceptable ciphers on server side. Therefore, if some one is able to get a valid session id from another user (by sniffing or whatever other way), it will be able to connect to the server and specify the RSA-NULL cipher, therefore the previous session won't be needed, and there won't be any proof that the current user is the previous one (ssl session hijacking). ``therefore the previous session won't be needed''? But the handshake still must be completed, must it not? And to do so, the attacker would need to know the master_secret (for the Finished messages). I must be missing something. Would you mind explaining a bit further for the slow? :-) Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??
Jacques A. Vidrine wrote: ``therefore the previous session won't be needed''? But the handshake still must be completed, must it not? And to do so, the attacker would need to know the master_secret (for the Finished messages). I must be missing something. Would you mind explaining a bit further for the slow? :-) Cheers, Hi, Yes the handshake is completed. To resume a session the client set the Session ID field in the Client Hello message, and that's it. Normally the server is sure that it's the real client, because the client will be able to decrypt the datas using the symetrical key that was exchanged during the previous handshake. The problem is that the datas won't be crypted anymore because during the Client Hello message the attacker specified a NULL cipher... I'm attaching a network dump of both the connections, you will see the problem :) Regards, -- Frédéric Giudicelli http://www.newpki.org ssl-null.dmp Description: Binary data
Re: SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??
On Thu, Sep 16, 2004 at 09:51:24PM +0200, Frédéric Giudicelli wrote: Jacques A. Vidrine wrote: ``therefore the previous session won't be needed''? But the handshake still must be completed, must it not? And to do so, the attacker would need to know the master_secret (for the Finished messages). I must be missing something. Would you mind explaining a bit further for the slow? :-) Cheers, Hi, Yes the handshake is completed. To resume a session the client set the Session ID field in the Client Hello message, and that's it. 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)) Normally the server is sure that it's the real client, because the client will be able to decrypt the datas using the symetrical key that was exchanged during the previous handshake. Hmm, I thought that the server is sure that it's the real client because only the real client could complete the handshake. The problem is that the datas won't be crypted anymore because during the Client Hello message the attacker specified a NULL cipher... I'm attaching a network dump of both the connections, you will see the problem :) 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. (The resumption you sent) New TCP connection #2: 10.0.0.1(40278) - 10.0.0.253(443) 2 1 0.0005 (0.0005) CS Handshake ClientHello Version 3.0 resume [32]= 6c 98 fa ec 78 cd 3d 8b 4e e9 71 78 b9 61 6d 0d 9d 1e aa 14 6c 48 73 1e 8b 7f 5d a5 61 4e 72 ed cipher suites SSL_RSA_WITH_NULL_SHA compression methods NULL 2 2 0.0025 (0.0020) SC Handshake ServerHello Version 3.0 session_id[32]= 6c 98 fa ec 78 cd 3d 8b 4e e9 71 78 b9 61 6d 0d 9d 1e aa 14 6c 48 73 1e 8b 7f 5d a5 61 4e 72 ed cipherSuite SSL_RSA_WITH_NULL_SHA compressionMethod NULL 2 3 0.0025 (0.) SC ChangeCipherSpec 2 4 0.0025 (0.) SC Handshake 2 5 0.0027 (0.0001) CS ChangeCipherSpec 2 6 0.0027 (0.) CS Handshake 2 7 0.0430 (0.0402) CS application_data 2 8 0.0430 (0.) CS application_data 2 9 0.0459 (0.0029) SC application_data 2 10 0.0459 (0.) SC application_data 2 11 0.0461 (0.0001) SC Alert 20.0463 (0.0001) SC TCP FIN 2 12 0.0468 (0.0004) CS Alert 20.0469 (0.) CS TCP FIN If this were a real attack, then the server should have aborted the message upon receiving message #6, should it not have? Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??
Jacques A. Vidrine wrote: 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]
