I like to browse the Web. In Firefox 3, we no longer allow viewing of https sites with self-signed certificates.

Right now, I can’t visit Microsoft SSL sites because of bug 399324. I would like my Web browser to allow me to browse the Web. Maybe it should treat self-signed SSL sites as it would a normal site.

14 Responses to “PRD1: Ability To Navigate To Web Pages”

  1. Topher Says:

    That would be cool. I have quite a few self-signed certs on my own sites for my own use. I actually don’t care if anyone else can use them, but I sure would like to.

  2. dafi Says:

    I always used signed certificates during my development life cycle and this is a boring solution :-(

    Maybe adding a button like “Continue at your own risk” is a better solution.

  3. Mike Beltzner Says:

    The basic problem here is that right now SSL errors aren’t being attended to since they are incredibly meaningless to users (which will hopefully addressed by bug 398718) and the ability to click-to-continue means that even if we could make them more meaningful, they wouldn’t be attended to.

    There are a few bugs on this, such as bug 398915 and even a few with suggested ways of making the exception-path less annoying, such as bug 399275. Johnathan, Mike Connor and I are also trying to figure out ways of making the action of excepting a certificate error more straightforward without being as facile as a clickthrough.

  4. Grillo Says:

    I1m 100% with you, they try to make the internet more secure, well let the users only see the about:blank page …

    Right now I can’t access a bank, my host, and didn’t had the time to fully test every site I browse since I discovered this this morning when trying to pay my host bill

    I will have to use IE for it, and the browser that I’ve sent to hell once is now on my everyday life again because there are many sites that I cannot access with FF

  5. Adam Says:

    “In Firefox 3, we no longer allow viewing of https sites with self-signed certificates.”

    That is one of the dumbest things I’ve ever heard.

    Self-signed https sites are no less secure than http sites. Why not just disallow people from browsing http sites? Oh, because that would be stupid!

    Your idea of treating self-signed https sites as http sites is spot on. The whole browser – including the UI – should just treat them as non-secure (http) sites. No padlock, no yellow address bar, warnings that third parties can view data on form submission, etc…

  6. Arthur Says:

    It’s especially problematic because the tooling support for server name indication in TLS isn’t yet available in the most often used libraries. OpenSSL hasn’t yet released a stable version with SNI support. This means that all those million of domains out there that share an IP address with others won’t be accessible via https with Firefox 3. And those running those sites don’t even have the tools at hand to correct the problem. So first we should have the necessary tools for the web hosters out there before instantiating such a drastic change.

  7. Asbjørn Ulsberg Says:

    Adam is spot on. I don’t really understand the fuzz. If a site claims to be secure (served over HTTPS), but the certificate fails to validate, then just serve it as it would have been over HTTP. Or is it fair to conclude that when a web site fails certificate validation, it’s deliberately trying to spoof the user and thus can’t be trusted? Sure, this might happen too, but Firefox has other mechanism to deal with that.

    The best solution is obviously to treat HTTPS sites with “bad” certificates as plain HTTP sites. Perhaps with a little warning, a broken padlock icon or something similar, to warn the user that the “s” in the URI doesn’t make the site secure.

  8. meandering wildly » Blog Archive » TODO: Break Internet Says:

    [...] but it seems like a bad play.  And so Rob Sayre is right to be a little miffed when it looks like we’ve done exactly that.  Sayre is often right, in fact, it’s his thing that he [...]

  9. Gerv Says:

    Do you think there’s a possibility we considered doing that before deciding on the current course of action? For those who can’t be bothered to read the bugs (and I admit, some are quite long) here’s the reason we can’t just treat self-signed certs as plain HTTP.

    Imagine someone who is not very computer-literate. He (let’s say it’s a he) has a bookmark to his bank, https://www.mybank.com/, which his son told him to use to be safe from phishing.

    Under the current Firefox 3, if someone subverts his connection via DNS spoofing or the like, and redirects him, he’ll get certificate errors with no way to continue. So he’s safe from the attack.

    Under a “self-signed is HTTP” model, the attacker could serve their fake site with a self-signed cert for “www.mybank.com”, Firefox would see the error, switch to an HTTP-like UI and load the phishing site, and the user would be at risk. Yes, the padlock or other indicators would be missing, but that’s not going to help everyone – particularly as this person was told “your bookmark is what makes you safe”.

    You can now get valid domain-validation SSL certs for free from http://www.startssl.com/ . Cost is no longer a barrier.

  10. Arthur Says:

    Hi Gerv

    “Under the current Firefox 3, if someone subverts his connection via DNS spoofing or the like, and redirects him, he’ll get certificate errors with no way to continue. So he’s safe from the attack.”

    If that person is extremely task oriented he will with just one click on an icon change the browser and he’s no more secure than before. It’s probably still the correct thing to do but I wouldn’t be so quick to call the user “safe from the attack”.

    “Cost is no longer a barrier.” Unfortunately it is. IP addresses don’t come for free. So you’re still forced to use the same certificate for several domains in regions where IPv4 addresses aren’t abundant. And tooling support for server name indication unfortunately isn’t yet there where it should be.

  11. arno Says:

    But if a webmaster (with few money) wants to use a certificate provided by another CA than startssl, users will not be able to access his site at all. Mozilla claims its goal is “choice and innovation”, but forcing to use startssl is far from providing some choice.

    And what if another browser does the same but chooses to include another free ca certificate ? Will secure sites have to target one browser, and be unavailable with other ?

    Is it technically possible in such a case to display something like: if you want visit that securely, you need to install certificate from xxx ?

  12. Dan Veditz Says:

    FF2 and 3 both support SNI (as does IE7 and Opera). FF1.5 will if you disable SSLv2 support (the SSLv2 hello conflicts with the TLS extensions).

    Don’t patronize a hosting company that doesn’t support SNI, and tell them why you’re going elsewhere.

  13. Iang Says:

    Certainly a self-signed cert can be treated like a plain HTTP site, from the point of view of pure PKI security logic. But it is a very different beast if treated as it is designed to be treated: a “trusted-first-party” identified site, Key-continuity-management, SSH model, etc etc.

    Perhaps the answer is to display the self-signed site as different. There are still plenty of colours left to use, and a security UI should anyway be a lot bigger than crammed into the URL box.

  14. Alex Says:

    Even addons.mozilla.org throws sec_error_bad_signature at the moment (and that’s the one you can’t override).

    Or half a dozen error boxes if you select “Get Add-ons” from the Add-ons window.

    – Alex