0

Say I own a domain called Bob.com, and I've sent an API request to Google.com. But instead of supplying a certificate for Bob.com, I send a certificate for Alice.com (which I got from a previous API request from Alice.com to my site). How / at what point in the SSL handshake does this mismatch get identified and the request to connect refused by Google.com? I've been thinking it through and can only think of two possibilities:

1) Google.com checks that the domain of the requester (Bob.com) matches one of the domain names in the certificate presented, and aborts the handshake if these don't match (however, I expect Google.com would only know the IP address of the requester rather than it's domain name)

2) At some point during the handshake (possibly key exchange?) Bob.com will need to perform some action that uses Alice.com's private key - and, as it doesn't have this, the handshake cannot be competed (if this is the case, at what point in the handshake does this action happen?)

Thanks in advance!!

user2521119
  • 35
  • 3
  • 1
    @schroeder Agreed. This is explained in some detail in the answers there. – Polynomial Dec 12 '18 at 10:18
  • @Polynomial I disagree - the accepted answer in that thread has a lot of information, but I cannot see a section that specifically calls out this scenario and states how TLS protocol prevents it from occurring. I think the answer below adds information that the other thread doesn't cover. – user2521119 Dec 12 '18 at 10:47
  • The "Certificates and Authentication" section of the answer in the linked question covers most of this. It probably would've been better to close this question as a duplicate of [*Client Certificate in SSL Handshake Insecure?*](https://security.stackexchange.com/questions/24577/client-certificate-in-ssl-handshake-insecure) since the answer there explains the process in more detail. – Polynomial Dec 12 '18 at 11:16
  • @Polynomial agreed, this link is much more to the point - thanks :) – user2521119 Dec 12 '18 at 13:53

1 Answers1

1

When you perform client certificate authentication, you must posses the private key for the certificate you are sending to server. Private key is used as a part of mutual TLS authentication to sign handshake messages.

If you don't have the right private key, you can't sign TLS handshake messages and client authentication cannot be completed.

If you sign messages with fake private key (which doesn't belong to public key in client certificate), server won't be able to successfully validate the signature against public key you sent along with client certificate.

Crypt32
  • 5,901
  • 12
  • 24
  • Thanks for this, makes sense. This website mentions 9 handshake messages in total https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm , do you know at what point the messages would start being encrypted with the sender's private key? I assume it wouldn't happen before the digital signatures had been verified, but that's only me assuming... – user2521119 Dec 12 '18 at 09:02
  • Never mind, I reread that link properly and it's steps 4 and 5 - 'The SSL or TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server's public key.' – user2521119 Dec 12 '18 at 09:11