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.

Maarten Bodewes
  • 4,562
  • 15
  • 29
  • "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 09: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 09: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 09:46

1 Answers1

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.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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](http://security.stackexchange.com/questions/20803/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
  • Thank you for the answer but I think I was not clear enough. I was thinking at the scenario where client connects to server A and server A connects to server B and presents the challenge given by B to the client as if it was server A challenge (to impersonate the client). Server A has the clear text with the client in this case as it's not a mitm, client wants to authenticate against A, A is just sending the same challenge as B is sending to him. (blame me if it's not clear this time) – r00t Jul 12 '15 at 21:40
  • @r00t: this will not work because A would need to fake the CertificateVerify from the client and can do this only if it has access to the private key of the client certificate. – Steffen Ullrich Jul 12 '15 at 21:48
  • @SteffenUllrich : ok, so what you are saying is that when the client signs the challenge, he adds the name of the server to wich he is authenticating with ? (to prevent server A from reusing this signature ; as server B will see that it was not intended to him if A tries ?) – r00t Jul 12 '15 at 21:53
  • @r00t: I'm not saying that. But this is not the place to explain how TLS works, please look at http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work which also explains more details about CertificateVerify. – Steffen Ullrich Jul 12 '15 at 22:01
  • @SteffenUllrich : I already read that. I think we just don't understand each other (my bad). I will try a last time. If not, it's ok I don't want to bother you. To verify that the person who presents you a certificate owns the private key, you encrypt some challenge and ask him to decrypt it. What if server A takes server B encrypted challenge (he is not able to decrypt it as he doesn't have the private key) and presents to the client this challenge as if it was his (server A) challenge and passes the decrypted data back to B ? – r00t Jul 12 '15 at 22:08
  • This is not some challenge specified by the server but (to cite the link) "a digital signature computed by the client over all previous handshake messages". Thus server A can only change it if it changes the handshake as man-in-the-middle but then the CertificateVerify cannot be verified by server B any more since it does not match the handshake from the perspective of B. – Steffen Ullrich Jul 12 '15 at 22:12
  • @SteffenUllrich : Many thanks dude, that makes sense now. That was the point I missed. +1. I would cite this in your answer as it clarify the "server A does not have the private key of the client, only the proof" which is not replayable. :) – r00t Jul 12 '15 at 22:17
  • I've accepted this answer. Thanks for the edit that explains why the verification cannot succeed on another server because the signature is over *all of* the handshake messages. It would be even nicer if we could make that more formal, but this is the answer regardless of that. – Maarten Bodewes Jul 13 '15 at 22:25