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.
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