4.1 Cryptographic attacks
In Crypto 1998, Bleichenbacher presented a seminal attack on RSA-based PKCS#1 v1.5 encryption [
39]. Essentially, he assumed the existence of an “oracle” that allowed an attacker to distinguish “valid” from “invalid” PKCS#1 v1.5 padded ciphertexts. Such an oracle may in practice be given by a TLS server, which responds with appropriate error messages, or allows otherwise to tell whether a given ciphertext has a “valid” padding or not; for instance, this can be done by observing the timing behavior of the server when processing the ciphertext. Bleichenbacher showed that such an oracle is sufficient to decrypt PKCS#1 v1.5 ciphertexts.
In 2015, the authors in [
40] elaborated on encrypted key transport with RSA-PKCS#1 v1.5 key exchange method as used by TLS, and demonstrated that it was still effective. Specifically, they presented two attacks against TLS v1.3 and gQUIC, respectively. The first, requires a very quick “Bleichenbacher-oracle” to generate the TLS
CertificateVerify message before the client releases the connection, which in turn reduces the real impact of the attack. The second, was more practical in terms of time as it can be effective in situations where forging a signature with the aid of a “Bleichenbacher-oracle” may require a great deal of time. This is because the aggressor can pre-compute the signature well in advance as the client initiates a connection. They considered two scenarios either with “perfect” or “imperfect” oracles.
At the time this attack was proposed, having an “imperfect” oracle was considered to be impractical for a real-world scenario. Moreover, having a “perfect” oracle weakness to a server, it should be considered highly unrealistic. Given that an Ubuntu 14.04 with 2.2 GHz dual core CPU was used to execute the queries, modern hardware is sure to perform much faster. On the other hand, the browser’s connection timeout timer may have been reduced due to the higher network speeds. For example, Firefox has now a default connection timeout (
network.http.connection-timeout) of 90 sec (at that time was 600 s), while Chrome has still the same default value of 30 s. Additionally, as NIST suggests, starting from 2020, the RSA key length should be at least 2048 bits [
41], i.e., increasing by far the complexity and the resources at the attacker’s side; in the context of [
40], a 2048 bits key needed 2,120 queries towards the server, requiring 66 s in total. RFC 8446, appendix § E.8 titled “Attacks on Static RSA” highlights this issue: TLS 1.3 does not use RSA key transport, therefore it is only indirectly susceptible to Bleichenbacher-type attacks. That is, “if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections”. This situation can be avoided by simply disabling support for static RSA across all versions of TLS.
The work in [
42] introduced an attack dubbed DROWN (Decrypting RSA using Obsolete and Weakened eNcryption). Precisely, DROWN was presented as a novel attack that allowed a perpetrator to break a passively collected RSA key for any TLS server if this RSA key was also used for SSLv2; therefore DROWN is characterized as cross-protocol; the assault uses a server supporting SSLv2 as an oracle to decrypt TLS sessions. In its generic version, which comprises a more powerful variation of the Bleichenbacher RSA padding-oracle assault, the attacker has to passively observe around 1K TLS sessions with RSA key exchange, make 40K TLS v2 connections, and perform 2
\(^{50}\) symmetric encryption operations.
Moreover, they pinpointed that gQUIC is vulnerable to a Man-in-the-middle (MitM) variant of the so-called DROWN attack, enabling the opponent to impersonate a server for as long as they wish. According to the authors, this requires 2\(^{17}\) SSLv2 connections and 2\(^{58}\) offline work. As a basic requirement, the attack can be performed against servers which expose their RSA public keys through SSLv2. The assault capitalizes on the “server config” message received by a gQUIC client when attempting a connection to the server. This message includes the server’s Diffie-Hellman public value, it has an expiration date, and it is signed by the server’s private key. In this respect, for launching a MitM attack against the client, the attacker needs to produce a (forged) valid “config message”; for counterfeiting the signature they need to find a valid, PKCS conformant SSLv2 ciphertext. The authors pinpoint that QUIC discovery can be done over plain HTTP, meaning that the server can be impersonated by the attacker and falsely indicate support of QUIC. Therefore, the next time the client connects to the server, it will attempt to connect using QUIC, allowing the attacker to present the forged “server config” message and execute the assault. Naturally, this attack does not affect IETF-QUIC as its cryptographic handshake is mandatorily based on TLS 1.3 rather than gQUIC crypto.
The authors in [
43] conducted a formal analysis of TLS v1.3 revision 10 through
Tamarin Prover, a security protocol verification tool. Their analysis, considering both unilateral and mutual authentication, demonstrated that revision 10 fulfills the objectives of authenticated key exchange. Further, by extending their model, they proposed a client impersonation attack based on the delayed authentication process; presumably this is the post-handshake authentication feature defined in Sect. 4.6.2 of RFC 8446, and it is permitted only if the client has sent the
post_handshake_auth extension. The identified attack requires certificate-based client authentication in session resumption using a PSK, as defined in Sect. 2.2 of RFC 8446—a PSK can be created in a previous connection and subsequently used to establish a new connection. Specifically, the attacker must be in a MitM position with the client and the server, and therefore is able to establish valid PSKs with both ends. Assuming a session resumption process the requires post-handshake authentication, the authors noticed that the attacker is able to produce the correct
CertificateVerify message because the Finished messages are not included in the session hash, i.e., the Transcript-Hash as defined in Sect. 4.4.1 of RFC 8446. After that, the attacker possesses the session keys and is able to impersonate the client to the server. On the other hand, Sect. 4.4 of RFC 8446 states that the
Handshake Context for post-handshake authentication includes the server’s Finished message. That is, with reference to Sect. 4.4.1 of the RFC the signature provided in the
CertificateVerify message is produced over the value
Transcript-Hash (Handshake Context, Certificate). Therefore, as the authors acknowledged, the identified attack is not considered feasible starting from revision 11 of the RFC.
The authors in [
44] elaborated on the nonce reuse/misuse resistance authentication encryption schemes for modern TLS and QUIC based web servers. Specifically, the problem of nonce-based authentication encryption is the repetition of nonce in two different messages; it is well-known that any AEAD relies on no reuse of the same pair of key and nonce. The authors argue that the nonce problem is avoided by using a nonce reuse/misuse resistance authentication scheme like the AES_GCM_SIV. The latter, defined in RFC 8452, is a mode of operation for AES, which comprises a nonce misuse-resistant AEAD. Based on their analysis, the AES_GCM_SIV is a superior scheme for achieving better security bounds performing large messages in TLS cipher suites and QUIC-based web servers, which also fulfils the NIST security bound of 2
\(^{-32}\).
With reference to the relevant RFCs, Sect. 5.3 of RFC 8446 states that “Each AEAD algorithm will specify a range of possible lengths for the per-record nonce, from N_MIN bytes to N_MAX bytes of input [as given in RFC 5116]. The length of the TLS per-record nonce (iv_length) is set to the larger of 8 bytes and N_MIN for the AEAD algorithm. An AEAD algorithm where N_MAX is less than 8 bytes must not be used with TLS.” Put simply, TLS 1.3 uses the same key for multiple records, but constructs the per-record nonce by XORing the accordingly padded 64-bit sequence number (is maintained separately for reading and writing records) with either the static client_write_iv or server_write_iv; the latter is a 96-bit value obtained through key generation.
On the other hand, RFC 9000 states in Sect. 12.3 that “The packet number is an integer in the range 0 to 2\(^{62}\)-1. This number is used in determining the cryptographic nonce for packet protection. [...] A QUIC endpoint must not reuse a packet number within the same packet number space in one connection.” If the packet number for sending reaches 2\(^{62}\)-1, the sender must silently terminate the connection.
Recall that based on Sect. 2.2 of RFC 8446, TLS 1.3 supports the use of a PSK that was either established in the context of a previous handshake (“session resumption or resuming with a PSK”) or distributed out-of-band. Note that the way an out-of-band PSK is generated and distributed is basically considered external to TLS; nevertheless, the Internet-Draft titled “Importing External PSKs for TLS” [
45] provides a PSK importer interface to mitigate against possible security issues.
The authors in [
46] pinpointed that the problem with this PSK-based, and therefore implicit, authentication mode leaves room for a “(misuse) vulnerability, assuming that a node can act as both a client and a server: the sender of an authentic message could also be, under an attack scenario, the receiver itself.” The attack, dubbed “Selfie”, is a type of reflection attack where the opponent acts as MitM, say, between Alice and Bob. Alice initiates session S1 with Bob by sending him the
ClientHello message with the
pre_shared_key extension. The attacker captures the message and reflects it back to Alice in another session S2, where Alice acts as the server and Bob as the client. In S2, Alice replies to Bob with
ServerHello and
server Finished messages. The attacker again captures both messages, and in the context of S1, reflects them back to Alice. These messages will be authenticated by Alice, who then is convinced she is talking to Bob. As a result, in S1, Alice will reply with a
client Finished message, which is again echoed back to Alice in the context of S2. This procedure will result in Alice opening a “Selfie session with herself”, meaning that any piece of data she sends in S1 will be echoed back to her through S2. Guidelines for addressing the Selfie attack are given in Appendix B of Internet-Draft [
45].
4.2 Handshake attacks
The authors in [
31] contributed the first study that focused on gQUIC security. They managed to identify three different attacks in which the gQUIC protocol was vulnerable and proposed a security model, namely
QACCE. The first one is a replay attack where an attacker with a MitM position could replay either some key establishment parameters to the client or the packet that contained the source address token (stk) of the client to the server. In both cases, the attacker could mount a Denial of Service (DoS), causing the protocol handshake to fail. As stated in the analysis of [
47], such attacks are still feasible during a 0-RTT connection; the authors compared this attack with the legacy TCP SYN flood one.
The second attack they examined is based on packet manipulation; as discussed in [
47] further down, unprotected parameters, such as the CID or the
stk token, could be possibly manipulated by an attacker with a MitM position to force a user into downgrading to a TLS connection over TCP. The result is the same as with the replay attack above, that is, for as long as the attack is active the client will be unable to connect with the server due to handshake failure. At this point, the authors correlated this attack with an SSL downgrade one, say, from SSL v3 to SSL v2.
The third attack tested by the authors was a crypto stream offset assault, where they injected a four character string, that is, “REJ\0” into the handshake message. This addition was enough to make the handshake fail and prevent the establishment of a QUIC connection between the client and the server either by denying access to the requested application or forcing the client to fall back to a TCP/TLS connection. Additionally, this attack was correlated to a TCP ACK flooding attack, in which an attacker sends multiple acknowledged (ACK) responses to the server to confuse it and drop the connection.
The work in [
47] provided a comparable study between TLS 1.2 and gQUIC from a security perspective. Specifically for gQUIC, the authors described (although not practically evaluated) three different attacks in the context of HTTP/2 services. All the attacks assume that the opponent has obtained a MitM position between the legitimate client and server and actively listens and interacts with the communication between the two ends. In the first attack, the adversary waits for the client to initiate the connection establishment process, that is, through a
ClientHello message, and in a race condition with the server, they respond to the client with a reject message, containing a spoofed source address token, that is, an authenticated-encryption block of the client’s IP address and a timestamp. Upon reception, and given that the source address token is invalid, the server sends a reject message to the client, who needs to repeat the connection establishment process from the onset.
The second attack considers the manipulation of unprotected parameters, including the CID or the source address token. This drives both the client and the server to possess different initial keys, eventually wrecking the connection establishment. The last attack capitalizes on the fact that all handshake messages in gQUIC comprise a logical byte-stream. If the adversary is able to inject random data to interrupt the byte-stream, they can render the byte-stream invalid, breaking the connection establishment. It is obvious that all three attacks have no real impact on the server and only induce a DoS effect on the client. It is also important to add that according to Sect. 5 of RFC 9000, “0-RTT provides no protection against replay attacks”, while Sect. 9.2 of RFC 9001 states that “QUIC is not vulnerable to replay attack, except via the application protocol information it might carry” and “Disabling 0-RTT entirely is the most effective defense against replay attack”. Moreover, on-path active attacks and handshake DoS are discussed in Sect. 21.1.3.1 and Sect. 21.2 of RFC 9000.
In work [
48], the focus is on the 0-RTT mode used in gQUIC and TLS 1.3. Since this mode allows the client and server to exchange data before switching to fully secure keys, the authors studied the way replay attacks affect the security of these protocols. Their results show that, at least at that time, replay attacks were accepted as inevitable by the protocol creators. This is further confirmed in IETF QUIC in RFC 9000.
The authors in [
49] compared gQUIC with other common protocols, such as TCP and UDP, in an attempt to pinpoint security issues in gQUIC. Their analysis led to the identification of two 0-RTT oriented attacks, namely
QUIC RST and
Version Forgery. In QUIC RST, the attacker sends a reset packet to the client, making it believe that the server refused the connection; this could lead the client to give up the connection. In Version Forgery, the attacker pretends to be the server and sends to the client a version negotiation packet with a version that is not supported by the client; again the client is deceived to drop the connection. The authors argue that both these attacks are more easily mounted in a LAN environment due to Address Resolution Protocol (ARP) spoofing.
The authors of [
50] examined downgrade attacks in TLS 1.3 in 2020. More specifically, they studied the Signaling Cipher Suite Value (SCSV) downgrade protection mechanism offered in TLS 1.3 and its support in 10 major Web browsers, including Firefox, Chrome, and Edge, in five operating systems. The SCSV mechanism is a pseudo cipher suite that is included in the
ClientHello message of TLS 1.3 and mentions the latest supported TLS version of the client; for this protection to be present, both the client and the server must support it. During their analysis, they discovered that all browsers in iOS v12.2, Safari and QQ in macOS v10.14.4, and Internet Explorer, Edge, and QQ in MS Windows 10 v1809, were vulnerable to a version downgrade attack, due to not supporting the protection mechanism of SCSV. In MS Windows, the TLS version could be downgraded to 1.0, whereas in iOS and macOS to 1.2. Indeed, such an attack is practically feasible and could be quite easily mounted due to the lack of SCSV protection.
Gagliardi and Levillain [
51] studied the QUIC transport and cryptographic layers in the related Internet drafts from version 18 to version 23. They focused on the connection establishment in existing implementations, testing them for security issues with the aid of the
Scapy Python library. They tested four different attacks in ten live demo servers, each one with a diverse QUIC implementation.
The first attack was
version negotiation, similar to the one already mentioned in [
49], where the attacker sends a different, yet-to-be-defined protocol version. Only the
ngtcp2 implementation was affected by this attack, leading to a timeout.
The second attack checked the behavior of implementations against the client initial packet length. To defend against amplification attacks, QUIC specifies that the initial packet sent should have a length of at least 1,200 bytes and the server’s response length should be at most 3 times the client’s packet length. The authors sent short initial packets (300 bytes long) to all the implementations and even though two of them replied, they did not send more than 3 times the length of the initial packet, providing a basic level of protection against amplification attacks.
In the third attack, namely missing parameters, different parameters described as mandatory in both QUIC and TLS 1.3, such as the maximum size of each packet, were sent to all implementations. The authors mentioned that some servers accepted packets with missing mandatory parameters without specifying which ones had this behavior.
Finally, they mounted frame mangling attacks by sending forbidden frames to the demo servers. In QUIC, four different types of packets could be used inside an initial packet, namely, crypto, ack, connection close, and padding frames. However, the authors identified that in four different tested cases, at least four different packets could be encapsulated inside an initial QUIC packet, causing a successful handshake instead of an error. First off, they used a Ping packet, that got a response from aioquic, ats, and ngtcp2. Second, they sent a split crypto packet, dividing the TLS ClientHello into two crypto frames, with only pandora and quant responding correctly, that is, rejecting the handshake. The third and fourth ones were based on sending overlapping crypto packets, one with consistent and one with inconsistent contents respectively. The correct behavior, that is, producing an error, was observed only from ats, pandora and quant, in both cases.
Nawrocki et al. [
52] examined the QUIC handshake protocol against two type of attacks, namely, state-overflow and reflective amplification, to eventually prove that QUIC is vulnerable to resource exhaustion attacks. This choice stems from the latest QUIC RFC [
3], which, to some extent, mitigates amplification attacks (see Sect.
2). State-overflow attacks, similarly to TCP SYN flood, are based on the fact that QUIC keeps a state from each connected client. The authors stated that another defensive mechanism has been added to the QUIC RFC to retry authentication if the IP address cannot be verified. While the latter protection method can assist into mitigating attacks, such as state-overflow, the same defensive mechanism is considered to be against the QUIC design goals since it introduces an additional overhead and delays the authentication procedure.
To evaluate their observations and to identify DoS attacks that may exist “in the wild”, the authors collected and analyzed QUIC traffic, that is, 92 M QUIC packets, from UCSD Network Telescope [
53]. Then, they selected sessions with: a) more than 25 packets, b) duration longer than 60 s, and c) a maximum packet rate of higher than 0.5 pps, calculated over all 1-min slots of the respective event. Their analysis revealed 2905 attacks, corresponding to 11% of all response sessions. According to the authors, 98% of all of these attacks target well-known QUIC servers. Additionally, they made a twofold observation on these attacks: a) QUIC floods are shorter but on average as severe as common TCP/ICMP floods and b) QUIC floods are part of multi-vector attacks and highly correlated with TCP/ICMP floods. The latter correlation means that QUIC floods were used in conjunction with TCP/ICMP floods against a target.
To cross-validate their results, the authors set up an NGINX webserver, on a 128-core computer with 512 GB RAM and recorded 500K packets using the QUIC client
quiche [
14]. To simulate attacks, the authors sent only client Initial messages with random packet rates to new server instances. The authors found that servers with 4 or 128 workers which did not support the
RETRY defensive mechanism presented slower responsiveness by 32% or 64% after 100 or 10,000 pps, respectively. On the other hand, servers that did implement the
RETRY protection mechanism, with only four workers could withstand even a load of 100,000 pps. This clearly indicates the importance of the
RETRY scheme; to further validate this observation, the same experiment has been carried out in subsection
5.2.7 against six different production-grade QUIC servers.
4.3 Fuzzing attacks
McMillan et al. [
54] presented a formal specification of the QUIC’s wired protocol that generates automated randomized testers for QUIC. The authors evaluated their method on a quartet of diverse QUIC implementations. For each of them, they performed test runs on a HTTP server based on a QUIC library. Their results revealed various issues in the server implementations, which according to the authors, point to issues in the draft standard. From a total of 27 errors, four cases were deemed to be exploitable; these were protocol or progress violations that revealed possible vulnerabilities in the implementations or the (at that time draft) standard itself. Specifically, one of these was a potential DoS attack by an off-path attacker. Another one was an information leak comparable to the OpenSSL well-known
heartbleed vulnerability; it occurs when a server instance sends an incorrect number of bytes in a re-transmission of a stream frame, violating the specification and resulting in a stream frame that is longer than intended, thus, causing arbitrary server memory data to leak into the network. Yet another data leak case was an
APPLICATION_CLOSE frame transmitted in response to the unexpected initial packet, sending application data in the clear. The last issue was a case where a server instance allocated a number of records in memory that was proportional to the gap in packet sequence numbers, allowing an attacker to eventually exhaust the server.
G.S. Reen et al. [
55] presented
DPIFuzz, a stateless fuzzing framework, which can find exploit strategies for Deep Packet Inspection (DPI) in QUIC implementations with the assist of “Mutations”, such as using duplicate packet numbers and exploiting the diverging handling of overlapping stream offsets. The authors evaluated their framework against five open-source QUIC implementations, namely
QUICLY [
25],
QUANT [
56],
NEQO [
19],
MVFST [
20] and
QUICHE [
14], identifying the following vulnerabilities. The implementation of QUANT tries to access the state of a stream, i.e., either open or closed, by calling the
q_is_stream_closed() function after the memory allocated to the stream has already been freed. The NEQO server calls the
close() function on a connection with state CLOSED.
In QUICLY, the server runs into a segmentation fault due to a reference on a null pointer; more specifically, the
QUICLY_get_ingress_max_streams() function tries to access the value of a NULL pointer, causing the server to crash. Finally, the MVFST server runs into a segmentation fault due to a reference on a null pointer; this is caused when a stream frame with a non-zero Offset field has the OFF bit set to 0, indicating that the Offset field is absent. In all the above cases, the issues were reported and fixed. In general, while a stateful, structure-aware fuzzer could identify more bugs in QUIC servers, it could also be considered to be too implementation-specific; for example, Table
1 shows that at least five different languages are used across 18 QUIC implementations.
Zhang et al. [
57] presented a modeling and verification method for cryptographic protocols. The authors performed analysis based on the symbolic protocol model, to verify the security of the QUIC handshake protocol. Their results reveal that an attacker can impersonate the client by forging two plaintext messages, i.e.,
CEPub and
CHLO, and sending them towards the server to complete the establishment of the initial session and final session key with the server. Additionally, the authors proposed a revised QUIC handshake protocol which uses the client’s private key to sign
CEPub and
CHLO, and thus prevent attackers from forging the aforementioned messages.
Thimmaraju et al. [
58] analyzed the Connection ID (CID) mechanism of the IETF QUIC draft v.30. According to the authors, an attacker can exploit servers, which do not permit the use of the same destination CID across new connections, to get the number of server instances behind a load balancer. The authors dubbed this situation “enumeration attack”. This information can be used to estimate the load necessary to mount a Distributed Denial of Service (DDoS) assault against the server. Their analysis on 15 QUIC implementations concluded that 25% of them are vulnerable to this attack, namely, Apache Traffic Server (ATS), Chromium, LiteSpeed, and ngtcp2. To solve that, the authors proposed an enumeration algorithm that would prevent an attacker from performing this enumeration attack. We argue that the enumeration attack discussed in the above work, is practically infeasible on the
Chromium and
ngtcp2 QUIC implementations due to the fact that both of them are not load balancers.
4.5 Privacy attacks
Although the work from Van et al. [
60] focuses on traffic classification, the described techniques could be used for attacking the privacy of users as well. Their proposal is a static-based method which relies on the Convolutional Neural Network (CNN) to detect various QUIC-based Google services, such as Google Hangout Chat, Google Hangout Voice Call, YouTube, File transfer, and Google play music. Specifically, their method uses a Random Forest model trained with NetFlow-based features to detect Google Hangout services due to the unique network flow of these services. It also uses the CNN model trained with packet-based features to classify file transfer, YouTube, and Google play music network traffic. The authors built a proof-of-concept implementation of their approach on an Ubuntu workstation using
quic-go [
13] to evaluate its performance. Precisely, they captured around 150GB of real network traffic including over 20K flows with five kinds of QUIC-based services. The experimental results showed that the proposed method can detect the five aforementioned QUIC-based Google services with high accuracy (approximately 99%).
The authors of [
61] tested the privacy of the full handshake and session resumption mechanisms of TLS 1.3. Their results showed TLS 1.3 does provide a level of privacy, when considered in isolation. According to the authors, in full handshakes, TLS 1.3 provides a perception of server unlinkability. On the other hand, session resumption, a fundamental feature of TLS, introduces a method of linking sessions between two objects. In addition, the authors demonstrated that privacy in TLS 1.3 is reduced when resumption is considered, due to the use of session tickets. In that sense, TLS 1.3 offers a rather optimal degree of privacy.
Govil et al. [
62] presented
MIMIQ, a privacy enhancing tool which leverages on QUIC to mitigate traffic-analysis attacks and protect user identity. To evaluate the proposed tool, the authors created a proof of concept MIMIQ implementation. More specifically, they used an off-the-shelf Dynamic Host Configuration Protocol (DHCP) server and configured short DHCP lease duration, to make old IP address leases expire in time for new requests. Additionally, they modified a QUIC client to act as a MIMIQ agent. This latter sends DHCP requests to the DHCP server, and triggers connection migration by changing its interface IP using the
ifconfig system administration utility. Furthermore,
Mininet [
63] was used to simulate two networks, i.e., a network with only one QUIC client running and a multi-client network with four QUIC clients, each running on a different host. Each network had both a DHCP and a QUIC server. Finally, the authors evaluated MIMIQ against state-of-the-art website fingerprinting attacks, and found that setting migration every 25 to 100 packets can reduce attack accuracy to less than 10%.
The authors in [
64] examined website fingerprinting attacks on QUIC, gQUIC, and HTTPS/2 from a traffic analysis perspective. The purpose of this type of passive attack is to deduce the website a user is visiting, which can be translated to a multi-class classification task. The tests employed by the authors concluded that gQUIC and QUIC are more at risk to these attacks than HTTPS/2 in the early traffic scenario, but are similar in the normal full traffic. Specifically, the authors collected network traffic using a controlled environment which comprised three web servers running Ubuntu 18.04. Additionally, the authors selected the official landing pages of the top 100 schools, which are split among the three hosting servers. Docker was used in each server to isolate resources from these websites.
To compare the protocols against fingerprinting attacks, the authors utilized five machine learning models, i.e., Random Forest, Extra Trees, k-nearest neighbors, Naive Bayes, and Support Vector Machine. The results were obtained using tenfold cross-validation. According to the authors, with only 40 packets, the attack accuracy reaches 95.4% for gQUIC, 95.5% for QUIC, whereas only 60.7% for HTTPS/2.
Ludovic et al. [
65] examined whether network-layer padding, a feature included natively in QUIC, can be used to defend against website fingerprinting attacks. Specifically, two datasets were used during the experiments, namely a mixed and a QUIC dataset. The authors observed that in the mixed dataset, which has only 4% QUIC traffic, the classifier favors TLS-specific features. For that reason, the authors created the QUIC-dominated dataset, which contains 70% of QUIC traffic.
The authors implemented an attack using the Random Forest model and their results showed that: (a) Network-layer defenses allow website identification with an F1 score of more than 92%, (b) web development practices, such as hosting resources on multiple servers, reduce the effectiveness of any defense, and (c) the IP addresses can help the attacker associate QUIC packets with a client; defences include MIMIQ [
62] or IP hiding solutions, such as Near-Path NAT [
66] and MASQUE [
67].