8 ms·

Mozilla SSL policy bad for the Web

49 points by nickb 18y ago

cstejerean 18y ago
"Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents." I wouldn't be so sure about that.
- rcoder 18y ago
  > I wouldn't be so sure about that. Umm, I would. Running Wireshark or tcpdump to sniff traffic over the wire is easy, and analysis can be done offline at the attacker's leisure. Hijacking DNS and phsishing for users' login credentials to other sites requires a lot more preparation, and in most cases, prior selection of the desired target sites.
  - cstejerean 18y ago
    In most cases where you can run Wireshark to sniff someone's traffic you're probably just steps away from performing a man in the middle attack.
  - tptacek 18y ago
    (1) An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. Without SSL in the way, she now owns several thousand bank account logins and Yahoo Mail passwords. (2) An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. With SSL in the way, she now owns several bank account logins and Yahoo Mail passwords.
axod 18y ago
SSL certificates for HTTPS are a big fat scam. Why do I need to pay money to get a certificate, just to provide encryption. Encryption should be separate from identity verification. Of course identity verification should be properly vetted and you should have to pay a fee, and have documents checked etc. If however, you just want to provide security for your users by encrypting http, you should not have to jump through hoops and spend money.
- olavk 18y ago
  But what good is encrypted communication if you cant be sure who you are communication with?
  - y0ghur7_xxx 18y ago
    It is good because that way you know that nobody in between can see your traffic. And more often than not it is enough to know that you are talking to the same site you talked to the last time (just like with SSH). The idea of "no lock icon" in case of a self signed/unknown CA certificate is a really good idea IMHO. The traffic is encrypted, but it does not give the user a false sense of security.
    - sigstoat 18y ago
      If you don't know who you're talking to, then there is no point in encrypting the data, because you're probably talking to the attacker. ("Man In The Middle") Now, the idea of "I'm talking to the same person I talked to last time" is useful, but if the users are all conditioned to accept random certificates without understanding, then when they go back a second time (and the attacker is waiting), they'll agree to the new cert, just like they did the first time.
      - trevelyan 18y ago
        If you've ever run an e-commerce site, you'll know that payments drop off significantly when browsers start throwing up warning signs.
        tptacek 18y ago
        Which is good, because without that dropoff, your customers security would be an externality to you.
      - y0ghur7_xxx 18y ago
        If you create an account on happykittens.com, you don't really care if the cert happykittens.com is sending you is signed by a trusted CA. What you care about is that the second time you visit the site, when you log in with your brand new account, that the cert the site sends you is the same you received when you created the account (the site is the same you created the account on). This has nothing to do with the fact that the cert is signed from a trusted CA or not, and thus, making it difficult for the user to accept a SS cert is not the right solution IMHO.
pdubroy 18y ago
Johnathan Nightingale of Mozilla has a good blog post explaining the rationale behind this: http://blog.johnath.com/2008/08/05/ssl-question-corner/ http://blog.johnath.com/2008/08/05/ssl-question-corner/ An especially pertinent point from his post: "Several CAs accepted by all major browsers sell certificates for less than $20/yr, and StartSSL, in the Firefox 3 root store, offers them for free."
- halo 18y ago
  Doesn't change the fact that it pops up a scary unintelligible message and makes you jump through hoops whenever someone tries to visit a site with a self-signed certificate. It's very much a "break the web" situation. As suggested by the original article, the correct behaviour would be to treat it as though there's no security whatsoever. After all, logically, how is being encrypted but unauthenticated worse than being unencrypted and unauthenticated?
  - tptacek 18y ago
    How can your browser tell the difference between: (1) A connection to onlinebanking.bankofamerica.com in which an attacker has hijacked the SSL handshake and subbed in a self-signed certificate, and (2) A connection to https://login.ratemykitten.com https://login.ratemykitten.com? You appear to be arguing that the warning for this situation should be tuned to (2).
- ajross 18y ago
  That's not the bug though. The bug is that the error message a user sees when visiting a self-signed site using HTTPS is much more scary than simply visiting that site on an unencrypted connection, even though by all reasonable standards this is a safer, more private, and more secure action. If we're not going to warn folks about unencrypted links where every proxy in the way is a man-in-the-middle attack waiting to happen, why are we going through such contortions to warn them about the same attacks in a situation where they are much harder to accomplish? I've never understood this warning at all.
  - 18y ago
sh1mmer 18y ago
Also, you can see the "add an exception" in the screen shot. You can manually add an SSL certificate to a white list, it's just a little bit harder, with a few more steps, than the previous YES|NO dialogue. I think this a good thing. 99% of user probably don't need to or shouldn't interact with pages with self-signed certificates. That's a good thing. Self-signed certs should really only be on development pages. I'm sure this is a good anti-phishing measure.
- aristus 18y ago
  In this case I disagree. The web is not all corporate, and there is a confusion between encryption and authentication. A certificate, signed or no, is a means to establish a secure connection between Alice & Bob. This ensures no one is snooping or modifying the data passing between them. this is a good thing that should be encouraged in an age when your ISP injects ads and the government keeps tabs on what sites you visit. A signed certificate is a means of authenticating the identity of the presenter of that certificate, to give some reassurance and trust about the other party. These two things can and should be kept separate. What Mozilla is doing is making it much more difficult to have a secure-by-default Web. Imagine if your mail program suddenly stopped receiving email unless each sender either paid 100 bucks per year to VeriSign, or faxed a copy of their passport to Microsoft, or you went through a scary, four-step process to "enable" them.
  - tptacek 18y ago
    A self-signed certificate does not establish a secure connection between Alice and Bob, because Alice can't verify the certificate. Bob can send his certificate, Mallory can trivially intercept it and replace it with her own, and nobody will be the wiser. Let's not encourage people to adopt security mechanisms that provide no real security. Let's make the security mechanisms we have today, which are strong enough to stop many governments and all of the largest corporations, cost-effective and easier to deploy. Let's solve the right problems, instead of trying to make ourselves feel better by sugarcoating browser warning messages.
    - aristus 18y ago
grhino 18y ago
What's encryption without authentication? Encryption ensures that only the entity you are sending the message to can read it. If you can't be sure of the entity you are sending the message to, then what's the point of encrypting it in the first place? Why does the article pick out Mozilla in particular? Are they suggesting that FireFox makes it overly complex to ignore the warning and continue on?
- wmf 18y ago
  Firefox 2 behaved similar to other browsers, giving one warning dialog for self-signed certs. People are complaining because Firefox 3 changed that to an annoying 4-step process.
- aristus 18y ago
  Encryption without authentication is just that: encryption. The point of encryption is to make sure no one else is listening OR modifying the data in transit. Like, say, your cash-starved ISP, or the government.
  - grhino 18y ago
    Without authentication, it could be your cash-starved ISP, or the government, which is generating a self-signed certificate.
  - tlrobinson 18y ago
    No, it's not. If a man-in-the-middle attack is possible (certainly the ISP could), then encryption without authentication is as insecure as no encryption at all. And in fact worse if the user has a false sense of security. The MITM pretends to be the bank's server (or whatever) when talking to you, and pretends to be you when talking to the bank's server. Both channels can be encrypted, but the attacker still sees (and can modify) everything that you think you're sending directly to the bank's server. This is the key point that most people seem to be missing here. If browsers didn't warn about self-signed certificate, the entire system would break down because an attacker could just use a self-signed cert in a MITM attack, and the user would have no idea.
- 18y ago
mattmcknight 18y ago
Amusingly, this policy blocks several US Dept of Defense public facing websites.
jncraton 18y ago
I'm not entirely sure why Firefox is being specifically targeted here. The pages that Opera and IE8 throw for self-signed certs aren't much less scary.
- jodrellblank 18y ago
  IE8 isn't out properly yet. Maybe with enough fuss, it can be changed before it is.
marketer 18y ago
Having a trusted third party is a pretty big deal in cryptography. Without it, many of the core assumptions of public-key cryptography are invalid. It's a huge part of making sure the other end is authentic. I'd place a lot more trust in Bank A's public key if it was signed by verisign, rather than an unverified third party. Having verisign's public key in my browser elimininates a large class of man-in-the-middle attacks. If paying $20/year is too inconvenient for you to transfer your data securely, then perhaps the data isn't sensitive enough, and you shouldn't bother.
- tptacek 18y ago
  It's not even that complicated. The problem with not having a valid certificate is this: if both sides can't tie every packet in the SSL handshake back to Verisign or Thawte's pubkey, attackers can inject their own handshake passwords and set the session key.
tptacek 18y ago
Unbelievable. I've been poking about here for like 6 months now. You are all very smart people. Why is this so hard to understand? If you do not have a valid certificate signed by a CA, SSL is not providing any security. Yes, the warning you get when you visit a site with an invalid cert is much scarier than what you see if you visit an unencrypted site. But it's the sites that use encryption that users care about, because those are the sites that get their passwords and credit card numbers. Perhaps you think the browser should make an exception for self-signed certs. After all, there's nothing "wrong" with their signatures. Nothing's expired. No signature fails to validate. Why not just make the URL bar orange or something? Because anyone can create a self-signed cert and sub it into a Bank of America SSL connection. It sure is annoying that you have to pay $20 every year to keep an SSL cert. I totally agree that this a problem. But right now, without that $20, you have a connection that provides cryptographically zero security. Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem.
- nickf 18y ago
  "Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem." Good point. You won't find it - performing proper background checks cost more than that. That's not to say you can't get cheap certificates - they're the domain-only validated ones where you only have to prove ownership of the domain. These are bad because they appear the same as properly-validated certs when they shouldn't. Kaminsky's recent work shows the DNS system can't always be trusted, and so certificates validated on that weak system cannot be trusted either. However, until GoDaddy and Geotrust stop having lots to lose from DV certs being marked-down by browsers, I doubt they'll let MS, Opera, Mozilla and the rest do such a thing.
- fendale 18y ago
  I don't fully agree with what you are saying. A self signed certificate DOES provide 100% cryptographic security, in that nobody sniffing on the the wire, or whatever open wi-fi I happen to be using can see my data. Securing the connection from 'spies' is only one part of an general SSL certificates function - the other is proving the identity of the site you are connecting to. A self signed cert provides zero use here. So a self signed cert has some uses - that said, perhaps its the more techy person who would ever care about encrypted connections but not identity, and they can probably work out how to get FF to accept their cert anyway.
msg 18y ago
Here's an interesting solution. CMU just put out a tool called Perspectives that runs public notary servers. The servers probe sites periodically to get a history of keys. This can go a long way toward determining whether there is a man-in-the-middle sending you a fake SSL certificate (because it will not match the history). http://www.cs.cmu.edu/~perspectives/ http://www.cs.cmu.edu/~perspectives/ (hat-tip Lauren Weinstein) http://lauren.vortex.com/archive/000414.html http://lauren.vortex.com/archive/000414.html
plusbryan 18y ago
One possible solution: use two icons Since SSL covers two cases of security, both encryption and identity, maybe it's time to invent a new icon - i.e. this web site is secure (a lock) but its identity could not be verified (an id card). Self-signed certs wouldn't show warnings, but wouldn't show the ID-verified icon. CA certs would show both. If they're worried about user education, the first time firefox encounters a self-signed site, it could provide a permanently dismissible dialog.
- tptacek 18y ago
  You can't have one without the other. The first icon doesn't mean anything. You might as well add a third icon for "this connection is compressed". Attackers can't read your credit card number out of a compressed stream either.
stcredzero 18y ago
I once bought a broadband router that was marked down ridiculously cheap. It had all the features I wanted, and it was half the price of any of the others. When I got it home, everything was running slowly. After poking around, I discovered that my machines' DNS servers had changed from Time Warner Cable's to IP addresses in China! If self signed certificates were indistinguishable, I may have been making connections through man in the middle machine located there without any way of knowing.
invisible 18y ago
In my opinion, self-signed SSL certificates shouldn't cause this. If I want to use an SSL connection for my users to sign in with, I shouldn't have to pay tons of money for a wildcard certificate for my domain (they charge a large amount more just to add *. to your certificate). SSL is to SECURE THE TRANSMISSION, but these companies have turned it into a certificate war, where you must have one signed by a "distinguished" CA or the browser will tell you that you're visiting a "bad" site (Mozilla has a stopping guard, IE has attention images). So don't even show the user that it's SSL. I don't care if my site seems more secure to the end-user, it just should be SECURE without regard to the mindset of the individual operating on it. Heck, even hide the https! Banks and online stores, sure, they should buy SSL certificates so they ease the end-user's mind. That is a relevant operating cost to incur for those individuals.

49 points by nickb 18y ago

"Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents." I wouldn't be so sure about that.

rcoder 18y ago
> I wouldn't be so sure about that. Umm, I would. Running Wireshark or tcpdump to sniff traffic over the wire is easy, and analysis can be done offline at the attacker's leisure. Hijacking DNS and phsishing for users' login credentials to other sites requires a lot more preparation, and in most cases, prior selection of the desired target sites.
- cstejerean 18y ago
  In most cases where you can run Wireshark to sniff someone's traffic you're probably just steps away from performing a man in the middle attack.
- tptacek 18y ago
  (1) An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. Without SSL in the way, she now owns several thousand bank account logins and Yahoo Mail passwords. (2) An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. With SSL in the way, she now owns several bank account logins and Yahoo Mail passwords.

axod 18y ago

SSL certificates for HTTPS are a big fat scam. Why do I need to pay money to get a certificate, just to provide encryption. Encryption should be separate from identity verification. Of course identity verification should be properly vetted and you should have to pay a fee, and have documents checked etc. If however, you just want to provide security for your users by encrypting http, you should not have to jump through hoops and spend money.

olavk 18y ago
But what good is encrypted communication if you cant be sure who you are communication with?
- y0ghur7_xxx 18y ago
  It is good because that way you know that nobody in between can see your traffic. And more often than not it is enough to know that you are talking to the same site you talked to the last time (just like with SSH). The idea of "no lock icon" in case of a self signed/unknown CA certificate is a really good idea IMHO. The traffic is encrypted, but it does not give the user a false sense of security.
  - sigstoat 18y ago
    If you don't know who you're talking to, then there is no point in encrypting the data, because you're probably talking to the attacker. ("Man In The Middle") Now, the idea of "I'm talking to the same person I talked to last time" is useful, but if the users are all conditioned to accept random certificates without understanding, then when they go back a second time (and the attacker is waiting), they'll agree to the new cert, just like they did the first time.
    - trevelyan 18y ago
      If you've ever run an e-commerce site, you'll know that payments drop off significantly when browsers start throwing up warning signs.
      - tptacek 18y ago
        Which is good, because without that dropoff, your customers security would be an externality to you.
    - y0ghur7_xxx 18y ago
      If you create an account on happykittens.com, you don't really care if the cert happykittens.com is sending you is signed by a trusted CA. What you care about is that the second time you visit the site, when you log in with your brand new account, that the cert the site sends you is the same you received when you created the account (the site is the same you created the account on). This has nothing to do with the fact that the cert is signed from a trusted CA or not, and thus, making it difficult for the user to accept a SS cert is not the right solution IMHO.

pdubroy 18y ago

Johnathan Nightingale of Mozilla has a good blog post explaining the rationale behind this: http://blog.johnath.com/2008/08/05/ssl-question-corner/ http://blog.johnath.com/2008/08/05/ssl-question-corner/ An especially pertinent point from his post: "Several CAs accepted by all major browsers sell certificates for less than $20/yr, and StartSSL, in the Firefox 3 root store, offers them for free."

halo 18y ago
Doesn't change the fact that it pops up a scary unintelligible message and makes you jump through hoops whenever someone tries to visit a site with a self-signed certificate. It's very much a "break the web" situation. As suggested by the original article, the correct behaviour would be to treat it as though there's no security whatsoever. After all, logically, how is being encrypted but unauthenticated worse than being unencrypted and unauthenticated?
- tptacek 18y ago
  How can your browser tell the difference between: (1) A connection to onlinebanking.bankofamerica.com in which an attacker has hijacked the SSL handshake and subbed in a self-signed certificate, and (2) A connection to https://login.ratemykitten.com https://login.ratemykitten.com? You appear to be arguing that the warning for this situation should be tuned to (2).
ajross 18y ago
That's not the bug though. The bug is that the error message a user sees when visiting a self-signed site using HTTPS is much more scary than simply visiting that site on an unencrypted connection, even though by all reasonable standards this is a safer, more private, and more secure action. If we're not going to warn folks about unencrypted links where every proxy in the way is a man-in-the-middle attack waiting to happen, why are we going through such contortions to warn them about the same attacks in a situation where they are much harder to accomplish? I've never understood this warning at all.
- 18y ago

sh1mmer 18y ago

Also, you can see the "add an exception" in the screen shot. You can manually add an SSL certificate to a white list, it's just a little bit harder, with a few more steps, than the previous YES|NO dialogue. I think this a good thing. 99% of user probably don't need to or shouldn't interact with pages with self-signed certificates. That's a good thing. Self-signed certs should really only be on development pages. I'm sure this is a good anti-phishing measure.

aristus 18y ago
In this case I disagree. The web is not all corporate, and there is a confusion between encryption and authentication. A certificate, signed or no, is a means to establish a secure connection between Alice & Bob. This ensures no one is snooping or modifying the data passing between them. this is a good thing that should be encouraged in an age when your ISP injects ads and the government keeps tabs on what sites you visit. A signed certificate is a means of authenticating the identity of the presenter of that certificate, to give some reassurance and trust about the other party. These two things can and should be kept separate. What Mozilla is doing is making it much more difficult to have a secure-by-default Web. Imagine if your mail program suddenly stopped receiving email unless each sender either paid 100 bucks per year to VeriSign, or faxed a copy of their passport to Microsoft, or you went through a scary, four-step process to "enable" them.
- tptacek 18y ago
  A self-signed certificate does not establish a secure connection between Alice and Bob, because Alice can't verify the certificate. Bob can send his certificate, Mallory can trivially intercept it and replace it with her own, and nobody will be the wiser. Let's not encourage people to adopt security mechanisms that provide no real security. Let's make the security mechanisms we have today, which are strong enough to stop many governments and all of the largest corporations, cost-effective and easier to deploy. Let's solve the right problems, instead of trying to make ourselves feel better by sugarcoating browser warning messages.
  - aristus 18y ago

grhino 18y ago

What's encryption without authentication? Encryption ensures that only the entity you are sending the message to can read it. If you can't be sure of the entity you are sending the message to, then what's the point of encrypting it in the first place? Why does the article pick out Mozilla in particular? Are they suggesting that FireFox makes it overly complex to ignore the warning and continue on?

wmf 18y ago
Firefox 2 behaved similar to other browsers, giving one warning dialog for self-signed certs. People are complaining because Firefox 3 changed that to an annoying 4-step process.
aristus 18y ago
Encryption without authentication is just that: encryption. The point of encryption is to make sure no one else is listening OR modifying the data in transit. Like, say, your cash-starved ISP, or the government.
- grhino 18y ago
  Without authentication, it could be your cash-starved ISP, or the government, which is generating a self-signed certificate.
- tlrobinson 18y ago
  No, it's not. If a man-in-the-middle attack is possible (certainly the ISP could), then encryption without authentication is as insecure as no encryption at all. And in fact worse if the user has a false sense of security. The MITM pretends to be the bank's server (or whatever) when talking to you, and pretends to be you when talking to the bank's server. Both channels can be encrypted, but the attacker still sees (and can modify) everything that you think you're sending directly to the bank's server. This is the key point that most people seem to be missing here. If browsers didn't warn about self-signed certificate, the entire system would break down because an attacker could just use a self-signed cert in a MITM attack, and the user would have no idea.
18y ago

mattmcknight 18y ago

Amusingly, this policy blocks several US Dept of Defense public facing websites.

jncraton 18y ago

I'm not entirely sure why Firefox is being specifically targeted here. The pages that Opera and IE8 throw for self-signed certs aren't much less scary.

jodrellblank 18y ago
IE8 isn't out properly yet. Maybe with enough fuss, it can be changed before it is.

marketer 18y ago

Having a trusted third party is a pretty big deal in cryptography. Without it, many of the core assumptions of public-key cryptography are invalid. It's a huge part of making sure the other end is authentic. I'd place a lot more trust in Bank A's public key if it was signed by verisign, rather than an unverified third party. Having verisign's public key in my browser elimininates a large class of man-in-the-middle attacks. If paying $20/year is too inconvenient for you to transfer your data securely, then perhaps the data isn't sensitive enough, and you shouldn't bother.

tptacek 18y ago
It's not even that complicated. The problem with not having a valid certificate is this: if both sides can't tie every packet in the SSL handshake back to Verisign or Thawte's pubkey, attackers can inject their own handshake passwords and set the session key.

tptacek 18y ago

Unbelievable. I've been poking about here for like 6 months now. You are all very smart people. Why is this so hard to understand? If you do not have a valid certificate signed by a CA, SSL is not providing any security. Yes, the warning you get when you visit a site with an invalid cert is much scarier than what you see if you visit an unencrypted site. But it's the sites that use encryption that users care about, because those are the sites that get their passwords and credit card numbers. Perhaps you think the browser should make an exception for self-signed certs. After all, there's nothing "wrong" with their signatures. Nothing's expired. No signature fails to validate. Why not just make the URL bar orange or something? Because anyone can create a self-signed cert and sub it into a Bank of America SSL connection. It sure is annoying that you have to pay $20 every year to keep an SSL cert. I totally agree that this a problem. But right now, without that $20, you have a connection that provides cryptographically zero security. Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem.

nickf 18y ago
"Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem." Good point. You won't find it - performing proper background checks cost more than that. That's not to say you can't get cheap certificates - they're the domain-only validated ones where you only have to prove ownership of the domain. These are bad because they appear the same as properly-validated certs when they shouldn't. Kaminsky's recent work shows the DNS system can't always be trusted, and so certificates validated on that weak system cannot be trusted either. However, until GoDaddy and Geotrust stop having lots to lose from DV certs being marked-down by browsers, I doubt they'll let MS, Opera, Mozilla and the rest do such a thing.
fendale 18y ago
I don't fully agree with what you are saying. A self signed certificate DOES provide 100% cryptographic security, in that nobody sniffing on the the wire, or whatever open wi-fi I happen to be using can see my data. Securing the connection from 'spies' is only one part of an general SSL certificates function - the other is proving the identity of the site you are connecting to. A self signed cert provides zero use here. So a self signed cert has some uses - that said, perhaps its the more techy person who would ever care about encrypted connections but not identity, and they can probably work out how to get FF to accept their cert anyway.

msg 18y ago

Here's an interesting solution. CMU just put out a tool called Perspectives that runs public notary servers. The servers probe sites periodically to get a history of keys. This can go a long way toward determining whether there is a man-in-the-middle sending you a fake SSL certificate (because it will not match the history). http://www.cs.cmu.edu/~perspectives/ http://www.cs.cmu.edu/~perspectives/ (hat-tip Lauren Weinstein) http://lauren.vortex.com/archive/000414.html http://lauren.vortex.com/archive/000414.html

plusbryan 18y ago

One possible solution: use two icons Since SSL covers two cases of security, both encryption and identity, maybe it's time to invent a new icon - i.e. this web site is secure (a lock) but its identity could not be verified (an id card). Self-signed certs wouldn't show warnings, but wouldn't show the ID-verified icon. CA certs would show both. If they're worried about user education, the first time firefox encounters a self-signed site, it could provide a permanently dismissible dialog.

tptacek 18y ago
You can't have one without the other. The first icon doesn't mean anything. You might as well add a third icon for "this connection is compressed". Attackers can't read your credit card number out of a compressed stream either.

stcredzero 18y ago

I once bought a broadband router that was marked down ridiculously cheap. It had all the features I wanted, and it was half the price of any of the others. When I got it home, everything was running slowly. After poking around, I discovered that my machines' DNS servers had changed from Time Warner Cable's to IP addresses in China! If self signed certificates were indistinguishable, I may have been making connections through man in the middle machine located there without any way of knowing.

invisible 18y ago

In my opinion, self-signed SSL certificates shouldn't cause this. If I want to use an SSL connection for my users to sign in with, I shouldn't have to pay tons of money for a wildcard certificate for my domain (they charge a large amount more just to add *. to your certificate). SSL is to SECURE THE TRANSMISSION, but these companies have turned it into a certificate war, where you must have one signed by a "distinguished" CA or the browser will tell you that you're visiting a "bad" site (Mozilla has a stopping guard, IE has attention images). So don't even show the user that it's SSL. I don't care if my site seems more secure to the end-user, it just should be SECURE without regard to the mindset of the individual operating on it. Heck, even hide the https! Banks and online stores, sure, they should buy SSL certificates so they ease the end-user's mind. That is a relevant operating cost to incur for those individuals.