1.0
Introduction
As increasing amounts of sensitive information like credit card numbers are being transmitted
over the Internet, World Wide Web security has become critically important. For this reason,
today, many companies use Secure Sockets Layer (SSL) to protect their information from an
unauthorised party and reduce the risks of the data being exposed on the Internet.
SSL is a protocol developed in 1994 by Netscape Communications Corporation that encrypts
your data to provide security during the transmission of sensitive data over a TCP/IP
connection. It lies between your web browser and the Internet (see figs 1.1 & 1.2).
Figure 1.1
Figure 1.2
The word "socket" refers to the method used to pass data back and forth between your
browser and a web server. SSL has become the most popular security protocol used among
many people. The two major browsers, Netscape and Internet Explore support SSL 3.0, the
current version of SSL.
Why do we need SSL?
Without the proper controls, your data is subject to several types of attacks.
You are in danger of :
Loss of privacy - without encryption, every message sent may be read by an
unauthorised party.
Loss of data integrity - your data maybe modified by third party.
Identity Spoofing - The practice of making a transmissions appear to come from an
authorised user. For example, in IP spoofing, a transmission is given the IP address of
an authorised user in order to obtain access to a computer or network. Because many
security systems today rely on IP addresses to uniquely identify users, your computer
may lead to numerous break-ins.
Denial of Service - over the last several years attackers have found deficiencies in the
TCP/IP protocol suite that allows them to arbitrarily cause computer systems to crash.
To reduce these risks, a number of industry leading companies and organisations choose SSL
protocol for their Internet security. SSL provides for companies the means for making safe
electric commerce on the Internet.
Overview of SSL Procedure:
When the web server gets information from your web browser (such as through a form
submitting credit card information), the information is encrypted by the web browser using
the server's public key. The encryption is done in the background without any interaction
from the user. SSL uses an algorithm from RSA Data Security Inc. for public-key encryption.
Once this data is encrypted, it can't be decrypted unless the private key is known. This is what
makes data transmissions secure.
Different key sizes work best with different cryptographic algorithms but in general the larger
the size of the Private Key the more secure the SSL enabled application will be. After the
Private Key is securely shared the client and server use the Private Key to create a different
set of keys called Session Keys. These keys are used with a specified cryptographic algorithm
to encrypt and decrypt the contents of the communication session.
The Session Keys are only ever valid for a single communications session.
MessageType
Direction
Data Transferred
client-hello
server-hello
C>S
C<S
client-master-key
C>S
client-finish
server-verify
C>S
C<S
server-finish
C<S
challenge-data, cipher-specs
connection-id, servercertificate, cipher-specs
cipher-kind, clear-master-key,
{secret-master-key}serverpublic-key
{connection-id}client-write-key
{challenge-data}server-writekey
{session-id}server-write-key
SSL in Action
An SSL connection is initiated by the client (normally a Web browser) by requesting a
document to be sent through the HTTPS protocol as opposed to the standard HTTP protocol.
This is done by simply prefixing the URL by "https" as opposed to "http". For example:
http://server.domain.com/index.html
requests the document index.html be sent through the standard HTTP protocol, whilst
https://server.domain.com/index.html
requests the same document be sent using the HTTPS protocol which incorporates SSL.
How secure is it?
To compromise the security of SSL you have to be able to find or guess the key for a given
session. For the types of key sizes used guessing is almost impossible. To find the correct key
you would have to systematically and exhaustively search for every possible key until you
found one that allowed you to decrypt the particular communications session.
Because the keys are valid for only one session, the exhaustive search would produce a key
that was only good for decrypting one session. This means you have to randomly choose one
communications session from the millions transversing the Internet and hope that it contains
information valuable enough to justify the time, effort and money it would take to
compromise the session.
2.0
How SSL works
2.1 - Transmitting Data Privately
SSL uses encryption and decryption to ensure that data is transmitted privately. It works on the
public-and-private key encryption system from RSA. The web server contains a private and public
key "signed" by a Certificate Authority. The public key is used to encrypt data, but it can only be
decrypted using the private key
Public (Asymmetric) key encryption
Public key encryption uses a key pair made up of a public and a private key. The keys are
mathematically linked; that is, data encrypted with one key in the pair can only be decrypted
using the other key in the pair. The public key can be distributed and made generally
available. The private key is kept private.
A web server and web browser use public key encryption when first establishing
communications with each other. Specifically, it is used during the SSL handshake when the
web browser authenticates the web server. After the handshake is complete, the web server
and web browser switch to the more efficient symmetric key encryption for the remainder of
the transaction.
Symmetric key encryption
Symmetric key encryption uses a single key. The web browser and the web server create the
key (called a session key) during their initial interaction (the SSL handshake). The same key
is used to both encrypt and decrypt the data. This encryption ensures that no one else can read
the data being transmitted in either direction. A different session key is used for each
server/browser connection, and the session key automatically expires after twenty-four hours.
2.2 - Ensuring the Data Is Not Altered During Transit
SSL uses cryptographic hashing to ensure that no one alters data during transit. Cryptographic
hashing creates a unique hash value based on the content of transmitted data. The content of
the data cannot be determined from the hash value and it is nearly impossible to compose
another message that computes to the same hash value. Both the web server and the web
browser compute hash values using the same hashing algorithm. If the hash values are the
same, the data was not altered.
When sending data to a web browser, the web server computes a hash value for data then
sends the hash value and the data to the web browser. When the web browser receives this
information, it computes its own hash value for the data then compares the two hash values. If
they match, the web browser is assured that the data was not altered during transit. A similar
process occurs when the web browser sends data back to the web server. The web browser
computes a hash value then sends it and the data to the web server. The web server computes
a hash value for the data and compares it to the hash value computed by the web browser.
This process assures web browser users that information they receive from the web server has
not been altered and that information they fill in on an HTML form is not altered before it
reaches the web server.
2.3 - Authenticating the Web Server
SSL uses digitally signed certificates to authenticate the web server, that is, to assure the web
browser that it is communicating with the organisation it thinks it is.
A certificate is a data structure that contains information about the organisation. It also
contains the public key of the organisation’s public/private key pair. Because the certificate
contains the public key, it binds a public/private key pair to the organisation. The key pair is
used for public key encryption during the SSL handshake.
A server certificate is a certificate that attests to the identity of an organisation that owns a
web server. Certificates are issued by certificate authorities such as VeriSign. A certificate
authority is a trusted company or organisation that confirms that an organisation is what it
claims to be.
To obtain a server certificate, an organisation must send a certificate signing request (CSR) to
the certificate authority. After conducting research to ensure the organisation is what it claims
to be, the certificate authority digitally signs the certificate and sends it to the organisation
that requested it.
To create the digital signature, the certificate authority computes a hash value based on the
contents of the certificate.
A hash value is an error-checking value derived from the addition of a set of numbers taken
from data (not necessarily numeric data) that is to be processed or manipulated in some way.
After processing, the hash total is recalculated and compared with the original total. If the two
do not match, the original data has been changed in some way.
The certificate authority then encrypts the hash value with its private key. The digital
signature is the encrypted hash value. The digital signature is stored with the certificate.
When the organisation that requested the certificate receives the certificate, it loads it to its
web server. When an SSL request is made, the web server sends the certificate to the web
browser. When the web browser receives the certificate, it can read the information about the
organisation and its public key.
To validate the certificate to ensure it contains the information digitally signed by the
certificate authority, the web browser verifies the digital signature. Because the digital
signature is an encrypted hash value that was computed based on the contents of the
certificate, the web browser needs to compare hash values. The web browser computes a hash
value based on the contents of the certificate it received. It then decrypts the digital signature
to determine the hash value that the certificate authority computed. If the two hash values
match, the web browser is assured that the certificate contains the information that the
certificate authority verified and digitally signed.
2.4 - The SSL Record Protocol
An SSL record consists of two parts, the header and the data. The header can either be 3 bytes in
length or 2 bytes in length, the latter being employed if there is no padding data. The escape bit is not
used in version 2 of the protocol but it is suggested that it is used to designate Out-Of-Band data in
future versions. For a 2 byte header, the maximum record length is 32767 bytes whereas a 3 byte
header will only allow a record length of up to 16383 bytes.
The data part of the record consists of a Message Authentication Code (MAC), the actual data itself
and padding data, if required. It is the data part of the record which is encrypted in its entirety when
encryption is necessary. Padding data is only required for use with block ciphers. It is used to pad out
the length of the data block to be a multiple of the block size of the cipher. If a stream cipher is used
or the data is already a multiple of the block size, then no padding is required and a 2 byte header
record can be used. The MAC is a hash or message digest of the secret write key of the sending party,
the actual data, the padding data and a sequence number in that order. The sequence number is a 32
bit integer which is incremented after each message is sent.
2.5 - SSL Handshake
The SSL handshake occurs when a web browser user first requests information from a
that is using SSL.
web server
The following is accomplished during the SSL handshake:



The web browser and the web server negotiate the cipher suite they will use for the rest of
the security services.
The web browser authenticates the web server.
The web browser selects and transmits a symmetric key to the web server.
The handshake protocol is composed of two phases.
Phase 1 deals with the selection of a cipher suite, the exchange of a master key and the authentication
of the server.
A cipher suite is made up of three techniques:

Key exchange technique--This is how the web browser and web server will exchange the
symmetric key that will be used for the symmetric encryption that takes place after the
SSL handshake is complete.

Symmetric encryption technique--This is the type of symmetric encryption to be used, for
example, RC2 or RC4.

Hashing technique--This is the type of hashing the web browser and the web server will
use to ensure the data is not altered during transit.
Phase 2 handles client authentication, if requested and finishes the handshaking. After the handshake
stage is complete, the data transfer between client and server begins. All messages during
handshaking and after, are sent over the SSL Record Protocol layer.
To allow the web browser to authenticate the web server, the web server sends its server certificate to
the web browser. The web browser validates the server certificate.
The web browser selects an appropriate symmetric key for the type of symmetric encryption to be
used. It then encrypts the symmetric key using the web server's public key. (The web browser
obtained the web server's public key from the server certificate.) The web browser then sends the
encrypted key to the web server.
Using its private key, the web server decrypts the symmetric key. Now both the web browser and the
web server have a secret key that they will use to send data back and forth. The handshake is
complete.
2.6 - SSL and The ISO Reference Model
It is important that any new communications protocol conform to a standard model if it is to easily
replace or become part of an existing protocol structure. The ISO Reference Model for Open Systems
Interconnection or 7-Layer Model is the most popular abstraction [HAL93].
Figure 2.1
2.7 - Example of an SSL Transaction:
The web browser user enters a URL to access information from a web server that is using SSL, for
example:
1. https://www.company.com:443/
2. The web browser and web server perform the SSL handshake, which consists of the
following steps:

The web server and the web browser negotiate what cipher suite they will use.

The web server sends its certificate. The web browser authenticates the web server
by validating the web server's certificate.
The web browser and web server create the symmetric encryption key that they
will use to send data back and forth privately.

3.
The web server sends the requested data to the web browser by performing these
steps:



4.
Computes the hash value for the data.
Encrypts the data and hash value using the symmetric encryption key.
Sends to the data and hash value to the web browser.
The web browser receives the data and hash value. Then it:




Decrypts the data and hash value.
Creates a hash value for the data.
Compares its hash value to the hash value the web server computed.
Displays the data if the hash values match.
5. The web browser user fills in information on an HTML form and uses the submit button
to return the information to the web server.
6. The web browser sends the HTML form data to the web server by performing these steps:



Computes the hash value for the data.
Encrypts the data and hash value using the symmetric encryption key.
Sends to the data and hash value to the web server.
7. The web server receives the data and hash value. Then it:



Decrypts the data and hash value.
Creates a hash value for the data.
Compares its hash value to the hash value the web browser computed. Continues
processing the request if the hash values match.
The process continues with steps 3-7 until the SSL transaction ends.
3.0 - Strengths of The SSL Protocol
Brute Force Attack Against Strong Ciphers
A brute force attack against the ciphers with 128 bits or more is completely impractical in the
foreseeable future. The only non-export cipher which would be susceptible to this attack is the
standard DES 56 bit cipher - it is not recommended that this cipher be used if at all possible.
Replay Attack
A replay attack is one where a third party records an exchange of messages between a client and
server and attempts to rerun the client messages at the server at a later date. SSL foils this possibility
by introducing a nonce number, this is in the form of the connection-id which the server randomly
generates and sends to the client. Since the nonce differs for each connection, no two connections are
likely to have the same nonce and thus the old set of client messages do not satisfy the server. SSL
nonces are 128 bits in length for added security.
Man-In-The-Middle Attack
The Man-In-The-Middle attack occurs when an adversary is able to intercept client messages read
them and pass them on to the server and vice versa. This attack is prevented by SSL forcing the
server to use its private key to decrypt the master key if it is to continue to handshake with the client.
To be able to do this requires that it has a valid certificate which the client can verify. An adversary
would have to fake a certificate and break the certification authorities key in order to compromise
this chain; a task which is more difficult than doing a brute force attack on the cipher itself.
4.0 - Weaknesses of The SSL Protocol
Brute Force Attack Against Weak Ciphers
The most obvious weakness of the protocol is the susceptibility of the ciphers which use small keys
to brute force attack, in particular RC4-40, RC2-40 and to some extent DES-56. See Section 3.2.4 on
Key Length for time and power requirements to break these ciphers. As has been discussed, this was
a weakness which was forced upon Netscape by US export law. However it remains a serious flaw
and has been exploited several times already. To the best of my knowledge successful brute force
attacks against RC4-40 have been carried out at least five times since the protocol's release in
February 1995.
Renegotiation of Session Keys
In the present situation, once a connection is established, the same session key (master key) is used
throughout. If SSL were layered underneath a long running connection, such as a Telnet application,
then this failure to alter session keys becomes a serious security hole. One of the best methods of
increasing the security of a system such as this is to force renegotiation of the session key at regular
intervals, thus multiplying the difficulty and cost of a brute force attack by the number times the
session key is changed. This could actually be used to increase the security of the export ciphers. If
an adversary were faced with the task of having to decrypt 100,000 records all encrypted using a
different, albeit weak, key rather than the same key, then the task becomes 100,000 times more
difficult.
5.0
Advantages/Disadvantages
Advantages
Privacy
Privacy is given through encryption. Although information can still be intercepted by a third party,
they will be unable to read any information as they have no access to the encryption key.
Integrity
Integrity is also ensured through encryption. If information is received that will not decrypt properly
then the recipient knows that the information has been tampered with during transmission.
Authentication
Authentication is provided through digital certificates.
Large Browser Deployment
Virtually everybody that uses the internet uses a version of either Internet Explorer or Netscape
Navigator. Both browsers support SSL. Therefore potential customers on the Internet don’t need any
software.
Disadvantages
Uncertainty
Many people feel unsafe giving their credit card details over the Internet. This is the biggest problem
e-commerce faces. Even though giving your credit card details over the phone is less secure, there
still exists a perception that using the internet is not safe.
Key Size
SSL is limited to 40 bit keys. Even though it is very difficult to break 40 bit encryption, it is still
possible.
Card Details
Even if the transaction between customer and merchant is secure, the merchant will have the
customer’s credit card details, probably on a database. How safe are these details? Is it possible for
someone to steal them.
6.0 - SSL BUG
Recently a bug has been found with SSL. Inside the script tags, SSL does not generate a warning.
This is also true with the applet tags. This is a potential security hole and could be used to lift data
(including credit card information). Therefore javascript, java applets and other scripts should not be
used with SSL when you require a secure connection. When using the script tags, Internet Explorer
generates a warning. However when using applet tags no warning is generated. Netscape Navigator
doesn’t generate a warning for either script or applet tags.
7.0- Applications
E-commerce
E-commerce is the main application for SSL. As using the internet to buy goods becomes more
popular, so does the need to provide security.
Internet Telephony
Internet telephony not only allows people to make calls across the internet but from the internet(i.e. a
PC) to the PSTN(i.e. a phone). These two networks are joined together by a gateway. When a person
wants to make a call across the internet they will log on to a gateway or server. Hence authentication
is required and therefore security is needed. This is another application that uses SSL.
8.0 - Competing Technologies
There are several alternatives to the SSL protocol. The major alternatives are S-HTTP(secure http)
but others are listed below:





IPSec
S/MIME
SET (Secure Electronic Transfer)
PCT (Private Communication Technology) from Microsoft
Digital Cash
S-HTTP Protocol:
HTTP (Secure HTTP) Protocol is an application-level security designed to provide for message level
and signing and encryption occur on the HTML "document" or form. S-HTTP uses the HTTP
client/server protocol to negotiate security information and allows you to choose the security
specifications you want for each transaction between a client and a server. It provides signatures that
can be archived for later retrieval to support non-repudiation services. The encrypted objects can also
be archived for later decryption. This protocol only supports for HTTP; therefore, the users of this
protocol is limited.
IPSec Protocol:
IPSec (IP Security) Protocol ensures secure private communications over IP networks. IPSec
provides IP network-layer encryption and authenticity to information transferred across IP networks.
IPSec parameters between two devices, are negotiated with the Internet KeyExchange (IKE). IKE
can use digital certificates for device authentication to enable the creation of large encryption
networks. It allows security to be embedded at the network layer. IPSec implements network layer
encryption and authentication providing an end-to-end security solution in the network architecture
itself. Thus the end systems and applications do not need any changes to have the advantage of strong
security.
S/MIME Protocol:
S/MIME Protocol works similarly to the S-HTTP. S/MIME is designed to provide for message level
signing digitally and encryption operations primarily in the context of store-and-forward applications
such as electronic mail. S/MIME enables users of web messaging client software such as Netscape
Messenger to send encrypted messages and authenticate received messages. S/MIME delivers
message encryption and authentication with the flexibility, interoperability, and cost-effectiveness of
web-based messaging.
SET (Secure Electronic Transactions):
SET is a security protocol developed by Visa and Mastercard for enabling secure credit card
transactions on the internet. It is exempt from US cryptographic export restrictions and unlike SSL
can use 128 bit encryption. SSL is limited to 40 bit encryption. This is a big advantage for SET over
SSL because while 40 bit encryption is very difficult to break, 128 bit encryption is almost
impossible to break. However in order for SET to be allowed use 128 bit encryprion, the use of 128
bit encryption has to be limited to financial information only and does not include other details of the
transaction such as delivery address, goods being purchased.
Like SSL, SET allows for the merchant’s identity to be authenticated via digital certificates.
However, SET also allows for the merchant to request users to authenticate themselves through
digital certificates. This makes it much more difficult for someone to use a stolen credit card.
In a typical SET transaction, there is information that is private between the customer and the
merchant (such as the items being ordered) and other information that is private between the
customer and the bank (such as the customer’s credit card number). SET allows both kinds of private
information to be included in a single, digitally signed transaction. Information intended for the bank
is encrypted using the bank’s public key while information for the merchant is encrypted with the
merchant’s public key. This means that the merchant has no access to the credit card details and thus
a source of fraud is elimated. This is another advantage that SET has over SSL.
Despite the advantages SET has over SSL, it is not as widely used mainly because it is very
expensive.
PCT (Private Communication Technology):
The PCT protocol is a security protocol from Microsoft. It is similar to SSL except in the way that it
deals with verification and in the design of its handshake phase. The PCT protocol does not deal with
the verification of certificates. Instead it assumes that protocol implementations have access to a
“black box”. It is this “black box” that authenticates a server to client and vice versa. PCT has not
really taken off. SSL is still the main application in internet security.
Digital Cash:
When a consumer signs up with a bank that supports Digital Cash, they receive “purse” software to
install. This software allows you to download electronic coins to your hard disk. It is also responsible
for managing your coins. When you buy coins, they are charged against your bank account or credit
card. When you buy something from a Web Store using digital cash, the store’s software generates a
payment request, describing the merchandise, price, the time and the date. You can then accept or
reject this request. If you accept, your purse software subtracts the required amount from your purse
and creates a payment that is sent to your bank, verified, and then deposited to the merchant’s
account. This all happens within a few seconds. The merchant is notified and ships the goods.
Digital cash is in operation and is predicted to become a popular form of payment. As purchasing on
the internet begins to grow people may feel more secure using Digital Cash as credit card numbers
are not passed across the internet. The money you use to buy electronic coins will not leave your
bank. However when using SSL, there is no need for the customer to purchase any software.
9.0 - Future
RSA Data Security plans to sell a Secure Sockets Layer implementation tool kit called BSafe SSL-C
through it’s new Australian subsidiary opened in January this year. BSafe SSL-C was built from
scratch in Australia by relying on textbook descriptions of the RSA algorithm and the
IETF’s(Internet Engineering Task Force) description of SSL. Because Bsafe SSL-C was developed
outside U.S. without any help from the parent company, it is exempt from U.S. encryption export
laws. Therefore 128 bit encryption keys could soon be available.
SSL is the dominant application for e-commerce. Most Web Stores use SSL for security. While there
are other alternatives out there, SSL is the most widely used security application. With 128 bit
encryption soon to be available, SSL will be around for a few more years. In the future it is unlikely
SSL will be completely replaced. It will probably be combined with other applications/technologies
to produce a better product.