[ilikehurdles]

The URL bar is helpful to fighting phishing attacks. It's one of the things everyone at my company, including the non-technical people, is askedt to check before entering information.

Also techie and non-techie people have been using the same browsers for how many decades now? Aren't the majority of people in many countries on the internet? It seems like the average non-techie users succeeded in figuring things out so far.

[u801e]

> The URL bar is helpful to fighting phishing attacks

It would have been nice if client side TLS certificates were more popular. Then your browser could warn you that you're not using your client cert when connecting to a certain website and not allow you to complete the connection. That would be a better solution as opposed to relying on users to manually check the URL.

[ralph84]

How does a client-side cert help with authenticating the server? Why wouldn’t a phishing site also ask for the client-side cert if the real site does?

[Arnavion]

It doesn't. The way client certs are useful is that a website that only uses client certs for authenticating clients removes the ability for the client's credentials to be leaked.

Even if the user uses the client cert with a phishing site, the phishing site doesn't have the ability to impersonate the user against the real site because the private key is still on the client's device.

In addition, if a browser is configured to automatically use a client cert for all requests to a particular domain, then even that leak doesn't happen because the browser would automatically not use the cert with the phishing domain.

[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.

[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.

[arbitrage]

while we're wishing for things that just won't ever happen, can I have a pony?