TRESTClient Security Error 12175 following Windows Update

[Andrew Spencer 2]

A very simple Delphi application (with TRESTClient, TRESTResponse and TRESTRequest) configured for a GET operation to our server fails after the most recent Windows 10 update (KB5018410 rolled out on 10 October 2022). It reports 'Error sending data: (12175) A security error occurred'. Rolling back the update works again.

 

The URL that I am testing is https://yams.ked.co.za/version

Insomnia, Firefox, Chrome, Edge and other clients have no problems with the polling.

Any advice would be very much appreciated
 

[Brian Evans 105]

 TLS 1.0/1.1 are now disabled by default starting with this month's patch (Oct 2022). They were already disabled in some editions of Windows.

 

TLS Security Settings fails after October 2022 Patch - Microsoft Community

Windows 10: Beware of a possible TLS disaster on October 2022 patchday | Born's Tech and Windows World (borncity.com)

 

Not sure why it stopped working however - just checked and your server offers just TLS 1.2 and TLS 1.3 so the older protocols should not be in use anyway. 

Edited October 13, 2022 by Brian Evans

[Andrew Spencer 2]

It seems to me, after some sniffing with WireShark, that TLS1.2 is not available following the KB5018410 roll-out.

TLS1.3 protocols are being used by Insomnia, Firefox etc requests. The Delphi TRESTClient/TRESTRequest/TRESTResponse suite, however, seems to be stuck on TLS1.2. I have tried setting SecureProtocols parameters in TRESTClient (which are unchecked by default), but this has made no difference.

I made a quick change of my simple application to use the ICS TSslHttpRest component. Not having used it before and hardly knowing how to use it, I could quickly see that it is reaching our server and polling the above URL correctly. However, it is definitely not going to be viable/quick to change our application's usage of the TRESTxxxxxx components to the ICS component.

 

It seems to me that the TRESTClient (?) component is not performing correctly.

 

I've attached my test project

SimpleREST.zip

[Brian Evans 105]

Main system: Windows 11 Pro 22H2. using Delphi 11.2 patch 1 the minimal application retrieves the response without issue.

Run exe on Windows 10 without update KB5018410 send request works.

Run exe on Windows 10 with update KB5018410 send request fails.

 

I did notice that Internet Options for Windows 10 has TLS 1.3 not checked by default and it says (experimental) after it. Windows 11 has it checked by default without the (experimental) tag.

Search for Internet options in start menu and it should come up as a control panel result, TLS selections are near the bottom on the Advanced tab.

 

No combination of settings gets it to work again on a patched Windows 10 system (KB5018410). There is some weird interaction between the patch and Delphi REST components it seems. It breaks TLS 1.2 somehow and TLS 1.3 isn't functional either. 

 

Images below: Windows 10 before patch, Windows 11 22H2 and Windows 10 after patch. 

 

 

Edited October 14, 2022 by Brian Evans

[Andrew Spencer 2]

Hi Brian
I agree with what you have found. I am running Delphi 11.2 patch 1 and Windows 10. This problem has also been seen under Delphi 10.4.2.

As with your tests, I get no operations with any variation of the Internet Properties "Use TLS x.y" checkboxes.

 

It sounds as if this should be raised on the Delphi bug website

[Angus Robertson 574]

It's possible that changing the SSL version tick boxes might require a reboot to be effective, that is certainly the case when you change SSL protocol settings such as ciphers in the registry or using Powershell. 

 

Angus

 

[Lajos Juhász 293]

What happends when you change the SecureProtocols property on the request?

Edited October 14, 2022 by Lajos Juhász

[Paul TOTH 2]

Hello,

 

it seems that curl did fix the problem
https://github.com/curl/curl/blob/master/lib/vtls/schannel.c#L223

I can read the site with curl, but my SChannel component fails 
https://github.com/tothpaul/Delphi/tree/master/Indy.SChannel

I did not found the time to look at their code

 

Edited October 14, 2022 by Paul TOTH

[Andrew Spencer 2]

I have tried to use the SecureProtocols property of TRESTClient, but it makes no difference. (In the large application that had been working fine till KB5018410 came around, I used the default, which is none of these protocols ticked)

I have also tried various options (with rebooting) in the Control Panel -> Internet Options -> Advanced -> Security -> Use TLS x.x
It did not change anything.

I agree with Brian Evans' comment, above " No combination of settings gets it to work again on a patched Windows 10 system (KB5018410). There is some weird interaction between the patch and Delphi REST components it seems. It breaks TLS 1.2 somehow and TLS 1.3 isn't functional either."

A WireShark capture, trying to access our site, shows TLS1.2 attempts, but results in a 12175 in the Delphi Application

 

Insomnia, by contrast moves to TLS1.3

 

My application is attached.

SimpleREST.zip

[Uwe Raabe 2057]

Currently removing the Windows Update seems the only solution.

[Andrew Spencer 2]

Does anyone have advice on an alternative for the TRESTClient / TRESTRequest / TRESTResponse set of Embarcadero components?

I have found that the ICS TSslHttpRest component does work (and uses TLS1.3), but the lack of documentation and sample code, and the odd handling of JSON mean that committing to replace all Embarcadero TRESTxxxxx operations in my code may be overly risky.

The best would be a well-supported, documented (commercial) solution (or a component fix from Embarcadero!)

 

Rolling back the Windows update is not going to be a good solution for large corporate clients spread all around the world!

Edited October 14, 2022 by Andrew Spencer

[Uwe Raabe 2057]

I managed to get it working with the following steps:

1. In the registry add a subkey to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols named "TLS 1.3"
2. Add another subkey to this new key named "Client"
3. Add a DWORD to the Client key named "Enabled" with Value = 1
4. Add another DWORD to the Client key named "DisabledByDefault" with Value = 0
5. In the TRESTClient component of your example enable TLS13 in SecureProtocols

 

Edit: You need to restart Windows to make the registry settings active.

 

Edited October 14, 2022 by Uwe Raabe

[Angus Robertson 574]

Just done some testing using the D11.2 TRESTClient component on Windows 11 Enterprise 22H2  fully updated,

 

It seems all TLS protocols are still available to the client.  I have servers built with the ICS web server component that can report the TLS client hello packet that tells the server what protocols the client can accept.  The URL is https://api2.telecom-tariffs.co.uk/serverinfo.htm  which returns an information page about the server and client connected, for the TRESTClient with all TLS boxes ticked the Hello starts with:

 

Client Hello: Server Name: api2.telecom-tariffs.co.uk, ALPN: , Versions: TLSv1.2, TLSv1.3, TLSv1.2, TLSv1.1, TLSv1.0, TLSv1.3 Key Share Data

 

which means all four protocols are accepted, ticking just TLS12 and only that protocol appears in the Hello, and works.  Windows 11 also connects with TLS/1.3 if requested, without registry patches.  However, I may have previously done the patches two years ago when first testing TLS/1.3.  I do hack the PC a lot, currently Edge and Windows File Explorer are dead with exceptions.

 

Angus

 

[Uwe Raabe 2057]

7 minutes ago, Angus Robertson said:

Windows 11 Enterprise 22H2  fully updated

Yes, the problem is Windows 10 only.

[Andrew Spencer 2]

Uwe, I tried this immediately on seeing your post, and it worked (once). But then it stopped working. In the past few hours, with reboots and various other attempts at fixes, it has somehow worked, but again only once.

Closer, but it is not (yet) the solution.

In WireShark I do now see that TLS 1.3 is now being used in the transactions, but the 12175 error persists.

 

I have been trying things on two separate PCs - one with Delphi 11.1 / Windows 10 and the other with Delphi 10.4.2 / Windows 10

[Andrew Spencer 2]

RSP-39760 at https://quality.embarcadero.com/

(and in my frustration, I had caused a double entry - also RSP-39755!)
Please also add comments there, or vote.

[Remy Lebeau 1393]

5 hours ago, Andrew Spencer said:

Does anyone have advice on an alternative for the TRESTClient / TRESTRequest / TRESTResponse set of Embarcadero components?

There is always Indy's TIdHTTP component   The standard TIdSSLIOHandlerSocketOpenSSL component will support up to TLS 1.2 with OpenSSL 1.0.2, and this WIP SSLIOHandler will handle TLS 1.3 with OpenSSL 1.1+.

 

[Brian Evans 105]

3 hours ago, Andrew Spencer said:

RSP-39760 at https://quality.embarcadero.com/

(and in my frustration, I had caused a double entry - also RSP-39755!)
Please also add comments there, or vote.

They deleted the first one, so just the second exists now.

[RSP-39755] Microsoft Windows update KB5018410 breaks REST operations - Embarcadero Technologies

[Wagner Landgraf 43]

The same issue happens with our TMS Sparkle library. It looks like it affected WinHttp API, which is what both Sparkle and Delphi REST library use.

I'm afraid this might be even a Microsoft bug, or at least I couldn't find any valuable or updated information that clarifies better what's happening and if and how to properly use the WinHttp library to overcome this issue.

[Paul TOTH 2]

I don't understand...

this is a portion of one of my projects
 

{$IFDEF INDY}
  HTTP := TidHTTP.Create(Self);
{$IFDEF INDY_SSL}
  SSL := TIdSSLIOHandlerSocketOpenSSL.Create(Self);
  SSL.SSLOptions.SSLVersions := [sslvTLSv1_2];
{$ELSE}
  SSL := TIdSSLIOHandlerSocketSChannel.Create(Self);
{$ENDIF}
  HTTP.IOHandler := SSL;
{$ELSE}
  HTTP := THTTPClient.Create;
{$ENDIF}
    HTTP.Get
      ('https://secure.bioserveur.com/bioserveur-access/ws_download.pl?logincode='
      + login + '&password=' + password, response);

if I define INDY only my SChannel component raise a 0x80090326 error on InitializeSecurityContext under Windows 10
with INDY and INDY_SLL (OpenSSL) it works
without INDY I use System.Net.HttpClient and it works also, with a call to WinHttpSendRequest() from winhttp.dll !

[Andrew Spencer 2]

On 10/14/2022 at 7:06 PM, Remy Lebeau said:

There is always Indy's TIdHTTP component   The standard TIdSSLIOHandlerSocketOpenSSL component will support up to TLS 1.2 with OpenSSL 1.0.2, and this WIP SSLIOHandler will handle TLS 1.3 with OpenSSL 1.1+.

Thanks for the suggestion, Remy.
After some looking around, I've settled on replacing all the Delphi TRESTxxxxx operations with the offering from Chilkat. It's a slow job, trawling through all the code, but it looks as if it will save the day.

[Andrew Spencer 2]

On 10/14/2022 at 9:23 PM, Brian Evans said:

They deleted the first one, so just the second exists now.

[RSP-39755] Microsoft Windows update KB5018410 breaks REST operations - Embarcadero Technologies

RSP-39760 has been restored, and has now moved from status "Reported" to status "Open" ("The issue is open and ready for the assignee to start work on it.")

[tgbs 14]

October 17, 2022—KB5020387 (OS Build 22000.1100) Out-of-band

October 17, 2022—KB5020435 (OS Builds 19042.2132, 19043.2132, and 19044.2132) Out-of-band

 

How is with this patch ?

Edited October 18, 2022 by tgbs

[Uwe Raabe 2057]

I can confirm that KB5020435 solves this issue on my system. As Windows Update didn't list it, I had to download and install it manually

[Nathan Wild 3]

Does anyone know if KB5020435 fixes this issue on Windows Server 2019?  Or is this a Win-10 specific thing?  We are having no issues at all on Win11 and Windows Server 2022.