this post was submitted on 18 Mar 2026
224 points (97.9% liked)
Technology
82830 readers
3398 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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?
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?
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.
Thank you for finally making how ssl/tls works click.
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?
assume the VPN provider is adversarial
now re-run your analysis
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.
They don't know the URL but they know the IP address so ... yes, they also can get the URL
IP addresses do not map to URLs.
They might map to domains, but not necessarily.
You cannot reliably get the URL from an IP, there's no direct mapping, especially with shared hosting.