it-swarm.com.de

Wie führe ich ordnungsgemäßes HTTPS in einem internen Netzwerk aus?

Diese Frage wurde mehrmals gestellt, ich werde ein paar verlinken:

Dies sind jedoch alte Fragen, und ich weiß, dass die Antworten zumindest in gewisser Hinsicht veraltet sind. Ich recherchiere in der Hoffnung, dass ich herausfinden kann, welche Teile davon veraltet sind und welche noch gut sind. Ich suche moderne Antworten.

Die Frage ist einfach, aber hier ist die Situation. Ich habe Webdienste, die auf vertrauliche Informationen zugreifen (aus der Perspektive: Es wäre schlecht für unser Unternehmen und unsere Kunden, aber wahrscheinlich auch nicht lebensbedrohlich). Ich möchte einen einfachen Zugang zu diesen Systemen bieten, aber Sicherheit ist offensichtlich wichtig. (Einige dieser Dienste werden über Nicht-Browser-Clients als Webservices aufgerufen. Einige sind einfach Webseiten, die Menschen von modernen Browsern aus verwenden.)

Zu diesem Zweck halten wir die wichtigsten Dienste nur intern zugänglich. Auf diese Weise ist es a) unwahrscheinlich, dass ein Angreifer sie versehentlich findet, und b) er muss ein zusätzliches Hindernis überwinden.

"Sicherheit in der Tiefe" würde jedoch bedeuten, dass wir den Datenverkehr auch intern verschlüsseln. Dies macht es für jemanden im Netzwerk noch schwieriger, Passwörter zufällig von der Leitung zu schnüffeln.

Im Sinne von „meine Hausaufgaben machen“ habe ich verschiedene Optionen zusammengestellt, von denen einige weniger angenehm sind als andere. Ich bin mir nicht ganz sicher, welche davon überhaupt machbar sind, da ich weiß, dass sich einige Regeln geändert haben.

Selbstsigniertes Zertifikat

Dies scheint die Antwort auf diese Frage zu sein, die meistens gestellt wird. Dies bietet Widerstand gegen das Problem des gelegentlichen Schnüffelns, aber ich muss allen Mitarbeitern sagen, dass die große böse Warnseite in Ordnung ist, klicken Sie sich einfach durch. Ich habe hart daran gearbeitet, sie zu trainieren, diese Seite niemals zu ignorieren, und die meisten von ihnen würden die Nuancen von "Die Seite ist manchmal in Ordnung, wenn Sie wissen und erwarten, dass die Site ein selbstsigniertes Zertifikat verwendet" nicht verstehen. sie neigen dazu, nicht mehr auf das Komma zu hören :)).

Selbstsigniertes Zertifikat, aber auf jedem System installiert und vertrauenswürdig

Ich denke, dies behebt die unangenehme Seite, aber ich müsste festlegen, dass sie auf jedem Computer, der darauf zugreift, als vertrauenswürdig eingestuft wird. Das ist möglich, aber unerwünscht.

Ich bin mir auch nicht 100% sicher, ob dies auch für interne Adressen noch möglich ist. Ich verstehe, dass moderne Browser jedes Zertifikat ablehnen sollen, das vorgibt, einen Computer zu zertifizieren, der in eine nicht öffentliche IP-Adresse aufgelöst wird oder nicht vollständig qualifiziert ist.

Darüber hinaus ist der Prozess zum Installieren von Systemstammzertifikaten auf Mobilgeräten ... grundsätzlich unmöglich. Es erfordert ein verwurzeltes Android Telefon) und einen relativ geheimen Prozess für iOS-Geräte.

Richten Sie meine eigene Zertifizierungsstelle ein

Grundsätzlich das gleiche Problem mit installierten und vertrauenswürdigen Zertifikaten, aber ich muss nur das Stammzertifikat installieren, nicht ein Zertifikat für jedes System, auf dem ich stehe. Grundsätzlich werden immer noch alle Mobilgeräte geschlossen, einschließlich der Tablet-Manager, die gerne in Besprechungen verwendet werden.

Ich bin noch weniger davon überzeugt, dass dies funktionieren würde, da die IPs intern sind und der DNS nicht vollständig qualifiziert ist.

Verwenden Sie öffentliche Zertifikate, jedoch für interne Adressen.

Wir könnten vollständig qualifizierte Adressen (wie "secret.private.example.com") konfigurieren, um sie in interne Adressen aufzulösen (wie "192.168.0.13"). Dann könnten wir Zertifikate für diese öffentlichen DNS-Namen verwenden (möglicherweise sogar Platzhalterzertifikate für "* .private.example.com").

Dies könnte funktionieren oder nicht, und es könnte nicht einmal eine gute Idee sein. Browser lehnen das Zertifikat möglicherweise ab, wenn versucht wird, es in eine lokale Adresse aufzulösen.

Wenn es funktioniert, ist es möglicherweise keine gute Idee. Ein Laptop, der von unserem internen System in ein anderes Netzwerk gebracht wird (möglicherweise sehr schnell über eine VPN-Trennung), könnte versuchen, auf geheime Dinge an lokalen IP-Adressen in anderen Netzwerken zuzugreifen. Solange HSTS in Kraft ist, sollte dies keine große Sache sein , da sie ohne unseren privaten Schlüssel den Kunden nicht überzeugen können um die gefälschte Site zu akzeptieren und kein Downgrade auf HTTP zu erzwingen. Aber es scheint unerwünscht und verstößt gegen die Regel "Keine privaten Adressen im öffentlichen DNS", die (vielleicht?) Kürzlich in Kraft getreten ist.

Also, all das zu sagen ... was ist die richtige Antwort? Ich könnte einfach "aufgeben" und die privaten Dienste öffentlich zugänglich machen, da ich darauf vertraue, dass die Verschlüsselungs- und anwendungsspezifischen Authentifizierungsanforderungen die Sicherheit gewährleisten. In der Tat ist dies für einige weniger sensible Dinge ein guter Kurs. Ich mache mir jedoch Sorgen, dass die anwendungsspezifische Authentifizierung fehlerhaft sein oder Anmeldeinformationen auf andere Weise kompromittiert werden könnten (Menschen sind immer das schwächste Glied), und ich würde es vorziehen, wenn es ein zusätzliches Hindernis gibt, wenn überhaupt vernünftig.

73
alficles

Die Zertifikatsüberprüfung wird durchgeführt, um sicherzustellen, dass der Peer derjenige ist, den Sie erwarten. Die Überprüfung eines Serverzertifikats im Browser erfolgt hauptsächlich, indem überprüft wird, ob der Hostname aus der URL mit den Namen im Zertifikat übereinstimmt und ob Sie eine Vertrauenskette zu einem lokal vertrauenswürdigen CA-Zertifikat (dh den im Browser gespeicherten Stammzertifikaten) erstellen können oder Betriebssystem). Zusätzlich gibt es Ablauf- und Widerrufsprüfungen.

Um sicherzustellen, dass dieser Prozess wie beabsichtigt funktioniert, muss der Aussteller des Zertifikats überprüfen, ob Sie tatsächlich die Hostnamen im Zertifikat besitzen. Dies bedeutet, dass Sie ein von einer öffentlichen Zertifizierungsstelle ausgestelltes Zertifikat nur erhalten können, wenn Sie nachweisen können, dass Sie diesen Namen besitzen. Dies bedeutet normalerweise, dass der Host mit diesem Namen öffentlich sichtbar ist - zumindest für die billigen Zertifikate, bei denen die automatische Validierung durchgeführt wird. Natürlich können Sie dieses Problem umgehen, indem Sie den Hostnamen tatsächlich öffentlich verfügbar machen (d. H. Einen einzelnen Server, auf den mit *.example.com Zugreifen kann) und dann die ausgestellten Zertifikate für Ihr internes System verwenden.

(Mis) die Verwendung einer öffentlichen Zertifizierungsstelle für interne Systeme auf diese Weise ist etwas hässlich, sollte aber meistens funktionieren. Sie benötigen weiterhin eine Internetverbindung, da die Sperrprüfungen anhand von Informationen der Zertifizierungsstelle durchgeführt werden, d. H. Von außerhalb Ihres lokalen Netzwerks. Dies kann durch die Verwendung von OCSP-Heften irgendwie eingeschränkt werden, aber nicht alle Clients und Server unterstützen dies. Wenn Sie Ihren Clients nicht erlauben, die externe Zertifizierungsstelle nach Sperrinformationen zu fragen, kann der Verbindungsaufbau manchmal langsam sein, da der Client erfolglos versucht, die Sperrinformationen abzurufen.

Daher sollte die Verwendung einer öffentlichen Zertifizierungsstelle möglich sein, jedoch mit Nachteilen, und es fühlt sich an, als würde man falsch mit dem Zertifizierungsstellensystem spielen - daher empfehle ich es nicht. Die einzige andere Alternative beim Umgang mit vielen Zertifikaten ist die Verwendung Ihrer eigenen lokalen Zertifizierungsstelle. Aber wie Sie selbst erkannt haben, bedeutet dies, das Stammzertifikat auf allen Ihren lokalen Systemen zu installieren und ihm zu vertrauen (dies kann für einige Systeme automatisiert werden). Dies bedeutet auch, dass Sie diese lokale Zertifizierungsstelle wirklich vor Missbrauch schützen müssen, da sie nicht nur lokale Zertifikate ausstellt, sondern theoretisch auch Zertifikate für öffentliche Domains wie google.com ausstellen kann. Und da alle Ihre lokalen Systeme dieser Zertifizierungsstelle vertrauen, vertrauen sie auch diesen Zertifikaten. Außerdem wird das Anheften von Zertifikaten in den meisten Systemen nicht überprüft, wenn die ausstellende Zertifizierungsstelle explizit als vertrauenswürdig hinzugefügt wurde. Dies macht es leicht, die Zertifizierungsstelle für legales oder illegales Abfangen von SSL zu missbrauchen (d. H. Man in the Middle Attack).

Dies bedeutet, dass es keine wirklich gute Option gibt: Missbrauch einer öffentlichen Zertifizierungsstelle für interne Hosts mit allen Nachteilen oder Erstellen einer eigenen Zertifizierungsstelle mit allen Nachteilen. Ich bin mir sicher, dass es auch eine öffentliche Zertifizierungsstelle geben wird, die Ihnen bei diesem Problem hilft, aber dies wird wahrscheinlich teurer sein, als Sie möchten.

14
Steffen Ullrich

"Verwenden Sie öffentliche Zertifikate, aber für interne Adressen."

Diese Option funktioniert ganz gut, das machen wir.

Sie können tatsächlich eine HTTP-Validierung durchführen. Das Zertifikat enthält nicht die IP-Adresse, sondern nur den DNS-Namen. Sie können Ihr DNS also auf einen externen Dienst verweisen, validieren und dann auf eine interne IP verweisen.

Die DNS-Validierung funktioniert jedoch besser, wenn Ihre Zertifizierungsstelle dies unterstützt, da Sie den Eintrag nicht jedes Mal ändern müssen, wenn Sie eine Erneuerung durchführen müssen. Ein SSL-Zertifikat überprüft lediglich, ob Sie den Namen steuern. Wenn Sie also Subdomain-Einträge erstellen können, steuern Sie offensichtlich den Namen.

Anweisungen für letsencrypt: https://serverfault.com/questions/750902/how-to-use-lets-encrypt-dns-challenge-validation

9
Bryan Larsen

Ich glaube , dass die Anforderungen für öffentliche IPs und FQDNs von den Zertifizierungsstellen und nicht von den Browsern übernommen werden. Sie sollten also in Ordnung sein (zumindest, es sei denn, jemand hat bessere Informationen können Sie an einem Nachmittag einen Test einrichten und auf die eine oder andere Weise bestätigen.

Dies schließt zumindest öffentliche Zertifikate aus. Von den verbleibenden drei Optionen wird die beste Benutzererfahrung durch das Erstellen einer eigenen Zertifizierungsstelle erzielt. Dies ist auch die vertrauenswürdigste Option, da sie den vollen Vorteil der Authentifizierung bietet, den die anderen Optionen nicht bieten.

Für das, was es wert ist, können Sie Stammzertifikate auf Android ( v4.x und höher!) Installieren ) und unter iOS ( wie Sie sagen, ein relativ arkaner Prozess ), obwohl das zweifellos ein Schmerz ist.

Die einzige andere echte Option besteht darin, eine öffentliche IP-Adresse zu erhalten und DNS mit einem öffentlichen Domainnamen einzurichten und den Zugriff darauf möglicherweise zu beschränken, möglicherweise über VPNs oder ähnliches.

Die Verwendung eines selbstsignierten Zertifikats, das die Benutzer bei jeder Verwendung akzeptieren, sollte das absolut letzte Mittel sein, da Sie festgestellt haben, dass sie nur darin geschult werden, das Falsche zu tun.

2
Jason

Die beste Lösung, die ich bisher entdeckt habe, ist die Verwendung eines Reverse-Proxys wie Caddy zur Verarbeitung der Zertifikate (Ausgabe und Erneuerung), die Einrichtung eines DNS-Servers, der den gesamten internen Hostnamen auf den Caddy-Server verweist, und alles funktioniert automatisch. Wenn Sie den Zugriff nur auf interne Dateien beschränken möchten, können Sie Port 80 schließen, bis Ihre Zertifikate erneuert werden müssen.

2
Gyver Chang

Ich habe auch selbst daran gearbeitet und nur https in einigen internen Webanwendungen implementiert.

Zuerst richte ich auf unserem internen DNS-Server eine neue Forward-Lookup-Zone ein, corp.domain.com, und richte dann einige A/C-Name-Einträge darin ein, webapp1.corp.domain.com, die auf unsere interne LAN-IP verweisen

Jetzt besitzen wir bereits ein Wildcard-SSL-Zertifikat für * .domain.com. Mit meiner Zertifizierungsanforderung habe ich ein doppeltes SSL-Zertifikat für webapp1.corp.domain.com erstellt

Installierte dies in unserem IIS und im Browser wird es als SICHER angezeigt :)

2
ArtR