HTTPS-Server in eigener Anwendung

**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 von 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

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 von mjustin:

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 von Hobbycoder:

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 von BrightAngel:

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 von Hobbycoder:

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:

markieren

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:

markieren

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:

markieren

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 von Hobbycoder:

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 von Hobbycoder:

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 von Hobbycoder:

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 von AndyDF:

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:

markieren

Delphi-Quellcode:

			  //OpenSSL Patchen...

  SSL_CTX_patch(IdServerIOHandlerSSLOpenSSL.SSLContext.InternalContext);

Das führt bei mir zu einer Zugriffsverletzung.

markieren

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:

markieren

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 von Hobbycoder:

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?