1
$\begingroup$

I asked this question recently but I was told it is not save to simply send over the identifier for your crypto method you want to use. for example, say the server has crypto method 3 5 and 6, the client had 2, 3, and 6.

The clients sends the methods it can do and the server checks the highest possible version. A man in the middle could intercept the message from the client and only send 3, so the server would use the weakest common method. Obviously you don't want this, we want them to use 6 (the highest is the strongest in this case).

I have tried to figure out why TLS does not have this weakness (other than the FREAK bug) but somehow I can't find out why TLS does this better. So my question: How does TLS ensure the use of the best crypto method both the server and client share?

Background info

I curently have a piece of code which has a crypto layer (very old) it currently sends 00 which indicates it needs to use our old crypto method but 01 will be TLS (which I'm going to implement) However having TLS and an insecure exchange to determine the crypto method is obviously as strong as our insecure exchange. But to keep it backwards compatible we can't simply switch our old crypto method for TLS so we need to do this exchange. which is why i need to know how to do this properly.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

How does TLS ensure the use of the best crypto method both the server and client share?

It does not. The server is responsible for selecting the cipher and there is no guarantee that it will select the best. But, if a man-in-the-middle tampers with the ClientHello to change the ciphers offered to the server, then this tampering will be detected at the end of the handshake, because their is a final signature over all data of the handshake and this signature will not match anymore.

Improve this answer
$\endgroup$
5
  • $\begingroup$ So if i would us the PSK (i'm using a psk) to apply a (SHA256) HMAC to the crypto methods i send and then send it over to check that would be enough to resist this man in the middle attack? $\endgroup$
    – Vincent
    May 19, 2015 at 7:54
  • $\begingroup$ I don't know the details of your custom protocol (remember, custom cryptography is usually not a good idea), but technically it should be enough to hash the offered ciphers and send this hash back, as long as modifications of the hash by a man-in-the-middle will be detected. $\endgroup$
    – Steffen Ullrich
    May 19, 2015 at 8:02
  • $\begingroup$ I know it's a bad idea but that's what the company i work for made years ago and since backwards compatibility is a huge issue there is no other way. Though is it safe to use my PSK directly in the hmac? without applying a KDF first? or should i send a random number with the methods to create a temporary key KDF(rand, PSK) for the hmac? $\endgroup$
    – Vincent
    May 19, 2015 at 8:24
  • 1
    $\begingroup$ Sorry, but this is out of my experience and I better don't give any tips which might be even slightly wrong. If you redesign cryptographic protocols you better talk to real experts. $\endgroup$
    – Steffen Ullrich
    May 19, 2015 at 8:57
  • $\begingroup$ @VincentAdvocaat: Maybe TLS-SRP could be useful? (It uses PSKs instead of certificates. But apart from its existence I know nothing about it.) $\endgroup$
    – StackzOfZtuff
    May 19, 2015 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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