**
*Dear QUIC WG,*
*
I’m Kashyap Thimmaraju, a postdoctoral researcher at Humboldt University
Berlin. Recently I discovered a couple of attacks with the QUIC
protocol. Lars Eggert recommended that I share my findings with the WG
to discuss the impact and relevance of these findings.
Broadly speaking, the attacks deal with the Connection ID (CID), which
I’ve elaborated on below.
ANALYSIS
The draft specifies and recommends several important points on secure
usage of the CID, e.g., i) the same CID MUST NOT be used multiple times
over the same connection to prevent an eavesdropper from correlating the
end-points; ii) end-points should associate a sequence number with each
CID to detect reuse within the same connection; iii) CIDs should be
(pseudo) randomly generated as they are also used for packet security
and; iv) CIDs can be very long (max. 20 bytes).
The draft, however, does not specify how servers should handle the case
when successive incoming connections to a server use the same
destination CID. Indeed, it can be seen that based on the assumption
that the CIDs are (pseudo) randomly generated with a maximum length of
20 bytes, the probability of such a collision is very low.
Hence, I posit the following: If the server (implementation) does not
permit the use of the same destination CID across successive connections
(for a specific timeout), then an attacker can exploit this behaviour in
at least 2 ways:
1.
She can enumerate the number of server instancesbehind the domain
name/public IP address: if the handshake does not complete on the
second/successive attempt, then she infers that she has reached the
same instance; if the handshake succeeds then it is a new instance.
2.
Create a covert channel: we can assume that a sender and receiver
agree upon a set of CIDs to use at specific times. For each time
interval, the sender and receiver use the same destination CID. The
sender sends a 1 by connecting to the server and a 0 by not
connecting. The receiver always attempts to connect to the server.
If the receiver could not complete the handshake, it’s a 1, if the
handshake completes it’s a 0. Using this scheme a binary string can
be covertly communicated in one direction.
EVALUATION
The primary goal of my evaluation is to identify implementations, if
any, that prevent two subsequent QUIC connections from using the same
destination CID. To conduct this experiment I adopted the following
methodology. First, I created a client that uses deterministic CIDs for
the source and destination CIDs (I modified LiteSpeed Technologies
open-source QUIC client). Second, I used 15 implementations from those
listed on the QUIC Working Group’s GitHub page1: either manually built
Docker containers or the public test server. The list of servers tested
are shown across the two rows in Table 1. To conduct the experiment, I
had the client open and hold a QUIC connection with source CID 1 and
destination CID 2 for a maximum of 10s with the server, and then close
it. We then idle for 10s and repeat the steps a second time. I saved the
debug logs of the client, packet traces and session keys. I then
repeated the process for each of the 15 implementations. Finally, to
obtain the results of the test, I searched the debug log of the client
or the packet trace to confirm whether the second QUIC connection
obtained a successful handshake or not. The absence of a successful
handshake indicates a vulnerable implementation.
RESULTS
The results from my evaluation are shown in the table below. In
particular, I found 4 out of 15 implementations to be vulnerable to the
enumeration and covert channel attacks, namely, Apache Traffic Server
(ATS), Chromium, LiteSpeed and NGTCP2. In an evaluation of the
throughput using Lsquic clients and server on my desktop I measured a
throughput of ~30 bps.
VULNERABLE : IMPLEMENTATION
NO : Akamai, F5, Quinn, Aioquic, Quiche, Proxygen, Neqo, Nginx,
Picoquic, Quant, Quicly
YES : ATS, Chromium, Lsquic, Ngctcp2
*
Sincerely,
--
Dr.-Ing Kashyap Thimmaraju
Lehrstuhl für Technische Informatik
Institut für Informatik
Humboldt-Universität zu Berlin
Besucheranschrift:
Rudower Chaussee 25, 12489 Berlin
Haus 4, 3. OG
[email protected]
http://www.ti.informatik.hu-berlin.de
