Inderdaad boeiend.

Laat ik proberen het wat duidelijker samen te vatten dan de summary van het paper.

Het gaat hier feitelijk om een vorm van een side-channel / timing attack .

Het scenario is dat je kijkt naar encrypted verkeer, waarvan je de werkelijke bestemming niet ziet (tunnel/proxy whatever). En de inhoud natuurlijk ook niet, want encryptie.
Wat je wel ziet zijn pakketgroottes/ datavolumes, en timing en pauzes van datastromen.

Ze hebben de sites (frontpages zo te zien) van de 92 top universiteiten genomen, en die gecloned, en kijken voor de analyse alleen naar het feitelijk encrypted verkeer (dus niet de SSL handshake) .
Ze bezoeken de geclonede sites elk 100x met een HTTPS en QUIC client .
(Ik heb vrij snel gelezen - zag niet meteen wat ze gedaan hebben qua certificaat - misschien een self-signed cert. Maar feitelijk beperken ze zich tot de structuur van de site en , in kenmerken waar ze in verkeer naar kijken ).

Dan gebruiken ze machine learning om modellen te maken/leren en aan de verkeers-stroom-patronen de bezochte site te herkennen.

En dan kunnen ze met behoorlijke accuracy zeggen welke site bezocht werd.

QUIC is , ietwat kort door de bocht , 'tcp over udp' . Het is een protocol stack, met retransmissie, flow control e.d. dat UDP als drager protocol gebruikt.
De reden is dat met de groei van Internet TCP 'versteend' . Het duurt decennia voordat verbetere TCP versies in voldoende aantallen gedeployed zijn op clients en servers om echt profijt te hebben van de verbeteringen.
(De verbeteringen betreffen met name de flow control en congestie beheer - zoek op TCP Vegas,Reno, Cubic, BBR etc als termen) .
Google heeft toen QUIC bedacht - waarbij ze de client stack (qua flowcontrol) in de browser implementeren, en de server stack ook userland kan zijn .

Dat research paper kijkt of er voor die side-channel analyse verschil is tussen HTTPS verkeer met QUIC dan wel TCP als transport .Blijkbaar is het herkennen van de site op basis van de eerste set van packets makkelijker als het om QUIC verkeer gaat dan om TCP .
Ik las het niet expliciet in het paper, maar QUIC ambieert een heel snelle start van nuttige data transfer - met de natte vinger denk ik dan dat dat ook wel verklaart waarom je meer informatie haalt uit de vroege data van een QUIC sessie dan van een TCP sessie.

Boeiend - maar imo voor de normale security praktijk helemaal onderop de stapel van zorgen.

Het _probleem_ dat ook traffic analyse informatie kan opleveren is bekend in de crypto wereld - de 'number stations' - korte golf zenders die eindeloze reeksen van getallen oplezen weten dat ook.
Die zenden _altijd_ . Niet alleen als er iets te melden is aan de spionnen die de luisteraars zijn.
Ook al zijn de uitzendingen one time pad - alleen zenden als er een bericht is , is ook nuttige informatie voor contra-spionage.

Soms gaat dat mis - en worden spionnen daardoor herkend .
Lees Matt Blaze : https://www.mattblaze.org/blog/neinnines/ .
Een number-station waarbij de 'opvul-berichten' het cijfer 9 missen in de reeksen. En daarbij onderscheidbaar zijn van echte berichten. Er bleek een correlatie tussen de afwezigheid van een verdacht spionnen echtpaar en de timeslots in het number station dat dan herkenbare (geen 9 ) 'opvul berichten' bevatte.

Bedankt voor de uitleg hierboven, echt super duidelijk, thanks!