Tuesday, October 27, 2009
The SSL and TLS Protocols
The SSL and TLS Protocols
SSL (Secure Sockets Layer) was originally
developed by Netscape as a means of securing communications across the
Internet, primarily for electronic commerce. Atotal of three versions
of the protocol were developed, with the last one, SSL version 3.0,
being released in 1996. Since then, the development of the original
idea has continued with TLS (Transport Layer Security), with the first
version being published in RFC 2246 in January 1999. At this point,
virtually all financial institutions have endorsed the use of SSL for
electronic commerce.
The
protocol is an interesting one, as it designed to be extensible. The
initial handshake done between two end points when they are setting up
an SSL channel includes negotiation for both the algorithms to be used
and the key size. The algorithm set used for an SSL channel normally
includes at least one public key mechanism, a symmetric cipher, a MAC
algorithm, as well as their associated key sizes. This collection of
algorithms is normally referred to as a cipher suite,
and as you may well imagine, some cipher suites are better than others
from a security point of view. The presence of weak cipher suites is
largely for historical reasons, but you do need to be aware that they
exist, as when you are using SSL, you should to take care to configure
the link creation with specific cipher suites. You should do this so
that a possibly malicious server or client cannot dumb down the
cryptography being used on the link by using the negotiation phase to
its advantage and subsequently fool your end of the link into
transmitting the data across a link with much lower security than you
wanted.
Normally you would have seen SSL being used where only
one end point is actually authenticated(the server end. This is the
common practice for Internet shopping; however, the protocol does allow
for both ends of the link to authenticate to the other one. This type
of link is usually described as one with clientside authentication,
because it is assumed the server side is always authenticated.
Since RFC 2246 came out, other RFCs have also been
published that add the use of Kerberos cipher suites (RFC 2712),
extensions (RFC 3546), the AES algorithm (RFC 3268), and compression
methods (RFC 3749). The RFCs read quite differently than the normal
ones you run into in security, as, unlike the PKIX RFCs on the use of
public key certificates, the TLS-related RFCs have their message
formats documented in a C-like language rather than ASN.1. Currently,
TLS is still at version 1.0, but at this writing, there is a TLS
version 1.1 RFC under development, which will probably be released at
the end of 2005. You can find out more about the development of TLS by
looking at the Web site for the TLS Working Group, which is listed in Appendix D.
Having said all that, as SSL and TLS are both low-level
protocols that operate just above the socket layer, you do not really
need to be familiar with the RFCs to be able to use it in Java. The
Java API that deals with SSL and TLS is the Java Secure Socket
Extension, or JSSE for short. At its simplest, it can be summed up as
providing two additional socket factory types and two additional socket
types that can be used in the same way as regular socket factories and
sockets defined in the java.net package. The JSSE goes a lot further than that, but that should give you an idea.
Like SSL itself, the JSSE has now gone through several
versions. It was previously a standard extension to the JDK, versions
1.2 and 1.3. As of JDK 1.4, the JSSE was integrated into the JDK. This
did result in some changes to the API, as prior to its integration with
the JDK, some of the classes now found in the javax.net.ssl package were originally found in com.sun.net.ssl.
So, if you are trying to use the examples with older versions of the
JSSE, you might need to change the imports used in the examples
accordingly and make a few other minor adjustments.
As of JDK 1.5, the JSSE can also support the
Kerberos cipher suites outlined in RFC 2712. I won't discuss Kerberos
support here in any detail, because I want to concentrate on using SSL
with X.509, but it is a fact worth being aware of.
No comments:
Post a Comment