There is a known traffic pattern for a GET request to Protonmail - size of the initial request, # of subsequent requests (for subresources, like CSS, JS, images

There is a known traffic pattern for a GET request to Protonmail - size of the initial request, # of subsequent requests (for subresources, like CSS, JS, images, etc), and size of those requests, as well as size of those responses. There is a known overhead for encapsulating these requests in an OpenVPN or WireGuard tunnel. So even without looking at the contents of the traffic at all, the metadata your ISP collects can easily reveal that you sent outbound traffic and received inbound traffic that had a high statistical correlation with the expected traffic flow of a request to Protonmail encapsulated within a Wireguard tunnel, to a known VPN node, and then a (known) number of milliseconds before that VPN's upstream provider also made a request that perfectly matched the expected packet flow of Protonmail. If you have visibility into the traffic netflow of both your ISP and the VPN's upstream provider, consider yourself confidently unmasked. The initial fingerprinting laid firm groundwork for your adversary to suspect you went to protonmail, and then the network behavior of the first destination machine you connected to simply offered confirmation of that. In case you're unfamiliar with the concept of website traffic metadata fingerprinting I've discussed above: https://www.ietf.org/archive/id/draft-irtf-pearg-website-fingerprinting-00.html https://www.ietf.org/archive/id/draft-irtf-pearg-website-fin...