| Ralf S. Engelschall | d02b48c | 1998-12-21 10:52:47 +0000 | [diff] [blame] | 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 | |
