0

this is my first question here, I've researched this briefly but couldn't find any satisfying answer. TLS handshakes are being sent over the wire unencrypted. This way someone that eavesdrops can learn a number of things about the connection (e.g. domain being accessed, protocol being used [ALPN], cipher as well). Why not initially use an anonymous cipher to encrypt the handshake and then switch to non-anonymous cipher after the certificate has been verified? MITM shouldn't be an issue here because the certificate still needs to be presented and verified.

Rotwang
  • 3
  • 1
  • 7
    Possible duplicate of [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) – Limit Apr 20 '18 at 16:18
  • Exact duplicate of : https://security.stackexchange.com/questions/175112/ssl-tls-handshake-potential-vulnerabilities but the the other question that I mentioned answers this question – Limit Apr 20 '18 at 16:19
  • How would you even do that? The whole point of a TLS handshake is to establish the necessary shared secrets to do encryption for the rest of the session. Before the handshake is done, how would you know what keys to use? – Ajedi32 Apr 20 '18 at 16:19
  • Possible duplicate of [SSL/TLS handshake potential vulnerabilities](https://security.stackexchange.com/questions/175112/ssl-tls-handshake-potential-vulnerabilities) – alecxe Apr 20 '18 at 17:06
  • 1
    I wouldn't say that this question is a duplicate of any of those. The author of [SSL/TLS handshake potential vulnerabilities](https://security.stackexchange.com/questions/175112/ssl-tls-handshake-potential-vulnerabilities) wonders about tls handshake being susceptible to MitM while what I'm worried about is that parameters of the tls connection are being "leaked". ps I did read the [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) it explains the tls topic well but it doesn't address my question. – Rotwang Apr 20 '18 at 20:33
  • @Ajedi32 that's what Diffie-Hellman is for I think. You could establish a shared secret for the initial part of the handshake. That's why I've mentioned anonymous ciphers (my understanding is that they can do just that but are susceptible to MitM). – Rotwang Apr 20 '18 at 20:41
  • @Rotwang Okay, now how are you going to communicate the fact that you're going to use DH to the client? The TLS handshake _is_ how you communicate these things between the client and server. – Ajedi32 Apr 20 '18 at 20:51
  • Learn how SSL handshakes work, you’ll then be able to answer this question. – Ben Lavender Apr 20 '18 at 21:39
  • I think you’d be interesting in reading about 0 round trip time in the new TLS 1.3 standard as it kinda relates to your concern. https://www.google.com/amp/s/blog.cloudflare.com/introducing-0-rtt/amp/ – SuperAdmin Apr 21 '18 at 05:10
  • [TLS1.3 -- still in draft after 4 years --](https://tools.ietf.org/html/draft-ietf-tls-tls13-28) proposes to do something very like this; it first does keyexchange using only DHE/ECDHE (ephemeral) or a tweaked PSK that subsumes resumption (longterm or ephemeral), then does some extensions (at least optionally including SNI and ALPN) and authentication and optionally '0-RTT' data (similar to the old 'fast start') under the 'handshake secret' before finalizing the 'application secret' used for, you probably guessed it, application data. – dave_thompson_085 Apr 21 '18 at 05:21

2 Answers2

1

You need the parameters for the encryption in the handshake. You can't encrypt anything without having at least the public key of the other user or a shared secret. Also, using some sort of hard-coded cipher could cause compatibility problems. That is the whole point of the handshake, not to bind the protocol to a single cipher with single set of settings.

Peter Harmann
  • 7,778
  • 5
  • 20
  • 28
  • So essentially what would need to happen is a "pre-handshake". However I guess that would add too much overhead without providing adequate benefits? – Rotwang Apr 20 '18 at 20:38
  • @Rotwang a pre-handshake would be just another handshake, it would add no benefits, as you would just do the handshake twice. The other option would be to just have a fixed encryption but I outlined the problems with that and you would still need a way to share keys, so that is a no-go. There however is a sort of post-handshake, where everything in the handshake is confirmed using the encrypted channel. The problem is, that if a MITM attack downgrades the connection to insecure ciphers, this post-handshake is done using the insecure parameters and can be broken. There is no known solution. – Peter Harmann Apr 21 '18 at 10:46
0

The information which is transmitted in the handshake contains the public keys of both sides. This information was designed to be public and doesn't involve any risk for both parties.

In cryptography a basic assumption is that a malicious attacker has the information about which protocol is being used and a full pcap of the session and yet - he/she won't be able to break the encryption (assuming it's strong like TLS/RSA etc).

Nir Alfasi
  • 136
  • 7