5

I'm far from a security expert, so the premise of my question might be wrong. If so please let me know.

In an enterprise setting, browser users are vulnerable to, and often subjected to, MITM attacks by the enterprise. The enterprise has complete control over how the browser is configured, so it simply pre-installs its own CA root certificate and configures the browser to trust it. The enterprise can then issue certificates for any website on the internet, and read or modify HTTPS traffic to them. For example, if a user accesses their online bank, they have no way of knowing if a rogue employee in the IT dept is intercepting their online banking password. Worse, they will be incorrectly reassured by all the expected security indicators (green padlock, correct name on the certificate, etc).

Revoking trust in the enterprise's root certificate would solve this, but the enterprise can prevent such configuration changes, and doing so would prevent the browser accessing intranet sites anyway, so it's not a solution.

Finally, since the enterprise (attacker) has complete control over the machine, it could just change the browser binary to display false security indicators (or install keyloggers, screen grabbers, etc). So let's assume that the enterprise's motivation only extends as far as configuring the browser and monitoring the network, and that the browser binary is unmodified. Let's also assume the browser is Firefox, since that's what I use.

  1. Is it possible for a NOVICE user, under these conditions, to reliably detect MITM attacks by the enterprise?

  2. If not, could changes made outside the control of the enterprise -- to Firefox itself, or to web security infrastructure -- block the enterprise from making a MITM attack without the user knowing?

4
  • This is not a highly noticeable solution, but if you know your external website had an Extended Validation cert (lock with name in firefox) and you only see the Domain Validation lock in the browser, you know the cert being offered is not the website's own. A more foolproof way that will work on any site is to record the certificate fingerprint from a known good connection and compare that to the fingerprint you see on the company computer.
    – Owen
    Commented Aug 4, 2017 at 2:58
  • Apart from these duplicates: if the system is controlled by the employer he can not only install new CA certificates but also change the software you are running, add extensions to intercept traffic before and after decryption etc - which is not noticed at the server end. Commented Aug 4, 2017 at 5:52
  • I expect that an answer to question 2 ("could changes made outside the control of the enterprise block the enterprise from making a MITM attack without the user knowing") would be yes, if Firefox was modified to warn when the "root certificate belongs to the enterprise rather than one of the Public CA" as per Lie Ryan's answer below. It's not really practical for the user to check this explicitly on every page load, so I'd encourage Firefox to implement this check and put a visual indicator in the address bar (and make it not able to be turned off).
    – Roofus
    Commented Aug 7, 2017 at 1:25
  • @Roofus: Using Classic addon API, addons can inspect the certificate chain and display or verify whether the issuer are part of the built-in root store or user added. Unfortunately, the Webextension API necessary for creating this type of extension is not yet available.
    – Lie Ryan
    Commented Aug 7, 2017 at 3:21

1 Answer 1

6

As long as the browser itself is unmodified, you can detect MITM by checking the certificate chain by clicking on the padlock icon next to the URL bar. When the connection isn't being MITMed, the root of the certificate chain should be a public CA. All public CA publishes their public key hash or you can cross check the root's hash against the root store you download directly from Mozilla. If you are really paranoid, you want to download the root store from a connection that you know for sure is secure. You can also audit the browser's root store (using the built in certificate manager) against the securely downloaded root store, to check that the browser's root store doesn't contain any additional roots that shouldn't have been there.

In practice, most Enterprise interception policy aren't meant to be hidden from their users/employees, so the CN field of the root certificate usually would clearly indicates that the root certificate belongs to the enterprise rather than one of the Public CA. Therefore, a much simpler way to detect MITM in this case is to simply check the name in the "Verified by:" field in the padlock icon popup. This is slightly less robust though, because it depends on the enterprise not deliberately going out of their way to try to hide that they're intercepting.

If the browser is modified, then all bets are off as the browser can lie to you. Note that installing a classic (non-Webextension) add-on counts as modifying the browser.

1
  • 4
    Thanks, good answer. I should mention that Firefox can now be configured to trust certificates that do not appear in its root store and are not visible in the built-in certificate manager. The setting is "security.enterprise_roots.enabled" which causes Firefox to use the Windows certificate store. It caused me a fair bit of confusion/concern that the root certificate listed in the site information panel could not be found using Firefox's certificate manager!
    – Roofus
    Commented Aug 7, 2017 at 1:17

Not the answer you're looking for? Browse other questions tagged .