LDNWebPerf June 2016 - Natasha Rooney

Upgrading to HTTPS still seems to be difficult for some, and one the given reasons is: performance. Current in use TLS versions can take three round trips before any application data can be sent, which may seem like too many to spare for some. However, optimisations and solutions exist which can cut this wait time down and make it negligible. Not only that, but new versions of TLS may bring the round trip times down to zero. Natasha will go through the methods of working with speedy TLS, and how it’ll get even speedier in the future.

Transcript

1. @thisNatasha TLS Perf: from three to zero in one spec Natasha Rooney, @thisNatasha
2. @thisNatasha
3. @thisNatasha Lots of Poppies - Public Key Crypto - TLS History - TLS 1.2 - Evil RTTs - TLS Config - TLS 1.3 - ACME / Let’s Encrypt - Some cool links - Sleep.
4. @thisNatasha Why do i need ssl/tls?
5. @thisNatasha @thisNatasha 781 data breaches in 2015 170m records stolen Average $3.8m per breach http://www.idtheftcenter.org/ITRC-Surveys-Studies/2015databreaches.html @thisNatasha
6. @thisNatasha Quick intro to Public Key Cryptography
7. @thisNatasha Let’s get that Pikachu! Jessie James
8. @thisNatasha @thisNatasha Symmetric Crypto (Caesar Cipher)
9. @thisNatasha Key = 3 Let’s get that Pikachu! = Ohw’v jhw wkdw Slndfkx! Jessie James
10. @thisNatasha Key = 3 Let’s get that Pikachu! = Ohw’v jhw wkdw Slndfkx! Jessie James
11. @thisNatasha Key = 3 Let’s get that Pikachu! = Ohw’v jhw wkdw Slndfkx! Jessie James Ohw’v jhw wkdw Slndfkx! = Let’s get that Pikachu!
12. @thisNatasha @thisNatasha Asymmetric Crypto 2 Keys 1 Secret Key (keep it to yourself!) 1 Public Key (share with others)
13. @thisNatasha Jessie James PUBLIC
14. @thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... PUBLIC PUBLIC
15. @thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! PUBLIC PUBLIC
16. @thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! PUBLIC PUBLIC PUBLIC 1cd87b63a2a933ca2...
17. @thisNatasha
18. @thisNatasha Does this key really belong to james? PUBLIC
19. @thisNatasha @thisNatasha Certs Certificate Authority (CA) issues a Certificate CA checks James’s identity Digicert, Versign (but anyone can be a CA)
20. @thisNatasha @thisNatasha Certs Certificate Authority (CA) issues a Certificate X.509 Version Number Serial Number Algorithm ID Issuer Validity period Subject name Subject Public Key Info Certificate Signature Algorithm Certificate Signature ...
21. @thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! Giant Meowth Certificate Authority PUBLIC PUBLIC
22. @thisNatasha
23. @thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! Giant Meowth Certificate Authority PUBLIC PUBLIC
24. @thisNatasha @thisNatasha SSL / TLS Also use Public Key Cryptography HTTPS
25. @thisNatasha TLS History.
26. @thisNatasha 7. Application Data HTTP / IMAP 6. Data Presentation, Encryption SSL / TLS 5. Session and connection management - 4. Transport of packets and streams TCP / UDP 3. Routing and delivery of datagrams on the Network IP / IPSec 2. Local Data Connection Ethernet 1. Physical data connection (cables) CAT5 OSI Model
27. @thisNatasha @thisNatasha SSL (TLS is the same, just later versions) SSLv1 Netscape 1994: SSLv2 Netscape Navigator 1.1 SSLv2 Security poor 1995: SSLv3
28. @thisNatasha @thisNatasha TLS A Crypto Protocol Framework 1996: TLS Working Group Microsoft vs Netscape 1999: TLSv1 2006: TLSv1.1 (sec fixes) 2008: TLSv1.2 configurable and flexible
29. @thisNatasha
30. @thisNatasha @thisNatasha TLS Aims Not just crypto... Cryptographic Security Interoperability Extensibility Efficiency
31. @thisNatasha @thisNatasha TLS Aims Don’t have a TIF Message tampering Message interception Message forgery
32. @thisNatasha @thisNatasha TLS Basics Not just crypto... 1. Handshake including authentication and key exchange 2. Data exchange 3. Shutdown
33. @thisNatasha Er, I can see why this take some time...
34. @thisNatasha TLS 1.2
35. @thisNatasha @thisNatasha 6-10 messages Handshake Full handshake with server authentication - Exchange capabilities - Agree on params - Validate certs - Agree master secret - Verify handshake was not modified Abbreviated handshake (resumes earlier session)
36. @thisNatasha Handshake Flow TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key Exchange Authentication Algorithm Strength Mode Cipher MAC or PRF TLS / Handshake Cheat Sheet Key Exchange Method: creates the pre master secret. Premaster secret is combined with PRF to create master secret RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA Authentication Method: Uses public key crypto and certificates public key together. Once certificate is validated the client can used public key. RSA or ECDSA Certs: X.509, ASN.1 DER encoding. Server Hello, Certificate - Server selects cipher & compression method - Server send certificate - Client authenticates Key Exchange Pre-master secret exchanged between client & server, client validates certificate Master Secret Client & Server can compute Master Secret. MAC Server verifies MAC, returns to client to verify also. Finished Handshake complete. Client Hello Client sends TLS Version, Ciphersuites, Compression methods Ciphers, Standards and Terms Encryption 3DES, AES, ARIA, CAMELLIA, RC4, and SEED [1] Steam: adds MAC [2] Block: adds IV and padding after encryption [3] Encryption (AEAD): encryption and integrity validation, using nonce, no padding, no IV. Master Secret Pre-master secret: combines params to help client and server create master secret. Master Secret: both server and client create this from pre-master secret to symmetrically encrypt Integrity Validation PRF: Pseudorandom Function. Takes a secret, a seed, and a unique label. TLS1.2 suites use PRF based on HMAC and SHA256 MAC: used for integrity validation in handshake and record.
37. @thisNatasha [1] Client Hello Cli-ant Ser-ver Server Hello [2] Certificate [3] Server Key Exchange [4] Server Hello Done [5] [6] Client Key Exchange [7] (Change Cipher Spec) [8] Finished (Change Cipher Spec) [9] Finished [10] TLS Handshake
38. @thisNatasha
39. @thisNatasha [1] Client Hello Cli-ant Ser-ver Server Hello [2] Certificate [3] Server Key Exchange [4] Server Hello Done [5] [6] Client Key Exchange [7] (Change Cipher Spec) [8] Finished (Change Cipher Spec) [9] Finished [10] TLS Handshake
40. @thisNatasha 2 Roundtrips And a lotta CPU...
41. @thisNatasha @thisNatasha Abbreviated Handshake Session Resumption Client and Server keep session security params Session ID Sent in ServerHello Client sends in next ClientHello
42. @thisNatasha [1] Client Hello (+ SessionID) Cli-ant Ser-ver (+ SessionID) Server Hello [2] (Change Cipher Spec) [3] Finished [4] [5] (Change Cipher Spec) [6] Finished TLS Abbreviated Handshake
43. @thisNatasha 1 Roundtrip A lot nicer
44. @thisNatasha @thisNatasha Key Exchange Depends on negotiated algorithm suite and algorithm - RSA: attackers can de-encrypt everything if has server private key, being replaced - DHE_RSA: has forward secrecy but slow - ECDHE_RSA and ECDHE_ECDSA: Fast and forward secrecy. Can be used with RSA or ECDSA - Server speaks first - Server sends params and signature of params for authentication
45. @thisNatasha @thisNatasha Authentication Certificate + Public Key Coupled with Key Exchange Public Key Crypto (RSA or ECDSA) RSA method: - Client creates a random value as premaster secret - Encrypts with public key - Server decrypts - Constructs Session Keys - Finished.
46. @thisNatasha @thisNatasha Encryption Usually AES, 3 types. 3DES, AES, ARIA, CAMELLIA, RC4, and SEED AES most popular Types: - Stream - Block - Authenticated (associated AEAD)
47. @thisNatasha Authenticated Encryption Seq Num Header Header Nonce Ciphertext Plaintext Authenticate Encrypt
48. @thisNatasha Handshake Flow TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key Exchange Authentication Algorithm Strength Mode Cipher MAC or PRF TLS / Handshake Cheat Sheet Key Exchange Method: creates the pre master secret. Premaster secret is combined with PRF to create master secret RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA Authentication Method: Uses public key crypto and certificates public key together. Once certificate is validated the client can used public key. RSA or ECDSA Certs: X.509, ASN.1 DER encoding. Server Hello, Certificate - Server selects cipher & compression method - Server send certificate - Client authenticates Key Exchange Pre-master secret exchanged between client & server, client validates certificate Master Secret Client & Server can compute Master Secret. MAC Server verifies MAC, returns to client to verify also. Finished Handshake complete. Client Hello Client sends TLS Version, Ciphersuites, Compression methods Ciphers, Standards and Terms Encryption 3DES, AES, ARIA, CAMELLIA, RC4, and SEED [1] Steam: adds MAC [2] Block: adds IV and padding after encryption [3] Encryption (AEAD): encryption and integrity validation, using nonce, no padding, no IV. Master Secret Pre-master secret: combines params to help client and server create master secret. Master Secret: both server and client create this from pre-master secret to symmetrically encrypt Integrity Validation PRF: Pseudorandom Function. Takes a secret, a seed, and a unique label. TLS1.2 suites use PRF based on HMAC and SHA256 MAC: used for integrity validation in handshake and record.
49. @thisNatasha
50. @thisNatasha TLS Record Type Version Length Header Data TLS Record TLS Header
51. @thisNatasha
52. @thisNatasha @thisNatasha Renegotiation New (encrypted) handshake with new security params requested... Why? - Requesting Client Certs - Benefit from fully encrypted handshake - Different encryption strength in different parts of the site.
53. @thisNatasha Weren’t we here to talk about performance?
54. @thisNatasha “People sometimes care about security, but they always care about speed; no one ever wanted their web site to be slower.” Ivan Ristić
55. @thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.
56. @thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.
57. @thisNatasha Mobile Network: - 3G 100-500ms latency to base station. - 4G < 100ms - 100 Mbits/s stationary - Waking from idle 100ms - Transatlantic cables: 99.7% the speed of light. - Transatlantic cables: latency < 100ms, 59ms.
58. @thisNatasha
59. @thisNatasha SYN Cli-ant Ser-ver SYN + ACK ACK Get /page TCP
60. @thisNatasha SYN (with cookie and GET) Cli-ant Ser-ver SYN + ACK (and data) TCP Fast Open
61. @thisNatasha Cli-ant Ser-ver TCP and TLS TCP Handshake [1] Client Hello Server Hello [2] Certificate [3] Server Key Exchange [4] Server Hello Done [5] [6] Client Key Exchange [7] (Change Cipher Spec) [8] Finished (Change Cipher Spec) [9] Finished [10] Get /page
62. @thisNatasha Cli-ant Ser-ver TCP and TLS with Session Tickets TCP Fast Open Handshake [1] Client Hello Server Hello [2] (Change Cipher Spec) [3] Finished [4] [5] (Change Cipher Spec) [6] Finished
63. @thisNatasha 2 Roundtrips Before anything is even sent
64. @thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.
65. @thisNatasha RTTs are EVIL. They make evil people do this:
66. @thisNatasha
67. @thisNatasha Cli-ant Ser-ver TCP and TLS with Session Tickets TCP Handshake [1] Client Hello Server Hello [2] (Change Cipher Spec) [3] Finished [4] [5] (Change Cipher Spec) [6] Finished
68. @thisNatasha Can Optimise TCP
69. @thisNatasha Optimise TCP - initcwnd around 10 segments - Slow start can restart, even after 1 second - Keep TCP Connections Open: Use Keep Alives (HTTP1.1)
70. @thisNatasha @thisNatasha Can Tune Server Keep Alives and Connections Ivan’s Tests: IE11 closes 30 secs Safari 7 after 60 secs Chrome 35 300 secs Firefox 30 when server closes.
71. @thisNatasha But you can’t control what browsers users use...
72. @thisNatasha New standards could help...
73. @thisNatasha @thisNatasha TLS False Start Send application data in Handshake 30% reduction in handshake latency Dangerous, failure Still in use Google Project
74. @thisNatasha SPDY HTTP2 QUIC Speed and security
75. @thisNatasha
76. @thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.
77. @thisNatasha CDN - Edge Caching - CDNs can manage connection - CDNs can optimise traffic
78. @thisNatasha CDN - Edge Caching - CDNs can manage connection - CDNs can optimise traffic
79. @thisNatasha CDN benefits outweigh any kind TLS tuning.
80. @thisNatasha @thisNatasha Throwing Money Solutions Then it’ll go away... CDNs Bigger Server Server Cluster
81. @thisNatasha Great, but what can we do with TLS?
82. @thisNatasha Cryptographic Operations do take (some) CPU time.
83. @thisNatasha @thisNatasha Optimising the Handshake Key Size: Longer keys - better protection - More CPU intensive Key Algorithm: RSA sucks. - RSA required strength too slow - ECDSA faster (3072 bit RSA) Key Exchange: RSA, DHE or ECDHE - RSA has no forward secrecy - DHE is slow - ECDHE is your friend (security and performance are influenced by named curve) Key Exchange
84. @thisNatasha
85. @thisNatasha @thisNatasha Performance Hits: size, must be validated, revocation checked Certificates Only include needed certs Make sure a complete chain can be created Use ECDSA certs (1kb shorter than RSA) Don’t use too many hostnames on the same cert
86. @thisNatasha When certs live out their lifetime they need to be “revoked”, how does the browser know?
87. @thisNatasha @thisNatasha Get your revocation info out quick, select a fast CA, and use OSCP stapling Revocation Checking CRL: Certificate Revocation Lists OSCP: Online Cert Status Protocol Browsers CRLs download can be 10secs OSCP certificate lookup in 1 request Use CAs with fast and reliable OCSP responders Use CAs which update their responders quickly OSCP Stapling (450 bytes on handshake)
88. @thisNatasha @thisNatasha Full handshake will happen once, rest will be abbreviated Session Resumption Server admin could: Configure session caching so sessions remain valid for a day Clients do the rest!
89. @thisNatasha Worst is over once the Handshake finishes.
90. @thisNatasha Transport Overhead
91. @thisNatasha TCP/IP overhead is 52 bytes per packet, properly implemented TLS is not much!
92. @thisNatasha IPv6 adds 72 bytes
93. @thisNatasha Symmetric Encryption Overhead AES_128_GCM
94. @thisNatasha Not all mobile devices run hardware-accelerated AES.
95. @thisNatasha
96. @thisNatasha
97. @thisNatasha Buffering Latency Application Payload (32kb) TLS Record (16kb) TLS Record (16kb) TCP Packet
98. @thisNatasha @thisNatasha TCP packets may arrive out-of-order Need to be buffered! Buffering Latency Extra time: - Buffering - TCP Recovery (extra RTT) - Overflowing initcwnd TLS Tuning (experiment!): - turn TLS record size down (16kb) - 4kb Better to leave to the web servers: - Discover MTU - They vary record size over connection lifetime
99. @thisNatasha @thisNatasha Inequality between client and server CPU time can be used to DoS (but more are moving to ECDHE_RSA or ECDHE_ECDSA) CPU time inequality RSA can be used to DoS (still uses RSA for auth) With ECDHE_ECDSA clients will then do 1.5 times more work
100. @thisNatasha Still sounds like TLS takes a lot of CPU energy...
101. @thisNatasha @thisNatasha In the Past - CPUs were slow - TLS (SSL) was heavy - Hardware Accelerators and Certs were expensive Now - Clients and Servers have fast processors, plenty of RAM - Hardware accelerators not needed - Certificates are cheap - Latency is most of the issue.
102. @thisNatasha So, CPU overhead is not your issue. RTTs and network latencies are.
103. @thisNatasha RTTs are EVIL. They make evil people do this:
104. @thisNatasha IS TLS Fast Yet? istlsfastyet.com
105. @thisNatasha So what can we do about these RTTs?
106. @thisNatasha TLS 1.3
107. @thisNatasha [1] Client Hello Cli-ant Ser-ver Server Hello [2] Encrypted Extensions [3] Certificate [4] Server Key Exchange [4] Certificate Verify [5] Finished [6] [6] Client Key Exchange [7] (Change Cipher Spec) [8] Finished (Change Cipher Spec) [9] Finished [10] TLS 1.3 Handshake
108. @thisNatasha [1] Client Hello (KeyShare Extension) Cli-ant Ser-ver (KeyShare Extension) Server Hello [2] Encrypted Extensions [3] Certificate [4] Server Key Exchange [4] Certificate Verify [5] Finished [6] [6] Client Key Exchange [7] (Change Cipher Spec) [8] Finished (Change Cipher Spec) [9] Finished [10] TLS 1.3 Handshake
109. @thisNatasha [1] Client Hello (KeyShare Extension) Cli-ant Ser-ver (KeyShare Extension) Server Hello [2] Encrypted Extensions [3] Certificate [4] Certificate Verify [5] Finished [6] [8] Finished TLS 1.3 Handshake
110. @thisNatasha 1 RTT Yay.
111. @thisNatasha @thisNatasha or/ Session Resumption TLS 1.3 Abbreviated handshake Identifiers and Tickets are obsolete! Replaces with PSK (pre- shared key mode) PSK created on previous connection after the handshake PSK then presented on next visit!
112. @thisNatasha [1] Client Hello (KeyShare & pre shared key) Cli-ant Ser-ver (pre shared key) Server Hello [2] Encrypted Extensions [3] (Change Cipher Spec) [3] Finished [4] [5] (Change Cipher Spec) [5] Finished TLS 1.3 Abbreviated Handshake (PSK)
113. @thisNatasha [1] Client Hello (KeyShare & pre shared key) Cli-ant Ser-ver (pre shared key) Server Hello [2] Encrypted Extensions [3] Finished [4] [5] Finished TLS 1.3 Abbreviated Handshake (PSK)
114. @thisNatasha 1 RTT Yay. Can we do better?
115. @thisNatasha [1] Client Hello (KeyShare & early data) [2] Finished [3] ApplicationData [4] end_of_early_data (alert) Cli-ant Ser-ver (KeyShare and early data) Server Hello [5] Encrypted Extensions [6] Server Configuration [7] Certificate [8] Certificate Verify [9] Finished [10] [11] Finished TLS 1.3 0-RTT Handshake
116. @thisNatasha Previous Connection: - Server sends ServerConfiguration after handshake - Includes: - Identifier - Semi-static (EC)DH parameters - Expiration - etc.
117. @thisNatasha [1] Client Hello (KeyShare & early data) [2] Finished [3] ApplicationData (as above) [4] end_of_early_data (alert) Cli-ant Ser-ver (KeyShare and early data) Server Hello [5] Encrypted Extensions [6] Server Configuration [7] Certificate [8] Certificate Verify [9] Finished [10] [11] Finished TLS 1.3 0-RTT Handshake
118. @thisNatasha O RTT Or same round-trip time as for an unencrypted HTTP request
119. @thisNatasha @thisNatasha Some Caveats 0-RTT Security No server random means replay attacks still possible 1 RTT needed to get ephemeral secret, so this has no Forward Secrecy MITM could tamper with 0-RTT data if key is compromised
120. @thisNatasha ACME / Let’s Encrypt
121. @thisNatasha ...webmasters often need 1-3 hours to obtain and install a certificate for a domain
122. @thisNatasha @thisNatasha Old Certificate way Issuance and Identity Verification - Generate a Certificate Signing Request (CSR). - ⌘C⌘V CSR into a CA webpage - Prove domain ownership by: - Put a CA-provided challenge on the web server. - Put a CA-provided challenge at a DNS location (target domain) - Receive CA challenge via e- mail corresponding to the domain and respond - Download the certificate and install
123. @thisNatasha
124. @thisNatasha
125. @thisNatasha This is accomplished by running a certificate management agent on the web server.
126. @thisNatasha @thisNatasha ACME Process https://example.com/ Domain Validation Agent proves to CA that the web server controls the domain Certifcate Issuance and Revocation Agent requests, renews and revoke certificates
127. @thisNatasha @thisNatasha Domain Validation Used to be done by email... Agent creates new key pair Proves to CA it has access to server CA asks domain to complete “challenges”: - Agent creates a file on server - CA provides a nonce - Agent signs nonce with private key - Agent tells CA it’s ready to complete validation
128. @thisNatasha Certificate Issuance and Revocation - Thank-you public key crypto! Issue Certificate - Agent asks CA to issue a cert with a public key - Agent also authorises by signing with authorised key - CA verifies both signatures - CA issues cert with public key from CSR CSR: PKCS#10 Certificate Signing Request Revoke Certificate - Agent signs revocation request with key pair - CA verifies authorisation - CA publishes to CRL, OCSP - Browsers learn they shouldn’t accept cert CRL, OCSP
129. @thisNatasha
130. @thisNatasha Setting Up TLS.
131. @thisNatasha
132. @thisNatasha Recap
133. @thisNatasha Lots of Poppies - Public Key Crypto - TLS History - TLS 1.2 - Evil RTTs - TLS Config - TLS 1.3 - ACME / Let’s Encrypt - @supersole - Sleep.
134. @thisNatasha
135. @thisNatasha Thank-you People: Ivan Ristic, Eric Rescola, Patrick McManus, Mark Nottingham, Tim Taubert, Ilya Grigorik, Yan Zhu.