From d02b48c63a58ea4367a0e905979f140b7d090f86 Mon Sep 17 00:00:00 2001 From: "Ralf S. Engelschall" Date: Mon, 21 Dec 1998 10:52:47 +0000 Subject: Import of old SSLeay release: SSLeay 0.8.1b --- bugs/sslref.dif | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 bugs/sslref.dif (limited to 'bugs/sslref.dif') diff --git a/bugs/sslref.dif b/bugs/sslref.dif new file mode 100644 index 0000000000..0aa92bfe6d --- /dev/null +++ b/bugs/sslref.dif @@ -0,0 +1,26 @@ +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. + +SSLref clients wait to recieve a server-verify before they send a +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 +reading. SSLeay was waiting in the server to recieve a client-finish +before sending the server-verify :-). I have changed SSLeay to send a +server-verify before trying to read the client-finished. + -- cgit v1.2.3