WinHttpRequest now fails on Win10, but succeeds on Win11

110 views Asked by At

I have a legacy VB6 program that uses WinHttpRequest for communicating with an API from xeno-canto.org. It worked fine for years on various flavors of Windows. Then starting in or around Aug/Sep of 2023 it started to fail on Win10 only (on all Win10 systems I have access to test on). It still works fine on Win11. Not tested on other versions of Windows lately.

Here is the VB6 function if it helps.

Public Function DownloadByteArrayContentsFromURL(url As String, Optional IgnoreSSLErrors As Boolean = True) As Byte()
Const WinHttpRequestOption_SecureProtocols = 9
Const SecureProtocol_TLS1_2 = &H800
Dim http As New WinHttpRequest
Dim responseBytes(0) As Byte

On Error GoTo ErrHandler

'Documentation on Option property. https://learn.microsoft.com/en-us/windows/win32/winhttp/winhttprequestoption
If IgnoreSSLErrors Then
    http.Option(WinHttpRequestOption_SslErrorIgnoreFlags) = &H3300
End If

http.Open "GET", url, False
http.Send
If http.status = 200 Then DownloadByteArrayContentsFromURL = http.responseBody

Set http = Nothing

Exit Function

ErrHandler:

    Set http = Nothing
    UnexpectedHandledError Err.number, Err.description, "Utilities.DownloadByteArrayContentsFromURL()", url

End Function

On Win10 this will produce a "RTE -2147012739 - An error occurred in the secure channel support"

I have used PowerShell to issue the command on a Win10 machine with these results.

Invoke-WebRequest -Uri https://xeno-canto.org/api/2/recordings?query=Flammulated+Flycatcher%20q:A
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ Invoke-WebRequest -Uri https://xeno-canto.org/api/2/recordings?query= ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : 
WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

The same command works on Win11 in PowerShell.

And, this command, works on Win10 machines.

Invoke-WebRequest -Uri https://www.google.com 

If, instead, I issue the same xeno-canto API URI on the Win10 machine using the Chrome browser, it works and returns valid results.

I have tried rolling back all Windows updates to the time when it used to work with no change in the results. It still errors out.

So, it seems that...

  • it is limited to Win10 machines only
  • It involves WinHttpRequest (WinHttp.dll), as that is what my VB6 and PowerShell's Invoke-WebRequest use
  • And it seems to also involve only the xeno-canto.org API.
  • It doesn't seem to be tied to a recent Windows update; although it is possible I didn't rollback all changes for some reason.

Interesting set of symptoms.

I am looking for assistance in how to troubleshoot this further as I have exhausted all resources that I can find on the matter. Maybe a potential workaround that I can use to get Win10 to work again.

UPDATE: It appears that the folks at xeno-canto made a change to ONLY support TLS 1.3 about the time the problem started. Windows 10 does not support TLS 1.3 natively for its system-level components. This includes WinHttpRequest apparently. Xeno-canto also advises that this broke some other apps interfacing to their api as well as older browsers not supporting TLS 1.3.

So now the question becomes, what options are available to me in VB6 that give me access to http protocol using TLS 1.3 on Windows 10?

1

There are 1 answers

0
JJJones_3860 On

Now that we know the problem is due to

  • xeno-canto.org servers stopped support TLS prior to 1.3, and
  • Win10 does not natively support TLS 1.3

The solution seems to lie in one of these 3 options:

  1. xeno-canto continue supporting legacy versions of TLS
  2. Win10 releases an update in support of TLS 1.3
  3. My VB6 program uses something that can communicate using TLS 1.3; rather difficult. ActiveX add-on paid such as Chilkat; reverse proxy service, etc.

I am hoping for #1 or #2. So I consider this closed.