Check out the new USENIX Web site. next up previous
Next: Fast, Automatic Checking of Up: Session II: Protocol Analysis Previous: Session II: Protocol Analysis

Analysis of the SSL 3.0 Protocol

David Wagner, University of California, Berkeley; Bruce Schneier, Counterpane Systems

SSL is a protocol for practical application-layer security, mostly for web traffic. The most recent version, 3.0, is an attempt to fix problems with version 2.0 and to add support for more cryptographic algorithms.

SSL version 3.0 is, overall, an improvement. The MAC keys have been expanded to 128 bits, even in the exportable version. Separate keys are now used to perform encryption and authentication. Finally, SSL now uses HMAC as its message authentication algorithm. These improvements help to stop replay and connection truncation attacks. Some standard, simple attacks were tried, but none compromised 3.0's security.

One attack that is successful against 3.0 is a traffic analysis attack, based on the observation that the ciphertext length usually reveals the plaintext length. An eavesdropper on web traffic could record the encrypted request for a URL and a server's encrypted reply. If the attacker can get an index of all the documents on a web server, he can compare the encrypted lengths of the documents and their request strings to the lengths of the observed request and document. A match in lengths between the lengths of an encrypted document and the observed document as well as the encrypted document request and the observed request indicates a very likely match between the unencrypted forms of the documents. This attack reveals which documents a client received from a web server.

In addition, there is an attack on the handshake layer of the protocol. A field used to select between the RSA and Diffie-Hellman algorithms is not part of the signed section of a message. If an adversary were to change the value of that field, the client could become confused about the meaning of signed data, eventually compromising the session's security. If the client performs a sanity check, it could detect this attack, but the sanity check is not mandated by the protocol. The suggested fix is to expand the signature to also cover the field.

There are still many questions for future study. David is not sure whether or not all nonces are properly signed, and the protocol should be checked to make sure that it is not vulnerable to session resumption and version rollback attacks. In general, this analysis was informal, not formal, meaning that it can only illustrate flaws in the protocol, not prove that it's correct.

Martin Abadi asked what the maximum amount of an SSL transaction in which David would be willing to participate was. David answered that SSL is probably acceptable for encrypted credit card transactions. Dan Geer was curious about where the most likely points for an implementation to fail would be. David responded that sanity checks and key management were likely places. Another question was whether cataloging all the documents on a web site is really possible. David did not know how much of a typical web site is made up of dynamically generated documents, but he suspected that the amount is non-trivial.


next up previous
Next: Fast, Automatic Checking of Up: Session II: Protocol Analysis Previous: Session II: Protocol Analysis
Alma Whitten
1998-07-21