0

The question is about a very specific SSL handshake scenario. I understand that some servers may request client certificates in order to authenticate connecting clients. However, as far as I can know, server only checks the authenticity of the client. Why would you not use client certificate to generate premaster key? For example, let server generate the key and sign it with public key it received from the client so that only the legitimate client can decrypt it.

The use case can be, for example, when MITM attacked somehow came into possession of server's private key. Now I know it's a bad situation to begin with but still. So in this case even if client authentication IS requested by the server, attacked can simply pass the certificate and certificate verify messages to the server and continue on eavesdropping the session. However if client's public key was used to generate the symmetric key, this would help prevent this. Since attacker doesn't have client's private key it would not be able to decrypt the session.

1

Your description is a bit confused; I see you are talking about "signing with the public key" which is analogous to "encrypting with the private key", i.e. a widespread but flawed explanation which does not actually work with real asymmetric cryptographic algorithms as they are used in practice.

Nevertheless, it can be said that what you seem to suggest does not do what you believe it does; or, rather, SSL is already more secure than you believe. When the attacker knows the private key of the server, then he can impersonate the server: the client talks to the attacker, believing that it talks to the genuine server. Similarly, if the attacker knows the private key of the client (assuming that the client has a private key, and the server asks for client authentication with a certificate), then he can impersonate the client when talking to the server. This is generic. However, in order to pull off a true Man-in-the-Middle attack, the attacker must do a double impersonation: he must simultaneously impersonate the server (when talking to the client) and impersonate the client (when talking to the server).

With SSL as defined by the standard, when the server request a certificate from the client, a true MitM is not feasible unless the attacker knows the secret keys of both the client and the server. The problem you allude to ("server only checks the authenticity of the client") does not actually exist. Therefore, your proposal cannot solve it (there is no possible solution for an inexistent problem).


In fact, somehow mixing the client's public key may make things worse. Ideally, the server's public key should not be used for key exchange either. The reason for that is often called forward secrecy (PFS). If the server uses a classic RSA-based key exchange, and the attacker, later on, steals a copy of the server private key, then the attacker can decrypt past recorded sessions. This is bad. But there is a fix in SSL, called "DHE" as "Ephemeral Diffie-Hellman". When using DHE cipher suites, the actual key exchange uses DH key pairs that both client and server generates on the fly; the server merely signs its DH public key using its permanent private key. This provides PFS because the server never stores its DH private key anywhere, making it presumably immune to ulterior theft.

We may note that, in SSL, the client's key, when used, is only for a signature; and that is good. It means that if the client's private key is stolen, previous sessions still remain confidential. Using a DHE cipher suite enables the same desirable property on the server side. This enhanced security is not obtained by "using the client certificate to generate the premaster key"; quite the contrary indeed. It is achieved by ceasing to use the server certificate to generate the premaster key.

  • But what if either client or server don't support DHE and there can be no PFS. In this case symmetric key is derived for each new session. And this key, when transmitted, is only encrypted by server's public key. But since we have another pair of keys on the client side, why not use them to provide a "second layer" of protection? I'm sorry, security is not my area of expertise so my question may look "confused". I just don't see how the client's private key is used and why would attacker need it. – mkashin Jan 31 '14 at 4:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.