5

Someone on my team said that there is a form of TLS that can be utilized that eliminates the need for a private key. They are "above" me, and I didn't want to argue without knowing for certain that is not the case. I've done my homework and the private key is critical for verification of the client/server identity. This is what I thought. Yes, there are ways to script the re-creation of these keys upon every session, but that's extreme.

Is there any way to have a private-keyless TLS that is not just some hacked together "symmetric encryption"?

bashCypher
  • 1,839
  • 11
  • 21
  • Private key is used during the handshake process, so unless I'm unaware of some new key exchange, this is required in TLS – pm1391 Feb 06 '18 at 03:05
  • Yeah, that's what I believe also. He trailed off when I was confused and mentioned diffie-helman... idk. Thank you for seconding – bashCypher Feb 06 '18 at 03:40
  • Diffie Hellman is just a mechanism to exchange keys in a secure manner, mainly used in on symmetric algorithms like AES. – pm1391 Feb 06 '18 at 03:48
  • Agreed! I'm just relating info to spark possible memory of the mentioned "private key-less system"... or confirm this was not accurate by that person. Thanks for helping, btw! – bashCypher Feb 06 '18 at 03:58
  • not sure if "TLS" supports it, but you could use RSA (or another pubkey system) for traffic. We normally use symmetric for traffic because it's a lot faster, but PKI does work; it's how you get your private key. – dandavis Feb 06 '18 at 04:03
  • Diffie Hellman allows to two parties to establish a secure connection, which is a great thing to have (communication is _confitendial_). However, it does **not guarantee authenticity**, so you know you are communicating confidentially, but you can't verify **who your are talking to**. This is where asymmetric algorithms like RSA come in really handy. – GxTruth Feb 06 '18 at 08:46

2 Answers2

5

TL;DR: TLS can in theory be used without private keys.

An integral part of TLS is that the client properly authenticates the server in order to detect potential man in the middle attacks. This is commonly done with certificates - and this requires the private key of the certificate on the server site to prove to the client that the server is the owner of the certificate1.

But, TLS is flexible and also provides other ways to authenticate the server. There are PSK ciphers which allow authentication by using a pre-shared key between client and server. There are SRP ciphers which allow authentication by password. There are even anon ciphers which allow you to abandon any kind of in-TLS authentication, i.e. require you to do your own authentication.

Thus, TLS might be used without certificates. And since certificates are the only part of TLS which requires a private key this means that TLS can be used without private keys. But, even if no private key is used a similar secret thing might be required on the server: both SRP and PSK based authentication require a secret on the server side which should at most be known to server and client.

Apart from this, certificate-less (and thus private-key-less) authentication requires both sides of the connection to support the relevant ciphers with the alternative authentication methods. Since browsers currently only support certificate-based authentication a private key is needed on the server side whenever access by a browser is required - i.e. practically every time in case of web servers.

For example you can use openssl to provide a TLS protected connection which does not require certificates. The server would look for example like this:

$ openssl s_server -www -nocert -psk 1a2b3c4d

The client would need to use the same key when connecting to the server, i.e. the basic idea behind PSK is that client and server share a secret key:

$ openssl s_client -connect 127.0.0.1:4433 -psk 1a2b3c4d
...
Cipher    : PSK-AES256-CBC-SHA
...
Verify return code: 0 (ok)

If you would try to connect with a browser to this server (i.e. https://127.0.0.1:4433) you would only get an error since the browser does not support the PSK ciphers: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

1 Private keys can not only be required for authentication but also for key exchange, i.e. RSA key exchange. But, RSA key exchange requires certificates so it again means that private keys are only relevant if certificates are used. Also, the Diffie-Hellman key exchange does not need certificates and this is actually the recommended method today since it provides forward secrecy.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • This is great. Thank you! What I'm taking is that it make sense that person might have said this, misunderstanding or misremembering mention of something similar... but if we want to use certificates in the way they are intented then you must have a private key. – bashCypher Feb 07 '18 at 19:57
1

You do need the private key, but that does not mean that you need direct access to the private key. You can use a TPM or an HSM where the key is born on, and never leaves, the physical hardware. Any operations that need the private key happen within those devices in an isolated and protected memory space.

Here's how to utilize a TPM on Windows using a virtual smart card and software that taps into APIs that interact with the TPM:

https://security.stackexchange.com/a/179422/68088

vrtjason
  • 1,045
  • 9
  • 10