19

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

  • 9
    Note that the Chrome Security Team apparently agrees that this is a bit silly, and is working to gradually change Chrome's UX over time to more clearly indicate that HTTP is unsecure: chromium.org/Home/chromium-security/marking-http-as-non-secure – Ajedi32 Aug 28 '15 at 18:44
  • You might revisit your assumption that there is no warning for unencrypted HTTP. google.com/… Probably you just unchecked the "alert me next time" checkbox and forgot you had done so. – Ben Voigt Aug 28 '15 at 19:45
  • Ajedi32 : Great news ! @BenVoigt : yes and no. A message box that you can discard forever is very different than a warning page that you have difficulty bypassing, sometimes even as an "advanced" user. – thomasb Aug 28 '15 at 20:23
  • See also security.stackexchange.com/q/97247/971. – D.W. Aug 30 '15 at 4:31
34

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.

  • 3
    Something to keep in mind is that a self-signed certificate can be as secure as an externally-signed one; it simply has no trust chain extending to a common trusted root (like Verisign). If you trust the issuer of that certificate implicitly, you must take the additional step of installing the certificate in your CA store, telling your computer to trust it until you say otherwise. PKIs for corporate networks, in which a self-signed "golden key" is used as a trusted root to sign additional keys for company IT assets, are set up this way all the time. – KeithS Aug 28 '15 at 19:05
  • 5
    "where one knows there is no encryption at all" : I disagree, regarding the general public. Plus, it seems "it might not be secure" is treated as less secure than "it is never secure". – thomasb Aug 28 '15 at 20:27
  • @KeithS: Which as far as I understand is not any different from a generally accepted certificate authority. Those just come pre-installed with your OS. – Matti Virkkunen Aug 29 '15 at 12:18
  • 2
    @cosmo0: Non-encrypted HTTP is 100% totally always secure if you assume there are no eavesdroppers. – Matti Virkkunen Aug 29 '15 at 12:18
  • 1
    @cosmo0: Every system can be considered 100% secure as long as you assume nobody will attack or misuse them... – WhiteWinterWolf Aug 30 '15 at 7:04
25

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?").
  • If you can't authenticate the remote party, you don't know that the communication is confidential or tamper-proof, because you have no way of proving that there isn't a man-in-the-middle eavesdropping or tampering. – hobbs Aug 30 '15 at 5:42
  • @hobbs: That's precisely the issue. SSL/TLS ensures that your communication is confidential and tamperproof between you and the remote host. However if you don't know who this remote host is, it may indeed be a malicious system instead of the expected server and it would be free to do anything he would-like with the transmitted data. – WhiteWinterWolf Aug 30 '15 at 7:03
  • Can't the browser just ensure it is communicating only with the server on the cert? I mean in this case authenticating the remote host is more like saying that the cert issued under this domain in Facebook's name is actually a cert of Facebook and not someone else, as such ensuring that you are connecting to Facebook officially. You are still connected directly to the server that issued the cert without a snooper (actually not true, NSA got around it) but you cannot state that the cert is valid due to not being authorised by a third party – Sammaye Aug 30 '15 at 13:53
  • @Sammaye: The browser sends his request to the over-crowded Internet, and among the billions of servers out-there one of them answers "Hi, I am the Facebook server". How can you be sure that this server coming out of nowhere is really the Facebook server and not one maliciously acting like it? That's where third-party authentication comes into the place: the only way is to have someone already known and trusted both by your browser and by the genuine Facebook server which will testify to the browser that the server currently answering it is the real Facebook server. – WhiteWinterWolf Aug 30 '15 at 17:09
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.

  • It doesn't really answer my question but it's very interesting! Thanks. – thomasb Aug 28 '15 at 20:37
1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.