[u801e]

~~It wouldn't work because the phishing site would lack the private key needed to validate your client-side certificate and the TLS connection would not be established. This is assuming that the legitimate website itself signed your certificate signing request (CSR) to create the client-side certificate.~~

Edit:

What I posted above is not correct. What I should have said was that the server would validate the client certificate by checking a certificate authority (either managed by the server itself or a 3rd party).

[Arnavion]

>It wouldn't work because the phishing site would lack the private key needed to validate your client-side certificate and the TLS connection would not be established.

That is not how TLS works. A server can trust a client based on the certificate the client presents. A client can't distrust a server based on the certificate the client presents.

"The phishing site would lack the private key needed to validate your client-side certificate" is nonsense. Neither the real site nor the phishing site have the private key used to generate the CSR; only the client that sent the CSR has that, and validating a cert does not involve the private key in any way. If you're thinking of a new protocol where the server itself generates an arbitrary asymmetric keypair and shares it with the client, then a) that's not TLS, b) that could just as well be done with a symmetric key (since this is just pre-shared key auth) where the server presents a nonce to the client to sign and verifies the client signed it, and c) a fake server can just not do that.

[u801e]

> That is not how TLS works. A server can trust a client based on the certificate the client presents. A client can't distrust a server based on the certificate the client presents.

You're correct; I posted inaccurate information.

> validating a cert does not involve the private key in any way.

What I should have said was that the server would validate the client cert by checking whether the certificate is valid according to the authority that signed it (which could be the server serving as a CA itself or a third party CA).

As for the original question, I guess it's possible for a phishing website to not bother validating the client certificate presented at all and allow the TLS negotiation to succeed.

If there was something that could instruct a browser to only send a given client certificate if it only receives a certain server certificate, then it would be much harder for a phishing website to work, because the browser would not send the client certificate to the wrong server.

[bmm6o]

Not to pile on, but I think you're imagining some kind of TLS framework that simply doesn't exist currently. It's not clear if you're misunderstanding what exists now, or you're alluding to a different possibility without clearly articulating it.

> I guess it's possible for a phishing website to not bother validating the client certificate presented at all

Why would a phishing site do anything to discourage a connection from a potential victim? Of course a phishing site would accept an invalid or missing certificate! Even if the site was impersonating something like amazon.com, Amazon hasn't issued client certificates to all of its users so the whole point is moot.

[u801e]

> I think you're imagining some kind of TLS framework that simply doesn't exist currently. It's not clear if you're misunderstanding what exists now, or you're alluding to a different possibility without clearly articulating it.

It's possible that I am misunderstanding it, but it appears that the point of contention is what the server will do when it receives a certificate from the client.

Ideally, it would check if it's valid by checking it against a CA. So, if someone who manages the server signed the CSR, then the server can validate the certificate with a CA that it manages. If it uses a 3rd party CA, then it would validate it using that.

What I'm not sure about is whether a browser can map a particular client side certificate to present to a server based on the server side certificate presented to the client. If it could, then it would be easy to determine whether one has connected to the correct server since the browser wouldnt' try to present the client side TLS cert to the wrong server.

> Even if the site was impersonating something like amazon.com, Amazon hasn't issued client certificates to all of its users so the whole point is moot.

Which was the point of my original post. If we had worked in making the process of generating and using client side certificates more user friendly, then companies would have done so as part of the account creation process (meaning poeople would use their client cert in addition to their username and password as part of the authentication process).

What we have now is major companies like Amazon using SMS based 2FA that would easily be compromised by re-routing the verification code message to another device since that factor is not under my control, but at the mercy of the phone company.

[ralph84]

A private key is not required to validate certs (private keys are for generating certs). A cert chain back to a trusted root cert is required for validation. A phishing site would just trust all certs.

[u801e]

I realize that now. One way to mitigate it would be to have the browser somehow tie a given client certificate with a particular website. That is, the client cert for news.ycombinator.com, would only be presented if I try to connect with that server and nothing else.

That way, if I go to a phishing website that pretended to be Hacker News, my client certificate would not be sent and my browser could warn me by saying that the connection is not using a client certificate. Right now, if we only rely on server side certificates, there's nothing stopping a phishing website from using Let's Encrypt to show the secure connection icon in the URL bar and tricking me into thinking it's a legitimate server.