5

Let's keep it short:

  1. On HTTP everyone can listen easily. MITM attacks are no problem.
  2. On HTTPS (self-signed) everything is at least encrypted, it's much harder to MITM-attack and only private key owners can listen.
  3. On HTTPS (non-self-signed -> "trusted by Browser vendor") it's like 2, but the illusion is created that this is far more secure than self-signed, but in the end we have to trust the Browser Vendor to not make mistakes (or being bribed)

For me option 1 is far less secure than 2, still Browsers complain about HTTP not at all, but about self-signed certificates extremly hard: several clicks are needed to establish the connection, otherise they fully block the connection with scary messages. Why is this?

Of course, I know the reason behind certificates: To make sure that the one you are talking to is the one you actually want to talk to. But on HTTP you don't have encryption and you don't have trust. On HTTPS (self-signed) you have at least encryption.

So, shouldn't it be really like the following?

  1. HTTP triggers the "big fat red error"
  2. HTTPS + self-signed has a warning icon but works regularly
  3. HTTPS + "trusted cert" issues no warning at all

What are the reason here?

Foo Bar
  • 193
  • 8
  • 1
    I do not find a good answer in the "duplicate". – Foo Bar Dec 04 '15 at 17:11
  • 1
    FWIW: Most browsers have (or at least used to have) some warnings before allowing you to submit data through a form on an HTTP page. – Iszi Dec 04 '15 at 17:31
  • @FooBar: the answer you've accepted is mostly what was already said in the answers to the older question I've referred to, even though you did not find a good answer there. – Steffen Ullrich Dec 04 '15 at 17:37

1 Answers1

7

They warn you because a self signed certificate could be a sign of a MITM attack where an attacker is attempting to get you to send them important credentials under the guise of a secure connection.

The major reason a browser wont warn about plain HTTP is because its far too common on the internet and would just be annoying for most users. One thing browsers do warn about however is if there are elements of a page being delivered over HTTP in an HTTPS page (ex. when a page loads elements from a different page and embeds them onto the page).

The reason browsers throw these scary messages for self signed certs is because they don't want inexperienced users adding random certs to their trusted list. Again, someone could MITM a connection, send their cert to you and pretend to be the site you are attempting to visit. Yes this can be done over HTTP too but many sites deliver at least a logon page over HTTPS so it is beneficial to users if browsers check since they could prevent your credentials from being compromised.

And on top of that, if people make self signed certs they could be working under a false sense of security. SSL isnt the most simple idea and even very large companies struggle with it, just look at how Dell messed up with their cert. The idea is to discourage the use of self signed certs, so that users can have the benefit of having a third party verify the legitimacy of a certificate.

The matter of CAs being irresponsible with their power however is another matter and can cause issues if they make bonehead decisions.

pureooze
  • 324
  • 1
  • 6
  • Thanks, this makes sense, especially the point about the HTTP-sites with HTTPS-logins (which wouldn't make sense if people trust everyone anyways). – Foo Bar Dec 04 '15 at 17:25
  • 3
    "False sense of security" is exactly right, at least in terms of the theoretical reason. The argument presumes that a typical user knows that http is unsecure, but is unaware of the importance of the distinction between a self-signed vs. CA-signed cert., thus putting the same amount of trust in both. But the more practical reason is the larger reason that http doesn't draw a warning: it was deemed acceptable a long time ago, became widely used, and keeps tenaciously hanging on despite everybody now knowing it's hazardous. Sort of like smoking cigarettes or drinking malt liquor. :) – mostlyinformed Dec 04 '15 at 20:28
  • Data retrieved via http:// can be cached by proxy layers in ways that data retrieved via https:// cannot. It would be helpful if there were a standard for retrieving data that could be publicly visible and cacheable but still had to be authenticated, but I don't know of any efforts in that direction. – supercat Jan 10 '17 at 19:32
  • Actually, IE has always warned about sending any form data over HTTP. It's just that the dialog is promptly dismissed with "Don't show this again", and everybody forgets about it :) You can find the setting in the security tab under "Submit non-encrypted form data" (configurable per-zone, of course). – Luaan Jan 12 '17 at 12:21