Using SSL_NO_VERIFY stops sending the SNI header
#113
Comments
|
This seems to be a documented limitation of libcurl's CURLOPT_SSL_VERIFYHOST option:
We could try only turning the CURLOPT_SSL_VERIFYPEER option off instead of turning both options off. The difference between these two options is a little confusing, but my reading of the docs is that VERIFYHOST is about checking whether the cert the server presents is for the right host or not whereas VERIFYPEER is about checking whether the certificate presented can be verified via CA roots and whatnot. It might be ok to leave VERIFYHOST on since the main purpose of the option for this is as an escape hatch if someone's local CA roots are messed up or they are behind a MITM firewall. I don't think there are a lot of realistic scenarios where someone needs to talk to a server that's presenting a certificate for the wrong host. My understanding is that what we do now matches the behavior of |
|
The "fix" here is just this patch: diff --git a/src/Curl/Easy.jl b/src/Curl/Easy.jl
index 0ac9fc1..c143fdd 100644
--- a/src/Curl/Easy.jl
+++ b/src/Curl/Easy.jl
@@ -76,7 +76,6 @@ set_url(easy::Easy, url::AbstractString) = set_url(easy, String(url))
function set_ssl_verify(easy::Easy, verify::Bool)
setopt(easy, CURLOPT_SSL_VERIFYPEER, verify)
- setopt(easy, CURLOPT_SSL_VERIFYHOST, verify*2)
end
function set_ssh_verify(easy::Easy, verify::Bool)I would have thought that this would cause |
|
In https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html under "Limitations", it is documented that when `CURLOPT_SSL_VERIFYHOST` is set to zero this also turns off SNI (Server Name Indication): > Secure Transport: If verify value is 0, then SNI is also disabled. SNI > is a TLS extension that sends the hostname to the server. The server > may use that information to do such things as sending back a specific > certificate for the hostname, or forwarding the request to a specific > origin server. Some hostnames may be inaccessible if SNI is not sent. Since SNI is required to make requests to some HTTPS servers, disabling SNI can break things. This change leaves host verification on and only turns peer verification off (i.e. CA chain checking). I have yet to find an example where turning host verification off is necessary. Closes #113.
In https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html under "Limitations", it is documented that when `CURLOPT_SSL_VERIFYHOST` is set to zero this also turns off SNI (Server Name Indication): > Secure Transport: If verify value is 0, then SNI is also disabled. SNI > is a TLS extension that sends the hostname to the server. The server > may use that information to do such things as sending back a specific > certificate for the hostname, or forwarding the request to a specific > origin server. Some hostnames may be inaccessible if SNI is not sent. Since SNI is required to make requests to some HTTPS servers, disabling SNI can break things. This change leaves host verification on and only turns peer verification off (i.e. CA chain checking). I have yet to find an example where turning host verification off is necessary. Closes #113. (cherry picked from commit 86e52d7)
When setting
JULIA_SSL_NO_VERIFY_HOSTS, Downloads.jl does not send the SNI header. Some hosts fail to properly set up an SSL session when the SNI header is not present. Command line curl seems to present the header when when verification is switched off.Tested on :
system curl :
curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2Downloads.jl:
libcurl/7.73.0 SecureTransport zlib/1.2.11 libssh2/1.9.0 nghttp2/1.41.0Tested with AWS Cloudfront, which shows this behaviour. Error shown from Pkg is:
cc: @vdayanand
The text was updated successfully, but these errors were encountered: