The Secure Socket Layer (SSL) is a suite of protocols that is a standard way to achieve a good level of security between a web browser and a website. SSL is designed to create a secure channel, or tunnel, between a web browser and the web server, so that any information exchanged is protected within the secured tunnel. SSL provides authentication of clients to server through the use of certificates. Clients present a certificate to the server to prove their identity.
Security of data in transit over the Internet becomes increasingly necessary because of steadily growing data volume and importance. Nowadays, every user of a public network sends various types of data, from email to credit card details daily, and he would therefore like them to be protected when in transit over a public network. To this end, a practical SSL protocol has been adopted for protection of data in transit that encompasses all network services that use TCP/IP to support typical application tasks of communication between servers and clients.
The SSL protocol was originally developed by Netscape, to ensure security of data transported and routed through HTTP, LDAP or POP3 application layers. SSL is designed to make use of TCP as a communication layer to provide a reliable end-to-end secure and authenticated connection between two points over a network (for example between the service client and the server). Notwithstanding this SSL can be used for protection of data in transit in situations related to any network service, it is used mostly in HTTP server and client applications. Today, almost each available HTTP server can support an SSL session, whilst IE or Netscape Navigator browsers are provided with SSL-enabled client software.
Figure1:- SSL between application protocols and TCP/IP
3.5.1. SSL objectives and architecture
Which problems does SSL target? The main objectives for SSL are:
- Authenticating the client and server to each other: the SSL protocol supports the use of standard key cryptographic techniques (public key encryption) to authenticate the communicating parties to each other. Though the most frequent application consists in authenticating the service client on the basis of a certificate, SSL may also use the same methods to authenticate the client.
- Ensuring data integrity: during a session, data cannot be either intentionally or unintentionally tampered with.
- Securing data privacy: data in transport between the client and the server must be protected from interception and be readable only by the intended recipient. This prerequisite is necessary for both the data associated with the protocol itself (securing traffic during negotiations) and the application data that is sent during the session itself.
SSL is in fact not a single protocol but rather a set of protocols that can additionally be further divided in two layers:
- The protocol to ensure data security and integrity: this layer is composed of the SSL Record Protocol,
- The protocols that are designed to establish an SSL connection: three protocols are used in this layer: the SSL Handshake Protocol, the SSL ChangeCipher SpecPprotocol and the SSL Alert Protocol.
The SSL protocol stack is illustrated in Figure1.
Figure 2: The SSL protocol stack
3.5.2. SSL session and connection
The concepts as mentioned above are fundamental for a connection between the client and the server, and they also encompass a series of attributes. Let’s try to give some more details:
- Connection: this is a logical client/server link, associated with the provision of a suitable type of service. In SSL terms, it must be a peer-to-peer connection with two network nodes.
- Session: this is an association between a client and a server that defines a set of parameters such as algorithms used, session number etc. An SSL session is created by the Handshake Protocol that allows parameters to be shared among the connections made between the server and the client, and sessions are used to avoid negotiation of new parameters for each connection.
This means that a single session is shared among multiple SSL connections between the client and the server. In theory, it may also be possible that multiple sessions are shared by a single connection, but this feature is not used in practice. The concepts of a SSL session and connection involve several parameters that are used for SSL-enabled communication between the client and the server. During the negotiations of the handshake protocol, the encryption methods are established and a series of parameters of the Session State are subsequently used within the session. A session state is defined by the following parameters: - session identifier: this is an identifier generated by the server to identify a session with a chosen client,
- Peer certificate: X.509 certificate of the peer,
- compression method: a method used to compress data prior to encryption,
- Algorithm specification termed CipherSpec: specifies the bulk data encryption algorithm (for example DES) and the hash algorithm (for example MD5) used during the session,
- Master secret: 48-byte data being a secret shared between the client and server,
- “is resumable”: this is a flag indicating whether the session can be used to initiate new connections.
According to the specification, the SSL connection state is defined by the following parameters: - Server and client random: random data generated by both the client and server for each connection,
- Server write MAC secret: the secret key used for data written by the server,
- Client write MAC secret: the secret used for data written by the client,
- Server write key: the bulk cipher key for data encrypted by the server and decrypted by the client,
- Client write key: the bulk cipher key for data encrypted by the client and decrypted by the server,
- Sequence number: sequence numbers maintained separately by the server for messages transmitted and received during the data session.
3.5.3. The SSL Record Protocol
The SSL record protocol involves using SSL in a secure manner and with message integrity ensured. To this end it is used by upper layer SSL protocols. The purpose of the SSL record protocol is to take an application message to be transmitted, fragment the data which needs to be sent, encapsulate it with appropriate headers and create an object just called a record, which is encrypted and can be forwarded for sending under the TCP protocol. The first step in the preparation of transmission of the application data consists in its fragmentation i.e. breaking up the data stream to be transmitted into 16Kb (or smaller) data fragments followed by the process of their conversion in a record. These data fragments may be further compressed, although the SSL 3.0 protocol specification includes no compression protocol, thus at present, no data compression is used.
At this moment, creation of the record is started for each data portion by adding a header to it, possible information to complete the required data size and the MAC. The record header that is added to each data portion contains two elementary pieces of information, namely the length of the record and the length of the data block added to the original data.
In the next step, the record data constructed consists of the following elements:
- primary data,
- some padding to complete the datagram as required,
- MAC value
- primary data,
- some padding to complete the datagram as required,
- MAC value.
With the addition of fields, the process of record preparation is completed. Afterwards, the record is sent to the targeted point. The entire process of preparation of the packet to be sent is illustrated in Figure 2
Figure 3. Creating a packet under SSL record protocol
3.5.4. SSL in practice
What is the reason for these complicated things associated with an SSL connection? SSL is used in many services but mostly SSL protects the HTTP communication channel over the Internet and therefore the SSL protocol is seen quite often as associated only with WWW pages. As it has been already mentioned, the SSL protocol can be used to protect the transmission for any TCP/IP service. Apart from the WWW accessing, the second most likely application of this protocol is associated with email sending and receiving.
As for Windows NT/2000/XP applications, SSL is practically used in the system of HTTP and SMTP server services that work in conjunction with IIS. These servers allow an appropriate request to be generated with the user’s own certificate (employing the Windows 2000 Server certificate services) or by obtaining the certificate from one of the trusted CAs such as VeriSign (www.verisgn.com) or Thawte (www.thawte.com). For a description of installation of the certificate for a WWW server working in conjunction with IIS browse www.faq.net.pl/article.asp?id=237. In the same manner as for the WWW server it is possible to obtain and install the certificate on an SMTP server supplied along with IIS or available in Exchange 2000. A possible application of the SSL to support other services depends on the possibility of configuration of such a connection by the server.
Figure 4: Establishing the SSL session between the client and the server (red coloured – messages that are non-mandatory).
| Port Service | |
| Protocol | Port Number |
| HTTPS | 443 |
| LDAP | 646 |
| NNTP | 563 |
| SMTP | 465 |
| POP3 | 995 |
Table 2: The numbers of ports of some SSL-based services
3.5.5. TSL: getting more from the SSL
In 1996 the IETF task force attempted to develop an Internet’s standardised secure method to communicate over the web. They adopted the SSL 3.0 as the starting point and in 1999 released the document RFC 2246 that defined the new Transport Layer Security (TLS) protocol in its version 1.0. The basic goal placed by the task force to be achieved through TLS, was similar to that associated with SSL’s standards, namely to provide security and data integrity features at the transport layer between two web applications. Moreover, some additional features have been added to TSL by the designers:
- Interoperability: an attitude of TLS towards the construction of TSL-enabled applications and exchange of TLS parameters by either party, with no need for the other party to know the TLS implementation’s details.
- Expandability: TLS is seen as a means to provide a framework for easy future extensions to be built in new cryptographic technologies, based, however, on the same protocols notwithstanding the changes made to the cryptographic protocols.
Both TLS and its predecessor SSL consist of two fundamental protocol layers: - TLS Record Protocol: it performs the same role as the SSL record protocol does, namely it is used to provide security and integrity for data sent during the client/server session,
- TLS Handshake Protocol: to negotiate connection parameters; it performs the same function as the SSL handshake previously described.]
TLS has been developed as a base used by application layer protocols that are layered on top of the TLS protocol. The specification provided in RFC 2246 does not define, however, how these top layer protocols should use TLS to protect transmissions. The TLS task force set out to resolve this problem by the designers of applications and protocols involved. Apart from developing the protocol specification itself, IETF has developed two additional RFC documents:
- RFC 2817 “Upgrading to TLS within HTTP/1.1”,
- RFC 2818 “HTTP Over TLS”.