Transport Layer Security

Secure Sockets Layer or SSL is a protocol designed by Netscape Communications Corporation to provide encrypted communications on the Internet. SSL Version 3.0, released in 1996, was later used as a basis to develop Transport Layer Security or TLS, an IETF standard protocol. TLS was first defined in RFC 2246[?]: "The TLS Protocol Version 1.0".

These protocols provide communications privacy over the Internet, using cryptography. They allow client/server applications to communicate in a way that is designed to prevent eavesdropping[?], tampering[?], or message forgery[?].

They are layered beneath application protocols such as HTTP, SMTP and NNTP and above the TCP transport protocol, part of the TCP-IP protocol suite. While both SSL and TLS can be used to add security to any protocol that uses TCP, they is most commonly used in the HTTPS access method. HTTPS is used to secure World Wide Web pages for applications such as Electronic commerce. Both protocols use public key cryptography and public key certificates to identify the identity of endpoints.

Like SSL, on which is was based, TLS is a modular protocol, designed to be extended, with support for forwards and backwards compatibility and negotiation between peers.

Both TLS and SSL involve a number of basic phases:

• peer negotiation for algorithm support
• public key encryption based key exchange and certificate-based identification
• symmetric cipher based traffic encryption

Some early versions of SSL used 40-bit symmetric keys because of restrictions on the export of cryptographic technology[?]. These were quickly abandoned as insecure: the 40-bit key space was simply too small, and could be exhausted by brute force search. Modern implementations use 128-bit keys for symmetric cipher encryption.

TLS has subsequently been extended by other RFCs including:

• RFC 2712[?] "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". The 40-bit ciphersuites defined in this memo are included only for the purpose of documenting the fact that those ciphersuite codes have already been assigned.

• RFC 2817[?] "Upgrading to TLS Within HTTP/1.1", explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).

• RFC 2818[?] "HTTP Over TLS", distinguishs secured traffic from insecure traffic by the use of a different server port.

• RFC 3268[?] "AES Ciphersuites for TLS". Adds enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites[?] to the previously existing symmetric ciphers, like RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES.

While an increasing number of client and server products can support TLS or SSL natively, there are many that still do not. In these cases, you may wish to use standalone SSL products like Stunnel to provide SSL encryption.

External links

• http://www.ietf.org/html.charters/tls-charter
• SSL 3.0 specification (http://wp.netscape.com/eng/ssl3/)
• Using OpenPGP keys for TLS authentication (http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-02.txt).

---

This article (or an earlier version of it) contains material from FOLDOC's article on SSL (http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?Secure+Sockets+Layer), used with permission.