More on SSL errors

I got some great responses to my ideas for SSL errors and I thought I’d make a new post to talk about them, since that post is old enough that you can’t comment on it anymore. I should probably emphasize up front that I’m not on Firefox’s UX team, I don’t know if they’re listening to my suggestions, and anyway they were meant as a starting point rather than completely finished designs.

David Bolton wanted to know why some of the error screens asked the user to visit other sites manually, rather than doing checks behind the scenes. The main reason, honestly, is that that made a good example thing the user could do next. In practice we probably would want to do at least some checks in the background. Right now, another reason would be that error pages do not have chrome privileges so they can’t do anything of the sort (this is part of why the certificate error screen pops up a separate dialog box if you say you want to add an exception) but we may be able to get around that in a real implementation.

John Barton, in email, points out that SSL errors often come up in practice because of server-side configuration changes that ought to have been transparent to users, but a sysadmin goofed. I’ve been using the Certificate Patrol extension, which brings up warnings when a site’s cert changes in any way; this reveals that cert handling mistakes happen even on very popular and well-staffed sites (recently, for instance, mail.google.com flipped back and forth between its own cert and the generic *.google.com cert several times in one day). Of course that would have been invisible to most people, but it’s not much harder to make mistakes that do trigger warnings in a stock browser.

My general feeling on that is, yes, it is way too hard to administer an SSL-encrypted web site, and I would wholeheartedly support an initiative to make it easier, especially for sites that carry information of only moderate sensitivity (e.g. the plethora of Bugzilla instances with self-signed certs out there in the wild). I don’t think that should stop us from raising the visibility of SSL administration mistakes, as long as we improve the presentation and advice on those mistakes so we are not just training people to click through the errors.

John also points out that most people won’t have any idea what Herdict is or why they are trustworthy. The explicit mention of Herdict was mainly because I was riffing off Boriss’ earlier proposal to use Herdict information to improve page not found errors. Indeed, we should probably put it more like Other people who try to visit this website get (something) which (is/isn’t) what you got. We should credit whatever service we use for that information, but it doesn’t have to be as prominent as I made it.

Someone else (whose name I have lost; sorry, whoever you were!) pointed me at the Perspectives extension, which is said to do more or less exactly what I proposed, as far as comparing certificates seen by the user with those seen by notaries at other network locations. I like the use of the term notary and the proof of concept; unfortunately, Perspectives seems not to be actively maintained at the moment, and doesn’t work with Firefox 3.6. Also, for privacy, we want to make the queries to the notaries as uninformative as possible to an adversary that can observe network traffic. Reusing the same system that is used for is this site down? requests would help there. (Ideally, the notaries would also be unable to tell which users are asking what about which sites, but that might not be tractable.)

Responses to “More on SSL errors”

  1. Zoon

    the SSL Patrol extension might evolve into the direction Perspectives according to some devs

  2. Lennie

    First of all, don’t let people use self-signed. Really, just don’t. Their is no need for that.

    Get a free domain-validated domain from: http://www.startssl.com/ it doesn’t take a lot of time and it’s free and works with most browsers*.

    *Only Opera doesn’t recognise it; Chrome, IE and Safari on Windows do with a not-so-recent Windows update; Firefox and Linux-distributions have it build-in.

    Atleast some of the Bugzilla’s I’ve seen are using http://www.cacert.org/ so just one root-certificate-install to handle many.

    Also I have the feeling the problem with the servers of Google is, they have many servers and your browser is the only visiting different servers and Google does not change them all in a jiffy.

    1. Zack Weinberg
      First of all, don’t let people use self-signed. Really, just don’t. There is no need for that.

      What about the HTTPS-based management interfaces of networked devices, e.g. my ReadyNAS storage box? You don’t want to ship a signed cert with the firmware, and there is no way of getting a trustworthy signature onto the device at installation time.

      The best thing I can come up with for that is, the manual instructs you to attach a USB thumbdrive when you first turn the device on. The device completely erases the thumbdrive, and writes a self-signed cert to the root directory of the new partition. The manual then walks you through manually installing the cert as trusted-only-for-that-device. Which we (Mozilla) make a less horrible process than it is now. Better ideas welcome :)

  3. Simon

    One thing that would be useful would be a setting to whitelist sites under certain domains, typically internal sites. I know our product is invariably running with bad SSL certificates in our development environments, and I don’t care, because it’s not a production setup.

    Unfortunately, Firefox insists on telling me about the bad certificates every time I hit a deployment I’ve not used before, and the ability to tell it to not worry about that specific deployment doesn’t help much when they’re relatively transient. In that regard, Internet Explorer is actually better for me - it can’t be told to remember a given site, but it’s just one click to bypass the warning, where Firefox requires a lot more interaction.

    1. Zack Weinberg

      That seems like extension territory to me, being a very specific use-case and potentially risky for people who don’t know what they’re doing.

      1. Simon

        Perhaps, but compare it with the proxy settings dialog, where you currently have an option to say no proxy for these domains and IPs.

        Is there value in the core browser at least having the concept of trusted domains (much like IE’s security zones), so that I can declare machines on the company’s internal network to be trustworthy - not just for dubious SSL certificates, but as something extensions like NoScript or FlashBlock could use?

  4. Mook

    I actually like the dialog popping up - it proves to me it’s a chrome prompt and not a web page pretending to be one. As an aside: I tried to expand your current warning screen example, because I totally thought it was a real error page!

    I wish there were some way I can tell the browser to load the page without trusting it - perhaps I want to see a CACert-signed bugzilla, but I don’t want to actually let it do things like handle extension updates. Current even the non-permanent exception still applies all over the app, and not just per-tab.

    Sadly, I do get MITMed often - when my ADSL modem disconnects, it tries to redirect all http and https requests to its configuration page to try to get me to hit connect. Except that it’s using self-signed cert for the wrong domain… bah.

    1. Zack Weinberg

      Yeah, I like the idea of a way to load the page without trusting it. (Do we have don’t allow an unencrypted form submission that contains what appears to be a credit card number, I wonder?)

      There really needs to be a better way for routers to get your attention than by force-redirecting all HTTP traffic.

  5. Wladimir Palant

    Just a note: what you observed with mail.google.com most likely wasn’t a misconfiguration. You have to remember that it isn’t one physical server. There was probably a certificate update in progress. Depending on which physical server you connected to you could get the old certificate or the new one.

    But I still agree with the essence: SSL is very hard to deal with and many people get it wrong. Not to mention that there are many exotic configurations (like people who somehow managed to disable some root certificates - yet aren’t aware of that).

  6. Robert Kaiser

    What I noticed with your ideas was that tampering and real cert mismatch looks just like a self-signed cert screen from a fast look. I think there ought to be some very apparent visual cue as to what is inherently dangerous and what is first-visit with unknown cert case. When people don’t know them apart, they’ll mistake the former for the latter…

  7. Jason Airlie

    Please stop treating self signed certs as worse than no security! I still can not understand why Mozilla treats a small increase in security as if it were a massive decrease. Give self signed certs equal status as no security.

    First of all, don’t let people use self-signed. Really, just don’t. Their is no need for that.

    You may not have a need but I do. This stubborn insistence on forcing encryption to be locked with identity verification has crippled the use of encryption on the web. Yes I understand the importance of the combination, but SSH handles the problem properly. The Perspectives extension takes the SSH model and adds another level of protection.

    SSL certs are too much of a pain to get, setup and maintain. Small admin mistakes cause scary looking errors for end users, often when no actual problem exists.

    If I use a self signed cert on my own website, I know I can trust it, I don’t need someone else to vouch for me! I can handle adding the cert in my browser, but my Wife and family get freaked out and the end result is we must teach them to ignore the error, or not use encryption. Not exactly the ideal outcome.

    1. Zoon

      The problem is: MITM attacks happen and without proper authentication encryption is useless.

      1. Jason Airlie

        Yes MITM happens, but it’s not exactly common. The Perspectives extension is one better way to handle it.

        Encryption without authentication is not useless, far less valuable, but not useless. As long as I continue to see the same cert, I don’t need anyone else to authenticate my site for me! The same goes for the internal site I setup for work. When I tell people this is our intranet web site, I am vouching for the authenticity of the site. No one else need get involved.

        If I can be certain that the Amazon.com website is presenting me with the same cert it has presented me with the last 50 times I went there, I can be reasonably confident that it is the real Amazon.com. If I know other people elsewhere are seeing the same cert I can be even more confident.