1

Posted this on Cryptography; reposting here in case it's more relevant.

I am trying to better understand how TLS works. I understand in the normal use case you need various random values generated and used in the key exchange, to prevent some MITM reusing a previous transmission to spoof the server or the client.

However, let us assume some degenerate case where there is a single server whose single public key is already known by its clients as well as various adversaries. In this case, I would think all that is strictly speaking necessary to perform a secure key exchange would be the following:

  1. Client uses server's public RSA key to encrypt random symmetric session key
  2. Client sends server encrypted session key
  3. Server decrypts session key using server's private RSA key
  4. Server uses session key to encrypt a "finished" message
  5. Server sends client encrypted "finished" message
  6. Client uses session key to decrypt "finished" message
  7. Client verifies message is "finished", handshake is complete

So in this simplified process, the only value changing each session is the session key itself, so no previous client or server random is used; and there is no pre-master secret, again only the session key.

This feels like a drastic oversimplification of things, but I am having trouble seeing what I am missing. If the main purpose of a key exchange is to make sure the server is the only one getting the session key, this seems to be secure. Proof by contradition, tracking the above process again, but from the perspective of an adversary:

  1. Adversary already has the server's public key, could encrypt its own symmetric session key for MITM purposes
  2. Adversary can see encrypted session key from client, but cannot decrypt it; can send server its own encrypted MITM session key
  3. Server decrypts MITM session key, unaware of its origin
  4. Server uses MITM session key to encrypt "finished"
  5. Server sends client (in fact adversary) encrypted "finished"
  6. Adversary can decrypt "finished", but cannot re-encrypt and send to client with client's session key, which adversary cannot decrypt
  7. Client will ultimately never receive correctly encrypted "finished", either from server or adversary

So it seems the only potential weakness here is that the server has no way of knowing whether it is communicating with a legitimate client or an adversary - but as I understand it, authenticating the client was never in view to begin with. Authenticating the server is, but in this case that is not a concern since there is only a single server.

So am I correct in understanding that if one were to employ this scheme, it would be impossible for an adversary to perform a MITM attack? Or how could this be defeated?

3
  • "If the main purpose of a key exchange is to make sure the server is the only one getting the session key," - it might be the main but is not the only important one. Protecting against replay is important too, which your idea does not protect from since the key is fully determined by the client. Forward secrecy is also important, but once the private key of the server is compromised all previous traffic can be decrypted with your approach. Nov 1, 2021 at 22:15
  • Please next time don't cross-post the same question without deleting the other, Is cross-posting a question on multiple Stack Exchange sites permitted if the question is on-topic for each site?
    – kelalaka
    Nov 2, 2021 at 8:09
  • @kelalaka understood, advised
    – Bondolin
    Nov 2, 2021 at 21:53

1 Answer 1

1

The protocol that you describe does not prevent replay attacks.

Suppose your bank's server used this protocol, and you made a request to an endpoint at your bank's server to send $1000 to Eve, and Eve is able to capture all of the packets going back and forth between your client and your bank's server.

Eve could simply repeat the process, doing exactly what your client did in steps 1, 2, 6, and 7, and make another transfer from your bank account to herself for $1000.

This is why 'real' TLS is a little more complicated. See https://tls.ulfheim.net/ for a good walkthrough of how TLS 1.2 works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.