secSSL: Error connecting with TSQLHttpClient

itSDS · 2015-01-31 13:11:07

Hi AB,

today i testet the Server with the standard TSQLHttpClient and get error 12175 from winhttp.dll.

ERROR_WINHTTP_SECURE_FAILURE
12175
One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server. To determine what type of error was encountered, check for a WINHTTP_CALLBACK_STATUS_SECURE_FAILURE notification in a status callback function. For more information, see WINHTTP_STATUS_CALLBACK.

the error may be true cause i get it also using google chrome, but there i can select "ignore error" and connect.
The certifikate is created by myself. The error can be ignored and it should connect.

Is this possible ?

itSDS · 2015-01-31 13:49:47

Test2: I generated a CrossplatformWrapper for my Server and connected. This works perfekt. But it uses Indy as Client.

I think the TSQLHttpClient should also work

ab · 2015-01-31 15:49:10

Take a look at TWinHTTP.IgnoreSSLCertificateErrors and the corresponding TSQLHttpClientWinGeneric.IgnoreSSLCertificateErrors property.

itSDS · 2015-01-31 16:51:37

OK - TYVM (I saw it but did not recognize it)

its much faster then the Crossplatform one...

ab · 2015-01-31 17:47:55

Yes, I guess there is something wrong with the Indy version...
Something like a thread creation at each request...

ab wrote:

If Indy is really slow, we would look into another library. There are direct HTTP client units around, AFAIR.
For iOS/MacOS, we may use directly the TNSMutableURLRequest class - see e.g. https://github.com/jacobthurman/Usertil … tility.pas
Or use this unofficial Synapse port http://delphi.cz/post/Neoficialni-Synap … -2014.aspx
See http://synopse.info/forum/viewtopic.php … 458#p14458

If you have any idea why it is so slow, feedback is welcome!

itSDS · 2015-02-01 11:59:34

In my special case the initialisation is very slow.
Indy has to load the OpenSSL - Libs.
I Just do one Interface call and one query after i press a Button.
With Indy i takes about 1-1.5s till the Results are displayed. Without it is Displayed immediatelly (0.1s)

ab · 2015-02-01 13:24:34

Are the OpenSSL libs loaded at each request?

itSDS · 2015-02-01 13:46:40

No the SSL - Libs are loaded once and keeped in Memory.

I tried with my Firemonkey App now under Win32 and tried USEINDY and USECRT.

USECRT is 2-5 Times Faster on pure Datatransfer than Indy
i have some Interfacefunctions which transfer JSON - Tables
There seems to be a large amount of time in the initialisation of Indy.
a small tableresult (1Line ~ 200Byte) takes 280ms on Indy an 46ms on CRT
whereas a bigger Table (~2000 Lines) took 521ms on Indy and 276 on CRT

The Complete Transfer took 4694ms with Indy and 1594ms with crt without loading openssl - Libs.

I made this tests until the times where 3 times nearly the same. But as Conclusion i can say that indy is 3times slower than crt.

itSDS · 2015-02-01 13:49:16

One thing about USECRT and ssl

I had to modify your code to set IgnoreSSLCertificateErrors I could not find a better soluction cause the Connectionclass is created in TSQLRestClientHTTP.Connect may be you have a better idea ?!

constructor TWinHttpConnectionClass.Create(
  const aParameters: TSQLRestConnectionParams);
begin
  inherited;
  InitializeCriticalSection(fLock);
  fConnection := TWinHTTP.Create(RawByteString(fParameters.Server),
    RawByteString(IntToStr(fParameters.Port)),fParameters.Https,
    RawByteString(fParameters.ProxyName),RawByteString(fParameters.ProxyByPass),
    fParameters.ConnectionTimeOut,fParameters.SendTimeout,fParameters.ReceiveTimeout);

  fConnection.IgnoreSSLCertificateErrors := True;   // itSDS
end;

itSDS · 2015-02-01 13:52:41

My Idea is to initialise IgnoreSSLCertificateErrors with true.
This makes sense cause we generally call our own servers with our own Certifikates.
If the Exception raises we have no possibility to handle it and reconnect.

Last edited by itSDS (2015-02-01 13:53:20)

ab · 2015-02-01 18:25:48

Good idea.

We have therefore relaxed TWinHttpConnectionClass so that SSL certificate errors would be ignored by default.
And introduced a new TAbstractHttpConnection.ActualConnection property, which would allow to customize the proper connection class afterwards.
See http://synopse.info/fossil/info/4d6b671d28

mORMot Open Source

#1 2015-01-31 13:11:07

secSSL: Error connecting with TSQLHttpClient

#2 2015-01-31 13:49:47

Re: secSSL: Error connecting with TSQLHttpClient

#3 2015-01-31 15:49:10

Re: secSSL: Error connecting with TSQLHttpClient

#4 2015-01-31 16:51:37

Re: secSSL: Error connecting with TSQLHttpClient

#5 2015-01-31 17:47:55

Re: secSSL: Error connecting with TSQLHttpClient

#6 2015-02-01 11:59:34

Re: secSSL: Error connecting with TSQLHttpClient

#7 2015-02-01 13:24:34

Re: secSSL: Error connecting with TSQLHttpClient

#8 2015-02-01 13:46:40

Re: secSSL: Error connecting with TSQLHttpClient

#9 2015-02-01 13:49:16

Re: secSSL: Error connecting with TSQLHttpClient

#10 2015-02-01 13:52:41

Re: secSSL: Error connecting with TSQLHttpClient

#11 2015-02-01 18:25:48

Re: secSSL: Error connecting with TSQLHttpClient

Board footer