SecureSockets

Secure Sockets Secure Sockets

Overview of Lecture Overview of Lecture

 We covered an overview of authenticated key exchange protocols

– Look at issues related to Web Security – Examine a specific implementation of such a protocol, known as

Secure Sockets

 In this lecture we will

Web Security Issues Web Security Issues

 The Web has become the visible interface of the Internet

– Many corporations now use the Web for advertising, marketing and sales

 Web servers might be easy to use but…

– Complicated to configure correctly and difficult to build without security

flaws

– They can serve as a security hole by which an adversary might be able to

access other data and computer systems

Threats

Consequences

Countermeasures

Integrity

Modification of Data

Loss of Information

MACs and Hashes

Trojan horses

Compromise of Machine

Confidentiality

Eavesdropping

Loss of Information

Encryption

Theft of Information

Privacy Breach

DoS

Stopping

Stopped Transactions

Filling up Disks and Resources

Authentication

Impersonation

Misrepresentation of User

Signatures, MACs

Data Forgery

Accept false Data

Table from Stallings, and from A. Rubin

So Where to Secure the Web? So Where to Secure the Web?

 There are many strategies to securing the web

This may be accomplished using IPSec, for example.

1. We may attempt to secure the IP Layer of the TCP/IP Stack:

accomplished using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS)

2. We may leave IP alone and secure on top of TCP: This may be

application-specific security solutions: For example, we may use Secure Electronic Transaction (SET)

3. We may seek to secure specific applications by using

for more specialized services

 The first two provide generic solutions, while the third provides

 We will focus this lecture on SSL

A Quick Look at Securing the TCP/IP Stack A Quick Look at Securing the TCP/IP Stack

HTTP FTP SMTP HTTP FTP SMTP

SSL/TLS TCP

TCP IP/IPSEC

At the Network Level

At the Transport Level

S/MIME PGP SET

Kerberos SMTP HTTP

UDP TCP

At the Application Level

Overview of SSL Overview of SSL

Netscape in order to secure http communications

 The Secure Sockets Layer was originally developed (1994) by

accepted by the IETF in 1999

– TLS is backward compatible with SSLv3

 Version 3 of SSL was released in 1995 – It is what we think of when we say SSL – Slight variation became Transport Layer Security (TLS) and was

 TCP provides a reliable end-to-end service

– SSL Record Protocol (where all the action takes place) – SSL Management: (Handshake/Cipher Change/ Alert Protocols)

 SSL consists of two sublayers:

SSL Preliminaries SSL Preliminaries

 An SSL Session is an association between a client and a server (created by the Handshake Protocol). There are a set of security parameters associated with each session

transient. There may be many connections associated with one session. The same security parameters may apply to many connections.

 An SSL Connection is a peer-to-peer relationship, and is

– Session Identifier – Peer Certificate: X.509v3 certificate of the peer – Compression: Optional algorithm used to compress data – Cipher Specs: Encryption Algorithm (3DES, AES, etc.) and hash

algorithm (MD5, SHA-1)

– Master Secret: 48-byte secret shared between client and server

 Session Security Parameters:

SSL Preliminaries, pg. 2 SSL Preliminaries, pg. 2

– Server and Client random byte sequences used for each connection – Server MAC Key: Key used in MAC operations on data sent by the

server

– Client MAC Key: Key used in MAC operations on data sent by the

client

– Server Encryption Key: Encryption key used for data encrypted by

server and decrypted by client

– Client Encryption Key: Encryption key used for data encrypted by

client and decrypted by server

– Initialization vectors: We will use CBC mode, so we need IVs. – Sequence Numbers: Each entity maintains sequence numbers for

transmitted and received messages

 Connection Parameters:

SSL Record Protocol SSL Record Protocol

Handshake Protocol to securely deliver data

 The SSL Record Protocol uses the keys derived from the

– Confidentiality and Message Integrity

 Two functions:

Data

Fragmentation

Chunk

Compression

Shrunk

MAC

Shrunk

Encrypt

Encrypted

Prepend Header

Encrypted

SSL Record Protocol, pg. 2 SSL Record Protocol, pg. 2

 SSL Record protocol allows protocols above SSL to be secured

– Example: HTTP delivers packets that are fragmented and securely

delivered

– SSL does not handle retransmissions… it does not have to! TCP provides

that functionality

– This is quite the opposite of IPSec, which only secures IP!

 Messages are broken into blocks of at most 16384 bytes

 The compression is optional and, due to message size/type, it might not even

be desirable to use!

 Encryption may be stream or block mode. This is negotiated through the

Handshake protocol – If block encryption, padding is necessary in order to fill out a block

length

u Padding is a sequence of padding bytes (random junk will do) followed by

1 byte that describes length of the pad (up to 255).

SSL Record Protocol, pg. 3 SSL Record Protocol, pg. 3

– Content type descriptor (1 byte): For the upper layer to use – Major Version (1 byte): What version of SSL? (3 for SSL and TLS) – Minor Version (1 byte): Indicates the revision (0 for SSLv3, 1 for

TLS)

 The Header consists of

that are allowed – Interchange Ciphers: RSA, Diffie-Hellman (signed and unsigned),

Fortezza

– Bulk Encryption Cipher: RC4, RC2, DES (CBC Mode), 3DES

(EDE-CBC Mode), Fortezza (CBC)

– MAC: SHA-1 and MD5

 There are only a limited selection of ciphers and MAC algorithms

SSL Record Protocol, pg. 4 SSL Record Protocol, pg. 4

 The real trick to the Record Protocol is the MAC

 In SSL, the record layer computes a MAC for each chunk of data.

 In SSLv3 the MAC is

Hash(MACws|| Pad2||Hash(MACws||Pad1||SeqNum||SSLComp||SSLLen||Chunk))

– MACws = Shared MAC Key – Hash: MD5 or SHA-1 – Pad1: (00110110) repeated 48 times for MD5 or 40 times for SHA-1 – Pad2: (01011100) repeated 48 times for MD5 or 40 times for SHA-1 – SeqNum; Sequence number for this message – SSLComp: Higher Layer descriptor of message type – SSLLen: Length of the chunk – Chunk: The fragment of data after it has been compressed

 The pieces:

SSL Handshake Protocol SSL Handshake Protocol

 This is the beast… Its where all the action really takes place!

data is transmitted. – It is used to allow the server and client to authenticate each other – To negotiate on an encryption and MAC algorithm – Establish keys to be used

 Basically, the Handshake protocol is used before any application

fields: – Type (1 byte): Indicates type of the message. There are 10 types. – Length (3 bytes) – Content: The payload exchanged in each message

 The Handshake Protocol consists of messages consisting of three

SSL Handshake Protocol, pg. 2 SSL Handshake Protocol, pg. 2

ClientHello ServerHello

 Round 1: Create the Connection between the Client A and Server G (Gigafirm in my notes), and figure out what each entity can do!

{:GA.1

vers

SessID ,

CiphList

CompList }

ﬁ

G.2

{:A

vers

SessID ,

CiphChoice

CompChoice }

,r,# A ,r,# G

ﬁ

ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd

ClientCertificate ClientKeyExchange CertVerify

ChangeCipher Finished

ChangeCipher

Finished

• rA is a nonce made of 4 bytes of timestamp and 28 bytes of random #. Similarly for rG. •SessID: 0 if new session, else is the session ID of an existing session (and the Handshake will update parameters) •CiphList is a list of algorithms supported by the client in an order of decreasing preference (Key Exchange and Encryption Cipher) •CiphChoice: The cipher suite chosen by the Server.

SSL Handshake Protocol, pg. 3 SSL Handshake Protocol, pg. 3

 Round 2: Server Authentication and Key

ClientHello ServerHello

Exchange – Server begins by sending its X.509 cert (and

associated cert chain)

– Next, a public key is sent (e.g. modulus and

exponent, if RSA)

– Server may Request a Cert from the Client – Server sends end round 2 message

ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd

ﬁ

{

}Cert [

} ]

G.3 G.4

hash

))

509X_G{:A E||)e,n(:A G

r( A

r|| G

e,n(|| G

ﬁ

G.5

{:A

CertType

ValidCertA

uthorities }

ﬁ

ClientCertificate ClientKeyExchange CertVerify

G.6

{:A

EndHello }

ﬁ

ChangeCipher Finished

ChangeCipher

Finished

KG is the private key, and hence EKG is a signature operation by the Server ValidCertAuthorities identifies the authorities the server will accept

SSL Handshake Protocol, pg. 4 SSL Handshake Protocol, pg. 4

 Round 3: Client Authentication and Key

ClientHello ServerHello

Exchange – Client verifies that the Server’s Cert is valid, and

checks that parameters sent are valid

– If a cert was requested, then the Client sends one – Server generates a PreMasterSecret sPM

ﬁ

ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd

[

509X_A{:GA.7 }Cert } { ] E:GA.8 {

ﬁ

(

hash

} ))

r||MS A

Messages ||8to1 ) )

:GA.9 =

SHA

|| )

)

ﬁ

ClientCertificate ClientKeyExchange CertVerify

SHA

|| ) )

hash ( s5MD ( s5MD ( s5MD

r||MS( G ( s||'A'1 PM ( s||'BB'1 ( '1

CCC

SHA

PM s||'

r|| A r|| A r|| A

r|| G r|| G r|| G

ChangeCipher Finished

ChangeCipher

Finished

+KG is the public key, and hence E+KG is a encryption using the public key gained from the certificate Messages1to8 is the concatenation of first 8 messages MS is master secret and Step 9 is for verification

SSL Handshake Protocol, pg. 5 SSL Handshake Protocol, pg. 5

 Round 4: Wrap-up

– Client tells Server to change cipher (via the

ClientHello ServerHello

Change Cipher Protocol).

– Server responds with its own changed cipher

message

– Finished Message are hashes for verification

ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd

}er

{:GA.10 {

ChangeCiph (

)

}

ﬁ

:GA.11

hash

(

Messages

||9to1

Client

)r||MS A

ﬁ

G.12

{:A {

r||MS G CipherChan }ged (

ﬁ

ClientCertificate ClientKeyExchange CertVerify

G.13

hash

(

Messages

||9to1

Server

})r||MS )

r||MS G

ChangeCipher Finished

ChangeCipher

Finished

Other SSL Management Functions Other SSL Management Functions

parameters have been agreed upon (aka. Handshake). “Pending” parameters become activated.

– SSL Alert Protocol: Signals that unusual conditions have been

encountered. u Each message consists of two bytes. First byte is a (1) if a warning

or a (2) if a fatal error. If error is fatal, the connection is terminated (other connections may continue…). Second byte says the type of error.

u Unexpected_Message: Fatal u Bad_Record_MAC: Fatal u Decompression_Failure: Fatal u Handshake_Failure: Fatal u And many more…

 There are two other Management Functions provided by SSL: – Change Cipher Spec: A single byte is sent after new cipher

Wrap-Up Wrap-Up

– ClientWrite MAC Secret and ClientWrite Key – ServerWrite MAC Secret and ServerWrite Key – Client and Server IVs – Parameters are generated via hashing… MS is basically a seed to a

pseudorandom function.

 Many other parameters are generated from the master secret:

– TLS uses HMAC instead of the concatenation-MAC – TLS does not support Fortezza – Minor differences in padding requirements

 TLS is very similar to SSL