A.

CHATURVEDI CSE 08951A0515

` ` ` ` ` ` ` `

TLS Definition Working of TLS History and Development Security TLS Protocols Applications Comparison of SSL and TLS Implementations

Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message.  The TLS protocol is based on Netscape's SSL 3.0 protocol.


TLS is composed of two layers:

TLS Record Protocol and the TLS Handshake Protocol.

The TLS Record Protocol provides connection security with some encryption method such as the Data Encryption Standard (DES). TLS Record Protocol can also be used without encryption. The TLS Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged.

The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. Once the client and server have decided to use TLS they negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security. The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported cipher suites (ciphers and hash functions). From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision. The server sends back its identification in the form of a digital certificate.

 

 

The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of the certificate before proceeding. In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key. From the random number, both parties generate key material for encryption and decryption. This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes. If any one of the above steps fails, the TLS handshake fails and the connection is not created.

Secure Network Programming API



Early research efforts toward transport layer security included the Secure Network Programming (SNP) application programming interface (API), which in 1993 explored the approach of having a secure transport layer API closely resembling Berkeley sockets, to facilitate retrofitting preexisting network applications with security measures. The SSL protocol was originally developed by Netscape. SSL version 1.0 was never publicly released. SSL version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0". SSL version 3.0, released in 1996, was a complete redesign of the protocol .Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historic document in RFC 6101.

SSL 1.0, 2.0 and 3.0



TLS 1.0
 

TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade to SSL Version 3.0. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate." TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0.

TLS 1.1
 

TLS 1.1 was defined in RFC 4346 in April 2006.It is an update from TLS version 1.0. Significant differences in this version include: Added protection against Cipher block chaining (CBC) attacks.  The implicit Initialization Vector (IV) was replaced with an explicit IV.  Change in handling of padding errors. Support for IANA registration of parameters.

TLS 1.2
 

 

TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Major differences include: The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use cipher-suite specified PRFs. The MD5-SHA-1 combination in the Finished message hash was replaced with SHA-256, with an option to use cipher-suite specific hash algorithms. However the size of the hash in the finished message is still truncated to 96-bits. The MD5-SHA-1 combination in the digitally-signed element was replaced with a single hash negotiated during handshake, defaults to SHA-1. Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept. TLS Extensions definition and Advanced Encryption Standard CipherSuites were added.

10

TLS has a variety of security measures:  Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.  Numbering subsequent Application records with a sequence number and using this sequence number in the message authentication codes (MACs).  Using a message digest enhanced with a key (so only a key-holder can check the MAC).  The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties.  The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these algorithms is found to be vulnerable.  SSL 3.0 improved upon SSL 2.0 by adding SHA-1 based ciphers and support for certificate authentication.
11

TLS handshake in detail  The TLS protocol exchanges records, which encapsulate the data to be exchanged. Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the connection.  Each record has a content type field that specifies the record, a length field and a TLS version field.  When the connection starts, the record encapsulates another protocol the handshake messaging protocol which has content type 22. Simple TLS handshake A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate: 1) Negotiation phase:  A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.  The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID.

12

  

The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected. The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server). The server sends a ServerHelloDone message, indicating it is done with handshake negotiation. The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate. The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the clientand server-generated random values), which is passed through a carefully designed pseudorandom function.

13

2) The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20  Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.  The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

14

3) Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."  The server sends its authenticated and encrypted Finished message.  The client performs the same decryption and verification. 4) Application phase: At this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.

15

Client-authenticated TLS handshake The following full example shows a client being authenticated (in addition to the server like above) via TLS using certificates exchanged between both peers. 1)Negotiation phase:
 A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.  The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.  The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).  The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.  The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.  The client responds with a Certificate message, which contains the client's certificate.

16

The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate. The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate. The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.

17

2) The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22. ` Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages. ` The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down

18

3) Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)." ` The server sends its own encrypted Finished message. ` The client performs the same decryption and verification. 4) Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message. The application will never again return TLS encryption information without a type 32 apology.

19

Resumed TLS handshake

Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations. In an ordinary full handshake, the server sends a session id as part of the ServerHello message. The client associates this session id with the server's IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello and ServerHello messages virtually guarantee that the generated connection keys will be different than in the previous connection. In the RFCs, this type of handshake is called an abbreviated handshake or Restart handshake.

20

1)Negotiation phase:


A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. Included in the message is the session id from the previous TLS connection. The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. If the server recognizes the session id sent by the client, it responds with the same session id. The client uses this to recognize that a resumed handshake is being performed. If the server does not recognize the session id sent by the client, it sends a different value for its session id. This tells the client that a resumed handshake will not be performed. At this point, both the client and server have the "master secret" and random data to generate the key data to be used for this connection.

21

2) The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.  Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.  The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

22

3)Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be encrypted."  The server sends its own encrypted Finished message.  The client performs the same decryption and verification. 4)Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message. Apart from the performance benefit, resumed sessions can also be used for single sign-on as it is guaranteed that both the original session as well as any resumed session originate from the same client. This is of particular importance for the FTP over TLS/SSL protocol which would otherwise suffer from a man in the middle attack in which an attacker could intercept the contents of the secondary data connections.

23

TLS HANDSHAKE PROTOCOL

The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions. When establishing a secure session, the Handshake Protocol manages the following: Cipher suite negotiation Authentication of the server and optionally, the client Session key information exchange.

` ` `

Establishing a Secure Session by Using TLS

The client and server make contact and choose the cipher suite that will be used throughout their message exchange. In TLS, a server proves its identity to the client. The client might also need to prove its identity to the server. PKI, the use of public/private key pairs, is the basis of this authentication. The exact method used for authentication is determined by the cipher suite negotiated. The client and server exchange random numbers and a special number called the Pre-Master Secret. These numbers are combined with additional data permitting client and server to create their shared secret, called the Master Secret. The Master Secret is used by client and server to generate the write MAC secret, which is the session key used for hashing, and the write key, which is the session key used for encryption.

Cipher Suite Negotiation

`

Authentication
`

Key Exchange
`

24

Resuming a Secure Session by Using TLS

` `

The client sends a "Client hello" message using the Session ID of the session to be resumed. The server checks its session cache for a matching Session ID. If a match is found, and the server is able to resume the session, it sends a "Server hello" message with the Session ID. Note :If a session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake. Client and server must exchange "Change cipher spec" messages and send "Client finished" and "Server finished" messages. Client and server can now resume application data exchange over the secure channel.

25

TLS HANDSHAKE PROTOCOL MESSAGE TYPES

Message Types Message Types

Code Code Description Description HelloRequest HelloRequest ClientHello ClientHello ServerHello Certificate

0 0 1 1 2 2 11 12 13 14
11 12 13 14 15

ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone

ServerKeyExchange CertificateRequest ServerHelloDone CertificateVerify

1516 1620 20

CertificateVerify ClientKeyExchange ClientKeyExchange Finished Finished

26

TLS record protocol ` The Transport Layer Security (TLS) Record protocol secures application data using the keys created during the Handshake. ` The Record Protocol is responsible for securing application data and verifying its integrity and origin. It manages the following: ` Dividing outgoing messages into manageable blocks, and reassembling incoming messages. ` Compressing outgoing blocks and decompressing incoming blocks (optional). ` Applying a Message Authentication Code (MAC) to outgoing messages, and verifying incoming messages using the MAC. ` Encrypting outgoing messages and decrypting incoming messages. ` When the Record Protocol is complete, the outgoing encrypted data is passed down to the Transmission Control Protocol (TCP) layer for transport.

27

TLS ALERT PROTOCOL

This protocol sends errors, problems or warnings between two parties. It Consists of two levels mainly :  Alert level  Security level Alert level types
code 1 Level type warning Connection state connection or security may be unstable. connection or security may be compromised, or an unrecoverable error has occurred

fatal

29

In applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the application-specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP. Historically it has been used primarily with reliable transport protocols such as the Transmission Control Protocol (TCP). However, it has also been implemented with datagram-oriented transport protocols, such as the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP), usage which has been standardized independently using the term Datagram Transport Layer Security (DTLS). A prominent use of TLS is for securing World Wide Web traffic carried by HTTP to form HTTPS. Notable applications are electronic commerce and asset management. Increasingly, the Simple Mail Transfer Protocol (SMTP) is also protected by TLS. These applications use public key certificates to verify the identity of endpoints. TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications.

31

TLS is a standard closely related to SSL 3.0, and is sometimes referred to as "SSL 3.1". ` Applications that require a high level of interoperability should support SSL 3.0 and TLS. The following is from RFC 2246 standard: The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough such that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0)."
`

32

The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure hello to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created. The main benefit in opting for TLS over SSL is that TLS was incepted as an open-community standard, meaning TLS is more extensible and will likely be more widely supported in the future with other Internet standards. TLS is even backwards compatible, possessing the ability to scale down to SSL if necessary to support secure client-side connections that only understand SSL. Another more immediate benefit, however, is that TLS allows both secure and insecure connections over the same port, whereas SSL requires a designated secure-only port. For users connecting to an email server via POP or IMAP, this means that using TLS will allow you to opt for secure connections but easily switch to insecure connections if necessary without needing to change ports. This is not possible with SSL.

33

SSL and TLS have been widely implemented in several free and open source software projects. ` Programmers may use the PolarSSL, CyaSSL, OpenSSL, NSS, or GnuTLS libraries for SSL/TLS functionality. ` Microsoft Windows includes an implementation of SSL and TLS as part of its Secure Channel package. Browser implementations ` All the most recent web browsers support TLS. ` Apple's Safari supports TLS.On operating systems (Safari uses the TLS implementation of the underlying OS) like Mac OS X 10.5.8, Mac OS X 10.6.6, Windows XP, Windows Vista or Windows 7, Safari 5 has been reported to support TLS 1.0.
`

34

` `

` `

Mozilla Firefox, versions 2 and above, support TLS 1.0.As of January 2012 Firefox does not support TLS 1.1 or 1.2. Microsoft Internet Explorer always uses the TLS implementation of the underlying Microsoft Windows Operating System, a service called SChannel Security Service Provider. Internet Explorer 8 in Windows 7 and Windows Server 2008 R2 supports TLS 1.2. Windows 7 and Windows Server 2008 R2 use the same code (Microsoft Windows Version 6.1 (build 7600)) similar to how Windows Vista SP1 uses the same code as Windows 2008 Server. As of Presto 2.2, featured in Opera 10, Opera supports TLS 1.2. Google's Chrome browser supports TLS 1.0, but not TLS 1.1 or 1.2.

35

36