Decode Subject Alternative Names (SAN) for X.509 Certificates#610
Decode Subject Alternative Names (SAN) for X.509 Certificates#610arturobernalg merged 1 commit intoapache:masterfrom
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.
@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.
@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.
@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.
@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.
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: