Linux server crash

[ThomasHorstmann]

Hello,
I have got problems with TaurusTLS and Linux. The server crashes without any message with some queries. I've tested it with Ubuntu 24.04, Ubuntu 26.04, and Debian Trixie. It works fine with Windows or without TLS. I attached a sample.

Demo.zip

[tregubovav-dev]

Hello Thomas.

I would appreciate it if you give examples of queries that server is crashed.
Please also check which openssl version is installed with these distros.

[tregubovav-dev]

I haven't see any crash during my investigation.
However, there is misconfiguration in your code that does not enable the SSL/TLS handshake. That means the HTTPServer parser receives encrypted data from the client and can't parse it.
The TIdHTTPServer (Indy) component uses plain connection by default, even when the IOHandler bound to the TIdHTTPServer component. You need use TIdHTTPServer.OnQuerySSLPort event to enable SSL/TLS support on specific listening port.

Updating your Server code with following changes enables SSL/TLS support and makes it work:

type
  THTTPServer = class(TObject)
    FHTTP: TIdHTTPServer;
    FIO: TTaurusTLSServerIOHandler;
  private
    procedure GetCommand(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
    procedure SetTLS(APort: TIdPort; var VUseSSL: Boolean);
  public
    constructor Create;
    destructor Destroy; override;
  end;

constructor THTTPServer.Create;
begin
  inherited Create;
  FHTTP := TIdHTTPServer.Create(nil);
  FHTTP.OnCommandGet := GetCommand;
  FIO := TTaurusTLSServerIOHandler.Create(nil);
  FIO.DefaultCert.PublicKey := 'server_certificate.crt'; // Use your own
  FIO.DefaultCert.PrivateKey := 'server_key.key'; // Use your own
  FHTTP.IOHandler := FIO;
  FHTTP.DefaultPort := 443;
  FHTTP.OnQuerySSLPort:=SetTls; // Event that allows to switch connection to SSL/TLS
  FHTTP.Active := True;
end;

procedure THTTPServer.SetTLS(APort: TIdPort; var VUseSSL: Boolean);
begin
  VUseSSL:=(APort = 443);
end;

Please try these changes and let us know it it resolves your issue or not.

[ThomasHorstmann]

Hello,
I changed the TaurusHTTPServer application, but the linux server still crashes. By now I was only able to reproduce the crash with the TNetHTTPClient component (see Client sample in Demo_2 folder). Curl and ohter clients are working. The Linux server (Ubuntu Server 26.04 LTS) uses OpenSSL 3.5.5.

Demo_2.zip

[tregubovav-dev]

Thank you Thomas for the reply.

Does it crash on any request or using specific URI path only?

[ThomasHorstmann]

Hello,
it seems it crashes with every request. In the sample, the "GetCommand" procedure always returns the same data, not checking the url.

Info: I have scoured the internet and AI, and one theory suggests that the client might be terminating the session before the server has finished.

[tregubovav-dev]

I was able to reproduce crash a couple time the only when run the taurusHTTPServer under the root (as 443 port requirement).
The issue is out after a couple crashes happened. That's weird.
What I able to check that the crash happens inside the OpenSSL code, not in the TaurusTLS or Indy code.
I will try to continue debugging it.

[ThomasHorstmann]

Thanks :-)

[tregubovav-dev]

Very interesting outcome of initial investigation:

• Issue is reproduced when the only in a first connect made by Windows TNetHTTPClient. Any subsequent calls (after restarting server) does not introduce the crash.
• TNetHTTPClient tries to connect using TLS1.3 two times. When both are failed - it switches to TLS1.2 where server crashes.

The crash happens in the OpenSSL code after calling SSL_peek(fSSL, buf, 1);.
This may lead to different conditions:

• reading multiple threads from the same socket handler
• invalidly formed tls extensions in the Client Hello

function TTaurusTLSSocket.Readable: TTaurusTLSReadStatus;
//From Tony WHyman - IndySecOpenSSL
var buf : byte;   //PALOFF - Variables that are set, but never referenced
    Lr: integer;
begin
  Result := sslNoData;
  {Confirm that there is application data to be read.}
  Lr := SSL_peek(fSSL, buf, 1); // <- Crash is here.
  {Return DataAvailable if application data pending, or if it looks like we have disconnected,
          UnrecoverableError if error state indicates thus,
          EOF if the connection has been shutdown, or
          NoData otherwise => try again later}
  if Lr > 0 then
    Result := sslDataAvailable
  else
  begin
    case SSL_get_error(fSSL,Lr) of
      SSL_ERROR_SSL, SSL_ERROR_SYSCALL:
          if SSL_get_shutdown(fSSL) = SSL_RECEIVED_SHUTDOWN then
            Result := sslEOF
          else
            Result := sslUnrecoverableError;

      SSL_ERROR_ZERO_RETURN:
          if SSL_get_shutdown(fSSL) = SSL_RECEIVED_SHUTDOWN then
            Result := sslEOF;

      {anything else return the function default - sslNoData (yet)}
    end;
  end;
end;

Recommendation: not to use SSL_peak in handshake handling.

[tregubovav-dev]

Problem Summary:

A crash (Exception 13 / GPF) occurred in TTaurusTLSSocket.Readable during the SSL_peek call. This was caused by a race condition where the SSL polling logic accessed the fSSL handle before it was fully initialized or after it was partially destroyed.

Resolution Details:

• Handle Lifetime Safety: Implemented an explicit Assigned(fSSL) check in TTaurusTLSSocket.Readable. If the OpenSSL handle is not initialized, the method now returns sslNoData immediately instead of calling into the C-library.
• Race Condition Mitigation: Modified TTaurusTLSIOHandlerSocket.Readable to capture the socket reference into a local variable (LSock). This ensures that even if fSSLSocket is cleared by another thread (e.g., during a Close call), the current execution path remains stable.
• Robust Handshake Protocol: The TLS handshake logic in Connect and Accept was refactored into a retry loop. It now correctly respects OpenSSL's WANT_READ and WANT_WRITE return codes. This ensures the OpenSSL state machine remains in a valid state even during interrupted or complex handshakes (like those involving ECH retry configs).
• Linux Stability: The handshake retry loop and nil checks resolve the underlying triggers that caused OpenSSL to emit alerts on closed sockets, which previously led to SIGPIPE issues on Linux targets.

Fix location

• Fix implemented in the bugfix-issue_217 branch.
• The fix needs wider testing as it impacts base TLS functionality on the server side.
• Fix may impact any platform where TTaurusTLSServerIOHandler is used.

[ThomasHorstmann]

Hello,
I checked "TaurusTLS-bugfix-issue_217". But the server still crashes.

[tregubovav-dev]

Hi Thomas, thank you for the feedback.

Are you able to run the the server in the debugger and let us know what king of exception makes the crash in your environment?

[ThomasHorstmann]

I had to intstall Ubuntu 20.04 Server, because the Delphi Linux debugger was not working with 26.04. I checked it several times. A few times it worked. But when I use a loop in the client application, it crasches immediately:

for i := 1 to 1000 do
begin
Load;
EditCounter.Text := inttostr(i);
Application.ProcessMessages;
end;

This is the result of the debugger:

TaurusHTTPServer Process [vdso] (8419)
Press enter to terminate. Process [vdso] (8419)
First chance exception at $00007FFFF7FB932F. Exception class 13. Process [vdso] (8419)
First chance exception at $00000000005E60F8. Exception class EIdConnClosedGracefully with message 'Connection Closed Gracefully.'. Process [vdso] (8419)
First chance exception at $00000000005E60F8. Exception class EIdConnClosedGracefully with message 'Connection Closed Gracefully.'. Process [vdso] (8419)
First chance exception at $00000000005E60F8. Exception class EIdConnClosedGracefully with message 'Connection Closed Gracefully.'. Process [vdso] (8419)

[JPeterMugaas]

Connection Closed Gracefully should be handled by Indy itself.