A Seminar Report "Transport Layer Security": Submitted To: Submitted by
A Seminar Report "Transport Layer Security": Submitted To: Submitted by
A Seminar Report "Transport Layer Security": Submitted To: Submitted by
Seminar Report
ON
Session: 2010-2011
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.
Abhishek Jha
ii
Contents
1 Abstract 1
2 Introduction 2
3 Goals 3
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
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
12 Conclusion 23
13 References 24
iv
List of Figures
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.
2
Chapter 3
Goals
1. Cryptographic security: TLS should be used to establish a secure connection between two
parties.
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.
3
Chapter 4
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:
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 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.
6
Figure 5.2: TLS Record Protocol
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.1 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.
9
Chapter 6
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.
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.
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.
13
Figure 6.4: Flow diagram for the handshake and authentication unit
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.
The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary
depending on key exchange method.
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.
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
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:
17
Chapter 9
Implementation Notes
The TLS protocol cannot prevent many common security mistakes. This section provides several
recommendations to assist implementors.
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.
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.
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.
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
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
[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