Remember the SuperFish scandal? A third party application installed a Certificate Authority on PCs, and then hijacked all secure connections by serving browsers certificates from this local certificate authority. The SuperFish issue was widely publicized, partly because it combined several bad practices, but it is far from the only program out there that attempts to do this.

Here is what we said about programs intercepting secure connections in our previous blog post:

“In practice, this means that a browser is unable to check the identity and safety of the website, which reduces the overall security. Browsers go to great lengths to make sure that websites are using their certificates correctly, and that the connection only uses protocols that are known to be secure, and this sort of MitM approach prevents that. Even if, for example, the browser were to prevent the FREAK attack, if the MitM software did not fix it, the user would remain vulnerable. For that reason, we would recommend being especially wary of any software which operates in this manner, and would advise against allowing software to intercept HTTPS connections in this way.”

We also said that we were working on improvements to safeguard user security and privacy, even in the face of such problems. We are happy to announce that the Opera Developer 32 release contains such improvements.

There are many different programs that will attempt to intercept secure connections, examples are debugging (I often use Fiddler myself), corporate intranets, parental control, anti-virus, ad injectors and spyware. Any one of these programs would have to be installed locally on your computer to do this. This typically means that they have been installed by “you”, and they “own” your computer – that you have given them permission to do this (even if unwittingly). Any protection applied in Opera could in theory be counteracted by another program on your computer. In general we do not protect users against setups they have configured on their own computer.

Adding new roots to the OS list is an API call, and not necessarily a malicious intent on the program. However, doing this disables some security checks performed by Opera. Certificate pinning and certificate transparency both require public roots, so these checks cannot be performed. Some of the stricter checks on CAs might not be followed by private roots, so the check for certificate validity duration is also not applied. As more such checks are implemented, these too might have to be disabled for private roots. We feel users ought to know when security is reduced, even if this is due to users’ chosen computer configuration.

If we were to reduce the security indicator every time Opera encounters a private root, a lot of sites (potentially all) might be shown as insecure. This would lead to users expecting the insecure indicator, and not being able to tell the difference between an insecure site, and a “normal” occurrence of some checks being disabled. If we were to warn, users might get too many warnings, and stop paying attention to warnings. So we have opted for a non-intrusive, non-blocking warning, shown only once. Though if we were to store a setting if the user had been shown this warning, a malicious program could easily hide the warning by overwriting that setting, so we show it once per session. Lastly, as corporations often use local roots for their intranets, we do not warn if this happens for an intranet domain name.

The warning when intercepting a request to facebook.

In conclusion: Opera detects the first time each session when a certificate is not issued by a publicly known CA. It then optionally does two things: If you have chosen to share usage information with Opera (opera://settings/?search=usage), it will log this event, and send it back to Opera along with other statistics. If you have enabled the warning for unknown roots (browser://flags/?search=roots), it will show you a warning as below. Note that this warning is enabled by default in our latest Developer release. We aim to see what the statistics tell us before enabling this warning by default for any other releases.

One question remains to be answered, that of how we detect if a root is not publicly known. On some OSes, there is a flag stating if this is a root shipped with the OS or not. We can trust this flag, if malware had flipped it, the malware’s root would be subject to, and fail, stricter checks in Opera, thus causing more severe warnings in the UI. For other OSes, Opera is shipped with a list of known roots for that OS.

Back to top
  • > Remember the SuperFish scandal?

    Link doesn’t work.

    • Vux777

      there’s extra ” at the end of the URL…just delete it

      • Ok but they should fix this. I just stand out to show problem.

    • Sigbjørn Vik

      Thanks, fixed 🙂

  • Sometimes it is hard to get to the root of the problem, and to be certian you are at the root

  • Sascha

    This warning is super annoying, since it does not explain what exactly is causing the “problem”. After reading this blog-post I suspect it is the locally installed CAcert root certificate. If so, is there a way to whitelist it?

    • Sascha

      To answer my own questions:

      1. The console (Ctrl + Shift + I) shows the offending certificate(s) (see http://www.opera.com/blogs/desktop/2015/06/opera-developer-32-0-1899-0-password-sync-animated-themes-and-more/#comment-2087446555). In my case it was indeed CAcert.

      2. As mentioned in another comment on the Opera Desktop blog (http://www.opera.com/blogs/desktop/2015/06/opera-developer-32-0-1899-0-password-sync-animated-themes-and-more/#comment-2086120890), disabling the flag ‘opera:flags#warn-for-unknown-root’ does disable the checks / warnings. Not a perfect solution, but at least the repeated warnings are gone.

    • Sigbjørn Vik

      We plan to make it easier to tell what is causing the toolbar to appear. For now, adding the hostname and a link to view the certificate. The final UI will be different, but probably with the same info.

      There is no way to whitelist a root, for two reasons:
      a) The certificate checks on certificates issued by this root will still not be possible to carry out, so the browser will not be any more secure.
      b) Any possibility to whitelist a root would easily be set by malware, thus removing much of the protection.

      For now, it can be disabled in the flags – which also means malware might do so. Depending on the result from our statistics, we hope to enable this by default, with no way to turn it off. To manage this, we need to be able to make the warning non-annoying. Please check back on our next update, and tell us how you find the warning, and how we can avoid annoying you and like-minded users.

      • Sascha

        Thanks for the info. I’ll certainly test the next release.

        But if I understand you correctly, it will still warn my every time I start Opera (= with every new session)? In that case the warning will still be annoying since I have to click it away everytime I start Opera. That’s still a real bugger … at least to me.

        • Sigbjørn Vik

          Yes, with every new session is the plan. – This is the only way we can do it without saving a “has shown warning already” flag to disk, such flags can trivially be overwritten by malware.

          I’d like to understand your use case better. Is this just for a single website (that you happen to access when starting Opera), or do you use multiple websites that use CACert? Or is it installed as a local https proxy?

          • Sascha

            Here are some details regarding my use case:

            In our company we use CAcert certificates for internal services (time registration, monitoring, etc.). I have permanently pinned those pages/tabs and I suppose that triggers the warning every time I start Opera. That could be several times a day.

            For comparison:
            Android has a very similar behaviour on OS level. It warns about the locally installed CAcert root certificate every time the device is restarted. But this only happens rarly.

          • Sigbjørn Vik

            The warning should not trigger for intranet sites, only for publicly accessible sites (meaning the hostnames are bought and registered on a well-known TLD).

            It is quite common that companies use their own roots to secure their own internal services. But for publicly accessible (registered) domain names, one ought to use a publicly trusted CA, I take it your company doesn’t do this.

            I am not convinced we should add a workaround for companies not using best practices. We will have to make sure the warning is more informative than annoying though 🙂

          • Sascha

            In our case the internal services are used via Intranet and extranet. Therefore they are provided via a TLD.

            The CAcert root certificate is intentionally installed on every device to access these services via https. I really don’t see why the browser has to bother the user about it every time it’s started.

          • Sigbjørn Vik

            The browser is connecting to a public site, which presents a non-public certificate. When this happens, the browser disables some checks it normally performs for certificates – the browser should notify/warn the user about this.

            Malware may do this, and malware may alter saved Opera settings. To be sure to warn also about malware, the browser does not read any such setting from disk, and does not know if the user was warned before restarting – thus the browser warns every time it starts. (As you note, this is also what Android does.) You might know this is not malware, but the browser does not know this. And the browser cannot tell the difference between you informing it that this is not malware, and malware telling it that this is not malwre.

            Your issue has been noted, and will be taken into account as we continue development on this feature 🙂 We will try to find a way that works for as many users as possible.

  • Dark Magician

    Switch everything to HTTPS, including this blog.