1. SSL / TLS
Internet Security Protocols

2. © Novell, Inc. All rights reserved.2
What is it used for?
 Designed to provide communication security over the
Internet
 Authentication, Data Integrity, Confidentiality
 Prevents Eavesdropping, tampering & message
forgery
 Application protocol independent ( POP3, IMAP,
SMTP, FTP)
 Virtual Private Network (SSL VPN)
 Public key infrastructure(PKI)

3. © Novell, Inc. All rights reserved.3
Cryptography Heads up!!!
1. Symmetric Key
Cryptography
2. Asymmetric Key
Cryptography a.k.a.
Public Key Cryptography

4. © Novell, Inc. All rights reserved.4
Symmetric Key Cryptography

5. © Novell, Inc. All rights reserved.5
Public Key Cryptography

6. © Novell, Inc. All rights reserved.6
History & Development
Secure Network Programming (1993)
SSL 1.0, 2.0 and 3.0 (1995-96)
TLS 1.0(1999)
TLS 1.1(2006)
TLS 1.2(2008)
TLS 1.3(Draft Oct. 2014)

7. © Novell, Inc. All rights reserved.7
SSL/TLS Architecture
Handshake
protocol
Change Cipher
spec
Alert Application
Protocol
Record
TCP/IP

8. © Novell, Inc. All rights reserved.8
Basic TLS Handshake
TLS Client
TLS Server
Client Hello
Offers TLS version, list of ciphers, compression methods etc.
Server Hello
Server chooses TLS version, Session IDs, Cipher, compression method
Server Certificate (Optional)
Server Key Exchange (Optional)
Servers public key if certificate not available
Client certificate request (Optional)
Server Hello Done
Client Certificate (Optional)
Client KeyExchange
PreMasterSecret or public key, or nothing encrypted using server’s public key
Client Certificate verify (Optional)
client will start using the new session keys for hashing and encrypting messages
Change CipherSpec
Server Finished
Encrypted Application Data
Change CipherSpec & Client Finished

9. © Novell, Inc. All rights reserved.9
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: resumed sessions.
 Resumed sessions are implemented using session IDs or
session tickets.
 Apart from the performance benefit, resumed sessions
can also be used for single sign-on.
 Session ID and Session tickets are used for resumed
TLS handshake.

10. © Novell, Inc. All rights reserved.10
Resumed TLS Handshake (Cont.)
TLS Client
TLS Server
Client Hello
Offers TLS version, list of ciphers, compression methods etc.
Older Session ID / Session Ticket
Server Hello
With Old / New session ID
Change CipherSpec & Client Finished
client will start using the new /old session keys for hashing and encrypting
messages
Encrypted Application Data
Change CipherSpec
Server Finished
containing a hash and MAC over the previous handshake messages

11. © Novell, Inc. All rights reserved.11
Session ID & Session tickets
Session ID:- 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.
Session Tickets:- When using session tickets, the TLS server stores
its session-specific state in a session ticket and sends the session ticket
to the TLS client for storing. The client resumes a TLS session by
sending the session ticket to the server, and the server resumes the TLS
session according to the session-specific state in the ticket. The session
ticket is encrypted and authenticated by the server, and the server
verifies its validity before using its contents.

12. © Novell, Inc. All rights reserved.12
TLS Record Protocol
 The TLS Record Protocol is a layered protocol.
 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,
reassembled, and then delivered to higher-level clients.
 Following four protocol clients uses it: the handshake
protocol, the alert protocol, the change cipher spec
protocol, and the application data protocol

13. © Novell, Inc. All rights reserved.13
TLS Record Protocol(Cont.)
TLS Record Header

14. © Novell, Inc. All rights reserved.14
Connection States
 A TLS connection state is the operating environment of
the TLS Record Protocol
 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 Change
Cipher Spec can selectively make either of the pending
states current

15. © Novell, Inc. All rights reserved.15
Message Authentication Code
 TLS record layer uses Keyed-Hash MAC(HMAC) for authentication
and integrity check of messages.
 HMAC employs an iterative cryptographic hash function in
combination with a premaster secret key as follows:
H(secret XOR opad, H(secret XOR ipad, message))
 HMAC produces a fixed length message digest which may not be
sufficiently long. To remedy this successive concatenation of HMAC
with different values is done as follows:
P_hash(secret, seed) = H(secret, A(1) + seed) + H(secret, A(2) + seed) + H (secret, A(3) +
seed) + ...
where + indicates concatenation.
A() is defined as: A(0) = seed = ClientHello.random + ServerHello.random
A(i) = H (secret, A(i-1))
Secret = premaster secret

16. © Novell, Inc. All rights reserved.16
Master Key Generation:-
 The master secret is calculated using PRF:
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random +
ServerHello.random) [0..47];
where + indicates concatenation.
 TLS's PRF is created by applying P_hash to the secret as:
PRF(secret, label, seed) = P_<hash>(secret, label, + seed)
where + indicates concatenation.
 The master secret is always exactly 48 bytes in length.
 The Length of the premaster secret will vary depending on
key exchange method.

17. © Novell, Inc. All rights reserved.17
TLS communication steps
1. Handshake and cipher suite negotiation
2. Authentication of parties
3. Key-related information exchange
4. Application data exchange
The steps that make up TLS are divided into two protocols
that together provide connection security:
TLS Handshaking Protocols — (steps 1 – 3)
Application Data Protocol — (step 4)

18. © Novell, Inc. All rights reserved.18
TLS Handshaking Protocols
 It is responsible for the authentication and key exchange
necessary to establish or resume secure sessions
 When establishing a secure session, the Handshaking
Protocol manages the following:
• Cipher suite negotiation
• Authentication of the server and optionally, the client
• Session key information exchange.
 It includes “The Handshake Protocol”, “The Alert
Protocol” & “Change Cipher Spec Protocol”

19. © Novell, Inc. All rights reserved.19
TLS Handshake Protocol
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 resume-able session state.
 Peer Certificate:- X509v3 certificate of the peer. This element of the state may be null.
 Compression Method:- The algorithm used to compress data prior to encryption.
 Cipher Spec:- Specifies the pseudorandom function (PRF) used to generate keying
material, the bulk data encryption algorithm (such as null, AES, etc.) and the MAC
algorithm (such as MD5 HMAC-SHA1). It also defines cryptographic attributes such as
the mac_length.
 Master Secret:- 48-byte secret shared between the client and server.
 is resumable:- A flag indicating whether the session can be used to initiate new
connections.

20. © Novell, Inc. All rights reserved.20
Change Cipher Spec Protocol
 The change cipher spec protocol exists to signal
transitions in ciphering strategies.
 The ChangeCipherSpec message is sent by both the
client and the server to notify the receiving party that
subsequent records will be protected under the newly
negotiated CipherSpec and keys.

21. © Novell, Inc. All rights reserved.21
Alert Protocol
 Alert messages convey the severity of the message
(warning or fatal) and a description of the alert.
 There are two alert levels in TLS
1. Fatal:- immediate termination of the connection
2. Warning:- 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
 For complete list of alert messages use RFC5246
Note :- alert messages are encrypted and compressed, as
specified by the current connection state.

22. © Novell, Inc. All rights reserved.22
Application Data Protocol
 Application data messages are carried by the record layer
and are fragmented, compressed, and encrypted based
on the current connection state. The messages are
treated as transparent data to the record layer.

23. © Novell, Inc. All rights reserved.23
TLS Record
Content Type:-
This field identifies the Record Layer
Protocol Type contained in this Record.

24. © Novell, Inc. All rights reserved.24
TLS Record(Cont.)
Version :- This field identifies
the major and minor
version of TLS for the
contained message. For a
ClientHello message, this
need not be the highest
version supported by the
client.

25. © Novell, Inc. All rights reserved.25
TLS Record(Cont.)
Version :- This field identifies
the major and minor
version of TLS for the
contained message. For a
ClientHello message, this
need not be the highest
version supported by the
client.
Length:- The length of
Protocol message(s), MAC
and Padding, not to
exceed 214 bytes (16 KiB).

26. © Novell, Inc. All rights reserved.26
TLS Record(Cont.)
Protocol message(s):- One or more messages identified by
the Protocol field. Note that this field may be encrypted
depending on the state of the connection.
MAC and Padding:- A message authentication code
computed over the Protocol message, with additional key
material included. Note that this field may be encrypted, or
not included entirely, depending on the state of the
connection. No MAC or Padding can be present at end of
TLS records before all cipher algorithms and parameters
have been negotiated and handshaked and then
confirmed by sending a CipherStateChange record (see
below) for signalling that these parameters will take effect
in all further records sent by the same peer.

27. © Novell, Inc. All rights reserved.27
References:-
• http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS
_record
• rfc2246, rfc5246, rfc4346
• http://msdn.microsoft.com/en-
us/library/windows/desktop/aa380516%28v=vs.85%29.as
px
• https://www.cs.bham.ac.uk/~mdr/teaching/modules06/net
sec/lectures/tls/tls.html
• http://lasr.cs.ucla.edu/vahab/resources/notes_on_tls.pdf

28. © Novell, Inc. All rights reserved.28
Corporate Headquarters
1800 South, Novell Place
Provo, Utah 84606
801.861.7000 (Worldwide)
800.453.1267 (Toll-free)
Join us on:
www.novell.com