CPSC6128 - Network Security 1 Network Security CPSC6128 – Lecture 7 IKE/SSL VPNs

CPSC6128 - Network Security 1

Network SecurityCPSC6128 – Lecture 7

IKE/SSL VPNs

CPSC6128- Network Security

IKE

2

CPSC6128- Network Security 3

Internet Key Exchange In previous examples, we manually established IPsec

SAs in IPsec endpoints

Example SASPI: 12345Source IP: 192.168.1.100Dest IP: 192.168.2.100 Protocol: ESPEncryption algorithm: 3DESHMAC algorithm: SHA-1Encryption key: 0x7f5c146b…HMAC key: 0x9a01d45….

IKE is used to establish SAs automatically: SPI number, protocol, algorithms, & keysAlso provides mutual authentication


IKE more (2)

lots of flexibility & optionsaccommodating everyoneSSL handshake has less flexibility and complication

From Kaufman, Perlman, Speciner: “IKE took many years to come out of IETF. The original

contenders…would have been just fine in practice. But due to committee politics, neither one was chosen and instead IKE/ISAKMP emerged, almost a decade after the work began, with a protocol so complex and a specification so incomprehensible that nobody had the patience to understand what was being decided upon, and so nobody had objections. The result had lots of ambiguities and flaws, although the world did manage to have interoperable implementations…”


IKE more (3)

Authentication (proof who you are) with eitherpre-shared key (PSK) or PKI (pubic/private keys and certificates)

With PSKboth sides start with PSKrun IKE to authenticate each other and obtain IPsec SAs, including session keys

With PKIboth sides start with public/private key pair and

certificatesrun IKE to authenticate each other and obtain IPsec SAs (normally one in each direction)Racoon in lab


IKE more (4)IKE has two phases

Phase 1: Establish bi-directional IKE SANote: IKE SA different from IPsec SAUse Diffie Hellman to generate a shared key

Phase 2:the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec

Phase 1 has two modesAggressive mode

uses fewer messagesNo identity protection

Main mode provides identity protection (encrypts certificates) and is more flexible

http://en.wikipedia.org/wiki/IPsec


Recall: Diffie-HellmanAllows two entities to agree on shared key

But does not provide encryptionp is a large prime; g is a number less than p.

p and g are made publicAlice and Bob each separately choose 512-bit

random numbers, SA and SB.the private keys

Alice and Bob compute public keys:TA = gS

A mod p ; TB = gSB mod p ;


Diffie-Helman (2)Alice and Bob exchange TA and TB

Alice computes (TB)SA mod p

Bob computes (TA)SB mod p

shared secret: S = (TB)SA = (TA)SB = gSASB mod p

Even though Trudy might sniff TB and TA , Trudy cannot easily determine S.


IKE Phase 1: example with main mode and PSK

use slide 103

IKE can be done in 8 different ways; see Kaufman et al. this is just 1 way.

Nonces for replay attack

Note neither user’s identity is revealed to sniffer

crypto proposal for IKE SA

crypto proposal accepted

ga mod p, nonceA

gb mod p, nonceB

K {“Alice,” HMAC(exchanged data, PSK)}

compute K =f(gab mod p, nonceA, nonceB)

K {“Bob,” HMAC(exchanged data, PSK)}


IKE: Phase 2IKE SA now in place

provides encrypted, authenticated channelPhase 2 takes place over this secured channel

Goal is to establish IPsec SAs

Alice & Bob negotiate crypto algorithms for IPsec SA

Alice sends SPIA to Bob and Bob sends SPIB to Alice

Both sides compute keys for IPsec SAFunction of IKE SA key and nonces


IKE Overview (Again)

Threat Mitigation

Denial of Service

Replay

Man in Middle

Perfect Forward Secrecy (PFS)

11


Perfect Forward SecrecyIf a key is compromised

only the specific session it protected will be revealed to an attackerThe security of previous or future encrypted sessions is not affected

Keys are securely deleted after use Without these keys, there is no way that cipher text captured can be

decrypted

It is actually computational forward secrecy

12


IKE OverviewA hybrid protocol

that uses part Oakley and SKEME inside ISAKMP frameworkused to establish a shared security policy, and authenticated keys for services

Combination ofISAKMP

Internet Security Association and Key Management Protocola protocol to establish framework authentication and key exchangeRFC 2408

SKEMEa key exchange technique that provides anonymity, reputability, and quick key refreshment

OakleyOakley Key Determination ProtocolDescribe a series of key exchangeRFC 2412

13


ISAKMPDefines procedures and packet formats

to establish, negotiate, modify or delete security associations

Defines payloads for exchanging key generation and authentication data

ISAKMP message consists of header followed by one or more payloads

Implementations must support UDP for the transport protocol

14


ISAKMP

15


ISAKMP Header

16

Each payload begins with the following generic payload header:


ISAKMP PayloadsSA payload

used to begin establishment of SAProposal Payload

Protocol, SPI and transformTransform payloadKey exchange payloadIdentification payloadCertificate payloadHash payloadSignature payloadNonce payloadNotification payload

error or status messagesDelete payload

17


ISAKMP Message Example

18


Oakley

Oakley is a refinement of Diffie-Hellman Uses cookies to thwart Denial-of-Service attacks

Enables two parties to negotiate groupglobal parameters of Diffie-Hellman

Uses nonce's to protect against replay attacks

Enables exchange of Diffie-Hellman public key values

Authenticates Diffie-Hellman exchange to thwart man-in-the-middle attack

19


Oakley ---How Cookie Exchange thwart DoS attack

An attacker can forge source address and force victim to do numerous Diffie-Hellman exponentiations which can overwhelm it

Cookie exchange requires that each side send a pseudo-random number, the cookie, in the initial message

If source address forged, attacker does not get victim’s cookie and hence cannot proceed

Diffie-Hellman exponentiation done only after successful cookie exchange

20


Oakley – Cookie GenerationCookie generation must satisfy the following:

Cookie must depend on specific partiesOnly issuing entity must be able to generate cookies that are accepted by

itCookie generation and verification methods must be fast

Recommended method fast (MD5) hash of

source and destination IP addresssource and destination ports, and locally generated secret value

21


Oakley - AuthenticationMultiple methods of authentication supported

Digital Signaturesexchange is authenticated by signing mutually obtainable hashHash generated over important parameter like ID’s and nonces

Public-key encryptionExchange is authenticated by encrypting critical parameters with

sender’s private key

Symmetric-Key encryptionExchange is authenticated by encrypted symmetric key exchanged by

some out-of-band method

22


Five Steps of IPSec OperationInteresting Traffic

the VPN devices recognize the traffic to protectIKE Phase 1

The VPN devices negotiate an IKE security policy and establish a secure channel

IKE Phase 2 The VPN devices negotiate an IPSec security policy used to protect

the IPSec dataData Transfer

The VPN devices apply security services to traffic and then transmit the data

Tunnel terminated The tunnel is torn down

23


Step 1 – Interesting Traffic

24


Step 2 – IKE Phase 1

25


First and Second Exchange

IKE Policy Sets and Establishing a Shared Secret

Negotiates Matching IKE Transform sets to protect IKE exchange A DH exchange is performed to establish the shared secret

26


Third Exchange – Authenticate Peer Identity

Peer authentication methodsPre shared keysRSA SignaturesRSA Encrypted Nonces

27


Step 3 - IKE Phase 2

Negotiates IPSec security parametersIPSec transform setsEstablishes IPSec SAsPeriodically renegotiates IPSec SAs to ensure securityOptionally performs an additional DH exchange

28


IPSec Transform Sets

A transform set is a combination of algorithms and protocols that enact a security policy for traffic.

29


SAs

�Security Policy DBEncryption AlgorithmAuthentication AlgorithmModeKey Lifetime

30

• �SA DB-Destination IP-SPI-Protocol (ESP or AH)


SPI/SAs

31


Security Association Database (SAD)Endpoint holds state of its SAs in a SAD

where it can locate them during processing

With n endpoints, 2 + 2n SAs in R1’s SAD

When sending IPsec datagramR1 accesses SAD to determine how to process datagram

When IPsec datagram arrives to R2R2 examines

SPI in IPSec datagramindexes SAD with SPI, and processes accordingly

32


SA Lifetime

SA need to be changed periodically

The longer the SA is not changed the more vulnerable it becomes

Can be changed based on time or data transmitted

33


IPSec Sequence NumbersFor new SA, sender initializes seq# to 0

Each time datagram is sent to SA:Sender increments seq# counterPlaces value in seq# field

Goal is to prevent attacker from sniffing and replaying a packet

34


Step 4 – IPSec Session

SAs are exchanged between peersThe negotiated security services are applied to the traffic

35


Step 5 – Tunnel Termination

A tunnel is terminatedBy an SA lifetime timeoutIf the packet counter is exceeded

Removes IPsec SA36


Example: STEP 1 – IKE Phase 1 Policy

3.2.0.0/24

crypto isakmp policy 1 authentication pre-shared hash sha encr aes 128 group 2!crypto isakmp key 123 address 2.0.0.2

3.1.0.0/24

R1 R2

2.0.0.1/30

2.0.0.2/30

IPsec

crypto isakmp policy 1 authentication pre-shared hash sha encr aes 128 group 2!crypto isakmp key 123 address 2.0.0.1

IP

37


Example: STEP 2 – IKE Phase 2 Policy

3.2.0.0/24

crypto ipsec transform-set ts esp-aes 128 esp-sha-hmac!access-list 101 permit ip 3.1.0.0 0.0.0.255 3.2.0.0 0.0.0.255!crypto map cm 10 ipsec-isakmp set peer 2.0.0.2 match address 101 set transform-set ts

3.1.0.0/24

R1 R2

2.0.0.1/30

2.0.0.2/30

IPsec

crypto ipsec transform-set ts esp-aes 128 esp-sha-hmac!access-list 101 permit ip 3.2.0.0 0.0.0.255 3.1.0.0 0.0.0.255!crypto map cm 10 ipsec-isakmp set peer 2.0.0.1 match address 101 set transform-set ts

IP

38


STEP 3 – Applying the VPN PolicySite-2-Site Configuration

3.2.0.0/24

interface serial 1/0 ip address 2.0.0.1 255.255.255.0 crypto map cm!ip route 3.2.0.0 255.255.255.0 2.0.0.2

3.1.0.0/24

R1 R2

2.0.0.1/30

2.0.0.2/30

IPsec

interface serial 1/0 ip address 2.0.0.2 255.255.255.0 crypto map cm!ip route 3.1.0.0 255.255.255.0 2.0.0.1

IP

39


SSL

40


SSL: Secure Sockets LayerWidely deployed security protocol

Supported by almost all browsers and web servershttpsTens of billions $ spent per year over SSL

Originally designed by Netscape in 1993

Number of variations:TLS: transport layer security, RFC 2246

ProvidesConfidentialityIntegrityAuthentication

Original goals:Had Web e-commerce transactions in mindEncryption (especially credit-card numbers)Web-server authenticationOptional client authenticationMinimum hassle in doing business with new merchant

Available to all TCP applicationsSecure socket interface


SSL and TCP/IP

Application

TCP

IP

Normal Application

Application

SSL

TCP

IP

Application with SSL

SSL provides application programming interface (API) to

applications C and Java SSL libraries/classes readily

available


Could do something like PGP:

But want to send byte streams & interactive data Want a set of secret keys for the entire connection Want certificate exchange part of protocol:

handshake phase

H( ). KA( ).-

+

KA(H(m))-m

KA-

m

KS( ).

KB( ).+

+

KB(KS )+

KS

KB+

Internet

KS


Toy SSL: a simple secure channelHandshake:

Alice and Bob use their certificates and private keys to authenticate each other and exchange shared secret

Key Derivation: Alice and Bob use shared secret to derive set of keys

Data Transfer: Data to be transferred is broken up into a series of records

Connection Closure: Special messages to securely close connection


Toy: A simple handshake

MS = master secretEMS = encrypted master secret

hello

certificate

KB+(MS) = EMS


Toy: Key derivationIt is bad to use same key for more than one

cryptographic operationUse different keys for message authentication code (MAC) and encryption

Four keys:Kc = encryption key for data sent from client to serverMc = MAC key for data sent from client to serverKs = encryption key for data sent from server to clientMs = MAC key for data sent from server to client

Keys derived from key derivation function (KDF)Takes master secret and (possibly) some additional random data and

creates the keys


Recall MACm

ess

ag

e

H( )

s

mess

ag

e

mess

ag

es

H( )

compare

s = shared secret

Recall that HMAC is a standardized MAC algorithm SSL uses a variation of HMAC TLS uses HMAC


Toy: Data RecordsWhy not encrypt data in constant stream as we write it

to TCP?

Where would we put the MAC? If at end, no message integrity until all data processed

For example, with instant messaginghow can we do integrity check over all bytes sent before displaying?

Instead, break stream in series of records

Each record carries a MACReceiver can act on each record as it arrives

Issue

in record, receiver needs to distinguish MAC from dataWant to use variable-length records

length data MAC


Toy: Sequence NumbersAttack

Attacker can capture and replay record or re-order records

Solutionput sequence number into MAC:

MAC = MAC(Mx, sequence||data)Note: no sequence number field

Attacker could still replay all of the recordsSolution: Use random nonce


Toy: Control information

Truncation attack: attacker forges TCP connection close segmentOne or both sides thinks there is less data than there actually is

Solutionrecord types, with one type for closuretype 0 for data; type 1 for closure

MAC = MAC(Mx, sequence||type||data)

length

type data MAC


Toy SSL: summary

hello

certificate, nonce

KB+(MS) = EMS

type 0, seq 1, datatype 0, seq 2, data

type 0, seq 1, data

type 0, seq 3, datatype 1, seq 4, close

type 1, seq 2, close

en

crypte

d

bob.com


Toy SSL isn’t completeHow long are the fields?

What encryption protocols?

No negotiationAllow client and server to support different encryption algorithmsAllow client and server to choose together specific algorithm before

data transfer


Most common symmetric ciphers in SSLDES – Data Encryption Standard: block3DES – Triple strength: blockRC2 – Rivest Cipher 2: blockRC4 – Rivest Cipher 4: stream

Public key encryptionRSA


SSL Cipher SuiteCipher Suite

Public-key algorithmSymmetric encryption algorithmMAC algorithm

SSL supports a variety of cipher suites

Negotiation: client and server must agree on cipher suite

Client offers choice; server picks one


Real SSL: Handshake (1)

Purpose1. Server authentication2. Negotiation: agree on crypto algorithms3. Establish keys4. Client authentication (optional)


Real SSL: Handshake (2)1. Client

sends list of algorithms it supports, along with client nonce2. Server

chooses algorithms from list sends back: choice + certificate + server nonce

3. Client verifies certificate extracts server’s public key generates pre_master_secret encrypts with server’s public key sends to server

4. Client and server independently compute encryption and MAC keys from

pre_master_secret and nonces5. Client

sends a MAC of all the handshake messages6. Server

sends a MAC of all the handshake messages


Real SSL: Handshaking (3)

Last 2 steps protect handshake from tamperingClient

typically offers range of algorithms, some strong, some weakMan-in-the middle

could delete the stronger algorithms from listLast 2 steps prevent this

Last two messages are encrypted


Real SSL: Handshaking (4)Why the two random nonces?

Suppose Trudy sniffs all messages between Alice & Bob Next day

oTrudy sets up TCP connection with Bobosends the exact same sequence of records, including Alice’s certificate

Bob (Amazon) thinks Alice made two separate orders for the same thingSolution: Bob sends different random nonce for each connectionAnd since Trudy could also pretend to be Bob, she also sends a random

nonce


Handshake typesAll handshake messages (with SSL header) have 1

byte type field: TypesClientHelloServerHelloCertificateServerKeyExchangeCertificateRequestServerHelloDoneCertificateVerifyClientKeyExchangeFinished


SSL Record Protocol

data

data fragment

data fragment

MAC MAC

encrypteddata and MAC

encrypteddata and MAC

recordheader

recordheader

record header: content type; version; length

MAC: includes sequence number, MAC key Mx

Fragment: each SSL fragment 214 bytes (~16 Kbytes)


SSL Record Format

contenttype

SSL version length

MAC

data

1 byte 2 bytes 2 bytes

Data and MAC encrypted (symmetric algorithm)


Content types in record headerapplication_data (23)alert (21)

signaling errors during handshakehandshake (22)

initial handshake messages are carried in records of type “handshake”Hankshake messages in turn have their own “sub” types

change_cipher_spec (20)indicates change in encryption and authentication algorithms


handshake: ClientHello

handshake: ServerHello

handshake: Certificate

handshake: ServerHelloDone

handshake: ClientKeyExchangeChangeCipherSpec

handshake: Finished

ChangeCipherSpec

handshake: Finished

application_data

application_data

Alert: warning, close_notify

Real Connection

TCP Fin follow

Everythinghenceforth

is encrypted


Key derivationClient nonce, server nonce, and pre-master secret

input into pseudo random-number generatorProduces master secret

Master secret and new nonces inputted into another random-number generator: “key block”Because of resumption: TBD

Key block sliced and diced:client MAC keyserver MAC keyclient encryption keyserver encryption keyclient initialization vector (IV)server initialization vector (IV)


SSL PerformanceBig-number operations in public-key crypto are CPU

intensive

Server handshakeTypically over half SSL handshake CPU time goes to RSA

decryption of the encrypted pre_master_secret

Client shakePublic key encryption is less expensiveServer is handshake bottleneck

Data transferSymmetric encryptionMAC calculationNeither as CPU intensive as public-key decryption


Session resumptionFull handshake is expensive

CPU time and number of RRTs

If the client and server have already communicated once,

they can skip handshake and proceed directly to data transferFor a given session

oclient and server store session_id, master_secret, negotiated ciphers

Client sends session_id in ClientHello

Server then agrees to resume in ServerHelloNew key_block computed from master_secret and client and server

random numbers


Client authenticationSSL can also authenticate clientServer sends a CertificateRequest message to

client


SSL: Secure Sockets Layer (Again)Widely deployed security

protocolSupported by almost all

browsers and web servershttpsTens of billions $ spent per

year over SSLOriginally designed by

Netscape in 1993Number of variations:

TLS: transport layer security, RFC 2246

ProvidesConfidentialityIntegrityAuthentication

Original goals:Had Web e-commerce

transactions in mindEncryption (especially

credit-card numbers)Web-server authenticationOptional client

authenticationMinimum hassle in doing

business with new merchantAvailable to all TCP

applicationsSecure socket interface


SSL Architecture

69


SSL History

70

95 96

Initial Design

SSL v2.0

SSLRef 2.0

SSL BOF@ IETF

SSL v3.0

SSL BOF II@ IETF

Independent ImplementationsHardware, Toolkits, Applications

TLS Draft

TLS v1.0

99


SSL Extended Validation Cert


Secure Sockets Layer Protocol

72

A server running SSL provides Confidentiality Integrity Authentication

SSL is designed to operate in a number of different modes, depending on the requirement of the network connection No authentication, no encryption Authentication without encryption Encrypted communication only Encryption and authentication of the server Encryption and authentication of client and server


SSL Sessions and Connections

73

AliceAmazon

A Connection• Server, Client Random

• Server Write MAC Secret

• Client Write MAC Secret

• Server, Client Write Key

• Initialization Vector

• Sequence Numbers

A Session• Session Identifier

• Peer Certificate

• Master Secret

• Compression Method

• IS RESUMEABLE


Record Layer Protocol Operations

74

1) Application Data

2) Fragments

3) Compress

4) Add MAC

5) Encrypt

6) Add SSLHeader

Each fragment 214 bytes

Optional Compression(allow 1024 bytes for

expansion)

HMAC-like or HMAC(using SHA-1 or MD5)

Encrypt(allow 1024 bytes for

expansion)

Add SSL Record Layerheader


Record Layer Format

75

Plaintext(optionally compressed)

ContentType

MajorVersion

MinorVersion

[Compressed]Length (16)

MAC

Encr

ypte

d

Content Type: change_cipher_spec (20) alert (21) handshake (22) application_data (23)

Major Version: Major version of SSL

Minor Version: Minor version of SSL

Length: 16-bits

Data expansion: Compression= 1024 Encryption = 1024 216 – 2048 = 214

Entire payload, including the MAC is encrypted.


SSL Handshake Protocol

76

Allows server and client to authenticate one another and establish security parameters.

Consists of following phases: Establish security capabilities Server authentication and key

exchange Client authentication and key

exchange Finish

Type: ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone CertificateVerify ClientKeyExchange Finished

Type Length Content

1 byte 3 bytes >= 0 bytes


SSL Alert Protocol

77

Alert Protocol – Used for SSL related alert and error messagesTwo levels of alerts: Warnings

Actions not specified in the spec. Fatal

Terminate the connection responsible for the alert Invalidate the session that contained the terminated connection No new connections allowed using that session, existing connections unchanged Clients, servers should forget all session information

Closure Alerts: Client, server should notify each other of connection terminations Uses close_notify alert Otherwise, Truncation Attacks are possible

“Defuse the bomb by removing the red wire, after removing the green wire” what if “after removing the green wire” is never received!!!

Security is compromised by terminating the connection prematurely


SSL Change Cipher Spec Protocol

78

Causes pending state to be copied into current state

Why separate protocol? Change Cipher Spec protocol notifies the Record Layer protocol to

change cipher specifications (keys etc.)


SSL Cipher Suite

79

For public-key, symmetric encryption and certificate verification we need Public-key algorithm Symmetric encryption algorithm Message digest (hash) algorithm Key exchange methods

This collection is called a cipher suite SSL supports a variety of cipher suites Client and server must agree upon a common suite The client offers a choice; the server picks one


SSL Encryption Techniques

80

Block Cipher

Algorithm Key Size

Stream Cipher

Algorithm Key Size

IDEA 128 RC4-40 40

AES 128-256 RC4-128 128

DES-40 40

DES 56

3DES 168

Fortezza 80

Fortezza is a protocol suite used in Defense Messaging System (DMS Cards), declassified by NSA in 1998 Contains two algorithms:

Skipjack: a 80-bit key, 64-bit symmetric block cipher KEA: Diffie-Hellman like Key agreement algorithm


Example Cipher Suites

81

INITIAL (NULL) CIPHER SUITE

PUBLIC-KEYALGORITHM

SYMMETRICALGORITHM

HASHALGORITHM

CIPHER SUITE CODES USEDIN SSL MESSAGES

SSL_NULL_WITH_NULL_NULL = { 0, 0 }

SSL_RSA_WITH_NULL_MD5 = { 0, 1 }

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 }


SSL Encryption

82

Pre-master Secret Created by client; used to “seed” calculation of encryption parameters Very simple: 2 bytes of SSL version + 46 random bytes Sent encrypted to server using server’s public key

Master Secret Generated by both parties from premaster secret and random values generated by

both client and server Key Material

A bit stream generated from the master secret and shared random values Length of the stream may vary depending on negotiated key sizes

Encryption Keys Extracted from the key material


SSL - IntegrityCompute fixed length Message Authentication Code

(MAC)Includes hash of messageShared secretSequence number

Transmit this MAC with the messageTLS uses MD5, SHA-1

83


SSL: Integrity

84


SSL Key Exchange Methods

85

RSA: Secret key is encrypted with receiver’s public-key

Fixed Diffie-Hellman: Diffie-Hellman public parameters are embedded in a certificate for the sides requiring

authentication

Ephemeral Diffie-Hellman: Diffie-Hellman public parameters are signed by the sender (using RSA or DSS)

Anonymous Diffie-Hellman: Standard Diffie-Hellman

Fortezza: KEA is used for key exchange Very much like standard Diffie-Hellman but Alice and Bob has two pairs of parameters

A pair of long-term public, private parameters A per-session public, private parameters

Design may have been influenced by Clipper program


SSL Messages

86

OFFER CIPHER SUITEMENU TO SERVER

SELECT A CIPHER SUITE

SEND CERTIFICATE ANDCHAIN TO CA ROOT

CLIENT SIDE SERVER SIDE

SEND PUBLIC KEY TOENCRYPT SYMM KEY

SERVER NEGOTIATIONFINISHED

SEND ENCRYPTEDSYMMETRIC KEY

ACTIVATEENCRYPTION

CLIENT PORTIONDONE

( SERVER CHECKS OPTIONS )

ACTIVATESERVERENCRYPTION

SERVER PORTIONDONE

( CLIENT CHECKS OPTIONS )

NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION


SSL Handshake

87

Courtesy: Wikipedia


Handshake Protocol

88

Message Type Parametershello_request null

client_hello version, random, session id, cipher suite, compression method

server_hello version, random, session id, cipher suite, compression method

certificate chain of X.509v3 certificates

server_key_exchange parameters, signature

certificate_request type, authorities

server_hello_done null

certificate_verify signature

client_key_exchange parameters, signature

finished hash value

The handshake protocol is used before any application data is transmitted.


Client Hello Parameters

89

Session ID An arbitrary byte to identify an active or resumable session Could be created by using Diffie-Hellman. Or by the hash of the shared secret and salt

Version Identifies highest version number of SSL client can support Compression method: The algorithms supported

Cipher spec Specifies the bulk data encryption algorithms (such as null, DES, etc.) and a hash algorithm (such as MD5 or SHA-1) supported

Random Number 32 byte random number used to seed cryptographic calculations First four bytes should be date and time


Server Hello Parameters

90

Session ID: An arbitrary byte to identify an active or resumable session

Version Identifies SSL protocol version to be used

Compression method The algorithm to be used

Cipher spec Specifies the bulk data encryption algorithm and a hash algorithm to be used. Also key size and hash size

Random Number 32 byte random number used to seed cryptographic calculations and chosen by server

Note: whereas client hello components are proposals, server hello components are

selections


Session Resumption

91

Client/Server simply send a new Hello message Using the Master key already established

new per connections keys can be created using the new ClientRandom and ServerRandom

Server and Client send Finished messages do complete the resumption

Session resumption is used to avoid expensive initial handshake process Just by transferring new random values server and client established new set

of keys using the existing master key

• Also see, Version Rollback attack


Server KeyExchange

92

Contains key information

Exact contents depend on the specific algorithm being used For RSA, it would be modulus and public key For Diffie-Helman, it contains server side key message


ServerHelloDone

93

Indicates to client server has finished initial negotiation messages

Message itself contains no other information


Client KeyExchange

94

Establishes symmetric encryption key information

For example, if RSA is being used then client generates session key and uses server’s public key to encrypt the session key

Only real server can decrypt to obtain session key


Finished Message

95

Allows both sides to verify that negotiation has been successful and security has not been

compromised

It is encrypted and authenticated by the cipher suite just established

It contains cryptographic hash of important information of just finished negotiation: Key information Contents of all previous hash messages exchanged by the systems Special value indicating client or server No hash of ChangeCipherState message (see Dropped ChangeCipherState attack)


Security Analysis of SSL

96

Authentication Issues: Depends on the validity of certificates and certificate revocation Unfortunately, there isn't any dependable infrastructure to enforce prudent

certification methods E.g.: Forged certificate of Microsoft, Inc. Another IE bug was it failed to validate the entire certificate chain, instead it stopped validation

after one parent certificate.

Key Exchange Issues: Avoid the use of anonymous Diffie-Hellman (MIM attack) Choice of “strong” public parameters in Ephemeral Diffie-Hellman

Choose very small prime numbers (like 3 or worst 2!)

Cipher Spec. Negotiation Issues: Version rollback Algorithm rollback Dropped Change Cipher Spec Message

Privacy Issues: Bleichenbacher’s Attack Remote Timing Attacks Traffic Analysis


Man in the Middle Attacks

97

A Simple DoS Send an invalid SSL packet to the server or client, by predicting subsequent TCP values of course. SSL will ignore the packet but TCP will accept it Then, when the real SSL packet comes in, TCP will ignore it thinking it is a duplicate SSL layer will never receive the packet subsequently resulting in a connection termination

Cipher Spec Rollback SSL V2 doesn’t do integrity check on ClientHello So a middle man can change the security parameters to the lowest common denominator in SSL

V2 SSL V3 fixes this by authenticating messages

Truncation Attack SSL V2 depends on TCP FIN|RST for connection termination notification But, TCP FIN|RST is not authenticated, hence anyone can terminate a SSL connection at wish Making “after removing the green wire” disappear! (See Alert Protocol)


SSL VPN vs. IPSec

98


IPSec or SSL VPN?

Feature IPSec SSL VPN

Client Software Uses VPN Client software for complete network access.

Uses a standard web browser to access limited corporate network resources. Eliminates need for separate client software

Management You must install and configure VPN client.

You do not need to install a VPN client. No configuration is required on the client machine.

Encryption Uses a variety of encryption and hashing algorithms such as DES, 3DES, AES, SHA & MD5

Uses SSL encryption native to web browsers.

Applications Encapsulates all IP protocols, including TCP, UDP, and ICMP.

Supports limited TCP-based client/server applications in clientless mode.Encapsulates all IP protocols with AnyConnect client


IPSec or SSL VPN?

Feature IPSec SSL VPN

Cost Free License Must purchase a licenseMany different types of licenses:AnyConnect Essential,AnyConnect Premium,AnyConnect Mobile,SSL Shared Premium

User Environment Suited for permanent or full-time telecommuters

Suited for all types of users including contractors, temp workers or even fulltime workers

Connectivity Establishes seamless connection to network.

Supports application connectivity through browser portal.

End-Workstations Linux/Window/OS X Linux/Window/OS X


IPSec or SSL VPN?Deployment Considerations

Client Workstations Are the client workstations company owned? Will the users be connecting from Internet Kiosks, guest machines? Will the users be using mobile stations (such as PDA etc)

User Type Do you want to deploy the remote access solution for contractors or part-time employees? Do you currently have a software deployment solution?

Connectivity Are all applications browser-based? Do you want to provide full network access or application based restrictive access? Are residential broadband providers blocking and/or charging more for IPSec traffic? Are remote access users coming in through NAT routers?


Examples

102

Documents

CPSC6128 - Network Security 1 Network Security CPSC6128 – Lecture 7 IKE/SSL VPNs