I understand the ssl handshake flow, but still need few verifications:

  1. If I'm trying to forge another handshake the client will fail because, and only because the certificate I'll send him back is not trusted?
  2. I understand that the session keys (symmetric) are used to decrypt/and encrypt the data.
    • Where are those stored in the client?
    • If I go to a client computer, get this session key, can i decrypt all the data sent to the server? (I mean, isn't the traffic encrypted with the public key from the server?)
  3. Also, I understand that the handshake can be sent during the flow to keep it more secured, if the certificate is not trusted, does the connection ends now? (because in the first step, i understand that the user can decide to go further with a warning in his browser that the certificate cannot be trusted).
  • Since you're asking multiple questions, you should make one post per question. Commented Dec 28, 2013 at 19:21

2 Answers 2


1) I'm not sure what you mean. There are numerous reasons a handshake could fail, however it should be noted that generally an untrusted certificate will not result in the handshake failing, but rather an indication of a lack of trust in the connection. A shared session key can be determined even if the server being connected to is untrusted and fails certificate validation.

2) It could vary by client, but probably just in memory. Yes, if the session key is stolen from either the client or the server, then the session can be monitored. This is why it is important that your client machine be secure. If the attacker controls the server or your client, SSL won't do you any good. Note, this is actually how some enterprise firewalls work. They use an SSL certificate on the firewall and then communicate the session key to both the server and the client so that all parties on the line can read the traffic.

3) As answered in #1, the lack of authentication of a connection is simply a failure to validate the recipient, it is not a failure of SSL to establish an encrypted tunnel. You still have a secure connection between you and the third party, the identity of the third party simply can not be validated and is thus untrusted.

  • 1 last thing, but if during the transmission the server/client decides to make the handshake again. What blocks me, as an attacker, replace the certificate and all the handshake response, and now make the client talk to me?
    – user36427
    Commented Dec 28, 2013 at 20:54
  • The client encrypts the session key with the public key of the server. Only the holder of that private key can get the session key and the client knows if the public key can be trusted. A third party might be able to get the client to send them the encrypted session key, but they wouldn't be able to decrypt it. Commented Dec 29, 2013 at 5:19

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .