SharkFest ’17 Europe
20 QUIC Dissection
Using Wireshark to
Understand QUIC
Quickly
Megumi Takeshita
ParkSuite Classroom
11 November 201711:15am-12:30pm

ikeriri network service
supplemental files
http://www.ikeriri.ne.jp/sharkfest#sf17eu • Estoril, Portugal#sf17eu
Quick
Dissection
Using •Wireshark
to Understand• Estoril,
Portugal
7-10 november
2017 QUIC Quickly

1

Megumi Takeshita, ikeriri network service
•
•
•

•
•

#sf17eu • Estoril, Portugal

Founder, ikeriri network service co.,ltd
Wrote 10+ books about Wireshark
Reseller of Riverbed Technology ( former
CACE technologies ) in Japan
Attending all Sharkfest
Translator of QT Wireshark into Japanese

Quick Dissection Using Wireshark to Understand QUIC Quickly2

20 QUIC: Using Wireshark to Understand QUIC Quickly
In this presentation, Megumi explains the details
of QUIC, and shows you how to understand theprotocol and mechanisms involved.
Using sample trace files, Megumi will show how
to inspect and visualize QUIC traffic and explain
the advantage of QUIC in comparison with otherprotocols too.
NOTE: IQUIC(IETF QUIC) is Internet-Draft andnow standardizing, so some specification may bechanged and the sample trace file is notadequate#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

3 3

Set up environment• For QUIC dissection, we need nightly build version of
Wireshark ( this time I use 2.5.0-1547-gbe625b9b
development version)• All supplemental files of this presentation is below
http://www.ikeriri.ne.jp/sharkfest (temporal)#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

4Open simple HTTP/1.1• open httpikeriri.pcapng of simple HTTP/1.1 packet,• HTTP/1.1 request
response loop
• Head of Line blocking• Rich applicationneeds many TCP
connection ( AJAX)#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

5Client

HTTP/1.1 is difficult to speed up•HTTP request have to send after previous
Server response has been received.
Request1• Please input display filter in Wireshark
Response1“http.next_request_in” ( Next request in
Request2
frame in HTTP request)• HTTP request is always waiting in one
Response2
connection. ( head line blocking)• Display filter “http” and Statistics>Flow Graph#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

6

HTTP/1.1 is text based, not efficient protocol• Right click HTTP header and “follow httpstream”• HTTP is text-based application protocol,
easy to read,but not efficient, ambiguous, andredundant• HTTP messages are clear texts so theyuses more data and CPU power for
dissection.
• Many connection is separated by eachother TCP connection, they work theirown TCP rules without HTTP.
#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

7

Accelerate Web service• Wider bandwidth, Faster computing in todays internet,
then what is the protocol ?
HTTP/1.0 (RFC1945-,1996)
HTTP/1.1 (RFC2068-,1997)• New generation of web protocol comes
HTTP/2.0 (RFC7540-,2015) former SPDY
Google, Facebook, Twitter, Yahoo, and major website
using Chrome, Edge, Safari and major browser#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly8www.twitter.com with HTTP/2.0• Set SSLKEYLOGFILE variable to decrypt
SSL/TLS• Open Chrome URL “chrome://flags/” anddisable QUIC protocol in list box,
now Chrome prefer to use HTTP2• Start capture and open www.twitter.com,
type chrome://net-internals/#http2you can see the HTTP/2 sessions• This time open twitter.pcapng andset (Pre)-Master-Secret log filename
Twitter_unencrypted_premaster_secret.txt
in SSL preference#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

9HTTP/2.0 uses binary frame with Huffman coding
compression in a SSL/TLS connection• Set “http2.header” in display filter andcheck the #14• The packet contains EthernetII,
IPv4, TCP, SSL, and HTTP2 header
Application

HTTP/1.1 semantics

Session

HTTP/2.0

Session

SSL/TLS

TCP• HTTP/2.0 uses binary frame with
Huffman coding,check packet bytes pane
Transport#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

10Connection process of HTTP/2.0• Click Statistics > Flow Graph and check connection
process of HTTP/2.0• HTTP/2.0 needs TCP 3 way handshakethat contains 1 RTT(round trip time)SYN-SYN/ACK-ACK from Client side
• HTTP/2.0 needs SSL/TLS connectionthat contains 2 RTT(round trip time) from Client side
Client Hello/Server Hello-Certificate-Server Key
Exchange-Server Hello Done/Client Key Exchange-New Session Ticket(TLS)-Change Cipher SpecFinished at the first time
• We need TCP 1 and SSL/TLS 2 RTT at the first time
#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

11

HTTP/2.0 Stream mechanism
HTTP/2.0 uses 1 tcp connection and many Stream( virtual connection channel ) that has id and priority
HTTP/2.0 request

WebbrowserStream(id 1)

Binary frame
Binary frame

HTTP/2.0 response
HTTP/2.0 request
Stream(id 2)

serverBinary frame
Binary frame

HTTP/2.0 response#sf17eu • Estoril, Portugal

1 tcp connectionused by HTTP/2.0

Quick Dissection Using Wireshark to Understand QUIC Quickly

12Multiple HTTP connections (at the first time)
HTTP/2.0

HTTP/1.1

TCP connection

TCP connection

SYN

SYN

1 RTT

1 RTT
SYN/ACKX manytimes

ACK
GET / HTTP/1.1#sf17eu • Estoril, Portugal

SYN/ACKACK

SSL/TLS1.0 connection
Client Hello

1 RTT
Server Hello-Certificate-Server
Key Exchange-Server Hello Done

1 RTTClient Key Exchange-Change Cipher Spec-Finished

New Session Ticket
Change Cipher Spec-Finished
Quick Dissection Using Wireshark to Understand QUIC Quickly

13

GQUIC• Google creates proprietary protocol, QUIC ( Quick UDP
Internet Connection) (a.k.a. GQUIC)• GQUIC omits TCP, SSL/TLS and HTTP/2.0 andprovides a monolithic mechanism of TCP + SSL/TLS
authentication and encryption + HTTP/2 multiplexing andcompression in UDP stream• Already used in Google service ( Gmail, YouTube,…)• QUIC needs just 1-RTT at the first time,and no RTT (0-RTT) when we connect again (if resumption
successes)#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly14

imfeelinglucky.pcapng• Open imfeelinglucky.pcapng, it is the packet thatjust I pushed I’m feeling lucky button at google using Chrome• At this time we just see some UDP streams of QUIC
• Open the Chrome and type chrome://net-internals/#quic
you can see current
QUIC sessions#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

15

Check GQUIC packets• Check header encapsulation ( Ethernet II, IP, UDP, and QUIC ) and payloads
are encrypted• This is not a first connection, so it immediately starts data transaction (0-RTT)
because we can see SH(Short Header) at Header Form field.
• 64-bit packet number is used as a part of nonce. Each endpoint uses a
separate packet number, that is increasing.
#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

16

IQUIC ( IETF Quick UDP Internet Connection)• Now IETF standardize IETF QUIC (a.k.a. IQUIC)• IQUIC also provides a monolithic mechanism of TCP
reliable transport + SSL/TLS1.3 authentication andencryption + HTTP/2 multiplexing and compression• Now Internet-Draft (October13, 2017)https://tools.ietf.org/html/draft-ietf-quic-transport-07• Data tracker (IETF) https://datatracker.ietf.org/wg/quic#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

17

IETF QUIC standards• Working Grouphttps://github.com/quicwg• Internet-Draft (October, 2017)https://tools.ietf.org/html/draft-ietf-quic-transport-07

Core specification#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

18

IETF QUIC standards• QUIC-TLS (October, 2017)https://tools.ietf.org/html/draft-ietf-quic-tls-07

Using TLS in QUIC
#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

19

Open sample packets of IETF QUIC
• Open quic_ietf_draft05_ngtcp2.pcapng using Wireshark( Thank you Alexis-san for dissector and sample pcap file )• View> Coloring rules…, new rule name: UDP source port 443,
set filter udp.srcport==443, and set pink color at background• Blue color is from Client and Pink is from Server#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

20

Long header of QUIC
• Click #1 packet and check QUIC header format

64-bit random
connection ID
from the clientLong headers are used for negotiationand establishment of 1-RTT keys
Once both conditions are met, a senderswitches to send short header
Packet type indicates the frame type of QUIC
64-bit packet number is used as pa art of nonce. Each
endpoint uses a separate packet number, that is increasing.
Stream is the same mechanism of HTTP/2.0 stream, andStream ID 0 is reserved for cryptographic handshake (TLS1.3)#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

21

Packet Type ( October, 2017)
type
0x01
0x02
0x03
0x04

0x05

0x06

Name
Explanation
VersionServer sends this type packet for not supporting client’s version (Long header)
Negotiation
Client Initial Client sends this type packet for initializing handshake (Long Header )ServerServer sends this type packet as cryptographic handshake message and ACK forStateless Retry requiring a new Client Initial packet ( Long Header )Server sends this type packet as cryptographic handshake message and ACK that
Servercontains server chosen connection ID and randomized packet number with STREAM,
Cleartext
PADDING, ACK. ( Long Header )Client sends this type packet as the receipt of Server Cleartext message, Client
ClientCleartext contains Server selected connection ID and incremented packet number ofCleartext
Client Initial with STREAM, PADDING, ACK. ( Long Header )Packets that are protected with 0-RTT keys are sent with Long Header; all packets
0-RTT
protected with 1-RTT keys are sent with Short Header.
Protected
Packets protected with 0-RTT keys use a type value of 0x06. The connection
ID field for a 0-RTT packet is selected by the client.

#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

22connection ID / packet number• Click connection ID field, right click and “Apply as column” ( same as
packet number) in #1 packet, and check the changes of both
• Server set 64-bit the random connection ID in #2 packet, Client updates
the connection ID as the same number• Packet number is set randomly (0 and 2^31-1) and used as a part ofnonce. Each endpoint uses a separate packet number, that is increasing#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

23

Stream ID ( encrypted in Short Header)• IQUIC packet has a 32-bit
STREAM id for multiplexing
many data connections.
• Clients use odd-number,Server use even-number,
0 is reserved for cryptographic
Handshake ( usually TLS connection )• IQUIC stream mechanism is almost
the same as HTTP/2.0(also as TCP)
• Stream change the state,
Many streams in a UDP connection#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

24

Short header of QUIC
• Click #5 packet and check QUIC IETF header
Set 0 : Connection ID field is omitted
Set 1 : Connection ID field is present

64-bit random
Server chosenconnection ID

Every time that a new set of keys is used forprotecting outbound packets, the KEY_PHASE
bit in the public flags is toggled.

64-bit packet number is used as pa art of nonce. Each
endpoint uses a separate packet number, that is increasing.

The short header can be used after the version and 1-RTT keys are negotiated.
#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

25

How to negotiate and installsession key in IQUIC• IQUIC is learned from SSL/TLS to install session
key, but how do QUIC install session key at thefirst time (1-RTT) and at resumption (0-RTT)• Open tls10ikeriri.pcapng to remember how tonegotiate and install session key in TLS1.0• tls10ikeriri.txt is a PEM format certification filewith server’s private key• Set RSA key list in SSL preference of Wireshark#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

26

Open tls10ikeriri.pcapng and
set RSA key list ( tls10ikeriri.txt )#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

27

Key creation process of TLS1.0
Root CA
cert

Root CA
Public Key

Client HelloCheck server cert
Servercert

ServerPublic Key

Server Hello-Certificate-Server
Key Exchange-Server Hello Done

Encrypted premaster secret

Client Key Exchange-Change Cipher Spec-Finished

Session Key#sf17eu • Estoril, Portugal

Encrypted premaster secretunencrypted premaster secret
Master secret

Master secret
MAC secretServerPrivate Key

ServerPublic Key

Decrypt encrypted PremastersecretEncrypt Premaster secret
Client Nonce(Random)

Servercert

New Session Ticket (TLS)
Change Cipher Spec-Finished

MAC secret

Quick Dissection Using Wireshark to Understand QUIC Quickly

Session Key

28

Filter “ssl” and check the each TLS packet• Check packet #6 and expand Client Key Exchange
Client send
Encrypted
PreMaster
Secret afternegotiatedwith Server#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

29

TLS1.0/1.2 needs 2 RTT at the first connection
HTTP/2.0
TCP connection

SSL/TLS1.0 connection
Client Hello

SYN

1 RTT

1 RTT
Server Hello-Certificate-Server
Key Exchange-Server Hello DoneSYN/ACKACK

1 RTT
Client Key Exchange-Change Cipher Spec-Finished• Old TLS needs 2 RTT
at the fist connection• It is not use for QUIC
1RTT connection• Another way tonegotiate and installsession key….

New Session Ticket
Change Cipher Spec-Finished#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly30

TLS1.3 Internet Draft 21• New TLS protocol since 2014 now Internet-Drafts
https://tools.ietf.org/html/draft-ietf-tls-tls13-21• Stronger ( few cleartext ) and Faster ( few packet )• New encryption / authentication• No SessionID, No Ticket, use PSK
No Change Cipher Spec,No Client Key Exchange,• 1-RTT at first time, 0-RTT when we connect again#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

31Sample trace of TLS1.3• Open sample trace file sip.pcap from Wireshark Wiki
sip-tls-1.3-and-rtcp.zip SIP call over TLS 1.3 transportwith enabled RTCP. Used openssl 1.1.1 prerelease
version (https://wiki.wireshark.org/SampleCaptures)• Open sip.pcap and filter ssl in Display Filter• Statistics > Flow Graph and set Displayed Packet
to see the 1-RTT full handshake of TLS1.3#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

32

Open sip.pcapng and filter ssl and create Flow Graph#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

33

TLS1.3 1-RTT handshake
TCP connection

TLS1.3 handshake
Client Hello

SYN

1 RTT

1 RTT

Server Hello, Application Data…

SYN/ACK

Finished, Application Data

ACK

(Application Data…)
The other handshake isencrypted( Encrypted Extension / Server
Configuration / Certificate /Certificate Verify / Finished )#sf17eu • Estoril, Portugal

There are no Client Key
Exchange, no Change Cipher
Spec packet, and theencryption starts afterServer Hello
The other handshake isencrypted using PSK (Pre
Shard Key ).
Client send Application data
after receiving Server packet
It needs just 1 Round trip
time from Client side

Quick Dissection Using Wireshark to Understand QUIC Quickly

34

Client Hello(contains former Client Key Exchange, Change Cipher Spec)
Extension: psk_key_exchange_modes (len=2)
Type: psk_key_exchange_modes (45) Length: 2
PSK Key Exchange Modes Length: 1

Set PSK Key
Exchange ModePSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)Extension: key_share (len=71)
Type: key_share (40) Length: 71
Key Share extension
Client Key Share Length: 69

Set Key Sharesettings

Send Client Nonce

Key Share Entry: Group: secp256r1, Key Exchange length: 65
Group: secp256r1 (23)Send Key Exchange Data

Key Exchange Length: 65

Key Exchange: 04f145e0e15072f4983d04be08c7886c598af98607204dd0...

Extension: certificate_authorities (len=40)
Type: certificate_authorities (47) Length: 40
Distinguished Names Length: 38
Distinguished Names (38 bytes)

Send certificate authorities#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

35Server Hello( contains former Change Cipher Spec)
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)Length: 111
Version: TLS 1.3 (draft 21) (0x7f15)

Determined
Auth/Encryption

Random: 8f3a63a080b3c1ae2b3192c76574d4f28afdb1f123a68f81...

Send Server Nonce

Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Extensions Length: 73
Extension: key_share (len=69)

Type: key_share (40)Set Key Sharesettings

Length: 69
Key Share extension

The others are encrypted

Key Share Entry: Group: secp256r1, Key Exchange length: 65

Group: secp256r1 (23)Key Exchange Length: 65

Send Key Exchange Data

Key Exchange: 04110e96ae58d23b968ebb7fd9075d83348733a622013785...
TLSv1.3 Record Layer: Application Data Protocol: sip.tcp#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

36

TLS1.3 in IETF QUIC• Let’s go back to quic_ietf_draft05_ngtcp2.pcapng• Check #1 packet of Client Initial (including Client Hello)
Extension: quic_transport_parameters
Extension: psk_key_exchange_modes
Extension: key_share• Check #2 packet of Server Cleartext (including Server Hello)
Extension: key_share• #3 (Server Cleartext) and #4(Client Cleartext) is encryptedwith application data (http-over-tls)
0x04
0x05

Server sends this type packet as cryptographic handshake message and ACK that contains server chosen connection
ID and randomized packet number with with STREAM, PADDING, ACK. ( Long Header )Client sends this type packet as the receipt of Server Cleartext message, Client Cleartext contains Server selected
Client Cleartext
connection ID and incremented packet number of Client Initial with STREAM, PADDING, ACK. ( Long Header )Server Cleartext#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

37

Client Hello/ Server Hello of IQUIC
Send Client Nonce
Send Server Nonce
Set PSK Key
Exchange Mode
Set Key Sharesettings
Send Key Exchange Data
#sf17eu • Estoril, Portugal

The others are encrypted

Quick Dissection Using Wireshark to Understand QUIC Quickly

38

Short header transaction• Check #5- packets with Short Header of IQUIC• The short header can be used after the version and 1-RTT
keys are negotiated.

• Transactions are independent and based on IP/UDP• Next time Client try to use 0-RTT way.
#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

39Comparizon between HTTP/1.1
HTTP/2.0 and IETF QUICHTTP/1.1

HTTP/2.0 with SSL/TLS

IETF QUIC handshake

SYN
SYN

1 RTT

SYN/ACK

1 RTT

ACK

Client Hello

1 RTT
Server Hello, Application Data…

SYN/ACKACK
GET / HTTP/1.1

X manytimes#sf17eu • Estoril, Portugal

Client Hello

1 RTT
Server Hello-Certificate-Server
Key Exchange-Server Hello Done

1 RTTClient Key Exchange-Change Cipher Spec-Finished
New Session Ticket
Change Cipher Spec-FinishedFinished, Application Data

(Application Data…)
The other handshake isencrypted( Encrypted Extension / Server
Configuration / Certificate /Certificate Verify / Finished )Quick Dissection Using Wireshark to Understand QUIC Quickly

40Use Wireshark
どうもありがとうございました！

#sf17eu • Estoril, Portugal

Quick Dissection Using Wireshark to Understand QUIC Quickly

41