Why is an unsigned SSL cert treated worse than no SSL cert?
There are plenty of people that feel that this system is broken.
Here's the logic behind why your browser will give you such an alarming warning when an SSL cert is invalid:
One of the original design purposes of the SSL infrastructure was to provide authentication of web servers. Basically, if you go to www.bank.com, SSL allows the webserver that responds to prove that it does, in fact, belong to your bank. This stops an imposter from manipulating DNS or using another method to have a malicious server respond.
The "Trust" in SSL is provided by having a trusted third party (companies like VeriSign and Thawte Consulting) sign the certificate, indicating that they have verified that it is owned by who it says it is (in theory by visiting the IT administrator in person or another method that creates direct trust, although evidence shows that they're actually rather lax about it - all it takes to get a signed SSL cert is often an 800 number and a bit of acting skill).
So, if you connect to a web server that provides an SSL certificate, but it is not signed by a trusted third party, in theory this could mean that you are communicating with an imposter that is pretending to be a server belonging to a different organization.
In practice, a self-signed certificate generally just means that the organization that runs the server chose not to pay for a signed certificate (they can be quite expensive, depending on the features you want), or lacked the technical expertise to configure one (some small-business solutions offer a one-click mechanism for a self-signed cert, but getting a trusted cert requires more technical steps).
I personally believe that this system is broken, and that communicating with a server offering no encryption is much more dangerous than communicating with a server offering SSL with a self-signed certificate. there are three reasons browsers don't act like this is the case:
- Unencrypted communications are the norm on the internet, so if browsers made you click through a warning to view websites not offering encryption, you'd quickly get annoyed and disable the warning.
- Because of the dire warnings to clients, it's abnormal to see a self-signed cert on a production website. This establishes a self-perpetuating system: self-signed certs are suspicious because they're rare, they're rare because they're suspicious.
- This is cynical sounding of me, but there are companies that stand to make a great deal of money off of signing SSL certificates (cough Verisign cough), so they use whitepapers (an IT term meaning "long and boring advertisement") and other publications to enforce the idea that unsigned certificates are dangerous.
Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST.If any post to unsecure page would trigger warning, users would be bombarded by pointless warnings.
Using secure channel indicates programmer intention to secure the transfer. In this case, using self-signed certificate warning is very right thing to do.
I can't comment, so I'll post this information that complements the correct information of user40350.
Yet the same browser has no problem allowing credentials to be sent across unsecured pages.
That is actually not even true. Most browsers will show a warning like you're about to submit data over an unsecured connection when you first try that, but you can turn it off so it never shows again, and I bet that is exactly what you have done...
Miro A wrote:
Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST
This is also incorrect, as password fields are special html tags for example. On top of that the labels like "username" and "password" also betray a lot of their sensitiviy. It would be perfectly feasible for browsers to take this kind of information into consideration.