Developer 32: Protecting against yourself
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.
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.