Could not create SSL/TLS secure channel Error

[BlueSky]

Just tried to run a scan on the site shown in the attached picture and got this SSL/TLS error.
https://www.dropbox.com/s/t9xc6ysy415956n/SSL-TLS-Error.png?dl=0

[BlueSky]

Image Url did not work, am attaching uploaded image

[BlueSky]

Forcing an old .NET application to support TLS 1.2 without recompiling it   

PS C:\windows\system32> Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version

PSChildName                      Version
-----------                      -------
v2.0.50727                       2.0.50727.4927
v3.0                             3.0.30729.4926
Windows Communication Foundation 3.0.4506.4926
Windows Presentation Foundation  3.0.6920.4902
v3.5                             3.5.30729.4926
Client                           4.8.04084
Full                             4.8.04084
Client                           4.0.0.0

[Richard Moss]

Hello,

Thanks for the report. WebCopy already supports TLS 1.2 but it doesn't yet support TLS 1.3 - that is planned for the next-but-one version (first a point release to resolve some bugs, then a major release to update to .NET 4.8 and add TLS 1.3 support). Trying to work around it with context switches probably won't work because WebCopy allows you to choose which protocols you want to support, so it always sets a value.

Some other points - firstly, the only URL from that scan which had the communication issue was a third party site linked by the main site.



Secondly, I did a test where I bumped to support TLS 1.3 and it still didn't work. Instead of "The request was aborted: Could not create SSL/TLS secure channel." I got "The client and server cannot communicate, because they do not possess a common algorithm".

Interestingly, I tried using cURL and it couldn't do it either: "curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.". This was logged as an OS level error, so I wonder if there's some ciphers disabled by default. Tested in Windows 10 Pro 22H2, so not that far out of date. More interestingly, Firefox is quite happy to load the page.





With a URL of `hacke.rs` it's almost inevitable they'll be doing something clever. WebCopy's crawl engine focuses on what to do with the content it downloads, it leaves encryption and networking to the framework, which works many nines most of the time so I don't have much I can offer at this point.

I need to do some more digging, but there's not much more to be done until TLS 1.3 support is added which won't be for a little while yet. Meanwhile I need to rethink why Quick Scan feels the need to display a blocking error message for a secondary site.

Regards;
Richard Moss

[BlueSky]

Richard,

Thanks for the in-depth dissection.   I did not notice that first url, the target website contains a trove of information on undocumented Microsoft protocols.  I am not a certficate, crptographic expert at all.  I just read that TLS is a subset of https.   I did try httrack, it works, except it doesn't replicate the html layout of the tree menu adjacent to the menu content, which is ok.

[Jimbo]

I have just encountered this error message using an existing Webcopy project which was working fine back on Feb 25.

From what Richard says, does:

... it doesn't yet support TLS 1.3

... sort of imply that the TLS version on the target site has been changed in the interim?



I'm no expert at all in this sort of thing. I Googled how to check a site's TLS level and one site that actually does work without generating that message is showing v 1.3 (see attachment).




The site that generates the error message has this:



They look the same to me. I am puzzled.