On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland < asutherl...@asutherland.org> wrote:
> On 05/28/2014 07:16 PM, David Keeler wrote: > >> * there is only a single certificate store on the device and therefore >>> that all exceptions are device-wide >>> >> This is an implementation detail - it would not be difficult to change >> exceptions to per-principal-per-app rather than just per-principal. >> > > It's good to know this should be easy, thank you! IIRC, different apps can share a single HTTPS connection. So, for HTTPS, you'd also need to modify the HTTP transaction manager so that it doesn't mix transactions from apps with different cert override settings on the same connection. My imagined rationale for why someone would use a self-signed certificate > amounts to laziness. > We encourage websites and mail servers to use invalid and self-signed certificates by making it easy to override the cert error. > A theoretical (but probably not in reality) advantage of only storing one > per domain:port is that in the event the key A is compromised and a new key > B is generated, the user would be notified when going back to A from B. This actually happens regularly in real life. If you accumulate all the cert error overrides for a host then you end up permanently letting every captive portal the user has accessed the site through MitM the user. > David Keeler wrote: > > In terms of solving the issue at hand, we have a great opportunity to >> not implement the "press this button to MITM yourself" paradigm that >> desktop browsers currently use. The much safer option is to ask the user >> for the expected certificate fingerprint. If it matches the certificate >> the server provided, then the exception can safely be added. The user >> will have to obtain that fingerprint out-of-band over a hopefully secure >> channel. >> > David, I would like to agree with you but even I myself have never checked the fingerprint of a certificate before adding a cert error override for a site, and I suspect that implementing the solution you propose would be the equivalent of doing nothing for the vast majority of cases, due to usability issues. > I agree this is a safe approach and the trusted server is a significant > complication in this whole endeavor. But I can think of no other way to > break the symmetry of "am I being attacked or do I just use a poorly > configured mail server?" > It would be pretty simple to build a list of mail servers that are known to be using valid TLS certificates. You can build that list through port scanning, in conjunction with the auto-config data you already have. That list could be preloaded into the mail app and/or dynamically retrieved/updated. Even if we seeded this list with only the most common email providers, we'd still be protecting a lot more users than by doing nothing, since email hosting is heavily consolidated and seems to be becoming more consolidated over time. > NB: I do think that if we must make it possible to insecurely add a > certificate exception, then making it harder for users to do so is > desirable. My original hope was that we'd just provide a mechanism in the > settings app to let users add exceptions and we'd never link the user > directly to this from the email app. Instead we'd bounce them to a support > page first which would require a-hassle-but-not-ridiculous steps along the > lines of the long flow via Thunderbird preferences. It's unlikely a gmail > vanity domain user would decide to actively take all those steps to > compromise their security. > I don't think that making things difficult for the users of our software is going to improve things too much because users will blame us for being harder to use than our competitors. One way to discourage the use of non-trusted certificates is to have a persistent UI indication that the certificate is bad in the app, along with a link to more info so that the user can learn why using such certificates is a bad idea. This way, even if we make adding cert error overrides easy for users, we're still putting pressure on the server administrator to use a valid certificate. Regarding DANE: Any TLS registry can apply to be a trust anchor in Mozilla's CA program and we'll add them if they meet our requirements. We can constrain them to issuing certificates that are trusted only for their own TLDs; we've done this with some CAs in our program already. Any CA can give away free certificates to any subset of websites (e.g. any website within a TLD). Consequently, there really isn't much different about the CA system we already have and DANE, as far as the trust model or costs are concerned. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
