New SSL policy in Firefox hurting tens of thousands of sites

FF3 SSL errorWith Firefox 3, Mozilla has changed the way Firefox handles SSL certificates. This change could scare away visitors from tens of thousands of websites that have expired or self-signed SSL certificates.

If you visit a website with either an expired or a self-signed SSL certificate, Firefox 3 will not show that page at all. Instead it will display an error message, similar to any other browser error (for example a “page not found” 404 message). To get past this error page, users have to go through four different steps before they can access the website, which from a usability standpoint is far from ideal.

This way of handling websites with expired or self-signed SSL certificates is bound to scare away a lot of inexperienced users, no matter how legitimate the website is.

It should be noted that this is not something that only affects smaller websites. For example, the SSL certificate for the official US Army website is declared invalid by Firefox 3 (see screenshots further down).

How common are these SSL “problems”?

Expired SSL certificates are actually quite common. According to a study by Venafi, referenced here, as many as 18% of the Fortune 1000 websites have expired SSL certificates.

According to Netcraft data, the number of SSL websites passed 600,000 in 2007. If we make a rough estimate and assume the same ratio as for the Fortune 1000 websites, that would mean that there are around 108,000 websites with expired SSL certificates. All these would get the “error page” in Firefox 3.

Anyone can forget to update their certificate; some examples are Google (for Adwords, Checkout and Gmail), Yahoo! and LinkedIn.

Another issue with Firefox 3’s approach is that lots of home routers are configured through web interfaces that use self-signed SSL certificates.

Real-life example, the official US Army website

This is what happens if you visit a website with a SSL certificate that Firefox 3 deems “not safe”. We used a login page on the official US Army website as an example:

Firefox 2 SSL handling
  1. The initial error page. It basically looks like any other error page that would show up when you can’t load a page. Note the little “Or you can add an exception…”
  2. When you click on the link you get the two buttons ”Get me out of here!” and “Add exception”, as well as an additional warning.
  3. Get the certificate, provided you clicked on “add exception”.
  4. Accept the certificate.
  5. Finally land on the actual page.

Why did Mozilla do this?

The point of this change was to make web browsing safer, and that is a good thing. There is a lot of malware on the Web. However, the people most in need of a clear and explicit warning regarding SSL certificates are inexperienced users, and those are not very likely to understand the error message that Firefox 3 is displaying. A large portion will simply be scared away, thinking that the website is broken.

Perhaps the error message (and the whole procedure) could have been presented a bit differently to make it easier for inexperienced users to understand, especially now that Firefox is entering the mainstream and is getting a wider user base.

So, from a security standpoint, the change in Firefox 3 kind of makes sense, but from a usability standpoint, the implementation is too confusing. You could say that the intention was good, but the execution poor. This is actually something that Mozilla itself seems aware of.  Jonathan Nightingale, who works with usability and security at Mozilla, had this to say in his blog in regards to how Firefox 3 handles SSL certificates:

I don’t think the approach in Firefox 3 is perfect, I’m not sure any of us do. I have filed bugs, and talked about things I think we could do to continue to enhance our users’ security while at the same time reducing unnecessary annoyances.

The impact of this will just keep growing

Firefox 3 was downloaded 8.3 million times in the first 24 hours upon its release in June. As user adoption of Firefox 3 increases, the effect of this change will have a growing impact, quite possibly putting a significant dent in the traffic to websites with expired or self-signed SSL certificates.

To not risk losing visitors, website owners should:

  • Update their SSL certificate(s).
  • Remove SSL from pages that don’t need it (for example the landing page).
  • Keep an eye on when their current SSL certificates will expire.

You can debate whether this change in Firefox 3 is a good or a bad thing, but that doesn’t change the fact that it’s already here and in use on millions of computers worldwide. Website owners need to adapt or risk losing sales, visitors and users.

There is a detailed explanation of the Firefox 3 SSL error pages over at the Mozilla Wiki.

What are your thoughts on this? Let us know in the comments.


  1. I had the problem. In my company, we use a self-signed certificate for our intranet : it is never seen by customers and it is free.
    The day after Firefox’ release, I had an email saying “Hey, the intranet is not working !”. In fact it was, but the error screen made the user think the site was down.

    Note that Internet Explorer 7 introduced a smililar screen. The “red button” making you think you will cancel the action in fact drives you to the website. But there is no “exception” feature I guess.

  2. There is absolutely no reason why a legitimate site used for doing business online would use expired or self-signed certs! They aren’t expensive and they are verified by a 3rd party.

    The whole idea behind this is so that phishing and spoofing will be reduced. You have to remember that 70% of people using the internet are dumb enough to click on email links and enter secure information without paying attention to the URL or SSL status.

    As your article points out, there is a way to add the expired/self-signed cert as an exception and therefore if a company prefers to use self-signed certs internally, they can still do so.

    I think the FireFox feature is perfectly appropriate.

  3. “A large portion will simply be scared away, thinking that the website is broken.”

    Similarly, if you put a broken link on your page, a large proportion of users will get an error message and think that the link is broken. If you use a red background on a page, a large portion of users will see it as red. If you place the word “wibble” on a page, a large portion of readers will interpret that as the presence of the word “wibble” on the page. If you…

    Oh never mind.

    Short form: they’ll think the site is broken because it _is_ broken. This Is Not An Error.

  4. The main problem is that there is no quick way to add an exception for this session-only. I had the habit of adding temporary exceptions for this kind of site, now it is just to annoying to have to click five times to do that (“Or you can add an exception”, “Really add an exception”, “Get certificate”, uncheck “Permanently store this exception”, “Confirm security exception”).

    Clicking twice (“Or you can add an exception”, “Add an exception for this session only”) would be okay. I think they should:

    1) let you see the certificate already when you press “Or you can add an exception”;

    2) show you the site already when you press “Really add an exception”. you can have scary text here, but show me the damn web page.

    3) show the little blue bar like the one for storing passwords saying “Add a permanent exception?” choosing among “Yes”, “Never”, “Not for this site”.

  5. I agree with Kevin, the whole point here is that inexperienced users are *supposed* to be scared away be the new error pages. Think about it: how can an inexperienced user tell the difference between a site that, while legitimate, just happens to use an invalid cert, versus a site that is trying to attack them?

    This policy was known long before FF3 shipped and anyone using self-signed certs should have known that the world’s second-largest browser was heading in this direction. The key is educating and preparing users by letting them know how to install the self-signed cert beforehand.

    And of course, rather than self-signed certs, sites should instead be using certs which are signed by their own self-signed CA (I’m pretty sure that’s what the Army does). That means users only have to install the root CA cert, which gives the site flexibility if they need to revoke or re-issue their actual site cert.

    Also, has been working with Mozilla to get its root certificate installed by default in Firefox, which means anyone could get valid, free-as-in-beer certificates issued to them once they prove they own the domain. Anyone who is unhappy with this change in Firefox should support to help them achieve that milestone.

  6. I welcome this change. It’s high time website operators are finally forced into not using self-signed certificates for anything that is not a test site. Self-signed certs give illusion of security, while they don’t prevent MITM attacks at all.

  7. Yeah, the intention is clearly to make it impossible to click allow “by default.” You don’t want the *VIOLATE ALL SECURITY RULES* action to be usable.

    I definitely agree with this for expired certs, but as one of the previous commenters notes, there are places where self signed certificates are useful, particularly as (a) public CA certs offer almost no guarantee of legitimacy given their lax approval processes and (b) public CA certs are ludicrously expensive for many use cases.

    There is definitely value in using SSL for obfuscation without a guarantee of security: keeping password sniffers off internal networks where there is low risk of man in the middle attacks, keeping user site visits private from their ISPs, etc. With a self signed cert, wholesale surveillance is impossible — the ISP can’t record all vists by default, the hacker can’t record all passwords on a network.

  8. Expired certificates are not by any means harmless. The vast majority of certs do not have any revocation capability, and therefore only periodic expiry keeps problems with them from being permanent. An example is the (unfortunately many) certs issued with fatally weak keys generated using Debian’s flawed OpenSSL package: once those certificates expire and are re-issued with proper keys, the only thing that distinguishes “my bank’s domain for real” and “oh look, a MITM using the old broken cert” is the expiration.

    Domain-validation certificates do not verify, and do not claim to verify, the identity of the organization on the other end, only the hostname; it is the weakest form of security that can be provided meaningfully by SSL, and self-signed certificates do not even provide that.

    Firefox 3 defaults to making the certificate exceptions permanent precisely so that users should see them infrequently for sites that they know to be “ok” through out-of-band information, and be alerted only if the certificate they see in the future is different. Organizations who don’t wish to get public-CA certificates for their internal machines can have their users install a signing cert once, and then use that to generate their internal certs to their heart’s content. The OpenSSL docs cover this case pretty effectively, and it’s what we do for our “internal” (non-public-facing) sites at Mozilla.

    (The risk of MITM is very rapidly approaching exactly the risk of password sniffing; see the most recent batch of easier-than-posting-to-a-blog tools for these sorts of attacks announced at Black Hat and Defcon this year, f.e., or the years-old Ettercap.)

  9. How does a self-signed cert not prevent MITM attacks? As I understand it the only difference between self-signed and signed is that you didn’t pay the cert company money. Functionally they are exactly the same. What the signed cert does (or at least is supposed to do) is verify that the site is more or less legitimate.

  10. You all miss the point of SSL certificates. It’s not about verifying the legitimacy of the site. It’s about providing a minimal layer of security so that data can be transferred to the site without snoopers or others getting their hands on it.

    Verifying the site is simply a requirement to the use of SSL certificates.

  11. The Army and the Navy both use the DOD as their certificate issuer. FF3 does not recognize the DOD as an issuing authority. Frankly, that is wrong thinking.

    I don’t think that Firefox should be the arbiter of who is and who isn’t a trusted authority. Expired? Throw a mention. Self Signed? Not a problem, perhaps a yellow lock instead of a green one.

    This “traffic-cop” error is needlessly alarming and confusing.

  12. This is pure Security Theater.

    It will reduce phishing by exactly 0%.

    Phishers mostly use HTTP, and even if they want to use HTTPS, it is trivial to find a CA who well give you a completely ‘legitimate’ certificate all for having a valid Domain Name and a credit card they can bill.

    This is an attack on people trying to use SSL to provide an encrypted channel for intranets, Open Source projects, personal sites, and other low-volume low-scale activity without paying a Certificate Authority some extortion money.

    This is more proof that the Mozilla Corporation is no longer running an Open Source project in the public interest but is now interested in operating an advertisement and ecommerce platform for the profit of the internet services industry.

  13. Why does nobody seem to care about encryption and prevention of eavesdropping? Everwhere this story pops up the commentary is full of people who believe that “MITM” attacks are the only things that matter. Unless you are merely a “consumer” and believe the internet is just a high-tech “Home Shopping Network™”, you may be a lot more interested in preventing (for example) other people staying at your hotel from “sniffing” your web-browsing traffic than in worrying about whether the NSA or FBI (who no doubt have the authority to compel pre-“trusted” Certificate Authorities to give them a “legitimate” fake certificate anyway…”wiretapping”, anyone?) is trying to trick you or Ivan Paypalovitch is hoping you’ll give him credit card numbers. Not all of us are mere “consumers” after all – some of us are participants here on the internet.

    Self-signed certificates are not “invalid”, they are “unauthenticated”. Yes, it is true that you are less certain of the identity of a server with a self-signed certificate than you are with one using a certificate from an organization that has been paid to say that they know who you are. But how is an unauthenticated encrypted link less secure than an unauthenticated UNencrypted link, which gets no Big Scary 4-Step Popup Box, or indeed any warning at all?
    It seems perfectly reasonable to me to withhold the “Happy Green Lock of Feel-Good Safety Assurance” icon from unauthenticated [or expired] certificates, but the elaborate and misleading obstacle course interface is gross overkill.

    The move from Firefox2 to Firefox3 is going in the wrong direction on this issue in my opinion. “Firefox 2 was too easy to use. We should fix that. We should also try to make it as inconvenient as possible for people to use encryption on their own without the permission of one of our ‘trusted’ professional organizations.”

    Personally, the whole idea that Mozilla may be deciding that their mission is to turn the internet into a “consumer” product rather than a communication medium is kind of sickening, but their stubborn insistence that this is the right way to go because they have to “scare consumers away” from stuff that might, maybe, possibly be bad kind of implies this.

  14. Epicanis: because a self-signed cert means you may as well not be encrypted. Go read again.

    In short, if your server is using a self-signed cert, and Firefox displays that as “fine by default”, I can sit on your network, intercept all the traffic between server and clients, re-sign with my own self-signed cert, and no users are the wiser. They may think their traffic is encrypted, but it’s not. I’m reading all of it.

    The solution to the encryption issue is not having browsers display self-signed certs as valid by default. It’s having a root CA that will issue no-cost certs.

  15. […]In short, if your server is using a self-signed cert, and Firefox displays that as “fine by default”, I can sit on your network, intercept all the traffic between server and clients, re-sign with my own self-signed cert, and no users are the wiser. They may think their traffic is encrypted, but it’s not. I’m reading all of it.[…]
    You forgot to mention also hiding a spy-camera in my hotel room, cloning my cellphone’s SIM card, and hiding under my bed in case I mumble my password in my sleep.

    What you casually describe yourself doing here is much more difficult and involved than merely sniffing wireless traffic (for example), and happens far less frequently and is far less of a risk. My privacy is at far more risk from “unencrypted” than from “unauthenticated”, much the same way that I am far more t risk for injury in an automobile accidents than from “terrorism”. By this analogy, the current defence of Mozilla’s new approach is the equivalent of “if you don’t have an armed air marshall on your plane then having a seatbelt is just a false sense of security” (but then reluctantly allowing someone who REALLY wants a seatbelt on an unguarded plane to fill out some confusing forms to requisition one before they board the plane if they’re willing to go through the hassle.)

    The “all or nothing” attitude is a little odd. I don’t think anybody is suggesting unauthenticated (self-signed) certificates should be treated the same as those signed by “trusted” authorities – only that treating an explicitly unauthenticated encryption certificate with the same alarm as a certificate signed by a third-party “” is gross overkill.

    Turn the window border amber and have an “encrypted by not ‘secure'” icon blinking or something. I doubt that would bother anyone, and that’s STILL more security than you get from a server with no certificate at all. Problem solved – there are ways for Mozilla to do all the consumer-scaring that its wants without acting as though it wants to stamp out self-serve encryption. (Or is this not an “act”?…)

    Cost is not really the issue here (StartSSL does offer a basic “free-as-in-free-beer” certificate-signing service). It’s only partly a “hassle” issue, too (having to go back to StartSSL or someone else every year for every server saying “Please, sir, may I have some more” is annoying but not THAT big of a deal). It’s really just the fact that there is even an implied requirement that you must get permission from an “approved” third party to “legitimately” use encryption and the fact that it’s “open source” Mozilla that seems to be fighting so insistently for this viewpoint – and that blog post that people keep insisting settles the discussion really doesn’t address this.

  16. Self-signed certificates are a way that an organization can hang a sign that says “kick me” on it’s back.

    For years I’ve argued with clueless managers that they should shell out the $50 /yr for a real cert. It’s great that Firefox is going to put them in their place.

  17. The problem with certificates is they’re trying to do two things at once. It’s validating that you have a secure connection and also implicating the validity of the site. However, an issued certificate doesn’t automatically mean the site you’re dealing with is legitimate, while an self signed certificate doesn’t mean the site is illegitimate.

    Implying the validity of a site through issued certificates actually harms security and serves no real purpose other than to enrich certificate issuers.

  18. When I’m sharing a computer I don’t want to “add an exception” or leave any traces at all if I can help it. At the very least, they should have a “just this once” option that lets you in but doesn’t remember the site after the current session.

  19. So, in summary, here’s a new huge batch of websites that work with IE and not with Firefox. It’s happened before. Most users don’t care why Firefox won’t show the website properly — if IE works and Firefox won’t, they use IE, period.

    It is actually an opportunity to try Opera, but I don’t think lots of people will.

    And for the webmasters: maybe it’s time to wonder whether you *really* need HTTPS. Do you really carry such sensitive informations?

  20. I’m responsible for approving the inclusion of CAs in Firefox and other Mozilla products. To respond to some of the CA-related comments:

    “The Army and the Navy both use the DOD as their certificate issuer. FF3 does not recognize the DOD as an issuing authority. Frankly, that is wrong thinking.” The US Department of Defense CA is an internal CA used for DoD-internal sites. The site mentioned in the original post is for Army Knowledge Online (AKO) and Defense Knowledge Online (DKO), which are sites for use by active and retired Army and other DoD personnel (and some DoD contractors, IIRC); it is *not* intended for the general public. Given that there a lot of Firefox users within DoD elsewhere, we might consider adding the DoD CA if requested by DoD; however we’ve never gotten an official request to do that.

    “This is an attack on people trying to use SSL to provide an encrypted channel for intranets, Open Source projects, personal sites, and other low-volume low-scale activity without paying a Certificate Authority some extortion money.” As previously mentioned, there’s at least one CA (StartCom) that provides no-cost certificates usable with Firefox (and perhaps in the future by IE and other browsers).

    “It’s really just the fact that there is even an implied requirement that you must get permission from an ‘approved’ third party to “legitimately” use encryption and the fact that it’s ‘open source’ Mozilla that seems to be fighting so insistently for this viewpoint …” You don’t need permission from anybody to add security exceptions or to add your own root CA for intranet use.

    Our policy regarding CAs and the default configuration of Firefox are designed for the vast majority of “typical users” of the public Intranet (who have no idea what a “self-signed certificate” is), not for the relatively small number of users using Firefox in an intranet context or in other non-public contexts. Those users are free to change the default configuration if it doesn’t suit their needs.

  21. New firefox 3 has many new security features that are causing pain to users and web administrators, take for example new anti-phishing anti-malware features where firefox queries a google service to tell which sites are potentially nocive, I had a webblog which was marked as having “malware”, but I could not find any such a thing and even scanned the very few files I had uploaded (with clamav), I had to subscribe to google webmaster tools to request a revision and remove the site from their database, however, I still haven’t received ANY response, I just shut down the site and subdomain, since then I’m using firefox2 or Opera exclusively (opera has better antiphishing features that don’t get in your way) and recommend Opera to my friends instead of firefox.

  22. Let’s all move to IPV6 so that the encryption is done at network layer without relying on SSL certificates.

    Dreaming about that in a couple of years.

    For now, any site owner should just spend $10-$20 to buy a real SLL certificate.

    You can’t get both convenience and strong security at the same time.

  23. @Fabien

    Uh, microsoft started doing the exact same thing with IE7. In IE7+, any site where the cert is expired or self-signed (including the google example Genius posted above) results in an a page that includes a red shield with an X, a message about a certificate error and a big, bolded statement of “We recommend that you close this webpage and do not continue to this website”. So saying that there is “…a new huge batch of websites that work with IE and not with Firefox.” is incorrect at best, deceitful at worst. If a site has a cert problem, the user is going to hit a warning page supplied by the browser in both IE7+ *and* FF3.

    I cant figure out why people keep trying to blame firefox for this issue when microsoft made a similar move when they released IE7 almost 2 years ago. Where was the outcry of bloggers then about this issue? The only difference between the two is that Mozilla’s method takes more steps to continue on to the site, whereas Microsoft’s method allows the user one click to continue on.

    I dont work for Mozilla, but I’m pretty sure their decision in this matter was based around protecting the end user. I’m sorry, but nowadays, the majority of users on the internet are clueless. They’ve been trained to click through error messages and dialog boxes to get to what they want. How many friends/relatives/coworkers have you had to save because they clicked on a link in an email, or opened an attachment in an email, or clicked on the “You’ve got a virus. Download this scanner” pop-up window?

    If your organization has a CA, and you are using self-signed certs for internal sites, it is an easy matter to add your company’s CA to firefox. That’s exactly what we do here on our campus. But if you are using self-signed, or expired, certs on public-facing sites, then you need to ask yourself WHY you are using an ssl-encrypted channel for your site. If you are doing it for security, then you need to either educate your users on why you are using that cert, and explain how to have your cert exempted in FF and IE. Or if your users arent that savy, then, for the sake of your users, you need to use an appropriate certificate.

  24. I still believe there’s something wrong here.

    If I go to a HTTPS website, and the certificate isn’t correct (not recognized, outdated, etc.), the browser should ask me if I intend to enter sensitive information.

    If I’m on, or a credit card payment page, I really care about security.

    If I just want to report a bug on, I don’t really care — it can be http, or proper https, or https with an invalid certificate, but just show me the damn page.

    Lots of non-critical websites use HTTPS for their own reasons. If the browser believes the connection isn’t secure enough, it should just tell me it’s no more secure or no less secure than HTTP, and let me access the page as if it was a HTTP connection.
    Or, to be logical, it should refuse any HTTP connection, since the server isn’t authenticated.

  25. Well, I think that is a good idea. I’m not trust in self-signed certs and every company must care about expired certs. You are trying to justify the lack of care and the bad practices of the use of SSL certificates.

  26. I guess we should start a fund-raiser for the military so they can pay for their expired certs.


    Don’t we do that on every paycheck????

    Don’t blame Firefox for blocking sites that ARE responsible for keeping their Certs and Registrations up-to-date.

    I am sure that if the entire site stopped continuing to work when the cert expired (like a domain registration) then they would immediately renew their certs.

    I am saying ‘Kudos’ for Mozilla to show this warning, regardless of who the site belongs to.

  27. For everyone saying “get a valid certificate”, have any of you even considered virtual hosts?

    Even buying a certificate (or getting a free one from startcom) for one domain will not resolve this issue on any other domains on the same IP address. Only one certificate can be used per IP.
    So, I run a couple of forums on the same IP (among about 50 different domain names), and offer SSL for those who want encryption because they are on an unsecure network. To do this now without getting this message on screen would require purchasing more IPs as well as more than one certificate.
    If every vhost out there suddenly required yet another IP4 address, we’d run out tommorow. IP6 is not widely used enough for that to happen.

  28. @Fabien

    So you are saying that Firefox should know whether encryption is more critical based on the site you are visiting? It should stop you if PayPal’s cert is invalid, but shouldn’t really do so if you are visiting your primary care clinic’s website to schedule an appointment? Because the latter is just a small site?

    Or maybe you should define what is a critical vs. a non-critical website.

  29. Self Signed Certificates are exceedingly useful when properly implemented for securing corporate (or Army) connections without having to deal with the SSL cartels usurious pricing.

    The problem here is not how Firefox handles self signed certs, it’s with how the companies using them are implementing them. A company can simply deploy their CA cert (or just the site cert) directly to those who are suppose to have it. Once FF3 knows it’s a trusted CA these messages disappear and SSL is allowed to do its thing without MitM issues.

    What we need here is better education for administrators not end users. Firefox is spot on with how it handles this.

  30. Those certificates are inherently broken. They should remove the ability to create exeptions as well, and perhaps go for ability adding the CA certificate to the store. It really makes more sense security, usability and adoption wise.

  31. Certificates cost less than $70 per year. This isn’t a push to make $$$.
    Its stupid that sites are self signed. It basically comes down to do you trust the site? its ironic that my banks use self signed certificates (if you dont trust them what are you doing banking with them), but for other sites (Such as buying / private communications etc) you don’t want to see that they are self signed when you don’t know much about them.

  32. The problem here, that most posters fail to grasp, is that Firefox is doing everything it can to make it look like a self-signed certificate is so much worse than plain http, with no encryption and no warning at all.

    Or turned around: No encryption at all is better than a self-signed certificate. That’s the message they are sending, intentional or not.

    Noone would have complained if they only showed the tiny padlock and the yellow address bar on fully “approved” certificates. That would send a message of self-signed being not secure enough for credit card numbers. Fine. Great. But the current system sends the message that self-signed is not as secure as plain http.

  33. So somebody hijacks the google domain, puts up his own self-signed google certificate. Do you not want people to have to think and check the certificate before passing on their credentials?

  34. A self-signed certificate is certainly in no way worse than no certificate at all. Firefox & IE should at a MINIMUM display self-signed cert’s without fuss. Obviously, it would be unwise to use the same “safe signal” lock icons, and I’d be fine if there were no UI indicating the difference at all beyond the https protocol, but it’s unfortunate that firefox removed the ability to encrypt traffic without identifying the other party.

    Expired Certs, on the other hand are a real problem. I don’t think an expired certificate should be treated the same as a spoofed one, but in the first month of expiry, a suitably annoying but circumventable warning might “suggest” to site owners to fix it, without breaking everything. Firefox’s (and other browsers too, for that matter) current behavior treats a site that’s one day expired identically to one that’s 10 years expired, which is ludicrous – expiry dates are at best a heuristic [i]anyway[/i] so they should degrade gracefully.

    Teaching users that heavy-handed security warnings are meant to be ignored (ala UAC and this cert-warning) is a long-term loss, and is to be mourned.

  35. @system
    If they are on a “insecure network”, then their DNS could be poisoned. I mean, whats the point of encryption if you don’t know who you are talking to? Self-signed certificates only makes sense it you confirm the encyrption in some other manner. In such a case, the “4-step” process hardly matters since you already went through the steps of using sneakernet or sending signed SSL certificates.

    The issue of expired SSL certificates is somewhat different. Firefox could probably be more lenient. At the same time, this will get all the sites to clean up their act and it won’t be a problem anymore.

  36. I agree with most of the users here and one of the designers of how Firefox handles this, Johnathan Nightingale: It should not be trivial to use a site that uses a self-signed or expired certificate. People need to think about what they are doing. If you know the site is trusted, freaking click 4 times and you’re done with it forever. It’s really not that difficult and it encourages the proper security of the Internet.

    If you want your site to have the best usability, install a proper certificate and keep it renewed.

  37. The problem isn’t just with self-signed certs. For example, my website uses a Plesk administered VPS. Plesk does not correctly updated the chain of trust when adding a cert. Given A PURCHASED CERT, FF3 complains, IE does not.

    Those who think this is solely an issue w/ self-signed certs are ASSuming facts not in evidence.

  38. Up until recently I used Firefox to perform most tasks within HP’s System Insight Manager. HP SIM uses self-signed certificates to setup trust relationships between the management server and the client servers. Drilling down to a single server requires importing and setting up an exception for each new self signed certificate within Firefox.

    Bottom line, until I have the time to find a workaround or assign a signed certificate to each server from our CA, we will not be using Firefox 3

  39. A page with expired or self-signed certificate is still a million times safer than a page that does not use HTTPS at all. I mean, HTTPS servers two purposes: 1. Certifying that the page is really what it appears to be (=trust) and 2. Encrypting data send between you and the web server (=encryption). A self-signed certificate that you do not trust cannot perform the first function, but it is still perfectly OK to use for encryption. A self-signed certificate is in no way broken, that is nonsense. Ok, expired certificates are broken, no arguing about that, but a self-signed certificate is not a reason for displaying four complicated dialogs. The user should be warned, but not in this intrusive way.

  40. @Ian Monroe: OK, let’s say that the user is sitting on a campus network using plain old http to access the site. Someone comes along with a packet sniffer in promiscuous mode and reads everything they are doing online. Maybe they even steal the cookies right out of the transmission and start posting as that user. It’s a lot less work to do that than setting up a fake site or proxying all the traffic.

    Sure, the users DNS *might* be compromised, but that’s a seperate issue. Maybe dnssec is in place, maybe the user is running DNS queries over SSH, maybe the user has the site address listed in the hosts file (thus avoiding DNS altogether).

    The fact that the DNS *may* be compromised is not a reason for not offering SSL, in the same way that the users OS being possibly compromised is not a reason to withdraw SSL.

    Presumably, one well written virus could simply add a fake certificate to the trusted list then alter the hosts file, allowing man in the middle on even purchased certs. Is that a reason to drop all SSL?

  41. I don’t think this is a good idea.
    1. Most “regular” users will simply be scared away from sites that did not actually pose any threat to them. These “false positives” (harmless sites) will outnumber the “true positives” (those that are actually malicious) by many-fold.
    2. Some “regular” users will hear just hear that FF3’s warnings are overkill, and learn to ignore the warnings and click past them. This is the “boy who cried wolf” problem. I don’t think this will teach people to think about security as much as it will condition them to ignore warnings.

  42. This is just as bad as UAC in Vista, and for all the same reasons. Adding protection for real security issues is good, but making the browser practically unusable in the process just means that people will have to use some other browser to get things done — just like they turn off Vista’s UAC or upgrade to XP to get things done there. As long as the other browser they use is Safari, I suppose that’s OK, but the unfortunate reality is, most of them will probably end up back on the IE abomination.

    Way to destroy what was once a decent browser, Mozilla team.

  43. One more thing, a certificate signed by an authority is just marginally more secure than a self-signed one. You can trick a certification authority into issuing you a certificate, they do some checking but to a skilled fraud it is not a serious challenge. The certification authorities are in fact a big placebo that still seems to work and is reinforced by web browsers such as Firefox 3.

  44. I think it would be solved changing the actual crazy and expensive system and including our self-signed certificate as a new field in the domain register page.

    In this way the owner of the domain name always would be the legitimate creator of certificates.

    No cost and secure.

  45. @Ian Monroe: A self-signed certificate is better than no certificate at all. That is a simple statement and nothing can be said that invalidates it. Why does not Firefox warn about using HTTP in the same way it warns about self-signed certificates?

    And a self signed certificate makes a difference. Without it all you need is a packet sniffer (which someone could be running for innocent purposes and accidentally reveal your password). With encryption you need someone who actively wants to break it. In a company network where employees are trusted not to be evil it is a big difference.

  46. I run a lab with dozens of serial port concentrators, APC remote power units and other devices that we all talk to via HTTPS to prevent password sniffing. Each of those devices has a self signed cert.

    It’s made using Firefox extremely painful- I desperately need a way to mark an IP range as “safe” because these warnings for every device, on every computer are driving me nuts.

    I’ve prohibited people from upgrading for now- but I’ll force a move to IE if this does not get fixed. It’s just too painful.

  47. – in poor countries (70% of this planet) $20 dollars still is an amount of money.

    – in the actual way, Firefox 3.0 is forcing webmasters to buy a certificate to authenticate themselves by phone calls, etc.. if they want to use encrypted communications.

    As a simple user, it only smells to more business and control.

  48. If certificates are going to provide the intended protection for consumers, they should be current and issued by a trusted source. Otherwise, the system is broken.

    Site managers should get their act together and keep their certs up to date.

    Consumers should be concerned when certificates are not valid. That’s that way it’s supposed to work.

    Kudos to Firefox for having the guts to hold web sites to basic security standards. Inconvenient now for the sites that have gotten sloppy. Good for all web users in the long run.

    Developers should be leading the way on this — it’s to your benefit that users trust the web so they can use your latest creations with some degree of confidence. Web users need real security solutions, not cosmetic ones. Otherwise, just post a padlock graphic on every site and admit that it’s “every man for himself.”

  49. Who cares about inexperienced users? really, get over that, people will learn eventually either the hard or the soft way. This is infinitely irritating to people who know what they are doing. Certs is what keeps me at FF2.

  50. You’re an idiot. It’s not the _BROWSER’S_ fault for being secure, it’s the _WEBSITE’S_ fault for being _INSECURE_. The browser is correctly instructing users to not trust sites which have _NOT PROVEN THEY’RE TRUSTWORTHY_.

    No one should be using a self-signed certificate for a website that needs to be secure. If your website needs security, buy a cert, that’s the only way people can verify you’re who you say you are (and not someone else pretending to be you). There are many inexpensive CAs around. No one is forcing you to pay a premium to Verisign–shop around.

    Encryption without Authentication is worse than no encryption at all, because at least with no encryption you _KNOW_ you’re insecure. If you lie to people and say they’re secure because the connection is encrypted, but you have authenticated it, they will have a _FALSE_ sense of security and feel comfortable revealing private information when they shouldn’t.

    Get a clue. Don’t speak about security if you’re an ignorant fool.

  51. @huh

    [quote]Who cares about inexperienced users?[/quote]

    Lots of us do! 1. Because they make up the majority of the users on the web now. 2. they are your customers, which means they are your source of income.

    I completely agree (with one exception) with chort: encryption without authentication is worse that no encryption. the only exception to this are sites that you already have a relationship with (and therefore trust) and that have provided a fingerprint for their self-signed certificate so that you can verify that the cert you got was the right one. But how many sites do you know of that use self-signed certs provide the cert fingerprint so you can verify the cert is valid? And on top of that, how many users do you think actually do it?

    The problem with letting users easily continue onto a site that is using a self-signed (SS) certificate is that the user is given a false sense of security. they see the lock (even if it is colored different), and think they are safe. But how do they know that the SS cert they received is the cert the site is actually handing out, and not one given to them by a hacker in a MitM attack? If I can get you to accept my cert, then I can listen in all i want. victim thinks they are safe because they are “encrypted” while i sit and collect passwords, CC #s, etc.

  52. First – where do you get off trying to imply fault with Firefox due to web admins not bothering to update their certificates? If a company is that lazy, I don’t particularly want to do business with them anyway – Fortune 1000 or not.

    Also, IE7 will give you the same error as well. IE6 and FF2 both will give you the same error, just in a dialog box rather than a web page format. And IE6 makes you go through about as many steps as FF3 does in order to accept the bad certificate. So it’s not a Firefox thing, it’s a web browser market thing, and it’s definitely nothing new. IT’S STANDARD WEB SECURITY.

    As for, it’s up to the user to decide if they trust the DoD. I have to say it’s pretty bad though that the DoD can’t either become a trusted CA or have their certs signed by one. These are the people who are supposed to protect our country, but they can’t manage to set up a trusted web site…

  53. As has been repeated here ad nauseam, encryption without authentication for web traffic is pretty useless. Any number of pretty easy attacks (MITM, DNS poisoning) can be used to impersonate any server and so you can’t actually have any confidence that your data is protected from sniffing or tampering.

    Which means self-signed certs are only useful if you manually authenticate them (by verifying the public key with the issuer via some side channel). Once you have done that, you can create an exception or just add it to your trusted cert store.

    But expecting user agents to ignore the fundamentals of cryptography to wallpaper over implementation flaws or bad practices is plain wrong.

  54. IE7 gives a warning that I can pass up in one click. Much easier than the five needed with FF.

    And yes, encryption without authentication is plenty useful- I want encrypted connections to prevent packet sniffing from turning up passwords- a policy mandated by corporate, but one I agree with.

    Just because you don’t personally deal with lots of appliances that self-sign, doesn’t mean that others might not have a legitimate need to do so. Lets see- 50 users, about 40 appliances… yeah, 5 clicks per user per appliance is a good use of our time….

  55. Just having encryption without authentication does not prevent sniffing of passwords, as you are still subject to MITM. Anyone who can sniff packets can also inject them… so all you have created is a false sense of security.

    Your earlier comment about “trusting IP ranges” is symptomatic of misunderstanding the security model. You can’t trust IP ranges, only certificates. If you want to trust all those appliances, either add those certificates to your trust store or create your own cert that you trust and deploy it to those appliances.

  56. This is all inside a lab and behind two firewalls, not on the internet.

    BTW- Do you really think that the color of a tiny lock icon, or even the presence of one does anything for the level of user that this protects against?

    In my experience, that is completely ignored.

  57. What, next year headlines will be something like: “Firefox 4 blocks all regular HTTP because of being so unsecure” ??

    Eavesdropping on regular HTTP is so much more easier and can be even accidendal, as in case of HTTPS you need some well thought approach.

    So the sentence “webmasters should see if their site actually needs that S in HTTPS” is plain stupid. Lets all downgrade from HTTPS to HTTP, that would stop all the nag screens and be SO much more better than an self-signed certificate.

    Mozilla guys seem to have forgotten that certificates have 2 points (authenticate site AND provide secure connection) and cry foul for millions of internal sites that use self signed certificates for many-many domains and sites.

    Currently webmasters have 2 options: a) downgrade to regular HTTP or cough up the dough for all certs, and so each year.
    No security vs better certificate issuer payday…

    Lets see the browser statistics after few months, probably firefox usage will go downhill 😛

  58. @Indrek

    Nothing is “secure” without authentication, so it’s a total oxymoron for you to say “authenticate side AND provide secure connection”–the connection isn’t _SECURE_ without the authentication. What on earth is so hard to understand about that?

    If you want to prevent sniffing, you might as well just use ROT13 for your “encryption” because that’s just as secure as unauthenticated SSL.

    The problem with automatically trusting self-sign/expired certs is that it gives the _ILLUSION_ of security, without actually being secure. It’s idiots like you who think there is some security without authentication who are perpetuating this myth and making the situation worse.

    For the final time: Stop blaming Mozilla and start blaming lazy/careless/stupid webmasters. If they gave a damn about their customers, they could easily lift their finger and solve the browser warnings. At leas the Mozilla developers care enough about their customers to try to protect witless end-users from themselves.

  59. The difference between HTTP and HTTPS is that the latter indicates the session is both authenticated and encrypted. If you don’t want authentication & encryption don’t use HTTPS, just use HTTP.

    Why isn’t there a scheme that provides encryption without authentication? Because it would be at best useless and not worth implementing.

  60. This is why I stayed with FF2. I tried FF3, but had immediate problems with it. Stay with FF2 until 3 is around a while.

  61. Chort: Once again, an authenticated certificate for every single domain is not an easy option because you can only use one certificate per IP.
    Some domains have to make do with SSL on a certificate that is not assigned to that domain, so you’ve already lost the authentication benefit. If and are hosted on the same IP, will have to use a.coms certificate or vice versa.

    Since we cannot have fully valid certificates on every single domain, is it better to do away with the encryption altogether?
    Even if the encryption is only there to protect passwords and cookies for a forum from casual eavesdroppers?

    Since a virus/malware could easily make MITM attacks possible against sites using authenticated certificates, should we do away with even authenticated certificates?

    Another example of how to perform a MITM attack against an authenticated cert is to temporarily hijack the IP of the MX server for the domain you are targeting, or poison startcoms DNS, while startcom are authenticating your email address. Grab yourself a cert signed by startcom (which is trusted by FF) and you can now use DNS poisoning or other methods and masquerade as the target site with no warnings from FF.
    Hell, you might not even need to get that complex if the domain you want offers email service and they have not reserved postmaster@, webmaster@ or hostmaster@. Check out for example.

    Authenticated certs are just as useless to end users when combined with attacks on other systems as self signed ones, so stop waffling about a false sense of security.

    P.S. If you genuinely believe that ROT13 would prevent sniffing in any way, I think you need to go read up on public key encryption and ROT13.
    For the sniffer to know how to decrypt the ROT(n) all he needs to do is visit the site and find n. With ROT(n), the text may as well be plain.

    P.P.S. Not all SSL sites deal with “customers”. They are not all handling credit card numbers or personal data. There are thousands of uses which only need a little more security than plain text http.

  62. extracted from

    Why can’t users get security right (revisited)
    Security people are wierdos
    • Go directly against millennia of evolutionary conditioning
    • No normal person would ever handle a user interface the way
    that security people do
    Security people design these interfaces assuming that
    they’ll be used the way that they would use them
    • At least one user study on PKI un-usability was greeted with
    disbelief by security people
    • It couldn’t possibly be this hard to use!

  63. Users know who they are; let them (i.e. each browser) have a self-signed certificate, and switch the roles. It’s the users who have to authenticate to the web sites later anyway. Why not require the browsers to initiate/require encryption? Flip the whole problem around.

    Then apache would have to figure out which users it wanted to talk to, and web site admins wouldn’t have to deal with buying and updating certs at all. 🙂

  64. Firefox guys, not allowing “allow for session” is a step backward.

    Everybody else, self-signed certificates *can* be more secure if users validate it through side channels. One does not have to trust a third party CA. Phone the site owner and the confirm the fingerprint, you are done.

  65. Another point to consider.

    When you choose to accept a self signed cert permanently, FF stores the cert and the fingerprint.
    If someone then attempts a MITM attack using a self signed cert, FF can spot the difference and alert the user.
    Where it all goes wrong is the automatic trust of CA signed certs. A MITM attack using a CA signed cert will not raise any flags for the user.
    If the attacker has a CA signed cert, it does not matter if the website is self signed or CA signed, FF will accept the new certificate.

    If FF really wanted to prevent MITM attacks, they would stop CA signed certs from over-riding stored certs without warning.
    You could then store self signed and CA signed certs (lacking in FF 2) for your important websites and be alerted to any changes.
    It’s why SSH always alerts you to any fingerprint change on server certificates (which are almost all self signed).

  66. @Frank Hecker
    ““This is an attack on people trying to use SSL to provide an encrypted channel for intranets, Open Source projects, personal sites, and other low-volume low-scale activity without paying a Certificate Authority some extortion money.” As previously mentioned, there’s at least one CA (StartCom) that provides no-cost certificates usable with Firefox (and perhaps in the future by IE and other browsers).”

    Now everyone read the part with more thought: “there’s at least one CA (StartCom) that provides no-cost certificates usable with Firefox (and perhaps in the future by IE and other browsers)”

    Mozilla developers encourage users/webmaster to use some CA that currently ONLY works with FF. No other browsers.
    Next we see some mozilla guy with a clever Apache hack, that can send that FF-only certificate to FF browsers and other main certificate to all other browsers.

    Currently everyone is complaining about MITM attacks and how easy it is to do them with self-signed certificate. But, how come I don’t see anyone thinking beyond ? Site sends a certificate to browser, browser stores certificate-per-domain in memory and when the certificate sent by server changes, it alerts user. Very easy and would quash all those comments that say it would be easy to insert packets signed with another self signed certificate.
    Plus, how cone none of the browser already do it ?? It should be quite basic ? Store in cache two values, domain name => certificate fingerprint. Creating a new self signed certificate creates new fingerprint which would cause browser to alert users when it receives data with changed fingerprint.

    Plus actually the fact that all those MITM comments miss, is that with regular HTTP, you don’t even need sophistication to act as MITM, you can sniff the unencrypted data right away, get the cookie information and see all the passwords as plaintexts.

    But I don’t see anyone complaining about HTTP insecurity, no, everyone is sooo worried that someone might come with special equipment to act as MITM for HTTPS connections rather than someone at rookie level with a laptop and special linux edition (available freely) might see your passwords in plaintext.

    Self-signed certificates are not that bad, what is bad is that browsers don’t alert users if certificate fingerprint changes in the middle of the session…. HTTPS is is secure by default for sniffing, meaning that no-one can sniff it. If you’re so worried that server admin/site owner is bad/crook, then you know, it’s not that big deal to get certificate from CA, pose as correct site, and still get your passwords and data stolen by site owner. And you may never even know which site was responsible for it.

    I sincerely hope that this 4 step process will be changed to something more easier (as it was pointed out, cert is valid for a signel ip, if you have 2 domains on same ip, then you’re screwed anyways). Self-signed cert provided security tops plain HTTP anytime and that’s the end of it.

  67. Another argument against Firefox 3: when I install a piece of software on my PC, I assume it will do what I want. If I want to go to a website, the browser is to show me that website, period. An icon saying whether the website is secure or not can be a good idea, but the point is: if Firefox 3 won’t show me the website I ask it to show me, it’s broken. If it’ll only show it to me after lots of clicking around, it’s being a PITA, so it’s only a little bit better than “completely broken”.

  68. When I first used Firefox 3 Beta, I went on my web server where I use SSL to crypt the communication only. I first tought that the site was down and I tried with IE to see that it was working. After 10 minutes, I understood that it was Firefox who has changed too much.

  69. Many commentors have pointed out that encryption is dangerous without authentication. That’s true; but conversely authentication is dangerous without CRL checking; and browsers generally don’t check CRLs (and site-owners generally don’t publish them). If CRLs were routinely checked, 60% of hits on HTTPS sites would result in requests to Verisign servers from the site-vistor’s browser.

    To me, that’s a *really* scary prospect.

  70. Wha…people are complaining about this?

    1) Update your certificate and keep it updated.
    2) Do not use ssl if you do not know how.

    It’s like complaining that your car leans to one side and that the road crews should tilt the roads accordingly.

  71. @Sadleric:
    “2) Do not use ssl if you do not know how.”

    You really think that all the points raised against this are because people don’t know how to use SSL?

    Even though I own a CA signed certificate considered valid by firefox for a domain name I have no affiliation with (making a MITM attack on that domain completely unnoticable), it must be because I don’t know how to use SSL?
    Simply owning this cert is enough to discount all the claims about self signed being susceptible to man in the middle attacks while CA signed aren’t.
    It shows that even with a CA signed cert, there is no foolproof authentication of who you are talking to.
    If the response is that it’s a little harder to get a fake CA signed cert (took me 2 minutes), thus making the attackers job harder, then there is nothing wrong with the argument that a self signed cert is good for preventing sniffing by making the sniffers job harder.

    That I understand fingerprints used for stored (self signed) certificates are more secure than blindly accepting a CA signed certificate must be because I don’t know how to use SSL?
    What needs to be known to prevent MITM is whether the certificate has changed, which can be achieved through the use of fingerprints. Carry out a MITM attack using a CA signed cert and FF will not bother to compare fingerprints, it’ll just accept the cert. This is BAD for security.
    Give the user a comparison of the certificates with a list of changes (issuer, valid dates etc) and the user can then make up their own mind.
    Keep showing users that they have to click accept on all certs to get rid of that annoying page and you’ve reduced security.
    Allowing users to store even CA signed certs as trusted and running a fingerprint comparison every time also wouldn’t hurt.

    That I know you cannot run multiple (individual) SSL certificates on the same IP but still run 50+ domains from a single IP must be because I’m stupid?
    Either we have to settle on giving every visitor to every domain a complete list of all the domains we are running (not good for web hosts) with a UCC cert and pay more for it (godaddy want nearly $700 for 50 domains), or we have to buy up more IP addresses and kill the IP4 space a lot quicker.
    However, as CA signed certs are NOT invulnerable to MITM attacks, we should do neither of these things. Throwing money or resources into a solution that does not work is not going to fix anything.

    The only thing a CA signed cert guarantees these days is that some company sent a single email to somebody they do not know. That’s what you’re placing your blind trust in. Doesn’t sound like such a foolproof plan now, does it?
    It hardly sounds like a position to be in when claiming others do not know what they are doing security-wise.

  72. This security certificate issue is so frustrating that i am about to dump Firefox alltogether.

    I have had validation issues from:

    MOZILLA.ORG (i can’t access add-ons)

    This is infuriating. If you can’t even make sure sites YOU built conform to the security standards, it is a real shame. And why IN GODS NAME can’t I disable SSL security verification? Just load the fucking site I am an adult and will gladly take responsibility if my computer gets raped by malware!!

  73. Using SSL with a broken certificate is always more secure that unencrypted http. However some might drop SSL because of this. If we follow this security idea, then one should get a warning and have to add an exception every time one wanted to use unencrypted http.

  74. This is definitely a bold step and this is exactly how the evolution occurs. You take the initiative and eventually realize its shortcomings.
    Then you improve.

    If one attempts to analyze this step in the larger picture, it seems headed into a positive direction.

  75. Jd wrote: If one attempts to analyze this step in the larger picture, it seems headed into a positive direction.

    Well, if that brings a convenient and free way to have valid certificates (and several on the same machine), it’s indeed a positive direction.

    But in the meantime, you’ll have a very small number of new valid certificates, along with a huge number of websites either less secure (because HTTP is less secure than self-signed HTTPs), or not accessible from FF3.

  76. #17 from the Deadly Sins of Software Security:

    [quote]Unauthenticated Key Exchange
    Exchanging a private key without properly authenticating the entity/machine/service that you’re exchanging the key with. To have a secure session, both parties need to agree on the identity of the opposing party. [/quote]

    @Indrek, system, etc
    Here is why self-signed certificates are bad for the general public (emphasis on “general public”): it gives them the impression of security even though they have done nothing to ensure security. If you have done any programming for end users, you know that 80% of the people out there do not read. At. All. So, when they get a notification of a problem with a certificate, they just click “continue” without further thought. This is why a MITM attack on a site with a self-signed cert is so easy. The majority of users will never, ever stop to check the fingerprint, or even give it a second thought. they’ll just keep clicking through. Even if the cert error comes up in the middle of a session. But they see the padlock icon and ASSUME that everything is secure. That’s why giving self-signed/expired certs the same easy acceptance as Authenticated certificates is more dangerous than standard http: because the user THINKS their connection is secure, when it very well might not be.

    Now, for the other 20% of the population out there, SS certs aren’t an issue. They know to check the cert, get the fingerprint, and then compare it to what the fingerprint should be. They become highly suspicious if the site they are on suddenly presents them with an unknown certificate in the middle of a session.

    But those users arent the ones Mozilla is trying to address here; it’s the 80% they are trying to protect. By making it more cumbersome, they are at least TRYING to drill it into the user’s head that there might be an issue.

    SS certificates have a place: intranets and sites where only that 20% visit.

  77. It is annoying. I am trying to access my bank online and got a certificate error. I added an exception and now all the page says is: “It works.” I worked on the internet for ten years and there is such a thing as too secure. I wish I never updated to firefox 3.

  78. ********************************************
    It is a great step taken by firefox and everyone should appreciate it.

    In the above example of the US army website, it’s pathetic that being an official website they haven’t installed a proper certificate.

    It is the responsibility of professionals to create security awareness among end users about this and not to criticize the bold step taken by firefox.

    Instead of making negative comments about firefox in forums and blogs like this one should encourage people to follow this, so that webservers would be installed with necessary certificates by respective authorities, thus increasing security.


  79. So what about certificates which are valid but don’t have a chain back to Thawte/Verisign/etc. – i.e. stuff you paid money for but Firefox still thinks it’s fake?

  80. Good to see the shills for the SSL cert companies are out in force. There’s really little reason for this system other than to force more people to buy certificates.

  81. “Epicanis: because a self-signed cert means you may as well not be encrypted.”

    No it ABSOLUTELY does not, OBVIOUSLY.

    OBVIOUSLY, a PASSIVE listener (f.ex. on a wireless link) will not be able to decrypt an SSL session made with a server using a self-signed certificate.

    OBVIOUSLY, going from PASSIVE to ACTIVE means taking the risk of being detected, especially when fake certificates are going to be inserted, and thus MUCH LESS LIKELY to be done all other things being equal.

    That makes it a MUCH LOWER RISK to have an SSL session with a server using a self-signed cert than a clear-text session.

    You understand NOTHING about security. You just repeat what you have heard.

    Let the grown-ups talk and LISTEN.

  82. “An invalid cert is no less secure than vanilla HTTP, why all the ruckus? ”

    Yes it is, thanks to inane design.

    You are not getting it, just as everybody here, because nobody cares to explain the real reason. This is a deep design problem in FF:

    – FF is currently NOT ABLE to download a resource on a server with non-compliant cert (for whatever compliance criteria, by default the criteria is that the cert must be signed by a known CA)

    – FF is currently NOT ABLE to NOT display the whole ‘secure’ interface (including the green bar idiocy (1)) for any PAGE whose every HTTP elements have been obtained over SSL links with compliant certs (except that the MAIN element (the element whose address is in the address bar) must be downloaded over a green SSL link for the green bar to appear, obviously)

    The problem FF 3 advocates don’t want you to know is that you must lower the bar (even for green sites) to be able to download ANY piece of information from a self-signed page.

    (1) it must be understood that the green thingy provides additional certified information NOT additional security; we may as well have a blue bar for sites allowed to collect VISA card numbers, a yellow bar for Mastercard, a blue-white-red bar for sites allowed to collect French social security numbers, etc.

  83. Didn’t really do much harm, most of the rants against it didn’t understand authentication, without which SSL security is a gentle emollient that hides the traffic but doesn’t guarantee the traffic is going to a person you trust. SSL/TLS is supposed to Authenticate AND Encrypt. It’s fairly easy to make the message go away. Establish trust with the users of your self-signed certificated site by creating your own Certification Authority Certificate, sign the server’s certificate and send them the CA certificate to be installed in their browser. They can then be sure the self-signed server certificate is associated with the website in question, only they’ll have to take your CA word for it.

Leave a Reply

Comments are moderated and not published in real time. All comments that are not related to the post will be removed.