The Secure Socket Layer (SSL) protocol, objectives, architecture, session and connection.

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 Secure Socket Layr (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.

Figure 1 SSL between application protocols and TCP/IP

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:

1. the protocol to ensure data security and integrity: this layer is composed of the SSL Record Protocol,
2. 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 Figure 2.

Figure 2 The SSL protocol stack

SSL uses these protocols to address the tasks as described above. The SSL record protocol is responsible for data encryption and integrity. As can be seen in Figure 2, it is also used to encapsulate data sent by other SSL protocols, and therefore, it is also involved in the tasks associated with the SSL check data. The other three protocols cover the areas of session management, cryptographic parameter management and transfer of SSL messages between the client and the server. Prior to going into a more detailed discussion of the role of individual protocols and their functions let us describe two fundamental concepts related to the use of SSL.

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.

The abbreviation MAC used in the above definitions means Message Authentication Code that is used for transmission of data during the SSL session. The role of MAC will be explained further when discussing the record protocols. A brief description of the terms was necessary to be able to explain the next issues connected with the functioning of the SSL protocol, namely the SSL record protocol.

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.

MAC is responsible for the verification of integrity of the message included in the transmitted record. It is the result of a hash function that follows a specific hash algorithm, for example MD5 or SHA-1. MAC is determined as a result of a hash function that receives the following data:
MAC = Hash function [secret key, primary data, padding, sequence number].
A secret key in creation of MAC is either a client write MAC secret or a server write MAC secret respectively, it depends on which party prepares the packet. After receiving the packet, the receiving party computes its own value of the MAC and compares it with that received. If the two values match, this means that data has not been modified during the transmission over the network. The length of the MAC obtained in this way depends on the method uses for its computing. Next, the data plus the MAC are encrypted using a preset symmetric encryption algorithm, for example DES or triple DES. Both data and MAC are encrypted. This prepared data is attached with the following header fields:

• Content type: identifies what payload is delivered by the packet to determine which higher protocols are to be used for processing of data included in the packet. The possible values are change_cipher_spec, alert, handshake, and application_data that refer to the appropriate protocols.
• Major version : establishes the main portion of the protocol version to be used. For SSL 3.0, the value is 3,
• Minor version : establishes the additional portion of the used version of the protocol. For SSL 3.0 the value is 0.

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 3.

Figure 3. Creating a packet under SSL record protocol

The SSL Record protocol
The SSL record protocol is used to transfer any data within a session - both messages and other SSL protocols (for example the handshake protocol), as well as for any application data.

The Alert Protocol
The Alert Protocol is used by parties to convey session messages associated with data exchange and functioning of the protocol. Each message in the alert protocol consists of two bytes. The first byte always takes a value, “warning” (1) or “fatal” (2) , that determines the severity of the message sent. Sending a message having a „fatal” status by either party will result in an immediate termination of the SSL session. The next byte of the message contains one of the defined error codes, which may occur during an SSL communication session.

The ChangeCipher Spec protocol
This protocol is the simplest SSL protocol. It consists of a single message that carries the value of 1. The sole purpose of this message is to cause the pending session state to be established as a fixed state, which results, for example, in defining the used set of protocols. This type of message must be sent by the client to the server and vice versa. After exchange of messages, the session state is considered agreed. This message and any other SSL messages are transferred using the SSL record protocol.

The handshake protocol
The handshake protocol constitutes the most complex part of the SSL protocol. It is used to initiate a session between the server and the client. Within the message of this protocol, various components such as algorithms and keys used for data encryption are negotiated. Due to this protocol, it is possible to authenticate the parties to each other and negotiate appropriate parameters of the session between them.
The process of negotiations between the client and the server is illustrated in Figure 4. It can be divided into 4 phases separated with horizontal broken lines. During the first phase, a logical connection must be initiated between the client and the server followed by the negotiation on the connection parameters. The client sends the server a client_hello message containing data such as:

• Version: The highest SSL version supported by the client,
• 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, in response to the client_hello message sends a server_hello message, containing the same set of fields as the client message, placing the following data:
• 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.

The set of encryption algorithms and key exchange method sent in the CipherSuite field establishes three components:

1. the method of key exchange between the server and client,
2. the encryption algorithm for data encryption purposes,
3. a function used for obtaining the MAC value.

The server begins the next phase of negotiations by sending its certificate to the client for authentication. The message sent to the client contains one or a chain of X509 certificates. These are necessary for authentication of both the server and the certification path towards a trusted certification official of the certificating body for the server. This step is not obligatory and may be omitted, if the negotiated method of key exchange does not require sending the certificate (in the case of anonymous Diffie-Hellman method). Depending on the negotiated method of key exchange, the server may send an additional server_key_exchange message, which is however not required in the case when the fixed Diffie-Hellman method or RSA key exchange technique has been negotiated. Moreover, the server can request a certificate from the client. The final step of Phase 2 is the server_done message, which has no parameters and is sent by the server merely to indicate the end of the server messages. After sending this message, the server waits for a client response. Upon receipt of the message, the client should verify the server’s certificate, the certificate validation data and path, as well as any other parameters sent by the server in the server_hello message. The client’s verification consists of:

• Validation date check of the certificate and comparison with the current date, to verify whether the certificate is still valid,
• checking whether the certifying body is included in the list of trusted Certifying Authorities in possession of the client. If the CA, which has issued the server’s certificate is not included in the CAs list, the client attempts to verify the CA signature. If no information about the CA can be obtained, the client terminates the identification procedure by either returning the error signal or signalling the problem for the user to solve it.
• Identifying the authenticity of the public key of the CA which has issued the certificate: if the Certifying Authority is included in the client’s list of trusted CAs, the client checks the CA’s public key stated in the server’s certificate with the public key available from the list. This procedure verifies the authenticity of the certifying body.
• checking whether the domain name used in the certificate matches the server name shown in the server’s certificate.

Upon successful completion of all steps the server is considered authenticated. If all parameters are matched and the server’s certificate correctly verified, the client sends the server one or multiple messages. Next is the client__key_exchange message, which must be sent to deliver the keys. The content of this message depends on the negotiated method of key exchange. Moreover, at the server’s request, the client’s certificate is sent along with the message enabling verification of the certificate. This procedure ends Phase 3 of negotiations.

Phase 4 is to confirm the messages so far received and to verify whether the pending data is correct. The client sends a change_cipher_spec message (in accordance with the pending SSL ChangeCipher Spec), and then sets up the pending set of algorithm parameters and keys into the current set of the same. Then the client sends the finished message, which is first protected with just negotiated algorithms, keys and secrets. This is to confirm that the negotiated parameters and data are correct. The server in response to the client sends the same message sequence. If the finished message is correctly read by either party this confirms that the transmitted data, negotiated algorithms and the session key are correct. This indicates that the session has been terminated and that it is possible to send the application data between the server and the client, via SSL. At this point the TCP session between the client and the server is closed, however a session state is maintained, allowing it to resume communications within the session using the retained parameters.

It is worth noticing that both Phases 2 and 3 are used by both parties to verify the authenticity of the server’s certificate and possibly the client’s certificate during the handshake step. If the server cannot be successfully authenticated by the client on the basis of the delivered certificate, the handshake terminates and the client will generate an error message. The same will occur at the server if the client’s certificate authenticity cannot be confirmed.
Figure 4 Establishing the SSL session between the client and the server (red coloured – messages that are non-mandatory).

At first glance this process seems to be somewhat complicated, however this takes place at each connection with the server of an SSL-enabled service, for example while requesting the address of a site beginning with HTTPS://.


SSL in practice.

What hat 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.

Table 1: The numbers of ports of some SSL-based services

Port Service
HTTPS 443
LDAP 646
NNTP 563
SMTP 465
POP3 995
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”.

Both the documents illustrate the TLS implementation using HTTP protocol to substitute the Secure Sockets Layer technique utilised so far. They demonstrate, among others, a method of using a TLS secured HTTP connection with no need to employ any additional port for encrypted connections in contrast to SSL protocol. An encrypted TLS connection is initiated by employing a standard HTTP port. The RFC 2487 document on “SMTP Service Extension for Secure SMTP over TLS” that defines a manner to establish a secure SMTP connection using a standard port and protocol extensions is the next example of the application specification for TLS.

Today, TLS is supported by parts of both server and client software. The Internet Explorer browser, for example, supports SSL. Notwithstanding this, SSL is currently the most frequently used method to provide security for Internet communications, however it is predicted that it will be replaced by TLS which will become a recognized security standard for Internet transmission services.

For protocol specifications, see also:

http://www.netscape.com/eng/security/SSL_2.html –SSL 2.0 Specification,
http://www.netscape.com/eng/ssl3/3-SPEC.HTM – SSL 3.0 Specification,
http://www.ietf.org/html.charters/tls-charter.html,
http://www.ietf.org/rfc.html –RFC documents.
http://www.netscape.com/eng/security/SSL_2.html –SSL 2.0 Specification
http://www.netscape.com/eng/ssl3/3-SPEC.HTM – SSL 3.0 Specification

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog: