An Analysis of TLS Handshake ProxyingNick Sullivan (@grittygrease) Douglas Stebila (@dstebila)

IEEE TrustCom August 20, 2015

CloudFlare Inc. Queensland University of Technology

Two competing goals on the web• Performance

• Security & Privacy

2

Performance on the Web

Improving performance by reducing latency

3

Web performance• Fundamentally bound by the speed of light

• Content Delivery Networks (CDNs) provide distributed global load balancing and caching

4

Reverse Proxy

5

Traditional traffic routing

6

Routing with reverse proxy

7

Security & Privacy on the Web

HTTPS and key compromise risks

8

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

12

HEARTBLEED

Private key compromise consequences• Private key disclosure breaks TLS trust model

• Server impersonation

• Retroactive decryption of sessions with RSA handshake

13

Keys on the edge

Combining HTTPS and Reverse Proxies

14

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

Reverse Proxy With HTTPS

🔒 🔑

🔒

Private Key

Location of TLS Terminators

17

Two contradictory goals• Global load balancing of TLS

• Reducing private key attack surface

18

Keyless SSL

19

Private Key

TLS Handshake Proxying

Combining HTTPS and Reverse Proxies

20

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 in RSA mode

22

Private Key

TLS in RSA mode with remote private key

23

Private Key

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

Also…• Fully implemented and live!

25

Performance Analysis

26

Geography of TLS

27

28

Geography of TLS With Proxy

29

Geography of TLS Handshake Proxy

Performance estimate• Triangle inequality for the internet topology

30

Performance measurement

31

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 Analysis

33

Security goals of TLS• Server-to-client authentication

• Channel security

34

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

Conclusions

38

TLS Handshake Proxying• Balances two contradictory goals

• Global load balancing of TLS

• Private key security

• Improved performance

• Strong security guarantees

39

An Analysis of TLS Handshake ProxyingNick Sullivan (@grittygrease) Douglas Stebila (@dstebila)

IEEE TrustCom August 20, 2015

CloudFlare Inc. Queensland University of Technology