This is assuming that the website is encrypted (it starts with https://, not http://), which nowadays luckily most websites are. Otherwise they can see the specific page, it’s content and most likely also all information you input on that page.
My work runs MITM with corporate certificates, so they can see everything no matter whether it’s encrypted or not. If you don’t accept the certificates to let them monitor, you can’t browse.
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.
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.
Depending on the nature of the work and security protocols it isn’t the WTF. When you’re working, on your work device, on the work network, there is zero assumption of privacy (and there really shouldn’t be). The company wants to maintain it’s security and so it is ensuring it is aware of things happening on its network.
It’s not necessary for everyone everywhere but it has valid use case that isn’t some mega shady weird thing.
if the company had installed something that uses similar technology as a pihole, wouldn’t they technically be able to see everything even if you use https?
Mostly no. PiHole works by providing a DNS server.
A DNS server is responsible for turning domain names such as en.wikipedia.org into internet protocol addresses such as 185.15.58.224.
PiHole has a list of known ad serving domains and when asked to resolve one just replies with an invalid address.
Running the DNS server itself would only give them access to the above mentioned data. However, they could respond with wrong addresses to redirect all traffic over a man in the middle proxy.
For an https secured connection this would just result in a certificate error, warning the user to not proceed. Https secured websites have a certificate electronically signed by a trusted outside party, that verifies that they really are the owner of a specific domain.
Another option would be to redirect the user to a man in the middle proxy that pretends to not support https in order to trick the browser and server into opening an unencrypted connection. This works on some websites, but can be noticed by the user (as the browser now displays “Not Secure” and “http://”) in the address bar) and is protected again by newer security mechanisms like HSTS that allow websites to tell browsers to always contact them over https in the future.
Basically if the site supports HSTS and you have visited it before this also won’t work.
Ah I see. When I run adguard on a mac and enable system wide protection, I think it registers itself as a trusted certificate authority and works similar to the “man-in-the-middle” component that you mentioned. This is just my assumption based on the fact that on https websites, if I click the padlock, the certificate info says “Adguard CA”. It also has an explicit option for a deep packet analysis which explicitly states that it can provide better protection by inspecting https traffic so I am guessing that in theory it’s possible.
Yes. This works because AdGuard is installed on your Mac and adds itself to the trusted authorities there. Basically computers with adguard installed will trust the certificate while computers without AdGuard installed will not trust it.
Some companies do something similar (like another commenter here mentioned), where they install their own certificate on all work provided devices, allowing them to man-in-the-middle all connections. Personal devices without the company certificate installed will then just show the certificate error.
Usually the websites and apps you use, but not what specific page you visit and it’s content.
If you for example visit https://en.wikipedia.org/wiki/Labor_unions_in_the_United_States they could see that you visited https://en.wikipedia.org/ but nothing more.
This is assuming that the website is encrypted (it starts with https://, not http://), which nowadays luckily most websites are. Otherwise they can see the specific page, it’s content and most likely also all information you input on that page.
My work runs MITM with corporate certificates, so they can see everything no matter whether it’s encrypted or not. If you don’t accept the certificates to let them monitor, you can’t browse.
Therefore, I just don’t use it.
Is that for the VPN, or actually all wifi connections? Not sure how it would be possible for wifi
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.
deleted by creator
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.
WTF?
Depending on the nature of the work and security protocols it isn’t the WTF. When you’re working, on your work device, on the work network, there is zero assumption of privacy (and there really shouldn’t be). The company wants to maintain it’s security and so it is ensuring it is aware of things happening on its network.
It’s not necessary for everyone everywhere but it has valid use case that isn’t some mega shady weird thing.
I see, thanks
if the company had installed something that uses similar technology as a pihole, wouldn’t they technically be able to see everything even if you use https?
Mostly no. PiHole works by providing a DNS server.
A DNS server is responsible for turning domain names such as en.wikipedia.org into internet protocol addresses such as 185.15.58.224.
PiHole has a list of known ad serving domains and when asked to resolve one just replies with an invalid address.
Running the DNS server itself would only give them access to the above mentioned data. However, they could respond with wrong addresses to redirect all traffic over a man in the middle proxy.
For an https secured connection this would just result in a certificate error, warning the user to not proceed. Https secured websites have a certificate electronically signed by a trusted outside party, that verifies that they really are the owner of a specific domain.
Another option would be to redirect the user to a man in the middle proxy that pretends to not support https in order to trick the browser and server into opening an unencrypted connection. This works on some websites, but can be noticed by the user (as the browser now displays “Not Secure” and “http://”) in the address bar) and is protected again by newer security mechanisms like HSTS that allow websites to tell browsers to always contact them over https in the future.
Basically if the site supports HSTS and you have visited it before this also won’t work.
Ah I see. When I run adguard on a mac and enable system wide protection, I think it registers itself as a trusted certificate authority and works similar to the “man-in-the-middle” component that you mentioned. This is just my assumption based on the fact that on https websites, if I click the padlock, the certificate info says “Adguard CA”. It also has an explicit option for a deep packet analysis which explicitly states that it can provide better protection by inspecting https traffic so I am guessing that in theory it’s possible.
Yes. This works because AdGuard is installed on your Mac and adds itself to the trusted authorities there. Basically computers with adguard installed will trust the certificate while computers without AdGuard installed will not trust it.
Some companies do something similar (like another commenter here mentioned), where they install their own certificate on all work provided devices, allowing them to man-in-the-middle all connections. Personal devices without the company certificate installed will then just show the certificate error.
Understood. Makes sense.