Secure Socket Layer (SSL)

Secure Socket Layer (SSL)

Introduction

As we all know security is a very important aspect of computer applications. This is very evident in e-commerce applications, which want to ensure easy access to its site but provide authentication and data security for transactions. A solution to this problem was developed by Netscape in their development of their first Internet browser [1][2][3], Secure Sockets Layers (SSL). Secure Socket Layers are widely implemented and SSL is now the de facto standard for providing secure ecommerce transactions over the Web [1].

Background

While developing their first Web Browser, Netscape realized that secure connections between clients and servers were necessary for the Internet to be a successful business tool. They decided that the best was to maintain this security was to encrypt and decrypt data transactions. Instead of integrating this encryption into their browser they developed a generic, non-HTTP, protocol called Secure Socket Layers (SSL). Netscape developed SSL to sit on top of TCP (Transmission Control Protocol), thus providing a TCP-like interface to upper-layer applications, as Figure 1 shows [1].

Figure 1: SSL operates above the transport layer to provide application-independent Security [1] After the development of SSL, MicroSoft and other vendors began creating their own transport security protocols, the Internet Engineering Task Force (IETF) intervened to define a standard for an encryption-layer protocol. Along with the input of many vendors, the IETF created TLS, the Transport Layer Security standard. This was based on SSL 3.0 and is often referred to as SSL 3.1. Although there are only small differences between TLS and SSL, they are not interoperable as TSL needs some encryption algorithms that SSL doesn’t. A TLS server can still interact with a SSL 3.0 client; it just has to “back down” to SSL 3.0 first.

How SSL Works

There is two parts to SSL, the handshake phase and the data transfer phase. The handshake protocol is the most complex part of SSL protocol [2]. During this phase, the server and client use a public-key encryption algorithm to negotiate secret-key parameters. At the conclusion of the handshake phase the secret keys will be know and will be used to encrypt and decrypt data transmissions in the data transfer phase. The client initiates an SSL handshake connection by first transmitting a client_hello message this contains information such as [2]:

• Version: The highest SSL version the client supports,
• Random Data: consisting of a 32-bit timestamp and 28 bytes of randomly generated data. This data is used to protect the key exchange session between the parties of the connection.
• Session ID: a number that defines the session identifier. A nonzero value of this field indicates that the client wishes to update the parameters of an existing connection or establish a new connection on this session. A zero value in this field indicates that the client wishes to establish a new connection.
• CipherSuite: a list of encryption algorithms and key exchange method supported by the client.

The server, responses to the client_hello message by sending a server_hello message, containing the same set of fields as the client message [2]:

• Version: the lowest version number of the SSL protocol supported by the server,
• Random Data: the same fashion as used by the client, but the data generated is completely independent,
• Session ID: if the client field was nonzero, the same value is sent back; otherwise the server’s session ID field contains the value for a new session,
• CipherSuite: the server uses this field to send a single set of protocols selected by the server from those proposed by the client. The first element of this field is a chosen method of exchange of cryptographic keys between the client and the server. The next element is the specification of encryption algorithms and hash functions, which will be used within the session being initiated, along with all specific parameters.

If the negotiated method of key exchange requires it, the server will send a certificate proving its identity to the client, this is followed by a server_done message which represents the end of the server messages. When the client receives the certificate it checks the authenticity of it and can look up the chain of certificates to make sure it comes from a reliable source. The certificate also contains the server’s public key, which the client can check against the list of keys it received earlier. Using this public key, the client encrypts a random number which can only be decrypted using the server’s private key, therefore keeps it safe, it sends this to the server and uses it itself to pass to a function along with the client_random and server_random random numbers that were obtained from the random data section of the hello messages. This function produces the master_key. This master_key along with the client_random and server_random are used to generate the secret key and the MAC key. On receipt of the client key, the server decrypts the message using is private key and then follows the same procedure as the client to acquire the secret and MAC keys. The client sends a change_cipher_specification message which just carries the value 1[2][3] and tells the other party that all their following messages will be encrypted with the secret key. The client then sends a handshake_finished message, representing that they are ready to enter the data transfer phase. The Server also sends a change_cipher_specification message and a handshake_finished message which concludes the handshake phase and the connection enters the data transfer phase.

SSL in Practice

SSL is used in a lot of different services but is mainly used to protect the HTTP communication channel over the Internet. It can however be used to protect the transmission for any TCP/IP service. Besides WWW accessing, SSL is widely associated with email sending and receiving. Before SSL 3.0, SSL 2.0 was the de facto standard for cryptographic protection of Web http traffic [4]. But SSL 2.0 had many limitations and was vulnerable to a wide range of attacks, such as Man-in-the-Middle downgrade attacks, truncate attacks and rollback attacks[3][4] . SSL 3.0 does well to plug up most of these holes but exposes itself to some new attacks such as, change cipher spec-dropping, KeyExchangeAlgorithm-spoofing, and version rollback. Fortunately these are relatively easy to fix in implementation [4]. In general SSL 3.0 provides robust security against active attacks as well as improving message integrity and a number of non-security aspects of SSL. SSL 3.0 is a valuable step toward practical communications security for Internet applications [4] which is improved upon by the continuing development of TLS.  

Bibliography

1. Chou, W. (2002) Inside SSL: the secure sockets layer protocol. IT Professional, 4 (4), 47-52
2. Onyszko, T. Secure Socket Layer. (July 22, 2004). Available: http://www.windowsecurity.com/articles/secure_socket_layer.html [Retrieved: 10/9/08]
3. Transport Layer Security. Available: http://en.wikipedia.org/wiki/Secure_Sockets_Layer [Retrieved: 10/9/08]
4. Wagner, D.; Schneier, B. (1996) Analysis of the SSL 3.0 protocol The Second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press.