14

I'm working on one client's network where they have enabled HTTPS authority spoofing on their proxy. This allows them to effectively perform a man-in-the-middle attack to decipher all outgoing encrypted traffic.

When I connect to an HTTPS site, my browser gets a certificate for the site which has been signed by the company's proxy - not the real certificate. Chrome and Internet Explorer say the website is secured (everything's green, no warnings) but Firefox says it's not. I know, given the SSL proxy is in place, that it isn't.

I guess that Chrome and IE accept the spoofed certificate because the proxy's certificate is deployed by the GPO. So, when the proxy sends a spoofed certificate (signed by itself) for a website, Chrome and IE show it as valid.

How can someone be expected to browse securely in this environment? With all certificates being signed by the proxy, how can I validate that the website isn't additionally being spoofed by some other third-party? I'm worried that there might come a time where Firefox is also configured to ignore these spoofed certificates. How can I prevent my browsers (Firefox, et. al.) from accepting these certificates?

Why do browsers allow this function? It would seem almost more sensible to completely disable HTTPS than to allow such a false sense of security as this. Is this not a major security issue - that the browser accepts seemingly-legitimate certificates even though they are not the ones provided by the websites?

Improve this question
8
  • 7
    "I guess Chrome and IE happily accept the spoofed certificate because" this certificate has been installed in the Windows certificate store by the system administrator.
    – curiousguy
    Commented Jun 20, 2012 at 16:51
  • 2
    I've said it here before, and I'll say it again: If you don't want a company monitoring your personal traffic, don't do personal web browsing on their network.
    – Iszi
    Commented Jun 20, 2012 at 17:09
  • 2
    @Benoît HTTPS is not "so (screwed) up" as you say - in fact, you've probably already demonstrated that yourself! You can always manually check the chain of any certificate you receive. The browser just gives its green/red light based on the installed list of approved certification authorities. You're under no obligation to use the website just because the browser says the cert is good when you know it's not. If you're worried about the client monitoring your HTTPS traffic, don't use your client's network - bring a cellular hotspot.
    – Iszi
    Commented Jun 20, 2012 at 17:17
  • 1
    (have you removed my comment?) yep, i get that but i'm really puzzled that there's no way for a client to check that the received certificate is genuine. Maybe i should look for a way to manually accept certificate on every first time connection? I wish browser could help me by telling me that the site is now presenting a cert different from the one accepted. And i don't understand the client POV, if they automatically spoof every cert, users can no longer detect fake/phished website and can potentially bring in dangerous content.
    – Benoît
    Commented Jun 20, 2012 at 17:26
  • 2
    @Iszi, to believe that a corporate root cert would actually be effective at detecting data leakage is credulous; it's a myth that only a tyrannical boss or self-serving "security admin" would perpetrate. Don't believe me? Ask Snowden. There are a hundred ways to leak data. All that the MITMed cert is doing is spying on the little guy's personal activities, and for what.
    – Asclepius
    Commented Aug 10, 2015 at 0:38

3 Answers 3

Reset to default
3

You might be interested in Certificate Patrol:

https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

It tracks which certificates you have seen before and warns you if they have changed prematurely. Of course, you could also just not install the company's root certificate in the first place.

Improve this answer
5
  • I accept your answer. Although i think this feature could definitely go into firefox. I have configured that plugin in paranoïd mode. Thank you.
    – Benoît
    Commented Oct 13, 2012 at 8:04
  • @Benoît, I think this plugin can indeed be useful to prevent bad CAs, but (a) it doesn't really help if the website changed its cert legitimately and (b) it doesn't help in your use-case: your problem was that your machine was trusting your proxy's CA. With or without Certificate Patrol, it still won't see the original server cert in such an environment.
    – Bruno
    Commented Oct 15, 2012 at 15:37
  • @Bruno If a website changes their certificate due to an upcoming expiration (a legitimate reason), then the Certificate Patrol will not warn about that.
    – Mark E. Haase
    Commented Oct 15, 2012 at 19:46
  • @mehaase, there are other reasons for changing a certificate legitimately potentially in the middle of the validity period. Some will trigger a warning with Cert Patrol.
    – Bruno
    Commented Oct 15, 2012 at 19:53
  • Unfortunately this addon is not compatible with Firefox Quantum. Is there a different addon that works for modern Firefox?
    – Greg Hewgill
    Commented Apr 8, 2018 at 20:27
8

How can someone be expected to browse securely in this environment?

You can't really. If there's an official MITM proxy and it's not your network, just don't do anything you don't want the network admins to be able to see. Use your own personal connection to connect to sites with personal accounts.

With all certificates being signed by the proxy, how can I validate that the website isn't additionally being spoofed by some other third-party?

I think it's fair to assume that the proxy itself, when it makes the connection to the actual website, does check the validity of the certificate against a list of CAs it was configured with (probably that of the OS it's running on).

I'm worried that there might come a time where Firefox is also configured to ignore these spoofed certificates. How can I prevent my browsers (Firefox, et. al.) from accepting these certificates?

The trend has always been to increase the awareness about invalid certificates in Firefox.

In Firefox, you can disable certain CAs by going into Options -> Advanced -> Encryption -> View Certificates -> Authorities. Then, use "Edit trust" (or delete a CA cert). You're likely to find the CA cert installed within this institution. You can also review the exceptions in the "Servers" tab, if any.

Why do browsers allow this function? It would seem almost more sensible to completely disable HTTPS than to allow such a false sense of security as this. Is this not a major security issue - that the browser accepts seemingly-legitimate certificates even though they are not the ones provided by the websites?

You're misunderstanding whose responsibility it is to ensure trust. Browsers are just there to use a list of trusted anchors. Whilst they often come with a default list, it's up to the machine's administrator (and/or the user) to check for the list of CAs they want to trust. (There's a slight exception to this with EV certificates, although it's not without its own set of problems.)

If you have a doubt regarding which CA is being use, click on the lock icon or blue/green bar (depending on the browser), you should be able to see the security details. Compare it with what you see using a machine you trust on a network you trust.

If you don't trust which CA certs are installed on the machine, don't use it. More generally, this boils down to this: don't use a machine you don't trust.

Improve this answer
14
  • 1
    Good answer, but I disagree with trusting the proxy to do the certificate validation for you. While I'm not familiar with the operation of SSL proxies myself, I expect this is something that can easily be broken by a bad configuration. If you need to trust an HTTPS cert (and let's presume this is for business purposes authorized by the company running the proxy) it would be best to have a way to validate it yourself - proxy or not.
    – Iszi
    Commented Jun 20, 2012 at 18:26
  • 2
    @IsziRoryorIsnti It's not ideal indeed, but if there's a MITM proxy, your SSL/TLS connection will end up there. You won't be able to see/change what it does beyond, when connecting to the target server. It won't have access to the target server's private key either, so the target server has no way to delegate its identity (and it shouldn't, really). What these proxies are doing is effectively a MITM attack with the consent of the client's admin. You just have to hope that the pseudo-attacker acts in the overall interest of the company ("with great power comes great responsibility...").
    – Bruno
    Commented Jun 20, 2012 at 18:38
  • 2
    @IsziRoryorIsnti Although SSL/TLS and HTTP are rather independent in HTTPS, in principle, this could be done quite easily when the proxy generate its certificate on the fly by placing the original certificate in a non-critical extension with its own OID, for example. The problem is that there would need to be a way in the browser to check that extension. This could be a bit tricky since the UI would need to take into account two chains of certificates.
    – Bruno
    Commented Jun 20, 2012 at 18:49
  • 4
    @Benoît the fact that the browser didn't warn you is part of the PKI flexibility: this is actually very useful to be able to update certificates (which have a date limit). In contrast, plain public keys (as used in SSH) don't have an expiry date, and you rarely have a initial known value to compare them against. "CA injection" would indeed be a perfect attack for a lot of things, but choosing which CAs are trusted isn't done remotely. Again, what you're worried about relies on someone (who had the permission to do so) adding that MITM CA cert to your trusted list: you can't fight against that.
    – Bruno
    Commented Jun 20, 2012 at 21:46
  • 1
    (...) On Firefox you can use CertPatrol to detect changes. I believe the restricted Chrome extension interface does not support checking certificates.
    – curiousguy
    Commented Jun 21, 2012 at 15:02
1

How can someone be expected to browse securely in this environment?

You can create a secure connection to the outside, such as a VPN. Then you tunnel all your requests through this secure connection. The problem is that the proxy might also understand the VPN protocol and intercept this as well. You can detect a VPN proxy if you compare the VPN certificate with a known-good version. If you're being intercepted on the VPN you'll have to find another protocol that the proxy allows to pass and does not intercept.

With all certificates being signed by the proxy, how can I validate that the website isn't additionally being spoofed by some other third-party?

You can't. You rely on the proxy to make the connection. It may or may not do this securely, but either way you have no control.

I'm worried that there might come a time where Firefox is also configured to ignore these spoofed certificates. How can I prevent my browsers (Firefox, et. al.) from accepting these certificates?

In my experience, Firefox provides the user more control by keeping its own certificate store. IE/Edge and Chrome both use the built-in Windows certificate store. Of course, an admin could change the Firefox store, so it just depends on what your admins do.

Why do browsers allow this function?

Sometimes you want to set up a trusted server without all the paperwork of getting a certificate signed by a public CA, or you want to do development or test work. In these cases you need to have control over exactly which certificates and CAs you trust.

It would seem almost more sensible to completely disable HTTPS than to allow such a false sense of security as this. Is this not a major security issue - that the browser accepts seemingly-legitimate certificates even though they are not the ones provided by the websites?

This is more an issue with your admins controlling your security than a browser issue. Think of it this way: you're not running Firefox, you're running a browser program provided by your admins that does what they want it to do.

Improve this answer

You must log in to answer this question.

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