1998-12-21 10:52:47 +00:00
|
|
|
The February 9th, 1995 version of the SSL document differs from
|
|
|
|
|
https://www.netscape.com in the following ways.
|
|
|
|
|
=====
|
|
|
|
|
The key material for generating a SSL_CK_DES_64_CBC_WITH_MD5 key is
|
|
|
|
|
KEY-MATERIAL-0 = MD5[MASTER-KEY,"0",CHALLENGE,CONNECTION-ID]
|
|
|
|
|
not
|
|
|
|
|
KEY-MATERIAL-0 = MD5[MASTER-KEY,CHALLENGE,CONNECTION-ID]
|
|
|
|
|
as specified in the documentation.
|
|
|
|
|
=====
|
|
|
|
|
From the section 2.6 Server Only Protocol Messages
|
|
|
|
|
|
|
|
|
|
If the SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE,
|
|
|
|
|
CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will be zero.
|
|
|
|
|
|
|
|
|
|
This is not true for https://www.netscape.com. The CERTIFICATE-TYPE
|
|
|
|
|
is returned as 1.
|
|
|
|
|
=====
|
|
|
|
|
I have not tested the following but it is reported by holtzman@mit.edu.
|
|
|
|
|
|
2013-06-12 23:22:32 +00:00
|
|
|
SSLref clients wait to receive a server-verify before they send a
|
1998-12-21 10:52:47 +00:00
|
|
|
client-finished. Besides this not being evident from the examples in
|
|
|
|
|
2.2.1, it makes more sense to always send all packets you can before
|
2013-06-12 23:22:32 +00:00
|
|
|
reading. SSLeay was waiting in the server to receive a client-finish
|
1998-12-21 10:52:47 +00:00
|
|
|
before sending the server-verify :-). I have changed SSLeay to send a
|
|
|
|
|
server-verify before trying to read the client-finished.
|
|
|
|
|
|
