Secure Socket Layer (TLS)

Carlo U. Nicola, SGI FHNW

With extracts from publications of :

William Stallings.

AS HS13 2

Crypto building blocks

AS HS13 3

1. , run a key-exchange protocol that establishes an

, between

and .

2. This is used together with a

cryptographic functions to protect the

and/or of the transmitted data.

Abstraction: The secure channel

AS HS13 4

Network

layer Data

link

Physical

layer

LLC = Logical Link Control

MAC = Media Access Control

The real ”secure” channel

AS HS13 5

We will study the SSL protocol and in the meantime recapitulate

(or relearn) some important concepts like:

1. Hash function, hash value (MD5 (deprecated), SHA-XXX)

2. Symmetric encryption key (AES)

3. Asymmetric encryption key (RSA)

4. Digital signature

5. X.509 certificates

SSL as a playground for crypto tools

AS HS13 6

Where security hides in the TCP/IP protocol stack

AS HS13 7

SSL functionality

AS HS13 8

The differnt parts of the SSL protocol

AS HS13 9

SSL(TLS) over TCP over IP

AS HS13 10

! Netscape Secure Socket Layer;

! Layered between the application and TCP;

! Server authenticated with public keys (X509);

! Can authenticate client (rare);

! Privacy enforced by encryption;

! Integrity enforced by MACs;

! Works with any TCP application (but mainly http):

Service port

SSL characteristics

AS HS13 11

SSL provides end to end security, based on a communication protocol.

The different protocols implemented by SSL:

1. Handshake

2. Record

3. Change cipher specifications

4. Alert services

The record protocol specifies how the data are encrypted.

SSL(TLS) protocols

AS HS13 12

The most complex and unsecure part of SSL:

a) Allows the server and client (optional) to authenticate each other.

b) Negotiate encryption, MAC (Message Authentication Code) algorithm

and cryptographic keys.

c) Used before any application data are transmitted.

Handshake protocol

AS HS13 13

Client : Hello, here is a list of cipher suites I can use.

Server: Hello, here is the cipher suite I chose from your list. And

here's an X.509v3 certificate that contains my public RSA

key.

Client : [Scrutinises the certificate, checks to make sure it's signed

by a known certificate authority.] Okay, thanks. Here's the

pre-master secret, encrypted with your public key. The next

thing I say to you will be encrypted with the session key.

Client : [Encrypted] I'm done with the handshake.

Server: [Decrypts the pre-master secret using private key, then

generates the session key.] The next thing I send will be

encrypted.

Server: [Encrypted] I'm done with the handshake too.

Handshake protocol action: the palatable version.

AS HS13 14

(i) The client initiates the connection to the server and tells the server which

SSL cipher suites the client supports.

(ii) The server responds with the cipher suites that it supports.

(iii) The server sends the client a certificate that should authenticate it.

(iv) The server initiate a session key exchange algorithm, based in part on the

information contained in the certificate it has just sent, and sends the

necessary key exchange information to the client.

(v) The client completes the key exchange algorithm and sends the

necessary key exchange information to the server. Along the way, it

verifies the certificate.

(vi) Based on the type of key exchange algorithm (that in turn is based on the

type of key in the server’s certificate), the client selects an appropriate

cipher suite and tells the server which suite it wishes to use.

(vii) The server makes a final decision as to which cipher suite to use.

SSL protocol basic handshake features

AS HS13 15

Negotiate cryptographic specifications:

-- includes session id and nonce (random number)

-- key exchange -- RSA, Diffie-Hellmann, Fortezza (IBM proprietary alg.)

-- cipher -- RC2, RC4, DES, 3DES, DES40, IDEA, Fortezza, AES

-- hash -- MD5, SHA-1

Authenticate server (optionally and rarely the client):

-- server sends its public key certificate

-- or anonymous DH (option)

-- client verifies server certificates with CA certificate

Establish session key/IV (Initial Vectors):

-- optional client authentication

-- client sends premaster secret encrypted with server's pub key

-- client/server calculate master secret, keys, IVs

Send change cipher message.

Send encrypted finish message.

Handshake protocol crypto details

AS HS13 16

Handshake protocol global view

AS HS13 17

Client Server

Handshake:

(offer of supported cipher clusters, represented as two-byte codes; the client is offering different combinations of signing algorithms, digest algorithms, and so on)

(4 bytes GMT + 28 bytes random)

3. version

(first time through client leaves this blank)

(the only one defined is null...)

Handshake:

(contains essentially the same fields as the message.

Server fills in , for uses we'll see shortly.

What's in are the algorithms the

client and server will actually use--i.e., the server

decides)

Handshake:Certificate (here's my X.509 certificate;

see the example below) Handshake:

of server

of client

Handshake protocol gritty details (1)

AS HS13 18

Client Server Handshake:

(client selects (= two bytes designating

version + 46 of random bytes, encrypts with sender's public

key (having verified the server's certificate and extracted the

key) and sends; each side now turns the

into the , and then

to turn the into a set of session keys; see

below for further details)

(my next message will use the encryptions we agreed on)

Handshake:

1. the client now sends a digest of all its previous messages so the server can verify the integrity of the messages received; the point is to prevent the possibility of an attacker injecting bogus handshake messages

2. in the case of SSLv3, the contents of the Finished message are an MD5 hash followed by a SHA-1 hash; here's how the MD5 hash is produced:

(my next message will

use the encryptions we agreed on) Handshake: (here's a digest of

what I just said)

Handshake protocol gritty details (2)

AS HS13 19

Client Server

(blah blah blah)

ApplicationData (yak yak yak)

Alert: warning, (the point of

which is to prevent truncation attack, i.e.,

attacker inserting a premature (they can't

insert a bogus because of the

integrity checks built into SSL))

Alert: , of

of

Handshake protocol gritty details (3)

AS HS13 20

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

SERVER’S PUBLIC KEY

IS SENT BY SERVER IN

ServerKeyExchange

CLIENT GENERATES THE

PREMASTER SECRET

ENCRYPTS WITH PUBLIC

KEY OF SERVER

CLIENT SENDS PREMASTER

SECRET IN ClientKeyExchange

SENT BY CLIENT

IN ClientHello

SENT BY SERVER

IN ServerHello

MASTER SECRET IS 3 MD5

HASHES CONCATENATED

TOGETHER = 384 BITS

Generating the Master Secret

AS HS13 21

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

JUST LIKE FORMING

THE MASTER SECRET

EXCEPT THE MASTER

SECRET IS USED HERE

INSTEAD OF THE

PREMASTER SECRET

. . .

Generation of key material

AS HS13 22

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

SECRET VALUES

INCLUDED IN MESSAGE

AUTHENTICATION CODES

INITIALIZATION VECTORS

FOR DES CBC ENCRYPTION

SYMMETRIC KEYS

Obtaining keys from the key material

AS HS13 23

1. Provides confidentiality and integrity.

2. Fragments message ( 214 bytes).

3. Optional compression (default: none).

4. Calculates MAC (Message Authentication Code = integrity). MAC

traditionally is based on symmetric block cipher, i.e. MAC = CK(M) where

M is the message, MAC a fixed length authenticator, K a secret

symmetric key shared between sender and receiver and C(.) a function.

5. Modified H(Hash)MAC to include sequence number (prevent replay

attacks).

6. Encrypts both message and MAC (confidentiality+integrity).

7. Propend header.

Record protocol

AS HS13 24

· 214 Bytes

= 16 KB

SSL Record Protocol Operation

AS HS13 25

2003: 3 2004: 1 Higher level

protocol used Length in Bytes of plaintext

or compressed fragment

SSL Record Format

AS HS13 26

¸

One of 10 messages, e.g.:

Parameters

Warning (1) or fatal (2)

Specifies alert

Always 1:

pending state →current

¸

SSL remaining protocols

AS HS13 27

RFC 2246 standard for SSLv3.1: ! contains only non patented technology (no IBM KEA/FORTEZZA)

! standard HMAC functions:

H = embedded hash function (for TLS, either MD5 or SHA-1)

M = message input to HMAC

K+ = secret key padded with zeros until the block length of hash code is

reached

ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits)

opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits)

! No weak cryptography for export

! Good PRF (pseudo random function) for random bit expansion

! Newer cryptographic algorithms (SHA-1/2/3, AES, …)

TLS enhancements: TLS 1.0 (1)

AS HS13 28

Differences in the:

– version number

– message authentication code

– pseudorandom function (PRF)

– alert codes

– cipher suites

– client certificate types

– certificate_verify and finished message

– cryptographic computations

– padding

Otherwise similar to SSL v3.1. Important: the same record format as the

SSL record.

Vaudeney (EPFL): TLS/1.0 is unsafe ! Production use: TLS 1.1 or better

TLS 1.2

TLS enhancements: TLS 1.0 (2)

AS HS13 29

Defined in RFC 4346 in April 2006. Significant differences in this version

include:

1. Added protection against Cipher block chaining ( ) attacks.

2. The implicit Initialization Vector ( ) was replaced with an explicit .

3. Change in handling of padding errors.

4. Support for IANA registration of parameters i.e. canonical bites’ codes for

Internet’s commands, protocols, algorithms etc. Examples:

Random IV via PRF

Each block has a

new IV field.

TLS enhancements: TLS 1.1

AS HS13 30

TLS 1.2 was defined in RFC 5246 in August 2008. Major differences include:

1. The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use PRFs specified in the cipher-suite.

2. The same combination in the message hash was replaced with SHA-256, with an option to use hash algorithms specified in the cipher-suite.

3. The same combination in the digitally-signed element was replaced with a single hash negotiated during handshake, defaults to SHA-1.

4. Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept.

5. Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption.

6. TLS Extensions definition and Advanced Encryption Standard CipherSuites were added.

7. TLS 1.2 was further refined in RFC 6176 in March 2011 redacting its backward compatibility with SSL such that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

TLS enhancements: TLS 1.2

AS HS13 31

1. Hashing and symmetric key ciphers are fast: use them for session

encryption.

2. RSA public key is slow, but it is useful for key exchange and user/server

authentication

3. Informal web of trust of PGP (you are in charge) versus CA based (you do

not know, who controls it: in fact the NSA controls it (note added in 2013))

4. A good protocol should:

1. negotiate cryptographic parameters

2. establish shared secret

3. authenticate endpoints

5. Use ssh, pgp liberally as the crypto part of an application.

6. SSL: a transport interface, but you still needs to modify the application (http

https, telnet ssltelnet, ...)

7. IPsec places cryptography where it belongs: at the network layer.

Words to the wise about applied cryptography

AS HS13 32

SSL and Java applications

AS HS13 33

Datagram (dg) = Internet data packet, which consists of: ! Header: accounting info (e.g., sequence #, src port and dest port)

! Payload: the data itself.

Internet data are a stream of dg. Questions:

How to split dg? How to reassemble dg? How to track packets’ arrival?

How to parse dg?

All this is handled by sockets. A socket is a descriptor that lets an application read/write from/to the network.

Socket is a Berkeley Unix innovation that treat network connection as yet another

byte stream, e.g., a file.

Clients and servers communicate with each other by reading from and writing

to socket descriptors.

The main difference between file I/O and socket I/O is how the application “opens” the socket descriptors.

! Example: Linux uses the same abstraction for both file I/O and network I/O.

! Example: Linux uses regular read and write I/O functions.

A fast intro to socket

AS HS13 34

and classes : connection between two hosts. Can

do

the following:

(i) bind to a port

(ii) connect to remote machine

(iii) send data

(iv) receive data

(v) close connection

(vi) listen for incoming data

(vii) accept connections from remote machines on background port

Socket basics in Java

AS HS13 35

1. Program create new socket with different constructors (see

DS) ;

2. Socket tries connecting to remote host;

3. After the connection is established, local and remote hosts get input and

output streams from socket, which are used to send data to each other.

Connection is full-duplex (both hosts can send and receive data

simultaneously). The protocol ( , , ) determines the data's

meaning.

4. When done, connection is closed by one or both hosts.

Normal use of Java class

AS HS13 36

Set of API to construct SSL-Client and SSL-Server sockets.

Two important new concepts: trust store and key store. Both are databases

that hold certificates. Key store are used to provide credentials; trust store to

verify them.

Example:

(i) Servers use key stores to obtain certificates they present to clients;

(ii) Clients use trust stores to obtain root certificates to verify the server’s

certificate.

Java SSL software (JSSE)

AS HS13 37

Java ¸ 1.6 class diagram for SSL-sockets

AS HS13 38

Java provides abstract classes for the SSL package. ,

and others offer concrete implementations (providers) of these classes.

Example: Sun JSSE provider:

1. SSL 2.0 and 3.1, TLS 1.2

2. See table for encryption methods

3. Checks for X.509 certificates

4. Certificates tree verification

5. Java Key Store (jks format) 6. Java ¸ 4 AES support

I recommend strongly to use open source implementations of these classes.

A good link:

Providers

AS HS13 39

Set of ciphers after FIPS SSL_RSA_WITH_DES_CBC_SHA (hex number 0009)

SSL_RSA_FIPS_WITH_DES_CBC_SHA (hex number FEFE)

SSL_RSA_WITH_3DES_EDE_CBC_SHA (hex number 000A)

SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (hex number FEFF)

SSL_RSA_WITH_AES_128_CBC_SHA (hex number 002F)

SSL_RSA_WITH_AES_256_CBC_SHA (hex number 0035)

SSL_DHE_RSA_WITH_AES_128_CBC_SHA (hex number 0033)

SSL_DHE_RSA_WITH_AES_256_CBC_SHA (hex number 0039)

SSL_DHE_RSA_WITH_DES_CBC_SHA (hex number 0015)

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (hex number 0016)

SSL_DHE_DSS_WITH_AES_128_CBC_SHA (hex number 0032)

SSL_DHE_DSS_WITH_AES_256_CBC_SHA (hex number 0038)

SSL_DHE_DSS_WITH_DES_CBC_SHA (hex number 0012)

SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA (hex number 0062)

SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (hex number 0008)

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (hex number 0014)

SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (hex number 0063)

SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (hex number 0011)

SSL_DH_anon_WITH_AES_128_CBC_SHA (hex number 0034)

SSL_DH_anon_WITH_AES_256_CBC_SHA (hex number 003A)

SSL_DH_anon_WITH_DES_CBC_SHA (hex number 001A)

SSL_DH_anon_WITH_3DES_EDE_CBC_SHA (hex number 001B)

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA (hex number 0019)

AS HS13 40

The processes the data contained in the buffer, or any

handshaking

data, to produce SSL/TLS encoded data and places it the network buffer

supplied by the application. The application is then responsible for using an

appropriate transport (shown on the right) to send the contents of the

network buffer to its peer. Upon receiving SSL/TLS encoded data from its peer

(via the transport), the application places the data into a network buffer and

passes it to . The processes the network buffer's

contents to produce handshaking data or application data.

Java ¸ 1.5: non blocking

AS HS13 41

Every X.509 certificate consists of two sections: (i) data and (ii) signature.

The data section includes the following information:

1. The version number of the X.509 standard supported by the certificate.

2. The certificate's serial number. Every certificate issued by a CA has a serial

number that is unique to the certificates issued by that CA.

3. Information about the user's public key, including the algorithm used and a

representation of the key itself.

4. The DN of the CA that issued the certificate.

5. The period during which the certificate is valid (for example, between 1:00

p.m. on January 1, 2000 and 1:00 p.m. December 31, 2000).

6. The DN of the certificate subject (for example, in a client SSL certificate this

would be the user's DN), also called the subject name.

7. Optional certificate extensions, which may provide additional data used by

the client or server. For example, the certificate type extension indicates the

type of certificate - that is, whether it is a client SSL certificate, a server SSL

certificate, a certificate for signing email, and so on. Certificate extensions can

also be used for a variety of other purposes.

X.509 certificate (1)

AS HS13 42

The signature section includes:

1. The cryptographic algorithm, or cipher, used by the issuing certificate

authority (CA) to create its own digital signature.

2. The CA's digital signature, obtained by hashing all of the data in the

certificate together and encrypting it with the CA's private key.

X.509 certificate (2)

AS HS13 43

Webserver verification of client's certificate

AS HS13 44

Client verification of server's certificate

AS HS13 45

The chain, or path, begins with the certificate of that entity, and each

certificate in the chain is signed by the entity identified by the next certificate

in the chain. The chain terminates with a root CA certificate. The root CA

certificate is always signed by the CA itself.

Certification path

AS HS13 46

Look contents of cacerts in:

Verisign, Thawte CA Date

MD5-hash of cert

trust degree given

by user

Certificates and keys administration

AS HS13 47

Private and public key + autosigned certificate

Encryption algorithm

Default name of keystore in $HOME directory.

Other options:

: Size in bits of key. Default 1024 bits. : Signature algorithm. Default: SHA1withDSA

: No of day the certificate is valid. Default 90 days.

Key pair generation (1)

AS HS13 48

Key pair generation (2)

AS HS13 49

List contents of keystore

AS HS13 50

Export:

Import it into your trusted :

Export and trust an autosigned certificate (1)

AS HS13 51

Examine it in your trusted :

Export and trust an autosigned certificate (2)

AS HS13 52

You want to get Verisign to authenticate your certificate

(it costs money). First step:

You get a file formatted with the standard:

Preparation for a Verisign certificate

AS HS13 53

A ”secure” Webserver in Java (1)

AS HS13 54

A secure Webserver in Java (2)

AS HS13 55

The password to is passed in clear text as argument.

Pseudo solutions:

(i) Use without password but restrict access permissions to it.

(ii) Use JCEKS ( ). is now encrypted, but to

open it, you need a password. Where is it hidden? Sun proposal:

The password to is passed

in clear text within the

code!

A secure Webserver: the problem

AS HS13 56

Stephen Thomas: SSL and TLS Essentials, John Wiley, 2003.

RFC on TLS 1.1, 1.2:

Analysis of SSL Security:

SSL Timing Attack:

Vaudenay paper can be found at:

Bibliography