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?"
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!
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..."
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"
And how legal is this over there?
This January, here in Portugal, things like that just became totally illegal, punishable with prison sentence.
Onda Technology Institute
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.
My previous company did it to:
They installed a Blue Coat proxy, and pushed to all windows computers (what normal staff was using) the configuration to use that proxy, and installed a trusted CA certificate so the proxy would be trusted.
That meant that most people didnt realize about the change, as both Explorer and Chrome used the Windows centralized certificate storage from day one.
The thing only broke for Firefox users (very few) who started getting not trusted certificate errors, and the linux machines when they set the firewall to prevent any http or htts traffic not thru the proxy. Most of those people simply started clicking on the "trust certificate" button.
A couple of weeks later they pushed an internal firefox installation and "forbid" people from installing it from the mozilla page.
Funny notes here:
a) they did it in an illegal way: in this country a company is allowed to monitor their employees network activity only if they make it very clear to them before starting to do so. They certainly did not. Actually our contracts said specifically that they did not.
b) after trying all kind of things they needed to give up on the idea of preventing any http(s) traffic off the proxy, as many tools (including EDA tools) required https connections to update and so forth and would not trust the proxy certificates. So eventually the firewall was left open for https. Who knew how to, could just work around the proxy in his own computer. All linux workstations were left connecting straight.
c) People realized and asked what was it. They lied to them with a straight face, with claims like: we dont unencrypt the proxy connections to banks, health (here we have a portal for online consultations with the public doctor and can access our medical history) or other similar private pages. This was a blatant lie anybody could check by just looking at the certificate issuing authority. They were doing it with _all_ pages.
d) they claimed this was only so they could scan for viruses in downloads. Not to monitor any activity.
e) I asked our local HR manager, she didnt have any problem telling the truth: "you are an engineer, you work on IT, you know how easy we can monitor anything we want.." and then made some funny remarks about the kind of pages people was enjoying in her previous company and how detailed usage reports she was getting. At that time I checked the blue coat page for the proxy we got installed, it could certainly log any activity in great detail.
f) My concern wasnt so much that they would monitor our activity (which was creepy), but the fact that all connections were unecrypted at the proxy. So somebody with bad intentions and access to the proxy could start collecting a lot of information. And this made the proxy a great target for hacking.
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.
Intercepting the network traffic of dishonest employees stealing company time and network access is perfectly legitimate
Why are you assuming that the employees are dishonest and stealing company time and access? My company specifically allows personal use of their network (within certain limitations), so nobody here is being dishonest.
as is the company reselling the captured personal data in the open market.
That's nowhere near legitimate, regardless of whether the employee is honest or not. That's an even greater level of dishonesty than someone checking their bank account on company time. If I found a company did that to me, I'd sue them as hard as I could, and I think I would have a decent shot of winning.
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.