6

My employer has set up what they're calling "SSL decryption" for Internet access from within the company. I believe this is provided by an f5 device. They have installed a trusted root certificate on all corporate devices, and are using this to terminate outgoing https, making their own https connection to the external server, intercepting all data in plaintext, and re-encrypting it using a fake certificate signed by their replacement root certificate. So, man-in-the-middling everything.

I can see that this interception is taking place by viewing the certification path in my browser, I get something like:

+- Acme Corporation Root CA
|
+--+- *
   |
   +--+- www.letsencrypt.org

The above is true for both Internet Explorer 11 and Chrome 65. However, when I try Firefox 59 I see the following certification path:

+- DST Root CA X3
|
+--+- Let's Encrypt Authority X3
   |
   +--+- www.letsencrypt.org

What I understand from this is that the Firefox connection has not been intercepted and decrypted. (If I've reached the wrong conclusion here, then that would be useful to know.)

Firefox provides under Technical Details the following info:

Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2)

I can't find a way to see which version of TLS is used by IE and Chrome.

Firefox does not show any installed corporate root certificate in its list of trusted certificates (as it doesn't use the Windows certificate store). Also, the security.enterprise_roots.enabled option is false.

My question is, why and how does Firefox avoid this? Is Firefox lying to me and the connection actually is being intercepted somehow? Is it using a different version of TLS or different cipher suite that the f5 device can't handle?

Note that I have read How can end-users detect malicious attempts at SSL spoofing when the network already has an authorized SSL proxy? which describes a similar situation but wasn't really enlightening. I have also seen the Certificate Patrol addon but that isn't compatible with Firefox Quantum. (Is there a replacement that does work with modern Firefox?)

Whitewash
  • 63
  • 1
  • 6
  • Does Firefox have specific DNS configuration? Or proxy? (depending on how your employer intercept all HTTPS traffic) Did you use it to visit `www.letsencrypt.org` before while not connected to your employer network (or through another connection like a personal tethering or something) ? – Patrick Mevzek Apr 05 '18 at 23:29

2 Answers2

12

It's quite simple really, it's your employer that hasn't secured their network properly. I guess that they add a system proxy settings or they configured the other browsers to use their interception proxy, and interception only happens when you are using their proxy, but they didn't put a network firewall to block traffic that doesn't go via the proxy.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • 4
    You know, I think you're absolutely right! It appears (checking with `netstat.exe`) that requests from IE and Chrome go through the usual corporate proxy, but Firefox doesn't. I had Firefox set to auto-detect the proxy, thinking that we had to use the proxy to get out (I know it used to be that way when I started here years ago), but just changed that to "No proxy" and it still works (I guess it was auto-detecting "no proxy"). Well, mystery solved I think, and I'll just continue to use Firefox. :) – Whitewash Apr 05 '18 at 23:50
-1

Firefox uses its own certificate storage, separate from the storage your operating system uses. Most other browsers use the system one, which you can read about in this answer. You can read about the Mozilla certificate policy on their website here, the most relevant part being:

When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla includes with such software a set of X.509v3 root certificates for various Certification Authorities (CAs).

Mozilla also have a tool called certutil for modifying the database.

Related: this question

JonRB
  • 393
  • 1
  • 6
  • 4
    I already understand that Firefox uses its own certificate store (I mentioned this in the question). But just having its own certificate store doesn't explain how it would bypass the SSL decryption. How does that work? Is it really bypassing the decryption, or is it actually being intercepted anyway and Firefox is lying to me? – Whitewash Apr 05 '18 at 23:17
  • The SSL decryption is happening through the corporate certificate, which as far as I can tell _isn't_ in your Firefox store. By firefox using the actual certificate for the service, there is no way that the man-in-the-middle decryption can happen over the network. Presumably the service is simply letting the traffic through, rather than rejecting it for not using the right certificates (edit: as mentioned in @lie ryan's response) – JonRB Apr 05 '18 at 23:27
  • 4
    @JonRB Firefox having its own certificate store means that it would be able to detect a corporate MITM and throw up a warning, but I don't see how it would be able to prevent a MITM? The browser has no ability to prevent the network packets it sends from being modified upstream. – tlng05 Apr 05 '18 at 23:30
  • @tlng05 As far as I know Firefox makes no attempt to _detect_ MITM, because it doesn't check the system store at all. It encrypts its communications with the upstream server so they cannot be trivially intercepted and changed. – JonRB Apr 06 '18 at 01:25
  • 1
    To my knowledge MITM is not something you can prevent; you can only detect it and throw a warning. This is a physical constraint, because you have no control over the packets once it leaves your computer. – tlng05 Apr 06 '18 at 03:55
  • If the packets are encrypted with keys that the MITM does not control (as in the case of Firefox, which doesn't have the corporate MITM's keys in it), the MITM will not be able to decrypt them. If the MITM is configured as such, it would be able to block any packets it does not control, but not decrypt them unless it has the appropriate keys. – JonRB Apr 08 '18 at 21:09
  • 2
    @JonRB: That's really not at all how HTTPS works. The mere existence of a root certificate in a client's certificate store does not mean that a MITM proxy can decrypt everything initiated by that client. First, it's a *certificate*, not a *key*. The root certificate is used to sign the certificate provided by the HTTPS server so the client knows to trust the server's certificate. – Whitewash Apr 08 '18 at 23:38