@thisNatasha TLS Perf: from three to zero in one spec Natasha Rooney, @thisNatasha

@thisNatasha

@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.

@thisNatasha Why do i need ssl/tls?

@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

@thisNatasha Quick intro to Public Key Cryptography

@thisNatasha Let’s get that Pikachu! Jessie James

@thisNatasha @thisNatasha Symmetric Crypto (Caesar Cipher)

@thisNatasha Key = 3 Let’s get that Pikachu! = Ohw’v jhw wkdw Slndfkx! Jessie James

@thisNatasha Key = 3 Let’s get that Pikachu! = Ohw’v jhw wkdw Slndfkx! Jessie James

@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!

@thisNatasha @thisNatasha Asymmetric Crypto 2 Keys 1 Secret Key (keep it to yourself!) 1 Public Key (share with others)

@thisNatasha Jessie James PUBLIC

@thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... PUBLIC PUBLIC

@thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! PUBLIC PUBLIC

@thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! PUBLIC PUBLIC PUBLIC 1cd87b63a2a933ca2...

@thisNatasha

@thisNatasha Does this key really belong to james? PUBLIC

@thisNatasha @thisNatasha Certs Certificate Authority (CA) issues a Certificate CA checks James’s identity Digicert, Versign (but anyone can be a CA)

@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 ...

@thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! Giant Meowth Certificate Authority PUBLIC PUBLIC

@thisNatasha

@thisNatasha Jessie James Let’s get that Pikachu! 1cd87b63a2a933ca2... Let’s get that Pikachu! Giant Meowth Certificate Authority PUBLIC PUBLIC

@thisNatasha @thisNatasha SSL / TLS Also use Public Key Cryptography HTTPS

@thisNatasha TLS History.

@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

@thisNatasha @thisNatasha SSL (TLS is the same, just later versions) SSLv1 Netscape 1994: SSLv2 Netscape Navigator 1.1 SSLv2 Security poor 1995: SSLv3

@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

@thisNatasha

@thisNatasha @thisNatasha TLS Aims Not just crypto... Cryptographic Security Interoperability Extensibility Efficiency

@thisNatasha @thisNatasha TLS Aims Don’t have a TIF Message tampering Message interception Message forgery

@thisNatasha @thisNatasha TLS Basics Not just crypto... 1. Handshake including authentication and key exchange 2. Data exchange 3. Shutdown

@thisNatasha Er, I can see why this take some time...

@thisNatasha TLS 1.2

@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)

@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.

@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

@thisNatasha

@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

@thisNatasha 2 Roundtrips And a lotta CPU...

@thisNatasha @thisNatasha Abbreviated Handshake Session Resumption Client and Server keep session security params Session ID Sent in ServerHello Client sends in next ClientHello

@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

@thisNatasha 1 Roundtrip A lot nicer

@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

@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.

@thisNatasha @thisNatasha Encryption Usually AES, 3 types. 3DES, AES, ARIA, CAMELLIA, RC4, and SEED AES most popular Types: - Stream - Block - Authenticated (associated AEAD)

@thisNatasha Authenticated Encryption Seq Num Header Header Nonce Ciphertext Plaintext Authenticate Encrypt

@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.

@thisNatasha

@thisNatasha TLS Record Type Version Length Header Data TLS Record TLS Header

@thisNatasha

@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.

@thisNatasha Weren’t we here to talk about performance?

@thisNatasha “People sometimes care about security, but they always care about speed; no one ever wanted their web site to be slower.” Ivan Ristić

@thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.

@thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.

@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.

@thisNatasha

@thisNatasha SYN Cli-ant Ser-ver SYN + ACK ACK Get /page TCP

@thisNatasha SYN (with cookie and GET) Cli-ant Ser-ver SYN + ACK (and data) TCP Fast Open

@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

@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

@thisNatasha 2 Roundtrips Before anything is even sent

@thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.

@thisNatasha RTTs are EVIL. They make evil people do this:

@thisNatasha

@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

@thisNatasha Can Optimise TCP

@thisNatasha Optimise TCP - initcwnd around 10 segments - Slow start can restart, even after 1 second - Keep TCP Connections Open: Use Keep Alives (HTTP1.1)

@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.

@thisNatasha But you can’t control what browsers users use...

@thisNatasha New standards could help...

@thisNatasha @thisNatasha TLS False Start Send application data in Handshake 30% reduction in handshake latency Dangerous, failure Still in use Google Project

@thisNatasha SPDY HTTP2 QUIC Speed and security

@thisNatasha

@thisNatasha @thisNatasha BANDWIDTH Can buy more of this LATENCY This still stings. Bad.

@thisNatasha CDN - Edge Caching - CDNs can manage connection - CDNs can optimise traffic

@thisNatasha CDN - Edge Caching - CDNs can manage connection - CDNs can optimise traffic

@thisNatasha CDN benefits outweigh any kind TLS tuning.

@thisNatasha @thisNatasha Throwing Money Solutions Then it’ll go away... CDNs Bigger Server Server Cluster

@thisNatasha Great, but what can we do with TLS?

@thisNatasha Cryptographic Operations do take (some) CPU time.

@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

@thisNatasha

@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

@thisNatasha When certs live out their lifetime they need to be “revoked”, how does the browser know?

@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)

@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!

@thisNatasha Worst is over once the Handshake finishes.

@thisNatasha Transport Overhead

@thisNatasha TCP/IP overhead is 52 bytes per packet, properly implemented TLS is not much!

@thisNatasha IPv6 adds 72 bytes

@thisNatasha Symmetric Encryption Overhead AES_128_GCM

@thisNatasha Not all mobile devices run hardware-accelerated AES.

@thisNatasha

@thisNatasha

@thisNatasha Buffering Latency Application Payload (32kb) TLS Record (16kb) TLS Record (16kb) TCP Packet

@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

@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

@thisNatasha Still sounds like TLS takes a lot of CPU energy...

@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.

@thisNatasha So, CPU overhead is not your issue. RTTs and network latencies are.

@thisNatasha RTTs are EVIL. They make evil people do this:

@thisNatasha IS TLS Fast Yet? istlsfastyet.com

@thisNatasha So what can we do about these RTTs?

@thisNatasha TLS 1.3

@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

@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

@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

@thisNatasha 1 RTT Yay.

@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!

@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)

@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)

@thisNatasha 1 RTT Yay. Can we do better?

@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

@thisNatasha Previous Connection: - Server sends ServerConfiguration after handshake - Includes: - Identifier - Semi-static (EC)DH parameters - Expiration - etc.

@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

@thisNatasha O RTT Or same round-trip time as for an unencrypted HTTP request

@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

@thisNatasha ACME / Let’s Encrypt

@thisNatasha ...webmasters often need 1-3 hours to obtain and install a certificate for a domain

@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

@thisNatasha

@thisNatasha

@thisNatasha This is accomplished by running a certificate management agent on the web server.

@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

@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

@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

@thisNatasha

@thisNatasha Setting Up TLS.

@thisNatasha

@thisNatasha Recap

@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.

@thisNatasha

@thisNatasha Thank-you People: Ivan Ristic, Eric Rescola, Patrick McManus, Mark Nottingham, Tim Taubert, Ilya Grigorik, Yan Zhu.