Ask Slashdot: Does Your Employer Perform HTTPS MITM Attacks On Employees? 572
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?"
I suspect... (Score:4, Informative)
More likely an IPS (Score:5, Informative)
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/... [wikipedia.org]
Re:Rule #1: Never access non-work related stuff in (Score:3, Informative)
Re:HIPAA violations? (Score:5, Informative)
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...
Re:Not MITM (Score:5, Informative)
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.
Re:Yes they did. (Score:5, Informative)
This is very common
Very.
Your employer probably does little with this - it is usually a part of the configuration for Microsoft Forefront TMG (Formerly ISA Server). I f you have Outlook Web Access, and do any spend on MS recommended practices, then you have a TMG, and 9 out of 10 times, the "Inspection Proxy for SSL" feature.
The intent is to scrub the stream for malware attachments and malicious XML, etc. Most are set-and-forget, with little competence to exploit or understand what they have done.
Bigger corporations, or those aware of data sensitivity issues are another matter. Outbound traffic may be subject to this inspection, for DLP with something like Vontu Network Prevent. These controls are managed by folks who spend 25K on netsec, not 25 C's. :-) Then? Clever operators may be logging and trapping all kinds of info. Reports are very "compliance centric" 'tho. The DLP operator team usually has a fair amount of audit scrutiny. Usually...
Any way, TLS is irrevocably broken. It is reasonable security, trivially implemented and nearly as easily defeated. You own DNS and the path? You own the world.
I am involved in defining a new transport security mechanism for my company's products, because TLS/SSL of handwaving, and IPsec brittleness.
Re:Not MITM (Score:5, Informative)
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.
Re:Not MITM (Score:5, Informative)
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.
Re: Yes they did. (Score:0, Informative)
We do this as well, but just to clarify, it is called proxyin, not a man in the middle attack. You could of course abuse this to perform a man in the middle attack, but it is not an attack, until you abuse it. There are many legit and perfectly good reasons for having proxy servers, such as protecting rhe internal network from malware etc. We do have some metadata logging enabled on our proxy, so if an employee goes to his onlin bank, we can see this, but we cannot see the encrypted communication with the bank, or gain access to their logon credentials.
Re:Yes they did. (Score:5, Informative)
Want to read your personal email, chat, facebook? Use a phone or tablet.
Just don't use the employer's Internet (Score:3, Informative)
Shesh, Really? Man in the Middle "attack" ? Give me a break.
If you are using an employer's resources to surf the internet just figure that *everything* you do is monitored. If you don't want to be monitored, GO HOME. If you don't trust your employer, GO HOME to do anything you don't want them to see. GO HOME or use your own internet access.
Don't try to make this into some "privacy" issue. It's not.
My company does this (Score:4, Informative)
So we know it's happening - it's not really "hidden" - so I'ts up to me if I want to use Facebook or GMail or whatever - knowing the connection could be snooped. If I don't like it - I can simply not use those services from work.
Re:Yes they did. (Score:4, Informative)
Yup. Here it's perfectly legal if you're informed. Any time I log into a machine at work I get a banner that my employer reserves the right to monitor anything I do with their network.
Re:Yes they did. (Score:2, Informative)
1: Windows does log when a machine gets a new network interface and how it is configured. It also logs the unavailability of AD and other services that get communicated back.
2: Fire the offending employee for unauthorized access.
Re:Yes they did. (Score:4, Informative)
I don't know where you are, but in the US, that can be boiled down to 3 words: sexual harassment lawsuit. Way more damaging than someone just working half time.