3 ms·

OpenSSL blog post: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... Q: Are

OpenSSL blog post: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... Q: Are all applications using OpenSSL 3.0 vulnerable by default? A: Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication. Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied.

NovemberWhiskey 4y ago
Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied. Paraphrasing... A: if you depend on mutual TLS; no.
- couchand 4y ago
  Well, it also seems to require that you completely ignore the trust chain? Am I reading that right? > Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.
  - NovemberWhiskey 4y ago
    The point is the vulnerable code will execute any time a trusted certificate is being validated. If you have a service that depends on mTLS, then your service is (by definition) validating client certificates so you can't mitigate your exposure. There is a separable question of whether your service trusts certificates issued by a CA that might produce a certificate with a SAN of the necessary form to trigger the exploit.
    - couchand 4y ago
      If you rely on mTLS you highly likely run your own CA. You can probably say with confidence that no malicious certificates have been signed by your CA. So you mitigate your exposure by ignoring certs without a valid chain of trust, which you're doing anyway. Am I missing something?

NovemberWhiskey 4y ago

Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied. Paraphrasing... A: if you depend on mutual TLS; no.

couchand 4y ago
Well, it also seems to require that you completely ignore the trust chain? Am I reading that right? > Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.
- NovemberWhiskey 4y ago
  The point is the vulnerable code will execute any time a trusted certificate is being validated. If you have a service that depends on mTLS, then your service is (by definition) validating client certificates so you can't mitigate your exposure. There is a separable question of whether your service trusts certificates issued by a CA that might produce a certificate with a SAN of the necessary form to trigger the exploit.
  - couchand 4y ago
    If you rely on mTLS you highly likely run your own CA. You can probably say with confidence that no malicious certificates have been signed by your CA. So you mitigate your exposure by ignoring certs without a valid chain of trust, which you're doing anyway. Am I missing something?