NETWORKS

Introduction to TLS Meir Leshem

Sept 2010
SSL/TLS Protocol Overview NETWORKS

 The SSL/TLS protocol allows client/server applications to

communicate across a network in a way designed to prevent
eavesdropping and alteration of the messages.
 TLS provides endpoint (peer) authentication and
communications confidentiality and Integrity over the Internet
using cryptography (encryption/ decryption).

Feature Service Method Attack

Hiding info Confidentiality Encryption Eavesdropping

(anyone can see content)
Proving Authentication Public Key Forgery and Masquerade
identity (verify who you are talking to)
Verifying Msg. Integrity HMAC Alteration
info (someone may alter content)
2
Network Layer (IpSec) Vs. Transport Layer (SSL/TLS) Security NETWORKS

3
SSL/TLS History NETWORKS

RFC 2246 RFC 4346 RFC 5246

TLS 1.1 TLS 1.2

2006 2008

4
The SSL with its (sub) layers and (sub) protocols NETWORKS

5
SSL/TLS sub layers and protocols NETWORKS

INITIALIZES SECURE ERROR HANDLING

COMMUNICATION

HANDLES COMMUNICATION
WITH THE APPLICATION

Protocols
INITIALIZES COMMUNCATION
BETWEEN CLIENT & SERVER
HANDLES DATA
COMPRESSION and
transfers TLS messages

6
SSL/TLS Main principles NETWORKS

Key Exchange (for Symmetric Encryption) – using Public Key

Data Integrity – using HMAC (Hashed Message Auth. Key)
Server Authentication – using Certificates with public key
Client / Server Protocol
Establish a Security Session
 Agree on algorithms
 Share secrets
 Perform server authentication (and optionally the client)
Transfer encrypted application data
 Ensure privacy and integrity
7
Encryption Types NETWORKS

 Symmetric encryption (= Secret key cryptography): Uses the

same key for encryption and decryption. It is also known as
secret-key cryptography. The symmetric algorithms are normally
used to encrypt the content of a message
 Asymmetric encryption (= Public key cryptography): each of
the two parties use separate keys - one for encryption and a
different one for decryption. The critical aspect of public key
cryptography is that only one of these two keys (private key)
needs to be kept secret. The other key, the public key, need not be
secret at all.
 Symmetric encryption does not need as much processing power
as asymmetric encryption. The encryption comes at a much lower
cost.

8
Public/Private (RSA) Key functionality NETWORKS

 The function provided depends on the cryptographic key in

use:
 If the recipient’s public key is used to encrypt a plaintext
message (by the sender), then the RSA public key
cryptosystem yields an asymmetric encryption system. In
this case, the recipient’s private key is used to decrypt the
ciphertext. Ideally, this can only be done by the recipient of
the message.
 If the sender’s private key is used to encrypt a plaintext
message (or hash value thereof), then the RSA key
cryptosystem yields a digital signature system.
 In this case, the sender’s public key is used to verify the
digital signature. This can be done by anybody.
9
TLS: Key Exchange algorithms for Encryption NETWORKS

 Need secure method to exchange secret key

 Use public key encryption for this
 “key pair” is used - either one can encrypt and then the other can
decrypt
 slower than conventional cryptography
 share one key, keep the other private
 Choices are RSA or Diffie-Hellman

10
TLS: Key Exchange Call Flow NETWORKS

Call Flow for Client (Alice) to Server (Bob) key exchange :

 Bob publishes its public key
 Alice generates random number and creates secret using Bob’s public key
 Bob decrypts the secret using its private key.
 Both sides send ‘Finish’ confirmation message with encrypted indication

11
TLS: Data Integrity NETWORKS

 Compute fixed-length Message

Authentication Code (MAC)
 Includes hash of message
 Includes a shared secret
 Transmit MAC with message
 TLS allows:
 MD5 (16 bytes output)
 SHA-1 (20 bytes output)

12
Message Authentication Code (MAC, HMAC) NETWORKS

 MAC is a cryptographic checksum that is used to ensure the integrity of the

message during transmission
 The hash-based MAC (HMAC) is the most popular MAC type
 Hashing properties:
 Processes a variable-length message into a fixed-length output (128,160 bits)
 One way encryption (impossible/difficult to get the original message)
 Collision free output (at least infeasible to find 2 inputs with same output)
 Sequence Number (in SSL/TLS)
 MD5 or SHA-1 are defined in TLS
 RFC 2104 defined HMAC for authentication:
HMAC(K,M) = H(K XOR opad,H (K XOR ipad,M))
where opad is the string 0X5c and ipad is the string 0x36
K = Secret, H = Hash function (MD5 or SHA-1)
MD5("The quick brown fox jumps over the lazy dog") =
9e107d9d372bb6826bd81d3542a419d6
MD5("") = d41d8cd98f00b204e9800998ecf8427e 13
Hashed MAC for TLS according RFC 2104 NETWORKS

H – Hash using MD5 or SHA-1

K - secret

HMAC = H[K xor 0x5c , H(K xor 0x36 , text)]

14
Message Authentication using HMAC NETWORKS

15
TLS: Authentication NETWORKS

Verify identities of participants

Client authentication is optional
Certificate is used to associate endpoint identity with
public key and other attributes

A B
Certificate
Certificate

16
Handshake Protocol NETWORKS

Negotiate Cipher-Suite Algorithms

 Symmetric cipher to use
 Key exchange method (RSA or DH)
 Message digest function

Establish and share master secret

Authenticate server and optionally the client

17
The SSL record processing NETWORKS

18
SSL Record Protocol Elements NETWORKS

 Fragmentation: SSL Record Protocol fragments the higher-

layer protocol data into blocks of 16,384 bytes or less.
 Compression: SSL Record Protocol compresses the SSL
Plaintext structure according to the compression method
specified in the SSL session state. This method is initially set
to null.
 MAC: Message Authentication Code (MD-5 or SHA-1).
 Cryptographic Protection: Key Exchange, Encryption and
Message authentication.

19
SSL Record Structure NETWORKS

20
Record Header NETWORKS

Three pieces of information:

 Content type (1 byte)
 Application data (23)
 Alert (21)
 Handshake (22)
 Change_cipher_spec (20)
 SSL version (2 bytes)
 The major and minor version of the SSL
 specification to which this message conforms
 Redundant check for version agreement
 Content length (2 bytes)
 The length of the following higher-layer protocol messages as a 16-bit binary
number.
 The SSL specification requires that this value not exceed 2**14 (16 384)

21
Handshake Protocol Messages NETWORKS

22
Handshake Protocol Message Types NETWORKS

23
 SSL Messages
NETWORKS

CLIENT SIDE SERVER SIDE

OFFER CIPHER SUITE SELECT A CIPHER SUITE
MENU TO SERVER
SEND CERTIFICATE AND
CHAIN TO CA ROOT

SEND PUBLIC KEY TO

ENCRYPT SYMM KEY

SEND ENCRYPTED SERVER NEGOTIATION

SYMMETRIC KEY FINISHED

ACTIVATE
ENCRYPTION
CLIENT PORTION ( SERVER CHECKS OPTIONS )
DONE ACTIVATESERVER
ENCRYPTION
( CLIENT CHECKS OPTIONS ) SERVER PORTION
DONE
NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION

24
Handshake Protocol - Detailed NETWORKS

25
Handshake Protocol – Detailed (Cont.) NETWORKS

26
Resuming a Session NETWORKS

ClientHello sent with previously established Session Id

27
Client Hello
NETWORKS

 Protocol version
 SSLv3(major=3, minor=0)
 TLS (major=3, minor=1)
 Random Number
 32 bytes
 First 4 bytes, time of the day in seconds, other 28 bytes random
 Prevents replay attack
 Session ID
 32 bytes – indicates the use of previous cryptographic material, maybe null
in 1st Client Hello
 CipherSuites
 A list of cryptographic parameters that the client can support.
 Compression algorithm
 Not used (null) 28
Client Hello - Cipher Suites
NETWORKS

SSL_NULL_WITH_NULL_NULL = { 0, 0 } INITIAL (NULL) CIPHER SUITE

PUBLIC-KEY SYMMETRIC HASH

ALGORITHM ALGORITHM ALGORITHM

SSL_RSA_WITH_NULL_MD5 = { 0, 1 } CIPHER SUITE CODES USED

IN SSL MESSAGES
SSL_RSA_WITH_NULL_SHA = { 0, 2 }
SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0, 3 }
SSL_RSA_WITH_RC4_128_MD5 = { 0, 4 }
SSL_RSA_WITH_RC4_128_SHA = { 0, 5 }
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0, 6 }
SSL_RSA_WITH_IDEA_CBC_SHA = { 0, 7 }
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0, 8 }
SSL_RSA_WITH_DES_CBC_SHA = { 0, 9 }
SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0, 10 }

29
Block vs. Stream Ciphers NETWORKS

 A stream cipher operates on individual bits or bytes, and the

actual transformation varies during the encryption process.
 Example: RC4 (key size: USA domestic unlimited, international limited to 40 bit).
Used also in WiFi (802.11).
 A block cipher operates on fixed-length groups of bits (i.e.,
blocks) with an unvarying transformation (determined by the
key).
 Examples: DES (64 bit), 3DES (192 bit), AES (key size: 128,192,256,
block size: 128)
 Modes: electronic code book (ECB), cipher block chaining (CBC), cipher feedback
(CFB), output feedback (OFB).
 Block ciphers require less computation resources, less vulnerable,
less convenient to use.
Need add of padding at the last block and require initialization
vector at the beginning of the encryption process.

30
ClientHello Message Structure NETWORKS

31
Server Hello NETWORKS

 Version
 SSLv3(major=3, minor=0)
 TLS (major=3, minor=1

 Random Number
 32 byte random number, protects against handshake replay

 Session ID
 Provided to the client for later resumption of the session

 Cipher suite
 Usually picks client’s best preference – No obligation

 Compression method
 Null

32
ServerHello Message Structure NETWORKS

33
Certificates NETWORKS

X.509 Certificate associates public key with identity

Certification Authority (CA) creates certificate
 Adheres to policies and verifies identity
 Signs certificate
User of Certificate must ensure it is valid
A Public Key Certificate compromises at least 3 types of
information:
 A Public Key
 Naming Information
 Digital Signature
CA types: Private (private network, corporate) or Public
34
X.509: Certificate Content (ASN.1 DER format) NETWORKS

Version (X.509 version, e.g. 3)

Serial Number (integer)
Signature Algorithm Identifier
 Object Identifier (OID) of the algorithm used to digitally sign the
certificate
 e.g. sha1RSA: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-
1(1) sha1-with-rsa-signature(5)}
Issuer (CA) X.500 name
 Identifies the organization issued this certificate (see later slide)
Validity Period (Start,End)

35
X.509: Certificate Content (Cont.) NETWORKS

Subject X.500 name (Owner)

 Same format as Issuer, see next slide
Subject Public Key
 Algorithm Id (OID)
 Algorithm parameters
 Public key Value

IssuerUnique Id (enables several id’s to same issuer)

Subject Unique Id (several id’s to same subject)
Extensions
 Optional (used by browsers)
CA digital Signature
 Digital signature of the content of the certificate with CA private key
This signature shall be verified by the user using the CA public key
36
Digital Signature principle NETWORKS

• The signatory’s private key is used to encrypt a message (or its

hash value).
• The RSA signature is generated for that particular message.
• The sender public key is used to successfully decrypt the
signature, proving that only someone possessing the private key
could have created it.

37
Digital Signature in Action (e.g. certificate verification) NETWORKS

Sender side:

Receiver side:

38
Issuer and Subject Name format NETWORKS

 Name Attributes (Distinguished Name) by Object Identifier

(OID):
 countryName::= SEQUENCE{{2.5.4.6}. StringType(size(2))}
 organization::= SEQUENCE{{2.5.4.10}. StringType(size(1..64))}
 localityName ::= SEQUENCE{{2.5.4.7}. StringType(size(1..64))}
 stateOrProvince ::= SEQUENCE{{2.5.4.8}. StringType(size(1..64))}
 commonName ::= SEQUENCE{{2.5.4.3}. StringType(size(1..64))}

 Distinguished Name (DN) user format:

 Country at highest level (e.g. US)
 Organization typically at next level (e.g. CertCo)
 Individual below (e.g. Common Name “Elizabeth”)
Dn={
* C=US
* O=CertCo
* CN=Elizabeth} 39
Certificate Message Structure NETWORKS

40
Validating a Certificate NETWORKS

Must recognize accepted CA in certificate chain

 One CA may issue certificate for another CA
Must verify that certificate has not been revoked
 CA publishes Certificate Revocation List (CRL)

41
 SSL Messages - reminder
NETWORKS

CLIENT SIDE SERVER SIDE

OFFER CIPHER SUITE SELECT A CIPHER SUITE
MENU TO SERVER
SEND CERTIFICATE AND
CHAIN TO CA ROOT

SEND PUBLIC KEY TO

ENCRYPT SYMM KEY

SEND ENCRYPTED SERVER NEGOTIATION

SYMMETRIC KEY FINISHED

ACTIVATE
ENCRYPTION
CLIENT PORTION ( SERVER CHECKS OPTIONS )
DONE ACTIVATESERVER
ENCRYPTION
( CLIENT CHECKS OPTIONS ) SERVER PORTION
DONE
NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION

42
Client Key Exchange - Assymetric encryption of Client Premaster secret NETWORKS

Premaster secret
 Created by client; used to “seed” calculation of encryption
parameters
 RSA: 2 bytes of SSL version + 46 random bytes
 D.H.: Special algorithm
 Sent encrypted to server using server’s public key

43
ClientKeyExchange Message Structure (RSA) NETWORKS

For RSA key exchange, the premaster secret is simply 2 bytes

for the version of ssl the client supports (3 and 1, for TLS version 1.0) followed
by 46 securely generated random bytes (encrypted with the public key).
44
SSL Encryption
NETWORKS

 Master secret
Generated by both parties from premaster secret and
random values generated by both client and server
 Key material
Generated from the master secret and shared random
values
 Encryption keys
Extracted from the key material

45
SSL/TLS Master Secret Generation (using premaster secret) NETWORKS

46
TLS Key materials generation NETWORKS

See next slide

47
TLS Pseudorandom function NETWORKS

48
Change Cipher Spec & Finished Messages NETWORKS

Change Cipher Spec

 Switch to newly negotiated algorithms and key material
Finished
 First message encrypted with new crypto parameters.
 Approval for successful negotiation.
 Digest (Hash) of negotiated master secret, the ensemble of handshake
messages, sender type (client/ server).
 If the receiver can not decrypt the message it closes the session

49
ChangeChiperSpec and Alert “Protocols” NETWORKS

CCS:

Alert:

50
Finished Message Structure NETWORKS

51
Application Data Message (Stream Cipher) Structure NETWORKS

52
 TLS connection states NETWORKS

Pending Active
Read Encr Key= Encr Key=
MAC= MAC=
Secret= Secret=
Write Encr Key= Encr Key=
MAC= MAC=
Secret= Secret=

• ServerHello changes Encryption key and MAC in Pending/Read

and Pending/Write states from null (or old) to new values in
both client and in server.
• ClientKeyExchange changes the Secret in Pending/Read
and Pending/Write states from null (or old) to new value in
both client and in server.
• Tx ChangeCipherSpec Moves Pending to Active in Write state
53
•
TLS connection states (cont.) NETWORKS

54
TLS connection states (cont.) NETWORKS

55
PKI NETWORKS

 PKI is as an infrastructure that can be used to issue,

validate, and revoke public keys and public key certificates.
(best defined in RFC 5280)
 PKI Functions
 Public key cryptography – Includes the generation, distribution,
administration, and control of cryptographic keys.
 Certificate issuance – Binds a public-key to an individual, organization, or
other entity.
 Certificate validation – Verifies that a trust relationship or binding exists and
that a certificate is still valid for specific operations.
 Certificate revocation – Cancels a previously issued certificate and either
publishes the cancellation to a Certificate Revocation List or enables an
Online Certificate Status Protocol process.

56
PKI standards - protocols NETWORKS

 RFC 5280 - X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile
 RFC 2585 - X.509 Public Key Infrastructure Operational Protocols: FTP and
HTTP
 RFC 2560 - X.509 Public Key Infrastructure Online Certificate Status Protocol
(OCSP) 
 RFC 4210 - X.509 Public Key Infrastructure Certificate Management Protocol
(CMP)
 Uses PKCS#7 and PKCS#10, maybe not deployed
 RSA PKCS #7 (RFC 2315)
Cryptographic message syntax standard
 RSA PKCS #10 V1.7 (RFC 2986) –
Certificate Request syntax standard
 IETF Draft-nourse-scep-20 –
Simple Certificate Enrollment Protocol
 RFC 4510- RFC 4521 Lightweight Directory Access Protocol (LDAP)
57
PKIX Architectural Model (from RFC 5280) NETWORKS

58
SCEP - Simple Certificate Enrollment Protocol NETWORKS

 SCEP: Simple Certificate Enrollment Protocol

 Draft-nourse-scep-20 (Cisco, expired June 2010)
 SCEP is a PKI communication protocol which leverages existing technology
by using PKCS#7, PKCS#10 and LDAP.
 SCEP is the evolution of the enrollment protocol developed by Verisign, Inc.
for Cisco Systems, Inc. It now enjoys wide support in both client and CA
implementations.
 SCEP supported by MS Win. Servers 2000-2003
 OpenSSL supports SCEP Client (network device) for Unix only (?)
 Network Device Enrollment Service (Win. Server 2008)
 Network Device Enrollment Service allows software on routers and other
network devices running without domain credentials to obtain certificates
based on SCEP.
 The protocol supports CA and RA public key distribution, certificate
enrollment, certificate revocation, certificate queries, and certificate revocation
queries
59
Changes from SSL 3.0 to TLS NETWORKS

 Fortezza algorithm removed in TLS

 Additional Alerts added
 Modification to hash calculations
 Different Master Secret & Key materials
calculations
 TLS Protocol version 3.1 in ClientHello and
ServerHello (SSL last version is 3.0)
 Separate Cipher Suites codes
60
TLS version 1.1 enhancements NETWORKS

 Added protection against Cipher block chaining (CBC) attacks.

 The implicit Initialization Vector (IV) was replaced with an explicit
IV.
 Change in handling padding errors
 Support for IANA registration of parameters

61
TLS version 1.2 enhancements NETWORKS

 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.
 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.
 Expansion of support for authenticated encryption ciphers, used
mainly for Galois/Counter Mode (GCM) and CCM mode of AES
encryption.
 TLS Extensions definition and Advanced Encryption Standard (AES)
CipherSuites were added.

62
 NETWORKS

Thank You