Secure Socket Layer
One of the most widely used security services is the Secure Sockets Layer (SSL) and the follow-on Internet standard
known as Transport Layer Security (TLS).
Tthe latter defined in RFC 5246. SSL is a general-purpose service implemented as a set of protocols that rely on TCP
TLS Architecture
SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is not a single protocol but
rather two layers of protocols, as illustrated in Figure
The SSL Record Protocol provides basic security services to various higherlayer protocols. In particular, the Hypertext
Transfer Protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top
of SSL.
Three higher-layer protocols are defined as part of SSL: the Handshake Protocol, The Change Cipher Spec Protocol,
and the Alert Protocol.
Two important SSL concepts are the SSL session and the SSL connection
Connection: A connection is a transport (in the OSI layering model definition) that provides a suitable type of service.
For SSL, such connections are peer-to-peer relationships. The connections are transient. Every connection is
associated with one session.
Session: An SSL session is an association between a client and a server. Sessions are created by the Handshake
Protocol. Sessions define a set of cryptographic security parameters which can be shared among multiple
connections.Sessions are used to avoid the expensive negotiation of new security parameters for each connection.
A session state is defined by the following parameters.
• Session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
• Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.
• Compression method: The algorithm used to compress data prior to encryption.
• Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm (such as
MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the hash_size.
1
• Master secret: 48-byte secret shared between the client and the server.
• Is resumable: A flag indicating whether the session can be used to initiate new connections.
A connection state is defined by the following parameters.
• Server and client random: Byte sequences that are chosen by the server and client for each connection.
• Server write MAC secret: The secret key used in MAC operations on data sent by the server.
• Client write MAC secret: The secret key used in MAC operations on data sent by the client.
• Server write key: The secret encryption key for data encrypted by the server and decrypted by the client.
• Client write key: The symmetric encryption key for data encrypted by the client and decrypted by the server.
• Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each
key. This field is first initialized by the SSL Handshake Protocol. Thereafter, the final ciphertext block from each
record is preserved for use as the IV with the following record.
• Sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages for
each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number
is set to zero. Sequence numbers may not exceed 264 - 1.
How Does TLS Work
Established by the Internet Engineering Task Force (IETF), TLS uses encryption for the client and server to generate a
secure connection between the applications. It begins when users access a secured website by specifying the TLS
encryption method like the advanced encryption standard (AES).
It works with two security layers – the TLS record protocol and the TLS handshake protocol. These protocols use
symmetric and asymmetric cryptography methods to secure data transfer and communications between the clients
and web servers.
The TLS handshake protocol, for example, uses asymmetric cryptography to generate public and private keys that
encrypt and decrypt data. Then, the overall process is as follows:
The client sends a list of all TLS versions along with suggestions for a cipher suite and generates a random number
that will be used later.
The server confirms which options it will use to initiate the connection.
The server sends a TLS certificate to the client for the authentication process.
After validating the certificate, the client creates and sends a pre-master key encrypted by the server’s public key
and decrypted by the server’s private key.
The client and server generate session keys using the previously generated random numbers and the pre-master
key.
Both the client and server have a finished message that has been encrypted with a session key.
The TLS handshake process is finished, and both the client and server have created secure symmetric encryption.
Handshake Protocol
2
The most complex part of SSL is the Handshake Protocol. This protocol allows the server and client to authenticate
each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data
sent in an SSL record.
The Handshake Protocol is used before any application data is transmitted. The Handshake Protocol consists of a
series of messages exchanged by client and server. All of these have the format shown in Figure 17.5c. Each message
has three fields:
• Type (1 byte): Indicates one of ten messages.
• Length (3 bytes): The length of the message in bytes.
• Content (# 0 bytes): The parameters associated with this message;
Phase 1. Establish Security Capabilities This phase is used to initiate a logical connection and to establish the security
capabilities that will be associated with it.
The exchange is initiated by the client, which sends a client_hello message with the following parameters:
• Version: The highest SSL version understood by the client.
• Random: A client-generated random structure consisting of a 32-bit timestamp and 28 bytes generated by a secure
random number generator. These values serve as nonces and are used during key exchange to prevent replay
attacks.
• Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to update the
parameters of an existing connection or to create a new connection on this session. A zero value indicates that the
client wishes to establish a new connection on a new session.
3
• CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported by the client, in
decreasing order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm
and a CipherSpec;
Compression Method: This is a list of the compression methods the client supports.
The first element of the CipherSuite parameter is the key exchange method (i.e., the means by which the
cryptographic keys for conventional encryption and MAC are exchanged). The following key exchange methods are
supported.
Rsa: The secret key is encrypted with the receiver’s RSA public key. A public- key certificate for the receiver’s key
must be made available.
• Fixed Diffie-Hellman: This is a Diffie-Hellman key exchange in which the server’s certificate contains the Diffie-
Hellman public parameters signed by the certificate authority (CA).
Following the definition of a key exchange method is the CipherSpec, which includes the following fields.
• CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 3DES, DES40, IDEA, or Fortezza
• MACAlgorithm: MD5 or SHA-1
• CipherType: Stream or Block
Phase 3. Client Authentication and Key Exchange Upon receipt of the server_done message, the client should verify
that the server provided a valid certificate (if required) and check that the server_hello parameters are acceptable. If
all is satisfactory, the client sends one or more messages back to the server.
If the server has requested a certificate, the client begins this phase by sending a certificate message. If no suitable
certificate is available, the client sends a no_certificate alert instead.
Phase 4. Finish This phase completes the setting up of a secure connection. The client sends a change_cipher_spec
message and copies the pending CipherSpec into the current CipherSpec. Note that this message is not considered
part of the Handshake Protocol but is sent using the Change Cipher Spec Protocol. The client then immediately sends
the finished message under the new algorithms, keys, and secrets. The finished message verifies that the key
exchange and authentication processes were successful.
Master Secret Creation The shared master secret is a one-time 48-byte value (384 bits) generated for this session by
means of secure key exchange. The creation is in two stages. First, a pre_master_secret is exchanged. Second, the
master_secret is calculated by both Parties
Record Protocol
the record protocol uses symmetric encryption to generate unique session keys for each connection during the
handshake process. It also adds all data exchanged with a hash-based message authentication code (HMAC) to verify
the data authenticity.
Now, TLS is becoming a standard practice for most modern browsers and other applications, where it serves three
purposes:
Encryption. It hides the data transferred from third parties through encoded information.
Authentication. TLS connection ensures both parties’ identities are who they claim to be by providing a certificate.
4
Integrity. Finally, it verifies that the data transmitted has not been forged or tampered with during the delivery
process.
SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
• Confidentiality: The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL
payloads.
• Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message
authentication code (MAC).
Figure 17.3 indicates the overall operation of the SSL Record Protocol.
The Record Protocol takes an application message to be transmitted, fragments the data into manageable blocks,
optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits the resulting unit in a TCP
segment.
Received data are decrypted, verified, decompressed, and reassembled before being delivered to higher-level users.
Change Cipher Spec Protocol
The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol, and it is
the simplest. This protocol consists of a single message (Figure 17.5a), which consists of a single byte with the value
1. The sole purpose of this message is to cause the pending state to be copied into the current state, which updates
the cipher suite to be used on this connection.
5
Alert Protocol
The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with other applications that use SSL,
alert messages are compressed and encrypted, as specified by the current state.
What Is TLS?
Transport Layer Security (TLS) is a cryptographic protocol that secures the connection between a web server and a
web application using data encryption. It applies to all data exchanged over the network, including emails, web
browsing sessions, and file transfers. As a result, hackers cannot access users’ sensitive data like login credentials and
credit card numbers.
TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL. TLS is defined as
a Proposed Internet Standard in RFC 5246. RFC 5246 is very similar to SSLv3.
Version Number
The TLS Record Format is the same as that of the SSL Record Format (Figure 17.4), and the fields in the header have
the same meanings. The one difference is in version values. For the current version of TLS, the major version is 3 and
the minor version is 3.
Message Authentication Code
There are two differences between the SSLv3 and TLS MAC schemes: the actual algorithm and the scope of the MAC
calculation. TLS makes use of the HMAC algorithm
HMAC is defined as
HMACK(M) = H[(K+ _ opad) } H[(K+ _ ipad) } M]]
where
H = embedded hash function (for TLS, either MD5 or SHA-1)
M = message input to HMAC
K+ = secret key padded with zeros on the left so that the result is equal to the block length of the hash code (for MD5
and SHA-1, block length = 512 bits)
ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits)
opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits)
SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the secret key rather than
being XORed with the secret key padded to the block length. The level of security should be about the same in both
cases.
