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?"
Yes, that is exactly what my company did. They got ratted out when they let the CA expire, but the argument was "Our hardware, our rules."
The usage rules stated something along the lines of they had the right to inspect and alter packets on the company owned network, so there you go...
Never answer an anonymous letter. - Yogi Berra
I own my company, and no... I don't do this to my employees.
I have warned people who've abused the system (I had some casual employees who spent inordinate amounts of time on Facebook, and I've had to clamp down on music downloads that could have gotten me into trouble) but I generally use HR methods rather than technological methods to take action.
This is a Man-in-the-Middle if the end-user is not notified of it.
Sometimes I doubt your committment to SparkleMotion!
It's more likely they are running the traffic through and IDS/IPS rather than logging everything. It's also likely that well know banking sites are excluded and just passed through. It does use quite a lot of resources to scan the traffic after all.
IDS/IPS https://en.wikipedia.org/wiki/...
My assumption is that the client logs all HTTPS traffic this way, capturing banking records, passwords, and similar data on their employees
A completely baseless assumption. I have worked with several organizations who do this "attack" to protect themselves from malicious traffic. I have not yet seen any that logged content. The legal and regulatory risks in doing this are too high to do this sort of data collection.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Also, it's worth noting that the kinds of devices that do this are often used for compliance with rules like HIPAA or PCI DSS. You can't demonstrate that you aren't allowing sensitive data out of a supposedly secured part of your network if you can't actually see what you're allowing out of it...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
A trusted proxy is a "Man in the Middle", so I presume your objection is to the word "attack"? Whatever you choose to call it, the fact is that SSL certificates are transparently being rewritten in order to capture data each website's SSL certificate was meant to stop from being captured. "Trusted proxy" is just a friendly euphemism which attempts to justify what may or may not be a legitimate practice, depending on what's being collected and whether or not the users are, in fact, specifically aware of it.
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
At my last job I did this to a limited extent. I decrypted filesharing sites and services so that I could scan files for viruses at the gateway before they made it to a computer. However, financial and medical industry sites were specifically excluded from decryption, due to the liability issues, and we publicized the fact that we were scanning encrypted traffic.
There are genuine uses for the technology. More and more sites are going to SSL all the time. That makes impossible to sniff the traffic for virus and intrusions. For schools and libraries, many of which are required to filter for content, unencrypted SSL prevents the content filters from working correctly. I expect that more employers will turn to this in the near future. Doesn't everyone expect
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"
At a former employer, we produced firewall hardware where this was SPECIFICALLY available as a feature. In fact, I developed the software for it. The certificates provided by the external servers are resigned by a CA cert installed on the appliance which is accepted by client machines behind it. Our equipment allowed the option of generating an internal CA cert, which would then be exported to all clients; generate a Certificate Signing Request, which could be signed by a CA already trusted by clients and imported back to the appliance (if the organization had it's own PKI infrastructure); or allow a resigning certificate and key to be imported.
The justification is simply this: "Our network, our traffic."
The practical reasons for this are to permit the firewall to do virus scanning on encrypted web pages and email (I handled SMTP STARTTLS and SMTP/SSL as well).
At least as far as the work I did went, there was no official way to take the plain text traffic off the appliance - it was not "designed" to snoop on employee traffic, though if someone managed to hack the appliance this would be theoretically possible.
Of course, if you are a contractor or employee concerned about the confidentiality of your traffic, you should exercise due diligence with regard to the CA's your machine trusts.
In our case, we DID have the capability to specify domain names for which this resigning would not be done: those that were "trusted" by the organization installing the firewall. This made it possible to go the extra mile and make some banking site traffic secure end-to-end, but it was on a site by site basis.
As I recall, I left the employ of this company prior to SNI support ever being implemented (we barely supported TLS 1.1, and certainly not TLS 1.2 when I was there, much to my protestations, and SNI is a TLS 1.2 Client Hello extension).
The appliance could also be used in a reverse-fashion: protecting web servers (but not virtual ones, for lack of SNI support, unless they shared a domain name), where it could just do SSL termination, with the site-specific certificate (presumably signed by a CA trusted by most browsers), though we allowed resigning here as well, in the event the internal traffic had to remain encrypted.
In Liberty, Rene
Yup. But proxies cannot handle HTTPS unless... they are acting as a MITM.
The proxy must either pass it along, block it outright or essentially stand in the middle so as to be able to perform all the usual filtering/sniffing/etc. it would do were the traffic plain ole' HTTP.
Yes, it's actually extremely common. Google "SSL Interception", as that's the name of the feature that is advertised on hardware/software that performs this function.
This is why I never browse private web sites on work hardware. You simply do not know how they've mangled the machine, what all it is revealing or to whom. (That's right, most large companies actually outsource security, so all of your private account numbers and passwords are going to third parties that you don't know and never will, third parties who have been indemnified and are completely immune to any kind of action or recourse from you if they screw up.) If I want to browse the web, I use a VPN connection to my house and my own personal laptop. I don't use my work smartphone for Facebook or personal email, I have my own personal phone using my own provider. When I'm working from home and VPNed into the office, I don't use my personal workstation for any work stuff, except as a VirtualBox host for a work VM, which my company has altered through group policy and direct installation of software to be configured how they want.
It's a shame that in today's work environment we have to worry about such things, but if you think the NSA is bad about spying on you, it's small potatoes compared to what your own company does. Never trust your company to just be innocently looking for malware or other intrusion detection means. Never install any software or services on your personal equipment from your company, no matter how much more convenient it will make your life. (This includes, for example, accepting elevated permissions to connect to your work email on your personal phone.) Always assume that they're watching you, looking for anything that can be used to fire you, cancel your severance, or extort whatever they want from you, whether you're just a paean on the low rung of the corporate ladder or the CEO.
I've worked very closely with both the network and security people in a large multinational corporation, and I've seen firsthand the kinds of things they do. It ain't pretty. I've seen people leave because they have moral qualms with the kind of monitoring that goes on, and people screwed because something innocent that everyone does was turned into a major issue. I cannot emphasize this enough; never, ever, ever mix your personal life with your work life, especially when it comes to communications and technology.
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!