On Thursday, July 18, 2019 at 3:42:00 PM UTC-4, Matthew Hardeman wrote: > Regarding indicators, I agree that it should be more apparent. Perhaps a > dedicated bar that occupies an entire edge-to-edge horizontal area. > > I would propose that it might have two distinct messages, as well: > > 1. A message that an explicitly known MiTM certificate exists in the > certificate chain being relied upon. This would allow for explicit warning > about known MiTM infrastructures and would allow tailoring any "more info" > resource to explicitly call out that it is known that interception is being > performed. > > 2. A message that indicates that a non-standard certificate chain is being > presented, which might mean corporate interception, private websites within > an organization, etc, etc. > > On Thu, Jul 18, 2019 at 2:11 PM Andrew via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > I agree a persistent indicator is a good idea. From what I understand > > Firefox does already have an indicator hidden in the site information box > > that appears when you click the lock icon in the address bar ( > > https://bugzilla.mozilla.org/show_bug.cgi?id=1549605 ). This should be > > more visible in my opinion. Maybe add an asterisk next to the lock icon or > > something. > > > >
I don’t think a persistent visual indicator on the browser chrome is a terribly effective solution, for two reasons: 1) This warning will presumably be displayed all the time when the MITM root is installed and browsing from a Kazakh ISP. There’s nothing actionable that the user can do except remove the MITM root (and break your Internet connection, more or less) or leave the country, so it becomes a nag warning. This warning will merely induce warning fatigue for the user, so when another attacker attempts to MITM a connection (perhaps to steal financial information) or otherwise encounters certificate validation errors, the user will be desensitized to these warning messages and click right through the warning interstitial. 2) By the time the persistent visual indicator is displayed, significant damage has already been done, as the browser has completed the intercepted HTTPS connection and sent their HTTP session state (cookies, etc.) to the attacker. This damage is greatly compounded if the user accesses the Internet from a non-Kazakh ISP to visit (or login to) websites that the government disapproves of. When the user returns to using the Kazakh ISP, their previous login sessions that were first established externally will have their session state data (session cookies, etc.) sent to the government, so the government can engage in session fixation attacks or otherwise leverage this information. A persistent visual indicator would not help at all in this scenario. I was originally thinking that as an alternative to the persistent visual indicator, perhaps some blacklist of known MITM CA certificates can be created and content specific to each certificate explaining the risks of installing each certificate could be displayed in response to the user selecting the CA certificate to be added to the trust store. The user could then see the risks of installing the certificate and make a better-informed choice on whether to proceed with the installation. However, I don’t think this is a very effective solution either, as it requires that the user understand this information despite it being contrary to what the government is directing them to do, so it would merely serve to confuse a lot of users. I think the optimal solution in terms of user security is to create a blacklist of known MITM CA public keys and simply prevent the installation of certificates containing these public keys in the trust store. If several browsers could coordinate on such an effort, then perhaps that would pressure the government to back down on their demand to intercept TLS communications because their root is would be incompatible with major browsers. Thanks, Corey _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
