4 ms·
Unfortunately, that seems not to be correct. If you read RFC4346 (TLS1.1) correctly, then you recognize that the ClientHello message is comprised of the followi
by PinguTS 13y ago
Unfortunately, that seems not to be correct. If you read RFC4346 (TLS1.1) correctly, then you recognize that the ClientHello message is comprised of the following data:
- client_version
- random
- session_id
- cipher_suites
- compression_methods
There is no additional hashing involved.
Some of these issues are addressed in later versions. But. And there is always a big BUT: http://f0rki.at/static/slides/f0rki-downgrade-attacks-by-example-bsidesvienna2012.pdf http://f0rki.at/static/slides/f0rki-downgrade-attacks-by-exa...
I will now not got through all the published informations or talks from BlackHat, CCC, and so on. ;o)
- mnordhoff 13y agoKeep reading down to section 7.4.9. After the negotiation is finished, the client and server exchange MACs of the previous messages to be sure they weren't tampered with.
- lvh 13y agoThe verification occurs at the end of the handshake, not at the start. After all, at ClientHello, the peers haven't agreed on anything yet.
- Nursie 13y agoTLS has its issues and has some fairly sohpisticated attacks against it, sure,, but simple ciphersuite MITM is not one of them as co-posters have explained.
- tptacek 13y agoThe hash you're looking for is in the _Finished_ message; both sides are implicitly required to hash all handshake messages except for _HelloRequest_. The ClientHello message is most definitely authenticated in TLS; I think you're straightforwardly mistaken.