curl verifies incorrect subject alternative name when contacting https proxy #12831
Comments
|
I didn't spend time working on a repro but we fairly sure that there is at least inconsistent output where there shouldn't be. |
|
That curl version is 5.4 years out of date. Does this reproduce with a recent
version? What TLS library are you using?
|
|
Hi Dan, we are using openssl. |
|
@HsiehYuho I added a test case using '127.0.0.1' for the proxy and gave it a certificate with a x590 IPAddress in the alt names. This test works with curl 8.6.0. Could you recheck your findings? Is there anything specific in your ipv6 address spec that we may not account for? |
- improve info logging when peer verification fails to indicate if DNS name or ip address has been tried to match - add test case for contacting https proxy with ip address - add pytest env check on loaded credentials and re-issue when they are no longer valid - disable proxy ip address test for bearssl, since not supported there Ref: #12831 Closes #12838
- refs curl#12831 - when verifying a proxy certificate for an ip address, use the correct ip family. That may be different from the "connection" ip family.
|
@knekritz, @HsiehYuho thanks, that is exactly the right spot. Would you be able to verify that #12931 fixes the issue for you as well? |
|
@icing i tried to verify it. I git clone your branch and follow https://github.com/curl/curl/blob/master/GIT-INFO to but it seems not hit you fix. I suspect my build is wrong. the |
Use src/curl instead, which may be a libtool wrapper script that uses LD_LIBRARY_PATH to load the libcurl that's in lib/.libs |
|
@HsiehYuho if you run ./src/curl with options |
I did this
I tried
It gives me SAN match failure.
However, the [proxy:ipv6] is in the proxy cert SAN field.
When switching to
the curl succeeds.
We (my colleagues and me) are suspecting checks around here https://github.com/curl/curl/blob/master/lib/vtls/openssl.c#L2152 lead to that curl only checks the proxy SAN type that is same as the destination type
I expected the following
should at least give me the same result
curl/libcurl version
curl 7.61.1 (x86_64-redhat-linux-gnu)
operating system
Linux, but our company (meta) dev our own linux ..
The text was updated successfully, but these errors were encountered: