Cryptography Reference
In-Depth Information
transmitted and published in a TLS connection are actually SSL versions, not
TLS versions. TLS 1.0 was formally specifi ed by RFC 2246 in 1999.
Although SSLv3 was also never offi cially ratifi ed by the IETF, SSLv3 and TLS
1.0 are both widespread. Most current commercial implementations of SSL/
TLS support both SSLv3 and TLS 1.0; TLS also includes a mechanism to negoti-
ate the highest version supported. SSLv3 and TLS 1.0, although similar except
for some cosmetic differences, are not interoperable — a client that only sup-
ports SSLv3 cannot establish a secure connection with a server that only
supports TLS 1.0. However, a client that supports both can ask for TLS 1.0 and
be gracefully downgraded to SSLv3.
At the time of this writing, SSLv3 and TLS 1.0 are by far the most wide-
spread implementations of the protocol. In 2006, a new version, 1.1, was
released in RFC 4346; it's not radically different than TLS 1.0, and the few dif-
ferences are examined at the end of this chapter. Two years later, TLS 1.2 was
released, and it was a major revision; TLS 1.2 is covered in depth in Chapter 9.
This chapter focuses on TLS 1.0. A complete implementation of the client-
side of TLS 1.0 is presented here in some detail.
Implementing the TLS 1.0 Handshake
(Client Perspective)
As much as possible, TLS aims to be completely transparent to the upper-layer
protocol. Effectively, this means that it tries to be completely transparent to the
application programmer; the application programmer implements the protocol
in question as if TLS was not being used. As long as nothing goes wrong, TLS
succeeds admirably in this goal; although, as you'll see, if something does go
wrong, everything fails miserably and the developer is left scratching his head,
trying to fi gure out what he missed.
Of course, TLS can't be completely transparent. The application must indicate
in some way that it wants to negotiate a secure channel. Perhaps surprisingly,
TLS doesn't specify how the application should do this nor does it even provide
any guidance. Remembering that SSL was initially developed as an add-on to
HTTP, this makes some sense. The protocol designers weren't thinking about
applicability to other protocols at the time. In fact, they didn't even specify how
to use HTTP with SSL, assuming that there was only way to do so. It actually
wasn't until 2000 that Eric Rescorla fi nally drafted RFC 2818 that describes how
it should be done.
TLS requires that the handshake — a secure key exchange — takes place
before it can protect anything. Effectively the question is when the handshake
should take place; anything that's transmitted before the handshake is complete
is transmitted in plaintext and is theoretically interceptable. HTTPS takes an
extreme position on this. The very fi rst thing that must take place on the channel is
Search WWH ::
Custom Search