-
Notifications
You must be signed in to change notification settings - Fork 985
Decode Subject Alternative Names (SAN) for X.509 Certificates #610
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
Conversation
| result.add(new SubjectName((String) o, type)); | ||
| } else if (o instanceof byte[]) { | ||
| // TODO ASN.1 DER encoded form | ||
| final byte[] bytes = (byte[]) o; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arturobernalg We have got to be super careful here as this method has security implications. It is better to be too strict and too lax here. I trust you know what you are doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arturobernalg We have got to be super careful here as this method has security implications. It is better to be too strict and too lax here. I trust you know what you are doing.
@ok2c I've ensured strict validation in the updated method: DNS names now reject unexpected byte[], IP addresses only allow 4 or 16 bytes with exceptions for invalid lengths, and unrecognized types log warnings while falling back.
| throw new IllegalArgumentException("Invalid byte length for IP address: " + bytes.length); | ||
| } | ||
| } else if (type == SubjectName.DNS) { | ||
| throw new IllegalArgumentException("Unexpected byte[] for DNS SAN type"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arturobernalg IllegalArgumentException looks really wrong here. Can we just ignore those bits that we are not able to properly recognize and handle?
| if (LOG.isWarnEnabled()) { | ||
| LOG.warn("Unrecognized SAN type: {}, data: {}", type, TextUtils.toHexString(bytes)); | ||
| } | ||
| decodedValue = TextUtils.toHexString(bytes); // Fallback to hex string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arturobernalg I would not do that. Before you know there will be so called security professionals with all sorts of hand-crafted certificates, claiming vulnerabilities in our code and demanding we issue CVE with them as a finder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ok2c please take another look
Supports DNS names as plain text, IPv4 and IPv6 addresses in binary form, and falls back to hex encoding for unknown types.
|
Has this change made into 5.4.3? I upgrade to that version yesterday and I'm seeing the following exception which seems related: When I downgrade to 5.4.2 the request succeeds. The URL that fails is the following: https://s3.amazonaws.com/kcm-alerts-realtime-prod/vehiclepositions.pb |
This failure isn't caused by SAN parsing. The old code ignored byte[] SANs entirely, including iPAddress (type 7), which per RFC 5280 must be stored as an OCTET STRING in network byte order. |
|
@leonardehrenfried This PR is completely unrelated to your problem. The cause of it is a regression introduced by #566. Feel free to raise a JIRA for the regression https://issues.apache.org/jira/browse/HTTPCLIENT |
|
Thanks for looking into it. I will create a Jira user and a ticket. |
This implementation adds decoding for Subject Alternative Names in X.509 certificates, including: