SSL and TLS 1

Running head: Secure Socket Layer/SSL

Secure Socket Layer/SSL

In APA style
(NAME WITHHELD)
Loyola University of Chicago

SSL and TLS 2

Abstract
A number of decades ago, the Internet was formed. Although it was nothing compared to what it
is today, it created a way for many people to collaborate and share ideas and eventually items
from great distances apart. It opened new worlds and new concepts that could never be
achieved before. However, in the background was a group of people that wanted to do harm to
this infrastructure. With this underground threat, people needed a sense of security to know that
the ideas and concepts were kept from those who might do evil. One of the first widely used and
relatively secure answers to this protection that was sought came in SSL (Secure Socket Layer)
and TLS (Transport Layer Security (which would come later from SSL version 3.0). The history
of these protocols, the implementation and how it works in the internet world, the benefits of SSL
and TLS over other protocols, the known issues, both positive and negative, and the availability
of the this security will be covered in depth in this paper.

In November of 1993 the first popular browser was released. This browser went by the
name of Mosaic and it was created by the National Center for Supercomputing Applications
(Thomas, 2000). Roughly eight months later Netscape communications sought a way to create a
sense of security over that browser by creating SSL version 1.0. Netscape would later create its
own browser with the newer version 2.0 of SSL fully integrated into it, by the name of Netscape
Navigator. Netscape protected this new technology by obtaining a patent on it, but this did not
detour software competitor Microsoft from entering the market. Microsoft, now well known for
its browser Internet Explorer, looked to improve on the SSL technology by making
enhancements to version 2.0, by developing Private Communications Technology (PCT)

SSL and TLS 3

(Thomas, 2000). This technology would later be integrated into version 3.0 of SSL, which is still
in use today. With the idea of a secure Internet browser, and the widespread acceptance of the
SSL technology, it would soon become the standard by which Internet users would be secure on
the web. To make this acceptance official, the technology was submitted to the Internet
Engineering Task Force (IETF) to make SSL the standard for the new idea TLS (Erkomaa,
1998).

TLS is still a rather emerging technology that has much in common with SSL, however

with some improvements and changes to the point that the two are no longer interoperable.

SSL Record Protocol

Record Header

Record Data

Record Header Type

Record Length

MAC-Data

Record Header Type

MAC-Data

Escape-Bit

Actual Data

Record Header Type

Actual Data

Padding-Length

Padding-Data

Figure 1: SSL Record Protocol Data Structure

The SSL protocol uses two sub protocols. These protocols are the SSL handshake
protocol, and the SSL record protocol (which occur in that order). To put it briefly the
handshake is an exchange of messages between the client and the server to initialize a tunnel

SSL and TLS 4

of information that would be secure only between the two endpoints. The record protocol
defines the actual data that is to be sent through the SSL enable connection.
The handshake in societal terms has only the function to introduce oneself, but in the
terms of SSL it has many functions. It is used to authenticate the server to the client. This is
important for the client to know that the server is actually who they say they are. The handshake
also allows the client and the server to select the type of encryption and the types of ciphers (to
be covered later) to be used in the remainder of the connection. SSL also allows the server to
authenticate the client, an extra security measure to make sure that both endpoints are genuine in
their connection. However, foremost the handshakes function is to establish the remainder of
the SSL connection to be handled through the record protocol.
The SSL handshake sub protocol begins with the exchange of messages between the
server and the client. This series of messages are sent in a rather complex manner but one that
will enable a secure connection between the two endpoints (SSL Protocol, 1996). It begins
with the client sending the server the clients SSL version number, the cipher settings, some
randomly generated data, and any other optional data that the client would like to establish with
the server (Introduction, 1998). From this point the server sends it SSL version number, etc to
the client along with an optional sending of the servers digital certificate.
The client then uses this data sent by the server to authenticate the server. This is done
by four checkpoints by the client based on the server. 1) Check if the servers certificate has not
expired 2) Check if the institution issuing the certificate to the server is genuine. 3) Check if the
institution that issued the certificate agrees with the certificate that the server has supplied. 4)
Check if the domain name in the certificate is the same as the one issued by the server
(Introduction, 1998). The server must pass all of these four checkpoints to continue the

SSL and TLS 5

connection. If the authentication cannot be established a return message that the authentication
failed is sent back to the server. However, if the authentication was successful, the process will
continue.
SSL Handshake authentication
Servers Certificate
Certificates Serial Number

1) Is todays date within

validity
period?

Certificates Validity Period

Servers Domain Name
Issuers Domain Name

2) Is issuing Certificate
Authority a trusted Certificate Authority?
3) Does issuing Certificate Authoritys public
key validate issuers
digital signature?

Clients List of Trusted

Certificate Authorities

Issuers Digital Signature

Issuers CAs Certificate
4) Does the domain
name specified in the
servers domain name
match the servers actual domain name?

Issuers Domain Name

Issuers Public Key
Issuers Digital Signature

Figure 2: SSL Handshake Protocol Process

Using the data sent in the handshake to this point, the client sends an encrypted premaster secret to the server (Introduction, 1998). If in the original data block sent from the
server back to the client included the authentication of the client, the client will also send its own
certificate along with this secret. The authentication of this certificate progresses in a similar
manner to the client authenticating the server. Once again, if this authentication of the client
fails, the connection is terminated. However, if it is successful, the server will then decrypt the

SSL and TLS 6

data sent by the client and then use the pre-master secret in creating a master secret that is
encrypted with the servers own private key (Introduction, 1998).
Once that has been established the client and the server then set up a session key to be
used for the entirety of the connection to encrypt and decrypt the data sent between the two users
(Introduction, 1998). This session key is symmetrical in that it is the same key used to encrypt
and decrypt and it is the same between the client and the server. The session key is also useful in
testing for message integrity in that the data being sent is from whom it supposed to be from, and
that it is received in order. The server then sends the client a message indicating that the next
message sent by the server will be encrypted and that the servers portion of the handshake is
complete.
As mentioned before the SSL handshake tells the server and the client which ciphers both
users support. Ciphers are cryptographic algorithms that are used to encrypt and decrypt the
information that is sent between the two endpoints. SSL supports a wide variety of these ciphers.
However, the ciphers supported can depend on the version of SSL being used. The strength of
the security desired by both endpoints, and also where, geographically, the two endpoints are
located. The ciphers supported generally by SSL are: Data Encryption Standard (DES), Digital
Signature Algorithm (DSA), Key Exchange Algorithm (KEA), Message Digest Algorithm
(MD5), Rivest Encryption ciphers (RC2 and RC4), Rivest, Shamir and Adleman (RSA), Secure
Hash Algorithm, (SHA-1), SKIPJACK, and Triple-DES. Versions 2.0 and 3.0 of SSL support
the overlapping of these ciphers (Introduction, 1998). Although this may provide more
security especially in the case of very sensitive data, it has the drawback of requiring a
considerable amount of processing time and power to accomplish. Also in some countries the
use of some of the ciphers are not supported due to government restrictions of key size. It is

SSL and TLS 7

usually in the best interest for the client and the server to support as many of the ciphers as
possible to enable a strong and secure connection that is supported by both sides.
The handshake method in the TLS protocol is very similar. However TLS improves on
the security by enabling the transmission of the protocol version, the session id, the cipher suite
being used and the compression method being used (Introduction, 1998). TLS also adds two
hash algorithms that are lacking in SSL.
The record protocol portion of the SSL encryption scheme is much simpler than the
handshake protocol. Each message that is sent between the server and the client consists of two
parts. These two parts are the header and the data. In the header is located the type of the header
included, the length of the data stream being sent. In some cases the header can actually be
longer by including an escape bit, and the padding-length (the amount of non-data bits being
added to the data) in the message. This usually occurs at the end of the transmission by either
side. In the actual data portion of the message is a Message Authentication Code (MAC)
(Introduction, 1998). Within the MAC is the ability to number the messages being sent so that
the endpoint may decipher between the messages and put them in the correct order in case some
blocks of data arrived at a different time than others.
One of the strongest features of the SSL and TLS protocol is where the two lie in relation
to the other protocol layers involved in network communication. At the top of the network is the
application software or the browsers mentioned earlier. Underneath this layer, is the application
protocol, which may include Telnet, FTP, HTTP etc (Introduction, 1998). Underneath this
layer, is the SSL protocol and the type of cryptographic algorithm being used in the
communication. Underneath this layer, is the transfer protocol. In most cases this is TCP/IP,
however SSL is unique in that it does not rely on that protocol to function properly. Last in the

SSL and TLS 8

layers is the actual physical layer that is involved in the network. By SSL separating itself from
the rest of the layers, and not placing itself in a different subsection of the overall network
system, SSL is able to remain a platform independent as well as a network independent entity.
Another strength of SSL is that it is protected from dictionary attacks (Erkomaa, 1998).
This is the use of some dictionary to break the key of the encryption scheme. SSL overcomes
this be enable very large key spaces for the ciphers being used. In most domestic cases it is
usually 128-bit encryption making it a very large key that would take an almost immeasurable
time to crack. This dictionary attack is further thwarted by the use of a nonce number
(Erkomaa, 1998). This is a truly randomly generated number that the server uses that is again
almost impossible to crack.
SSL also protects itself against man-in-the-middle attacks (Erkomaa, 1998). This is
where another client may intercept the data traveling between the server and the original client.
This second client may masquerade as either the client or the server in this case. SSL protects
against this by the use of a private key used by the server, and the use of certificates.
SSL encryption is not completely secure however. It should be established that many of
the faults in SSL lie not really in SSL itself but more in the cryptographic algorithms that SSL
chooses to use and accept. One feature that is a strength of SSL, the fact that it is in its own
layer making it independent of the transfer protocol layer, is also a weakness. SSL does not rely
on TCP/IP as a transfer protocol, however it does work best with it (SSL Protocol, 1996).
TCP/IP is a stable transfer protocol. SSL requires that the protocol being used be a stable one.
SSL does not work with connectionless protocols, such as UDP (Erkomaa, 1998). This
shortcoming comes as a negative to some users of SSL.

SSL and TLS 9

A project called Hals Challenge has been set up over the years since the inception of
SSL that is designed for people to break the SSL security. The first time was in 1993 by an
American and a French group that were able to break the 40-bit encryption scheme (Erkomaa,
1998). In 1997, the strength of the encryption was increased to 48-bit and 56-bit respectively.
Each of these two keys were broken. Still today, the Hals Challenge exists, and is being made
more difficult by changing the encryption schemes being used, and also by the size of the key
being used for encryption and decryption.
Another weakness of the SSL encryption is having a session that lasts for too long
(Erkomaa, 1998). In the handshake process a session key is set up between the client and the
server to be used for the duration of the connection. As long as the key remains the same every
time a transmission is sent back and forth, this opens the door for potential break-ins in the
connection. The TLS protocol is actually able to correct this error by having the keys change
within the session.
In addition to the actual communication between the client and the server that opens itself
for attack, is the storage of the data sent to either endpoint. SSL, in transmission is encrypted.
However, because on either end of the connection the message is decrypted, SSL does not have
the feature to remain encrypted in the respective systems cache. Once again, this deteriorates
the security of the connection.
Another issue with the SSL system is its applicability to a worldwide audience. Although
some foreign clients do support the SSL architecture, it has drawbacks with encryption
boundaries. These boundaries were put in place by the United States government and it limits
the amount of bits that can be used in the encryption scheme. Although SSL can support 128-bit
encryption, when used in intercontinental markets, this is reduced to 40-bit encryption (Erkomaa,

SSL and TLS 10

1998). This severely limits the strength of the security, and makes it a little easier for outside
sources to crack the system.
Some say that one of the strongest drawbacks of the SSL system doesnt actually lie in
the handshake protocol portion of the connection (Erkomaa, 1998). The problem lies in the
record layer of the protocol. In the handshake process the authentication between the server and
the client can be very strict, as mentioned before, with certificates and with keys. However, in
the record layer, the authentication seems to be put aside for the remainder of the connection.
With the lack of authentication between the server and the client, this brings about the possibility
of a man-in-the middle attack to masquerade as either ends of the connection.
Many web servers using Apache or IIS are SSL enabled (Blue Coat, 2002). This
security is widespread amongst the Internet community and many institutions have embraced it.
Many believe that SSL is only limited to e-commerce applications, however this is not true.
Financial institutions may use SSL to transmit PIN numbers. Insurance companies use SSL to
transmit client data. Business-to-Business companies use SSL to conduct transactions between
different companies. SSL may also be used within an institution to transmit data across an
intranet, from one part of the company network to another one (Blue Coat, 2002). This last
feature is due to the layer of the network connection that SSL lies in, as mentioned earlier.
Nowadays, a web server can be SSL enabled using Netscapes SSLRef program library, which is
available for commercial or non-commercial usage (Introduction, 1998). However, due to
drawbacks in the encryption technology, there are still servers that cannot support SSL
encryption. Although the idea of encryption is very important, the processing power necessary
to check digital certificates, and key signing is more than many servers can handle. Many web
servers have created bottlenecks in their systems due to this processor demand, and thus have

SSL and TLS 11

created a very slow SSL connection, something that is not widely accepted by consumers or
clients (Blue Coat, 2002).
Today the presence of SSL can be seen in nearly every web browser including the most
popular Netscape Navigator and Internet Explorer. This presence can be seen by two indications
in the browser window. One is the web site itself. In many cases this appears as https as
opposed to the usual http that appears for websites. Another indication of the usage of SSL is
an icon near the bottom of the browser window. This icon is usually a yellow lock, that when
double-clicked, can bring up more information on the usage of SSL in the connection that is
being established. SSL continues to be used prolifically as it is a stable and reliable connection
that provides security to a level that is acceptable by todays standards.

SSL and TLS 12

References

Blue Coat Systems. (2002). SSL Technology and Applications: How to increase performance
and scalability of secure communications over the web. Retrieved from
http://www.bluecoat.com
Erkomaa, Liisa. (1998). Secure Socket Layer and Transport Layer Security. Helsinki University
of Technology.
Netscape Communications Corporation. (1998). Introduction to SSL. Retrieved from
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
Netscape Communications Corporation. (1996). The SSL Protocol Version 3.0. Retrieved from
http://wp.netscape.com/eng/ssl3/draft302.txt.
Thomas, Stephen. (2000). SSL and TLS Essentials: Securing the Web. New York, New York:
Wiley Computer Publishing.