Transport layer security



Network security approaches

At which layer should we provide security?
Quite a difficult question.






Secure sockets layer (SSL) and Transport Layer Secuity (TLS)


They are a family of protocols that were originally designed to provide security for HTTP transactions, but that also can be used for a variety of other Internet protocols such as IMAP and NNTP. HTTP running over SSL is referred to as secure HTTP .You specify that you want to connect to a server using SSL by replacing http with https in the protocol component of a URI. The default port for HTTP over SSL is 443.

SSL achieves confidentiality via encryption, integrity via message authentication codes, and authentication via certificates and digital signatures.

Is it SSL or TLS?

SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security.

Netscape released SSLv2 in 1994 and SSL version 3 in 1995. TLS is an IETF standard designed to standardize SSL as an Internet protocol. It is just a modification of SSLv3 with a small number of added features and minor cleanups. It identifies itself as SSLv3.1. The TLS acronym is the result of arguments between Microsoft and Netscape over the naming of the protocol because each company proposed its own name. A summary of the differences between SSLv3 and TLS is at the end of this page.

Secure Socket Layer (SSL)

SSL was originated by Netscape in 1995.  SSL version 3.0 was released in 1996, which later served as the basis for TLS version 1.0, an IETF standard protocol first defined in RFC 2246 in January 1999. The bulk of this section is devoted to a discussion of SSLv3. At the end of the section, the key differences between SSLv3 and TLS are described.


Handshake Protocol

This protocol allows the server and client to

The handshake protocol is used before any application data is transmitted.

It establishes a session.



The Handshake Protocol consists of a series of messages exchanged by client and server, in four phases.




Phase 1. Establish Security Capabilities
Phase 2. Server authentication and key exchange
Phase 3. Client authentication and key exchange
Phase 4. Finish


Phase 1. Establish Security Capabilities


Key exchange method

The method that will be used to establish the pre-master secret.



Phase 2. Server Authentication and Key Exchange

When a signature is needed, the signed value is 
     hash(ClientHello.random || ServerHello.random || ServerParams)


Phase 3. Client Authentication and Key Exchange



Generating the keys




Phase 4. Finish


Role of the Finish phase


Transporting data with SSL


Two important SSL concepts are the SSL session and the SSL connection, which are defined in the specification as follows:


SSL Record Protocol

The SSL Record Protocol provides two services for SSL connections, thanks to the shared keys defined by the handshake protocol.






The message authentication code is defined as follows:

hash(MAC_write_secret || pad_2 ||
    hash(MAC_write_secret || pad_1|| seq_num ||SSL Compressed.type ||
          SSLCompressed.length || SSLCompressed.fragment))

Where

hash

=

cryptographic hash algorithm; either MD5 or SHA-1

pad_1

=

the byte 0x36 (0011 0110) repeated 48 times (384 bits) for MD5 and 40 times (320 bits) for SHA-1

pad_2

=

the byte 0x5C (0101 1100) repeated 48 times for MD5 and 40 times for SHA-1

seq_num

=

the sequence number for this message

SSLCompressed.type

=

the higher-level protocol used to process this fragment

SSLCompressed.length

=

the length of the compressed fragment

SSLCompressed.fragment

=

the compressed fragment (if compression is not used, the plaintext fragment)

Note that this is very similar to the HMAC algorithm defined in Chapter 9. The difference is that the two pads are concatenated in SSLv3 and are XORed in HMAC. The SSLv3 MAC algorithm is based on the original internet draft for HMAC, which used concatenation. The final version of HMAC, defined in RFC 2104, uses the XOR.

Next, the compressed message plus the MAC are encrypted using symmetric encryption.

The final step of SSL Record Protocol processing is to prepend a header, consisting of the following fields:

•

Content Type (8 bits): The higher-layer protocol used to process the enclosed fragment.
•

Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.
•

Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.
•

Compressed length (16 bits): The length in bytes of the plaintext fragment (or compressed fragment if compression is used). The maximum value is 214 1 2048.

The content types that have been defined are change_cipher_spec, alert, handshake, and application_data. The first three are the SSL-specific protocols, discussed next. Note that no distinction is made among the various applications (e.g., HTTP) that might use SSL; the content of the data created by such applications is opaque to SSL.


 

Alert Protocol

This protocol is used to report errors

Examples


It is also used for other purposes
Examples


Transport Layer Security

TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL. The current draft version of TLS is very similar to SSLv3. In this section, we highlight the differences.

Version Number

The TLS Record Format is the same as that of the SSL Record Format, and the fields in the header have the same meanings. The one difference is in version values. For the current draft of TLS, the Major Version is 3 and the Minor Version is 1.

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 defined in RFC 2104. HMAC is defined as follows:

HMACK_K ( M )  =  H[ (K+ XOR opad) || H[ (K+ XOR 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.

For TLS, the MAC calculation encompasses the fields indicated in the following expression:

HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type || 
          TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment))

The MAC calculation covers all of the fields covered by the SSLv3 calculation, plus the field TLSCompressed.version, which is the version of the protocol being employed.

Pseudorandom Function

TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for purposes of key generation or validation. The objective is to make use of a relatively small shared secret value but to generate longer blocks of data in a way that is secure from the kinds of attacks made on hash functions and MACs. The PRF is based on the following data expansion function (Figure 14.7):

     P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) ||
                            HMAC_hash(secret, A(2) || seed) ||
                            HMAC_hash(secret, A(3) || seed) || . . .

where A() is defined as

A(0)

=

seed

A(i)

=

HMAC_hash(secret, A(I-1))

The data expansion function makes use of the HMAC algorithm, with either MD5 or SHA-1 as the underlying hash function. As can be seen, P_hash can be iterated as many times as necessary to produce the required quantity of data. For example, if P_SHA-1 was used to generate 64 bytes of data, it would have to be iterated four times, producing 80 bytes of data, of which the last 16 would be discarded. In this case, P_MD5 would also have to be iterated four times, producing exactly 64 bytes of data. Note that each iteration involves two executions of HMAC, each of which in turn involves two executions of the underlying hash algorithm.




To make PRF as secure as possible, it uses two hash algorithms in a way that should guarantee its security if either algorithm remains secure. PRF is defined as

PRF(secret, label, seed) = P_MD5(S1, label || seed) Å P_SHA-1(S2, label || seed)

PRF takes as input a secret value, an identifying label, and a seed value and produces an output of arbitrary length. The output is created by splitting the secret value into two halves (S1 and S2) and performing P_hash on each half, using MD5 on one half and SHA on the other half. The two results are exclusive-ORed to produce the output; for this purpose, P_MD5 will generally have to be iterated more times than P_SHA to produce an equal amount of data for input to the exclusive-OR function.

Alert Codes

TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate. A number of additional codes are defined in TLS; of these, the following are always fatal:

•

decryption_failed: A ciphertext decrypted in an invalid way; either it was not an even multiple of the block length or its padding values, when checked, were incorrect.
•

record_overflow: A TLS record was received with a payload (ciphertext) whose length exceeds 214 + 2048 bytes, or the ciphertext decrypted to a length of greater than 214 1 1024 bytes.
•

unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA.
•

access_denied: A valid certificate was received, but when access control was applied, the sender decided not to proceed with the negotiation.
•

decode_error: A message could not be decoded because a field was out of its specified range or the length of the message was incorrect.
•

export_restriction: A negotiation not in compliance with export restrictions on key length was detected.
•

protocol_version: The protocol version the client attempted to negotiate is recognized but not supported.
•

insufficient_security: Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client.
•

internal_error: An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue.

The remainder of the new alerts are the following:

•

decrypt_error: A handshake cryptographic operation failed, including being unable to verify a signature, decrypt a key exchange, or validate a finished message.
•

user_canceled: This handshake is being canceled for some reason unrelated to a protocol failure.
•

no_renegotiation: Sent by a client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these messages would normally result in renegotiation, but this alert indicates that the sender is not able to renegotiate. This message is always a warning.

Cipher Suites

There are several small differences between the cipher suites available under SSLv3 and under TLS:

•

Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the exception of Fortezza.
•

Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms found in SSLv3, with the exception of Fortezza.

Client Certificate Types

TLS defines the following certificate types to be requested in a certificate_ request message: rsa_sign, dss_sign, rsa_fixed_dh, and dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes rsa_ephemeral_dh, dss_ephemeral_ dh, and fortezza_kea. Ephemeral Diffie-Hellman involves signing the Diffie-Hellman parameters with either RSA or DSS; for TLS, the rsa_sign and dss_sign types are used for that function; a separate signing type is not needed to sign Diffie-Hellman parameters. TLS does not include the Fortezza scheme.

Certificate_Verify and Finished Messages

In the TLS certificate_verify message, the MD5 and SHA-1 hashes are calculated only over handshake_messages. Recall that for SSLv3, the hash calculation also included the master secret and pads. These extra fields were felt to add no additional security.

As with the finished message in SSLv3, the finished message in TLS is a hash based on the shared master_secret, the previous handshake messages, and a label that identifies client or server. The calculation is somewhat different. For TLS, we have

     PRF(master_secret, finished_label, MD5(handshake_messages) || SHA-
                               1(handshake_messages))

where finished_label is the string "client finished" for the client and "server finished" for the server.

Cryptographic Computations

The pre_master_secret for TLS is calculated in the same way as in SSLv3. As in SSLv3, the master_secret in TLS is calculated as a hash function of the pre_master_secret and the two hello random numbers. The form of the TLS calculation is different from that of SSLv3 and is defined as follows:

master_secret =
     PRF(pre_master_secret, "master secret", ClientHello.random || ServerHello.random)

The algorithm is performed until 48 bytes of pseudorandom output are produced. The calculation of the key block material (MAC secret keys, session encryption keys, and IVs) is defined as follows:

key_block =
          PRF(master_secret, "key expansion",
               SecurityParameters.server_random  || SecurityParameters.client_random)

until enough output has been generated. As with SSLv3, the key_block is a function of the master_secret and the client and server random numbers, but for TLS the actual algorithm is different.

Padding

In SSL, the padding added prior to encryption of user data is the minimum amount required so that the total size of the data to be encrypted is a multiple of the cipher's block length. In TLS, the padding can be any amount that results in a total that is a multiple of the cipher's block length, up to a maximum of 255 bytes. For example, if the plaintext (or compressed text if compression is used) plus MAC plus padding.length byte is 79 bytes long, then the padding length, in bytes, can be 1, 9, 17, and so on, up to 249. A variable padding length may be used to frustrate attacks based on an analysis of the lengths of exchanged messages.


Problems

14.1 In SSL and TLS, why is there a separate Change Cipher Spec Protocol, rather than including a change_cipher_spec message in the Handshake Protocol?

14.2 Consider the following threats to Web security and describe how each is countered by a particular feature of SSL.

1.

Brute-Force Cryptanalytic Attack: An exhaustive search of the key space for a conventional encryption algorithm.

2.

Known-Plaintext Dictionary Attack: Many messages will contain predictable plaintext, such as the HTTP GET command. An attacker constructs a dictionary containing every possible encryption of the known-plaintext message. When an encrypted message is intercepted, the attacker takes the portion containing the encrypted known plaintext and looks up the ciphertext in the dictionary. The ciphertext should match against an entry that was encrypted with the same secret key. If there are several matches, each of these can be tried against the full ciphertext to determine the right one. This attack is especially effective against small key sizes (e.g., 40-bit keys).

3.

Replay Attack: Earlier SSL handshake messages are replayed.

4.

Man-in-the-Middle Attack: An attacker interposes during key exchange, acting as the client to the server and as the server to the client.

5.

Password Sniffing: Passwords in HTTP or other application traffic are eavesdropped.

6.

IP Spoofing: Uses forged IP addresses to fool a host into accepting bogus data.

7.

IP Hijacking: An active, authenticated connection between two hosts is disrupted and the attacker takes the place of one of the hosts.

8.

SYN Flooding: An attacker sends TCP SYN messages to request a connection but does not respond to the final message to establish the connection fully. The attacked TCP module typically leaves the "half-open connection" around for a few minutes. Repeated SYN messages can clog the TCP module.

14.3 Based on what you have learned in this chapter, is it possible in SSL for the receiver to reorder SSL record blocks that arrive out of order? If so, explain how it can be done. If not, why not?