Writer of the top answer here. I haven't looked at the post in a while, it might be that the answer is slightly outdated. BREACH has been released after writing the answer and RC4 hasn't gotten anymore secure, but besides that I don't think it misses that much. Let me know or do suggested edits if there is anything you think should be added!
Wikipedia articles tend to be written in a rather impenetrable style† that take a lot longer to convey the answer to a basic question like this than a good Stack Exchange answer would.
† Often they alternate between being completely cryptic until you have read 14 other articles and going into full-on infovomit mode.
Side question: what about an active MITM attack which changes the ciphersuite preferences?
So e.g. if I know as an attacker of a weakness in scheme X (which is advertised by both server and client), but server and client would prefer scheme Y, then I'd just have to manipulate the initial handshake to include only scheme X, right?
>> Side question: what about an active MITM attack which changes the ciphersuite preferences?
Part of the protocol involves exchanging checksums of all data passed between the server and client. Can't remember off the top of my head exactly when this takes place, but effectively the whole handshake process is fed into a hash algorithm and if they don't match then the connection won't be established. The hash itself will be protected from MITM by some sort of signing/MAC.
In TLS 1.0 and 1.1, the Finished message is protected by HMAC-MD5 and HMAC-SHA1. (RFC 2246, sections 5 and 7.4.9.) (By the way, while there are attacks against MD5 and SHA-1, there are no known attacks against HMAC-MD5 or HMAC-SHA1. Don't freak out.)
TLS 1.1 is the same as TLS 1.0. (RFC 4346, sections 5 and 7.4.9.)
For TLS 1.2, I am uncertain which algorithm is used. See RFC 5246, sections 5 and 7.4.9. It's either HMAC-SHA256 or the MAC defined by the chosen cipher suite, which would currently be one of HMAC-MD5, HMAC-SHA1, HMAC-SHA256 or HMAC-SHA384. (As long as your weakest cipher suite's MAC can't be broken in half a second, this doesn't help an attacker.)
Edit: Staring at RFC 5246 a bit longer, I am almost certain that TLS 1.2 will always use HMAC-SHA256. Future cipher suites may define a different algorithm, but no such cipher suites yet exist.
(Edits: This post was basically written one sentence at a time in a dozen different edits.)
>> In TLS 1.0 and 1.1, the Finished message is protected by HMAC-MD5 and HMAC-SHA1. (RFC 2246, sections 5 and 7.4.9.) (By the way, while there are attacks against MD5 and SHA-1, there are no known attacks against HMAC-MD5 or HMAC-SHA1. Don't freak out.)
Yeah, been reading up on HMAC lately. I had to implement a MAC algorithm due to a weird failing by an embedded platform vendor. HMAC(sha256) was it, until at the last minute we switched out for iso9797 algorithm 3, pad 3* because a second vendor we have to work with couldn't support 32 byte keys. It's always a bit sad to write beautiful code and then discard it again within days...
Yes, your are right. That is the weakness. That is the reason why it his highly advised to look at your supported cipher suites on the client side and disable the weak ones.
Many people say: "No problem, it is anyhow a decision by the server and this side will choose a strong encryption." But the weakness here is the problem you described.
>> Yes, your are right. That is the weakness. That is the reason why it his highly advised to look at your supported cipher suites on the client side and disable the weak ones.
You absolutely should configure all endpoints only to use adequate cipher suites, but that's simply because the bad ones shouldn't be used and as a client you don't want to rely on the server being well configured (and vice-versa).
HOWEVER - that does not mean a handshake MITM is possible, the protocol accounts for this, please see my parallel reply to yours.
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-exa...
I will now not got through all the published informations or talks from BlackHat, CCC, and so on. ;o)
The 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.
Keep 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.
TLS 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.
Will it make my client more unique (so identifiable) for a third-party passive attacker (who can sniff traffic) if I tune my browser's settings for example to support only TLS 1.2 and by removing all the RC4 encryption methods?
People who can't read Wikipedia ask questions on Stackexchange.
I always assumed, if you are on Stackexchange you have at least some knowledge and also be competent enough to look for information yourself in the first place.
> People who can't read Wikipedia ask questions on Stackexchange.
Not saying this is an example of this behaviour but there are also groups of people kudos whoring on SE/SO by shill posting questions and then providing very thorough/researched answers shortly afterwards from their real account(s).
I've got hands-on experience 10 years ago, I thoroughly understand how SSL handshaking is working. But it's still not enough, especially with the latest upgrades and attacks.
I'll save it somewhere. BTW, where do you guys save the important information? Or just let it passed? Can never remember enough detail about it. And next time when I need it, it's hard to find any more.
Thank you for showing the list, which is part of the marketing campaign I'm running on both Kickstarter and Hacker News. Since those posts are not on the first page, they disappeared quickly, and I'm afraid that not many people have visited.
Is there anything wrong with it? Do you mean I cannot or should not post the series of blog posts here for people to visit?
Instead, I'd like to hear from you how you like it or why you hate it.
You may check out if I only commented on my own project from all my comments:
