HTTPS-Server in eigener Anwendung

[Hobbycoder]

Hi,

ich habe in meinem Projekt einen kleinen Mini-HTTP-Server über Indy integriert. Jetzt will ich den noch mit einer SSL-Option versehen. Über OpenSSL habe ich mir ein passendes Zertifikat nach diesem Thread erstellt. Seite wird aufgerufen, alles gut.

Bis auf die Tatsache, dass der Browser einen Zertifikatsfehler meldet und mir sagt, dass mein Zertifikat ungültig ist.

Nun möchte ich auch, dass jeder, der dieses Programm betreibt, eigene Zertifikate hinterlegen kann. Und das natürlich auch ohne weitere Kosten (das Prog selbst soll auch nichts kosten).

Wie wäre jetzt das richtige Vorgehen? Muss man so ein Zertifikat irgendwo kaufen, oder kann man sich das quasi selber signieren? Es geht im Grunde nur darum die Datenübertragung abzusichern, sprich zu Verschlüsseln. (Ist zwar von den Informationen, die dort übertragen werden, nicht wirklich zwingend notwendig, aber a) sieht's schick aus und b) wollte ich das einfach mal machen).
Das ganze Thema ist doch leider etwas kompliziert.
Ich bräuchte da mal jemand, der mir ein wenig dir Richtung zeigt.

Ich habe dann noch das https://forums.embarcadero.com/threa...hreadID=105763 gefunden, ich weiß aber nicht ob das Programm mein Problem lösen kann. Kann man damit seine Zertifikate selber signieren, so dass sie gültig sind?

Sorry für die dumme Frage, aber ich habe mit dem Thema mangels Notwendigkeit noch nie wirklich beschäftigt.

Desweiteren bekomme ich immer mal wieder, wenn der HTTP-Server das erste Mal von einem Client angefragt wird, die Fehler Meldung EIdOSSLUnderlyingCryptoError. Bestätige ich die aber im Programm und lasse es einfach weiterlaufen, so wird die Seite korrekt angezeigt.

[Bernhard Geyer]

Ist dieser Mini-http-Server nur für den lokalen Zugriff freigeschaltet (wie mittlerweile viele Programme machen) oder willst du hier wirklich LAN-Weit deine Lösung bereit stellen.

Falls es nur eine lokaler Webserver ist - Was für einen Vorteil erwartest du wenn du den Zugriff über https ermöglichst?
Welches Angriffsszenario will du hier ausschalten?

[Hobbycoder]

Nein, natürlich Lan-Weit bzw. über Port-Freischaltung auch aus dem I-Net. Sonst könnte ich mir den kram ja auch sparen.
Es geht dabei darum, bestimmte Daten auch per Handy abzurufen, und wenn der Nutzer das über seinen Router freigibt auch aus dem Internet.

[Olli73]

Hier mal mein Halbwissen dazu: Im Browser oder Betriebssystem sind gültige Zertifizierungsstellen hinterlegt, von denen ausgestellte Zertifikate akzeptiert werden. Von diesen kann man dann ein Zertifikat kaufen, welches direkt als gültig betrachtet wird. Selbst ausgestellten Zertifikaten fehlt diese vertrauenswürdige Zertifizierungsstelle, deshalb wird ihnen misstraut und es kommt ein Fehler. Du kannst dein Zertifikat aber irgendwie manuell im Browser/OS eintragen, damit auch dieses als gültig betrachtet wird.

[Hobbycoder]

Danke für den Hinweis.

Ich habe das Zertifikat mal importiert und dann mittel mmc in die Vertrauenwürdigen Zertifikate verschoben.
Jetzt Zeit mir der IE schon mal, dass mein Zertifikat gültig ist. Aber ich habe immer noch die URL rot hinterlegt und daneben "Zertifikatfehler" stehen. Um was für einen Fehler es sich handelt, will mir IE nicht preisgeben. Schön wäre es, wenn man es hinbekäme, das dir URL grün wird.

Es wäre ja auch praktisch, wenn man das Clients, ohne gültiges Zertifikat gleich mal anweisen könnte. Also nur die Clients reinlassen, die ihrerseits das Zertifikat bereits vorliegen haben. Spannende Frage: Kann man das mit Indy machen?

[Hobbycoder]

Auch bekomme ich dann im Programm immer eine Exception (s.Bild im Anhang) EIdOSSLAcceptError, dessen Ursache ich mir nicht erklären kann. Das kann, muss aber nicht, damit in Verbindung stehen.

[Sherlock]

Der Zertifikatsfehler dürfte weiterhin auf die selbstgemachte Herkunft hinweisen.

Noch eine Portion Halbwissen von mir: Wenn Du das Ding wirklich ins Internet stellst, darfst Du Dich eine völlig neue Dimension des Schmerzes freuen.

Ich hoffe sehr, daß Du regelmäßig und vollständig Backups von all Deinen Rechnern ziehst.

Sherlock

[Hobbycoder]

Zitat:

Zitat von Sherlock (Beitrag 1372298)

Noch eine Portion Halbwissen von mir: Wenn Du das Ding wirklich ins Internet stellst, darfst Du Dich eine völlig neue Dimension des Schmerzes freuen.
Ich hoffe sehr, daß Du regelmäßig und vollständig Backups von all Deinen Rechnern ziehst.

Warum? Der HTTP-Server verfügt über keinerlei Möglichkeiten Daten oder Steuerungsbefehle entgegen zu nehmen. Er liefert lediglich über OnCommand im Programm statisch erzeugte, minmalistische Webseiten, die Information über bestimmte Zustände bzw. eine JPG-Grafik liefert. In wie weit sollte das dann einen neue Dimension des Schmerzes erzeugen? Ich will ja keinen richtigen Web-Server bauen.


Und zurück zum Thema:
Hier mal etwas von dem Source, vielleicht habe ich da ja schon einen eklatanten Fehler drin:

Delphi-Quellcode:

  FIdServerIOHandlerSSLOpenSLL:=TIdServerIOHandlerSSLOpenSSL.Create(nil);
  FIdServerIOHandlerSSLOpenSLL.OnGetPassword:=IdSSLIOHandlerSocketOpenSSL1GetPassword;
  FIdServerIOHandlerSSLOpenSLL.SSLOptions.Method:=sslvSSLv23;
  FIdServerIOHandlerSSLOpenSLL.SSLOptions.Mode:=sslmServer;
  FIdServerIOHandlerSSLOpenSLL.SSLOptions.CertFile:=ExtractFilePath(Self.FPicdefFilename)+'testzertifikat.crt';
  FIdServerIOHandlerSSLOpenSLL.SSLOptions.KeyFile:=ExtractFilePath(Self.FPicdefFilename)+'testzertifikat.key';
  FIdServerIOHandlerSSLOpenSLL.SSLOptions.RootCertFile:=ExtractFilePath(Self.FPicdefFilename)+'testzertifikat.pem';

  // FIdServerIOHandlerSSLOpenSLL.SSLOptions.VerifyDepth := 1;
  // FIdServerIOHandlerSSLOpenSLL.SSLOptions.VerifyMode := [sslvrfPeer,sslvrfFailIfNoPeerCert,sslvrfClientOnce];

  FHTTP:=TIdHTTPServer.Create(nil);
  FHTTP.IOHandler:=FIdServerIOHandlerSSLOpenSLL;
  FHTTP.AutoStartSession:=True;
  FHTTP.SessionState:=True;
  FHTTP.ParseParams:=True;
  FHTTP.Bindings.Clear;
  for i:=0 to FIPs.Count-1 do
  begin
    if (Self.FPort>0) then
    begin
      with FHTTP.Bindings.Add do
      begin
        IP:=FIPs[i];
        Port:=Self.FPort;
      end;
    end;
    if (self.FSSLPort>0) then
    begin
      with FHTTP.Bindings.Add do
      begin
        IP:=FIPs[i];
        Port:=FSSLPort;
      end;
    end;
  end;
  FHTTP.OnCommandGet:=OnCommandGet;
  try
    DoOnHTTPStart;
    FHTTP.Active:=True;

[mjustin]

Zitat:

Zitat von Hobbycoder (Beitrag 1372296)

Danke für den Hinweis.

Ich habe das Zertifikat mal importiert und dann mittel mmc in die Vertrauenwürdigen Zertifikate verschoben.
Jetzt Zeit mir der IE schon mal, dass mein Zertifikat gültig ist. Aber ich habe immer noch die URL rot hinterlegt und daneben "Zertifikatfehler" stehen. Um was für einen Fehler es sich handelt, will mir IE nicht preisgeben. Schön wäre es, wenn man es hinbekäme, das dir URL grün wird.

Falls IE da nichts preisgibt, würde ich einen anderen (z.B. den Chrome Browser) verwenden, und schauen ob er eine detailliertere Fehlermeldung ausgibt.

Sehr praktisch ist auch der Test unter https://www.ssllabs.com/ssltest/analyze.html, da werden für deinen Server gleich auch entdeckte Sicherheitslücken angezeigt. Voraussetzung ist dafür allerdings, dass der Server im Internet erreichbar ist.

[Olli73]

Was für eine Verschlüsselung/Verfahren verwendest du denn? Da wird nicht mehr alles als sicher betrachtet.

[Hobbycoder]

Danke, das werde ich mal ausprobieren.

Leider hakt es noch an anderen Stellen. Ich bekomme auch oft die Meldung "EIdOSSLUnderlyingCryptoError", wenn ich auf einen Linke klicke, der auch auf meinem int. HTTP-Server zeigt. Dann springt er mich noch nicht mal mehr in die OnCommandGet-Routine. Erklären kann ich es mir zur Zeit noch nicht.
Leider finde ich auch nicht wirklich mal richtig schöne Demos bzw. Tutorials zu Indy-SSL-HTTP-Server.

[mjustin]

Zitat:

Zitat von Hobbycoder (Beitrag 1372307)

Ich bekomme auch oft die Meldung "EIdOSSLUnderlyingCryptoError", wenn ich auf einen Linke klicke, der auch auf meinem int. HTTP-Server zeigt. ... Leider finde ich auch nicht wirklich mal richtig schöne Demos bzw. Tutorials zu Indy-SSL-HTTP-Server.

Indy ist die aktuelle Version mit den neuesten OpenSSL DLLs? (z.B. von https://indy.fulgan.com/)? Sind andere (veraltete) OpenSSL DLLs im "Suchpfad"?

Schöne Demos und Tutorials müssten geschrieben werden ;)

[Hobbycoder]

ja, alles vorhanden.

Ich denke ich habe den Fehler EIdHTTPProtokolException auch gefunden. Ich hatte teilweise noch in der zurück gelieferten Webseite noch Hard-Coded-Links "http://xxx.xxx.xxx.xxx/..." drin stehen. Hab das jetzt mal gegen relative Links getauscht, dann tritt der Fehler so jedenfalls nicht mehr auf.

Ich hab auch mal das ganze mit der Seite www.ssllabs.com getestet. Aus allem was das steht werde ich nicht schlau ;-) ist ja ne ganze Menge.
Und das das Zertifikat grundsätzlich ungültig wäre, hat er auch nicht gesagt. Allerdings meckert er den "common Name" als Mismatch an. Da habe ich einfach mal meinen Realnamen verwendet. Auch bei trusted steht "Not Trusted" was aber klar ist.

Ich hänge mal Bilder von dem Bericht an. Falls jemand draufschauen mag.

Wenn's mal richtig läuft, mach ich daraus vielleicht ein Tutorial (zumindest aber stell ich mal den Source hier irgend ein, damit sich andere daraus was abschauen können).

[mjustin]

Ja, den Poodle (SSLv3 Support) sollte man abschalten ;) Bei Indy ist dazu SSLOptions.Method:=sslvSSLv23; auszutauschen gegen etwas anderes (TLS1.2 ist der aktuellste Level).

[Hobbycoder]

Zitat:

Zitat von mjustin (Beitrag 1372325)

Ja, den Poodle (SSLv3 Support) sollte man abschalten ;) Bei Indy ist dazu SSLOptions.Method:=sslvSSLv23; auszutauschen gegen etwas anderes (TLS1.2 ist der aktuellste Level).

Interessant ;-) Wär ich so nicht drauf gekommen. Danke.

[mjustin]

Noch ein Tip (von http://stackoverflow.com/a/39499131/6517492):
Den Suchpfad für die OpenSSL DLL kann man in Indy genau angeben:

Delphi-Quellcode:

IdOpenSSLSetLibPath(ExtractFilePath(ParamStr(0)));

Ich habe es selbst nicht getestet, eventuell könnte man so auch verhindern, dass andere DLLs als die gewünscht geladen werden.

[Hobbycoder]

Das ist auf jeden Fall auch nicht uninteressant ;-)

[BrightAngel]

Hey :)

Stichwort letsencrypt.org: Die signieren kostenfrei und die CA ist in den großen Browsern deployed. Voraussetzungen: ein DNS Eintrag auf deine IP mit dem Namen der im Common Name deines Certs steht und ein Service, der auf den .well-known Pfad hört und eben generell das Erneuern der kurzlebigen (glaube 90 Tage) Zertifikate automatisch reagiert.

Da du dem Benutzer vermutlich die Certs ohnehin in ein Verzeichnis legen dürftest, kannst du es auch einfach dem Benutzer überlassen, wie er an ein signiertes Cert kommt. Deployed zum Browser muss immer die komplette Zertifikatskette werden.

Brighty

[Hobbycoder]

Zitat:

Zitat von BrightAngel (Beitrag 1372333)

Da du dem Benutzer vermutlich die Certs ohnehin in ein Verzeichnis legen dürftest, kannst du es auch einfach dem Benutzer überlassen, wie er an ein signiertes Cert kommt.

So war der Plan :-D Funktioniert das auch mit Dyndns-Domain's (o.ä.)?

[BrightAngel]

Afaik ist das so, dass bei dem Zertifizierungsprozess ein Serverprogramm let's encrypt bittet zu signieren. Damit die wissen, dass sie der Bitte nachkommen dürfen fragen die entweder per DNS oder per http url ein security token (weiß nicht was genau das ist; vmtl ne signatur) ab, das auch bei der Zertifizierungsbitte mitgeteilt wurde. Ist das Zertifikat signiert landet es in der Antwort von Let's encrypt. Dann hat man ganz normal ein signiertes Cert auf Platte. Welche IP das dann benutzt ist vmtl egal, also sollte es mit dyndns gehen. Der common Name muss übereinstimmen. Seitenbemerkung: Let's encrypt kann keine Wildcards.

Brighty

[mjustin]

Noch ein Tipp: als Aufsatz auf den Indy HTTP Server habe ich dieses Open Source Framework geschrieben, mit dem sich HTTP Requests leichter mit dem eigenen Code verknüpfen lassen:
[Werbung]
HTTP Server Framework für Object Pascal - nun auf GitHub
[/Werbung]
Es sollte im Prinzip auch mit HTTPS einsetzbar sein werden, da der interne Indy HTTP Server über eine Property angesprochen werden kann. (In der Praxis wird oft ein Apache HTTP Server als Reverse Proxy eingesetzt, der die Verschlüsselung erledigt)

Homepage: https://www.habarisoft.com/daraja_framework.html
Github-Projekt: https://github.com/michaelJustin/daraja-framework

[Hobbycoder]

Zitat:

Zitat von BrightAngel (Beitrag 1372336)

Afaik ist das so, dass bei dem Zertifizierungsprozess ein Serverprogramm let's encrypt bittet zu signieren. Damit die wissen, dass sie der Bitte nachkommen dürfen fragen die entweder per DNS oder per http url ein security token (weiß nicht was genau das ist; vmtl ne signatur) ab, das auch bei der Zertifizierungsbitte mitgeteilt wurde. Ist das Zertifikat signiert landet es in der Antwort von Let's encrypt. Dann hat man ganz normal ein signiertes Cert auf Platte. Welche IP das dann benutzt ist vmtl egal, also sollte es mit dyndns gehen. Der common Name muss übereinstimmen. Seitenbemerkung: Let's encrypt kann keine Wildcards.

Brighty

So ganz Verstanden habe ich den ganzen Signierungsprozess jetzt zwar noch nicht, aber ich werde das einfach mal ausprobieren. Ist das wirklich zu 100% kostenlos?

Zitat:

Zitat von mjustin (Beitrag 1372353)

Noch ein Tipp: als Aufsatz auf den Indy HTTP Server habe ich dieses Open Source Framework geschrieben

Danke für den Hinweis. Das, was dort als Webseite angeboten bzw. übertragen wird, ist sehr überschaubar, und soll auch nicht vom User verändert bzw. erweitert werden können, weil es zu stark von den internen Funktionen abhängt. Mit irgendwelchen eigenen Seite würde ich dann nur wieder genau das Realisieren, worauf Sherlock hingewiesen hat. Einzige Eingriffsmöglichkeiten, die ich schaffen will sind a) eigenen Zertifikate und b) bearbeiten eine CSS-Files.

[BrightAngel]

Zitat:

Zitat von Hobbycoder (Beitrag 1372383)

So ganz Verstanden habe ich den ganzen Signierungsprozess jetzt zwar noch nicht, aber ich werde das einfach mal ausprobieren. Ist das wirklich zu 100% kostenlos?

Ja, also die finanzieren sich afaik durch Spenden. Einziger Nachteil: Das ACME Protocol (mit dem automatisiert zertifiziert wird) hat im Moment mit dem Certbot nur Unixe im Ziel. Der Protocolstandard ist noch nicht final, aber die Sache ist hier beschrieben und es ist offen. Ich habe jetzt auf Anhieb tatsächlich keine Delphi Library bzw. kein Projekt gefunden, das sich der Implementierung in Delphi angenommen hat...
Das könnte man bei Interesse vllt in einem neuen Thread mal beginnen und auf github oder so stellen :)
Und wenn es nur Wrapper für ne C Lib sind...

Brighty

[mjustin]

Zitat:

Zitat von BrightAngel (Beitrag 1372440)

Ich habe jetzt auf Anhieb tatsächlich keine Delphi Library bzw. kein Projekt gefunden, das sich der Implementierung in Delphi angenommen hat...
Das könnte man bei Interesse vllt in einem neuen Thread mal beginnen und auf github oder so stellen :)

Einige Clients sind hier verlinkt:

https://letsencrypt.org/docs/client-options/

Deren Sourcecode ist vermutlich open. Für eine Portierung nach Pascal ein Startpunkt...

[AndyDF]

Zitat:

Zitat von Hobbycoder (Beitrag 1372321)

Ich hab auch mal das ganze mit der Seite www.ssllabs.com getestet. Aus allem was das steht werde ich nicht schlau ;-) ist ja ne ganze Menge.
Und das das Zertifikat grundsätzlich ungültig wäre, hat er auch nicht gesagt. Allerdings meckert er den "common Name" als Mismatch an. Da habe ich einfach mal meinen Realnamen verwendet. Auch bei trusted steht "Not Trusted" was aber klar ist.

Also ich habe damals auch eine ganze Weile rum gemacht, bis ich bei www.ssllabs.com ein vernünftiges Ranking hatte. Jetzt habe ich A. :-)

Hier ein paar Tipps, was ich gemacht habe, dass man "A" erreichen kann:

1. Hier meine Konfiguration vom TIdServerIOHandlerSSLOpenSSL:

Delphi-Quellcode:

  IdServerIOHandlerSSLOpenSSL.SSLOptions.DHParamsFile:= appDir + 'Zertifikat\dhparam.pem';
  IdServerIOHandlerSSLOpenSSL.SSLOptions.KeyFile:= appDir + 'Zertifikat\de_private_key.key';
  IdServerIOHandlerSSLOpenSSL.SSLOptions.CertFile:= appDir + 'Zertifikat\de_ssl_certificate.cer';
  IdServerIOHandlerSSLOpenSSL.SSLOptions.RootCertFile:= appDir + 'Zertifikat\de_ssl_certificate_INTERMEDIATE.cer';
  IdServerIOHandlerSSLOpenSSL.SSLOptions.SSLVersions := [sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2];
  IdServerIOHandlerSSLOpenSSL.SSLOptions.Mode := sslmServer;
  IdServerIOHandlerSSLOpenSSL.SSLOptions.CipherList := SSLDefaultCipherList;

SSLDefaultCipherList ist in der beigelegten uOpenSSLPatch Datei definiert.

2. Die dhparam.pem Datei muss mind. 1024Bit haben und wird so erstellt:

Code:

openssl dhparam -outform PEM -out dhparam.pem 1024

3. Der SSLContext vom TIdServerIOHandlerSSLOpenSSL muss gepatcht werden:

Hierzu die Source-Datei aus dem Anhang (uOpenSSLPatch.pas) verwenden und z.B. im FormCreate folgenden Befehl aufrufen:

Delphi-Quellcode:

  //OpenSSL Patchen...
  SSL_CTX_patch(IdServerIOHandlerSSLOpenSSL.SSLContext.InternalContext);

So, wenn ich jetzt nichts übersehen oder verwechselt habe müsste es bei www.ssllabs.com zu einem "A" Rating führen. :-)
Es gibt auch noch ein A+ Rating. Ich bin gerne für Tipps offen wie man das hin bekommt.

Wichtig: Das Zertifikat darf natürlich nicht self-signed sein!
Ich habe meines z.B. von 1und1. (früher StartCom, aber die sind scheinbar nicht mehr vertrauenswürdig).

[Hobbycoder]

Toll, dass du deine Erfahrungen hier zur Verfügung stellst.
Ich werde das mal mit einbauen. Mal sehen welches Ranking ich dann erreiche. T bzw. C ist ja nicht unbedingt top.

Aber ich habe mir das mal mit Let's Trust angeschaut. Der Aufwand ist mir für diese kleine Anwendung viel zu hoch.

Mein Hauptziel für den Einsatz von SSL war, dass der Transport verschlüsselt erfolgt, was jetzt ja der Fall ist. Und dazu muss es noch nicht einmal den besten Hackern mit den optimalsten Möglichkeiten standhalten, sondern es soll eben den Aufwand für das Abgreifen der Daten über den Nutzen stellen, den man dadurch hätte. Und weil es eben im Grund um unsensible Daten geht und auch keinerlei Steuerungsmöglichkeiten, ist das hier definitiv der Fall. Von da her werde ich es bei self-signed Zertifikaten belassen. Wer denn später mit meinem Programm ein offizielles, kostenverbundenes Zertifikat verwenden möchte kann es ja tun.

Aber das Thema ist so interessant, dass ich mich noch mehr damit beschäftigen möchte.

PS: Ist es wirklich notwendig TLS 1.0 und TLS 1.1 noch zu unterstützen? Halbwegs aktuelle Smartphones und Betriebssystem sollte doch mit TLS 1.2 problemlos klar kommen. Und es gibt ja bestimmt auch einen Grund, warum TLS 1.2 entwickelt wurde. Sollte das nicht zu einem höheren Sicherheitsstand führen?

Und: Könntest du noch mal erläutern was in dhparam.pem drin steht und in welchem Zusammenhang das mit dem Zertifikat / Key steht? Immerhin wird ja beim erzeugen keinerlei Bezug auf diese genommen.

[AndyDF]

Zitat:

Zitat von Hobbycoder (Beitrag 1372497)

Toll, dass du deine Erfahrungen hier zur Verfügung stellst.

Es war recht schwer damals die notwendigen Informationen zu finden. Daher ist das bestimmt eine Hilfe für andere. :-)

Zitat:

Zitat von Hobbycoder (Beitrag 1372497)

Ich werde das mal mit einbauen. Mal sehen welches Ranking ich dann erreiche. T bzw. C ist ja nicht unbedingt top.

Ja das Rating hat dann bei mir auch den Ehrgeiz geweckt. Ich wollte einfach das Rating so gut wie möglich hin bekommen. :-)

[mjustin]

Zitat:

Zitat von Hobbycoder (Beitrag 1372497)

PS: Ist es wirklich notwendig TLS 1.0 und TLS 1.1 noch zu unterstützen? Halbwegs aktuelle Smartphones und Betriebssystem sollte doch mit TLS 1.2 problemlos klar kommen. Und es gibt ja bestimmt auch einen Grund, warum TLS 1.2 entwickelt wurde. Sollte das nicht zu einem höheren Sicherheitsstand führen?

TLS 1.0 wird von Salesforce im Juli und von UPS im Dezember komplett deaktiviert. (Für Neuentwicklungen nur noch 1.2 zu unterstützen ist keine schlechte Wahl).

[Hobbycoder]

Zitat:

Zitat von AndyDF (Beitrag 1372484)

3. Der SSLContext vom TIdServerIOHandlerSSLOpenSSL muss gepatcht werden:

Hierzu die Source-Datei aus dem Anhang (uOpenSSLPatch.pas) verwenden und z.B. im FormCreate folgenden Befehl aufrufen:

Delphi-Quellcode:

  //OpenSSL Patchen...
  SSL_CTX_patch(IdServerIOHandlerSSLOpenSSL.SSLContext.InternalContext);

Das führt bei mir zu einer Zugriffsverletzung.

Delphi-Quellcode:

function TIdSSLContextHelper.InternalContext: PSSL_CTX;
begin
  Result := Self.FContext;
end;

Self ist bei mir NIL.

ich setzte das auch nicht auf eine Form, sondern habe das in einem Thread.
Ich wollte das so machen:

Delphi-Quellcode:

    FIdServerIOHandlerSSLOpenSLL:=TIdServerIOHandlerSSLOpenSSL.Create(nil);
    SSL_CTX_patch(FIdServerIOHandlerSSLOpenSLL.SSLContext.InternalContext);
    FIdServerIOHandlerSSLOpenSLL.OnGetPassword:=IdSSLIOHandlerSocketOpenSSL1GetPassword;

ich kann's natürlich auch im ThreadCreate machen, aber da gibt es mein FIdServerIOHandlerSSLOpenSSL noch gar nicht. Ich erzeuge den erst im ThreadExecute. Muss von TIdSSLContextHelper keine Instanz erzeugt werden?

[AndyDF]

Zitat:

Zitat von Hobbycoder (Beitrag 1372505)

Self ist bei mir NIL.

ich setzte das auch nicht auf eine Form, sondern habe das in einem Thread.

Das hat bestimmt irgendwas mit dem Thread zu tun. TIdSSLContextHelper ist ja ein Helper für TIdSSLContext der evtl. in dem Fall noch nicht geladen wurde.

Ich habe natürlich nur ein TIdServerIOHandlerSSLOpenSSL im Haupt-Thread (sogar direkt auf dem Formular).
Aber das reicht doch eigentlich auch? Warum den Server (inkl. IOHandler) in einem Thread anlegen?

[Hobbycoder]

Weil der Web-Server nur ein kleiner Teil der Anwendung ist, und dabei auch noch ein paar Bildberechnungen durchführt. Ist aber egal.
Sollte ja auch da gehen.

Mir ist nur nicht klar, worauf sich das self bzw. das Fcontext bezieht.

[Edit] Muss das Korrigieren. Mir ist nicht klar, warum self=Nil ist. FIdServerIOHandlerSSLOpenSLL wird ja vorher erzeugt. Von daher sollte FIdServerIOHandlerSSLOpenSLL.SSLContext.InternalCo ntext auch nicht =Nil sein. [/Edit]

[Hobbycoder]

Also mein FIdServerIOHandlerSSLOpenSLL.SSLContext ist immer Nil.
Wann wird denn der erzeugt?

Erledigt. Der SSLContext wird erst erzeugt, wenn der HTTPServer auf active gesetzt wird.

[Hobbycoder]

Okay, startet zwar, aber mit dem SSL_CTX_Patch kommt es beim Aufruf einer Seite zu einer Zugriffsverletzung und dann zu keinem Laden der Seite.
Ohne läuft's Wunderbar.

die CypherList und das DHparamsFile habe ich eingebunden. Jetzt habe ich, mal abgesehen davon das es self-signed ist, also non-Trusted, ein A (vorher: C).

Ich denke ich kann auf den SSL_CTX_Patch dann auch verzichten.

Aber nochmal: Kann irgendwer sagen, welche Auswirkungen das DHParamsFile hat bzw. dessen Schlüsselgröße?

[BrightAngel]

Zitat:

Zitat von Hobbycoder (Beitrag 1372514)

[...]
Aber nochmal: Kann irgendwer sagen, welche Auswirkungen das DHParamsFile hat bzw. dessen Schlüsselgröße?

Schau mal hier bei der Perfect forward secrecy: Diese Parameter sind aufwändig zu berechnen und daher merkt man sich diese Parameter in dieser Datei, um sie bei Verbindungen benutzen zu können. Man kann (sollte streng genommen) dieses File auch gerne öfter mal neu berechnen. Bei der PFS geht es hauptsächlich darum, dass ein temporärer Schlüssel gewählt wird, um die eigentlichen Verbindungsdaten zu schützen. Der Schlüssel hat üblicherweise nur eine begrenzte Lebensdauer und wird jedes Mal neu gewürfelt. So sind die übertragenen Nutzdaten auch sicher, wenn der authentifizierende private Schlüssel in der Zukunft kompromittiert würde und es Aufzeichnungen der verschlüsselten Verbindung gäbe: Der Sitzungsschlüssel, den man zum Beispiel über Diffie-Hellman-Verfahren würfelt ist unabhängig vom Public/Private-Key gezogen; ein Angreifer müsste also auch dieses Geheimnis erhalten, um an die Daten zu kommen.

Das war aus dem Kopf heraus getippt, daher keine Garantie für vollständige Korrektheit 😇

Brighty

[Hobbycoder]

Zitat:

Zitat von BrightAngel (Beitrag 1372529)

Das war aus dem Kopf heraus getippt, daher keine Garantie für vollständige Korrektheit 😇

Brighty

Hat meinen Kopf aber erhellt ;-) Danke für die Klarstellung.