Corporate networks (especially those utilizing MITM) block vpn access altogether.
You can’t reach your vpn server, falling back to plain un-tunneled https. Then instead of dns retuning the true ip, it returns a local corporate ip; you connect to that with https and it serves you a cert generated on the fly for that particular domain signed by a root cert your browser already trusts. Your browser sees nothing wrong and transmits via that compromised connection.
You can usually check for this by connecting via mobile data, taking a screenshot of the cert details, then doing the same on work wifi and compare.
If the cert details change on wifi, your traffic is being intercepted, decrypted, read/logged, then re-encrypted and passed to the server you’re trying to reach.
Every wifi network out there can and many do steal your info. Most just don’t actually use it. This is why trusting public wifi is a terrible idea.
It can and is done in exactly the way I’ve described previously in this thread.
Here’s an example:
My domain/home server, secured with a certificate from letsencrypt (domain obfuscated, obviously):
And that exact same domain/server via my my work wifi:
The certificate is replaced with one from Googles Trust service (they sell the ability to intercept and decrypt https traffic traveling through your network) served by a server local to my work lan, which then reverse proxies the connection out to my server leaving my browser unaware of the interception.
This can be done with any and every domain and doesn’t require any software installed on the client device.
You can’t reach the internet directly at all, all of your connections are either proxied through a lan server where all the data is logged/monitored or blocked entirely.
Depending on how your work vpn is configured; it’s very likely all traffic leaving your device while on that vpn is routed through the vpn to the corporate lan wjere its intercepted as above, then proxied+monitored. This is not limited to work-only activities.
The other option is split tunneling where traffic not bound for corporate infrastructure bypasses the vpn, but that’s not a common setup.
Can you link to something with more info on how it works? I know how certs work and CAs but not how some random wifi network can hijack that whole trust system. It sounds like it would defeat the whole purpose of https. Thanks in advance.
While this has traditionally been achieved by having the end client install a new certificate into their device for the corporations certificate authority, Google and other security firms also offer network appliances that will do this using certificates your device already trusts such as the above Google Trust Services LLC certificate. I’ve also experienced this 4 years ago with connections intercepted using certs from DigiCert and I’m sure there are others out there.
Https is dependent on a chain of trust, but most end users no little to nothing about it and definitely don’t chose which certificates to base that chain of trust on. Instead you’re given a set of certificates from the os/software developers and told to trust everything that leads back to those without any idea who has the authority to sign with those certificates.
Theoretically speaking; I could have an insider at letsencrypt who bypasses their check to see if I actually control a particular domain and instead just issues every certificate for any domain I ask for.
Your browser wouldn’t know the difference, just accepting them as valid certs as they’ve got the domains you asked for and they’re signed by someone the browser trusts.
Corporate networks (especially those utilizing MITM) block vpn access altogether.
You can’t reach your vpn server, falling back to plain un-tunneled https. Then instead of dns retuning the true ip, it returns a local corporate ip; you connect to that with https and it serves you a cert generated on the fly for that particular domain signed by a root cert your browser already trusts. Your browser sees nothing wrong and transmits via that compromised connection.
You can usually check for this by connecting via mobile data, taking a screenshot of the cert details, then doing the same on work wifi and compare.
If the cert details change on wifi, your traffic is being intercepted, decrypted, read/logged, then re-encrypted and passed to the server you’re trying to reach.
I was talking about work VPN, the thing I connect to every morning to access work’s internal services.
I don’t see how a 3rd party device connecting to wifi can have https MITM. Otherwise many wifi out there would do it and steal your info.
Every wifi network out there can and many do steal your info. Most just don’t actually use it. This is why trusting public wifi is a terrible idea.
It can and is done in exactly the way I’ve described previously in this thread.
Here’s an example:
My domain/home server, secured with a certificate from letsencrypt (domain obfuscated, obviously):
And that exact same domain/server via my my work wifi:
The certificate is replaced with one from Googles Trust service (they sell the ability to intercept and decrypt https traffic traveling through your network) served by a server local to my work lan, which then reverse proxies the connection out to my server leaving my browser unaware of the interception.
This can be done with any and every domain and doesn’t require any software installed on the client device. You can’t reach the internet directly at all, all of your connections are either proxied through a lan server where all the data is logged/monitored or blocked entirely.
Depending on how your work vpn is configured; it’s very likely all traffic leaving your device while on that vpn is routed through the vpn to the corporate lan wjere its intercepted as above, then proxied+monitored. This is not limited to work-only activities.
The other option is split tunneling where traffic not bound for corporate infrastructure bypasses the vpn, but that’s not a common setup.
Can you link to something with more info on how it works? I know how certs work and CAs but not how some random wifi network can hijack that whole trust system. It sounds like it would defeat the whole purpose of https. Thanks in advance.
https://www.cloudflare.com/learning/security/what-is-https-inspection/
https://blog.cloudflare.com/monsters-in-the-middleboxes/
While this has traditionally been achieved by having the end client install a new certificate into their device for the corporations certificate authority, Google and other security firms also offer network appliances that will do this using certificates your device already trusts such as the above Google Trust Services LLC certificate. I’ve also experienced this 4 years ago with connections intercepted using certs from DigiCert and I’m sure there are others out there.
Https is dependent on a chain of trust, but most end users no little to nothing about it and definitely don’t chose which certificates to base that chain of trust on. Instead you’re given a set of certificates from the os/software developers and told to trust everything that leads back to those without any idea who has the authority to sign with those certificates.
Theoretically speaking; I could have an insider at letsencrypt who bypasses their check to see if I actually control a particular domain and instead just issues every certificate for any domain I ask for. Your browser wouldn’t know the difference, just accepting them as valid certs as they’ve got the domains you asked for and they’re signed by someone the browser trusts.
Google and others sell exactly that service.