SSL provides for encryption of a session, authentication of a server, and optionally a client, and message authentication. The SSL Handshake Protocol and the application protocol both operate on top of the SSL Record Protocol, a simple means of encapsulating authentication information. SSL-Record Layer works on TCP or some other reliable transport mechanism. Session establishment takes from 5 to 8 messages, depending on options used. SSL relies on the existence of a key certification mechanism for the authentication of a server. SSL does not provide for renegotiation of keys within a session. (This is not a problem in HTTP, but might be with other protocols.) A multitude of ciphers and secure hashes are supported, including some explicitly weakened to comply with export restrictions.
The meaning of bits is as follows: 1 2 3 4 5 6 7 8 +----------------+-----------------+----------------+ |# S Length | Length | Padding length | +----------------+-----------------+----------------+ # is the number of bytes in the header 0 indicates a 3 byte header, max length 32,767 bytes. 1 indicates a 2 byte header, max length 16,383 bytes S indicates the presence of a security escape, although none are currently implemented. (Several suggestions for security escapes are in the weaknesses section.)There is no version information within the SSL record header, although it is available in the handshake.
Within a record, there are three components: MAC-DATA, Actual-data, and Padding-data. MAC is the Message Authentication Code, Actual-data is the actual data being sent, and Padding-data is padding.
The MAC-DATA is a hash of a key, the data, padding, and a sequence number. The hash is chosen based on the cipher-choice. The key used is the (sender)-write-key, which is the same key as the (receiver)-read-key. When cipher-choice is not defined, there is no mac-data or padding-data.
Padding is used to ensure that the data is a multiple of the block size when a block cipher is used. Padding data is always discarded after the MAC has been calculated.
Sequence numbers are unsigned 32 bit integers incremented with each message sent. Sequence numbers wrap to zero after 0xFFFFFFFF. Each dialog direction has its own sequence number.
Failure to authenticate, decrypt, or otherwise get correct answers in a crytpographic operation result in I/O errors, and a close of connection.
For the initial connection, when a client wishes to establish a secure connection, it sends a CLIENT-HELLO message, including a challenge, along with information on the cryptographic systems it is willing or able to support. The server responds with a SERVER-HELLO message, which is connection id, its key certificate, and information about the cryptosystems it supports. The client is responsible for choosing a cryptosystem it shares with the server.
The client then verifies the server's public key, and responds with a CLIENT-MASTER-KEY message, which is a randomly generated master key, encrypted or partially encrypted with the servers public key. The client then sends a CLIENT-FINISHED message. This includes the connection-id, encrypted with the client-write-key. (All these keys are explained separately, in the next section.) The server then sends a SERVER-VERIFY, verifying its identity by responding with the challenge, encrypted with the server write key. The server got its server-write-key sent to it by the client, encrypted with the server's public key. The server thus must have the appropriate private key to decrypt the CLIENT-MASTER-KEY message, thus obtaining the master-key, from which it can produce the server-write-key.
When a session identifier is found by the client, a slightly different initialization takes place. It is initially distinguishable by the CLIENT-HELLO message including a session-id. The SERVER-HELLO response includes a set "session_id_hit" bit if the session-id is found. The client then sends an encrypted connection-id for this session in the CLIENT-FINISH message. The server responds with a SERVER-VERIFY and a SERVER-FINISH message, which are close to identical to those used in the "No session identifier case." The only difference is that the SERVER-FINISH message contains a session-id instead of new-session-id.
If client authentication is in use, then the server must at some point, send a REQUEST-CERTIFICATE message, which contains a challenge (called challenge') and the means of authentication desired. The client responds with a CLIENT-CERTIFICATE message, which includes the client certificate's type, the certificate itself, and a bunch of response data. The server then sends a SERVER-FINISH message.
To summarize those messages, they are:
2.2.1 Assuming no session-identifier
client-hello C -> S: challenge, cipher_specs
server-hello S -> C: connection-id,server_certificate,cipher_specs
client-master-key C -> S: {master_key} server_public_key
client-finish C -> S: {connection-id} client_write_key
server-verify S -> C: {challenge} server_write_key
server-finish S -> C: {new_session_id} server_write_key
2.2.2 Assuming a session-identifier was found by both client & server
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {session_id}server_write_key
2.2.3 Assuming a session-identifier was used and client
authentication is used
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
request-certificate S -> C: {auth_type,challenge'}server_write_key
client-certificate C -> S: {cert_type,client_cert, response_data}client_write_key
server-finish S -> C: {session_id}server_write_key
In this last exchange, the response_data is a function of
the auth_type. (These tables are taken verbatim from the SSL
Specification, Section numbers as indicated.)There are some errors defined for the handshake. They are NO-CIPHER-ERROR, client NO-CERTIFICATE-ERROR, BAD-CERTIFICATE-ERROR, and UNSUPPORTED_CERTIFICATE_TYPE. NO-CIPHER occurs when the client and server can't agree on a cipher. (It is not clear why SSL doesn't require support for some simple cipher, such as RC4-40.) The other errors are recoverable if the client is the one with the bad certificate.
Client-write-key and client-read-key are derived via a secure hash from the master key, an ordinal character, the challenge, and connection-id. Of this input, only the master key is sent encrypted (with the server's public key.) The master key is reused across sessions, while the read- & write- keys are generated anew for each session.
Two or more sets of key material are generated, based on how many bits of key are needed. Hash tends to be MD5, but is not required to be so by the spec. It is MD5 for all cipher types currently defined.
key-material-N = hash (master key, "N", challenge, connection-id) Keys are taken from the output of these hashes. Because of the design of secure hashes, changing 'N' will result in the output of these hashes being very different.
Insiders, especially those around the top of the key certification hierarchy, have the potential to do quite a bit of harm by creating false signatures on keys. Few of these attacks will occur in a vengeful manner; they require time and foresight to enact, and are probably the domain of the malicious employee. (This assumes that employees who become vengeful do so at about the time they leave a firm.)
A criminal organization could, depending on its resources, possibly target an employee at a key certification organization. However, a more useful option might be to buy a cheap PC, and have it attempt brute force RC4 keys. It is estimated that a pentium based PC should be able to crack a 40 bit RC4 key in a month or several months using brute force. The manipulations used on the master key may increase the cost of tha attack, but probably not by orders of magnitude. If a PC costs $1500, then breaking 12 keys a year leads to a cost that could be as low as $125 per stolen card number. While this seems like a high price, the credit card numbers are acquired in a nearly risk free manner of sniffing an ethernet. In addition, that time will drop with the introduction of faster hardware.
SSL is designed to protect at the network layer. This means it is not designed to, and does not, protect you from host breakins. To protect against host breakins, a Tripwire-like package should be integrated with the HTTPd. Tripwire uses cryptographically strong hashes to ensure documents have not been changed from some reference version. The database is usually stored on a physically write protected media like a floppy (Kim).
The use of RC4 is troublesome, albeit understandable. RC4 is a newly published cipher, and although it was designed by the very competent Ron Rivest, it has not been subjected to the same kind of intense professional scrutiny that DES and IDEA have undergone. The decision to use RC4-40 is driven by the fact that it gets automatic export approval from the State Department.
There are also a number of areas in the design of SSL as it stands that could become exploitable problems. None suggest an immediate means of attack, but are things which could be modified for possible added surety.
Handshaking protocol: The challenge data, sent in the CLIENT-HELLO message, could in some types of handshakes, be sent later, encrypted. The data used in generating the session keys could include more data not sent in the clear. The means of generating the master key should be better specified, probably with reference to RFC-1750.
Record protocol: Bad MAC-data should not terminate a connection, it should cause a repeat-request message. There are few attacks that will get anything from having the same data resent, and closing the connection on a bad message opens avenues for denial of service attacks. Sequence numbers should be randomly initialized. There are quite a few non-obvious attacks on sequence numbers (in IP, and NFS); it can't hurt to start with a non-predictable number.
There should be a way for one or both sides to demand renegotiation of keys. Perhaps this could be implemented as a security escape. This is not needed for HTTP connection security, since the connections are very short lived, but if SSL is used, as the authors suggest, for telnet or FTP, the sessions could last substantially longer.