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

[Christian Huitema <[e-mail]>]

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
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat