[New Issue] CID based attacks

[Kashyap Thimmaraju <[e-mail]>]

**

*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

[e-mail]

http://www.ti.informatik.hu-berlin.de