I worked for an organisation in the same industry and they definitely do this. They have to because there are so many targeted attacks against their windows workstations. They inspect every byte passing through their email system and they have to do it with free webmail services as well. So they have to MitM.
We first found it with gentoo packages. Our linux installs didn’t have the special certs. I used to shake my head when I saw my co-workers doing their internet banking at work.
Even if you could get away with that, you would only be blocking the services which you had found to be a source of exploits by inspecting their traffic.
Don’t forget about data ex-filtration - this can be far more damaging in terms of monetary losses than employees visiting restricted websites.
Who the fuck is Jeff? I’m Bob…
Precisely. My. Point. Your question raises one of the fundamental truths that PKI solves when done right. The question, “who the fuck is Jeff?” should be raised with more regularity, but sadly isn’t.
Certs are a racket; CAs are the racketeers.
I use SSH for all my personal stuff. My keys don’t expire 
and I don’t have to trust a bunch of swindlers with a proven record of untrustworthiness and I can’t be MitM’d by a cheap appliance.
But at work, I ain’t in charge o’ that anymore, so every two weeks those damn kids implement forcepoint, and it breaks a whole lot of stuff, and they back it out again. They’ll make it work eventually, though, bad ideas never die.
I disapprove of this corporate MitM nonsense because it creates a single point of failure for all HTTPS traffic enterprise-wide. Smelty McBadguy hacks your MitM node and collects all your end user credit card numbers and passwords in one spot. It’s very poor security strategy to introduce a vulnerability like that…
Oh great another IT/internet related thing for me to worry about. I have a group in Feedly named “Security” where I stuck a bunch of security blogs and I never open it because most of what I’ve read in there terrifies me.
cough reverse tunnel to a VPS out of the country, and if you feel saucy encode AES in base64?cough
Word of warning, I have never done that, never will, and advise noone to ever attempt it.
I’m glad to see this research, especially the product report card on P5. I’ve not read through the whole PDF yet (actually going to have to print this out as my middle aged eyes cant handle such small fonts in double column on a screen) but at first glance the work looks solid.
That said, lets all be clear that this is not a The Sky Is Falling issue. As @japhroaig pointed out, HTTPS does not mean “security”. HTTPS does not magically adress all the many other weak points and certainly has nothing to do with the content that is within the encrypted session nor the configuration of the server the content comes from nor the end user PC/phone/whatever.
Regarding the report card on P5, lots of what is shown dont really seem to be “enterprise class firewalls” or even enterprise class products. What is nice to see is that BlueCoat comes out so well in their tests. IIRC BlueCoat is hated by Boing but their product does do what it says it will do on the box. Last place I put them in I got a 60% drop in desktop malware as soon as we enabled that feature.
At my last job, one of my tasks was doing the security orientation for new employees. I spent about 10 minutes of the 60 minute session on this point alone. Surprisingly a good number of the new employees thanked me for this, said that no employer had ever warned them about this issue before.
Endpoint management is just one piece of the puzzle. Definitely an important one but not one that can replace any of the border inspection points. One issue with endpoint management is like the herd immunity problem.
Lets say you have a perfect list of all clients & servers in your environment. Now lets say you can categorize them by criticality of both their infrastructure roles and by the data on or processed by them. Go to your endpoint management console and run reports on which of your devices are up to date. Sort by criticality. Get the idea?
There is a tremendous gold rush over the last few years in data loss prevention products for the enterprise. Some of this can be addressed by some of the HTTP gateway products but unfortunately even with gateway inspection, DLP features/products, locking down PC ports, etc. Data finds its way out.
I think the first person I saw talking about this was Richard Bejtlich and that was many years ago. Not enough people took him seriously unfortunately.
sigh
Now you are making me nostalgic for the says when we all believed in PKI, back when we thought we actually understood how “done right” was supposed to look and how we could scale it.
You know, if this infosec gig ever goes away, I am just gonna write horrible, horrible technology jokes.
“You thought the bad hombre DAP, was bad!? Beware his son, El-DAP!!”
(Obligatory "keep your day job!')
I’ve been dreaming about opening up a little kosher izakaiya for a few years now. I’m a decent cook and have a connection with a liquor wholesaler…
Oh fup yeah. That is a beautiful idea, but you’d have to do it David Chang style (yeah, we have five seats total, get in line), or Guy Fieri style (we have five thousand seats, so good luck on food quality).
It would be small, traditional rather than chain style. More “unnamed red lantern nomiya” than Watami.
I wouldn’t make a big deal about it being kosher but would be under local Chabad supervision.
See, while I come from solid Jewish stock, and would never ever ever pass off kosher for anything else, the entire process entices me.
If you ever are coming to Japan let me know. Even if I haven’t quit security for cooking & serving drinks, I’d be glad to meet.
You can for some things. However things like peer to peer connections generally will not involve fixed IP addresses.
You might want to move from saying SSL to TLS. SSL is deprecated and not often used these days.
I completely agree with the sentiment that buying off the shelf solutions and assuming you are OK is a bad idea. The problem as I see it is that while those controls should be in place, even when used together they are going to miss a few things. One quick example, malware or links to malware delivered via TLS encrypted email. Executable prevention on the Windows platform is not up to the task of preventing malware execution and unless you know before hand the IP of the malware server, you won’t be blocking that IP. So, your user gets and email with a link to some malware, they click the link, your authenticated-via-non-blocking-proxy browser opens up to that site via a TLS connection. No ‘executable’ is run so the scan before execution does nothing and now you have an infected system that gets to work infecting your other systems.
By intercepting that TLS session, we would have a chance to stop that malware before it is delivered to the browser.
Edit to add: I don’t intercept TSL traffic at my current job. I was lucky enough to move from corporate IT to a small firm where we don’t do that sort of thing. I personally don’t like TSL interception since I feel like I’m increasing the attack surface even if the proxy farm replacing the certs isn’t internet facing.
Since you offered: I have a serious question.
In your experience, do these enterprise MITM boxes correctly validate the certificate of whatever site they are MiTMing; or is there the amusing possibility that my dodgy self-signed cert; or would-have-been-detected-by-certificate-pinning fake cert will be cheerfully accepted by the firewall and then MiTMed with a locally generated cert that is exactly as trusted by the client PC as it would be for any other flavor of SSLed site?
Assuming that you are the legitimate administrator and your internal CA is in order and all that, SSL MiTM isn’t always inherently wicked; but since an SSL MiTM strips out the original cert information and replaces it with the IT department’s cert; an MiTM that fails to catch various certificate abnormalities is at a very real risk of ‘whitewashing’ those abnormal certs by replacing them with the something signed by the internal CA; which could lead to some very ugly problems.
First off, YES!!!Oneoneone
Internal CAs, even with good intentions, generally miss things like I dunno revocation, reasonable expiries, weak fingerprint hashes, CN mismatches… The list goes on. Even good internal CAs may miss things like allowing sslv3 in their accepted cipher list.
To your first question, I honestly don’t know. I know how to turn off every check in openssl, and when running my own MitM proxies I do exactly that. But I won’t disparage vendors simply out of conjecture (even though I know what they are up to)
since when does a CA control the negotiation of the cipher during the TLS handshake? shitty interception proxies may offer bad ciphers the real client finds inacceptable, but this is imo directly related to an in-house pseudo-root CA
Last I checked it is in the bundle. You can explcitly deny weak ciphers at the cert level, but ya gotta know you should do that.
