securing networks guy leduc chapter 4: securing tcp connections chapter...
TRANSCRIPT
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
Securing TCP connections 3
Chapter Roadmap
❒ Security in the transport layer❒ SSL - The big picture❒ SSL - A more complete picture❒ Issues with certificates
© From Computer Networking, by Kurose&RossSecuring TCP connections 4
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 5
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
Securing TCP connections 6
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
Securing TCP connections 7
Chapter Roadmap
❒ Security in the transport layer❒ SSL - The big picture❒ SSL - A more complete picture❒ Issues with certificates
© From Computer Networking, by Kurose&RossSecuring TCP connections 8
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 9
“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
© From Computer Networking, by Kurose&RossSecuring TCP connections 10
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 11
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 12
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
Securing TCP connections 13
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 14
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 15
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 16
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 17
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:
© From Computer Networking, by Kurose&RossSecuring TCP connections 18
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 19
“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
Securing TCP connections 20
Chapter Roadmap
❒ Security in the transport layer❒ SSL - The big picture❒ SSL - A more complete picture❒ Issues with certificates
11
Securing TCP connections 21
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 22
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 23
SSL Record Formatcontent
type SSL version length
MAC
data
1 byte 2 bytes 3 bytes
Data and MAC encrypted (symmetric algo)
Securing TCP connections 24
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 25
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
Securing TCP connections 26
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
Securing TCP connections 27
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
Securing TCP connections 28
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
Securing TCP connections 29
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
Securing TCP connections 30
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
Securing TCP connections 31
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
Securing TCP connections 32
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
© From Computer Networking, by Kurose&RossSecuring TCP connections 33
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
Securing TCP connections 34
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
Securing TCP connections 35
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
Securing TCP connections 36
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
Securing TCP connections 37
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
Securing TCP connections 38
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
Securing TCP connections 39
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
Securing TCP connections 40
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
Securing TCP connections 41
Chapter Roadmap
❒ Security in the transport layer❒ SSL - The big picture❒ SSL - A more complete picture❒ Issues with certificates
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
Securing TCP connections 4-43
DNS-based authentication of named entities (DANE)
❒ Thanks to DNSSEC, DANE allows DNS to indicate which certificate is the right one to use!
Securing TCP connections 4-44
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
Securing TCP connections 4-45
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
Securing TCP connections 4-46
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
Securing TCP connections 4-47
MTA1 MTA2UA1 UA2
Securing TCP connections 48
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