1 of 106

Solving HTTP Problems With Code and Protocols

NATASHA ROONEY

@thisNatasha

2 of 106

HTTP

TLS

TCP

IP

Web

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

@thisNatasha

3 of 106

Some fundamental limitations

@thisNatasha

4 of 106

300,000,000 m/s

@thisNatasha

5 of 106

300,000,000 m/s

Speed of Light

@thisNatasha

6 of 106

300km, 1ms

@thisNatasha

7 of 106

10ms

@thisNatasha

8 of 106

10ms

5G

@thisNatasha

9 of 106

Only one way!

And as the crow flies...

@thisNatasha

10 of 106

Hops

@thisNatasha

11 of 106

Not good enough!

@thisNatasha

12 of 106

CDNs, Edge

@thisNatasha

13 of 106

Mobile Network (not wifi)

The Internet

@thisNatasha

14 of 106

Amount of data

@thisNatasha

15 of 106

@thisNatasha

16 of 106

@thisNatasha

17 of 106

@thisNatasha

18 of 106

@thisNatasha

19 of 106

Speed & Distance

Amount of Data

Capped by Speed of Light

>100 objects per site

800k to 2.5mb data

>50 resources on same domain

@thisNatasha

20 of 106

RTs are Evil

Mostly because of physics. Not much you can do about that.

@thisNatasha

21 of 106

HTTP/1

@thisNatasha

22 of 106

HTTP/1

TLS

TCP

IP

HTTP/1

TLS

TCP

Request

@thisNatasha

23 of 106

HTTP/1

TLS

TCP

IP

HTTP/1

TLS

TCP

Request

Response

@thisNatasha

24 of 106

HTTP/1

TLS

TCP

IP

HTTP/1

TLS

TCP

Request

Response

Request

@thisNatasha

25 of 106

@thisNatasha

26 of 106

@thisNatasha

27 of 106

Urgh...

@thisNatasha

28 of 106

Spriting

@thisNatasha

29 of 106

Inlining

@thisNatasha

30 of 106

@thisNatasha

31 of 106

Image source: @jungkees

@thisNatasha

32 of 106

Pipelining

@thisNatasha

33 of 106

Home

Roads

Supermarket

@thisNatasha

34 of 106

Home

Roads

Supermarket

@thisNatasha

35 of 106

HTTP/1

TLS

TCP

IP

HTTP/1

TLS

TCP

TCP Setup

TLS Setup

HTTP Request/Response

@thisNatasha

36 of 106

HTTP/2

@thisNatasha

37 of 106

SPDY

@thisNatasha

38 of 106

Home

Roads

Supermarket

@thisNatasha

39 of 106

Home

Roads

Supermarket

@thisNatasha

40 of 106

SPDY

A Protocol by Google

2009

Header Compression

Parallel Connections

Multiplexing

Priority Marking

Server Push

TLS (to work)

@thisNatasha

41 of 106

SPDY

A Protocol by Google

Header Compression

@thisNatasha

42 of 106

@thisNatasha

43 of 106

@thisNatasha

44 of 106

@thisNatasha

45 of 106

@thisNatasha

46 of 106

HTTP/2

@thisNatasha

47 of 106

“Idea was to maintain HTTP semantics but change how it is transported.”

Daniel Stenberg

https://daniel.haxx.se/blog/

@thisNatasha

48 of 106

Home

Roads

Supermarket

@thisNatasha

49 of 106

Home

Roads

Supermarket

@thisNatasha

50 of 106

HTTP/1

TLS

TCP

IP

HTTP/1

TLS

TCP

Request

Response

Request

@thisNatasha

51 of 106

HTTP2

A Protocol by IETF

(SDPY base)

Binary

Header Compression

Multiplexing

Server Push

TLS...

@thisNatasha

52 of 106

HTTP2

A Protocol by IETF

(SDPY base)

@thisNatasha

53 of 106

@thisNatasha

54 of 106

Stats

Gimme gimme

35% Requests

70% HTTPS Connections

13% Top 1,000,000 Sites

29% Top 1000 Sites

“90% your site”

@thisNatasha

55 of 106

2% packet loss

HTTP1 is better.

@thisNatasha

56 of 106

Head of line blocking

@thisNatasha

57 of 106

Home

Roads

Supermarket

@thisNatasha

58 of 106

Home

Roads

Supermarket

@thisNatasha

59 of 106

Home

Roads

Supermarket

Not good enough!

@thisNatasha

60 of 106

Home

Roads

Supermarket

Not good enough!

@thisNatasha

61 of 106

TCP issue

(Can happen on any protocol with in-order delivery)

@thisNatasha

62 of 106

QUIC

@thisNatasha

63 of 106

“Idea was to maintain HTTP semantics but change how it is transported.”

Daniel Stenberg

https://daniel.haxx.se/blog/

@thisNatasha

64 of 106

Home

Roads

Supermarket

TCP

@thisNatasha

65 of 106

TCP

UDP

Transport Layer

Suffers from

Head of Line Blocking

Can work...with help.

@thisNatasha

66 of 106

“We want QUIC to work on today’s internet”

Jana Iyengar

QUIC Editor, Google

@thisNatasha

67 of 106

Ossification

@thisNatasha

68 of 106

Why TCP or UDP only?

@thisNatasha

69 of 106

Image source: http://itpro.nikkeibp.co.jp/

@thisNatasha

70 of 106

HTTP/2

TLS 1.2+

TCP

IP

Application

QUIC

UDP

Google Crypto

Congestion Control

@thisNatasha

71 of 106

HTTP/2

TLS 1.2+

TCP

IP

Application

QUIC

UDP

Google Crypto

Congestion Control

@thisNatasha

72 of 106

QUIC

A Protocol by Google

Goo

@thisNatasha

73 of 106

HTTP/2

TLS 1.2+

TCP

IP

HTTP over QUIC

QUIC

UDP

TLS 1.3

@thisNatasha

74 of 106

“A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection…

A single HTTP/2 connection can contain multiple concurrently open streams…”

Hypertext Transfer Protocol Version 2 (HTTP/2), RFC7540

@thisNatasha

75 of 106

Image source: High Performance Browser Networking https://hpbn.co/http2/

@thisNatasha

76 of 106

IP

HTTP over QUIC

QUIC

UDP

TLS 1.3

HTTP over QUIC

QUIC

UDP

TLS 1.3

@thisNatasha

77 of 106

IP

HTTP over QUIC

QUIC

UDP

TLS 1.3

HTTP over QUIC

QUIC

UDP

TLS 1.3

@thisNatasha

78 of 106

IP

HTTP over QUIC

QUIC

UDP

TLS 1.3

HTTP over QUIC

QUIC

UDP

TLS 1.3

@thisNatasha

79 of 106

IP

HTTP over QUIC

QUIC

UDP

TLS 1.3

HTTP over QUIC

QUIC

UDP

TLS 1.3

Head of Line

Blocking!

@thisNatasha

80 of 106

RTs are Evil

Mostly because of physics. Not much you can do about that.

@thisNatasha

81 of 106

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

@thisNatasha

82 of 106

Reduce the RTs!

@thisNatasha

83 of 106

@thisNatasha

84 of 106

@thisNatasha

85 of 106

7% Internet Traffic

35% Google Egress Traffic

@thisNatasha

86 of 106

How does this affect me?

@thisNatasha

87 of 106

Abstraction

Is a computer scientist’s friend / fiend

@thisNatasha

88 of 106

Layer Violation

@thisNatasha

89 of 106

HTTP

TLS

TCP

IP

Web

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

@thisNatasha

90 of 106

Some things

If you have to do something...

Manage your resources logically

Detect on upgrade header and adapt

Measure

Remember Physics!

@thisNatasha

91 of 106

Recap

We made it!

RTTs, Physics, Data

SPDY, HTTP2, QUIC

Header compression

Multiplexing & Streams

Head of Line Blocking

Make protocols for today’s internet

@thisNatasha

92 of 106

3

@thisNatasha

93 of 106

@thisNatasha

94 of 106

@thisNatasha

95 of 106

@thisNatasha

96 of 106

Thank-you

People: Martin Thomson, Mark Nottingham, Jana Iyengar, Mike Bishop, Eric Rescola, Ian Swett

@thisNatasha

97 of 106

@thisNatasha

98 of 106

@thisNatasha

99 of 106

@thisNatasha

100 of 106

OSI Model

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

@thisNatasha

101 of 106

TLS / Handshake Cheat Sheet

Handshake Flow

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Key Exchange

Authentication

Algorithm

Strength

Mode

Cipher

MAC or PRF

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

Handshake is based on full

Cipher suite name construction

TLS 1.2 fully configurable

ECDHE: elliptic curve diffie-hellman key exchange

ECDSA: Elliptic Curve Digital Signature Algorithm

Ciphers:

Authentication method
Key exchange method
Encryption algorithm
Encryption key size
Cipher mode (when applicable)
MAC algorithm (when applicable)
PRF (TLS 1.2 only—depends on the protocol otherwise)
Hash function used for the Finished message (TLS 1.2)
Length of the verify_data structure (TLS 1.2)

Three types of encryption are supported:

Stream adds a MAC
Block is add IV and padding after encryption
Authentication (with assoicated AEAD) combines encryption and integrity validation, no padding, no IV, use a nonce

GCM and CCM ciphers are used
Generate a nonce, encrypt the plaintext, feed the seq number and record header for integrity, send nonce and ciphertext together.

The client then encrypts the so-called premaster secret with the server’s public key found in the certificate and wraps it in a ClientKeyExchange message. ChangeCipherSpec signals that from now on messages will be encrypted. Finished, the first message to be encrypted and the client’s last message of the handshake, contains a MAC of all handshake messages exchanged thus far to prove that both parties saw the same messages, without interference from a MITM.

The server decrypts the premaster secret found in the ClientKeyExchange message using its certificate’s private key, and derives the master secret and communication keys. It then too signals a switch to encrypted communication and completes the handshake. It takes two round-trips to establish a connection.

Diffie Hellamn: adds ServerKeyExchange message. This message contains either the parameters of a DH group or of an elliptic curve, paired with an ephemeral public key computed by the server. The client too computes an ephemeral public key compatible with the given parameters and sends it to the server. Knowing their private keys and the other party’s public key both sides should now share the same premaster secret and can derive a shared master secret.

Authentication: With static RSA key exchanges, the connection is authenticated by encrypting the premaster secret with the server certificate’s public key. Only the server in possession of the private key can decrypt, correctly derive the master secret, and send an encrypted Finished message with the right MAC.

Authentication: With (EC)DH key exchanges it’s still the certificate that must be signed by a CA listed in the client’s trust store. To authenticate the connection the server will sign the parameters contained in ServerKeyExchange with the certificate’s private key. The client verifies the signature with the certificate’s public key and only then proceeds with the handshake.

Master secret construction: The processing occurs because the premaster secret might differ in size depending on the key exchange method used. Also, because the client and server random fields are used as the seed, the master secret is also effectively random [ 54 ] and bound to the negotiated handshake.

102 of 106

Cli-ant

Ser-ver

TLS 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]

@thisNatasha

103 of 106

Cli-ant

Ser-ver

TCP and TLS with Session Tickets

[1] Client Hello

Server Hello [2]

(Change Cipher Spec) [3]

Finished [4]

[5] (Change Cipher Spec)

[6] Finished

TCP Fast Open Handshake

@thisNatasha

104 of 106

@thisNatasha

105 of 106

Transport Overhead

@thisNatasha

106 of 106

Min

@thisNatasha