Skip to main content
  • Home
  • login
  • Browse the archive

    swh mirror partner logo
swh logo
SoftwareHeritage
Software
Heritage
Mirror
Features
  • Search

  • Downloads

  • Save code now

  • Add forge now

  • Help

  • 055d593
  • /
  • bugs
  • /
  • sslref.dif
Raw File
Permalinks

To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.

  • content
  • directory
content badge Iframe embedding
swh:1:cnt:0817009bb453b705bf669c41b70877f7ce0e9129
directory badge Iframe embedding
swh:1:dir:11427142752ff0f29cf28ea5c40d9cd91c639481
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 receive 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 receive a client-finish
before sending the server-verify :-).  I have changed SSLeay to send a
server-verify before trying to read the client-finished.

ENEA — Copyright (C), ENEA. License: GNU AGPLv3+.
Legal notes  ::  JavaScript license information ::  Web API

back to top