If I view a site that has a unsigned or self-signed SSL cert, my browser gives me a warning. Yet the same browser has no problem allowing credentials to be sent across unsecured pages.
Why is the self-signed cert treated worse than having no 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:
Many good reasons have been listed. Here's one more:
Think about cases where one secure web page embeds elements from another. An attacker could detect which requests are for the outer web page (say by looking at the timing, it has to come first) and which are for the inner elements. He could inject himself as a MITM in just the inner elements, use a self-signed certificate, and control parts of the page. Unless a warning was presented for the inner elements using SSL but not using a trusted certificate, the security of the outer page would be compromised.
Here's a realistic example. Say I'm a vendor, and I have a 'pay with PayPal' link. You click on that, and I know. I redirect you to PayPal, and let you get the legitimate, secure PayPal page. If I'm watching your network, I know that will be your first request from PayPal, and soon after that you'll submit your password. So I MITM the
You see how the security of the outer page is compromised by not warning if the certificate of the inner page is self-signed? So it must warn on self-signed certificates that come from links.
And, of course, if you enter
I can't comment, so I'll post this information that complements the correct information of user40350.
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:
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.
Connections that are secured by the https:// protocol are indicated by the browser to be "secured". For example, a little Padlock is shown or parts of the URL are marked in green.
The user therefore is supposed to trust that the pages he is visiting are indeed from the URL he had entered and are not from someone else.
If he is using no https://, the user is supposed to know, that the data entered is not protected and the site he is surfing at might be imposted.
A self signed certificate does not make sure - againts expectation, that the page surfed to is not imposted, therefore it gives no extra security.
A distinction must be made between a trusted (signed by an authority you trust) and untrusted certificate. Otherwise someone could impersonate your bank (for example) by using a self-signed certificate with relative impunity.
An in-your-face warning is preferable to a subtle one in this case because the potential risk is relatively high. People might click on an https link and not even think that someone could be sitting in the middle monitoring the connection. If the indication that the certificate is untrusted is subtle (say a red instead of green icon, etc), then people could be easily fooled, removing the benefits of SSL.
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.