A

Seminar Report
ON

“Transport Layer Security”

Submitted as a requirement for the partial fullfillment of degree of
Bachelor of Technology
In
Information Technology
Under
Rajasthan Technical University, Kota

Session: 2010-2011

Submitted To: Submitted By:

Mr. Nitesh chouhan Abhishek Jha
Assistant Professor,IT Dept. 07E1MBITM40P002

M.L.V.Textile & Engineering College.

(An Autonomous Engineering College of Govt. Of Rajasthan)
Bhilwara 311001 (Rajasthan), India.
 Preface

Engineering is the science of economy for conserving the energy and potential provided. Engi-
neering is the professional art of applying science to the optimum conversion of natural resources to
the benefit of man.It is the business of engineering to utilize this energy to the best advantage so
that there may be the least possible waste of time.To bridge the gap of theory and practical and to
provide a solution for it practical knowledge is very necessary.

Seminar is an exposure of students for their personality development. This is the best time for the
students who want to prove themselves. It is only possible when one has a burning desire in his heart
to achieve something. It train us to be aware,co-operative and creative, which will surely help us
in future. It also enhances our reasoning power and sense of expressing our thoughts in better and
effective way as well as it sharpens our minds. Without it the course would not have any true sense.

To make the learning of engineering more fruitful, We, the students of Manikya Lal Verma Textile
& Engineering College,Bhilwara, present a seminar on a topic to increase the understandibility and
knowledge about the topic. The seminar on “Transport Layer Security” is the backbone for ”OSI”
model which provides the most important feature that is security while transporting the data from
one node to another.

Abhishek Jha

i
 Acknowledgement

Gratitude is the most exquisite form of courtesy. Life without thankfulness is devoid of love and
passion. Hope without thankfulness is lacking in fine percption. Faith without thankfulness lacks
strenght and fortitude. The beatitude, bliss and euphoria that accompany the successful completion
of any task would not be complete without the expression of appreciation of simple virtues to the
people who made it possible. So with reverence, veneration honour, I ackhowledge all those whose
guidance and encouragement have made successful in winding up this.

First and foremost, I would like to thank Professor(Dr.)G.K.Tyagi (Principal - M.L.V.T.E.C)for

the support he has given to us. I am deeply indebted to my seminar incharge Mr. Nitesh Chouhan
(Assistant Professor, IT Dept)for all the motivational and support he has given to me during the
work. I am also grateful to Mr. Mukesh Verma (Assistant Professor, IT Dept) and Mr. Anurag
Jagetiya(Assistant Professor, IT Dept) for their attitude towards excellence that become a source of
constant inspiration.

Abhishek Jha

ii
Contents

1 Abstract 1

2 Introduction 2

3 Goals 3

4 HMAC and the pseudorandom function 4

5 The TLS Record Protocol 6

5.1 Connection states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Record layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2 Record compression and decompression . . . . . . . . . . . . . . . . . . . . . 9
5.2.3 Record payload protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Key Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 The TLS Handshake Protocol 10

6.1 Change cipher spec protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Alert protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1 Closure alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.2 Error alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Handshake protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7 Cryptographic computations 15
7.1 Computing the master secret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1 Anonymous key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.2 RSA key exchange and authentication . . . . . . . . . . . . . . . . . . . . . . 15
7.1.3 Diffie-Hellman key exchange with authentication . . . . . . . . . . . . . . . . 16

8 The Security Parameters 17

9 Implementation Notes 18
9.1 Temporary RSA keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2 Random Number Generation and Seeding . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3 Certificates and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.4 CipherSuites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.5 Backward Compatibility With SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iii
10 Security analysis 20
10.1 Version rollback attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2 Detecting attacks against the handshake protocol . . . . . . . . . . . . . . . . . . . . 20
10.3 Resuming sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

11 Protecting application data 22

12 Conclusion 23

13 References 24

iv
List of Figures

4.1 TLS Function ph ash(secretdata) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.1 TLS Handshake Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.2 TLS Record Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Connection states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4 Data Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6.1 Functional diagram of server TLS program . . . . . . . . . . . . . . . . . . . . . . . 12

6.2 Functional diagram of client TLS program . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Handshake protocol between client and server . . . . . . . . . . . . . . . . . . . . . . 13
6.4 Flow diagram for the handshake and authentication unit . . . . . . . . . . . . . . . . 14
6.5 Communication between handshake protocol and record protocol . . . . . . . . . . . 14

7.1 Diffie-Hellman public key agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

v
Chapter 1

Abstract

The Transport Layer Security (TLS) protocol includes features to negotiate selection of a lossless
data compression method as part of the TLS Handshake Protocol and to then apply the algorithm
associated with the selected method as part of the TLS Record Protocol. TLS defines one standard
compression method which specifies that data exchanged via the record protocol will not be com-
pressed. This document describes an additional compression method associated with a lossless data
compression algorithm for use with TLS, and it describes a method for the specification of additional
TLS compression methods.
TLS is used extensively to secure client-server connections on the World Wide Web. While these
connections can often be characterized as short-lived and exchanging relatively small amounts of
data, TLS is also being used in environments where connections can be long- lived and the amount
of data exchanged can extend into thousands or millions of octets.

1
Chapter 2

Introduction

The primary goal of the TLS Protocol is to provide privacy and data integrity between two commu-
nicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS
Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g.,
TCP[TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security
that has two basic properties:
The connection is private:
Symmetric cryptography is used for data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys
for this symmetric encryption are generated uniquely for each connection and are based on a secret
negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can
also be used without encryption.

The connection is reliable:

Message transport includes a message integrity check using a keyed MAC. Secure hash functions
(e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without
a MAC, but is generally only used in this mode while another protocol is using the Record Protocol
as a transport for negotiating security parameters.
The TLS Record Protocol is used for encapsulation of various higher level protocols. One such en-
capsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each
other and to negotiate an encryption algorithm and cryptographic keys before the application pro-
tocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection
security that has three basic properties:

The peer’s identity can be authenticated:

using asymmetric or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentica-
tion can be made optional, but is generally required for at least one of the peers.

The negotiation of a shared secret is secure:

the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret
cannot be obtained, even by an attacker who can place himself in the middle of the connection.
The negotiation is reliable:
no attacker can modify the negotiation communication without being detected by the parties to the
communication.

2
Chapter 3

Goals

The goals of TLS Protocol, in order of their priority, are:

1. Cryptographic security: TLS should be used to establish a secure connection between two
parties.

2. Interoperability: Independent programmers should be able to develop applications utilizing

TLS that will then be able to successfully exchange cryptographic parameters without knowledge of
one another’s code.

3. Extensibility: TLS seeks to provide a framework into which new public key and bulk encryp-
tion methods can be incorporated as necessary. This will also accomplish two sub-goals: to prevent
the need to create a new protocol (and risking the introduction of possible new weaknesses) and to
avoid the need to implement an entire new security library.

4. Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly

public key operations. For this reason, the TLS protocol has incorporated an optional session caching
scheme to reduce the number of connections that need to be established from scratch. Additionally,
care has been taken to reduce network activity.

3
Chapter 4

HMAC and the pseudorandom function

A number of operations in the TLS record and handshake layer required a keyed MAC; this is a
secure digest of some data protected by a secret. Forging the MAC is infeasible without knowledge
of the MAC secret. The construction we use for this operation is known as HMAC.

HMAC can be used with a variety of different hash algorithms. TLS uses it in the handshake
with two different algorithms: MD5 and SHA- 1, denoting these as HMAC-MD5(secret, data) and
HMAC-SHA(secret, data). Additional hash algorithms can be defined by cipher suites and used to
protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for
this version of the protocol. In addition, a construction is required to do expansion of secrets into
blocks of data for the purposes of key generation or validation. This pseudo-random function (PRF)
takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.

In order to make the PRF as secure as possible, it uses two hash algorithms in a way which should
guarantee its security if either algorithm remains secure. First, we define a data expansion function,
P-hash(secret, data) which uses a single hash function to expand a secret and seed into an arbitrary
quantity of output:

P-hash(secret, seed) = HMAC-hash(secret, A(1) + seed) + HMAC-hash(secret, A(2) + seed)

+ HMAC-hash(secret, A(3) + seed) + ...
Where + indicates concatenation.
A() is defined as: A(0) = seed, A(i) = HMAC-hash(secret, A(i-1))

4
 Figure 4.1: TLS Function p-hash(secret data)

P-hash can be iterated as many times as is necessary to produce the required quantity of data. For
example, if P-SHA-1 was being used to create 64 bytes of data, it would have to be iterated 4 times
(through A(4)), creating 80 bytes of output data; the last 16 bytes of the final iteration would then
be discarded, leaving 64 bytes of output data.

TLS’s PRF is created by splitting the secret into two halves and using one half to generate data
with P-MD5 and the other half to generate data with P-SHA-1, then exclusive-or’ing the outputs of
these two expansion functions together.

5
Chapter 5

The TLS Record Protocol

The TLS Record Protocol is a layered protocol. At each layer, messages may include fields for
length, description, and content. The Record Protocol takes messages to be transmitted, fragments
the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and
transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then de-
livered to higher level clients.
Four record protocol clients are described in this document: the handshake protocol, the alert proto-
col, the change cipher spec protocol, and the application data protocol. In order to allow extension of
the TLS protocol, additional record types can be supported by the record protocol. Any new record
types should allocate type values immediately beyond the ContentType values for the four record
types described. If a TLS implementation receives a record type it does not understand, it should
just ignore it. Any protocol designed for use over TLS must be carefully designed to deal with all
possible attacks against it. Note that because the type and length of a record are not protected by
encryption, care should be take to minimize the value of traffic analysis of these values.

Figure 5.1: TLS Handshake Protocol

6
 Figure 5.2: TLS Record Protocol

5.1 Connection states

A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a
compression algorithm, encryption algorithm, and MAC algorithm. In addition, the parameters for
these algorithms are known: the MAC secret and the bulk encryption keys and IVs for the connection
in both the read and the write directions.

Figure 5.3: Connection states

7
 Logically,there are always four connection states outstanding: the current read and write states,
and the pending read and write states. All records are processed under the current read and write
states. The security parameters for the pending states can be set by the TLS Handshake Protocol,
and the Handshake Protocol can selectively make either of the pending states current, in which case
the appropriate current state is disposed of and replaced with the pending state; the pending state is
then reinitialized to an empty state. It is illegal to make a state which has not been initialized with
security parameters a current state. The initial current state always specifies that no encryption,
compression, or MAC will be used.

5.2 Record layer

The TLS Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary
size.

5.2.1 Fragmentation

Figure 5.4: Data Fragmentation

The record layer fragments information blocks into TLSPlaintext records carrying data in chunks
of 2 raise to power 14 bytes or less. Client message boundaries are not preserved in the record layer
(i.e., multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext
record, or a single message may be fragmented across several records).
Note: Data of different TLS Record layer content types may be interleaved. Application data is
generally of lower precedence for transmission than other content types.

8
5.2.2 Record compression and decompression
All records are compressed using the compression algorithm defined in the current session state. There
is always an active compression algorithm; however, initially it is defined as CompressionMethod.null.
The compression algorithm translates a TLSPlaintext structure into a TLSCompressed structure.
Compression functions are initialized with default state information whenever a connection state is
made active.
Compression must be lossless and may not increase the content length by more than 1024 bytes.
If the decompression function encounters a TLSCompressed.fragment that would decompress to a
length in excess of 2 raise to power 14 bytes, it should report a fatal decompression failure error.

5.2.3 Record payload protection

The encryption and MAC functions translate a TLSCompressed structure into a TLSCiphertext. The
decryption functions reverse the process. The MAC of the record also includes a sequence number
so that missing, extra or repeated messages are detectable.

5.3 Key Calculation

The Record Protocol requires an algorithm to generate keys, IVs, and MAC secrets from the security
parameters provided by the handshake protocol.
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets,
keys, and non-export IVs required by the current connection state. CipherSpecs require a client
write MAC secret, a server write MAC secret, a client write key, a server write key, a client write
IV, and a server write IV, which are generated from the master secret in that order. Unused values
are empty.
When generating keys and MAC secrets, the master secret is used as an entropy source, and the
random values provide unencrypted salt material and IVs for exportable ciphers.

9
Chapter 6

The TLS Handshake Protocol

The TLS Handshake Protocol consists of a suite of three sub-protocols which are used to allow
peers to agree upon security parameters for the record layer, authenticate themselves, instantiate
negotiated security parameters, and report error conditions to each other.

The Handshake Protocol is responsible for negotiating a session, which consists of the following items:

Session identifier:
An arbitrary byte sequence chosen by the server to identify an active or resumable session state.

Peer certificate:
X509v3 [X509] certificate of the peer. This element of the state may be null.

Compression method:
The algorithm used to compress data prior to encryption.

Cipher specification:
Specifies the bulk data encryption algorithm (such as null, DES, etc.) and a MAC algorithm (such
as MD5 or SHA). It also defines cryptographic attributes such as the hash size.

Master secret:
48 byte secret shared between the client and server.

Resumable for:
A flag indicating whether the session can be used to initiate new connections.
These items are then used to create security parameters for use by the Record Layer when protecting
application data. Many connections can be instantiated using the same session through the resump-
tion feature of the TLS Handshake Protocol.

10
6.1 Change cipher spec protocol
The change cipher spec protocol exists to signal transitions in ciphering strategies. The protocol
consists of a single message, which is encrypted and compressed under the current (not the pending)
connection state. The message consists of a single byte of value 1.

6.2 Alert protocol

One of the content types supported by the TLS Record layer is the alert type. Alert messages convey
the severity of the message and a description of the alert. Alert messages with a level of fatal result
in the immediate termination of the connection. In this case, other connections corresponding to
the session may continue, but the session identifier must be invalidated, preventing the failed session
from being used to establish new connections. Like other messages, alert messages are encrypted
and compressed, as specified by the current connection state.

6.2.1 Closure alerts

The client and the server must share knowledge that the connection is ending in order to avoid a
truncation attack. Either party may initiate the exchange of closing messages.

11
6.2.2 Error alerts
Error handling in the TLS Handshake protocol is very simple. When an error is detected, the de-
tecting party sends a message to the other party. Upon transmission or receipt of an fatal alert
message, both parties immediately close the connection. Servers and clients are required to forget
any session-identifiers, keys, and secrets associated with a failed connection.

Figure 6.1: Functional diagram of server TLS program

Figure 6.2: Functional diagram of client TLS program

6.3 Handshake protocol

The TLS Handshake Protocol is one of the defined higher level clients of the TLS Record Protocol.
This protocol is used to negotiate the secure attributes of a session. Handshake messages are supplied
to the TLS Record Layer, where they are encapsulated within one or more TLSPlaintext structures,
which are processed and transmitted as specified by the current active session state.
The handshake protocol messages are presented below in the order they must be sent; sending
handshake messages in an unexpected order results in a fatal error. Unneeded handshake messages

12
can be omitted, however. Note one exception to the ordering: the Certificate message is used twice
in the handshake (from server to client, then from client to server), but described only in its first
position. The one message which is not bound by these ordering rules in the Hello Request message,
which can be sent at any time, but which should be ignored by the client if it arrives in the middle
of a handshake.

Figure 6.3: Handshake protocol between client and server

13
 Figure 6.4: Flow diagram for the handshake and authentication unit

Figure 6.5: Communication between handshake protocol and record protocol

14
Chapter 7

Cryptographic computations

In order to begin connection protection, the TLS Record Protocol requires specification of a suite of
algorithms, a master secret, and the client and server random values. The authentication, encryption,
and MAC algorithms are determined by the cipher suite selected by the server and revealed in the
server hello message. The compression algorithm is negotiated in the hello messages, and the random
values are exchanged in the hello messages. All that remains is to calculate the master secret.

7.1 Computing the master secret

For all key exchange methods, the same algorithm is used to convert the pre master secret into the
master secret. The pre master secret should be deleted from memory once the master secret has
been computed.

master secret = PRF(pre master secret, “master secret”, ClientHello.random + ServerHello.random)

[0..47];

The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary
depending on key exchange method.

7.1.1 Anonymous key exchange

Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange.
With anonymous RSA, the client encrypts a pre-master-secret with the server’s uncertified public
key extracted from the server key exchange message. The result is sent in a client key exchange
message. Since eavesdroppers do not know the server’s private key, it will be infeasible for them
to decode the pre-master-secret. (Note that no anonymous RSA Cipher Suites are defined in this
document).

7.1.2 RSA key exchange and authentication

When RSA is used for server authentication and key exchange, a 48- byte pre-master-secret is gen-
erated by the client, encrypted under the server’s public key, and sent to the server. The server uses

15
its private key to decrypt the pre-master-secret. Both parties then convert the pre-master-secret into
the master-secret.
With RSA, key exchange and server authentication are combined. The public key may be either
contained in the server’s certificate or may be a temporary RSA key sent in a server key exchange
message. When temporary RSA keys are used, they are signed by the server’s RSA or DSS certifi-
cate. The signature includes the current ClientHello.random, so old signatures and temporary keys
cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions.

7.1.3 Diffie-Hellman key exchange with authentication

A conventional Diffie-Hellman computation is performed. The negotiated key is used as the pre-
master-secret, and is converted into the master-secret.
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed
Diffie-Hellman parameters or can use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed
with the hello.random values before signing to ensure that attackers do not replay old parameters.
In either case, the client can verify the certificate or signature to ensure that the parameters belong
to the server.

Figure 7.1: Diffie-Hellman public key agreement

If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains
the information required to complete the key exchange. Note that in this case the client and server
will generate the same Diffie-Hellman result (i.e., pre-master-secret) every time they communicate.
To prevent the pre-master-secret from staying in memory any longer than necessary, it should be
converted into the master-secret as soon as possible. Client Diffie-Hellman parameters must be
compatible with those supplied by the server for the key exchange to work.
If the client has a standard DSS or RSA certificate or is unauthenticated, it sends a set of temporary
parameters to the server in the client key exchange message, then optionally uses a certificate verify
message to authenticate itself.

16
Chapter 8

The Security Parameters

These security parameters are determined by the TLS Handshake Protocol and provided as pa-
rameters to the TLS Record Layer in order to initialize a connection state. SecurityParameters
includes:

• enum [null(0), (255)] CompressionMethod;

• enum [server, client] ConnectionEnd;

• enum [null, rc4, rc2, des, 3des, des40, idea] BulkCipherAlgorithm;

• enum [stream, block] CipherType;

• enum [true, false] IsExportable;

• enum [null, md5, sha] MACAlgorithm;

17
Chapter 9

Implementation Notes

The TLS protocol cannot prevent many common security mistakes. This section provides several
recommendations to assist implementors.

9.1 Temporary RSA keys

US Export restrictions limit RSA keys used for encryption to 512 bits, but do not place any limit
on lengths of RSA keys used for signing operations. Certificates often need to be larger than 512
bits, since 512-bit RSA keys are not secure enough for high-value transactions or for applications
requiring long-term security. Some certificates are also designated signing-only, in which case they
cannot be used for key exchange.

9.2 Random Number Generation and Seeding

TLS requires a cryptographically-secure pseudorandom number generator (PRNG). Care must be
taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably MD5
and/or SHA, are acceptable, but cannot provide more security than the size of the random number
generator state. (For example, MD5-based PRNGs usually provide 128 bits of state.)

9.3 Certificates and authentication

Implementations are responsible for verifying the integrity of certificates and should generally support
certificate revocation messages. Certificates should always be verified to ensure proper signing by a
trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very
carefully. Users should be able to view information about the certificate and root CA.

9.4 CipherSuites
TLS supports a range of key sizes and security levels, including some which provide no or minimal
security. A proper implementation will probably not support many cipher suites. For example,

18
40-bit encryption is easily broken, so implementations requiring strong security should not allow
40-bit keys. Similarly, anonymous Diffie- Hellman is strongly discouraged because it cannot prevent
man-in- the-middle attacks. Applications should also enforce minimum and maximum key sizes.
For example, certificate chains containing 512-bit RSA keys or signatures are not appropriate for
high-security applications.

9.5 Backward Compatibility With SSL

For historical reasons and in order to avoid a profligate consumption of reserved port numbers,
application protocols which are secured by TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the
same connection port: for example, the https protocol (HTTP secured by SSL or TLS) uses port
443 regardless of which security protocol it is using. Thus, some mechanism must be determined to
distinguish and negotiate among the various protocols.

19
Chapter 10

Security analysis

The TLS protocol is designed to establish a secure connection between a client and a server commu-
nicating over an insecure channel. This document makes several traditional assumptions, including
that attackers have substantial computational resources and cannot obtain secret information from
sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete,
replay, and otherwise tamper with messages sent over the communication channel. This appendix
outlines how TLS has been designed to resist a variety of attacks.

10.1 Version rollback attacks

Because TLS includes substantial improvements over SSL Version 2.0, attackers may try to make
TLS-capable clients and servers fall back to Version 2.0. This attack can occur if (and only if) two
TLS- capable parties use an SSL 2.0 handshake.

Although the solution using non-random PKCS 1 block type 2 message padding is inelegant, it
provides a reasonably secure way for Version 3.0 servers to detect the attack. This solution is not
secure against attackers who can brute force the key and substitute a new ENCRYPTED-KEY-
DATA message containing the same key (but with normal padding) before the application specified
wait threshold has expired. Parties concerned about attacks of this scale should not be using 40-bit
encryption keys anyway. Altering the padding of the least- significant 8 bytes of the PKCS padding
does not impact security for the size of the signed hashes and RSA key lengths used in the protocol,
since this is essentially equivalent to increasing the input block size by 8 bytes.

10.2 Detecting attacks against the handshake protocol

An attacker might try to influence the handshake exchange to make the parties select different
encryption algorithms than they would normally choose. Because many implementations will support
40-bit exportable encryption and some may even support null encryption or MAC algorithms, this
attack is of particular concern.

20
10.3 Resuming sessions
When a connection is established by resuming a session, new ClientHello.random and ServerHello.random
values are hashed with the session’s master-secret. Provided that the master-secret has not been com-
promised and that the secure hash operations used to produce the encryption keys and MAC secrets
are secure, the connection should be secure and effectively independent from previous connections.
Attackers cannot use known encryption keys or MAC secrets to compromise the master-secret with-
out breaking the secure hash operations (which use both SHA and MD5).

21
Chapter 11

Protecting application data

The master-secret is hashed with the ClientHello.random and ServerHello.random to produce

unique data encryption keys and MAC secrets for each connection.

Outgoing data is protected with a MAC before transmission. To prevent message replay or mod-
ification attacks, the MAC is computed from the MAC secret, the sequence number, the message
length, the message contents, and two fixed character strings. The message type field is necessary
to ensure that messages intended for one TLS Record Layer client are not redirected to another.
The sequence number ensures that attempts to delete or reorder messages will be detected. Since
sequence numbers are 64-bits long, they should never overflow. Messages from one party cannot be
inserted into the other’s output, since they use independent MAC secrets. Similarly, the server-write
and client-write keys are independent so stream cipher keys are used only once.

If an attacker does break an encryption key, all messages encrypted with it can be read. Similarly,
compromise of a MAC key can make message modification attacks possible. Because MACs are also
encrypted, message-alteration attacks generally require breaking the encryption algorithm as well as
the MAC.

22
Chapter 12

Conclusion

For TLS to be able to provide a secure connection, both the client and server systems, keys, and
applications must be secure. In addition, the implementation must be free of security errors.

The system is only as strong as the weakest key exchange and authentication algorithm supported,
and only trustworthy cryptographic functions should be used. Short public keys, 40-bit bulk encryp-
tion keys, and anonymous servers should be used with great caution. Implementations and users
must be careful when deciding which certificates and certificate authorities are acceptable; a dishon-
est certificate authority can do tremendous damage.

23
Chapter 13

References

The references that were useful in creating this report are:

[1] W. Tuchman, ”Hellman Presents No Shortcut Solutions To DES,” IEEE Spectrum, v. 16, n.
7, July 1979, pp40-41.

[2] X3.106, ”American National Standard for Information Systems-Data Link Encryption,” Amer-
ican National Standards Institute, 1983.

[3] . Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard,
August 1995.

[4] http://www.rsc.org/Publishing/ChemTech/Volume/2009/09/tls.html

[5] http://en.wikipedia.org/wiki/Transportlayersecurity

24