sgcIndy 2026.6: serverbeveiliging versterken voor TLS, TCP en HTTP

sgcIndy 2026.6 richt zijn aandacht op de serverkant. Deze release voegt een reeks optionele beveiligingsversterkingen toe aan de TLS-, TCP- en HTTP-servercomponenten en sluit daarmee een aantal bekende aanvalsklassen af waartegen de onderliggende Indy-code zich nooit beschermde: een certificaatverificatie-callback die fail-open is, traag druppelende Slowloris-verbindingen, onbegrensde requestbodies en headers, en HTTP request smuggling. Het levert ook de eerste ML-KEM-768 post-quantum sleutelinkapselingsprimitieven.

Elke nieuwe bescherming valt standaard terug op het vorige gedrag, zodat bestaande applicaties onaangetast blijven totdat u ze inschakelt. Deze post loopt door elk ervan heen met kant-en-klare Delphi-snippets.

Versterkte TLS-servers

De belangrijkste verbetering zit in de OpenSSL peer-verificatie-callback. In het standaard Indy kan de verificatie-callback fail open zijn: wanneer een server om een clientcertificaat vraagt, werd de uiteindelijke beslissing aangestuurd door de gebruikers-callback en negeerde deze het oordeel van OpenSSL zelf, zodat een callback die succes teruggaf een verlopen, zelfondertekend of niet-vertrouwd certificaat accepteerde. De nieuwe vlag TIdSSLOptions.StrictVerify dwingt het OpenSSL-resultaat af, zodat een aangepaste OnVerifyPeer-handler de beslissing alleen verder kan beperken, nooit kan versoepelen.

Drie andere vlaggen koppelen OpenSSL-opties die de headers al hadden gedeclareerd maar die de bibliotheek nooit toepaste: DisableCompression beperkt CRIME, DisableRenegotiation blokkeert door de client geïnitieerde heronderhandeling (een CPU-asymmetrische DoS) op OpenSSL 1.1.0h en later, en ServerCipherPreference zorgt ervoor dat de ciphervolgorde van de server de onderhandeling wint in plaats van die van de client.

uses
  IdHTTPServer, IdSSLOpenSSL;

var
  oServer: TIdHTTPServer;
  oSSL: TIdServerIOHandlerSSLOpenSSL;
begin
  oServer := TIdHTTPServer.Create(nil);
  oSSL := TIdServerIOHandlerSSLOpenSSL.Create(oServer);

  oSSL.SSLOptions.CertFile    := 'server.pem';
  oSSL.SSLOptions.KeyFile     := 'server.key';
  oSSL.SSLOptions.SSLVersions := [sslvTLSv1_2, sslvTLSv1_3];

  // opt-in hardening, every flag defaults to False
  oSSL.SSLOptions.StrictVerify           := True;  // enforce the OpenSSL verdict
  oSSL.SSLOptions.DisableCompression     := True;  // CRIME
  oSSL.SSLOptions.DisableRenegotiation   := True;  // renegotiation DoS
  oSSL.SSLOptions.ServerCipherPreference := True;  // server picks the cipher

  oServer.IOHandler := oSSL;
  oServer.Active := True;
end;

Stel VerifyMode in op [sslvrfPeer, sslvrfFailIfNoPeerCert] samen met StrictVerify wanneer u wederzijdse TLS wilt die een onbekend clientcertificaat ook daadwerkelijk afwijst.

Slowloris stoppen

Een Slowloris-client opent veel verbindingen en druppelt één byte per keer, voltooit de request nooit, om elke worker-thread vast te zetten. De voor de hand liggende verdediging lijkt op een lees-timeout, maar er is een subtiliteit die u moet kennen: de ReadTimeout van Indy is een inactiviteits-timeout. Elke byte die binnenkomt reset hem, zodat een client die om de paar seconden een byte stuurt de verbinding eindeloos in leven houdt.

2026.6 voegt een echte totale leesdeadline toe aan TIdIOHandler via SetReadDeadline. Deze wordt bij elke lees-actie gecontroleerd, dus hij treedt in werking zelfs terwijl er nog bytes binnendruppelen. De HTTP-server koppelt dit automatisch via de nieuwe eigenschap RequestReadTimeout, die de tijd begrenst om de requestregel en headers te ontvangen en per keep-alive-request opnieuw wordt gereset.

uses
  IdHTTPServer;

var
  oServer: TIdHTTPServer;
begin
  oServer := TIdHTTPServer.Create(nil);
  oServer.DefaultPort := 8080;

  // close any client that has not finished sending the request
  // line and headers within 5 seconds, even if it keeps dripping bytes
  oServer.RequestReadTimeout := 5000;

  oServer.Active := True;
end;

Voor een aangepaste TIdTCPServer kunt u dezelfde deadline handmatig toepassen rond uw lees-lus. Geef 0 door om hem te wissen.

procedure TForm1.ServerExecute(AContext: TIdContext);
var
  vLine: string;
begin
  // bound the whole request to 5 seconds of total read time
  AContext.Connection.IOHandler.SetReadDeadline(5000);
  try
    vLine := AContext.Connection.IOHandler.ReadLn;
    // ... handle the request ...
  finally
    AContext.Connection.IOHandler.SetReadDeadline(0);
  end;
end;

Requestlimieten voor HTTP-servers

Een HTTP-server die alles inleest wat een client opgeeft, is een eenvoudig doelwit voor geheugenuitputting. Eén enkele request kan Content-Length: 2000000000 aankondigen waarna de server probeert twee gigabyte te bufferen, of kan een eindeloze chunked body streamen, of miljoenen header-bytes versturen. 2026.6 voegt drie limieten en een smuggling-controle toe aan TIdCustomHTTPServer.

MaxRequestBodySize begrenst de Content-Length en de opgetelde chunked body en antwoordt met 413 Payload Too Large wanneer deze wordt overschreden. MaxHeaderTotalSize begrenst het totale aantal header-bytes en antwoordt met 431 Request Header Fields Too Large. StrictRequestParsing wijst requests af die met opzet dubbelzinnig zijn, zoals een bericht dat zowel Content-Length als Transfer-Encoding: chunked bevat (de klassieke request-smuggling-vector) of een negatieve chunkgrootte, en antwoordt met 400 Bad Request. De lus voor chunked trailer-headers is nu eveneens begrensd, zodat een aanvaller een verbinding niet langer open kan houden met een oneindige stroom trailer-regels.

oServer.MaxRequestBodySize := 10 * 1024 * 1024;  // 10 MB, else 413
oServer.MaxHeaderTotalSize := 64 * 1024;         // 64 KB, else 431
oServer.StrictRequestParsing := True;            // reject CL+TE smuggling, else 400

Op de ruwe TCP-laag begrenst TIdIOHandler.MaxInputBufferSize de cumulatieve invoerbuffer voor elk protocol dat op de IOHandler is gebouwd, waardoor een length-prefixed read of een te grote regel de buffer niet onbeperkt kan laten groeien.

// inside OnConnect / OnExecute of any Indy server
AContext.Connection.IOHandler.MaxInputBufferSize := 1024 * 1024;  // 1 MB cap

Optioneel door ontwerp

Geen van deze opties wijzigt het standaardgedrag. De velden staan allemaal standaard uit (0 voor de grootte- en timeoutlimieten, False voor de booleaanse vlaggen), zodat een project dat naar 2026.6 upgradet zich precies zo gedraagt als op 2026.5. U schakelt exact de beschermingen in die uw deployment nodig heeft, en dezelfde code compileert over Delphi 7 tot en met RAD Studio 13 en Free Pascal.

Ook in deze release

2026.6 introduceert de eerste ML-KEM-768 post-quantum inkapselings- en ontkapselingsprimitieven, beschikbaar op OpenSSL 3.5 en later. Ze bieden een eenvoudige TBytes-API zodat u een post-quantum sleutelinkapselingsstap kunt inpassen in een hybride handshake naast de klassieke ECDH-uitwisseling.

Aan de buildkant mislukt het compileren van C++Builder-packages niet langer met de MSBuild-fout MSB1008 wanneer RAD Studio is geïnstalleerd in een pad dat spaties bevat. De parameter DCC_BpiOutput wordt nu tussen aanhalingstekens geplaatst.

Upgraden

2026.6 is een drop-in upgrade. Er zijn geen breaking changes en er valt niets te migreren, omdat elke nieuwe bescherming optioneel is. Bekijk de bovenstaande snippets en schakel de opties in die bij uw server passen.

sgcIndy is gratis. Download de nieuwste build van esegece.com/products/sgcindy/download.

Vragen, feedback of hulp bij het versterken van uw server? Neem contact op, u krijgt een antwoord van de mensen die de code hebben geschreven.