Revision c36ceb0b1550f0c2a8d56f81ea33c0d876020a07 authored by Adam Langley on 24 April 2013, 18:45:44 UTC, committed by Emilia Kasper on 24 September 2014, 13:56:09 UTC
that bad encryptions are treated like random session keys in constant time. (cherry picked from commit adb46dbc6dd7347750df2468c93e8c34bcb93a4b) Reviewed-by: Rich Salz <rsalz@openssl.org>
1 parent 904fcce
sslref.dif
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.
Computing file changes ...
