Evolving HTTP and making things QUIC
0 likes99 views
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.
![@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)
Evolving HTTP and making things QUIC
- 1. @thisNatasha Down the Line: evolving HTTP and making things QUIC Natasha Rooney on version negotiation, end-point capabilties, and successful TLS handshake.”
- 4. @thisNatasha Protocols: a set of instructions
- 5. @thisNatasha
- 12. @thisNatasha Only one way! And as the crow flies...
- 16. @thisNatasha Mobile Network (not wifi) The Internet
- 17. @thisNatasha@thisNatasha Distance Capped by Speed of Light
- 18. @thisNatasha
- 19. @thisNatasha
- 20. @thisNatasha
- 21. @thisNatasha@thisNatasha Distance Capped by Speed of Light Amount of Data >100 objects per page 800k to 2.5mb data >50 resources on same domain
- 27. @thisNatasha
- 28. @thisNatasha
- 33. @thisNatasha
- 34. @thisNatasha
- 39. @thisNatasha HTTP/1 TLS TCP IP HTTP/1 TLS TCP TCP Setup TLS Setup HTTP Request/Response
- 40. @thisNatasha
- 41. @thisNatasha Wasting bytes, wasting time. TCP setup, HTTP and TCP headers, waiting on HTTP response before sending again, not fit for today’s internet!
- 46. @thisNatasha@thisNatasha SPDY A Protocol by Google 2009 Header Compression Parallel Connections Multiplexing Priority Marking Server Push TLS (to work)
- 47. @thisNatasha
- 48. @thisNatasha
- 49. @thisNatasha
- 50. @thisNatasha
- 52. @thisNatasha “Idea was to maintain HTTP semantics but change how it is transported.” Daniel Stenberg https://daniel.haxx.se/blog/
- 55. @thisNatasha@thisNatasha HTTP2 A Protocol by IETF (SDPY base) Binary Header Compression Multiplexing Server Push TLS...
- 56. @thisNatasha@thisNatasha HTTP2 A Protocol by IETF (SDPY base)
- 57. @thisNatasha
- 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 HTTP1 is better.
- 60. @thisNatasha Mobile Network (not wifi) The Internet
- 61. @thisNatasha Head of Line Blocking Problem for HTTP and TCP
- 63. @thisNatasha TCP: In order, reliable protocol. Image Source: http://ariecazz.blogspot.com/2015/02/protokol-tcp-dan-udp.html
- 70. @thisNatasha 3
- 73. @thisNatasha “We want QUIC to work on today’s internet” Jana Iyengar QUIC Editor, Fastly
- 76. @thisNatasha
- 77. @thisNatasha@thisNatasha TCP Suffers from Head of Line 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 not a transport. UDP is a way to build a transport - it has no function alone.
- 81. @thisNatasha@thisNatasha TCP Suffers from Head of Line Blocking UDP Can work...with help. Transport Layer
- 83. @thisNatasha@thisNatasha QUIC A Protocol by Google Goo
- 84. @thisNatasha HTTP/2 TLS 1.2+ TCP IP HTTP over QUIC QUIC UDP TLS 1.3
- 86. @thisNatasha HTTP/2 QUIC TLS 1.3 HTTP/2 QUIC TLS 1.3 TCP Connection UDP Connection
- 87. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 88. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 89. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3
- 90. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 Head of Line Blocking! Multiplexing! ✓
- 91. @thisNatasha Connection establishment. Lots of RTTs. Especially when we encrypt.
- 92. @thisNatasha Round Trips are Evil Killer for Connection Establishment
- 94. @thisNatasha HTTP/1 TLS TCP IP HTTP/1 TLS TCP TCP Setup TLS Setup HTTP Request/Response
- 95. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 97. @thisNatasha
- 98. @thisNatasha The Internet can be unreliable. Stuff gets lost. Networks get blocked.
- 100. @thisNatasha ACK Based - Estimate RTT - Retransmit when ACK not received after RTT estimate threshold Timer Based - Aggressive CRYPTO retransmission - Tail Loss Probe - Retransmission timer Loss Detection
- 102. @thisNatasha Slow Start Congestion Avoidance
- 106. @thisNatasha HTTP/2 TLS 1.2+ TCP IP HTTP over QUIC QUIC UDP TLS 1.3
- 108. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 111. @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.
- 112. @thisNatasha QUIC: encrypt everything possible. Security & Ossification
- 113. @thisNatasha Traffic Amplification Address validation with byte limitation 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
- 115. @thisNatasha
- 116. @thisNatasha
- 117. @thisNatasha
- 118. @thisNatasha 7% Internet Traffic 35% Google Egress Traffic
- 119. @thisNatasha
- 120. @thisNatasha
- 121. @thisNatasha Video Rebuffers 15 - 18%
- 122. @thisNatasha Search Latency 3.6 - 8%
- 124. @thisNatasha IP HTTP over QUIC QUIC UDP TLS 1.3 HTTP over QUIC QUIC UDP TLS 1.3 0RTT: Setup + Data 2RTT: If QUIC version negotiation needed 1RTT: New Crypto Keys
- 126. @thisNatasha
- 127. @thisNatasha
- 129. @thisNatasha
- 130. @thisNatasha@thisNatasha Quic What’s next? Standardised this week? Spin bit DNS over QUIC WebRTC over QUIC
- 131. @thisNatasha How does this affect me?
- 132. @thisNatasha Abstraction Is a computer scientist’s friend / fiend
- 136. @thisNatasha@thisNatasha Some things If you have 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
- 139. @thisNatasha
- 140. @thisNatasha
- 141. @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
- 142. @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.
- 143. @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
- 144. @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
- 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 ● 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)
- 148. @thisNatasha