An analysis of TLS handshake proxying
3 likes2,389 views
The document examines the analysis of TLS handshake proxying, focusing on balancing performance and security goals in web traffic management. It discusses the importance of private key security and the impacts of key compromise risks, such as server impersonation and retroactive decryption. The proposed solution combines HTTPS with reverse proxies to optimize performance while maintaining a secure architecture for key operations.
An analysis of TLS handshake proxying
- 1. An Analysis of TLS Handshake Proxying Nick Sullivan (@grittygrease) Douglas Stebila (@dstebila) IEEE TrustCom August 20, 2015 CloudFlare Inc. Queensland University of Technology
- 2. Two competing goals on the web • Performance • Security & Privacy 2
- 3. Performance on the Web Improving performance by reducing latency 3
- 4. Web performance • Fundamentally bound by the speed of light • Content Delivery Networks (CDNs) provide distributed global load balancing and caching 4
- 7. Routing with reverse proxy 7
- 8. Security & Privacy on the Web HTTPS and key compromise risks 8
- 9. HTTPS/TLS • Point-to-point authentication and encryption • Visualized in lock icon in your browser address bar 9
- 10. 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
- 11. 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
- 12. 12 HEARTBLEED
- 13. Private key compromise consequences • Private key disclosure breaks TLS trust model • Server impersonation • Retroactive decryption of sessions with RSA handshake 13
- 14. Keys on the edge Combining HTTPS and Reverse Proxies 14
- 15. 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
- 16. Reverse Proxy With HTTPS 🔒 🔑 🔒 Private Key
- 17. Location of TLS Terminators 17
- 18. Two contradictory goals • Global load balancing of TLS • Reducing private key attack surface 18
- 20. TLS Handshake Proxying Combining HTTPS and Reverse Proxies 20
- 21. 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
- 22. TLS in RSA mode 22 Private Key
- 23. TLS in RSA mode with remote private key 23 Private Key
- 24. 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
- 25. Also… • Fully implemented and live! 25
- 28. 28 Geography of TLS With Proxy
- 29. 29 Geography of TLS Handshake Proxy
- 30. Performance estimate • Triangle inequality for the internet topology 30
- 32. 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
- 34. Security goals of TLS • Server-to-client authentication • Channel security 34
- 35. Security goals of TLS Handshake Proxying • Key-server-to-client authentication • Edge-server-to-client authentication • Channel security • Optional: Forward Security 35
- 36. 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
- 37. 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
- 38. Conclusions 38
- 39. TLS Handshake Proxying • Balances two contradictory goals • Global load balancing of TLS • Private key security • Improved performance • Strong security guarantees 39
- 40. An Analysis of TLS Handshake Proxying Nick Sullivan (@grittygrease) Douglas Stebila (@dstebila) IEEE TrustCom August 20, 2015 CloudFlare Inc. Queensland University of Technology