Cannot download from GitHub with curl 7.42.1 on Windows #267

Closed
michael-o opened this Issue May 14, 2015 · 23 comments

Comments

Projects
None yet
5 participants
@michael-o
Member

michael-o commented May 14, 2015

Running

mosipov@MIKA /d/Projekte/curl ((curl-7_42_1))
$ curl --version
curl 7.42.1 (i386-pc-win32) libcurl/7.42.1 WinSSL
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtp
telnet tftp
Features: AsynchDNS Largefile SSPI Kerberos SPNEGO NTLM SSL

with

curl https://github.com/michael-o/curl.git

gives me

curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - 
Das Format der empfangenen Nachricht war unerwartet oder fehlerhaft.

I have compiled this to solve this issue.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 14, 2015

Member

How did you build? I have curl-7_42_1 checked out and I cannot reproduce. I was trying to reproduce a separate issue on Win2k and at one point I got an ILLEGAL_MESSAGE error but I figured it just something to do with protocol or algorithms disabled in Win2k.

In Windows 7 x64:

X:\j\curl\curl-LATEST\build\Win32\VC10\DLL Debug - DLL Windows SSPI - DLL WinIDN
>curld --version
curl 7.42.0-DEV (i386-pc-win32) libcurl/7.42.0-DEV WinSSL WinIDN
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp
smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug IDN Largefile SSPI Kerberos SPNEGO NTLM SSL

X:\j\curl\curl-LATEST\build\Win32\VC10\DLL Debug - DLL Windows SSPI - DLL WinIDN
>curld https://github.com/michael-o/curl.git
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

There is a problem with schannel in curl that I'm working on at #244 but I don't think it's related.

Member

jay commented May 14, 2015

How did you build? I have curl-7_42_1 checked out and I cannot reproduce. I was trying to reproduce a separate issue on Win2k and at one point I got an ILLEGAL_MESSAGE error but I figured it just something to do with protocol or algorithms disabled in Win2k.

In Windows 7 x64:

X:\j\curl\curl-LATEST\build\Win32\VC10\DLL Debug - DLL Windows SSPI - DLL WinIDN
>curld --version
curl 7.42.0-DEV (i386-pc-win32) libcurl/7.42.0-DEV WinSSL WinIDN
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp
smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug IDN Largefile SSPI Kerberos SPNEGO NTLM SSL

X:\j\curl\curl-LATEST\build\Win32\VC10\DLL Debug - DLL Windows SSPI - DLL WinIDN
>curld https://github.com/michael-o/curl.git
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

There is a problem with schannel in curl that I'm working on at #244 but I don't think it's related.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 14, 2015

Member

I have built with mingw, gcc 4.8.2, make 3.81 on Windows XP SP3. This is how I built:

D:\Projekte\curl>mingw32-make mingw32-sspi-winssl

Here is a trace output:

$ curl --trace - https://github.com/michael-o/curl.git
== Info:   Trying 192.30.252.130...
== Info: Connected to github.com (192.30.252.130) port 443 (#0)
== Info: schannel: SSL/TLS connection with github.com port 443 (step 1/3)
== Info: schannel: checking server certificate revocation
== Info: schannel: sending initial handshake data: sending 77 bytes...
== Info: schannel: sent initial handshake data: sent 77 bytes
== Info: schannel: SSL/TLS connection with github.com port 443 (step 2/3)
== Info: schannel: failed to receive handshake, need more data
== Info: schannel: SSL/TLS connection with github.com port 443 (step 2/3)
== Info: schannel: encrypted data buffer: offset 7 length 4096
== Info: schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - Das Format der empfangenen Nachricht war unerwartet oder fehlerhaft.
== Info: Closing connection 0
== Info: schannel: shutting down SSL/TLS connection with github.com port 443
== Info: schannel: clear security context handle
== Info: schannel: clear credential handle
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - Das Format der empfangenen Nachricht war unerwartet oder fehlerhaft.
Member

michael-o commented May 14, 2015

I have built with mingw, gcc 4.8.2, make 3.81 on Windows XP SP3. This is how I built:

D:\Projekte\curl>mingw32-make mingw32-sspi-winssl

Here is a trace output:

$ curl --trace - https://github.com/michael-o/curl.git
== Info:   Trying 192.30.252.130...
== Info: Connected to github.com (192.30.252.130) port 443 (#0)
== Info: schannel: SSL/TLS connection with github.com port 443 (step 1/3)
== Info: schannel: checking server certificate revocation
== Info: schannel: sending initial handshake data: sending 77 bytes...
== Info: schannel: sent initial handshake data: sent 77 bytes
== Info: schannel: SSL/TLS connection with github.com port 443 (step 2/3)
== Info: schannel: failed to receive handshake, need more data
== Info: schannel: SSL/TLS connection with github.com port 443 (step 2/3)
== Info: schannel: encrypted data buffer: offset 7 length 4096
== Info: schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - Das Format der empfangenen Nachricht war unerwartet oder fehlerhaft.
== Info: Closing connection 0
== Info: schannel: shutting down SSL/TLS connection with github.com port 443
== Info: schannel: clear security context handle
== Info: schannel: clear credential handle
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - Das Format der empfangenen Nachricht war unerwartet oder fehlerhaft.
@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 14, 2015

Member

Confirmed SEC_E_ILLEGAL_MESSAGE fail on XP x86 SP3 and XP x64 SP2. Vista/7/8 ok. Tested curl-7_42_1 in configuration DLL Debug - DLL Windows SSPI - DLL WinIDN | Win32 using Visual Studio 2010.

Member

jay commented May 14, 2015

Confirmed SEC_E_ILLEGAL_MESSAGE fail on XP x86 SP3 and XP x64 SP2. Vista/7/8 ok. Tested curl-7_42_1 in configuration DLL Debug - DLL Windows SSPI - DLL WinIDN | Win32 using Visual Studio 2010.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 14, 2015

Member

Thanks for the confirmation. I just opened up the GitHub URL in IE8, it won't load. So I guess we need to report this to GitHub directly. It does not seem to be a bug in curl.

Member

michael-o commented May 14, 2015

Thanks for the confirmation. I just opened up the GitHub URL in IE8, it won't load. So I guess we need to report this to GitHub directly. It does not seem to be a bug in curl.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 14, 2015

Member

Here is the confirmation: https://www.ssllabs.com/ssltest/analyze.html?d=github.com scroll down for "Handshake Simulation".

Here is Github's announcement on that: https://github.com/blog/1937-improving-github-s-ssl-setup
That is pretty crappy because they locked out all XP machines, very shortsighted.

I have dropped some lines to GitHub support, basically they have removed RC4 support from their servers which means that Schannel on XP cannot longer negotiate a usable cipher.

Member

michael-o commented May 14, 2015

Here is the confirmation: https://www.ssllabs.com/ssltest/analyze.html?d=github.com scroll down for "Handshake Simulation".

Here is Github's announcement on that: https://github.com/blog/1937-improving-github-s-ssl-setup
That is pretty crappy because they locked out all XP machines, very shortsighted.

I have dropped some lines to GitHub support, basically they have removed RC4 support from their servers which means that Schannel on XP cannot longer negotiate a usable cipher.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 14, 2015

Member

You might be SOL on this one. Github ciphers are all AES but XP x86 does not support AES. XP x64 and Windows Server 2003 same thing but one difference, there's an MS hotfix to add TLS_RSA_WITH_AES_256_CBC_SHA which is compatible with Github's servers.

Member

jay commented May 14, 2015

You might be SOL on this one. Github ciphers are all AES but XP x86 does not support AES. XP x64 and Windows Server 2003 same thing but one difference, there's an MS hotfix to add TLS_RSA_WITH_AES_256_CBC_SHA which is compatible with Github's servers.

@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder May 14, 2015

Member

XP with "native" crypto is doomed to have lots of problems with the modern web already. I would strongly urge anyone still on XP to use a modern crypto library with support for updated cryptos so that you can speak with the ever growing part of the Internet that is using stricter TLS requirements.

Member

bagder commented May 14, 2015

XP with "native" crypto is doomed to have lots of problems with the modern web already. I would strongly urge anyone still on XP to use a modern crypto library with support for updated cryptos so that you can speak with the ever growing part of the Internet that is using stricter TLS requirements.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 14, 2015

Member

@jay, do you think that we could make SSPI tell us that cipher could not be negotiated? The response now does not really help.

@bagder, I agree on that. I stumbled upon this while trying to access ASF Git repos. Curl fails over HTTP with TLS. Something is wrong/incomplete the the ca-bundle. I have even tried this one from master. No avail.

Member

michael-o commented May 14, 2015

@jay, do you think that we could make SSPI tell us that cipher could not be negotiated? The response now does not really help.

@bagder, I agree on that. I stumbled upon this while trying to access ASF Git repos. Curl fails over HTTP with TLS. Something is wrong/incomplete the the ca-bundle. I have even tried this one from master. No avail.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 15, 2015

Member

do you think that we could make SSPI tell us that cipher could not be negotiated? The response now does not really help.

There's a mapping here that shows for what TLS/SSL alerts schannel will return SEC_E_ILLEGAL_MESSAGE. I can't find in the schannel doc how to get the alert information. @mback2k any idea?

I stumbled upon this while trying to access ASF Git repos. Curl fails over HTTP with TLS. Something is wrong/incomplete the the ca-bundle. I have even tried this one from master. No avail.

I doubt that has to do with the ca-bundle.

git-wip-us.apache.org sends the entire certificate chain to the client. You can see those certificates either in Wireshark or openssl s_client -showcerts -connect git-wip-us.apache.org:443 or copy them from here. *Edit: Apache fixed the issue so the old VeriSign certificate is no longer available this way. At the end of this post there is a link that has the old certificate. *

The root CA apache sends VeriSign Class 3 Public Primary Certification Authority - G5 is different from the certificate of the same name in the ca-bundle. Both certificates have the same key and subject:

CN = VeriSign Class 3 Public Primary Certification Authority - G5
OU = (c) 2006 VeriSign, Inc. - For authorized use only
OU = VeriSign Trust Network
O = VeriSign, Inc.
C = US

The issuer for the ca-bundle one is the same as the subject, as one would expect. However check out the issuer for the one send by the apache website:

OU = Class 3 Public Primary Certification Authority
O = VeriSign, Inc.
C = US

:(

If I make a bundle with just these two:
Symantec Class 3 Secure Server CA - G4
VeriSign Class 3 Public Primary Certification Authority - G5 (the ca-bundle one)
I can use it to successfully verify the server certificate:

cat "VeriSign from mozilla bundle.cer" "Symantec from git-wip-us.apache.org.cer" > both.cer
openssl verify -CAfile both.cer -verbose -purpose any "Server - git-wip-us.apache.org.cer"
Server - git-wip-us.apache.org.cer: OK

Try with the VeriSign one sent by the server and it fails...

C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
error 2 at 2 depth lookup:unable to get issuer certificate

So my guess is OpenSSL is setup to work so that the CA sent by the server trumps any preloaded.

Certificates also available here if you're unable to reproduce.

Member

jay commented May 15, 2015

do you think that we could make SSPI tell us that cipher could not be negotiated? The response now does not really help.

There's a mapping here that shows for what TLS/SSL alerts schannel will return SEC_E_ILLEGAL_MESSAGE. I can't find in the schannel doc how to get the alert information. @mback2k any idea?

I stumbled upon this while trying to access ASF Git repos. Curl fails over HTTP with TLS. Something is wrong/incomplete the the ca-bundle. I have even tried this one from master. No avail.

I doubt that has to do with the ca-bundle.

git-wip-us.apache.org sends the entire certificate chain to the client. You can see those certificates either in Wireshark or openssl s_client -showcerts -connect git-wip-us.apache.org:443 or copy them from here. *Edit: Apache fixed the issue so the old VeriSign certificate is no longer available this way. At the end of this post there is a link that has the old certificate. *

The root CA apache sends VeriSign Class 3 Public Primary Certification Authority - G5 is different from the certificate of the same name in the ca-bundle. Both certificates have the same key and subject:

CN = VeriSign Class 3 Public Primary Certification Authority - G5
OU = (c) 2006 VeriSign, Inc. - For authorized use only
OU = VeriSign Trust Network
O = VeriSign, Inc.
C = US

The issuer for the ca-bundle one is the same as the subject, as one would expect. However check out the issuer for the one send by the apache website:

OU = Class 3 Public Primary Certification Authority
O = VeriSign, Inc.
C = US

:(

If I make a bundle with just these two:
Symantec Class 3 Secure Server CA - G4
VeriSign Class 3 Public Primary Certification Authority - G5 (the ca-bundle one)
I can use it to successfully verify the server certificate:

cat "VeriSign from mozilla bundle.cer" "Symantec from git-wip-us.apache.org.cer" > both.cer
openssl verify -CAfile both.cer -verbose -purpose any "Server - git-wip-us.apache.org.cer"
Server - git-wip-us.apache.org.cer: OK

Try with the VeriSign one sent by the server and it fails...

C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
error 2 at 2 depth lookup:unable to get issuer certificate

So my guess is OpenSSL is setup to work so that the CA sent by the server trumps any preloaded.

Certificates also available here if you're unable to reproduce.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 15, 2015

Member

There's a mapping here that shows for what TLS/SSL alerts schannel will return SEC_E_ILLEGAL_MESSAGE. I can't find in the schannel doc how to get the alert information.

Great, they map half a dozen of errors to one. 👎 ...Microsoft...

Member

michael-o commented May 15, 2015

There's a mapping here that shows for what TLS/SSL alerts schannel will return SEC_E_ILLEGAL_MESSAGE. I can't find in the schannel doc how to get the alert information.

Great, they map half a dozen of errors to one. 👎 ...Microsoft...

@stumped2

This comment has been minimized.

Show comment
Hide comment
@stumped2

stumped2 May 15, 2015

@jay is there anything I can change on ASF's webserver end to help with this?

When I got the cert from Symantec, that was the intermediate cert they said to use. But if there's something I can change, let me know and I can get a mock ssl site up for testing.

@jay is there anything I can change on ASF's webserver end to help with this?

When I got the cert from Symantec, that was the intermediate cert they said to use. But if there's something I can change, let me know and I can get a mock ssl site up for testing.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 15, 2015

Member

@stumped2 If you want to support both legacy clients (using the 2021 VeriSign cert) and newer clients (using the 2036 VeriSign cert) it looks like you'd have to supply the 2021 for legacy clients assuming they don't have it (remember 2021 is an intermediate and 2036 isn't), as you're currently doing. You may be able to change the ordering so that OpenSSL will handle it differently. This is a rare case where it actually may help to include a self-signed root CA in a chain file just to manipulate the ordering, but I don't know if that's acceptable.

For example if I order it so the 2036 is before the 2021:

cat "VeriSign from mozilla bundle.cer" "VeriSign from git-wip-us.apache.org.cer" "Symantec from git-wip-us.apache.org.cer" > three.cer
openssl verify -CAfile three.cer -verbose -purpose any "Server - git-wip-us.apache.org.cer"
Server - git-wip-us.apache.org.cer: OK

But will that work client side when they have certificates that are preloaded? And will that break legacy clients? You'd have to setup a server to test all scenarios. If it were me I'd probably remove the 2021 version from the chain file (I assume SSLCertificateChainFile or similar) and see who protests.

I don't see anything wrong with the Symantec intermediate. If Symantec gave you the chain file I suggest you take it up with them. If you look at their CA root advisory page you can see it specifies the 2036 version of the VeriSign certificate (the one in the Mozilla ca-bundle) not the 2021. 2021 version goes back to 'Class 3 Public Primary Certification Authority' which is an old certificate that uses md2 as signature hash and md2 has been disabled for a long while in OpenSSL, GnuTLS. Also see https://ssltest2.bbtest.net/ . There's a nice explanation on the difference between the two VeriSign certs here.

Edit: (2015-05-28) Please note Apache has since chosen to fix the issue by removing the 2021 version from the server supplied chain. It is unknown whether or not my idea above works. I've since traced this issue back to OpenSSL. If you have a similar issue and for the latest information please refer to OpenSSL RT 2634 and 3261.

Member

jay commented May 15, 2015

@stumped2 If you want to support both legacy clients (using the 2021 VeriSign cert) and newer clients (using the 2036 VeriSign cert) it looks like you'd have to supply the 2021 for legacy clients assuming they don't have it (remember 2021 is an intermediate and 2036 isn't), as you're currently doing. You may be able to change the ordering so that OpenSSL will handle it differently. This is a rare case where it actually may help to include a self-signed root CA in a chain file just to manipulate the ordering, but I don't know if that's acceptable.

For example if I order it so the 2036 is before the 2021:

cat "VeriSign from mozilla bundle.cer" "VeriSign from git-wip-us.apache.org.cer" "Symantec from git-wip-us.apache.org.cer" > three.cer
openssl verify -CAfile three.cer -verbose -purpose any "Server - git-wip-us.apache.org.cer"
Server - git-wip-us.apache.org.cer: OK

But will that work client side when they have certificates that are preloaded? And will that break legacy clients? You'd have to setup a server to test all scenarios. If it were me I'd probably remove the 2021 version from the chain file (I assume SSLCertificateChainFile or similar) and see who protests.

I don't see anything wrong with the Symantec intermediate. If Symantec gave you the chain file I suggest you take it up with them. If you look at their CA root advisory page you can see it specifies the 2036 version of the VeriSign certificate (the one in the Mozilla ca-bundle) not the 2021. 2021 version goes back to 'Class 3 Public Primary Certification Authority' which is an old certificate that uses md2 as signature hash and md2 has been disabled for a long while in OpenSSL, GnuTLS. Also see https://ssltest2.bbtest.net/ . There's a nice explanation on the difference between the two VeriSign certs here.

Edit: (2015-05-28) Please note Apache has since chosen to fix the issue by removing the 2021 version from the server supplied chain. It is unknown whether or not my idea above works. I've since traced this issue back to OpenSSL. If you have a similar issue and for the latest information please refer to OpenSSL RT 2634 and 3261.

@stumped2

This comment has been minimized.

Show comment
Hide comment
@stumped2

stumped2 May 15, 2015

Thanks @jay! I'll read up on this over the weekend and test some things out.

Thanks @jay! I'll read up on this over the weekend and test some things out.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 16, 2015

Member

@michael-o I found that Windows XP has a sha1RSA version of Class 3 Public Primary Certification Authority. You should be able to use it as the CA file until the ASF issue is resolved. Tested:

curl -v --cacert "VeriSign legacy CA - sha1RSA.cer" "https://git-wip-us.apache.org/repos/asf?p=flex-utilities.git"
curl 7.39.0 (i386-pc-win32) libcurl/7.39.0 OpenSSL/1.0.0r zlib/1.2.8 libidn/1.18
 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp
rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN Largefile SSPI SPNEGO NTLM SSL libz
Member

jay commented May 16, 2015

@michael-o I found that Windows XP has a sha1RSA version of Class 3 Public Primary Certification Authority. You should be able to use it as the CA file until the ASF issue is resolved. Tested:

curl -v --cacert "VeriSign legacy CA - sha1RSA.cer" "https://git-wip-us.apache.org/repos/asf?p=flex-utilities.git"
curl 7.39.0 (i386-pc-win32) libcurl/7.39.0 OpenSSL/1.0.0r zlib/1.2.8 libidn/1.18
 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp
rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN Largefile SSPI SPNEGO NTLM SSL libz

@jay jay added the SSL/TLS label May 16, 2015

@mback2k

This comment has been minimized.

Show comment
Hide comment
@mback2k

mback2k May 19, 2015

Member

@jay I don't know about any way to access the alert code using the SCannel APIs. According to this MSDN blog post the alert information is written to the system event log. This means it might be possible to extract that information from there. I think that would probably be quite fragile.

Member

mback2k commented May 19, 2015

@jay I don't know about any way to access the alert code using the SCannel APIs. According to this MSDN blog post the alert information is written to the system event log. This means it might be possible to extract that information from there. I think that would probably be quite fragile.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 19, 2015

Member

Thanks for checking Marc, unfortunately I agree. I think the best I can do here is in Curl_sspi_strerror append some text to the detail for SEC_E_ILLEGAL_MESSAGE that says something like "For error detail enable Schannel EventLogging in Windows." That way at least the user will know more detail can be made available in the event log.

Member

jay commented May 19, 2015

Thanks for checking Marc, unfortunately I agree. I think the best I can do here is in Curl_sspi_strerror append some text to the detail for SEC_E_ILLEGAL_MESSAGE that says something like "For error detail enable Schannel EventLogging in Windows." That way at least the user will know more detail can be made available in the event log.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 20, 2015

Member

@jay, @mback2k, I was not able to get that message in the event log. I have enabled debug logging on Windows XP with the value 0x3 and called curl against GitHub. No avail.

Is there anything one needs to observe?

Member

michael-o commented May 20, 2015

@jay, @mback2k, I was not able to get that message in the event log. I have enabled debug logging on Windows XP with the value 0x3 and called curl against GitHub. No avail.

Is there anything one needs to observe?

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 20, 2015

Member

I was not able to get that message in the event log. I have enabled debug logging on Windows XP with the value 0x3 and called curl against GitHub. No avail.

@michael-o more bad news for you. Empirical testing just now shows a lack of recorded alert messages to the System event log, particularly in the case of SEC_E_ILLEGAL_MESSAGE. This is not specific to curl; I get the same behavior with IE. (side note: some versions of IE may fallback to TLS 1.0 in case of SEC_E_ILLEGAL_MESSAGE and may make a successful connection depending on the server, but not in your case).

I'm not sure what the criteria is for recording alert messages, I can't find it documented. I tried several servers where the client hello causes a return of alert SSL3_ALERT_UNEXPECTED_MESSAGE (10) instead of a sever hello, but in no case does it show in my logs. I cannot find any evidence that alert is recorded client-side though some web searches show it can be recorded server-side. I tried Windows XP, 7 and 8. I could see in Wireshark that the alert was sent back always when I expected. I have all logging enabled (warn, error, info) for Schannel.

If you want to test if Schannel error logging is working (I doubt this is the problem though) try https://kuix.de:9455/ . You should see error TLS1_ALERT_UNKNOWN_CA (48) recorded in the event log.

So we're back where we were yesterday. The only other thing I can think of is we parse it out of the recv data, but that seems like it would be a lot of work and personally I don't think it's worthwhile. I'm strongly leaning towards closing this by having a helpful error message accompany SEC_E_ILLEGAL_MESSAGE, and that's all.

Member

jay commented May 20, 2015

I was not able to get that message in the event log. I have enabled debug logging on Windows XP with the value 0x3 and called curl against GitHub. No avail.

@michael-o more bad news for you. Empirical testing just now shows a lack of recorded alert messages to the System event log, particularly in the case of SEC_E_ILLEGAL_MESSAGE. This is not specific to curl; I get the same behavior with IE. (side note: some versions of IE may fallback to TLS 1.0 in case of SEC_E_ILLEGAL_MESSAGE and may make a successful connection depending on the server, but not in your case).

I'm not sure what the criteria is for recording alert messages, I can't find it documented. I tried several servers where the client hello causes a return of alert SSL3_ALERT_UNEXPECTED_MESSAGE (10) instead of a sever hello, but in no case does it show in my logs. I cannot find any evidence that alert is recorded client-side though some web searches show it can be recorded server-side. I tried Windows XP, 7 and 8. I could see in Wireshark that the alert was sent back always when I expected. I have all logging enabled (warn, error, info) for Schannel.

If you want to test if Schannel error logging is working (I doubt this is the problem though) try https://kuix.de:9455/ . You should see error TLS1_ALERT_UNKNOWN_CA (48) recorded in the event log.

So we're back where we were yesterday. The only other thing I can think of is we parse it out of the recv data, but that seems like it would be a lot of work and personally I don't think it's worthwhile. I'm strongly leaning towards closing this by having a helpful error message accompany SEC_E_ILLEGAL_MESSAGE, and that's all.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 20, 2015

Member

So we're back where we were yesterday. The only other thing I can think of is we parse it out of the recv data, but that seems like it would be a lot of work and personally I don't think it's worthwhile. I'm strongly leaning towards closing this by having a helpful error message accompany SEC_E_ILLEGAL_MESSAGE, and that's all.

All I can do here is: agree. Microsoft gives us, again, pain in the ass. SSPI is too high-level for this.

Member

michael-o commented May 20, 2015

So we're back where we were yesterday. The only other thing I can think of is we parse it out of the recv data, but that seems like it would be a lot of work and personally I don't think it's worthwhile. I'm strongly leaning towards closing this by having a helpful error message accompany SEC_E_ILLEGAL_MESSAGE, and that's all.

All I can do here is: agree. Microsoft gives us, again, pain in the ass. SSPI is too high-level for this.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o May 20, 2015

Member

@jay, maybe we could add here another row showing that that TLS impl gives reasonable messages back.

Member

michael-o commented May 20, 2015

@jay, maybe we could add here another row showing that that TLS impl gives reasonable messages back.

jay added a commit that referenced this issue May 22, 2015

strerror: Change SEC_E_ILLEGAL_MESSAGE description
Prior to this change the description for SEC_E_ILLEGAL_MESSAGE was OS
and language specific, and invariably translated to something not very
helpful like: "The message received was unexpected or badly formatted."

Bug: #267
Reported-by: Michael Osipov

@jay jay self-assigned this May 22, 2015

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay May 22, 2015

Member

I changed the description for SEC_E_ILLEGAL_MESSAGE in 995c600. Here is an example of what the output looks like now:

curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAG
E (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is receive
d (e.g. handshake failed). More detail may be available in the Windows System ev
ent log.

I'm limited to about 200 characters so I can't add anything else to the text.

maybe we could add here another row showing that that TLS impl gives reasonable messages back

@michael-o I don't think that's necessary, the new error message should be enough.

Member

jay commented May 22, 2015

I changed the description for SEC_E_ILLEGAL_MESSAGE in 995c600. Here is an example of what the output looks like now:

curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAG
E (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is receive
d (e.g. handshake failed). More detail may be available in the Windows System ev
ent log.

I'm limited to about 200 characters so I can't add anything else to the text.

maybe we could add here another row showing that that TLS impl gives reasonable messages back

@michael-o I don't think that's necessary, the new error message should be enough.

@jay jay closed this May 22, 2015

@mback2k

This comment has been minimized.

Show comment
Hide comment
@mback2k

mback2k May 24, 2015

Member

Thanks a lot, @jay.

Member

mback2k commented May 24, 2015

Thanks a lot, @jay.

jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Jun 30, 2015

spz
update of curl to version 7.43.0. Upstream RELEASE_NOTES:
Curl and libcurl 7.43.0

 Public curl releases:         147
 Command line options:         176
 curl_easy_setopt() options:   219
 Public functions in libcurl:  58
 Contributors:                 1291

This release includes the following changes:

 o Added CURLOPT_PROXY_SERVICE_NAME[11]
 o Added CURLOPT_SERVICE_NAME[12]
 o New curl option: --proxy-service-name[13]
 o Mew curl option: --service-name [14]
 o New curl option: --data-raw [5]
 o Added CURLOPT_PIPEWAIT [15]
 o Added support for multiplexing transfers using HTTP/2, enable this
   with the new CURLPIPE_MULTIPLEX bit for CURLMOPT_PIPELINING [16]
 o HTTP/2: requires nghttp2 1.0.0 or later
 o scripts: add zsh.pl for generating zsh completion
 o curl.h: add CURL_HTTP_VERSION_2

This release includes the following bugfixes:

 o CVE-2015-3236: lingering HTTP credentials in connection re-use [30]
 o CVE-2015-3237: SMB send off unrelated memory contents [31]
 o nss: fix compilation failure with old versions of NSS [1]
 o curl_easy_getinfo.3: document 'internals' in CURLINFO_TLS_SESSION
 o schannel.c: Fix possible SEC_E_BUFFER_TOO_SMALL error
 o Curl_ossl_init: load builtin modules [2]
 o configure: follow-up fix for krb5-config [3]
 o sasl_sspi: Populate domain from the realm in the challenge [4]
 o netrc: support 'default' token
 o README: convert to UTF-8
 o cyassl: Implement public key pinning
 o nss: implement public key pinning for NSS backend
 o mingw build: add arch -m32/-m64 to LDFLAGS
 o schannel: Fix out of bounds array [6]
 o configure: remove autogenerated files by autoconf
 o configure: remove --automake from libtoolize call
 o acinclude.m4: fix shell test for default CA cert bundle/path
 o schannel: fix regression in schannel_recv [7]
 o openssl: skip trace outputs for ssl_ver == 0 [8]
 o gnutls: properly retrieve certificate status
 o netrc: Read in text mode when cygwin [9]
 o winbuild: Document the option used to statically link the CRT [10]
 o FTP: Make EPSV use the control IP address rather than the original host
 o FTP: fix dangling conn->ip_addr dereference on verbose EPSV
 o conncache: keep bundles on host+port bases, not only host names
 o runtests.pl: use 'h2c' now, no -14 anymore
 o curlver: introducing new version number (checking) macros
 o openssl: boringssl build brekage, use SSL_CTX_set_msg_callback [17]
 o CURLOPT_POSTFIELDS.3: correct variable names [18]
 o curl_easy_unescape.3: update RFC reference [19]
 o gnutls: don't fail on non-fatal alerts during handshake
 o testcurl.pl: allow source to be in an arbitrary directory
 o CURLOPT_HTTPPROXYTUNNEL.3: only works with a HTTP proxy
 o SSPI-error: Change SEC_E_ILLEGAL_MESSAGE description [20]
 o parse_proxy: switch off tunneling if non-HTTP proxy [21]
 o share_init: fix OOM crash
 o perl: remove subdir, not touched in 9 years
 o CURLOPT_COOKIELIST.3: Add example
 o CURLOPT_COOKIE.3: Explain that the cookies won't be modified [22]
 o CURLOPT_COOKIELIST.3: Explain Set-Cookie without a domain [23]
 o FAQ: How do I port libcurl to my OS?
 o openssl: Use TLS_client_method for OpenSSL 1.1.0+
 o HTTP-NTLM: fail auth on connection close instead of looping [24]
 o curl_setup: Add macros for FOPEN_READTEXT, FOPEN_WRITETEXT [25]
 o curl_getdate.3: update RFC reference
 o curl_multi_info_read.3: added example
 o curl_multi_perform.3: added example
 o curl_multi_timeout.3: added example
 o cookie: Stop exporting any-domain cookies [26]
 o openssl: remove dummy callback use from SSL_CTX_set_verify()
 o openssl: remove SSL_get_session()-using code
 o openssl: removed USERDATA_IN_PWD_CALLBACK kludge
 o openssl: removed error string #ifdef
 o openssl: Fix verification of server-sent legacy intermediates [27]
 o docs: man page indentation and syntax fixes
 o docs: Spelling fixes
 o fopen.c: fix a few compiler warnings
 o CURLOPT_OPENSOCKETFUNCTION: return error at once [28]
 o schannel: Add support for optional client certificates
 o build: Properly detect OpenSSL 1.0.2 when using configure
 o urldata: store POST size in state.infilesize too [29]
 o security:choose_mech remove dead code
 o rtsp_do: remove dead code
 o docs: many HTTP URIs changed to HTTPS
 o schannel: schannel_recv overhaul [32]

This release includes the following known bugs:

 o see docs/KNOWN_BUGS (http://curl.haxx.se/docs/knownbugs.html)

This release would not have looked like this without help, code, reports and
advice from friends like these:

  Alessandro Ghedini, Alexander Dyagilev, Anders Bakken, Anthony Avina,
  Ashish Shukla, Bert Huijben, Brian Chrisman, Brian Prodoehl, Chris Araman,
  Dagobert Michelsen, Dan Fandrich, Daniel Melani, Daniel Stenberg,
  Dmitry Eremin-Solenikov, Drake Arconis, Egon Eckert, Frank Meier, Fred Stluka,
  Gisle Vanem, Grant Pannell, Isaac Boukris, Jens Rantil, Joel Depooter,
  Kamil Dudka, Linus Nielsen Feltzing, Linus Nielsen Feltzing Feltzing,
  Liviu Chircu, Marc Hoersken, Michael Osipov, Oren Souroujon, Orgad Shaneh,
  Patrick Monnerat, Patrick Rapin, Paul Howarth, Paul Oliver, Rafayel Mkrtchyan,
  Ray Satiro, Sean Boudreau, Tatsuhiro Tsujikawa, Tomas Tomecek, Viktor Szakáts,
  Ville Skyttä, Yehezkel Horowitz,
  (43 contributors)

        Thanks! (and sorry if I forgot to mention someone)

References to bug reports and discussions on issues:

 [1] = http://curl.haxx.se/mail/lib-2015-04/0095.html
 [2] = curl/curl#206
 [3] = curl/curl@5b66860#commitcomment-10473445
 [4] = curl/curl#141
 [5] = curl/curl#198
 [6] = http://curl.haxx.se/mail/lib-2015-04/0199.html
 [7] = curl/curl#244
 [8] = curl/curl#219
 [9] = curl/curl#258
 [10] = curl/curl#254
 [11] = http://curl.haxx.se/libcurl/c/CURLOPT_PROXY_SERVICE_NAME.html
 [12] = http://curl.haxx.se/libcurl/c/CURLOPT_SERVICE_NAME.html
 [13] = http://curl.haxx.se/docs/manpage.html#--proxy-service-name
 [14] = http://curl.haxx.se/docs/manpage.html#--service-name
 [15] = http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html
 [16] = http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html
 [17] = curl/curl#275
 [18] = curl/curl#281
 [19] = curl/curl#282
 [20] = curl/curl#267
 [21] = http://curl.haxx.se/mail/lib-2015-05/0056.html
 [22] = http://curl.haxx.se/mail/lib-2015-05/0115.html
 [23] = http://curl.haxx.se/mail/lib-2015-05/0137.html
 [24] = curl/curl#256
 [25] = curl/curl#258 (comment)
 [26] = curl/curl#292
 [27] = https://rt.openssl.org/Ticket/Display.html?id=3621&user=guest&pass=guest
 [28] = http://curl.haxx.se/mail/lib-2015-06/0047.html
 [29] = http://curl.haxx.se/mail/lib-2015-06/0019.html
 [30] = http://curl.haxx.se/docs/adv_20150617A.html
 [31] = http://curl.haxx.se/docs/adv_20150617B.html
 [32] = curl/curl#244

@vbrozik vbrozik referenced this issue in notepad-plus-plus/notepad-plus-plus Sep 24, 2015

Open

"Update Notepad++" does not work on Windows 2003 and older any more #967

jgsogo added a commit to jgsogo/curl that referenced this issue Oct 19, 2015

strerror: Change SEC_E_ILLEGAL_MESSAGE description
Prior to this change the description for SEC_E_ILLEGAL_MESSAGE was OS
and language specific, and invariably translated to something not very
helpful like: "The message received was unexpected or badly formatted."

Bug: curl#267
Reported-by: Michael Osipov
@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay Mar 25, 2018

Member

Github ciphers are all AES but XP x86 does not support AES. XP x64 and Windows Server 2003 same thing but one difference, there's an MS hotfix to add TLS_RSA_WITH_AES_256_CBC_SHA which is compatible with Github's servers.

An update on this, I've found github is still accessible with a fully updated Windows XP SP3 x86 with the POSReady key (the hack you can use to still receive security updates in XP). At some point in the last several months they updated the schannel for TLS 1.1 and TLS 1.2 support. Also contrary to my assertion that XP x86 doesn't support AES it does. I have snapshots from last year that are using AES.

Here's a ClientHello from curl 7.60.0-DEV w/schannel July 2017 updates snapshot:

    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 80
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 76
            Version: TLS 1.0 (0x0301)
            Random: 5ab70966941566189188d67646aad9e72543442142604546...
                GMT Unix Time: Mar 24, 2018 22:28:54.000000000 Eastern Daylight Time
                Random Bytes: 941566189188d67646aad9e72543442142604546a0c0e9fd...
            Session ID Length: 0
            Cipher Suites Length: 26
            Cipher Suites (13 suites)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
                Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
                Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 9
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0

and here's a ClientHello from curl 7.60.0-DEV w/schannel March 2018 updates snapshot:

    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 90
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 86
            Version: TLS 1.2 (0x0303)
            Random: 5ab708eb95b8ef97a43f4680f9d0105a81ab46b3d86fb3f1...
                GMT Unix Time: Mar 24, 2018 22:26:51.000000000 Eastern Daylight Time
                Random Bytes: 95b8ef97a43f4680f9d0105a81ab46b3d86fb3f137ac7d1f...
            Session ID Length: 0
            Cipher Suites Length: 20
            Cipher Suites (10 suites)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 25
            Extension: signature_algorithms (len=12)
                Type: signature_algorithms (13)
                Length: 12
                Signature Hash Algorithms Length: 10
                Signature Hash Algorithms (5 algorithms)
                    Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: SHA1 DSA (0x0202)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0

Background here. It seems to imply some registry keys need to be set to enable TLS 1.1 and 1.2 but I did not need to set those keys and they aren't set in the registry.

edit: I asked on technet about TLS 1.2 being enabled by default despite the lack of registry keys.

Member

jay commented Mar 25, 2018

Github ciphers are all AES but XP x86 does not support AES. XP x64 and Windows Server 2003 same thing but one difference, there's an MS hotfix to add TLS_RSA_WITH_AES_256_CBC_SHA which is compatible with Github's servers.

An update on this, I've found github is still accessible with a fully updated Windows XP SP3 x86 with the POSReady key (the hack you can use to still receive security updates in XP). At some point in the last several months they updated the schannel for TLS 1.1 and TLS 1.2 support. Also contrary to my assertion that XP x86 doesn't support AES it does. I have snapshots from last year that are using AES.

Here's a ClientHello from curl 7.60.0-DEV w/schannel July 2017 updates snapshot:

    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 80
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 76
            Version: TLS 1.0 (0x0301)
            Random: 5ab70966941566189188d67646aad9e72543442142604546...
                GMT Unix Time: Mar 24, 2018 22:28:54.000000000 Eastern Daylight Time
                Random Bytes: 941566189188d67646aad9e72543442142604546a0c0e9fd...
            Session ID Length: 0
            Cipher Suites Length: 26
            Cipher Suites (13 suites)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
                Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
                Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 9
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0

and here's a ClientHello from curl 7.60.0-DEV w/schannel March 2018 updates snapshot:

    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 90
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 86
            Version: TLS 1.2 (0x0303)
            Random: 5ab708eb95b8ef97a43f4680f9d0105a81ab46b3d86fb3f1...
                GMT Unix Time: Mar 24, 2018 22:26:51.000000000 Eastern Daylight Time
                Random Bytes: 95b8ef97a43f4680f9d0105a81ab46b3d86fb3f137ac7d1f...
            Session ID Length: 0
            Cipher Suites Length: 20
            Cipher Suites (10 suites)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 25
            Extension: signature_algorithms (len=12)
                Type: signature_algorithms (13)
                Length: 12
                Signature Hash Algorithms Length: 10
                Signature Hash Algorithms (5 algorithms)
                    Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: SHA1 DSA (0x0202)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0

Background here. It seems to imply some registry keys need to be set to enable TLS 1.1 and 1.2 but I did not need to set those keys and they aren't set in the registry.

edit: I asked on technet about TLS 1.2 being enabled by default despite the lack of registry keys.

@curl curl locked as resolved and limited conversation to collaborators Jun 23, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.