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…
Comment on Firefox 149 adds built-in free VPN with 50GB monthly data
victorz@lemmy.world 1 day agoCan a VPN provider do man in the middle attacks if they wanted to? Like sniff my /api/login calls and get my password? My gut tells me yes but I don’t know enough to be sure, I feel.
GenosseFlosse@feddit.org 21 hours ago
victorz@lemmy.world 15 hours ago
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?
GenosseFlosse@feddit.org 7 hours ago
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.
Passerby6497@lemmy.world 14 hours ago
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
Kissaki@feddit.org 20 hours ago
When you connect to a secure https site, then no. When you connect to unsecured http, then yes.
nymnympseudonym@piefed.social 1 day ago
If you have to install any closed-source software to use the VPN, the answer is oh hell yes, they can install a root cert. If they are clever they can remove it when you disconnect, so it will not be noticed by most people.
Even if they require no proprietary install, by definition the VPN knows every IP address you connect to. Even if you use DoH. Even if you use Quad9 DNS. The VPN knows you visited midwestsluts.com
If you want privacy, either spin up your own selfhost OpenVPN, or use the Tor nodes myself and volunteers like pay to make free for you to use. Tor node operators can’t tell what site you are visiting (if they run an exit node they can see the site – but don’t know your IP; if they run a Guard/proxy node they can see your IP, but can’t tell anything about what sites you visit or what data you get)
SlurpingPus@lemmy.world 1 day ago
the VPN knows every IP address you connect to
Joke’s on them, because half the web is behind CloudFlare now.
zeca@lemmy.ml 21 hours ago
What if the gov has access to both tor nodes, cloudfare infrastructure and mozilla servers?
RaisinCrazyFool@kopitalk.net 1 day ago
Generally not. Anything with authentication would be using HTTPS encryption. So there will be two layers of encryption: the VPN encryption and the web site’s HTTPS encryption. The VPN provider can’t replace the HTTPS encryption because your browser would identify it as being encrypted with the wrong certificate and it would block the connection.
Although…given that they control the browser, too, I suppose they could code it to remove those safeguards, but that would not go unnoticed for long.
When you use a VPN, it basically replaces your ISP as the intermediary who can snoop all your traffic, so the real question is who do you trust more: your ISP or Mozilla?
nymnympseudonym@piefed.social 1 day ago
assume the VPN provider is adversarial
now re-run your analysis
XLE@piefed.social 1 day ago
This is true regardless. HTTPS encryption keeps a man in the middle from seeing your URL. They just get the domain name, which is a lot, but it isn’t your credentials.
nymnympseudonym@piefed.social 15 hours ago
They don’t know the URL but they know the IP address so … yes, they also can get the URL
victorz@lemmy.world 20 hours ago
What I was thinking was that the VPN would be able to sniff the key exchange hand shake thing that HTTPS does in order to setup the connection, and use the data during the handshake to basically recreate the cryptographic key used for the connection later. So then it’d be able to just decrypt all traffic and reencrypt it again after passing through. Seamlessly to both ends.
Is that a thing in theory?
RaisinCrazyFool@kopitalk.net 14 hours ago
The SSL/TLS encryption used on the web is designed to prevent that type of attack. It’s called “asymmetric encryption”, because a different key is used to encrypt and decrypt data. So each side has both a private and public key. You can broadcast your public key, and then anyone can use it to encrypt a message that only YOU can decrypt, with your private key. The private key never goes over the network, so the VPN provider can’t intercept messages meant for you.
It’s possible to spoof the server’s certificate and make your browser think it’s talking to a real server when it’s not. However, this is difficult, because certificates follow a chain of trust, so they’d either need to compromise one of the certificate authorities (plausible for state-level actors), or compromise your web browser/OS so that it trusts a fake authority (definitely possible for a browser/OS vendor, but again, it would be noticed, especially in an open-source product like Firefox).
There are lot of enterprise products out there that perform this kind of “attack” so that businesses can monitor their network traffic. They do this by requiring adding their certificate authority to the list of trusted certs in the OS. This is often called “deep packet inspection”. If you try to use these products without adding their certs, your browser will throw a fit every time you load a site because it will see that the certificate doesn’t match.
victorz@lemmy.world 11 hours ago
Interesting, okay. Just to be clear, if the middle man, i.e. the VPN, were to listen in on the data exchanged during the TLS handshake, wouldn’t it be able to recreate both parties’ key pairs simply using the same algorithm? If it has all the pieces, so to speak. Or is the tech resistant to that as well?