Secure Socket Layer

Carlo U. Nicola, SGI FHNW

With extracts from publications of :

William Stallings.

NS HS13 2

Abstraction: Crypto building blocks

NS HS13 3

Abstraction: The secure channel

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.

NS HS13 4

The real ”secure” channel

Network

layer

Physical

layer

LLC = Logical Link Control

MAC = Media Access Control

Data

link

NS HS13 5

We will study the SSL protocol and in the meantime recapitulate (or relearn)

some important concepts like:

1. Hash function, hash value (SHA-1/2/3)

2. Symmetric encryption key (AES)

3. Asymmetric encryption key (RSA)

4. Digital signature

5. X.509 certificates

SSL as a playground for crypto tools

NS HS13 6

Where hides security in the TCP/IP protocol stack?

NS HS13 7

SSL functionality

NS HS13 8

The different parts of the SSL protocol

NS HS13 9

SSL(TLS) over TCP over IP

NS 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

NS HS13 11

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

SSL protocols:

1. Handshake

2. Record

3. Change cipher specifications

4. Alert services

The record part provides how encrypted data are transported to the application

(via http) and other protocols

SSL(TLS) protocols

NS HS13 12

The most complex part of SSL:

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

2. Negotiate encryption, MAC algorithm and cryptographic keys.

3. Used before any application data are transmitted.

Handshake protocol

NS 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.

NS 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

NS 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

NS HS13 16

Handshake protocol global view

NS HS13 17

Client Server

Handshake: ClientHello

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

2. random (4 bytes GMT + 28 bytes random)

3. version

4. session_id (first time through client leaves this blank)

5. compression_method (the only one defined is null...)

Handshake:

(contains essentially the same fields as the message.

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

What's in cipher_suite 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)

NS HS13 18

Client Server

Handshake:

(client selects pre_master_secret (= two bytes designating

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

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

key) and sends; each side now turns the

pre_master_secret into the master_secret, and then

to turn the master_secret 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: Finished (here's a digest of

what I just said)

Handshake protocol gritty details (2)

NS 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)

NS HS13 20

Generating the Master Secret

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

SERVER’S PUBLIC KEY

IS SENT BY SERVER IN

CLIENT GENERATES THE

PREMASTER SECRET

ENCRYPTS WITH PUBLIC

KEY OF SERVER

CLIENT SENDS PREMASTER

SECRET IN

SENT BY CLIENT

IN

SENT BY SERVER

IN

MASTER SECRET IS 3 MD5

HASHES CONCATENATED

TOGETHER = 384 BITS

TLS 1.2 : MD5 and SHA-1

replaced by SHA-256

NS HS13 21

Generation of key material

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

JUST LIKE FORMING

THE MASTER SECRET

EXCEPT THE MASTER

SECRET IS USED HERE

INSTEAD OF THE

PREMASTER SECRET

. . .

NS 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

NS 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

NS HS13 24

· 214 Bytes

= 16 KB

SSL Record Protocol Operation

NS HS13 25

2003: 3 2004: 1 Higher level

protocol used Length in Bytes of plaintext

or compressed fragment

SSL Record Format

NS HS13 26

¸

One of 10 messages, e.g.:

Parameters

Warning (1) or fatal (2)

Specifies alert

Always 1:

pending state →current

¸

SSL remaining protocols

NS 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)

NS 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)

NS 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

NS 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

NS 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: DigiNotar (NL) 2011, NSA 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

NS HS13 32

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

NS HS13 33

OpenSSL is a sort of reference implementation consisting of:

1. SSL software library: To develop SSL based applications like

2. Tools ( ) to create certificates with your own CA (Certification

Authority). Some options:

: key generation

: verify certificates

: convert keys

: certificates’ management

: generates signing certificate request CSR

OpenSSL software (1)

NS HS13 34

3. Generates random numbers: ! mix with MD5 of data in

! Windows: hash of screen

! add randomness on each connect()

! save/restore from rand file

4. Generates big prime numbers: ! quick sieve (2048)

! MillerRabin

5. Arithmetic with big integer

OpenSSL software (2)

NS HS13 35

Secure message protocol:

1. TCP stream only

2. RSA, DiffieHellman + legacy

3. Key exchange and authentication

4. Message integrity (MD2, MD5, SHA-1)

5. Encryption (DES, IDEA, RSA, AES, RC4)

6. (Weak) random numbers

7. Reference implementations available

OpenSSL library

NS HS13 36

OpenSSL client

NS HS13 37

OpenSSL server

NS HS13 38

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)

NS HS13 39

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)

NS HS13 40

Client verification of server's certificate

NS HS13 41

Webserver verification of client's certificate

NS HS13 42

1. Create a random string: (write 128 random bytes of base64-encoded data to stdout)

2. Generate public/private key:

3. Generate certificate signing request (CSR):

4. Email to CA, or selfsign:

OpenSSL key generation for CA

NS HS13 43

In OpenSSL directory start :

1. Creates a CA.

2. has CA policies: dictates which certificate’s fields are

mandatory, the cert lifetime, which algorithms are to be used.)

3. Generates certificate requests .

4. Signs CSR.

5. Generates CRL (Certificates’ Revocation List).

6. Uses PEMencoded certificates (not PKCS#12).

7. For secure web server, real CA certificate -- $400/year (Verisign)

Your own CA

NS HS13 44

NS HS13 45

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

NS HS13 46

Appendix: Java certificates

NS HS13 47

Look contents of cacerts in:

Verisign, Thawte CA Date

MD5-hash of cert

trust degree given

by user

Certificates and keys administration (Java)

NS HS13 48

Private and public key + autosigned certificate

Encryption algorithm

Default name of keystore in

directory.

Other options:

: Size in bits of key. Default 1024 bits.

: Signature algorithm. Default:

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

Key pair generation (1)

NS HS13 49

Key pair generation (2)

NS HS13 50

List contents of keystore

NS HS13 51

Export:

Import it into your trusted :

Export and trust an autosigned certificate (1)

NS HS13 52

Examine it in your trusted .cuntruststore:

Export and trust an autosigned certificate (2)

NS HS13 53

You want to get Verisign to authenticate your certificate

(it costs money). First step:

You get a file cuncert.crq formatted with the MIME64 standard:

Preparation for a Verisign certificate