Cryptography Reference
In-Depth Information
APPENDIX
C
Understanding the
Pitfalls of SSLv2
With all the elements of a secure connection — cryptography, authentication, secure
key exchange and message authentication — it should be a simple matter to put
it all together securely, right? Well, as it turns out, even when all the pieces are
in place, it's surprisingly easy to get subtly wrong. Just ask the original Netscape
engineers who released SSLv2. On paper, they did everything right, but the protocol
was found to have subtle, but fatal fl aws after it had been widely released. To the
credit of the Netscape protocol designers, everybody else thought that they had
gotten everything right the fi rst time around as well. It wasn't until the protocol
had been intensively studied in action that the chinks in the armor began to show.
Because SSLv2 was widely disseminated before it was found to be fl awed, it's
interesting to start by examining exactly how it worked, and then move on to see
what's wrong with the protocol. SSL was specifi ed fairly rigorously and submit-
ted as an IETF draft (
http://www.mozilla.org/projects/security/pki/nss/
ssl/draft02.html
), but its fl aws were discovered before it was accepted, so it's
never been offi cially blessed by the IETF. Although SSLv2 has been deprecated,
there are pockets of support for it, so you can easily fi nd the protocol details.
This appendix details an SSLv2 implementation similar to the TLS imple-
mentation presented in Chapter 6. I've assumed you're familiar with Chapter 6;
I discuss only the differences between the two implementations here. I do my
best to avoid covering old ground, but since SSLv2 and TLS 1.0 have the same
goals — to encrypt and authenticate a channel — it's unavoidable that some
similar elements reappear here.
Search WWH ::
Custom Search