What is the difference between http and https with a self-signed SSL certificate?

Question

A colleague of mine has told me he doesn't see why there is a warning when visiting a HTTPS website with a self-signed certificate saying that the security may be compromised, but there is no warning when visiting a "regular" HTTP website, although the security could also be compromised.

I have failed to think of an argument against that (I understand the difference between self-signed certificates and CA-issued).

So, what is the security risk that one has when visiting a HTTPS website with a self-signed or expired certificate, that you don't have when visiting a HTTP website ?

I would like to add what is the reasoning behind the browser warning message for self-signed certificates but there is none for HTTP, but I can think of several already, "not bothering the users of 90% of the web" being one.

Note

I am aware of a very similar question, but it doesn't answer my particular question.

Update

Google realized this paradox, and they will soon mark all HTTP-not-S connections as non-secure : https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

Answer 1

The purpose of the warning is that by using HTTPS, there is an expectation of proper security, but a self-signed or expired certificate has vulnerabilities that the user needs to be aware of.

The "risk" is that one thinks they are properly secured, but they are not fully secured, as opposed to HTTP, where one knows there is no encryption at all.

There would not be a warning for HTTP, because there is no security (i.e. encryption) to compromise.

Answer 2

Security difference

First, let's talk about SSL (now called TLS by the way), which adds the 'S' at the end of HTTPS and is in charge of "securing the communication". The clue to answer this question is indeed to fully understand what we mean by "securing the communication".

SSL, no matter if it is a self-signed certificate which is being used or one signed by a trusted CA, will ensure that the communication between you and the remote host remains confidential and that no one could tamper with any data exchanged.

The warning is therefore not about that.

However, how can you be sure that this remote host answering to your requests is really who you expect it to be? With public websites, for which you have no direct way to authenticate the certificate just by yourself, it is just impossible. Here comes external trusted CA: by trusting a CA you assume that all certificates signed by him are used only for legit purposes to secure the traffic with the server(s) explicitly mentioned in the certificate.

This is all this warning is about: your browser warns you that, while the communication itself is secured, it has no automated way to authenticate the certificate by itself and therefore relies upon you to accept it or refuse it.

If the self-signed certificate is associated to one of your servers, you should be able to proceed with this manual authentication: you should be able to check the certificate fingerprint, or at least you should know if the certificate has been changed recently or not.

Once this manual authentication has been done, your browser offers you the possibility to "remember" this certificate: this means that the browser will associate this self-signed certificate to the URL host and provide no warning in the future since, now, the browser has an automated way to authenticate the certificate.

However, as soon as the self-signed certificate will be changed on the server, the browser will display the warning again, and it will again be up to the end-user to determine wether this certificate change is normal and if the new certificate presented by the server is indeed a genuine one.

UX difference

My answer did not covered the browser's user interface aspect of your question until now.

I found the default way browser's inform the user's about current security to be mostly ineffective. User's just do not care about the padlock, and do not notice when the SSL security is missing. Even users who care haven't access to the right information (nothing prevents a website showing an Extended Validation Certificate to configure their website to use poor and weak cryptography systems or to rely on less secured third-party content: default browser's interface will still be happy about that and show the "top-notch security" green bar).

Hopefully, depending on the browser used there might be some plugins trying to remedy this situation. On Firefox, you have SSLeuth which will by default add a new notification area to the left or the URL bar (next to the padlock when there is one)

This new notification area has the following properties:

• The background color ranges from red (no security: HTTP), through orange (poor security setup) to blue and green (good and best security according to current best-practices).
• An option allows to extend this color to the whole URL bar, so HTTP websites will now display a fully red URL bar,
• At last a score (between 0 and 10) is displayed to show an estimation of the current SSL/TLS security level. It takes into account several criterion, amongst them the type of certificate (self-signed, CA signed, Extended Validation Certificate), the cryptographic configuration used, third-party content security, etc. Clicking on the notification area provides all score details, mostly useful when the result is not the expected one (aka "Why is my bank website granted an orange URL bar?").

Answer 3

Without warnings for things like self-signed or expired certs, inappropriate cipher suite selections, and other bad HTTPS configurations, the presentation of a website's state of security to the user becomes binary - either you have HTTPS on the site, or you don't. This would hide a number of nuances which can significantly affect exactly how much the "S" in "HTTPS" really is protecting you.

In a proper HTTPS implementation, the site's certificate is signed by a third-party that the client system trusts. This establishes assurance to the client that the content is being delivered from the system that they expect, and there's nobody in between.

The problem with a self-signed certificate is that anyone can make one. So, that certificate could just as well be generated from a system acting as Man-in-the-Middle who is intercepting and possibly even manipulating the data going back and forth between you and the trusted system. If the trusted system normally uses a self-signed certificate, and you haven't personally validated that certificate out-of-band or during a previous known-trustworthy connection, you'll never know the difference.

How is this different from regular HTTP? On its face, it may seem that it's not - in either scenario, a MitM can fairly easily view and tamper with the connection and you'd be oblivious. However, using HTTPS with a self-signed certificate offers you something HTTP cannot: The assurance that your data is still being encrypted in transmission, despite whomever may be in between. Depending on the environment (e.g.: densely populated public Wi-Fi), this could drastically reduce the audience who has access to your data, even while there may actually be a MitM in play.

You may want to check out my answer on another related question for more coverage on this. Troy Hunt's article, "SSL is not about encryption" may be of interest to you, though perhaps not very helpful for your side of the debate here.

Answer 4

These answers are great. But I often have to give a simplified answer without all the jargon.

HTTP - It is not encrypted and the data sent over the line could be easily read.

HTTPS - It is encrypted and verified by a trusted party the data is being handled by the correct source.

HTTPS (Self Signed) - It is encrypted but there is no verification by a trusted party that it is handled by the correct source.

That is why self-signed certificates get the very important notice. Even though it doesn't mean the certificate is unsafe the browser cannot confirm that the certificate is safe in it's usage/transmission of your data. Without this important notice a scammer/hacker could replace the certificate with one of their own and you would be none the wiser.

Answer 5

Visiting a https url carries with it an expectation of security. Visiting a http url does not. This applies not just when manually typing urls but perhaps more importantly when following links and submitting forms.

One soloution to this would be to add another url scheme for "encrypted but not authenticated" but even if all browsers started supporting that tomorrow it would take a long time before it was widespread enough for websites to rely on it. It would also potentially be difficult to explain the security differences to users.

Another soloution would be to do opertunistic encyrption under the http url scheme. Again though getting support into browsers would be an uphill struggle.