Firefox’s free VPN will offer 50 gigabytes of monthly data, which is pretty generous for a browser-based VPN. A Mozilla account is required to make use of it, which isn’t a hardship (they’re free), but is a point of friction some may wish to know upfront.
We had a proxy server at work that would route all internet traffic and scan for viruses, blocked urls or other traffic patterns, depending on your network rules. It did work on https and SSL traffic, because you had to accept the cert from the proxy server in your browser. So your traffic was encrypted between proxy and webserver, and proxy and your computer, but unencrypted on the proxy server itself. It would be similar with a VPN. Plus, if you control the browser you could just ship the required certs with the update…
So a VPN could basically sniff the Diffie-Hellman keys used during the exchange, recreate the key that browser and server use for HTTPS, and then decrypt all traffic sent through the VPN? Is that correct? And basically the same goes for any ISP or whatever else that’s acting as a node?
No, not at all. You have 2 encrypted connections A to B and B to C, where B is the proxy server. The proxy server decrypts AB, sees the plaintext traffic to check against rules, then reencrypts the traffic with his own key and forwards it to B to C. Your browser on C sees the proxy servers cert for BC, and the website and proxy handle out a different cert AB. No encryption or cert is broken during the process.
I just woke up and I don’t fully comprehend what you wrote, but I thank you for your reassurance. 🙏
disregard what I said on my other comment. I believe it to be correct, but despite the post title this is not a VPN, but a proxy, as the article says, that needs to decrypt the HTTPS traffic.
weird choice to be honest.
they were explaining what happens with a proxy server, but with only a VPN there’s no proxy server or other such decrypting middleman. but in short: TLS was made to protect against exactly this: the network between. only thing leaked is the domain you are connecting to
So if they were going to do an attack like this, they wouldn’t do anything like the DH attack you’re talking about, they’d have a custom CA in the browser’s SSL root store. That root cert means they can generate a certificate for any website you visit, and that custom root cert would be how they decrypt your traffic.
Afaik there isn’t a current attack on proper DH key pairings, but you can’t block the custom certificate path at the browser level without some serious server side work/client side JS to validate