Selbstsignierte Zertifikate - Benutzer müssen wissen, dass sie die Root CA zum vertrauenswürdigen Zertifikatspeicher hinzufügen müssen

Question

Ich habe ein Desktop-Produkt, das einen eingebetteten Webserver verwendet, der selbstsignierte Zertifizierungen verwendet.

Gibt es etwas, das ich in eine Webseite einbauen kann, um zu erkennen, dass die Root-CA nicht zur Liste der vertrauenswürdigen Organisationen hinzugefügt wurde, und um einen Link oder DIV oder etwas anderes anzuzeigen, das die Benutzer anweist, dies zu tun?

Ich denke vielleicht eine DIV, die Anweisungen zur Installation der CA hat, und ein Javascript, das einige Test läuft (versucht, etwas ohne interne Warnungen zugreifen??), und versteckt die DIV, wenn der Test erfolgreich ist. Oder etwas in der Art...

Irgendwelche Ideen aus der brillanten SO-Gemeinschaft? :)

Answer 1

Da der Server auf dem Client-Rechner (Desktop-Produkt) läuft, kann er nicht die unterstützten Browser mithilfe von Winapi/os-Funktionen auf installierte Zertifikate überprüfen? Ich weiß, dass Firefox eine Zertifikatsdatenbank im Profilverzeichnis des Benutzers hat und der IE wahrscheinlich Informationen in der Registry speichert. Es wäre nicht für alle Browser zuverlässig, aber wenn der Server einfach zwischen "Zertifikat gefunden" und "Bitte stellen Sie sicher, dass Sie das Zertifikat installiert haben, bevor Sie fortfahren" wählt, dann wird kein Schaden angerichtet, da der Benutzer sich für eine der beiden Möglichkeiten entscheiden kann.

Sie könnten die Sache auch vereinfachen, indem Sie einen eingebetteten Browser bereitstellen (z. B. Gecko). Auf diese Weise müssen Sie sich nur mit einem Browser befassen, was viele Dinge vereinfacht (einschließlich der Vorinstallation der Root-CA).

Answer 2

Zur Erinnerung: Sie richten Webserver für Desktop-Anwendungen ein; jeder Desktop wird seinen eigenen Webserver haben, aber Sie möchten SSL verwenden, um die Verbindung zu diesem Webserver zu sichern.

Ich vermute, dass es hier mehrere Probleme mit Zertifikaten gibt. Eines davon ist, dass der Hostname, der für den Zugriff auf den Desktop verwendet wird, mit dem Zertifikat übereinstimmen muss. In diesem Fall haben Sie kaum eine andere Wahl, als Zertifikate auf dem Client zu generieren. Sie müssen dem Benutzer die Möglichkeit geben, den Hostnamen anzugeben, falls der von Außenstehenden verwendete Name nicht vom Host selbst erkannt werden kann.

Ich würde auch vorschlagen, dass ein Administrator ein vertrauenswürdiges Zertifikat installieren kann, für diejenigen, die sich nicht auf selbst signierte Zertifikate verlassen wollen. Auf diese Weise können Sie auch die Kosten für die Pflege von vertrauenswürdigen Zertifikaten auf die Administratoren abwälzen, die dies wirklich wollen.

Meiner Erfahrung nach lassen Browser das selbstsignierte Zertifikat entweder zu oder verweigern es, und es gibt keine Möglichkeit für den Server zu erfahren, ob das Zertifikat verweigert, vorübergehend akzeptiert oder dauerhaft akzeptiert wird. Ich nehme an, dass es irgendwo einen Mechanismus geben muss, um SSL-Fehler zu behandeln, aber die typische Webprogrammierung arbeitet nicht auf dieser Ebene. Auf jeden Fall ist das einzige, was ein Webserver tun kann, wenn SSL ausfällt, auf Nicht-SSL zurückzugreifen, und Sie haben in einem Kommentar angedeutet, dass Sie nichts haben können, was nicht-SSL ist. Ich denke, Sie sollten versuchen, diese Einschränkung aufzuheben; eine Nicht-SSL-Startseite wäre in dieser Situation äußerst hilfreich: Sie kann (mit Frames oder Bildern oder JSON oder AJAX) die https-Verbindung testen und sie kann auf die Dokumentation zur Einrichtung des Zertifikats verweisen oder darauf, wo man ein Installationsprogramm für das Zertifikat herunterladen kann.

Wenn der Browser aufgrund eines selbstsignierten Zertifikats keine Verbindung herstellt und Sie kein einfaches HTTP verwenden dürfen, wie können Sie dann auf andere Weise mit dem Benutzer kommunizieren? Es gibt keine anderen Kanäle, und Sie können auch keinen aufbauen, weil Sie keine Kommunikation haben.

Sie haben in einem Kommentar erwähnt, dass Sie eine Win32-Anwendung für die Installation des Zertifikats geschrieben haben. Sie könnten ein Zertifikat installieren, wenn Sie die Anwendung selbst installieren, aber das hilft keinem entfernten Browser, und ein lokaler Browser braucht kein SSL, um auf localhost zuzugreifen.

Answer 3

Wir haben an einem Open-Source-JavaScript-Projekt namens Forge gearbeitet, das sich mit diesem Problem befasst. Haben Sie eine Website, auf die Ihre Benutzer zugreifen können? Wenn ja, könnten Sie über Ihre Website eine sichere Verbindung zu diesen Desktop-Anwendungen herstellen, indem Sie eine Kombination aus Flash für Cross-Domain und JavaScript für TLS verwenden. Dazu müssen Sie einige Webdienste auf Ihrer Website implementieren, um die Zertifikate der Desktop-Anwendungen zu signieren (oder Ihre Desktop-Anwendungen die selbstsignierten Zertifikate hochladen lassen, damit sie über JavaScript zugänglich sind). Wir beschreiben hier, wie es funktioniert:

http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/

Eine Alternative zur Einrichtung einer Website, die jedoch weniger sicher ist, da sie einen MiTM-Angriff ermöglicht, besteht darin, das JavaScript+Flash direkt auf dem Server der Desktop-Anwendung zu hosten. Sie könnten Ihre Benutzer über normales HTTP auf Ihre Desktop-App zugreifen lassen, um das JS+Flash+SSL-Zertifikat herunterzuladen, und danach TLS über das JS verwenden. Wenn Sie eine Localhost-Verbindung haben, ist der MiTM-Angriff vielleicht etwas weniger besorgniserregend - vielleicht genug für Sie, um diese Option in Betracht zu ziehen.

Answer 4

Ein ActiveX-Steuerelement könnte diesen Zweck erfüllen. Aber ich habe mich wirklich nicht zu Wort gemeldet, um bei der Lösung zu helfen, sondern eher, um der Meinung zu widersprechen, dass das, was Sie tun, ein Sicherheitsrisiko darstellt.

Sie benötigen also eine sichere Verschlüsselung (hoffentlich AES und nicht DES) und haben bereits die Kontrolle über Ihre Endgeräte, können aber nicht vollständig ausschließen, dass Netzwerk-Sniffer im Promiscuous-Modus Passwörter im Klartext oder andere sensible Daten abfangen können.

SSL ist ein "Secure Socket Layer" und ist per Definition NICHT von irgendwelchen Zertifikaten abhängig.

Dies ist jedoch bei allen wirksamen modernen Verschlüsselungen erforderlich, um die Tunnelendpunkte zu authentifizieren, was nicht immer für jede Anwendung notwendig ist. Mit dieser Frustration habe ich mich bei zahlreichen Back-End-Automatisierungsroutinen für Rechenzentren auseinandergesetzt, die Webdienst-APIs zur Verwaltung von Knoten verwenden, bei denen die "Benutzer" eigentlich Prozesse waren, die vor einer RESTful-Befehlsaushandlung einen verschlüsselten Schlüsselaustausch benötigten.

In meinem Fall waren die VLANs über ACLs gesichert, so dass ich wirklich Klartext-Authentifizierungs-Header senden "konnte". Aber allein beim Tippen dieses Satzes musste ich mich schon ein wenig übergeben.

Ich bin mir sicher, dass ich für diesen Satz angefeindet werde, aber ich bin extrem kampferprobt und hätte Ihnen in den Jahren 10-15 meiner IT-Karriere die gleichen Bemerkungen gemacht. Ich kann also ihre Sorgen nachvollziehen und freue mich sehr, wenn sie sich so sehr für die Sicherheit engagieren, dass sie mich abflammen. Sie werden es schließlich herausfinden.....

Aber ich stimme der Tatsache zu, dass es eine SCHLECHTE Idee ist, Benutzer zu "trainieren", Root-CAs selbständig zu installieren. Wenn Sie andererseits ein selbstsigniertes Zertifikat verwenden, müssen Sie den Benutzern beibringen, dieses zu installieren. Und wenn ein Benutzer nicht weiß, wie er feststellen kann, ob ein CA-Zertifikat vertrauenswürdig ist, wird er definitiv nicht in der Lage sein, ein selbstsigniertes Zertifikat von einem CA-Zertifikat zu unterscheiden, so dass beide Verfahren den gleichen Effekt haben.

An meiner Stelle würde ich den Prozess automatisieren, anstatt ihn den Endbenutzern zu überlassen, damit er für sie so unsichtbar wie möglich wird, so wie es eine richtige PKI für ein Unternehmen tun würde.

Apropos, mir ist gerade eine mögliche Lösung eingefallen. Verwenden Sie das Microsoft PKI-Modell. Mit Server 2012 R2 können Sie vertrauenswürdige Schlüssel an Endpunkte liefern, die nicht einmal Domänenmitglieder sind, indem Sie "Gerätesteuerung" über "Arbeitsbereiche" verwenden, und die Clientcomputer können mehrere Arbeitsbereiche abonnieren, so dass sie nicht nur an Ihren gebunden sind, wenn sie abonnieren. Sobald sie dies tun und sich authentifizieren, wird die AD-Zertifikatsdienstrolle alle erforderlichen Root-CA-Zertifikate übertragen, die im Active Directory oder im angegebenen LDAP-Server vorhanden sind. (Falls Sie Offline-CA-Server verwenden)

Außerdem ist mir klar, dass dieser Thread schon 7 Jahre alt ist, aber ich bin mir sicher, dass er immer noch von vielen Leuten, die ähnliche Lösungen benötigen, angesprochen wird, und ich fühlte mich verpflichtet, eine gegensätzliche Meinung zu äußern. (Ok Microsoft, wo ist mein Kickback für die Werbung, die ich dir gegeben habe?)

-cashman