-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Erroneous handling of IP address SANs #3498
Comments
Thanks for your report! I agree that the way the library currently compares IPs to domain name is a bug, and that it should either ignore non-DNS SANs or handle them properly according to their types. I think there are two parts there:
I'm currently investigating the first part, trying to clarify the implications, and coming up with a fix. Once that's done, we'll hopefully be in a better place to start supporting IP SANs. |
I'm working on a fix, and writing a ChangeLog entry describing the issue and crediting you for finding and reporting it. How would you like to be credited: by your github handle, your legal name? do you want to include an affiliation? Thanks! |
Hi, I don't really care about attribution that much. If you want to credit me, Github handle is OK. |
Ok, thanks! |
Description
mbed TLS build:
Version: checked on 2.16.4 and git-8f4f9a8da, likely occurs on all versions that support SAN
Actual behavior
x509_crt_verify_name()
treats all kinds of Subject Alternative Names equivalently, even in cases where it does not make sense. In particular, IP address SANs are compared byte-by-byte with whatever the value ofcn
is - and in the typical cases it is a hostname (specifically, in the case of normalmbedtls_ssl_context
operation, it's the value configured viambedtls_ssl_set_hostname()
).It is possible, for example, for a certificate to exist with an IP address SAN for
97.46.112.108
(a perfectly valid IP owned by Verizon in the US), which would erroneously match a hostname ofa.pl
(an actual Polish retailer's website). While unlikely, this is seems like a possibility for certificate spoofing.This also means that it is very difficult to handle connecting to a server that actually uses an IP address SAN in its certificate, as there is no way to pass an IP address to mbed TLS when connecting.
Expected behavior
I would expect IP address SANs to be either ignored or compared in a more appropriate way (e.g. stringified first, perhaps?)
The text was updated successfully, but these errors were encountered: