INFORMATION SECURITY [3 0 0 3]

ICT 3172:
Transport layer security provides end-to-end security services for
applications that use a reliable transport layer protocol such as
TCP.

To provide security services for transactions on the Internet.

.
When a customer shops online, following security services are desired:

1. The customer needs to be sure that the server belongs to the actual vendor,
not an impostor. The customer does not want to give an impostor her credit
card number (entity authentication).

2. The customer and the vendor need to be sure that the contents of the
message are not modified during transmission (message integrity).

3. The customer and the vendor need to be sure that an impostor does not
intercept sensitive information such as a credit card number (confidentiality).

.
Two protocols are dominant today for providing security at the transport layer:

• Secure Sockets Layer (SSL) Protocol

• Transport Layer Security (TLS) Protocol.

The latter is actually an IETF version of the former.

position of SSL and TLS in the Internet model.

.
One of the goals of these protocols is to provide server and client
authentication, data confidentiality, and data integrity.

If the server and client are capable of running SSL (or TLS) programs, then the
client can use the URL https://… instead of http://… to allow HTTP messages to
be encapsulated in SSL (or TLS) packets.

Credit card numbers can be safely transferred via the Internet.

.
17.1 SSL ARCHITECTURE

SSL is designed to provide security and compression services to data generated

from the application layer.

SSL can receive data from any application layer protocol, but usually HTTP.

Data received from the application is compressed (optional), signed, and

encrypted.

The data is then passed to a reliable transport layer protocol such as TCP.

Netscape developed SSL in 1994. Versions 2 and 3 were released in 1995.

Here discuss SSLv3.

.
Services

SSL provides several services on data received from the application layer.

Fragmentation : First, SSL divides the data into blocks of 214 bytes or less.

Compression : Each fragment of data is compressed using one of the lossless

compression methods negotiated between the client and server.
This service is optional.

Message Integrity: To preserve the integrity of data, SSL uses a keyed-hash function to
create a MAC.

Confidentiality: To provide confidentiality, the original data and the MAC are encrypted
using symmetrickey cryptography.

Framing : A header is added to the encrypted payload. The payload is then passed to a
reliable transport layer protocol.

.
Key Exchange Algorithms

To exchange an authenticated and confidential message, the client and the server each
need six cryptographic secrets (4 keys and 2 initialization vectors).

To create these secrets, one pre-master secret must be established between 2 parties.

SSL defines six key-exchange methods to establish this premaster secret:

.
NULL

There is no key exchange in this method.

No pre-master secret is established between the client and the server.

.
RSA

In this method, the pre-master secret is a 48-byte random number created by the client,
encrypted with the server’s RSA public key, and sent to the server.

The server needs to send its RSA encryption/decryption certificate.

.
Anonymous Diffie-Hellman

Simplest and most insecure method.

Pre-master secret is established between client and server using Diffie-Hellman (DH) protocol.
The Diffie- Hellman half-keys are sent in plaintext.
It is called anonymous Diffie-Hellman because neither party is known to the other.
Most serious disadvantage of this method is the man-in-the-middle attack.

.
Ephemeral Diffie-Hellman
To thwart the man-in-the-middle attack, ephemeral Diffie-Hellman key exchange can be used.
Each party sends a Diffie-Hellman key signed by its private key.
The receiving party needs to verify the signature using the public key of the sender.

Public keys for verification are exchanged using either RSA or DSS digital signature
certificates.

.
Fixed Diffie-Hellman

All entities in a group can prepare fixed Diffie-Hellman parameters (g and p).

Then each entity can create a fixed Diffie-Hellman half-key (g x).

For additional security, each individual half-key is inserted into a certificate verified by a
certification authority (CA).

In other words, the two parties do not directly exchange the half-keys; the CA sends the half-
keys in an RSA or DSS special certificate.

When the client needs to calculate the pre-master, it uses its own fixed half-key and the
server half-key received in a certificate.

The server does the same, but in the reverse order.

No key-exchange messages are passed in this method; only certificates are exchanged.

.
Fortezza

Fortezza (derived from the Italian word for fortress) is a registered trademark of the U.S.
National Security Agency (NSA).

It is a family of security protocols developed for the Defense Department.

.
Encryption/Decryption Algorithms

There are several choices for the encryption/decryption algorithm.

All block protocols use an 8-byte initialization vector (IV) except for Fortezza, which uses a
20-byte IV.

.
Hash Algorithms

SSL uses hash algorithms to provide message integrity (message authentication).

.
Cipher Suite
The combination of key exchange, hash, and encryption algorithms defines a cipher suite
for each SSL session.

Table 17.1 shows the suites used in the United States.

.
Cipher Suite

Each suite starts with the term “SSL” followed by the key exchange algorithm.

The word “WITH” separates the key exchange algorithm from the encryption and hash
algorithms. For example,

defines DHE_RSA (ephemeral Diffie-Hellman with RSA digital signature) as the key exchange with
DES_CBC as the encryption algorithm and SHA as the hash algorithm.

Note that DH is fixed Diffie-Hellman, DHE is ephemeral Diffie-Hellman, and DH-anon is anonymous Diffie-
Hellman.

.
Compression Algorithms

Compression is optional in SSLv3. No specific compression algorithm is defined for SSLv3.

Therefore, the default compression method is NULL.

However, a system can use whatever compression algorithm it desires.

.
Cryptographic Parameter Generation

To achieve message integrity and confidentiality, SSL needs 6 cryptographic secrets (4

keys and 2 IVs. )

The client needs one key for message authentication (HMAC), one key for encryption, and
one IV for block encryption. The server needs the same.

The parameters are generated using the following procedure:

1. The client and server exchange two random numbers; one is created by the client and
the other by the server.

2. The client and server exchange one pre-master secret using one of the key exchange
algorithms we discussed previously.

.
Cryptographic Parameter Generation

3. A 48-byte master secret is created from the pre-master secret by applying two hash
functions (SHA-1 and MD5), as shown in Figure 17.8.

.
Cryptographic Parameter Generation

4. The master secret is used to create variable-length key material by applying the same
set of hash functions and prepending with different constants as shown in Figure 17.9.
The module is repeated until key material of adequate size is created.

Note that the length of the key material block depends on the cipher suite selected and the
size of keys needed for this suite.
.
Cryptographic Parameter Generation

5. Six different keys are extracted from the key material, as shown in Figure 17.10

.
Sessions and Connections

SSL differentiates a connection from a session.

A session is an association between a client and a server.

After a session is established, the two parties have common information such as the
session identifier, the certificate authenticating each of them (if necessary), the compression
method (if needed), the cipher suite, and a master secret that is used to create keys for
message authentication encryption.

A session can consist of many connections.

.
Sessions and Connections

.
Sessions and Connections

Session State

A session is defined by a session state, a set of parameters established between the

server and the client.

.
Sessions and Connections

Connection State
A connection is defined by a connection state, a set of parameters established between
two peers.

.
17.2 FOUR PROTOCOLS

SSL defines four protocols in two layers.

.
17.2 FOUR PROTOCOLS

Record Protocol carries messages from 3 other protocols as well as the data coming
from the application layer.

The Handshake Protocol provides security parameters for the Record Protocol.
• It establishes a cipher set and provides keys and security parameters.
• Authenticates the server to the client and the client to the server if needed.

ChangeCipherSpec Protocol is used for signalling the readiness of cryptographic secrets.

The Alert Protocol is used to report abnormal conditions.

.
17.2 FOUR PROTOCOLS
Handshake Protocol

Uses messages to negotiate the cipher suite, to authenticate the server to the client and
the client to the server if needed, and to exchange information for building the
cryptographic secrets.

The handshaking is done in four phases.

.
Handshake Protocol

Phase I: Establishing Security Capability

Client and the server announce their security capabilities and choose those that are
convenient for both.

In this phase, a session ID is established and the cipher suite is chosen.

Two random numbers are selected, one by the client and one by the server, to be used for
creating a master secret.

Two messages are exchanged in this phase: ClientHello and ServerHello messages.

.
 17.2 FOUR PROTOCOLS
Handshake Protocol

ClientHello
The client sends the ClientHello message. It contains the following:
a. The highest SSL version number the client can support.
b. A 32-byte random number (from the client) that will be used for master secret generation.
c. A session ID that defines the session.
d. A cipher suite that defines the list of algorithms that the client can support.
e. A list of compression methods that the client can support .

.
17.2 FOUR PROTOCOLS
Handshake Protocol

ServerHello
The server responds to the client with a ServerHello message. It contains the following:
a. An SSL version number. This number is the lower of two version numbers: the highest
supported by the client and the highest supported by the server.
b. A 32-byte random number (from the server) that will be used for master secret generation.
c. A session ID that defines the session.
d. The selected cipher set from the client list.
e. The selected compression method from the client list.

.
17.2 FOUR PROTOCOLS

Handshake Protocol

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase II: Server Key Exchange and Authentication
In phase II, the server authenticates itself if needed.
The sender may send its certificate, its public key, and may also request certificates from
the client.
At the end, the server announces that the serverHello process is done.

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase II: Server Key Exchange and Authentication

Certificate If it is required, the server sends a Certificate message to authenticate itself. The message
includes a list of certificates of type X.509. The certificate is not needed if the key-exchange algorithm is
anonymous Diffie-Hellman.

ServerKeyExchange After the Certificate message, the server sends a ServerKey- Exchange message
that includes its contribution to the pre-master secret. This message is not required if the key-exchange
method is RSA or fixed Diffie-Hellman.

CertificateRequest The server may require the client to authenticate itself. In this case, the server
sends a CertificateRequest message. The server cannot request a certificate from the client if it is using
anonymous Diffie-Hellman.

ServerHelloDone The last message is the ServerHelloDone message, which is a signal to the client that
Phase II is over and that the client needs to start Phase III.

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase II: Server Key Exchange and Authentication

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase II: Server Key Exchange and Authentication

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase III: Client Key Exchange and Authentication

Phase III is designed to authenticate the client.

Up to three messages can be sent from the client to the server, as shown in Figure 17.17.

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase III: Client Key Exchange and Authentication

Certificate To certify itself to the server, the client sends a Certificate message. This message is sent only
if the server has requested a certificate in Phase II.

ClientKeyExchange After sending the Certificate message, the client sends a Client- KeyExchange
message, which includes its contribution to the pre-master secret. The contents of this message are
based on the key-exchange algorithm used. If the method is RSA, the client creates the entire pre-master
secret and encrypts it with the RSA public key of the server. If the method is anonymous or ephemeral
Diffie-Hellman, the client sends its Diffie-Hellman half-key.

CertificateVerify If the client has sent a certificate declaring that it owns the public key in the certificate, it
needs to prove that it knows the corresponding private key. This is needed to thwart an impostor who
sends the certificate and claims that it comes from the client. The proof of private-key possession is done
by creating a message and signing it with the private key. The server can verify the message with the
public key already sent to ensure that the certificate actually belongs to the client.

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase III: Client Key Exchange and Authentication

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase III: Client Key Exchange and Authentication

.
17.2 FOUR PROTOCOLS
Handshake Protocol
Phase IV: Finalizing and Finishing

In Phase IV, the client and server send messages to change cipher specification and to finish
the handshaking protocol.

Four messages are exchanged in this phase, as shown in Figure 17.19.

.
17.2 FOUR PROTOCOLS
ChangeCipherSpec Protocol

The negotiation of the cipher suite and the generation of cryptographic secrets are formed
gradually during the Handshake Protocol.

The sender and the receiver need two states. One state, the pending state, keeps track of
the parameters and secrets. The other state, the active state, holds parameters and secrets
used by the Record Protocol to sign/verify or encrypt/decrypt messages.

In addition, each state holds two sets of values: read (inbound) and write (outbound).

The ChangeCipherSpec Protocol defines the process of moving values between the
pending and active states.

.
17.2 FOUR PROTOCOLS
ChangeCipherSpec Protocol
Figure 17.20 shows a hypothetical situation, with hypothetical values, to show the concept.
Only a few parameters are shown.
Before the exchange of any ChangeCipherSpec messages, only the pending columns have values.

.
Alert Protocol

SSL uses the Alert Protocol for reporting errors and abnormal conditions.
It has only one message type, Alert message, that describes the problem and its level (warning or fatal).

.
Record Protocol
The Record Protocol carries messages from the upper layer (Handshake Protocol, ChangeCipherSpec
Protocol, Alert Protocol, or application layer).
The message is fragmented and optionally compressed; a MAC is added to the compressed message using
the negotiated hash algorithm.
The compressed fragment and the MAC are encrypted using the negotiated encryption algorithm.
Finally, the SSL header is added to the encrypted message.
Figure 17.21 shows this process at the sender. The process at the receiver is reversed.

.
Record Protocol
This process can only be done when the cryptographic parameters are in the active state.

Fragmentation/Combination
At the sender, a message from the application layer is fragmented into blocks of 214 bytes, with the last
block possibly less than this size. At the receiver, the fragments are combined together to make a
replica of the original message.

Compression/Decompression
At the sender, all application layer fragments are compressed by the compression method
negotiated during the handshaking. The compression method needs to be lossless.

.
17.2 FOUR PROTOCOLS
Record Protocol

Signing/Verifying
At the sender, authentication method defined during the handshake (NULL, MD5, or SHA-1) creates a
signature (MAC).

.
 17.2 FOUR PROTOCOLS

Record Protocol

The hash algorithm is applied twice

First, a hash is created from the concatenations of the following values:

a. The MAC write secret (authentication key for the outbound message)
b. Pad-1, which is the byte 0x36 repeated 48 times for MD5 and 40 times for SHA-1
c. The sequence number for this message
d. The compressed type, which defines the upper-layer protocol that provided the compressed fragment
e. The compressed length, which is the length of the compressed fragment
f. The compressed fragment itself

Second, the final hash (MAC) is created from the concatenation of the following values:
a. The MAC write secret
b. Pad-2, which is the byte 0x5C repeated 48 times for MD5 and 40 times for SHA-1
c. The hash created from the first step

At the receiver, the verifying is done by calculating a new hash and comparing it to the received hash.

.
17.2 FOUR PROTOCOLS
Record Protocol

Encryption/Decryption
At the sender, the compressed fragment and the hash are encrypted using the cipher write
secret.
At the receiver, the received message is decrypted using the cipher read secret

Framing/Deframing
After the encryption, the Record Protocol header is added at the sender. The header is
removed at the receiver before decryption.

.
 17.3 SSL MESSAGE FORMATS

The Record Protocol has a general header that is added to each message coming from the
sources.

Protocol. This 1-byte field defines the source or destination of the encapsulated
message. It is used for multiplexing and demultiplexing. The values are 20
(ChangeCipherSpec Protocol), 21 (Alert Protocol), 22 (Handshake Protocol), and 23
(data from the application layer).

Version. This 2-byte field defines the version of the SSL; one byte is the major
version and the other is the minor. The current version of SSL is 3.0 (major 3 and
minor 0).

Length. This 2-byte field defines the size . of the message (without the header) in
17.3 SSL MESSAGE FORMATS

ChangeCipherSpec Protocol

ChangeCipherSpec Protocol has one message, the Change-CipherSpec message.

Message is only one byte, encapsulated in the Record Protocol message with protocol
value 20.

The one-byte field in the message is called the CCS and its value is currently 1.

.
17.3 SSL MESSAGE FORMATS

Alert Protocol

The Alert Protocol, has one message that reports errors in the process.

The two fields of the Alert message are listed below.

Level. This one-byte field defines the level of the error. Two levels have been defined so far: warning and
fatal.
Description. The one-byte description defines the type of error.

.
17.3 SSL MESSAGE FORMATS

Handshake Protocol
Several messages have been defined for the Handshake Protocol.

All of these messages have the four-byte generic header.

The figure shows the Record Protocol header and the generic header for the Handshake Protocol.

.
17.3 SSL MESSAGE FORMATS

Handshake Protocol
Type. This one-byte field defines the type of message. Ten types are

Length (Len). This 3-byte field defines the length of the message (excluding the length of the type
and length field).
Need two length fields, one in the general Record header and one in the generic header for the
Handshake messages : Record message may carry two Handshake messages at the same time if
there is no need for another message in between.

.
17.3 SSL MESSAGE FORMATS

Handshake Protocol

HelloRequest Message

The HelloRequest message, which is rarely used, is a request from the server to the client to restart a
session.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

ClientHello Message
The ClientHello message is the first message exchanged during handshaking.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

ServerHello Message
The ServerHello message is the server response to the ClientHello message. The format is
similar to the ClientHello message, but with fewer fields.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

ServerHello Message

The version field is the same. The server random number field defines a value selected by
the server.

The session ID length and the session ID field are the same as those in the ClientHello
message.

However, the session ID is usually blank (and the length is usually set to 0) unless the
server is resuming an old session.

In other words, if the server allows a session to resume, it inserts a value in the session ID
field to be used by the client (in the ClientHello message) if the client wishes to reopen an
old session.

The selected cipher suite field defines the single cipher suite selected by the server from
the list sent by the client. The compression method field defines the method
selected by the server from the list sent by the client.

.
 17.3 SSL MESSAGE FORMATS
Handshake Protocol
Certificate Message
Certificate message can be sent by the client or the server to list the chain of
publickey certificates.

Certificate Chain Length. This three-byte field shows the length of the
certificate chain.

Certificate Chain. This variable-length field lists the chain of public-key

certificates that the client or the server carries. For each certificate, there are
two sub-fields:
a. A three-byte length field
b. The variable-size certificate itself .
17.3 SSL MESSAGE FORMATS
Handshake Protocol

ServerKeyExchange Message
The ServerKeyExchange message is sent from the server to the client.

The message contains the keys generated by the server. The format of the message is
dependent on the cipher suite selected in the previous message. The client that receives
the message needs to interpret the message according to the previous information.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

CertificateRequest Message
The CertificateRequest message is sent from the server to the client.
The message asks the client to authenticate itself to the server using one of the acceptable
certificates and one of the certificate authorities named in the message.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

CertificateRequest Message

Len of Cert Types. This one-byte field shows the length of the certificate
types.
Certificates Types. This variable-length field gives the list of the public-key
certificate types that the server accepts. Each type is one byte.
Length of CAs. This two-byte field gives the length of the certificate
authorities .
Length of CA x Name. This two-byte field defines the length of the xth
certificate authority name. The value of x can be between 1 to N.
CA x Name. This variable-length field defines the name of the xth certificate
authority. The value of x can be between 1 to N.
.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

ServerHelloDone Message
The ServerHelloDone message is the last message sent in the second phase of
handshaking. The message signals that phase II does not carry any extra information.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

CertificateVerify Message

The CertificateVerify message is the last message of Phase III. In this message, the client proves that it
actually owns the private key related to its public-key certificate. To do so, the client creates a hash of all
handshake messages sent before this message, and signs them using the MD5 or SHA-1 algorithm
based on the certificate type of the client.

If the client private key is related to a DSS certificate, then the hash is based only on the SHA-1
algorithm and the length of the hash is 20 bytes. If the client private key is related to an RSA
certificate, then there are two hashes (concatenated), one based on MD5 and the other based on
SHA-1. The total length is 16 + 20 = 36 bytes. Figure 17.35 shows the hash calculation.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

ClientKeyExchange Message
The ClientKeyExchange is the second message sent during the third phase of
handshaking. In this message, the client provides the keys.

The format of the message depends on the specific key exchange algorithms selected by
two parties.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

Finished Message
The Finished message shows that the negotiation is over. It contains all of the
messages exchanged during handshaking, followed by the sender role, the
master secret, and the padding. The exact format depends on the type of cipher
suite used.

.
17.3 SSL MESSAGE FORMATS
Handshake Protocol

Finished Message
Figure 17.37 shows that there is a concatenation of two hashes in the message.
Figure 17.38 shows how each is calculated.

Note that when the client or server sends the Finished message, it has already
sent the ChangeCipherSpec message. In other words, the write cryptographic
secrets are in the active state. The client or the server can treat the Finished
message like a data fragment coming from the application layer. The Finished
message can be authenticated (using the MAC in the cipher suite) and
encrypted (using the encryption algorithm. in the cipher suite).
17.3 SSL MESSAGE FORMATS

Application Data
The Record Protocol adds a signature (MAC) at the end of the (possibly compressed)
fragment coming from the application layer and then encrypts the fragment and the MAC.

After adding the general header with protocol value 23, the Record message is transmitted.
Note that the general header is not encrypted.

.
17.4 TRANSPORT LAYER SECURITY

Transport Layer Security (TLS) protocol is the IETF standard version of the SSL protocol.

The two are very similar, with slight differences.

Discuss: differences between TLS and SSL protocols.

.
17.4 TRANSPORT LAYER SECURITY

Version

The first difference is the version number (major and minor).

The current version of SSL is 3.0; the current version of TLS is 1.0. In other words,
SSLv3.0 is compatible with TLSv1.0.

TLS 1.3

.
17.4 TRANSPORT LAYER SECURITY

Cipher Suite
Another minor difference between SSL and TLS is the lack of support for the Fortezza
method.

TLS does not support Fortezza for key exchange or for encryption/decryption.

.
17.4 TRANSPORT LAYER SECURITY

Generation of Cryptographic Secrets

• The generation of cryptographic secrets is more complex in TLS than in SSL.

• TLS first defines two functions: the data-expansion function and the,
pseudorandom function.

.
17.4 TRANSPORT LAYER SECURITY
Generation of Cryptographic Secrets

Data-Expansion Function
Data-expansion function uses a predefined HMAC (MD5 or SHA-1) to expand a secret into a longer one.
This function can be considered a multiple section function, where each section creates one hash value.
The extended secret is the concatenation of the hash values.
Each section uses two HMACs, a secret and a seed.
The data-expansion function is the chaining of as many sections as required.
To make the next section dependent on the previous, the second seed is actually the output of the first
HMAC of the previous section.

.
17.4 TRANSPORT LAYER SECURITY
Generation of Cryptographic Secrets

Pseudorandom Function (PRF)

TLS defines a pseudorandom function (PRF) to be the combination of two data-expansion functions, one
using MD5 and the other SHA-1.
PRF takes three inputs, a secret, a label, and a seed.

The label and seed are concatenated and serve as the seed for each data expansion function.
The secret is divided into two halves; each half is used as the secret for each data-expansion function.

The output of two data-expansion functions is exclusive ored together to create the final expanded
secret.

Because the hashes created from MD5 and SHA-1 are of different sizes, extra sections of MD5-based
functions must be created to make the two outputs the same size.

.
17.4 TRANSPORT LAYER SECURITY

Pre-master Secret

The generation of the pre-master secret in TLS is exactly the same as in SSL.

.
17.4 TRANSPORT LAYER SECURITY

Master Secret

TLS uses the PRF function to create the master secret from the pre-master secret.

This is achieved by using the pre-master secret as the secret, the string “master secret” as
the label, and concatenation of the client random number and server random number as
the seed.

.
17.4 TRANSPORT LAYER SECURITY

Key Material

TLS uses the PRF function to create the key material from the master secret.

This time the secret is the master secret, the label is the string “key expansion”, and the
seed is the concatenation of the server random number and the client random number.

.
17.4 TRANSPORT LAYER SECURITY

Alert Protocol

TLS supports all of the alerts defined in SSL except for NoCertificate.

TLS also adds some new ones to the list. Table 17.7 shows the full list of alerts supported
by TLS.

.
17.4 TRANSPORT LAYER SECURITY

Alert Protocol

.
17.4 TRANSPORT LAYER SECURITY

Handshake Protocol

TLS has made some changes in the Handshake Protocol.

Specifically, the details of the CertificateVerify message and the Finished message have
been changed.

CertificateVerify Message
In SSL, the hash used in the CertificateVerify message is the two-step hash of the
handshake messages plus a pad and the master secret.
TLS has simplified the process. Hash in the TLS is only over the handshake messages.

.
17.4 TRANSPORT LAYER SECURITY

Handshake Protocol

Finished Message
The calculation of the hash for the Finished message has also been changed.

TLS uses the PRF to calculate two hashes used for the Finished message.

.
17.4 TRANSPORT LAYER SECURITY

Record Protocol

The only change in the Record Protocol is the use of HMAC for signing the message.
TLS uses the MAC to create the HMAC. TLS also adds the protocol version (called
Compressed version) to the text to be signed.
Figure 17.46 shows how the HMAC is formed.

.
END