OpenSSL security advisory: Infinite loop reachable when parsing certificates
openssl.org
openssl.org
I know there are other AWS features/services that are lined up behind that validation for FIPS support.
They don't mention S/MIME or things like signed binaries or SAML assertions but those seem plausibly vulnerable as well.
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"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.
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.
You made up a number with no grounding in reality because of your bias due to being "general public".
For corporate services it is actually quite common to use client certificates and mutual auth. Also popular with VPNs.
You might not be aware of this because corporations do not want to deal with people who do not know or can be forced to know how to generate signing request.
This is different when you control both the service and the users of the service and you have something valuable to protect.
As an example, I worked with credit card terminals and these used mutual auth with properly managed client certificates.
You wouldn't call DOS on all terminals and ATMS "insignificant".
they removed a lot of cruft, but this is needed
1. yes, having things done the right way where they need to be done makes sense. think of the user after. for instance, you could just make his stupid cloud device aggregate all the keys he needs automatically
Which format?
What algorithim?
How do you prevent it from being sent to the wrong domain and enabling MITM phishing?
X.509 has a lot of issues but they've thought through a number of things. Whatever you replace it with would have similar problems. Even if you "just sent a key" it would have to be parsed in some way (Say it's RSA, you'd still have to pull the module and exponent out before you could do anything with it, if the channel is text you'd probably do some base64 decoding etc.)
> How do you prevent it from being sent to the wrong domain and enabling MITM phishing?
TOFU. Petnames.
> it would have to be parsed in some way
Encoding a key is trivial, even with an ad-hoc serialization format. Nothing near what X.509 does.
Non-practical but https has been running on it for decades now?
Yeah there are issues with it and as someone that's worked with it a lot at the profile design and issuing level, I think it's high time we came up with a replacement and ditched ASN.1 entirely. But ...
It's hard to see it as a non-practical, academic idea when it's out there, deeply embedded in the internet, everywhere.
> just make the user provide the public key
Doesn't solve the problems X.509 addresses. There's a lot more going on than a method to exchange keys.
It is non-practical, has no application in reality, and the direct consequence of using such a tool is massive security problems being disclosed every year.
> Doesn't solve the problems X.509 addresses.
What problem does X.509 address? Not only is it needlessly centralized, but your connection can be intercepted as long as one single CA anywhere is compromised. The "solution" to this is to log what certs each client got, reducing their privacy because this would allow us to detect when an attack happened, after it already happened (followed by a barrage of petty arguments like "w-well, it would disincentivize an attacker"). Also, a domain name that sounds kind of like the company you want to connect to is not proof that you have the right domain name. You still have to ask them for the right domain name, at which point you may as well have just received their public key. The alternative is to do this dog shit thing you guys keep doing where you complain about Google search not being regulated enough and enact more ad-hoc laws many of which backfire. Imagine search engines having to do work to find the "real" domain for some company. This is 10th level stupidity, we could not have got here without several other generations of stupidity becoming normalized prior.
In particular: " In OpenSSL, this loop resulted in a DoS vulnerability, CVE-2022-0778. BoringSSL is mostly unaffected by this. In particular, this case is not reachable in BoringSSL from certificate and other ASN.1 elliptic curve parsing code. Any impact in BoringSSL is limited to:
- Callers of EC_GROUP_new_curve_GFp that take untrusted curve parameters - Callers of BN_mod_sqrt that take untrusted moduli"
:D :D :D