-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Respond with TLS alert "bad_certificate" if certificate parsing fails #1710
base: main
Are you sure you want to change the base?
Respond with TLS alert "bad_certificate" if certificate parsing fails #1710
Conversation
The basic idea is good, but the patch is a bit simplistic:
|
- Refactor response into common static method - Apply response to certificates received by server, too - Only throw a new TlsFatalAlert in case of an unspecific IOException
Thanks for your feedback.
Agreed, I refactored my patch to have a common method which is used both for handling of received client and server certificates
Fixed.
JcaTlsCrypto.createCertificate() detects if the certificate is not of type X.509 and responds with "unsupported_certificate". bc-java/tls/src/main/java/org/bouncycastle/tls/crypto/impl/jcajce/JcaTlsCrypto.java Lines 162 to 171 in 0520ebc
If none or more than one ASN.1 object has been provided, TlsUtils.readASN1Object() throws a "decode_error" (the method is originally called by JcaTlsCertificate.parseCertificate()) bc-java/tls/src/main/java/org/bouncycastle/tls/TlsUtils.java Lines 1080 to 1093 in 0520ebc
For everything else, "bad_certificate" is IMHO the right response at this place. Rationale:
|
Improve the error handling in case a invalid (syntactically incorrect) certificate is received in a TLS handshake from the server.
Previously, the exception thrown during ASN.1 parsing was not caught and therefore caused a TLS alert "internal_error". This PR handles the exception to respond with a RFC-compliant TLS alert "bad_certificate".