Securing Networks Guy Leduc Chapter 4: Securing TCP connections Chapter ...leduc/cours/ISIR/SecNet-ch4.pdf · Network Security - PRIVATE Communication in a PUBLIC World ... Securing

1

© From Computer Networking, by Kurose&RossSecuring TCP connections 1

Computer Networking: A Top Down Approach, 7th edition. Jim Kurose, Keith RossAddison-Wesley, April 2016.(section 8.6)

Network Security - PRIVATE Communication in a PUBLIC World C. Kaufman, R. Pearlman, M. SpecinerPearson Education, 2002.(chapter 19)

Computer Networks, 4th or 5th editionAndrew S. TanenbaumPearson Education, 2003 or 2011.(section 8.9.3)

Securing Networks

Guy Leduc

Chapter 4:Securing TCP connections

Securing TCP connections 2

Chapter 4: Securing TCP connections

Chapter goals:

❒  security in practice:❍ Security in the transport layer

(versus other layers)❍ SSL / TLS❍ SSL / TLS certificate issues and the role of DNSSEC

2


Chapter Roadmap

❒  Security in the transport layer❒  SSL - The big picture❒  SSL - A more complete picture❒  Issues with certificates


SSL: Secure Sockets Layer❒  Widely deployed security

protocol❍  Supported by almost all

browsers and web servers❍  “https”❍  Billions €/year over SSL

❒  Mechanisms: [Woo 1994], Implementation: Netscape, 1995

❒  Number of variations:❍  SSLv3❍  TLS: transport layer

security, RFC 2246❒  TLS is kind of SSLv3.1

❍  But not interoperable with SSL❍  Session key made stronger

(harder to cryptanalyse)

❒  Original goals:❍  Had Web e-commerce

transactions in mind❍  Encryption (especially credit-

card numbers)❍  Web-server authentication❍  Optional client authentication❍  Minimum hassle in doing

business with new merchant❒  Provides

❍  Confidentiality❍  Integrity❍  Authentication

❒  Available to all TCP applications❍  Secure socket interface

3


SSL/TLS and TCP/IP

Application

TCP

IP

Normal Application

Application

SSL/TLS

TCP

IP

Application over SSL

•  SSL/TLS provides application programming interface (API) to apps•  C, Java, … SSL/TLS libraries/classes readily available


Relative Location of Security Facilities in the TCP/IP Stack

❒  Both are general-purpose (i.e. application independent) solutions❒  But

❍  SSL/TLS is specific to TCP•  Does not work with UDP, contrary to IPsec

–  Note: There exits DTLS (Datagram TLS) for securing UDP•  But makes SSL simpler (no worry about loss and retransmission of data)

❍  SSL/TLS only protects the TCP payload•  Traffic analysis is thus possible

HTTP FTP SMTP

TCP / UDP

IP / IPsec

HTTP FTP SMTP

SSL / TLS

TCP

IPSecurity at network level

Security at transport level

4


Chapter Roadmap



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

5


“Toy SSL”: a simple secure channel

❒ Handshake: Used by Alice and Bob to agree on crypto algorithms, to proceed with authentication and exchange of 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 SSL: three phases

1. Handshake:❒  Alice establishes TCP

connection to Bob❒  Alice authenticates Bob

via Bob’s CA-signed certificate❍  why (knowing that

Trudy could send Bob’s certificate)?

❒  creates, encrypts (using Bob’s public key), sends pre-master secret key to Bob❍  nonce exchange not

shown

SSL hello

Bob’s certificate

KB+(PMS)

TCP SYN

TCP SYNACK

TCP ACK

decrypt using KB

-

to get PMS

create Pre-MasterSecret (PMS)

6


Toy SSL: three phases2. Key Derivation:❒  Considered bad to use same key for more than one

cryptographic operation❍  Use different keys for message authentication code (MAC)

and encryption❒  4 keys:

❍  EB: “Bob -> Alice” data encryption key❍  EA: “Alice -> Bob” data encryption key❍  MB: “Bob -> Alice” MAC key❍  MA: “Alice -> Bob” MAC key

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

data and creates the keys


Toy SSL: three phases❒  Why not encrypt data in constant stream as we write

it to TCP?❍  Where would we put the MAC? If at end of TCP connection,

no message integrity until all data processed❍  For example, with instant messaging, how can we do

integrity check over all bytes sent before displaying?❒  Instead, break stream in series of records

❍  Each record carries a MAC❍  Receiver can act on each record as it arrives

❒  Issue: in record, receiver needs to distinguish MAC from data❍  Want to use variable-length records

length data MAC

3. Data transfer

7


Toy SSL data transfer❒ How could an attacker interfere with TCP data

transfer?❍  If it discards a TCP segment, TCP will simply retransmit it❍  If it changes the order of TCP segments, TCP will simply

reorder them❍  If it duplicates a TCP segment, TCP will simply discard the

duplicate❒  Yes, but the attacker could also

❍  modify consistently all sequence numbers of segments following a discarded segment, thus making loss invisible to TCP

❍  modify consistently the sequence numbers of two swapped segments (and in between segments if needed), thus allowing undetectable reordering

❍  modify consistently the sequence numbers of a duplicate segment and of all the following segments, thus making duplicates undetectable by TCP


Toy SSL data transfer (sender)

H( ).MB

b1b2b3 … bn…

d

d H(d)

d H(d)

K( ).EB

Application byte stream:

block n bytes together: compute

MAC

encrypt d + MAC

SSL record:

encrypted using EB

becomes TCP payload

First version:

Len

8


Sequence Numbers

❒  Problem: Attacker can capture and replay record or re-order records

❒  Solution: Put sequence number into MAC:❍ MAC = MAC (Mx, sequence || data)❍ Note: no sequence number field in SSL record

❒  Problem: Attacker could still replay all records❒  Solution: Add nonces in handshake, and use

them to build keys, e.g. Mx ❍  see detailed protocol


Control information

❒  Problem: Truncation attack: ❍ Attacker forges TCP connection close segment❍ One or both sides thinks there is less data than there

actually is ❒  Solution: record types, with one type for closure

❍  type 0 for data; type 1 for closure❒ MAC = MAC (Mx, sequence || type || data)

type length data MAC

9


Toy SSL data transfer (sender)

H( ).MB

b1b2b3 … bn

d

d H(d)

d H(d)

K( ).EB

Application byte stream:

block n bytes together: compute

MAC

encrypt d + MAC

SSL seq. #

d H(d)Type Ver LenSSL record

formatencrypted using EBunencrypted

but integrity-protected

Useful to ensure integrity of the whole byte stream.seq # not sent, just used

in the hash

becomes TCP payload

Updated version:


Toy SSL: summaryhello

certificate, nonce

KB+(PMS) = EMS

type 0, data, MAC(seq1||type0||data)type 0, data, MAC(seq2||type0||data)

type 0, data, MAC(seq1||type0||data)

type 0, data, MAC(seq3||type0||data)type 1, close, MAC(seq4||type1)

type 1, close, MAC(seq2||type1)

Encr

ypte

d an

d

auth

entic

ated

bob.com

10


“Toy SSL” isn’t complete

❒ How long are fields?❒ Which encryption protocols?❒ Want negotiation?

❍ Allow client and server to support different encryption algorithms

❍ Allow client and server to choose together specific algorithm before data transfer


Chapter Roadmap


11


Secure Socket Layer - SSL

❒  SSL is composed of 2 sublayers❍ The lower layer is the SSL Record Protocol:

•  Provides Integrity and Confidentiality❍ The main protocol of the upper layer is the SSL

Handshake Protocol, that we will study in more detail

SSL Record Protocol

TCP

IP

SSLHandshake

Protocol

SSL ChangeCipher Spec

ProtocolSSL AlertProtocol Application


SSL Record Protocoldata

data fragment

data fragmentMAC MAC

encrypteddata and MAC

encrypteddata and MAC

recordheader

recordheader

record header: content type; version; length

MAC: also includes sequence number, type and MAC key Mx

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

12


SSL Record Formatcontent

type SSL version length

MAC

data

1 byte 2 bytes 3 bytes

Data and MAC encrypted (symmetric algo)


SSL Handshake Protocol❒  The most complex part of SSL❒  Purpose

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

❒  This mechanism is called session creation❍  a session defines the set of cryptographic security parameters to be

used❍  multiple secure TCP connections between a client and a server can

share the same session•  less computation cost

❒  This handshake protocol is used before any application data is transmitted

13


The four phases of the SSL Handshake Protocol

❒  1. Establish Security Capabilities❒  2. Server Authentication (and key exchange)❒  3. (Client Authentication and) key exchange❒  4. Finish


Phase 1 of SSL Handshake: Establish Security Capabilities

Client Server

client_hello (cipher_suite, RA)

server_hello (cipher, session_id, RB)

❒  Client_hello contains the combinations of cryptographic algorithms supported by the client, in decreasing order of preference

❒  Server_hello is the selection by the server•  Assign a session_id•  Select the CipherSpec

❒  The client_hello can contain a session_id•  To resume a previous session

❒  Both messages have nonces: RA and RB

14


Why the two random nonces?❒  Suppose Trudy sniffs all messages between Alice

& Bob❒ Next day, Trudy sets up TCP connection with

Bob, sends the exact same sequence of records❍ Bob (Amazon) thinks Alice made two separate orders

for the same thing❒  Solution:

❍ Bob sends different random nonce for each connection. ❍ Nonces used in KDF. This causes encryption and MAC

keys to be different on the two days❍ Trudy’s messages will fail Bob’s integrity check


CipherSpecs

❒ The CipherSpec contains fields like:❍ Cipher Algorithm (DES, 3DES, RC4, AES, …)❍ MAC Algorithm (based on MD5, SHA-1, …)❍ Public-key algorithm (RSA, DHE, …)

15


Phase 2 of SSL Handshake: Server Authentication (and Key Exchange)

❒  Certificate❍  Server’s RSA certificate❍  Client software comes

configured with public keys of various “trusted” (anchor) CAs to check certificate (chains)

•  Security threat!•  Discussed later

❒  (Server_key_exchange)❍  With RSA: not used

❒  Certificate_request❍  Server may request client

certificate❍  Usually not done

❒  Server_hello_done

Client Server

server_hello_done

certificate

(server_key_exchange)

certificate_request

We first consider the most classical key exchange protocol: RSA

All these messages are usually combined with the previous server_hello message

checkcertificate


Phase 3 of SSL Handshake: (Client Authentication and) Key Exchange

❒  Certificate ❍  Client’s RSA certificate❍  Only if requested by server

❒  Client_key_exchange❍  For RSA: It’s the pre-master secret

(PMS) encrypted with the server’s public key

❍  Also sent is a hash of (PMS,RA,RB)❍  Avoids substitution or replay of

encrypted PMS❒  Certificate_verify

❍  If certificate sent by client❍  Used by the client to prove it has

the private key associated with its certificate (in case someone is misusing the client's certificate)

❍  Basically, the client signs a hash of the previous messages

Client Server

certificate

client_key_exchange

certificate_verify

16


Phase 4 of SSL: Handshake Finish❒  Change_cipher_spec

❍  Its purpose is to cause the pending state to be copied into the current state

❍  From now on, all records are encrypted and integrity-protected

❍  Is part of the Change Cipher Spec protocol

❒  Finished❍  Are encrypted and integrity-

protected❍  Verifies that the key exchange

and authentication processes were successful

❍  It is the concatenation of 2 MAC values calculated from the previous messages

Client Server

change_cipher_spec

finished

change_cipher_spec

finished


Role of the Finish phase❒  Counter the downgrade attack:

❍  An attacker could have removed the cipher suites with strong encryption from the client_hello message, causing the entities to agree upon a weaker cipher

❒  Counter the truncation attack:❍  An attacker could close the underlying connection (by sending a

TCP close message) which, in SSLv2, would have terminated the SSL session abnormally

❍  In SSLv3 connection cannot be closed before FINISHED❒  Note: The truncation attack can also occur later during

the data transfer: ❍  The solution is to indicate in the type field of the SSL record

whether it is the last record❍  In normal operations, the TCP connection cannot be closed

before these type fields have been exchanged over the SSL connection

17


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 follows

Everythinghenceforthis encrypted

After TCP SYN and SYNACK


Main Key exchange methods based on RSA❒  RSA

❍  The classical method shown in previous slides❍  Client sends a PMS encrypted with the server's certified RSA public key:

KB+(PMS) •  Server needs a certified encryption public key

❒  RSA with signature-only key❍  May be used when encryption with an RSA key longer than 512 bits is not

allowed, while signing with such a key is allowed❍  Server first generates a temporary pair of RSA (short) keys (kB

-, kB+) and

sends the public one to the client, signed by its RSA (long-term) key: KB

-(kB+,B)

❍  Client sends a PMS encrypted with the server's temporary RSA public key: kB

+(PMS)

❍  Note: this scheme designed for exportability actually enhances security because it allows (weak-key) perfect forward secrecy:

•  Breaking or stealing the temporary private key does not allow Trudy to decrypt previous SSL sessions

18


Phases 2 and 3: RSA with “signature-only”

❒ Server_key_exchange❍ With RSA “signature-only”:

it is the temporary public key, signed by the server’s long-term key

❒ Client_key_exchange❍  It’s the PMS encrypted with

the server’s temporary public key

❍ + hash of (PMS, RA, RB)

Client Server

server_hello_done

certificate

server_key_exchange

certificate_request

certificate

client_key_exchange

certificate_verify

checkcertificate

checksignature


Other key exchange methods (1)❒ Anonymous Diffie-Hellman (DH)

❍  Public DH parameters (YA and YB) are sent in server_key_exchange and client_key_exchange messages

❍  The pre-master secret is the shared key computed by DH•  No need to send the PMS•  No protection against man-in-the-middle attack, as DH

parameters are not authenticated❒ Fixed (or Static) Diffie-Hellman

❍  The DH public (key) parameters are fixed and signed by a CA

•  Resists to man-in-the-middle attack, but allows an attacker to use brute force on long-standing DH public-key parameters

•  Client needs a certified DH public key too!•  Server’s DH public parameters could also be signed by the

server’s RSA key if it has one

19


Other key exchange methods (2)❒ Ephemeral Diffie-Hellman (DHE)

❍  Ephemeral DH public-key parameters are exchanged•  They can vary from session to session•  More robust to brute force •  Provides forward secrecy

❍  They are signed using the sender's private RSA key•  Resists to man-in-the-middle thanks to this authentication of

public-key parameters•  Sender should have a secret RSA key to sign•  So, client needs a certified RSA public key too!

❍  Many browsers and servers support DHE


Master secret and keys❒  The previous phases have generated a pre-master secret

❍  Key chosen and sent encrypted to the server (with RSA)❍  Or, the DH secret key

❒  The master secret is generated (via pseudo random-number generator) from❍  The pre-master secret❍  The two nonces (RA and RB) exchanged in the client_hello and

server_hello messages❍  Makes it possible to use the same pre-master secret for several

sessions (useful for Anonymous and Fixed DH, for example)❒  Six keys are derived from this master secret:

❍  Secret key used with MAC (for data sent by server)❍  Secret key used with MAC (for data sent by client)❍  Secret key and IV used for encryption (by server)❍  Secret key and IV used for encryption (by client)

20


Server Gated Cryptography (SGC)❒  The US allows an exported client to use strong crypto when

talking to some servers doing financial transactions❍  Those servers have an SGC certificate signed by Verisign (trusted

by the Government, which turns out to be the real matter!)❍  This is wired in the implementation❍  Other trust authorities (in Browser) can be modified by the user

❒  Start with weak (exportable) cryptography, and then upgrade to strong cryptography if the server has an SGC certificate❍  The SGC certificate is discovered in phase 2 only❍  In the step-up variant (Netscape) the client continues with a 2nd

handshake protected by the first master secret❍  Use Change_Cipher_Spec to switch to strong crypto❍  This does not require the server to run any special SGC code❍  There is another variant where the 2nd Handshake is replaced by a

2nd Hello (but requires specific SGC code)From Network Security, by Kaufman et al. © Pearsons


SSL Alert Protocol

❒  This protocol is used to report errors❍  Examples

•  Unexpected message•  Bad record MAC•  Decompression failure•  Handshake failure (i.e. security parameters negotiation failed)•  Illegal parameters

❒  It is also used for other purposes❍  Examples

•  To notify closure of the TCP connection•  To notify the absence of certificate (when requested)•  To notify that a bad or unknown certificate was received•  To notify that a certificate is revoked or has expired

21


Chapter Roadmap


SSL/TLS – certificate issues ❒  Client browser is equipped with many certificates of trusted

CAs (associated with Trusted Authorities) that will be used to verify the authenticity of server certificates❍  so-called anchor CAs, these CAs are implicitly trusted by the client

❒  The client checks that❍  the server certificate has the right name❍  there is a certificate chain whose last certificate is signed by one of

those anchor CAs trusted by the client❍  the lower signer in the chain is a CA, which is indicated in certificate

(“Basic Constraint” extension), otherwise Trudy holding a valid certificate could certify anything!

•  This was exploited in sslsnif in 2009

❒  SSL/TLS ensures confidentiality and server authentication provided that the server certificate is properly anchored!

Securing TCP connections 4-42

22

Too many anchor CAs!

❒  Because too many trusted authorities (TAs)❍ More than 1000 trusted CAs in modern web browsers!

❒  If a server certificate is signed by a compromised or rogue CA present in this set, client wrongly thinks it has authenticated server!

❒ Worse: nothing precludes a CA to issue a certificate for any domain name, e.g. for www.bob.com❍ So, a rogue CA could issue fake certificates for any

domain


DNS-based authentication of named entities (DANE)

❒  Thanks to DNSSEC, DANE allows DNS to indicate which certificate is the right one to use!


root DNS server

bob.com DNS server

com DNS server

❒  Example: DNS of bob.com publishes a new DNS RR record (TLSA RR) specifying the only valid certificate for e.g. www.bob.com

❒  And this TLSA is signed by the DNS of bob.com thanks to DNSSEC

❒  DANE can also allow a domain owner to specify which CA is allowed to issue certificates for resources in its domainwith

TLSA RRs

23

DANE in browsers

❒  A browser supports DANE when, before accepting the SSL/TLS session, it also fetches the DNSSEC-signed TLSA RR associated with the server name, and checks that the received server certificate is the right one to use

❒  But it adds DNS traffic and delay in the browser


Back to e-mails: here over SSL/TLS

❒  UAs should use SSL/TLS to connect to their MTAs at source and destination, thereby authenticating their MTAs and also encrypting e-mail headers

❒  But what about the TCP connection between MTAs?❍  Usage of SSL/TLS depends on willingness of MTA2

❒  Also e-mails stored unencrypted in MTAs if PGP/SMIME not used


Bob retrieves the email from his local MTA

(e.g., IMAP over SSL/TLS)MTA forwards email

to another MTA(SMTP over ?)

Alice sends an email to her local MTA

(SMTP over SSL/TLS)

MTA1 MTA2UA1 UA2

24

E-mail transfer between MTAs

❒  If MTA1 is wrongly directed to a rogue MTA2 when it searches the DNS MX RR for Bob’s domain name (e.g. due to DNS poisoning), then this rogue MTA2 can/will pretend that it does not support SSL/TLS and will collect the e-mails from MTA1 over TCP!

❒  DNSSEC ensures that the MX RRs are signed❍  Therefore ensuring that MTA2 is the right MTA for Bob’s domain

❒  In addition, DANE will certify that MTA2 supports SSL/TLS if MTA2 has an associated TLSA RR❍  Thereby adding security because MTA2 or a MIM could not trick MTA1 in

not using SSL/TLS


MTA1 MTA2UA1 UA2


Conclusion: Pros and Cons of SSL/TLS❒  Pros

❍  Transport Layer Security is transparent to applications

❍  Server is authenticated (if client’s browser correctly configured with trusted CAs to check server’s certificate)

❍  Application layer headers are encrypted

❍  OK for direct client to server communication

❍  More fine-grained than IPSec (see later) because it works at the transport connection level

❒  Cons❍  TCP/IP headers are in clear❍  Only applicable to secure TCP-

based applications (not UDP)❍  Not enough to secure

applications using intermediate servers and a chain of TCP connections (e.g. email)

❍  Nonrepudiation is not provided❍  Server authentication not

guaranteed if server certificate not properly anchored

❍  Client authentication, if needed, must be implemented above SSL (e.g. username and password sent over the SSL connection) or client must have a certificate too

Securing Networks Guy Leduc Chapter 4: Securing TCP connections Chapter ...leduc/cours/ISIR/SecNet-ch4.pdf · Network Security - PRIVATE Communication in a PUBLIC World ... Securing

Documents