In a SSL handshake, asymmetric cryptography occurs. In particular, the client uses the server's public key for key exchange, and the magic of asymmetric cryptography implies that only the owner of the corresponding private key (the server) will be able to unravel the whole thing and obtain the same "master secret" as the client. Without this "master secret", you cannot decrypt all that is encrypted with it, i.e. the remaining of the SSL connection.
To certificate is there to convey the server's public key to the client. If, as an attacker, you let the client learns the true server's public key, then the client will use it and you will be locked out by the cryptography. So, your goal, as an attacker, is to feed to the client your public key, as part of a fake certificate. What prevents you to do it is that the server certificate is a certificate, i.e. it is signed by a Certificate Authority that the client trusts. If your fake certificate is not signed by a CA that the client trusts, then the client will reject that certificate and refuse to complete the handshake. Of course, existing CA are not supposed to sign fake certificates...
When the client is a Web browser, an untrusted server certificate is incarnated as a "scary browser warning" which, depending on the browser, may be bypassed by the user with one or several clicks ("I understand the risks" / "Confirm security exception" / ...). The risks that the user "accepts" are, here, that the certificate may be faked, and contain an attacker's public key who currently tries to impersonate the server. SSL's security evaporates like morning dew if the user accepts to use an untrusted server certificate.
The important point to remember is that it is not showing the certificate which matters, but knowing the private key. The certificate is there to inform the client about which public key it should use, but only after due validation, which is what certificates are about.
Once all the asymmetric cryptography has been played, a shared master secret is known to both client and server. From that master secret are derived the encryption and MAC keys used to actually protect the data for the duration of the connection.
A master secret may be reused: this is the "abbreviated handshake" (see section 7.3 of the TLS standard). If a given client and server still remember a master secret from a previous connection, then they may reuse it for other connections, bypassing the asymmetric cryptography step (this results in a faster handshake with much fewer data bytes to be exchanged). A typical SSL client will keep such a master secret in RAM only. On the server side, RAM-based storage is also the most common case, but some servers actually store master secrets in a database: this is done in order to allow several front-ends to be aware of the same values (depending on the used load balancing technology, it may be difficult to ensure that a given client will always talk to the same front-end server, hence the need to share master secrets across front-ends if abbreviated handshakes are to be supported). Since master secrets are quite sensitive data (knowing a "master secret" allows decrypting all traffic which has been encrypted relatively to it), allowing them to be written to some permanent storage device is a matter of delicacy...
If a client accepts to use an alleged but unvalidated server public key, then the client does not really know to whom it is currently talking. Whether the clients accepts to keep on talking or not is up to its internal policy; in the case of Web browsers, it depends on how much the human user is willing to click through warning messages.
SSL supports the notion of doing a new handshake within the context of an existing connection. Though this second handshake gets encrypted with the secret keys negotiated from the first handshake, this is not a really crucial feature: each handshake is supposed to be able to withstand attacks on its own. How much "security" is transported from the first to the second handshake is not clearly defined; some implicit assumptions about it turned out to imply a vulnerability. What must be remembered here is the following:
If the client could not validate the server's certificate, a second handshake will not restore security, unless the client successfully validates the certificate sent by the server for the second handshake.
Security assumptions about the connection transfer across the second handshake in one direction only: for instance, what the server could ascertain about the client's identity before the second handshake is still valid after the second handshake, but not really the other way round (if the client was authenticated with a certificate of its own during the second handshake, this authentication does not necessarily covers whatever data was sent by the client before the second handshake).
In practice, the use of an extra handshake within the first is there to make a smoother support for client certificates. In SSL, the server may ask the client to also show a certificate (and use the corresponding private key); this is certificate-based client authentication. However, Web browsers tend to act poorly in that case, from a user's point of view. For instance, if the server asks for a client certificate, then a technical and ugly popup may appear on the user's screen, asking him to select a certificate (in the case of old versions of Internet Explorer, the popup might even appear with an empty list). Therefore, Web servers who use certificate-based client authentication wish to do so only when they are reasonably sure that the user indeed owns a certificate and knows what is going on, i.e. not for the top-level page of a Web site, but only from some specific pages.
However, a Web server learns the target page (as part of the HTTP request) only after the handshake has completed. During the handshake, the server just knows that it is invoked, but knows no detail about the HTTP request yet; it has not seen the URL yet. So Web servers do not ask for a client's certificate during the first handshake. When they "see" the request, and only then, may they realize that the request is for one of the pages which require client authentication, and in that case trigger a second handshake within the connection.
