Subject: [EToSat] FW: Website Fingerprinting on Early QUIC Traffic

From: "Border, John" <[email-masked]>
Date: Thu, 4 Feb 2021 14:42:06 +0000

FYI

Subject: Website Fingerprinting on Early QUIC Traffic

Website Fingerprinting on Early QUIC Traffic
https://arxiv.org/abs/2101.11871

Cryptographic protocols have been widely used to protect the user's privacy and avoid exposing private information. QUIC (Quick UDP Internet Connections), as an alternative to traditional HTTP, demonstrates its unique transmission characteristics: based on UDP for encrypted resource transmission, accelerating web page rendering. However, existing encrypted transmission schemes based on TCP are vulnerable to website fingerprinting (WFP) attacks, allowing adversaries to infer the users' visited websites by eavesdropping on the transmission channel. Whether QUIC protocol can effectively resisting to such attacks is worth investigating. In this work, we demonstrated the extreme vulnerability of QUIC under WFP attacks by comparing attack results under well-designed conditions. We also study the transferability of features, which enable the adversary to use proven effective features on a special protocol attacking a new protocol. This study shows that QUIC is more vulnerable to WFP attacks than HTTPS in the early traffic scenario but is similar in the normal scenario. The maximum attack accuracy on QUIC is 56.8 % and 73 % higher than on HTTPS utilizing Simple features and Transfer features. The insecurity characteristic of QUIC explains the dramatic gap. We also find that features are transferable between protocols, and the feature importance is partially inherited on normal traffic due to the relatively fixed browser rendering sequence and the similar request-response model of protocols. However, the transferability is inefficient when on early traffic, as QUIC and HTTPS show significantly different vulnerability when considering early traffic. We also show that attack accuracy on QUIC could reach 95.4 % with only 40 packets and just using simple features, whereas only 60.7 % when on HTTPS.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 4 Feb 2021 12:17:00 -0800

There are some limitations in this paper. They test against an early 
version of Google QUIC, not the latest IETF version. They use only the 
Chrome client, thus have to consider just one rendering sequence. They 
force the clients to clear their caches and thus download the full 
sites, which makes identification easier. And they use somewhat charged 
language, like "the insecurity characteristic of QUIC", when they merely 
demonstrated vulnerability to traffic fingerprinting. But then, yes, the 
results are interesting.

Is it OK to forward this to the privacy research group (PEARG)?

-- Christian Huitema

On 2/4/2021 6:42 AM, Border, John wrote:
>
> FYI
>
> *Subject:* Website Fingerprinting on Early QUIC Traffic
>
> https://arxiv.org/abs/2101.11871 <https://arxiv.org/abs/2101.11871>
>
> Cryptographic protocols have been widely used to protect the user's 
> privacy and avoid exposing private information. QUIC (Quick UDP 
> Internet Connections), as an alternative to traditional HTTP, 
> demonstrates its unique transmission characteristics: based on UDP for 
> encrypted resource transmission, accelerating web page rendering. 
> However, existing encrypted transmission schemes based on TCP are 
> vulnerable to website fingerprinting (WFP) attacks, allowing 
> adversaries to infer the users' visited websites by eavesdropping on 
> the transmission channel. Whether QUIC protocol can effectively 
> resisting to such attacks is worth investigating. In this work, we 
> demonstrated the extreme vulnerability of QUIC under WFP attacks by 
> comparing attack results under well-designed conditions. We also study 
> the transferability of features, which enable the adversary to use 
> proven effective features on a special protocol attacking a new 
> protocol. This study shows that QUIC is more vulnerable to WFP attacks 
> than HTTPS in the early traffic scenario but is similar in the normal 
> scenario. The maximum attack accuracy on QUIC is 56.8 % and 73 % 
> higher than on HTTPS utilizing Simple features and Transfer features. 
> The insecurity characteristic of QUIC explains the dramatic gap. We 
> also find that features are transferable between protocols, and the 
> feature importance is partially inherited on normal traffic due to the 
> relatively fixed browser rendering sequence and the similar 
> request-response model of protocols. However, the transferability is 
> inefficient when on early traffic, as QUIC and HTTPS show 
> significantly different vulnerability when considering early traffic. 
> We also show that attack accuracy on QUIC could reach 95.4 % with only 
> 40 packets and just using simple features, whereas only 60.7 % when on 
> HTTPS.
>
>
> _______________________________________________
> EToSat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat

---

From: "Border, John" <[email-masked]>
Date: Thu, 4 Feb 2021 20:29:23 +0000

Its public

From: EToSat <[email-masked]> On Behalf Of Christian Huitema
Sent: Thursday, February 04, 2021 3:17 PM
To: [email-masked]
Subject: Re: [EToSat] FW: Website Fingerprinting on Early QUIC Traffic

**EXTERNAL EMAIL**

There are some limitations in this paper. They test against an early version of Google QUIC, not the latest IETF version. They use only the Chrome client, thus have to consider just one rendering sequence. They force the clients to clear their caches and thus download the full sites, which makes identification easier. And they use somewhat charged language, like "the insecurity characteristic of QUIC", when they merely demonstrated vulnerability to traffic fingerprinting. But then, yes, the results are interesting.

-- Christian Huitema

FYI

Website Fingerprinting on Early QUIC Traffic
https://arxiv.org/abs/2101.11871<https://urldefense.com/v3/__https:/arxiv.org/abs/2101.11871__;!!Emaut56SYw!kXz4ZIkt-vgb-C_c-7Zccfeyn0EVJivN7iQUAvXg6BorOv_W2qbbDVXLDsB0DoW-tw$>

EToSat mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/etosat<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/etosat__;!!Emaut56SYw!kXz4ZIkt-vgb-C_c-7Zccfeyn0EVJivN7iQUAvXg6BorOv_W2qbbDVXLDsBG0AM-xQ$>