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 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.
"Flyin' in just a sweet place,
Never been known to fail..."
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.