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) C>S 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) S>C 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.0000) S>C ChangeCipherSpec
2 4 0.0025 (0.0000) S>C Handshake
2 5 0.0027 (0.0001) C>S ChangeCipherSpec
2 6 0.0027 (0.0000) C>S Handshake
2 7 0.0430 (0.0402) C>S application_data
2 8 0.0430 (0.0000) C>S application_data
2 9 0.0459 (0.0029) S>C application_data
2 10 0.0459 (0.0000) S>C application_data
2 11 0.0461 (0.0001) S>C Alert
2 0.0463 (0.0001) S>C TCP FIN
2 12 0.0468 (0.0004) C>S Alert
2 0.0469 (0.0000) C>S 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]
