Hallo,

Mein Programm stellt einen rudimentären WebServer bereit, über den auf die Daten zugegriffen werdne kann.
Das ganze ist mit TidHttpServer realisiert und funktioniert auch soweit sehr gut.
Nun möchte ich die Verbindung absichern und nutze dazu den TidServerIOHandlerSSLOpenSSL. Auch das funktioniert soweit.

Aber bei zwei Dingen bin ich mir unsicher:

- Damit das ganze funktioniert, brauche ich ein Zertifikat. Aktuell verwende ich ein 'Self-Signed' Zertifikat, was natürlich die entsprechende Warnung im Browser aufruft. Ein 'gutes' Zertifikat zu verwenden, würde ja dazu führen, dass jeder, wenn er das Passwort kennt (das ja die Software auch kennen muss), sich mit dem Zertifikat als TomyN ausgeben könnte. Gibt es da eine sinnvolle Lösung oder sollte ich damit leben? Macht es evtl. Sinn bei der Installation / ersten Start auf dem Rechner des Users ein self-signed Zertifikat zu erstellen und zu verwenden?

- Das andere ist die Verschlüsselung der Übertragung, die mit dem self-signed Zertifikat funktioniert (zumindest verhält sich der Browser so, als wäre die Verbindung verschlüsselt). Kann man diese Verschlüsselung auch auf eine Übertragung, d.h. http (Port 80) statt https (Port 443) verwenden?

Tomy

Das Problem daran ist, dass ein solches Zertifikat nur dann etwas bringt, wenn der Nutzer es im Browser (oder ein eigener Client) auch als korrekt erkennen kann. Das funktioniert nur mit einem jeweils passenden Zertifikat, nicht mit einem "Generalzertifikat".

Nutzt du ein selbst signiertes Zertifikat, kann man nicht erkennen, wenn sich jemand mit einem Proxy dazwischen setzt. Denn derjenige würde dann ja auch wieder ein selbst signiertes Zertifikat präsentieren. Dadurch kann er die Kommunikation komplett mitlesen.

Das machen übrigens z.B. manche Antivirenprogramme, um auch verschlüsselte Kommunikation zu scannen. Probleme macht das, wenn auf der anderen Seite nicht nur geprüft wird, ob da ein Zertifikat ist, sondern auch, ob es das richtige ist. Dann klappt die Kommunikation nicht mehr.

Den Port kannst du frei wählen, aber dieser muss dann natürlich in der URL explizit angegeben werden. Da die Standardports oft schon belegt sind, sollte der Nutzer natürlich auch selbst einen wählen können.

Man kann sich auch selbst ein Zertifikat für SSL erstellen,
aber dann muß man es auch im ZertifikateStore des Browsers registrieren.
Also genauso, wie bei den Code Signing Zertifikaten, wo Windows das Zertifikat kennen muß (den Public-Teil ... das Private kennt nur der Server)

Zertifikate, wie z.B. von [GOOGLE]Let's Encrypt[/GOOGLE] haben aber den Vorteil, dass sie von einem Root-Zertifikat abgeleitet sind, welches der Browser schon kennt und damit dann auch dein Zertifikat als vertrauenswürdig erachtet.

Um dort (und auch bei anderen Anbietern) ein Zertifikat zu bekommen, muß dein Server "meistens" öffentlich über eine Domain erreichbar sein (zumindestens für die Zeit der Ausstellung des Zertifikates).
Und der Server muß auch über diese Domain angesprochen werden (die angerufene Adresse muß mit der/denen übereinstimmen, welche im Zertifikat angegeben sind) ... ja, das kann auch ein lokaler Server sein, wenn man ihn über die öffentliche Domain aufruft (oder z.B. via Direktleitung, welche man z.B. in HOSTS einträgt, wenn die öffentliche Auflösung von DOMAIN zu IP nicht geht, oder nicht gemacht werden soll)

Danke für die Rückmeldungen

Ich halte mal fest:
- Dem Nutzer eine Möglichkeit geben, ein eigenes Zertifikat zuzuweisen
- Ports frei wählbar machen, mit entsprechenden Defaults.

Der eigentliche Grund dieser Frage war ein anderer: Da die Anzeige z.B. auf Mobilgeräten länger zu sehen sein soll, nutze ich in javascript wakeLock. Das lässt der Browser aber nur dann zu, wenn die Verbindung gesichert ist (der Server muss aber nicht 'zertifiziert' sein). D.h. wenn ich die Verbindung über https:// anstoße, dann kommt zwar der Hinweis, dass das zertifikat nicht akzeptiert wird, die Vergindung läuft aber anscheinend doch verschlüsselt, denn wakeLog steht zur Verfügung (getestet auf chrome auf dem Android Smartphon und firefox auf dem win10 Pc). Baue ich die Verbindung über http:// auf, dann wird zwar nicht gemotzt, aber wakeLock steht nicht zur Verfügung.

Ich würde mir daher einen Weg wünschen, die Übertragung sicher zu machen, so dass der Browser wakeLock zulässt und das ungültige Zertifikat nicth anmotzt.

"Ich wünsche mir, dass der Browser das ungültige Zertifikat nicht bemängelt".

Halte mal zehn Sekunden inne und überlege, ob es wirklich einen Weg geben sollte, dass so etwas möglich wäre.

1,2,3,4,5,6,7,8,9,10

Schöne Grüße an den schönen Günther

Ist vielleicht etwas doof formuliert. Es wäre okay, wenn der Browser sich wie bei einer http:// Verbindgung verhält, d.h. in der Adresszeile einen Hinweis ausgibt, dass die Adresse unsicher ist, aber er trotzdem eine gesichterte Übertragung durchführt, oder auf eine andere Weise wakeLock funktioniert.

Es gibt doch unmengen von Programmen, deren Bedienung / Visualisierung über einen Browser erfolgt, wie machen die das?

Laufen der Webserver und der Browser auf unterschiedlichen Rechnern?

Ist es der gleiche, könnte das "WakeLock" vielleicht über Delphi umgesetzt und eine ungesicherte Verbindung genutzt werden.

Und welcher Browser wird verwendet?

Chrome bietet unter chrome://flags die Option, sichere Verbindungen über localhost auch mit selbst erstelltem Zertifikat zuzulassen, siehe #allow-insecure-localhost.

Ansonsten kann ich doch im Browser die Zertifikatswarnung ignorieren. Bei Chrome mit Klick auf "Erweitert" und "Weiter zu [hostname] (unsicher)". Reicht das nicht?

Bei anderen Programmen, wo die Visualisierung über den Browser verläuft, reicht im lokalen Betrieb eine ungesicherte Verbindung oder der Browser wird eingebaut in die Anwendung.
Wenn der Server im Firmennetz läuft, nutzt man ggf. die lokale Zertifizierungsstelle des Windows-Servers, um selbstsignierte Zertifikate zu erstellen, die im lokalen Netz akzeptiert werden.

Also, für deine Funktion brauchst du einen "Secure Context". Wie du den bekommst, hängt davon ab, ob deine Anwedung auf einem übers Web erreichbaren Server liegt und aufgerufen werden soll oder nicht. Zum Hintergrund siehe hier: https://developer.mozilla.org/en-US/...ecure_Contexts

Wenn deine Anwendung nur in einem lokalen Netz erreichbar sein soll, dann wird auch alles, was irgendwie auf *.localhost endet, als sicher betrachtet. Du könntest deinen Server also unter http://wuppdi.localhost erreichbar machen - dann brauchst du kein SSL/TLS und bist das ganze Thema los.

Wenn dein Server nicht nur lokal erreichbar ist, dann brauchst du ein "richtiges" Zertifikat. Am einfachsten bekommt man das heutzutage mit Let's encrypt.

Vielleicht sind da ja mal ein paar hilfreiche Stichworte dabei.

Zitat von Bbommel:

Wenn deine Anwendung nur in einem lokalen Netz erreichbar sein soll, dann wird auch alles, was irgendwie auf *.localhost endet, als sicher betrachtet. Du könntest deinen Server also unter http://wuppdi.localhost erreichbar machen - dann brauchst du kein SSL/TLS und bist das ganze Thema los.
...
Vielleicht sind da ja mal ein paar hilfreiche Stichworte dabei.

Also auch, wenn ich nicht der Fragesteller war, mir hat's geholfen. Wieder was gelernt, danke! Secure Context mit *.localhost kannte ich noch nicht.

Wobei das dem originalen Fragesteller wahrscheinlich nicht weiterhilft. Alles unter *.localhost sollte eine Loopback-Adresse sein, was die Browser sicherstellen müssen. Das heißt, du kannst das so tatsächlich nur auf dem lokalen Rechner benutzen, wenn ich die Spezifikationen richtig verstanden habe.

Für alles andere wird man um ein Zertifikat nicht herum kommen.