I know this topic has been covered comprehensively on SO and several other forums by now. I'm hoping someone can shed some light on my issue. TL;DR: I can get this script to see if a URL is valid when the server uses Tls1.2, but not a URL where the server uses Tls1.2 and Tls1.3.

I'm writing a script for a lowest common denominator audience (Win7, .NET Framework 4.8, WMF 3.0/4.0, all updates installed as of 12/2022) and part of the script checks to see if a given KB update has a support page and/or a MS update catalog download link using Invoke-WebRequest.

• I can successfully test https://www.catalog.update.microsoft.com/Search.aspx?q=KB2506143 to see if it has any download buttons.

  • This particular search result does not have any download buttons/links.
  • Initially I received a Could not create SSL/TLS secure channel error, but resolved this by including this in the script: [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor [System.Net.SecurityProtocolType]::Tls12

• I cannot test https://support.microsoft.com/en-us/kb/2506143 to see if the URL exists or not. I still receive the Could not create SSL/TLS secure channel error.

  • When I use [Net.ServicePointManager]::SecurityProtocol = 'Tls13' I get a different exception (expected on Win7):
    System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm

• Every other combination of SecurityProtol produces the SSL/TSL secure channel error message.

• support.microsoft.com looks like it uses Tls 1.2 and Tls 1.3.

• www.catalog.update.microsoft.com looks like it uses Tls 1.2 only.

I'm open to other methods simply to check if a URL exists in PowerShell 3.0/4.0 but have come up empty.

I'm certain I'm missing a crucial detail in terms of comparing both SSL reports. I assumed that I would be able to use Invoke-WebRequest using Windows 7 and Tls1.2 (with .NET 4.8 installed and after registry edits, etc) with both websites, but only the catalog URL is working for now. I tried a Win8.1 VM for kicks and got the same results - catalog URL works but the support URL still fails with the SSL/TLS secure channel error. This works on Windows 10 for me though.

What am I overlooking or missing (other than there are people/companies using Win7 that shouldn't be)?

CodePudding user response：

In this case, the issue is not about the TLS 1.2/1.3 Protocol it is about the Cipher Suites that are supported.

The TLS protocol supports many different methods for exchanging keys, encrypting data, and authenticating message integrity. As a Protocol, it defines how packets move between you and the server, the Cypher suites supported between both client and server, and how to select the encryption protocol. Earlier versions of the Protocol were susceptible to protocol related issues like Man-In-The-Middle attacks (and nothing related to encryption). TLS 1.2 (with certain Cipher Suites) is regarded as secure.

Protocols are like roads and highways. They have pavement, lines, and markings that allow cars and trucks to move from one point to the next. Earlier protocols didn't have protective guard rails, new ones now do.

Cipher Suites are like the cars and trucks. There are dozens of ways to encrypt a packet of data. Some have elliptic curves, some do not. Some have government level encryption with huge number of bits, some have less. Likewise some cars have no doors on them, and some trucks have 256bit steel reinforced doors on them. They both can go down the same protocol highway, but one of these is not secure.

In this case, the web server is saying that it allows both TLS 1.2 and 1.3 protocols (highways with guard rails). It is also saying that it only allows certain secure Cipher Suites that have not been deemed insecure (e.g. no cars without doors are allowed).

The Cipher Suites allowed on this site is:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp256r1 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   ECDH secp256r1 (eq. 3072 bits RSA)

Since new Cipher Suites are developed all the time, Windows 7, 8, and 8.1 while supporting the TLS 1.2 protocol don't have the newest developed Cipher Suites installed to actually know how to decrypt the packets (e.g. fancy new alien space ships are allowed to travel down the TLS 1.2 protocol highway, but your old school town doesn't know how to open one because you don't have the newest elliptical curve spanners). See Windows 7 Supported Cipher Suites.

In this case, the new Cipher Suites weren't developed and installed until Windows 10. See Windows 10 Supported Cipher Suites. Remember Windows 10 came out 10 years after Windows 7, so not having the latest technology is the situation here, and since it is out of mainstream support, it won't be fixed. Basically, this website will never be able to visit this particular website.