SSL Server

[TomyN]

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

[jaenicke]

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.

[himitsu]

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)

[TomyN]

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.

[Der schöne Günther]

"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.

[TomyN]

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?