-----Original Message-----
From: Kruikemeier, Joep (GXS)
Sent: Monday, January 27, 2003 3:10 PM
To: '[EMAIL PROTECTED]'
Cc: Vos, Erik (GXS); Bosma, Peter (GXS); Kruikemeier, Joep (GXS)
Subject: OpenSSL questions
Hello,
Due to an existing project for one of our clients, we would like to get some detailed answers on the following questions concerning
the OpenSSL coding ( based on OpenSSL 0.9.6g ) :
- Client Key exchange - handling format errors
In handling a client key exchange message, the server component should, upon detection of an erroneous message format, fill the pre_master_secret element with random data, and then continue the handshake protocol until an error occurs upon reception of the client finished message. This measure is taken in view of a weak spot in the protocol (the million message attack, also see RFC 2246, section 7.4.7.1).
Question : How is this aspect implemented?
- Handling of invalid message sequence
Generally speaking under the protocol specification, messages are presented in sequence they are sent; deviation from this sequence causes a fatal error. The SSL implementation should not accept a finished message without a preceding change cipher spec message. This requirement is specifically noted, as it is not clearly covered in the protocol specification (SSL design 3.1.7).
Question : How is this aspect implemented? - Handling of incorrect MAC
The MAC (Message Authentication Code) is a value that is calculated for each message, using parameters that are determined during setup of the connection. This allows confirmation for each message that it originated with the partner with which the connection was established. (SSL design 3.1.10). Special attention is also required for the "Hello done" messages. These still form part of the initialization protocol, but are sent after changing the encryption code.
Question : How does the system react to the receipt of an incorrect MAC? And will the answer also be applicable for the "hello
done" messages ? - Storing the master_secret element
The master_secret element is a vulnerable point of the SSL 3.0 protocol. Its secrecy should therefore be carefully guarded. Among other things, this means that storage on a file system is not allowed, and that the owning process has exclusive access to this element in memory. This element is used in the certificate verify, finished and change cipher spec messages (SSL design 3.1.2).
Question : How is exclusive access to the master secret element by the SSL component guaranteed?
Best Regards,
Joep Kruikemeier
Project Manager
Strategic Accounts
Global eXchange Services
e-mail : [EMAIL PROTECTED]
