Is encryption still applied if you ignore the SSL certificate warning for self-signed certs?

Question

Would encryption still be applied on communication with devices using self-signed certificates if you ignore the warning and proceed without installing the certificate? Would you need to install it to ensure encryption or will it by default encrypt when the user ignores the warning and proceeds?

I understand that the integrity part or validating the server or device by a CA is not applied but just wanted to know if the encryption part would be applied if we ignore the browser warning and proceed.

If installing is required, In an environment where you log in only from an internal network to an internal-only asset through https etc. let's say an internal portal, would it be recommended to add that self signed certificate to the trusted list so that the encryption would be applied and MiTM attacks wouldn't be able to see the credentials sent over. In a pure internal-only production setup (assuming a CA is not set up yet) what would be the best practices with self-signed certificates.

BTW, it is not a „self signed“ warning, it’s a warning about „not trusted (issuer)“. If you verify the issuer yourself (by checking the fingerprint of the certificate) this can actually be even more secure than trusting any of hundreds international CAs to do their work correctly. — eckes, Jul 18 '19 at 19:42
With some handwaiving, this is effectively what Anonymous Diffie-Hellman (ADH) does. In TLS when using ADH the server does not even bother sending its certificate (if it has one). It only sends its DH public key to the client. — , Jul 18 '19 at 20:08
Insiders are one of the biggest threat vectors. "Internal only" should not be much of a consideration! (There may even be a dramatically elevated risk that a single person ends up with all the roles needed to orchestrate the mitm attack alone.) — Affe, Jul 18 '19 at 22:25
Dupe https://security.stackexchange.com/questions/110334/is-my-ssl-connection-encrypted-if-the-certificate-isnt-trusted — dave_thompson_085, Jul 19 '19 at 06:22

score 29 · Answer 1 · answered Jul 18 '19 at 10:25

29

If you ignore the certificate warning the encryption still applied, but because it's an unauthenticated encryption, the encryption is useless against active adversary (an MITM adversary that can intercept and modify the data passing through it), as the active adversary can just reencrypt your connection.

The best practice to use self signed certificate in production environment is to compare the certificate fingerprint with the expected certificate fingerprint obtained through a trustworthy channel. After you verified the certificate fingerprint, you then should pin the certificate by adding it to the trusted list. Additionally, if you need to work with lots of certificates and lots of devices, you can create your own certificate authority and add that root CA certificate to the root trust list.

answered Jul 18 '19 at 10:25

Lie Ryan

31,089
6
68
93

Thanks for this, for an active adversary - they would still need the private key of the server right? If they intercept the traffic they will be getting encrypted data again, to decrypt and re-encrypt it again he would need the private key of the device/ server the client is sending the data to? Assuming he has not compromised the target server yet. – Damien.Rick Jul 18 '19 at 10:58
22

@Damien.Rick: an active adversary do not need the server's private key to intercept, they simply need to intercept the handshake and send their own self signed certificate to your client, and your client will just accept it because it doesn't validate the connections' certificate. – Lie Ryan Jul 18 '19 at 11:36
3

@Damien.Rick no, they don't need any compromise of the target server, the man-in-the-middle attack would result in the attacker being "the server" in communication with you and "you" in communication with the server, and have two separate SSL channels that are secure from passive listening but not from the intercepting proxy in the middle. – Peteris Jul 18 '19 at 18:53
9

Basically, the attacker shows you a *different* self-signed certificate that you blow through the grand warning for, then proxies your data to the actual server. PKI prevents this by making the common name (CN) of the certificate trustworthy, but exchanging fingerprints manually is just as good! – trognanders Jul 19 '19 at 06:36

score 16 · Answer 2 · answered Jul 18 '19 at 10:32

16

Yes, the communication is still encrypted with self-signed certificates.

Self-signed certificates can be made by you, but they also can be made by any attacker. If you insist on using self-signed certificates, I would advice you to mark the certificate as trusted, so that you get a warning if an active man-in-the-middle attack is happening.

Creating your own CA certificate is not really more difficult than creating a self-signed certificate, and has the advantage that you can create trusted certificates now and in the future by just trusting your CA certificate.

answered Jul 18 '19 at 10:32

Sjoerd

28,707
12
74
102

1

Of course, you should be especially careful of CA private keys, since if those are compromised, the attacker could create his own valid certificates on your behalf - a single key leak would compromise all of your other certificates derived from the CA. A leaked private key for an end certificate compromises your connection to that one server, but doesn't affect any of the other certificates in your system, unlike a leaked trusted CA key. – Luaan Jul 19 '19 at 12:21
If you want to use a custom CA, it should be scoped to a single domain you actually own, not a fake root CA. – R.. GitHub STOP HELPING ICE Jul 19 '19 at 20:50
In general, managing a custom CA is a rather involved process if you actually want it to be secure. Think key-signing ceremonies, physically secure offline key storage, regular rotation of intermediate keys, and so on. It's not for the faint of heart. – Kevin Jul 20 '19 at 20:02

score 5 · Answer 3 · answered Jul 18 '19 at 12:08

Cryptography has three main security goals:

Confidentiality
Integrity
Authentication

The certificate in the TLS/SSL handshake is used to provide authentication, i.e. to guarantee the client that he is talking to the intended server and not some Man in the middle attacker. Ignoring a certificate warning will kill this property of the connection.

The connection will still be secured by cryptographic means to provide confidentiality and integrity, i.e. only the initial communication partners (whoever they might be) are able to read or modify a message.

score 3 · Answer 4 · answered Jul 19 '19 at 09:35

Encryption is still applied, the issue with self signed certificates is that you have no assurance that the server you are connecting to is who it says it is.

The problem is not so much that they are self signed, it's that they are not signed by some third party you trust. When you browse to a https website your computer checks that the certificate you are given has been signed by a third party that you trust, which means unless there has been a compromise of the server, you are connecting through an encrypted channel and who you are connecting to is who they say they are. With self signed you cannot be sure of the second part.

ulidtko · Answer 5 · 2019-07-19T19:47:31.450

Let me just draw a MITM for you.

                   ===| When you accept a self-signed cert |===
                   ===|           and get lucky            |===

+--[Your browser]--+                                         +--[Server S]--+
|  accepts cert A  |                                         | has cert A   |
|      sends       +---------------------+-------------------> has key A    |
|   POST /secret   |                     |                   | decrypts     |
|  encrypts for A  |              +------+-----+             |              |
+------------------+               pahQu:eiSh6m              |     sees     |
                                  (seen on wire)             | POST /secret |
                                                             +--------------+

                   ===| When you dismiss browser warnings |===
                   ===|       and accept whatever         |===

+--[Your browser]--+      +---[Evil Chris' server]----+      +--[Server S]--+
|  accepts cert M  |      |                           |      |              |
|      sends       |      | has cert M  |     accepts |      | has cert A   |
|   POST /secret   +--+---> has key M   |      cert A +---+--> has key A    |
|  encrypts for M  |  |   | decrypts    |  reencrypts |   |  | decrypts     |
+------------------+  |   |                     for A |   |  |              |
                      |   |         ! SEES !          |   |  |     sees     |
           +------------+ |       POST /secret        |   |  | POST /secret |
            fex5be;P[ivR  +---------------------------+   |  +--------------+
           (seen on wire)                                 |
                                                    +-----+------+
                                                     Qui8paeY]u0V
                                                    (seen on wire)

See? Encryption is kinda useless (i.e. easily defeated) without authentication.

"Real" (not self-signed) certificates provide authentication: a way for your browser to tell if it's talking to the server that website/domain owner controls, or some totally different machine.

That said; yes encryption is still applied. Even with bogus certificate, you still get protection from passive evesdropping. However, in principle, some network devices can detect self-signed certs and perform SSL MITM in what looks like totally passive fashion, invisible until you start verifying byte-to-byte exact matches of fingerprints.

For intranet use, setup a CA and pin/trust its roots.

By the way, if you still think you have to pay for green HTTPS — check out https://letsencrypt.org/ NOW.
These guys, the Let's Encrypt authors, the EFF, fight a good fight to protect your digital rights.
Learn more on your own.

score 0 · Answer 6 · answered Jul 19 '19 at 15:59

Yes, encryption is applied. The warning is simply notifying you that the identity of the server you are sending encrypted data to may not be who they claim to be, thus information that you send over the encrypted connection may be going to an unauthorized party. Self-signed certificates can be dangerous to accept because anyone can generate one claiming to be anyone else.

However, if you are the owner of the certificate and are sure your private key to the certificate hasn't been compromised, or you can validate that the person who presented the certificate holds the private key to the certificate (also ensuring it hasn't been compromised), then you can trust the connection, in which case you can install the certificate as a trusted root to tell your computer that you trust connections to the server presenting this certificate. This is not required to enable encryption though, the encryption is still applied when just ignoring the warning.

Bass · Answer 7 · 2019-07-20T18:48:11.873

Encryption will still happen. It is mostly useless though.

TLS aims to ensure that the connection between the endpoints is secure. For this to happen, it is essential that the endpoints can identify each other. Since it's impractical for every endpoint to share a secret with every other site, a trusted third party (Certificate Authorities) is used to verify the ownership of each (asymmetric) secret.

When you click "yeah, go on already, who cares" on the alert, you bypass this verification, and you have absolutely no idea who is at the opposite end.

To put it into other words:

If someone ever successfully impersonates the site to which you are going to send your private data, that particular warning is the only one you'll see. Don't ignore it.

Instead, you should install the particular self-signed certificate as a "trusted certificate" on the client machine(s), or even better, have the other end use LE certificates instead of self-signed ones.

Is encryption still applied if you ignore the SSL certificate warning for self-signed certs?

7 Answers7

Linked

Related