Hacker News Reader

Comment by brian_cunnie | Hacker News Reader

I don't think a modern firewall can MiTM HTTPS TLS without triggering a "Warning: Potential Security Risk Ahead" (Firefox) or "Your connection is not private" (Chrome).

Edit: typo

View on HN

I don't think _any_ firewall can MITM traffic without this happening unless you install the appropriate certificate in each client machine's trust store. I bet that with the advent of such all-in-one solutions as Fortinet or Cisco VPNs that this would be handled automatically. If not I'm sure an endpoint management solution could be coaxed into doing this via some glue scripts. I haven't been an "IT guy" in a decade-plus but I'd be surprised if this wasn't within reach fairly easily these days.

Yeah, that's what the IT at my company did. Installed Zscaler, rolled out a new root cert to Chrome, and then told people to configure the remaining apps they use to use the organization's root cert.

Sophos does that in fact. I did a double take when I noticed my domains weren't signed by let's encrypt on my work machine.

Which is why corporates who do this also use MDM to ensure that certs for the firewall/reverse proxy are installed on endpoints, RADIUS at network access points to authenticate devices by certificates and endpoint protection software to send nasty-grams if you fuck around.

That’s been my experience. The difference being in a corporate environment they can push policies to all employee endpoints that make this happen with no scary warning (trust the internal CA, etc).

Regarding SSH, the MitM would generate a new host key for the actual host you try to connect to. meaning when the MitM existed in the first place and you trusted the host key then (adding it to your Known_hosts), you will not get any additional security warning.

This can of course be avoided by the organization by distributing host keys to the client beforehand as they (maybe) would if the host keys were the actual keys from the host stored in /etc/ssh.

Correct. Companies that implement such a firewall must also install their own trust stores on the machines on the network. This can be a problem when you try to use some software that uses its own trust store from a public source like Mozilla (e.g. Python libraries).

It really makes you think how much your security hinges on that trust store yet it's something most people aren't even aware exists, let alone inspected themselves.

Pretty sure you still can, it just requires that the client system trusts the CA being used to sign the MITM certs. That obviously limits the cases where it works, but not to zero.

Because this has been abused, a lot of (mobile) apps use certificate pinning and will not accept MITM, even with a custom CA installed.

I don't for a moment believe that that's the reason (more likely, it's the apps trying to prevent reverse engineering), but yes, there's a bit of a cat/mouse game where you can read traffic but HTTPS prevents that but you can add a custom CA but apps can pin certs but you can modify the app to fix that. But I suspect that for the appliance case, a business can just require that the vendor allow a custom CA and block any traffic they can't decrypt.

Reply on news.ycombinator.com