[lmilcin]

> This vulnerability affects parsing maliciously crafted certificates, so it will mostly affect clients.

Actually, it is the opposite.

You seem to be unaware of the fact that servers do receive certificates from the clients which are then parsed.

Which is already mentioned in the advisory document:

  "Thus vulnerable situations include:

   - TLS clients consuming server certificates
   - TLS servers consuming client certificates <---- here
   - Hosting providers taking certificates or private keys from customers
   - Certificate authorities parsing certification requests from subscribers
   - Anything else which parses ASN.1 elliptic curve parameters"

[alexw91]

That's not how the TLS handshake works. The TLS server must be configured to request a certificate from the client in order for the client to know that it needs to send a client certificate to the server, and that server-side configuration is disabled for ~99%+ of endpoints.

TLS server implementations should be aborting the TLS connection for violating the TLS Handshake state machine if a client attempts to send a client certificate when it wasn't requested.

So while this bug affects both clients and servers, 100% of clients are parsing the server's TLS cert during the TLS handshake, but less than ~1% of servers are parsing a client's certificate during a handshake.

[lmilcin]

There is very little reason to DOS a client and a lot of reasons to attack servers.

There is a huge number of public facing services that implement mutual auth and all those are potentially vulnerable to DOS. While clients can just decide to not connect to a web service that causes their browser to malfunction (and why have you connected there in the first place?), services are usually not at liberty to ignore a client at this stage.

So yes, those servers that do request client certificate are targets and my point still stands that servers are much more affected than the clients.

What would be an affected client? You keep connecting to this infected website that causes your browser to die? Somebody embedded some tracking on their page that now points to an infected website? Everybody will just move on and it is hard to say you are very much affected by this problem.

Whereas if you are a service and you are affected you absolutely need to implement a fix.

[unixbane]

correction: literally 99.99999% of endpoints. they use password^W SMS authentication instead. no seriously, how is the only one good thing about X.509 (authentication via public key) the only unused part (to be fair, if anyone used it, wed have a whole new 10 episodes of vuln disclosures).