Posts by ec

ec · mORMot 2

It seems more stable to me.

In Firefox, it works perfectly. The browser displays the warning: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, as expected.

In other browsers, the exception occurs: "Project ecentric.exe raised exception class ESChannel with message '<>: HandshakeStep returned 80090327 [SEC_E_CERT_UNKNOWN], System Error 87 [ERROR_INVALID_PARAMETER]'.". The browser displays the warning: NET::ERR_CERT_AUTHORITY_INVALID. However, now it is possible to ignore this type of exception, and the execution continues normally.

Thank you!

ec · mORMot 2

What browser are you using? I recently noticed a similar situation in browsers other than Firefox.

ec · mORMot 2

In case anyone is interested, InitNetTlsContextSelfSignedServer works in Firefox too, with the pre-computed certificate.

ec · mORMot 2

Ab, I apologize for the language barrier, and I thank you in advance for your attention.

I was able to identify the issue that caused confusion here. The conclusion is that when SChannel is used, the certificate generated by the call to InitNetTlsContextSelfSignedServer(FTls, Algo, {UsePreComputed=}TRUE) only works with mormot2, or curl, and is not valid and/or compatible with current browsers. However, when a .pfx certificate is used, and not the precomputed one, it works normally.

ec · mORMot 2

But, I think ignoring this exception may not be a good idea, things may not work correctly

ec · mORMot 2

Ab, check this out:

I ran an additional step with openssl, as documented in TSChannelNetTls.AfterBind:

openssl pkcs12 -inkey private.key -in certificate.crt -export -out certificate.pfx

Using ...

InitNetTlsContext(FTls, True, 'C:\Devel\eCentric-11\certificate\certificate.pfx', 'C:\Devel\eCentric-11\certificate\private.key');

Or ...

FWsServer.WaitStarted(10, 'C:\Devel\eCentric-11\certificate\certificate.pfx', 'C:\Devel\eCentric-11\certificate\private.key');

And, ignoring the server-side exception...

It worked again!!!

The browser displays the usual warning:

Your connection is not private Attackers might be trying to steal your information from 192.168.0.128 (for example, passwords, messages, or credit cards). Learn more about this warning net::ERR_CERT_AUTHORITY_INVALID Turn on enhanced protection to get Chrome's highest level of security This server could not prove that it is 192.168.0.128; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.

Proceed to 192.168.0.128 (unsafe).

And the websocket client (wss) also works.

The certificate has been deleted from Windows!!!

Working with or without openssl

Ab, in my understanding it doesn't work when we use InitNetTlsContextSelfSignedServer(FTls, Algo).

What do you think ?

ec · mORMot 2

Ab, I did this (with and without openssl):

1. openssl genrsa -out private.key 2048
2. openssl req -new -key private.key -out request.csr
3. openssl x509 -req -days 365 -in request .csr -signkey private.key -out certificate.crt
4. I installed the certificate on Windows

When I use one of the ways:

...
FWsServer.WaitStarted(10, 'C:\Devel\eCentric-11\certificate\certificate.crt' , 'C:\Devel\eCentric-11\certificate\private.key');

Or

...
InitNetTlsContext(FTls, {server=}True, 'C:\Devel\eCentric-11\certificate\certificate.crt', 'C:\Devel\eCentric-11\certificate\private.key');
FWsServer .WaitStarted(10, @FTls);

Now the following exception is occurring:
Project ecentric.exe raised exception class ESChannel with message '<>: PFXImportCertStoreSEC_E_CERT_UNKNOWN returned 80090327 [SEC_E_CERT_UNKNOWN], System Error -2146885630 [Error during encryption operation or decoding]'.

ec · mORMot 2

Ok, I'll test as suggested.

I tried using openssl but I'm getting the following error:

[dcc64 Error] mormot.crypt.openssl.pas(879): E2250 There is no overloaded version of 'AlgoName' that can be called with these arguments
[dcc64 Error] mormot.crypt .openssl.pas(966): E2250 There is no overloaded version of 'AlgoName' that can be called with these arguments
[dcc64 Fatal Error] mor.wss.acceptor.pas(918): F2063 Could not compile used unit 'mormot. crypt.openssl.pas' Failed

ec · mORMot 2

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls13
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the
SSL/TLS secure channel. At line:1 character:1 + Invoke-WebRequest -Uri https://192.168.0.128:7799 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo: InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

ec · mORMot 2

Ab, I also tested it this way, and the exception continues to occur on the server side, in any version of TLS

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls11
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls13
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799

ec · mORMot 2

I'm using Windows 11 on the server side. Until a few days ago, this exception was not occurring. Now the browser's websocket client causes this exception on the server!

ec · mORMot 2

Ab, with curl, there is no exception at server side:

C:\Tools\curl\bin>curl -v -k "https://192.168.0.128:7799"
* Trying 192.168.0.128:7799...
* Connected to 192.168.0.128 (192.168.0.128) port 7799
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=127.0.0.1
* start date: Jul 6 20:15:22 2022 GMT
* expire date: Jul 3 20:15:22 2032 GMT
* issuer: CN=127.0.0.1
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Certificate level 0: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 192.168.0.128:7799
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: ecentric.I11
< Content-Length: 0
<
* Connection #0 to host 192.168.0.128 left intact

ec · mORMot 2

Sorry for the inconvenience, ab. The code snippet was just intended to illustrate how I was doing it on both sides (client and server). The exception that is appearing on the server side is:
Project ecentric.exe raised exception class ESChannel with message '<>: HandshakeStep returned 80090326 [SEC_E_ILLEGAL_MESSAGE], System Error 87 [ERROR_INVALID_PARAMETER]'.

The error at the browser side is:
ERR_SSL_KEY_USAGE_INCOMPATIBLE

ec · mORMot 2

Hi Ab,

I'm using InitNetTlsContextSelfSignedServer. It was working perfectly since my first tests. Now, it only works in mormot2 connections (wss client, for example) to mormot2 (wss server, for example), and the following exception occurs when connected via browser (https, or wss):

:00007FFFD9D0FABC ; C:\Windows\System32\KERNELBASE.dll
System._RaiseAtExcept(???,???)
System._RaiseExcept(???)
mormot.net.sock.TSChannelNetTls.ESChannelRaiseLastError('''¼'#0#0#0#0#0'&'#3#9'€'#0#0#0#0#0#0#0#0#3#0#0#0'xy’'#7#0#0#0#0#$1C#1#1#0'&'#3#9'€ày’'#7#0#0#0#0'¨&¼'#0#0#0#0#0'€¼Á'#4#0#0#0#0'Õ''¼'#0#0#0#0#0'&'#3#9'€'#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0'P'#$B'¼'#0#0#0#0#0'ðD»'#4#0#0#0#0#8'ÿ’'#7#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0#0#0'<'#4#0#0#0#0#0#0'ðD»'#4'8J'#0#0'PNî'#6#0#0#0#0#0#0#0#0'&'#3#9'€`z’'#7#0#0#0#0' !¼'#0#0#0#0#0'€¼Á'#4#0#0#0#0'Â!¼'#0#0#0#0#0#0#0#0#0#0#0#0#0'P"ñ'#6#0#0,2148074278)
mormot.net.sock.TSChannelNetTls.CheckSEC_E_OK('''¼'#0#0#0#0#0'&'#3#9'€'#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0'P'#$B'¼'#0#0#0#0#0'ðD»'#4#0#0#0#0#8'ÿ’'#7#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0#0#0'<'#4#0#0#0#0#0#0'ðD»'#4'8J'#0#0'PNî'#6#0#0#0#0#0#0#0#0'&'#3#9'€`z’'#7#0#0#0#0' !¼'#0#0#0#0#0'€¼Á'#4#0#0#0#0'Â!¼'#0#0#0#0#0#0#0#0#0#0#0#0#0'P"ñ'#6#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0'°¼Á'#4#0#0#0#0#0#0#0#0#0#0#0#0#$90'¿'#$12#1#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0,-2146893018)
mormot.net.sock.TSChannelNetTls.HandshakeLoop
mormot.net.sock.TSChannelNetTls.AfterAccept($43C,(True, True, True, True, False, False, False, '', nil, '', ),???,nil {''})
mormot.net.async.TAsyncServer.OnFirstReadDoTls($4B93F30)
mormot.net.async.TPollAsyncConnection.OnFirstRead($4BDBFB0)
mormot.net.async.TPollAsyncSockets.ProcessRead($4C66CD0,1152921504686096176)
mormot.net.async.TAsyncConnectionsThread.Execute
System.Classes.ThreadProc($4C66CD0)
System.ThreadWrapper($4BB44E0)
:00007FFFDADE257D ; C:\Windows\System32\KERNEL32.DLL
:00007FFFDC82AF28 ; ntdll.dll

...
InitNetTlsContextSelfSignedServer(FTls, caaRS256);
FTls.IgnoreCertificateErrors := True;
...
FWsServer :=
TWebSocketAsyncServer.Create(
Target, Nil, Nil, 'Acceptor', FOuAccepts, 30000, [
hsoNoStats, hsoEnableTls,
hsoNoXPoweredHeader,
hsoHeadersInterning,
hsoCreateSuspended,
hsoThreadSmooting ]);
...
FWsServer.Start;
FWsServer.WaitStarted(10, @FTls);
...

ec · mORMot 2

Hi,

Browsers return ERR_SSL_KEY_USAGE_INCOMPATIBLE when accessing any resource with a self-signed certificate, on Windows, for example:
https://192.168.0.128:7799

What is wrong ?

ec · mORMot 2

I understood. Perfect ! The implementation, as it stands, already meets the needs. In the production environment, we will have thousands of concurrent connections, and, in addition to Linux, with several clients using the Windows server. This is why the synchronous version does not suit us.

Once again, thank you very much for your attention

ec · mORMot 2

Hi Arnaud !

I understood.

Anyway, I noticed that with a small increase in the number of test connections, the increase in connection time is also happening with openssl, only on the server side! But, despite the increase in connection time, the server continues to work, and new connections are established normally.

Thank you very much for your attention

ec · mORMot 2

Good morning Arnaud !

When I define USE_OPENSSL in the project it works normally.

ec · mORMot 2

Hi Arnaud !

I'm not sure if this is the same problem observed by @maro.

Tested only with Default SSPI Windows API (Windows 10 and 11). I'm sure this only occurs on the server side.

Reproducing what I observed is very simple.

1) I created a websocket listener:
FWsServer :=
TWebSocketAsyncServer.Create('0.0.0.0:7799', Nil, Nil, 'Acceptor', 32, 30000, [
hsoNoXPoweredHeader, hsoHeadersInterning, hsoThreadSmooting,
hsoNoStats, hsoBan40xIP, hsoEnableTls ]);
...

2) The reproduction of what I observed can be done as follows:
In Google Chrome, using two instances of the "Simple Websocket Client" extension,
pointing to: "wss://192.168.0.109:7799/Test", it is observed that the connection of the first instance occurs normally.
Connecting and disconnecting, with a single instance, occurs quickly.
With the first instance connected, the second instance's connection behaves differently, the time to connect increases,
and, after several repetitions, the server stops responding.

It only occurs when I'm using TLS.

I hope I have contributed in some way.

Thank you very much for your attention.

ec · mORMot 2

Good morning Arnaud !

What do you think could be happening ?

Thank you for your attention

ec · mORMot 2

Good morning !

The following situation was also observed: Quickly connecting and disconnecting a single websocket client, everything works well, it is possible to connect and disconnect quickly and efficiently. From the second websocket client onwards, the behavior of new connections changes. Thereafter, there is an unusual delay in all new connections, until, finally, the new connections are rejected. In the test carried out there is no data traffic, only websocket connection and disconnection.

** This does not happen without TLS !!!

I hope I contributed in some way

ec · mORMot 2

Good morning !

What excellent news, Ab. Our team thanks you immensely for all your attention and effort.

ec · mORMot 2

Okay Ab.

I got better results as follows:

fEvent.ResetEvent;
fWaitForReadPending := true; // should be set before wakeup
if new <> 0 then
fOwner.ThreadPollingWakeup(new)
else
{ ec...
} begin
new := fOwner.fClients.fRead.PollForPendingEvents(ms);
If new = 0 Then Begin
TThread.Sleep(1);
Continue;
End;
fOwner.ThreadPollingWakeup(new);
end;

Or simply ...

atpReadPoll:
// main thread will just fill pending events from socket polls
// (no process because a faulty service would delay all reading)
begin
fWaitForReadPending := false;
{ new := fOwner.fClients.fRead.PollForPendingEvents(ms);
} new := fOwner.fClients.fRead.PollForPendingEvents(ms + 1100); // << it works too

I hope it helps !

Thank you very much for your attention.

ec · mORMot 2

Testing like this now
...
atpReadPoll:
// main thread will just fill pending events from socket polls
// (no process because a faulty service would delay all reading)
...
if new <> 0 then
fOwner.ThreadPollingWakeup(new)
else
begin
new := fOwner.fClients.fRead.PollForPendingEvents(ms);
If new = 0 Then Begin
TThread.Sleep(1); // Without this things don't work, anyway
Continue;
End;
end;
...

ec · mORMot 2

It didn't stabilize! It stopped working, with the same symptoms as before, after an hour of testing

ec · mORMot 2

Good morning !

With this change, a single connection causes high CPU consumption!

It appears to be working normally again with the following:

...
fWaitForReadPending := true; // should be set before wakeup
if new <> 0 then
fOwner.ThreadPollingWakeup(new)
Else Begin
fEvent.WaitFor(1); // ec **
Continue;
End;
...

ec · mORMot 2

Goodnight !

Ab, me, again. On the same subject!

...
procedure TAsyncConnectionsThread.Execute;
...
{$ifdef OSWINDOWS}
{ start := -1; // ensure never SleepHiRes(0)
} start := 1; // ec
{$else}
start := 0; // best reactivity
{$endif OSWINDOWS}
...

After two hours of testing (30 clients), with the start value = -1, the following situation occurs:

-One of the connections stops working. The other 29 are still working;
-No new connections to the server are possible;
-CPU consumption goes up to 50% or more.

Changing the value of start to 1, and adding another 70 clients, no problem occurs and, strangely, one has the impression of better performance and stability!

What do you think ?

ec · mORMot 2

Good morning !

If so, it's much more efficient! Correct me if I'm wrong: -1 = INFINITE, which is the same as mormot.core.os.windows.inc.WaitFor(INFINITE), in the given snippet. Tested with thousands of operations.
Working perfectly, with minimal CPU consumption!!!

Thank you very much for your attention.

ec · mORMot 2

Good afternoon !

About the high CPU consumption, I tested it a little while ago and apparently it works correctly. See if that makes any sense to you...
Excessive context switching of threads is causing high CPU consumption.
At mormot.cor.windows.inc we have:
...
procedure SleepHiRes(ms: cardinal);
begin
if ms <> 0 then
Windows.Sleep(ms) // follow the HW timer: typically up to 16ms on Windows
else
SwitchToThread; // <-- Executed millions of times per minute
end;
...

At mormot.net.async.pas
...
procedure TAsyncConnectionsThread.Execute;
...
atpReadPoll:
// main thread will just fill pending events from socket polls
// (no process because a faulty service would delay all reading)
begin
{ start := 0;
} start := 1; // < -- My Test is this. It is the same as SleepHiRes(1)
while not Terminated do
...

Disregarding possible side effects, it works !!!

What do you think ?

ec · mORMot 2

Adding hsoThreadSmooting option, with a thread pool of 16, receiving 4 frames of 50 bytes, per second, without any processing, consumption drops to 6%.

ec · mORMot 2

I understood. Anyway, thank you immensely for your attention. I will provide the logs as soon as possible.

ec · mORMot 2

Yes. I even just tested with the new stable version released today

ec · mORMot 2

Thanks for the quick feedback.

Well, the question is exactly this. When using a ServerThreadPoolCount > 1 (4, 8, or the default 32) CPU consumption increases substantially, up to 20%, for no processing no Delphi 11.3

ec · mORMot 2

Good morning !

Considering the code ...

...
FServer := TWebSocketAsyncServer.Create('[::1]:12345', Nil, Nil, 'Acceptor', 2, 30000, []);
...

For every ServerThreadPoolCount > 1, when frames of any size are received at a rate of, say, two per second, CPU consumption increases substantially. There is no processing after receiving the frames. This does not happen when ServerThreadPoolCount = 1 !

This is normal ?

mORMot Open Source

#1 Re: mORMot 2 » HTTPS on THttpAsyncServer » 2024-10-09 16:20:36

#2 Re: mORMot 2 » HTTPS on THttpAsyncServer » 2024-10-09 12:11:22

#3 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-09-09 13:43:46

#4 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-30 09:40:22

#5 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-29 18:38:14

#6 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-29 13:42:14

#7 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-29 12:29:22

#8 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-29 10:26:53

#9 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-28 16:06:24

#10 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-28 15:12:58

#11 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-28 14:02:54

#12 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-28 13:47:42

#13 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-28 12:15:23

#14 Re: mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-27 18:17:42

#15 mORMot 2 » Err_Ssl Key_Usage Incompatible ! » 2024-08-27 13:53:28

#16 Re: mORMot 2 » Issue with TWebSocketAsyncServer » 2023-11-27 19:24:08

#17 Re: mORMot 2 » Issue with TWebSocketAsyncServer » 2023-11-27 17:26:45

#18 Re: mORMot 2 » Issue with TWebSocketAsyncServer » 2023-11-27 15:15:12

#19 Re: mORMot 2 » Issue with TWebSocketAsyncServer » 2023-11-23 20:17:20

#20 Re: mORMot 2 » Issue with TWebSocketAsyncServer » 2023-11-23 12:56:54

#21 Re: mORMot 2 » Issue with TWebSocketAsyncServer » 2023-11-09 10:51:05

#22 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-31 11:25:45

#23 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-30 14:39:34

#24 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-30 13:32:01

#25 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-30 12:27:24

#26 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-30 10:38:10

#27 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-29 21:27:48

#28 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-26 11:52:33

#29 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-25 18:38:14

#30 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-24 15:06:20

#31 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-24 14:48:40

#32 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-24 14:12:09

#33 Re: mORMot 2 » High CPU usage when frames are received » 2023-08-24 12:09:51

#34 mORMot 2 » High CPU usage when frames are received » 2023-08-24 11:24:49

Board footer