Prevention of «Could not create SSL/TLS secure channel»

[Boris-Ockham]

When RadioDownloader is used on for example Windows 8.1 then there are some podcast-feeds which can't be loaded because of a cipher suite mismatch. The problem is that .NET uses Schannel of Windows which has cipher suites depending on the operating system. See Cipher Suites in TLS/SSL (Schannel SSP). Browsers, except for Internet Explorer, don't have that problem because they use their own technology for setting up TLS/SSL-channels.

I expect that there is no cheap or easy solution for this problem. In Adding Cipher suite to TLS1.2 of HttpClient of dotnetcore 3.1 someone suggests the use of the NuGet packet CurlThin as the solution. But there are probably more solutions.

On Windows 10 TLS 1.3 is available (and in the browsers on Windows 8.1). I'm not sure RadioDownloader will use TLS 1.3 when compiled with an older .NET Framework version than 4.8. TLS 1.2 probably will become obsolete soon, because its regarded as unsafe.

What exactly happens when a podcast can't be downloaded can be studied with wireshark. What cipher suits servers can use are listed by Qualys SSL Labs.

[ribbons]

Thanks for the report. #250 was caused by a very similar kind of issue but under Windows 7.

My general instinct on this is that as it isn't an issue on Windows 10, is a shortcoming in the .NET framework itself and that Windows 8.1 goes out of extended support in about 9 months time (Jan 10, 2023), I'm not really inclined to invest much effort in addressing the issue. I'd be happy to consider a PR as long as it didn't introduce an extra maintenance burden or introduce other issues though.

[Boris-Ockham]

You seem to use Windows 10. Does RadioDownloader use TLS 1.3 on this OS without recompiling to .NET Framework 4.8?

[ribbons]

I'm running Arch Linux actually, though I do have a Windows 10 VM I use for Windows-only stuff. I wouldn't expect TLS 1.3 only connections to be supported even under Windows 10 as Radio Downloader is targeting the .NET Framework 4.5.2.