TLS version problem downloading mirrors.lst?

[Brad Wetmore]

Hi Brian, and thanks for the response.

Horray for conflicting information from MS.  🙂

I will look at the IIS tool mentioned in one of the posts.

My registry entries for SCHANNEL and the TLSv1.2 look to be the same between my previous Windows 2012 install and this new Windows 2016 one, so a little surprising.

Do you happen to know if the cygwin.com server hosting cygwin.com/mirrors.lst was recently upgraded to no longer support the earlier TLS versions?

Is mirrors.lst cached somewhere during the install, and where would I find it?  Just wondering why I can't seem to find it on different Windows instances but can still connect.

> Are any of them running legacy Server instances?

I think you are asking whether the mirror server (sonic.net) that I eventually contacted still has TLSv1.0 on.  Probably.  I can check that next week.

Thanks,

Brad





________________________________
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Sent: Friday, February 5, 2021 7:53 PM
To: cygwin@cygwin.com <cygwin@cygwin.com>
Subject: Re: TLS version problem downloading mirrors.lst?

On 2021-02-05 18:00, Brad Wetmore via Cygwin wrote:
> I am trying to install a new instance of cygwin on Windows 2016 Server MSDN instance and am having problems downloading the mirrors list:
>      2021/02/05 14:21:39 connection error: 12029 fetching https://cygwin.com/mirrors.lst
> Using Wireshark and configuration options in Firefox, the root cause appears
> to be that the setup-x86_64.exe is trying to use TLSv1.0 and SSLv3 to
> download this file, but the download is failing as the response is a fatal
> TLS alert: invalid protocol (2/70). Many Internet servers have been shutting
> off TLSv1.0/SSLv3 in favor of TLSv1.2/1.3 these days, is this a case of that?
> If so, the setup app needs to be updated.

Cygwin setup is a Windows app using Windows libraries built using open tools.

> I can specify a specific server URL after the mirrors.lst download fails and
> can at least get something installed.
> Is there any workaround to force setup-x86_64.exe to default to TLSv1.2/1.3?
> Or is this something that the MSDN version of Windows 2016 Server has
> configured?
> More details/symptoms:
> I am behind a firewall, but the proxy settings in IE allow me to tunnel out.
> The corresponding "Use System Proxy Settings" in Firefox works fine. But when
> I set the TLS settings in Firefox's "about:config" to use only TLSv1.0/SSLv3,
> I see the same alert being returned to Firefox.
> Wireshark reports:
> CONNECT cygwin.com:443 HTTP1.0 ->
> User-Agent: ...deleted
> <- HTTP/1.0 200 Connection established
> ClientHello ->
> v1.0
> <- Fatal Alert: 2/70
> Supposedly SCHANNEL has TLSv1.2 on by default, but have no idea how the
> setup app is written.

*NOT* by default on W2016 for SCHANNEL and may need enabled for both CLIENT and
SERVER uses:

https://github.com/MicrosoftDocs/windowsserverdocs/issues/2783

https://social.technet.microsoft.com/Forums/en-US/cb1a695b-a15c-4fa7-94f0-1aaa20c1279d/enabling-tls-12-on-windows-server-2012-amp-2016?forum=winserversecurity

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs#enable-and-disable-tls-12

Cygwin setup is written like most other Windows GUI apps, but you can clone the
sources, modify, and build it using only Cygwin tools.

> https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-
> https://docs.microsoft.com/en-us/archive/blogs/kaushal/support-for-ssltls-protocols-on-windows

> My previous installs of cygwin aren't having any problems when trying to
> incrementally add software, maybe the mirrors file is cached somewhere?

Are any of them running legacy Server instances?

> Thanks for any tips,

It's possible that W2016 might not support the root CA, support available TLS
1.2 Cipher suites (although that seems unlikely with the WEAK ratings), TLS 1.3,
HTTP2, etc:

        https://www.ssllabs.com/ssltest/analyze.html?d=cygwin.com

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]