Indy & OpenSSL 1.1.1 & TLS 1.3

[AWeber]

Hallo,
zunächst möchte ich mich bedanken für die hier geleistete Arbeit

Aber auch gleich mit einem kleinen Problem um die Ecke kommen. Die Reaktion denn die OpenSSL DLL's nicht vorhanden sind - ist nicht so schön bei mir kommt es dann immer zu einer Schutzverletzung - im destructor der Klasse TIdOpenSSLContextClient Soweit ich durchdebuggt habe - ist die Aufrufkette folgende:

Delphi-Quellcode:

TIdTCPClientCustom.Connect( )  --> IOHandler := nil; (bedingt durch Exception) --> TIdTCPConnection.SetIOHandler --> IdDisposeAndNil(LIOHandler); 
-->  TIdOpenSSLIOHandlerClient.Destroy --> TIdOpenSSLContextClient.Destroy

Delphi-Quellcode:

TIdTCPClientCustom.Connect( ) 
  try
    IOHandler.Open;  --> Exception weil DLL's nicht verfügbar 
  except
    if IOHandler <> nil then begin
      IOHandler.Close;
      if ManagedIOHandler then begin
         // Mein IOHandler ist ManagedIOHandler = true! (bedingt durch anderen Code zuvor)
         IOHandler := nil; // RLebeau - SetIOHandler() will free the IOHandler
      end;
    end;
    raise;
  end;

Das Set IOhandler = nil führt dann zu:

Delphi-Quellcode:

 procedure TIdTCPConnection.SetIOHandler(AValue: TIdIOHandler);
    if ManagedIOHandler then begin
      if Assigned(LIOHandler) then begin
        FIOHandler := nil;
        -- Zugriffsfehler im Destructor des IOHandlers
        IdDisposeAndNil(LIOHandler); 
      end;
      ManagedIOHandler := False;
    end;

Delphi-Quellcode:

destructor TIdOpenSSLIOHandlerClient.Destroy;
  FContext.Free();  --> Zugriffsfehler

Delphi-Quellcode:

destructor TIdOpenSSLContextClient.Destroy;
  OpenSSLContext ist hier noch nil
  und die Methoden  / Funktionszeiger
  -> SSL_CTX_sess_set_remove_cb
  -> SSL_CTX_sess_set_new_cb ebenso... da DLL ja nicht gefunden wurde

Meine Lösung sieht jetzt so aus ich ändere die Routine:

Delphi-Quellcode:

procedure TIdOpenSSLIOHandlerClient.EnsureContext;
begin
  // schlägt das Laden der DLL fehl ist FContext noch <nil> und der Aufruf des TIdOpenSSLContextClient.Destroy entfällt.
  EnsureOpenSSLLoaded();

  if not Assigned(FContext) then
     FContext := TIdOpenSSLContextClient.Create();
  
  // EnsureOpenSSLLoaded(); --> führt ggf. zu Exception, wo FContext welches nicht komplett initialsiert ist abgeräumt wird 
  try
    BeforeInitContext(FContext);
    TIdOpenSSLContextClient(FContext).Init(FOptions);
    AfterInitContext(FContext);
  except
    on E: EExternalException do
    begin
      try
        FreeAndNil(FContext);
      except
        on E: EExternalException do ; // Nothing
      end;
      raise EIdOpenSSLLoadError.Create('Failed to load OpenSSL');
    end;
  end;
end;

ist das so der richtige Weg?

Nachtrag:

in der Funktion TOpenSSLLoader.Load steckt leider auch ein Bug, auch wenn diese Funktion beim ersten Versuch sauber false liefert wenn die DLL's nicht geladen werden konnten, liefert einer 2. Aufruf true - auch wenn die DLL's immer noch nicht da sind... daher habe ich folgende geändert:

if not Result then
begin
// bei weiterem Aufruf nochmal versuchen die DLL's zu laden...
FLoadCount.Decrement();
Exit;
end;




André

[THonscha]

Hat sich bei Indy etwas mit dem TLS 1.3 Support getan? Gibt es eine Delphi Version, die das out of the box unterstützt?

[Thomasl]

Ich habe es auch ans laufen bekommen.
Eine Frage, die IdOpenSSLConsts.pas kann man die wie hier auf die 3er DLL´s umbenennen?
Oder gibt es da noch Probleme.
Muss SSLDLLVers auch angepasst werden?
Es Funktioniert so wie hier

Delphi-Quellcode:

unit IdOpenSSLConsts;

interface

{$i IdCompilerDefines.inc}

const
  CLibCryptoRaw = 'libcrypto';
  CLibSSLRaw = 'libssl';

  SSLDLLVers: array [0..1] of string = ('', '.1.1');

  CLibCrypto =
 //   {$IFDEF CPU32}CLibCryptoRaw + '-1_1.dll'{$ENDIF}
 //   {$IFDEF CPU64}CLibCryptoRaw + '-1_1-x64.dll'{$ENDIF}
    {$IFDEF CPU32}CLibCryptoRaw + '-3.dll'{$ENDIF}
    {$IFDEF CPU64}CLibCryptoRaw + '-3-x64.dll'{$ENDIF}
    ;
  CLibSSL =
//    {$IFDEF CPU32}CLibSSLRaw + '-1_1.dll'{$ENDIF}
//    {$IFDEF CPU64}CLibSSLRaw + '-1_1-x64.dll'{$ENDIF}
    {$IFDEF CPU32}CLibSSLRaw + '-3.dll'{$ENDIF}
    {$IFDEF CPU64}CLibSSLRaw + '-3-x64.dll'{$ENDIF}
    ;

implementation

end.

[AWeber]

@mezen, liest du hier noch mit? Ich verwende seit einiger Zeit deinen neuen Openssl IOHandler und bin recht zufrieden damit. Jetzt bin ich an einem Punkt wo ich Mails mit S/MIME signieren und verschlüsseln möchte. Die notwendigen Funktionen dazu gibt es ja in dem Openssl Dlls. Ich würde dazu gerne die restlichen Importe ergänzen, für einige der Funktionen kommt dieses Stack genannte Konstrukt zum Einsatz, damit nicht alles mit mehr oder minder typlosen pointern machen muss habe ich den Codegenerator erweitert, so dass er auch die Stack_of defines in Delphi inline Funktionen umsetzt.
Das würde ich gerne mit der Gemeinschaft teilen, wie lautet die URL / Branch deines github repositories?
Ich würde davon einen Branch machen und meinen Änderungen dort einstellen, ggf. kannst du das ja mergen?

[mjustin]

Zitat von AWeber:

Das würde ich gerne mit der Gemeinschaft teilen, wie lautet die URL / Branch deines github repositories?

Das wird vermutlich dieser hier sein,

https://github.com/mezen/Indy/tree/NewOpenSSL_PR

oder dieser:

https://github.com/mezen/Indy/tree/NewOpenSSL

[Apfelmus]

Hallo zusammen,
ich breche mir seit Tagen die Finger, um folgende Anforderung umsetzen zu können:

Wir haben einen Rest-Webservice laufen, der mit Indy entwickelt wurde.
Diesen WS ruft unser SAP auf, um uns Daten (IDOC) zu übermitteln.

Aus Sicherheitsgründen soll nun auf der SAP-Seite "EMS" (Extended Master Secret) verwendet werden.
AFAIK funktioniert das nur mit OpenSSL 1.1.1.

Die Binaries dafür habe ich, aber ich stehe irgendwie komplett auf dem Schlauch, was ich jetzt für Indy 10 unter 10.1 Berlin alles herunterladen, patchen usw. muss.

Kann mir da jemand Schritt für Schritt auf die Sprünge helfen?

Tausend Dank im Voraus!

[mjustin]

Zitat von Apfelmus:

Kann mir da jemand Schritt für Schritt auf die Sprünge helfen?

Selbst gemacht habe ich es noch nicht, grob gesagt muss nur der Code aus dem speziellen GitHub Branch heruntergeladen werden. Dieser wird dann im Projekt eingebunden. Dazu muss normalerweise nicht die Indy Package Installation in der IDE erfolgen, es müssen nur die Verzeichnisse im Projekt-Suchpfad eingetragen werden.

Eventuell hilft es, zuerst ein separates Testprojekt zu erstellen, und damit einen Verbindungsaufbau zu einem TLS 1.3 Server zu probieren.

Alternativ kann auch ein kommerzieller SSL Handler verwendet werden. Der wird dann in Indy einfach anstelle des normalen Indy Handlers zugewiesen.

Die werden z.B. hier genannt:
https://www.delphipraxis.net/211132-...secureblackbox

[Apfelmus]

Den Code aus dem Repo hab' ich.
Die Idee war, einfach den "alten" IOHandler durch den neuen (TIdOpenSSLIOHandlerServer) zu ersetzen.
Da unser WS als Server fungiert klang das naheliegend.
War wohl zu einfach gedacht. Die Behebung eines Problems macht gleich 2 neue auf.

Code:

[dcc32 Fehler] IdOpenSSLHeaders_async.pas(70): E2003 Undeklarierter Bezeichner: 'TIdC_SIZET'

Der Typ ist in idGlobal definiert, in IdOpenSSLHeaders_async wird auf idGlobal verwiesen und das Verzeichnis steht im Suchpfad des Projektes.
Natürlich kann ich jetzt idGlobal in das Projekt mit aufnehmen. Dann kommt der nächste Fehler:

Code:

[dcc32 Fehler] IdOpenSSLHeaders_bio.pas(284): E2003 Undeklarierter Bezeichner: 'TIdC_SIZET'

Das kann aber nicht Sinn und Zweck der Übung sein.
Irgendwie krieg' ich das jetzt nicht mehr gewechselt ...

[mjustin]

Zitat von Apfelmus:

Code:

[dcc32 Fehler] IdOpenSSLHeaders_async.pas(70): E2003 Undeklarierter Bezeichner: 'TIdC_SIZET'

Der Typ ist in idGlobal definiert, in IdOpenSSLHeaders_async wird auf idGlobal verwiesen und das Verzeichnis steht im Suchpfad des Projektes.

Ich versuche das zu reproduzieren. Schritte:

1. Download und Entpacken von https://github.com/mezen/Indy/archiv...OpenSSL_PR.zip
2. Suchpfade im Projekt eintragen: ...\Lib\Core;...\Lib\Protocols;...\Lib\System;...\ Lib\Protocols\OpenSSL;...\Lib\Protocols\OpenSSL\dy namic

Wenn ich nun IOHandlerServer := TIdOpenSSLIOHandlerServer.Create; verwende, kompiliert das Projekt ohne Fehler.

Ich vermute, entweder ist der Projektsuchpfad nicht korrekt oder es werden Units im Projektsuchpfad gefunden, die aus einer anderen Indy-Version kommen.

[Apfelmus]

Zitat von mjustin:

... oder es werden Units im Projektsuchpfad gefunden, die aus einer anderen Indy-Version kommen.

Hmmm, das dürften vermutlich die mit Delphi installierten Teile aus Indy sein. Die stehen ja im PATH.
Ich versuche mal, die temporär woanders hinzuschieben ...