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?
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.
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_h...
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.)
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...
(*why yes, it is a retail application)
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.
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.
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)