]>
Commit | Line | Data |
---|---|---|
d02b48c6 RE |
1 | The February 9th, 1995 version of the SSL document differs from |
2 | https://www.netscape.com in the following ways. | |
3 | ===== | |
4 | The key material for generating a SSL_CK_DES_64_CBC_WITH_MD5 key is | |
5 | KEY-MATERIAL-0 = MD5[MASTER-KEY,"0",CHALLENGE,CONNECTION-ID] | |
6 | not | |
7 | KEY-MATERIAL-0 = MD5[MASTER-KEY,CHALLENGE,CONNECTION-ID] | |
8 | as specified in the documentation. | |
9 | ===== | |
10 | From the section 2.6 Server Only Protocol Messages | |
11 | ||
12 | If the SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE, | |
13 | CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will be zero. | |
14 | ||
15 | This is not true for https://www.netscape.com. The CERTIFICATE-TYPE | |
16 | is returned as 1. | |
17 | ===== | |
18 | I have not tested the following but it is reported by holtzman@mit.edu. | |
19 | ||
20 | SSLref clients wait to recieve a server-verify before they send a | |
21 | client-finished. Besides this not being evident from the examples in | |
22 | 2.2.1, it makes more sense to always send all packets you can before | |
23 | reading. SSLeay was waiting in the server to recieve a client-finish | |
24 | before sending the server-verify :-). I have changed SSLeay to send a | |
25 | server-verify before trying to read the client-finished. | |
26 |