Pingdom Home

US + international: +1-212-796-6890

SE + international: +46-21-480-0920

Business hours 3 am-11:30 am EST (Mon-Fri).

Do you know if your website is up right now? We do! LEARN MORE

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.



98 comments
boratebomber
boratebomber

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.

boratebomber
boratebomber

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.

Corrector
Corrector

"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.

Corrector
Corrector

"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.

WhyCerts
WhyCerts

The way Firefox handles certificates is awful because it breaks usability of legitimate HTTPS services. The simplest solution is also the best: notify the user about the problem, and then allow the user to proceed anyways at their option. A visual warning indicator can remain on the page. As long as this happens, firefox has done it's job. Anything more is getting in the way of the user's intentions without providing any benefit to anyone. Make a recommendation, but let the user drive. An invalid cert is no less secure than vanilla HTTP, why all the ruckus? Frankly, your nuts if you think a few days of expiration makes the cert any less secure than a few days earlier. The bank will renew the cert, but in the mean time there is no reason to prevent users from accessing the site using the old cert (so long as a clear notification is in place). I hope all of you guys defending the FF SSL roadblock always say "NO" when asked about new SSH keys, otherwise you are total hypocrites. As a FF user I hate to say this, but developers made a very poor judgment call with this design. I've developed a new habit of using IE again to access my routers because FF is so annoying. Focus on usability.

SuzieQ
SuzieQ

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.

Gargaj
Gargaj

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?

Janardhan
Janardhan

******************************************** 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. ***********************************************

cyclemad
cyclemad

This is not just a problem with Self-Sighned. We have both Thawte and godaddy certs and both have issue with the new firefox

Cathy
Cathy

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.

Gilzow
Gilzow

#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.

Fabien
Fabien

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.

Jd
Jd

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.

CableCat
CableCat

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.

Fangorn81
Fangorn81

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) WACHOVIA.COM PAYPAL.COM TWITTER.COM/LOGIN 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!!

Vasuki Ashok
Vasuki Ashok

Does it mean, if I'm able to access the same URL using Explorer my machine is not secure?

system
system

@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.

Sadleric
Sadleric

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.

MrD
MrD

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.

I for one welcome our new security theatre overlor
I for one welcome our new security theatre overlor

I for one welcome our new security theatre overlords. Dear Mozilla Devs, Thanks for the heavy-handed, misguided and conceited approach to browser security. Thanks for ignoring all the comments regarding the completely insecure nature of http. Thankyou also for ignoring the valid comments regarding authentication v. encryption. All us admins who need to run hundreds or thousands of https virtual hosts thanks you also. Security Theatre Genius Certificates to all of you

I for one welcome our new security theatre overlor
I for one welcome our new security theatre overlor

I for one welcome our new security theatre overlords. Dear Mozilla Devs, Thanks for the heavy-handed, misguided and conceited approach to browser security. Thanks for ignoring all the comments regarding the completely insecure nature of http. Thankyou also for ignoring the valid comments regarding authentication v. encryption. All us admins who need to run hundreds or thousands of https virtual hosts thanks you also. Security Theatre Genius Certificates to all of you

Simon Levesque
Simon Levesque

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.

Fabien
Fabien

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".

Andrey P.
Andrey P.

Guys, tell me what to do when I'd like to connect from Mozilla Browser to localhost (e.g., https://localhost:5678? Who can give me trusted certificate?

Indrek
Indrek

@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.

system
system

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).

ep
ep

update your certificates and update your site.

sam
sam

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.

Jim McDish
Jim McDish

I am shocked Firefox is letting this go on. I have always thought very Highly of FireFox until this report! RD www.decrypt.net.tc

Todd
Todd

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. :)

dan wendlandt
dan wendlandt

Readers might be interested in a new firefox extension called Perspectives that we developed at Carnegie Mellon. Perspectives uses network probing to determine when a self-signed certificate is legitimate and automatically overrides the security error page. Check it out: http://www.cs.cmu.edu./~perspectives We welcome feedback. Thanks!

orlando_ombzzz
orlando_ombzzz

extracted from http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf: ——– 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! ——–

system
system

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 a.com and b.com are hosted on the same IP, b.com 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 dodgit.com 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.

Chuck
Chuck

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.

Lucas Adamski
Lucas Adamski

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.

chort
chort

@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.

Indrek
Indrek

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 :P

Zephrant
Zephrant

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.

Lucas Adamski
Lucas Adamski

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.

Zephrant
Zephrant

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....

Lucas Adamski
Lucas Adamski

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.

KIved
KIved

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 www.us.army.mil, 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...

Gilzow
Gilzow

@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.

chort
chort

@Zephrant IE7 gives the same type of warning; what's your point?

chort
chort

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.

huh
huh

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.

MarketObserver
MarketObserver

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."

mesmer
mesmer

- 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.

Zephrant
Zephrant

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.

mh
mh

@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.