Slashdot Mirror
Ask Slashdot: Does Your Employer Perform HTTPS MITM Attacks On Employees?
New submitter Matt.Battey writes "I was recently on-site with a client and in the execution of my duties there, I needed to access web sites like Google Maps and my company's VPN. The VPN connection was rejected (which tends to be common, even though it's an HTTPS based VPN service). However, when I went to Google Maps I received a certificate error. It turns out that the client is intercepting all HTTPS traffic on the way out the door and re-issuing an internally generated certificate for the site. My client's employees don't notice because their computers all have the internal CA pushed out via Windows Group Policy & log-on scripts.
In essence, my client performs a Man-In-The-Middle attack on all of their employees, interrupting HTTPS communications via a network coordinated reverse-proxy with false certificate generation. My assumption is that the client logs all HTTPS traffic this way, capturing banking records, passwords, and similar data on their employees.
My question: How common is it for employers to perform MITM attacks on their own employees?"
In essence, my client performs a Man-In-The-Middle attack on all of their employees, interrupting HTTPS communications via a network coordinated reverse-proxy with false certificate generation. My assumption is that the client logs all HTTPS traffic this way, capturing banking records, passwords, and similar data on their employees.
My question: How common is it for employers to perform MITM attacks on their own employees?"
This is a Man-in-the-Middle if the end-user is not notified of it.
Sometimes I doubt your committment to SparkleMotion!
Honestly I WOULD entirely agree if not for the MITM aspect.
If they really want to do that, setup a proxy and whitelist allowed sites. Deny SSL connections. Fine. Silent MITM attacks expose people in an unsuspecting manner; in ways that its unrealistic to expect most employees outside of IT to understand.
"I opened my eyes, and everything went dark again"
The company does not own the employee, and does not own the server that the employee is talking to, and so it really is a MITM attack. The company is the middle.
Your advice is on the nose, though. It is impossible to trust any employer run system, and therefore you should never, ever do anything of a personal nature on company systems. Even if, as where I work, using the company systems for reasonable personal use is allowed.
You, sir (or ma'am), are doing it right. This is precisely the thing that gets me so mad at companies today, that they view these issues as an IT problem, not an HR problem. So they spend hundreds of thousands of dollars (sometimes millions) in hardware, software, salaries, support contracts, and lost time when shit breaks, just so that management 1) won't have to do their jobs--you know, managing people, and 2) will have plausible deniability when someone does do something stupid. ("It's not my fault for not making sure my workers were working on what they were supposed to and not violating company policy; IT should have blocked that site!!!")
It's refreshing to see someone who actually gets where company policies should actually be enforced and where responsibility really ought to lie when there are gaps. Thank you!
For example, I have to pay travel expenses from my own money, and then get them reimbursed afterwards. That is, I may have a legitimate reason to access my bank account in order to e.g. pay my flight. But that doesn't give my employer the right to access my banking password (and possibly look what's going on in my bank account).
Also, if I'm not allowed to access my bank account from the company network, the right thing is not to decrypt it, but to block it.
The Tao of math: The numbers you can count are not the real numbers.