[HN Gopher] OpenSSL security advisory: Infinite loop reachable w...
___________________________________________________________________
OpenSSL security advisory: Infinite loop reachable when parsing
certificates
Author : psanford
Score : 150 points
Date : 2022-03-15 16:54 UTC (6 hours ago)
(HTM) web link (www.openssl.org)
(TXT) w3m dump (www.openssl.org)
| beny23 wrote:
| I wouldn't have thought this an issue if you're behind an AWS WAF
| or LB? (and assuming AWS is patched already)
| nazlorenzo wrote:
| This vulnerability affects parsing maliciously crafted
| certificates, so it will mostly affect clients. If your app is
| fetching data from a 3rd party and validating its certificate,
| it may be vulnerable, regardless of how you are fronting
| requests to your site.
| lmilcin wrote:
| > 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 wrote:
| 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 wrote:
| 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?)
|
| 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.
| jcims wrote:
| Depends if s2n is vulnerable to the same bug. Of course AWS
| doesn't protect you against application bugs so if your
| application has an SSRF vulnerability (presumably otherwise
| unexploitable) an attacker might be able to DoS you.
|
| They don't mention S/MIME or things like signed binaries or
| SAML assertions but those seem plausibly vulnerable as well.
| acdha wrote:
| For an intermediary like a WAF, load-balancer, or CDN to help
| it needs to do all of the certificate processing and keep your
| backend app from seeing the certificate at all. If you are
| terminating HTTPS at the edge and using HTTP internally that's
| very likely but if you're using an NLB instead of an ALB, it's
| not. Similarly, you'd also want to see if there's any
| application-level path where a certificate would be included in
| an uploaded file but that's far less common.
| jamespwilliams wrote:
| I think nearly everything at AWS uses s2n and not OpenSSL these
| days
| justinsaccount wrote:
| Has s2n been fips certified? I thought some things
| (govcloud?) were still using openssl due to fips
| requirements.
| znep wrote:
| I'm not sure what they are using right now, but they
| currently have the "AWS-LC Cryptographic Module" listed as
| being in process for validation which may be sufficient for
| s2n.
|
| I know there are other AWS features/services that are lined
| up behind that validation for FIPS support.
___________________________________________________________________
(page generated 2022-03-15 23:01 UTC)