# How does SSL secure the initial handshake?

I'm reading the SSL specs, and it seems that the initial handshake has no authenticity protection at all. What is to prevent, say, an attacker from overwriting the "available ciphers" list with one that is full of broken, or even null, ciphers? Is there some sort of defense for this, or is this fundamentally unsolvable because the handshake part by definition cannot itself be authenticated (which leads to infinite regress)? Is there a way to anonymously authenticate the initial, non-authenticated part of an SSL connection?

-
SSL, as in SSL 3.0? That is severely deprecated due to security concerns (like the kind you are mentioning. Do you mean TLS? –  Richie Frame Oct 27 '13 at 20:31
Yes, I mean TLS. SSL 3.0 isn't severely deprecated, though. I think it is still widely used. SSL 2.0 is the badly insecure one. –  user54609 Oct 27 '13 at 20:49

The cornerstone of the handshake security is that the Finished messages, sent under the protection of the newly exchanged key (for encryption and MAC), contain hash values computed over all the handshake messages exchanged so far, including the list of cipher suites and all other parameters. As long as client and server don't negotiate the use of a cipher suite which can be broken instantaneously, these Finished messages reliably detect foul play.
What if the attacker forces the client and server to negotiate the NULL cipher? –  user54609 Oct 27 '13 at 21:06
So in the real world, as long as the servers are configured not to support weak ciphers, the Finished messages don't really matter? –  user54609 Oct 27 '13 at 23:39
The Finished message always matter. One of their jobs (but not the only one) is to prevent "version rollback attacks". –  Thomas Pornin Oct 28 '13 at 10:45