An analysis of TLS handshake proxying
-
Upload
nick-sullivan -
Category
Technology
-
view
1.357 -
download
2
Transcript of An analysis of TLS handshake proxying
An Analysis of TLS Handshake ProxyingNick Sullivan (@grittygrease) Douglas Stebila (@dstebila)
IEEE TrustCom August 20, 2015
CloudFlare Inc. Queensland University of Technology
Web performance• Fundamentally bound by the speed of light
• Content Delivery Networks (CDNs) provide distributed global load balancing and caching
4
HTTPS/TLS• Point-to-point authentication and encryption
• Visualized in lock icon in your browser address bar
9
HTTPS/TLS• client-server model
• Private key operation in handshake proves ownership of the certificate
• Client validates certificate via PKI
• Handshake establishes session keys
10
Private key compromise risks• Most cryptography is written in memory-unsafe languages like C
• Private keys are read from disk, used in memory
• Web servers (nginx, Apache) use OpenSSL
11
Private key compromise consequences• Private key disclosure breaks TLS trust model
• Server impersonation
• Retroactive decryption of sessions with RSA handshake
13
TLS with reverse proxies• TLS needs to be terminated at caching layer
• Private keys need to be distributed to the edge
• Financial institutions are highly regulated — no sharing with third parties
• This is why banks do not use CDNs — yet
15
TLS Handshake Proxying• Compromise between key security and performance
• Split the handshake geographically
• Private key operation performed at site owner’s facility (in HSM, etc)
• Rest of handshake performed at the edge
• Communicate to key server over secure tunnel
21
TLS Handshake Proxying• Private key stored in trusted location
• Mutually-authenticated TLS tunnel from edge
• TLS session resumption
• All static assets served over TLS from the edge
• Dynamic assets served from origin through reverse proxy
24
Additional Performance Notes• Persistent connection between Edge and Key Server is already established
• Otherwise the first connection will be slower
• Session resumption is even more improved
• No need to connect to key server if resumption data is present
32
Security goals of TLS Handshake Proxying• Key-server-to-client authentication
• Edge-server-to-client authentication
• Channel security
• Optional: Forward Security
35
Security of the key server• Dedicated TLS connection between key server and edge
• TLS client authentication with Private CA
• Timing side-channel protection
• Message size side-channel protection
36
Security of the edge server• Session ID-based resumption
• no claims about shared local session state
• sessions expiry determines forward secrecy
• Session Ticket-based resumption
• sharing state among all edge servers can result in confusion (rely on Host header)
• sessions ticket decryption secret lifetime determines forward-secrecy
37
TLS Handshake Proxying• Balances two contradictory goals
• Global load balancing of TLS
• Private key security
• Improved performance
• Strong security guarantees
39