6 ms·

Let's keep this simple. Let's say you are using an ISP to connect to a VPN provider. That VPN provider does what most of them do and SNATs multiple customers

by LeBit 3y ago

Let's keep this simple. Let's say you are using an ISP to connect to a VPN provider. That VPN provider does what most of them do and SNATs multiple customers connections to a single exit public IP. How can they correlate the encrypted wireguard data from my ISP connection to the VPN provider and then from the VPN provider to the final endpoint (say, ProtonMail)?

anonym29 3y ago
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...

6 ms·

Let's keep this simple. Let's say you are using an ISP to connect to a VPN provider. That VPN provider does what most of them do and SNATs multiple customers

by LeBit 3y ago

anonym29 3y ago
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...