2

Say that there are two servers that perform TLS. Both servers have valid end-point certificates. In other words, neither of them would raise a warning from the browsers after the connection has been established.

Is there any way that the client authentication requested by one server can be abused to create a valid connection to the other server? For TLS 1.2 the final authentication is performed using the Finished message containing verify_data which is calculated over all the handshake messages. Is this enough to prevent a man-in-the-middle attack even if there is a trusted malicious server in play? What about the former TLS 1.1, 1.0 and SSLv3 protocols?

One of the two servers can be considered to be malicious. The malicious server may use the same web-address with a valid client certificate from a different chain and private key. Any cipher suite is valid although ones that are commonly enabled in browsers have of course preference to an attacker. I don't think it matters much, but assume that the client authentication is performed using X509v3 certificates using PKCS#1 v1.5 padding with SHA-256 as signature algorithm.

  • "assuming that the server addresses cannot be distinguished by the client?" - i think you need to explain your setup in more detail. How can it happen that these are different servers with different certificates for different domains (???) but the client can not distinguish them? – Steffen Ullrich Jul 11 '15 at 9:26
  • @SteffenUllrich I'm assuming server addresses that the client cannot verify by eye. For instance the trap you get when you are forwarded to a "random" financial institution that handles the online payment for the web-shop you were visiting. Or some acronym that may represent the institution that you're trying to visit. Or a client-authentication server running next to the one that handles the other traffic. Especially on the first visit, the client can expect about anything. To make it easier, just assume two valid server certs for the same address. – Maarten Bodewes Jul 11 '15 at 9:40
  • @SteffenUllrich Thank you for helping me sharpen the question. The main question is if the client authentication can be used by a malicious server to log into the real server (i.e. man-in-the-middle attack). So client \<-> Malory's server \<-> real server. I'm presuming not as the DH parameters are usually signed. But I'm not sure for all the different suites out there. So I thought I would ask here just in case. – Maarten Bodewes Jul 11 '15 at 9:46
3

While your question looks complex I think it boils down to the following setup:

  • two servers, client does not know which one is the correct one
  • both require authentication with client certificates

And your question is, if client authenticates against server A: can this server use the successful client authentication to authenticate against server B? The answer is no, because server A does not have the private key of the client, only the proof that the client knows the private key. And since it does not know the private key server A can not proof to B that it knows the key. For details about this process see How does SSL/TLS work? where it states: "CertificateVerify: a digital signature computed by the client over all previous handshake messages.". And because the handshake messages are different between client and B to client and A a simply replay of CertificateVerify is not possible but the private key of the client is necessary to create a new CertificateVerify.

The situation would be different if no client certificates are involved, i.e. only username and passwords. In this case server A would get the credentials and could use them to identify against server B (classical phishing).

The situation would also be different if server A only forwards between the client and server B without modifying the messages. It is not possible for A to sniff or modify data in this case but if server B considers the IP address where it got the client certificate from as trusted for other purposes, this trust could then be used by server A.

  • I made the question even more specific to the TLS protocol and removed the add-on questions. As long as the protocol is secure I am pretty your answer is right, but I haven't done enough TLS protocol analysis to call myself a full expert yet. – Maarten Bodewes Jul 11 '15 at 12:48
  • @MaartenBodewes: Checking the client certificate is essentially that the clients proofs that it knows the private key of the certificate. But it does not send the private key. Thus the malicious server will not receive the private key and can thus not claim knowledge of the key against some other server. Man-In-The-Middle would not work too because of how TLS works. For more details see How does SSL TLS work. – Steffen Ullrich Jul 11 '15 at 13:47
  • I know that the private key isn't send :) I was just wondering if there was a loophole for the final authentication if the server isn't the one you would expect. But even in SSL v3 I can see that the authentication very probably takes too much information for this to succeed. The only thing that's still an issue is simply logging into the wrong server without noticing. That's something I presume cannot be helped. – Maarten Bodewes Jul 11 '15 at 14:08
  • In an active attack scenario, what exactly prevent server A from sending client certificate to server B and present server B challenge back to the client ? (Does the data to sign contain the FQDN of the server and it's verified by the client before signing ?) – r00t Jul 12 '15 at 17:44
  • @r00t: nothing prevents server A to do just forward the data, but sniffing or even modifying the encrypted connection is not possible. But if server B considers the IP address of A as trusted just because the client certificate was seen from this address, than this could be used as an attack vector. – Steffen Ullrich Jul 12 '15 at 20:27

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.