Why does Chrome hate self-signed certificates so much?

Question

I'm running a small web app on an EC2 instance and I want some friends to be able to use it. I also want to make it use HTTPS, just for basic security purposes (prevent packet snooping whenever possible). Of course I am using a self-signed certificate, because my budget for this project is $0. But Chrome throws up a warning page upon trying to visit it:

Your connection is not private

Attackers might be trying to steal your information from [...] (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

This server could not prove that it is [...]; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.

Is is not true that "any encryption is better than no encryption"? On unenecrypted HTTP, I could be trying to steal information as well, and don't have to prove anything about my server identity, AND my communication can be read in plaintext by packet sniffing, but Chrome doesn't throw up any warning flags there...

What gives? Why does Chrome hate self-signed certificates so much? Why doesn't it just put a little red box over the padlock icon, instead of giving me a two-click warning page?

Edit Sep 2021 (this was applicable since 2016): Just suck it up and use one of the free key issuers. Let's Encrypt and AWS ACM will literally do it for free.

Solution 1

This question is not specific to chrome. Firefox and probably other browsers behave similar and in the last years the warnings even got stricter. Complaining about these warnings shows more a missing understanding of the role of certificates in HTTPS.

With HTTPS one expects encryption, i.e. private communication between the browser and the server with nobody sniffing or manipulating the transferred data. At the beginning of the encryption client and server exchange the encryption keys, so that one can encrypt the data and the other can decrypt the data. If some man-in-the-middle manages to manipulate the key exchange in a way that it gets control over the encryption keys, then the connection will still be encrypted but not private. Thus it is essential that the key exchange is protected and this is done with certificates. Only with proper checking of the certificates the client can verify that it talks to the server and not some man-in-the-middle and thus the critical key exchange can be protected.

Certificates are usually verified by

• Checking the trust chain, i.e. if the certificate is directly or indirectly (via immediate certificates) issued by a certificate agency (CA) trusted by the browser or operating system.
• Verifying that the certificate is issued for the expected hostname, i.e. the subject matches the hostname.

With self-signed certificates or certificates issued by a CA unknown to the browser/OS this check will fail. In this case it is unknown, if the original certificate was already not issued by a trusted CA or if there is some man-in-the-middle manipulating the connection. Being man-in-the-middle is not hard, especially in unprotected networks like public hotspots.

Because the browser can not verify the certificate in this cases it will throw a big fat warning to show the user that something is seriously wrong. If your friends know that you only have some self-signed certificate there they should also know that this is the expected behavior of the browser in this case. You also should provide them with the fingerprint of your certificate so that they can be sure that this is the expected certificate - because there is no other way to check the validity of this certificate. Note that this warning also comes once because the browser saves the fingerprint and from then on knows that your site is associated with this certificate. But if you change the certificate it will complain again.

If you don't like the trouble of teaching all of your friends how to properly verify your certificate then get yourself a certificate by a public CA. They don't need to be expensive and some also issue free certificates.

Is is not true that "any encryption is better than no encryption"?

While bad encryption might be better than no encryption, transferring sensitive data over en encrypted but man-in-the-middle connection is definitely worse then transferring non-sensitive data with no encryption. And contrary to plain HTTP you can actually detect a potential man-in-the-middle attack with HTTPS. What you can not do is find out if this a potential man-in-the-middle attack or if the non-verifiable certificate is actually the expected, because the browser has no previous knowledge what to expect. Thus a self-signed certificate is actually not that bad provided that the browser knows up-front that this site only provides a self-signed certificate. And it might also not bad if the transferred data are not sensitive. But how should the browser know what kind of data and what kind of certificate are to expect?

Solution 2

Because SSL/TLS are trying to solve two problems in a single stroke, but you are completely ignoring one of them.

SSL is meant to provide both encryption (between two endpoints) and authentication (where each endpoint is exactly who it says it is). This latter solution is generally meant to be solved via organizations known as Certificate Authorities (CAs), who are supposed to verify your identity before agreeing to give you a certificate. While there have been some spectacular failures of this level of trust in the past, we don't have anything better yet, and so browsers still expect to see SSL/TLS certificates to be issued by one of these Trusted authorities; if it's not, there's no way to know if you're actually talking to the party you intended to.

So, while it may be encrypted, having an encrypted conversation with someone who shouldn't be party to the conversation is actually WORSE than having a plaintext conversation with someone who SHOULD be party to the conversation.

There are a few free SSL providers out there such as Let's Encrypt that won't cause this warning and still fit in your $0 budget.

Solution 3

Put chrome://flags/#allow-insecure-localhost into the Chrome address bar, then select the enabled option.

Solution 4

The reason for the click through is to offer some protection from phishing attacks.

The $0 work-around is to create a certification authority verified by Justaskin_ (which is just a special file) and have your friends to install the public key derived from of it on their computers.
Instead, use the private key to sign your https certificate and their browsers will accept it. OpenSSL is one tool that can do this.

View more solutions

Comments

[Ed Heal]

Why not get the certificate installed on your and your friends machine?

[Reishin]

he couldn't verify that your self-generated certificate is valid. To be able to verify that, you certificate should be located in the trust store, to which browser trusting. In other ways your "encryption" nothing cost, as browser couldn't check that this certificate is original, not replaced by attackers). Try to read about MITM attacks and google about "why self signed certificates are evil", and how https work at all

[user2864740]

See Public Key Infrastructure (Wikipedia)

[JustAskin]

@Reishin Are unencrypted HTTP connections not also vulnerable to MITM attacks...? My question is not about whether self-signed certificates can be used to verify identity (obviously, they cannot) but whether or not it should be considered "more secure" in any sense than unencrypted HTTP.

[Reishin]

@Justaskin_ yes, same like HTTPS with self-signed certificates. You not wanna to listen, completely.... An i will tell you even more, badly configure web server with valid SSL certificate will be vulnerable to, even more badly than simple HTTP.

[JustAskin]

> So while it may be encrypted, having an encrypted conversation with someone who shouldn't be party to the conversation is actually WORSE than having a plaintext conversation with someone who SHOULD be party to the conversation.

[user3391801]

Updated answer to refer to Let's Encrypt instead of StartSSL (which, last I checked, wasn't a trusted CA anymore)

[FluffyKitten]

Welcome to Stack Overflow. Code-only answers are discouraged on Stack Overflow because they don't explain how it solves the problem. Please edit your answer to explain what this command does and how it answers the question, so that it is useful for other users with similar issues.

[Pierre D]

We use ssh tunneling to our own ec2 instances that we own and manage and where we run a variety of services. This answer seems the most straightforward way to avoid the pesky dialog from chrome being unhappy with localhost.