Download as PDF, PPTX
![@thisNatasha
Handshake Flow
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Key Exchange
Authentication Algorithm Strength Mode
Cipher MAC or PRF
TLS/HandshakeCheatSheet 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.](https://image.slidesharecdn.com/perf-190728182443/85/Evolving-HTTP-and-making-things-QUIC-111-320.jpg)
![@thisNatasha
Handshake Flow
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Key Exchange
Authentication Algorithm Strength Mode
Cipher MAC or PRF
TLS/HandshakeCheatSheet 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.](https://image.slidesharecdn.com/perf-190728182443/85/Evolving-HTTP-and-making-things-QUIC-142-320.jpg)
![@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](https://image.slidesharecdn.com/perf-190728182443/85/Evolving-HTTP-and-making-things-QUIC-143-320.jpg)
![@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](https://image.slidesharecdn.com/perf-190728182443/85/Evolving-HTTP-and-making-things-QUIC-144-320.jpg)
![@thisNatasha
Cryptographic handshake
● authenticated key exchange, where
○ a server is always authenticated,
○ a client is optionally authenticated,
○ every connection produces distinct and unrelated keys,
○ keying material is usable for packet protection for both 0-RTT and 1-RTT packets, and
○ 1-RTT keys have forward secrecy
●
● authenticated values for the transport parameters of the peer (see Section 7.3)
● authenticated confirmation of version negotiation (see Section 7.3.3)
● authenticated negotiation of an application protocol (TLS uses ALPN [RFC7301]for this purpose)](https://image.slidesharecdn.com/perf-190728182443/85/Evolving-HTTP-and-making-things-QUIC-146-320.jpg)
Uploaded byNatasha Rooney
Evolving HTTP and making things QUIC
This document summarizes Natasha Rooney's presentation on QUIC and the evolution of HTTP. Some key points include: - QUIC aims to improve performance over TCP by eliminating head-of-line blocking and reducing latency through 0-RTT connections. - It achieves this by multiplexing streams over a UDP connection and integrating TLS 1.3 for encryption to provide security. - Early results show QUIC reducing page load times by 15-18% for video and 3.6-8% for search queries on Google's services. - As QUIC becomes more widely adopted, it may continue to improve performance for a "long tail" of users on slower or more unreliable networks.
More Related Content
Similar to Evolving HTTP and making things QUIC
Evolving HTTP and making things QUIC
- 1. @thisNatasha Down the Line: evolvingHTTP and making things QUIC Natasha Rooney on version negotiation, end-point capabilties, and successful TLS handshake.”
- 2.
- 3.
- 4. @thisNatasha Protocols: a set ofinstructions
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. @thisNatasha Only one way! Andas the crow flies...
- 13.
- 14.
- 15.
- 16. @thisNatasha Mobile Network (notwifi) The Internet
- 17.
- 18.
- 19.
- 20.
- 21. @thisNatasha@thisNatasha Distance Capped by Speedof Light Amount of Data >100 objects per page 800k to 2.5mb data >50 resources on same domain
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. @thisNatasha Wasting bytes, wasting time. TCPsetup, HTTP and TCP headers, waiting on HTTP response before sending again, not fit for today’s internet!
- 42.
- 43.
- 44.
- 45.
- 46. @thisNatasha@thisNatasha SPDY A Protocol byGoogle 2009 Header Compression Parallel Connections Multiplexing Priority Marking Server Push TLS (to work)
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. @thisNatasha “Idea was tomaintain HTTP semantics but change how it is transported.” Daniel Stenberg https://daniel.haxx.se/blog/
- 53.
- 54.
- 55. @thisNatasha@thisNatasha HTTP2 A Protocol byIETF (SDPY base) Binary Header Compression Multiplexing Server Push TLS...
- 56. @thisNatasha@thisNatasha HTTP2 A Protocol byIETF (SDPY base)
- 57.
- 58. @thisNatasha@thisNatasha Stats Gimme gimme 35% Requests 70%HTTPS Connections 13% Top 1,000,000 Sites 29% Top 1000 Sites “90% your site”
- 59. @thisNatasha 2% packet loss HTTP1is better.
- 60. @thisNatasha Mobile Network (notwifi) The Internet
- 61. @thisNatasha Head of LineBlocking Problem for HTTP and TCP
- 62.
- 63. @thisNatasha TCP: In order,reliable protocol. Image Source: http://ariecazz.blogspot.com/2015/02/protokol-tcp-dan-udp.html
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73. @thisNatasha “We want QUICto work on today’s internet” Jana Iyengar QUIC Editor, Fastly
- 74.
- 75.
- 76.
- 77. @thisNatasha@thisNatasha TCP Suffers from Head ofLine Blocking UDP Can work...with help. Transport Layer
- 78. @thisNatasha TCP: In order,reliable protocol. Image Source: http://ariecazz.blogspot.com/2015/02/protokol-tcp-dan-udp.html
- 79. @thisNatasha UDP is nota transport. UDP is a way to build a transport - it has no function alone.
- 80.
- 81. @thisNatasha@thisNatasha TCP Suffers from Head ofLine Blocking UDP Can work...with help. Transport Layer
- 82.
- 83.
- 84. @thisNatasha HTTP/2 TLS 1.2+ TCP IP HTTP overQUIC QUIC UDP TLS 1.3
- 85.
- 86. @thisNatasha HTTP/2 QUIC TLS 1.3 HTTP/2 QUIC TLS 1.3 TCPConnection UDP Connection
- 87. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 88. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 89. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 90. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3 Head of Line Blocking! Multiplexing! ✓
- 91. @thisNatasha Connection establishment. Lots of RTTs. Especiallywhen we encrypt.
- 92. @thisNatasha Round Trips areEvil Killer for Connection Establishment
- 93.
- 94.
- 95. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 96.
- 97.
- 98. @thisNatasha The Internet can be unreliable. Stuffgets lost. Networks get blocked.
- 99.
- 100. @thisNatasha ACK Based - EstimateRTT - Retransmit when ACK not received after RTT estimate threshold Timer Based - Aggressive CRYPTO retransmission - Tail Loss Probe - Retransmission timer Loss Detection
- 101.
- 102. @thisNatasha Slow Start CongestionAvoidance
- 103.
- 104.
- 105.
- 106. @thisNatasha HTTP/2 TLS 1.2+ TCP IP HTTP overQUIC QUIC UDP TLS 1.3
- 107.
- 108. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 109.
- 110.
- 111. @thisNatasha Handshake Flow TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key Exchange AuthenticationAlgorithm Strength Mode Cipher MAC or PRF TLS/HandshakeCheatSheet 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.
- 112. @thisNatasha QUIC: encrypt everythingpossible. Security & Ossification
- 113. @thisNatasha Traffic Amplification Address validation with bytelimitation Spoofing Path validation during connection migration Passive Observation Changing Connection IDs. Encryption. Limited data till sure of encryption and valid path. Denial of Service Authentication through encrypted handshake Stream Commitment Active streams is limited by the concurrent stream limit transport parameter. Explicit Congestion Notification Attacks Ignore duplicate ECN packets Downgrade Three fields that encode version information, included in TLS handshake also. Packet Reflection Authenticate source address, strictly limiting UDP datagrams in first flight Attack Mitigation
- 114.
- 115.
- 116.
- 117.
- 118. @thisNatasha 7% Internet Traffic 35%Google Egress Traffic
- 119.
- 120.
- 121.
- 122.
- 123.
- 124. @thisNatasha IP HTTP over QUIC QUIC UDP TLS1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 125.
- 126.
- 127.
- 128.
- 129.
- 130. @thisNatasha@thisNatasha Quic What’s next? Standardised thisweek? Spin bit DNS over QUIC WebRTC over QUIC
- 131. @thisNatasha How does thisaffect me?
- 132. @thisNatasha Abstraction Is a computerscientist’s friend / fiend
- 133.
- 134.
- 135.
- 136. @thisNatasha@thisNatasha Some things If youhave to do something... Manage your resources logically Detect on upgrade header and adapt Measure Remember Physics!
- 137. @thisNatasha Thank-you People: Martin Thomson,Mark Nottingham, Jana Iyengar, Mike Bishop, Eric Rescola, Ian Swett
- 138.
- 139.
- 140.
- 141. @thisNatasha 7. Application DataHTTP / 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
- 142. @thisNatasha Handshake Flow TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key Exchange AuthenticationAlgorithm Strength Mode Cipher MAC or PRF TLS/HandshakeCheatSheet 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.
- 143. @thisNatasha [1] Client Hello Cli-antSer-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
- 144. @thisNatasha Cli-ant Ser-ver TCP andTLS 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
- 145. @thisNatasha TLS Encryption Levels ●CRYPTO frames MAY appear in packets of any encryption level except 0-RTT. ● CONNECTION_CLOSE MAY appear in packets of any encryption level other than 0-RTT. ● APPLICATION_CLOSE MAY appear in packets of any encryption level other than Initial and 0-RTT. ● PADDING frames MAY appear in packets of any encryption level. ● ACK frames MAY appear in packets of any encryption level other than 0-RTT, but can only acknowledge packets which appeared in that packet number space. ● STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels. ● All other frame types MUST only appear at the 1-RTT levels.
- 146. @thisNatasha Cryptographic handshake ● authenticatedkey exchange, where ○ a server is always authenticated, ○ a client is optionally authenticated, ○ every connection produces distinct and unrelated keys, ○ keying material is usable for packet protection for both 0-RTT and 1-RTT packets, and ○ 1-RTT keys have forward secrecy ● ● authenticated values for the transport parameters of the peer (see Section 7.3) ● authenticated confirmation of version negotiation (see Section 7.3.3) ● authenticated negotiation of an application protocol (TLS uses ALPN [RFC7301]for this purpose)
- 147.
- 148.
- 149.