TRESTClient Exception: REST request failed: Error sending data: (12175) A security error occurred

[MikeMon 12]

Using a TRESTClient on Delphi 10.4, I'm getting the following exception when sending a POST request to a https site:

 

REST request failed: Error sending data: (12175) A security error occurred.

 

FYI, "REST Debugger" that ships with Delphi 10.4 is producing the same exception, while the same request, to the same https site, is working perfectly with Postman.

 

Any ideas?

[bdw_nz20 11]

Could it be the SSL version being used on the server ?

 

Might not be negotiating the correct version ?  Could check if they are restricted to v1.1 or v1.2, I believe you can set the max version to use at runtime.

[MikeMon 12]

2 hours ago, bdw_nz20 said:

Could it be the SSL version being used on the server ?

 

Might not be negotiating the correct version ?  Could check if they are restricted to v1.1 or v1.2, I believe you can set the max version to use at runtime.

Disabling TLS v1.2 on Postman is producing the same error. Disabling all other options and leaving only TLS v1.2 is working fine on Postman. So, I disabled the TLS13 in the TRESTCLient.SecurityProtocols, but I'm getting the same error.

 

BTW, this is on a Windows Server 2012 R2 (which was working correctly until 2 days ago). On my Windows 10 computer, it's working properly. 

[Dmitry Arefiev 101]

Try to leave only TLS v 1.1 and 1.2 in SecurityProtocols.

[MikeMon 12]

1 hour ago, Dmitry Arefiev said:

Try to leave only TLS v 1.1 and 1.2 in SecurityProtocols.

I tried. Same exception.

[RDP1974 40]

I had a trouble calling a soap webservice, solved with 10.4.1 update

[MikeMon 12]

27 minutes ago, RDP1974 said:

I had a trouble calling a soap webservice, solved with 10.4.1 update

I'm already using 10.4.1.

[Dmitry Arefiev 101]

1) If server is publicly accessible, please, log this issue to quality.embarcadero.com and attach simple test project. If there is some sensitive information, which you dont want to share publicly, then let me know. We can exchange it privately.

2) Otherwise, you can try to analyze the server using https://www.ssllabs.com/ssltest/ This may give some hints.

[MikeMon 12]

1 hour ago, Dmitry Arefiev said:

1) If server is publicly accessible, please, log this issue to quality.embarcadero.com and attach simple test project. If there is some sensitive information, which you dont want to share publicly, then let me know. We can exchange it privately.

2) Otherwise, you can try to analyze the server using https://www.ssllabs.com/ssltest/ This may give some hints.

I checked the site using  https://www.ssllabs.com/ssltest. It uses TLS1.2. In the handshake simulation, IE11 / Win7 and IE11 / Win8.1 return with "Server sent fatal alert; handshake_failure" message.

 

Just FYI, as I wrote above, the problem is on a Windows Server 2012 R2. On my Windows 10 computer, it's working properly. Moreover, on the same Windows Server 2012 R2, the Postman software is working fine.

[Dmitry Arefiev 101]

May be this will help:

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

[MikeMon 12]

34 minutes ago, Dmitry Arefiev said:

May be this will help:

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

I've already added the registry values. No luck. It is very weird that the Postman is working. Obviously, it is overriding the default protocols.

[Tomo 0]

Hello!

 

 

[Tomo 0]

Hello!

 

As I read this post, I saw that I have the same problem. REST debugger and Execute in design don't work on my Win8.1 machine, but it works ok on Win 10 machine. The same request works ok using Postman on my machine. Has a problem already  been solved? I've also opened an issue in quality center...

 

Thanks

 

Tomaz

[MikeMon 12]

1 hour ago, Tomo said:

Hello!

 

As I read this post, I saw that I have the same problem. REST debugger and Execute in design don't work on my Win8.1 machine, but it works ok on Win 10 machine. The same request works ok using Postman on my machine. Has a problem already  been solved? I've also opened an issue in quality center...

 

Thanks

 

Tomaz

No solution yet. A solution has to be found because, like I said, other software, e.g. Postman, work fine.

[Tomo 0]

Yes, I agree with you, that a solution has to be found. By my opinion, the problem is connected with older versions of Windows and obviously with TLS1.2 security protocol. I've tried a few suggestions from the net, but nothing worked by now. I'm still waiting for the reply from Quality center...

[MikeMon 12]

4 minutes ago, Tomo said:

Yes, I agree with you, that a solution has to be found. By my opinion, the problem is connected with older versions of Windows and obviously with TLS1.2 security protocol. I've tried a few suggestions from the net, but nothing worked by now. I'm still waiting for the reply from Quality center...

It IS connected with older Windows versions which use TLS 1.1 or below. But as long as Postman works on those older Windows versions, there should be a solution with TRESTClient.

 

Would you share the Quality Central issue link for me to follow up as well?

[Tomo 0]

https://quality.embarcadero.com/browse/RSP-31406

[MikeMon 12]

12 minutes ago, Tomo said:

https://quality.embarcadero.com/browse/RSP-31406

Tx. I've voted for the issue!!

[Huseyin Ozkan Erdem 0]

Dear all, we have had this problem too. We have find the solution by installing this small easyfix update by microsoft:

 

https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392

 

but, finding the location of the file easyfix was not easy.

here is the link:

http://download.microsoft.com/download/0/6/5/0658B1A7-6D2E-474F-BC2C-D69E5B9E9A68/MicrosoftEasyFix51044.msi

 

I have found the link form this page: thanks a lot:

https://deakin.service-now.com/kb_view_customer.do?sys_kb_id=df07b2a4db50c8503986a05605961954&sysparm_nameofstack=&sysparm_kb_search_table=

 

I ve already written this into https://quality.embarcadero.com/browse/RSP-31406

 

Best Regards.

 

[MikeMon 12]

Hi @Huseyin Ozkan Erdem

 

Thank you for your answer. We had tried the fix prior to creating this thread. Unfortunately, it does not work on Windows Server 2012.

[Gerson 1]

On 2/16/2021 at 5:58 PM, Huseyin Ozkan Erdem said:

Dear all, we have had this problem too. We have find the solution by installing this small easyfix update by microsoft:

 

https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392

 

but, finding the location of the file easyfix was not easy.

here is the link:

http://download.microsoft.com/download/0/6/5/0658B1A7-6D2E-474F-BC2C-D69E5B9E9A68/MicrosoftEasyFix51044.msi

 

I have found the link form this page: thanks a lot:

https://deakin.service-now.com/kb_view_customer.do?sys_kb_id=df07b2a4db50c8503986a05605961954&sysparm_nameofstack=&sysparm_kb_search_table=

 

I ve already written this into https://quality.embarcadero.com/browse/RSP-31406

 

Best Regards.

 

Show de bola Huseyin Ozkan Erdem resolveu o problema aqui... muito obrigado pela contribuição.

[blower 1]

I have run into the same problem with the RESTClient (and any HTTPS based controls for that matter), and i suspect the issue you are having with windows 7, is due to the limited cipher suites available on 7 and 8.1

 

Some servers have switched to using strong cipher's for their TLS...and merely enabling TLS 1.2 will not work on operating systems older than Windows 10.

I've seen some servers only support TLS ciphers such as

 

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

 

These are not supported on Windows 7 (and i believe neither on 8.1) - there is no way to add them either.

Microsoft in their (lack) of wisdom never added them on their final cipher update, despite them being in use at the time, and now these OS's no longer receive any mainstream support and are considered EOL, they won't ever add them.

 

If you try to connect to a server which uses the above ciphers for TLS, on windows 7, you will get the 12175 security error.

 

You can see what ciphers are supported on windows 7 here: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-7

 

You can test your servers SSL certificate here to find out what TLS ciphers it supports: https://www.ssllabs.com/ssltest

 

If the server supports ciphers on the list, and yet you are still getting the error then the previous posts for enabling TLS1.2 on windows 7 may work, you may also have to set the appropriate SecureProtocols property on the RESTClient.

 

[Guest]

5 hours ago, blower said:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

 

These are not supported on Windows 7 (and i believe neither on 8.1) - there is no way to add them either.

There is other cipher suits that provide the same security level like these 

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

DHE instead of ECDHE with TLS 1.2 still provide perfect forward secrecy

 

Or just try to replace your certificate with EC one instead of the one with RSA key, these do have better ciphers suits and a little faster in handshakes.

[blower 1]

28 minutes ago, Kas Ob. said:

There is other cipher suits that provide the same security level like these 

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

DHE instead of ECDHE with TLS 1.2 still provide perfect forward secrecy

 

Or just try to replace your certificate with EC one instead of the one with RSA key, these do have better ciphers suits and a little faster in handshakes.

Unfortunately that's no good if you are accessing a 3rd party server beyond your control.

[Adam 5]

Blower is right above! I hit this problem today.

 

The answer at https://quality.embarcadero.com/browse/RSP-31406  is misleading. It says "RESOLVED - Fixed in Alexandria 11". I don't believe this is the case, as I don't believe it's a Delphi problem, but a Windows issue. (That won't be resolved as the protcols being used by the server are the TLS_ECDHE_RSA which are not available on EOL operating systems).

 

Postman works - but I believe the reason postman works is because it is using it's own (or a 3rd party) SSL library instead of the WinHTTP API's. This makes sense being cross platform.

 

If the server being connected to is 3rd party, and you have no control over the certificates - I believe the only solutions will either be to update the operating system or otherwise switch to a component suite that uses a 3rd party SSL library (such as OpenSSL). I'm not sure but I think you could do this with some Indy components.