Enterprise firewalls are man-in-the-middling HTTPS sessions like crazy, and weakening security

Originally published at: http://boingboing.net/2017/02/08/enterprise-firewalls-are-man-i.html


Yes. All the time. Some companies MitM correctly with a series of hardened internal CAs, others are slapdash, and even others–like I’ve seen this too many times–just replace certs on the fly with self signed. “Just click through the warnings, it’s alright!”

If you’d like to hear me drone on about certs, let me know. But I promise it is dry and dull.


But I wish everyone had better knowledge of them. Too many many people replace Certificate with Magic Happens Here and stop thinking about it.


Some years ago we were trying to sell a certain distributed system to an enterprise which shall be nameless. The IT department complained that when they had read the messages sent by our clients via MitM, they found they were encrypted by a “non-standard cipher”. Yes, guys. Works as advertised. By the way, you weren’t trying to reverse engineer our protocol contrary to the DMCA were you?


I am pretty sure that is what Boeing does. I know that was gonna be the solution for print drivers but I escaped that bit of fun before it was going to be reality.
And I will say we had one video driver issue that was due to improper certs and luckily the server OS was properly hardened and kept going NOPE. I wasn’t sure how the vendor released the driver update with an internal self signed testing cert but they did. Took me more head scratching than I would have liked to figure it out but damn man the front line break fix admins should not be the ones to catch that shit even if things are locked down to prevent damage. It still took them a few weeks to fix it after we beat them up for it.


So, so, so many people–even infosec–have a lazy idea that Encryption equals Security.

When I feel sassy, I break out a pen and a notebook and ask them to do a simple Diffie Hellman key exchange. After they finish (if they do, but I use small primes), I ask a single question: how the fuck do you know Alice isn’t Jeff?

That usually gets them to think about the problem in a deeper fashion.

(My apologies to non infosec needs, that likely made zero sense)


It’s fun when you can’t upgrade your server or install python packages because the geniuses in IT put some middleware bullshit between your HTTPS traffic and all of the certs are garbage. That’s a good time to wake up to.

Work and personal IT: don’t mix the two. This has never been more important to follow. If my employer pulls apart my HTTPS from my work PC, OK: it’s their property. My personal phone has VPN so they can either kick me off the wifi, block the VPN (which will make me get off the wifi) or leave it alone.


This conversation is like catnip mixed with, oh, I don’t know, something else I can’t avoid liking. :grinning:

And yes, there is a reason I carry two phones, two laptops, three 2fa things, and… I’m gonna stop right there. I have some keys to rotate.


I always shake my head at the whole bring your own device people. Security incident waiting to happen.


Oh but {insert MDM vendor} said it will be transparent to both us and the user.


It’s a difficult problem. We want to keep our networks safe but we cannot inspect TLS traffic without decrypting the traffic. We want to keep employees from using prohibited services but cannot detect those services without decrypting the traffic.
Encryption is a great way to keep your session mostly secret. It is also a great way to deliver malware and viruses undetected through a firewall/IDS/IPS/proxy. You kind of have to pick your poison here.


Can’t you just blacklist the IP address(es) of the prohibited service?


but still a black art : )


boss, I blocked the CDN of $prohibitedService and suddenly our cloud-based ERP isn’t working anymore!


A lot of this can be better addressed via endpoint management. For instance, you can have a browser policy on downloads and site access, and you can enforce the use of your supported/authorized browser by requiring the browser to authenticate to a non-intercepting HTTPs proxy. You can use execution control that prevents unauthorized executables from being run at all, or you can just require virus/malware scanning before allowing execution. Of course these all have varying levels of impact on users and in any case are more complicated and expensive than just buying an interceptor box.

I don’t think I would say that SSL interception is never OK, but it needs to be treated as a major security weak point that needs to be protected carefully and the risk vs. effectiveness should be considered before just buying something off the shelf and assuming you are secure.


Dynamic/secure content shouldn’t be served from the CDNs domain name. Usually the CDN will have a certificate specifically for the target service with its own hostname, hosted with its own IP address and/or using SNI (using dedicated IPs for https sites is now obsolete). So you can still tell the service name of an HTTPS connection. You shouldn’t need to block the CDN domain if you are trying to prevent someone from using unapproved cloud services. Preventing file downloads is another issue, but there are other ways to deal with that.

1 Like

@nimelennar talked about blocking IPs, and services like Cloudflare play proxy for everyone and their dog


No. Send me a pm, I’ll get you an invite to Canary::Wharf, and we will walk through why.


Gah!! Pre-emptive apology. You are knowledgeable. But this doesn’t work. Full stop.

I am all about mitigating controls and risk assessments, but the concept of preventing unauthorized executables is akin to preventing thieves from stealing.

Yes, mitigate. Yes, have a plan when it happens. But preventing unauthed exes… That sounds quite a bit like the nsrl/carbon black/tripwire pitch. Which doesn’t work.