Apache: Überprüfen Sie die SSL-Vertrauenskette, um MITM-Angriffe zu verhindern?

11

Ich habe gerade festgestellt, dass SSL-Man-in-the-Middle-Angriffe weitaus häufiger sind als ich dachte, insbesondere in Unternehmensumgebungen. Ich habe von mehreren Unternehmen gehört und mich selbst gesehen, die über einen transparenten SSL-Proxyserver verfügen. Alle Clients sind so konfiguriert, dass sie dem Zertifikat dieses Proxys vertrauen. Dies bedeutet im Grunde, dass der Arbeitgeber theoretisch sogar SSL-verschlüsselten Verkehr abfangen kann, ohne dass Warnungen im Browser auftauchen. Wie oben erwähnt, werden die Clients mit dem vertrauenswürdigen Zertifikat geliefert. Dies kann nur durch manuelle Validierung des verwendeten Zertifikats festgestellt werden.

Mir scheint, als würde der Arbeitgeber seine überlegene Position nutzen, um den SSL-Verkehr des Arbeitnehmers auszuspionieren. Für mich macht dies das gesamte Konzept von SSL nicht vertrauenswürdig. Ich habe ein ähnliches Setup selbst mit mitmproxy erfolgreich getestet und konnte die Kommunikation zwischen dem Client und meinem E-Banking-Server lesen. Dies sind Informationen, die niemandem preisgegeben werden sollten.

Daher ist meine Frage ziemlich einfach: Wie kann ich die Vertrauenskette auf der Serverseite überprüfen? Ich möchte sicherstellen, dass der Client das Zertifikat meines Servers und nur eine Vertrauenskette verwendet. Ich frage mich, ob dies durch die SSL-Konfiguration von Apache erreicht werden kann. Dies wäre praktisch, da es leicht auf viele Anwendungen angewendet werden könnte. Wenn dies nicht möglich ist, kennt jemand eine Möglichkeit, dies in PHP zu tun? Oder haben Sie noch andere Vorschläge?

— Querruder79
quelle

1

Es ist in Ordnung, wenn der Arbeitgeber den Verkehr der Arbeitnehmer sieht. Sie verwenden die Ressourcen des Arbeitgebers (PC, Netzwerkverbindungen usw.), diese gehören nicht Ihnen. Und wenn Sie befürchten, dass der Mitarbeiter die Daten sehen könnte, die Sie auf Ihr Bankkonto übertragen, tun Sie dies zu Hause und nicht bei der Arbeit. Und Versuche, gegen die Sicherheitsrichtlinien des Unternehmens zu verstoßen, können Gegenstand eines Gerichts gegen Sie sein.

— Crypt32

2

In vielen europäischen Unternehmen ist die private Nutzung von Bürogeräten im Arbeitsvertrag geregelt. In der Firma, in der ich arbeite, kann ich privat surfen, das ist kein Problem. Es gibt Ausnahmen wie Pornos, Filesharing usw. Gleichzeitig gibt es Gesetze, die es Unternehmen verbieten, ihre Mitarbeiter auszuspionieren. Daher ist es für mich - und viele andere - NICHT in Ordnung, wenn Arbeitgeber den Arbeitnehmerverkehr abfangen, da dies eindeutig verboten ist, während privates Surfen in vielen Unternehmen toleriert wird.

— Querruder79

2

Die meisten (meiner Erfahrung nach) Workstations im Besitz der US-Regierung enthalten diese beiden Hinweise bei jeder Anmeldung: "Mitteilungen oder Daten, die auf diesem IS gespeichert sind, sind nicht privat, unterliegen einer routinemäßigen Überwachung, Überwachung und Suche und können offengelegt oder verwendet werden für jeden von USG autorisierten Zweck. Dieser IS umfasst Sicherheitsmaßnahmen (z. B. Authentifizierung und Zugriffskontrollen) zum Schutz der USG-Interessen - nicht zu Ihrem persönlichen Vorteil oder Ihrer Privatsphäre. " Die Nutzung dieser Systeme wird häufig durch eine unterzeichnete Vereinbarung abgedeckt, in der dies festgelegt ist. Das wichtigste Detail ist, dass sich der Eigentümer des Systems vor Ihnen schützt.

— Randall

Das ist einer der vielen Unterschiede zwischen den USA und Europa. Die oben genannten Begriffe @ Randall sind in den meisten europäischen Ländern illegal.

— Querruder79

Die von mir zitierten Begriffe sind unvollständig, andere Begriffe listen Aktivitäten auf, die ausdrücklich nicht überwacht werden sollen. Ich kann keinen Hinweis darauf finden, dass europäische Arbeitgeber solche Voraussetzungen nicht zur Bedingung für die Nutzung ihrer Computer machen können (ich arbeite für ein in Europa tätiges Unternehmen und richte solche Überwachungsprozesse ein, obwohl ich für eine Abteilung arbeite, in der keine Geschäfte getätigt werden Europa), kann aber Referenzen finden, die darauf hindeuten, dass solche Begriffe nicht illegal sind, solange sie explizit und transparent sind.

— Randall

9

Ich denke, diese Frage wäre besser für security.stackexchange.com geeignet, wo das Thema MITM in vielen Fragen diskutiert wird. Aber wie auch immer:

Die Validierung des Serverzertifikats erfolgt nur auf dem Client und kann nicht auf den Server verschoben werden, da der Validierungspunkt des Zertifikats auf dem Client darin besteht, dass die Clients sicherstellen müssen, dass es mit dem richtigen Server kommuniziert und dem nicht vertrauen kann (nicht vertrauenswürdiger) Server, um diese Entscheidung für den Client zu treffen.

Beim Abfangen von SSL ist der TLS-Client aus Sicht des Servers die SSL-abfangende Firewall / AV. Daher besteht das Problem auf der Serverseite darin, festzustellen, ob mit dem erwarteten Client (dem Browser) oder nicht (der Firewall / AV) gesprochen wird. Der sicherste Weg, dies zu tun, besteht darin, Client-Zertifikate zur Authentifizierung des Clients zu verwenden. Tatsächlich funktioniert das Abfangen von SSL nicht, wenn die Client-Authentifizierung verwendet wird, dh der TLS-Handshake schlägt fehl, da das MITM das erwartete Client-Zertifikat nicht bereitstellen kann.

Nur werden Client-Zertifikate selten verwendet. Ein fehlgeschlagener TLS-Handshake würde auch nicht bedeuten, dass der Client ohne SSL-Abfangen mit dem Server kommunizieren kann, sondern dass der Client überhaupt nicht mit dem Server kommunizieren kann. Eine alternative Möglichkeit wäre die Verwendung einiger Heuristiken, um die Art des TLS-Clients anhand des Fingerabdrucks des TLS-Handshakes zu ermitteln, dh Art und Reihenfolge der Chiffren, Verwendung bestimmter Erweiterungen ... Während ein SSL-Intercepting-Proxy theoretisch das Original emulieren könnte ClientHello perfekt die meisten nicht. Siehe auch Man-in-the-Middle-Erkennung auf der Serverseite für HTTPS oder Abschnitt III, Heuristiken für die TLS-Implementierung in Die Sicherheitsauswirkungen des Abfangens von HTTPS .

— Steffen Ullrich
quelle

14

Mir scheint, als würde der Arbeitgeber seine überlegene Position nutzen, um den SSL-Verkehr des Arbeitnehmers auszuspionieren. Für mich macht dies das gesamte Konzept von SSL nicht vertrauenswürdig

Das Problem liegt weder im Konzept von SSL noch in der technischen Implementierung, sondern darin, dass jemand anderes die volle Kontrolle über einen Endpunkt der Verbindung hat, dh Ihre Workstation.
Das ist die Wurzel des tatsächlichen Sicherheitsrisikos ...

Aus Sicherheitsgründen ist Ihre Workstation gefährdet, wodurch die Vertrauenskette unterbrochen wird, die unter normalen Umständen den Erfolg eines MITM verhindert.

Wie kann ich die Vertrauenskette auf der Serverseite überprüfen?

Das kannst du nicht. Das geschieht clientseitig.

Abhängig von Ihrem Anwendungsfall können Sie RFC 7469 HTTP Public Key Pinning ausführen, bei dem Sie einen zusätzlichen Header mit einer Liste (Hashes) Ihrer tatsächlichen SSL-Zertifikate oder der von Ihnen verwendeten Zertifizierungsstellen an den Client gesendet haben.

— HBruijn
quelle

4

HPKP hilft nicht, da es von Browsern ignoriert wird, wenn das Zertifikat von einer explizit hinzugefügten Zertifizierungsstelle signiert ist. Dies geschieht speziell, um das Abfangen von SSL durch eine vertrauenswürdige Partei zu ermöglichen, z. B. eine Unternehmensfirewall oder einen lokalen Desktop-AV (viele verwenden SSL-Abhören).

— Steffen Ullrich

2

Dort sind Sie absolut richtig: §2.6 aus dem RFC: "Es ist akzeptabel, die Pin-Validierung für einige Hosts gemäß den lokalen Richtlinien zu deaktivieren. Beispielsweise kann ein UA die Pin-Validierung für angeheftete Hosts deaktivieren, deren validierte Zertifikatkette um endet ein benutzerdefinierter Vertrauensanker anstelle eines in die UA (oder die zugrunde liegende Plattform) integrierten Vertrauensankers. "

— HBruijn

3

Das ist der falsche Weg. Nicht der Server überprüft die Vertrauenskette. Es ist der Kunde. Der Grund, warum Unternehmen diese Methode verwenden, besteht darin, die Unternehmensumgebung zu sichern und zu überprüfen, was der Mitarbeiter in seiner Arbeitszeit tut.

— beli3ver
quelle

Ja, mir ist bewusst, dass dies allein auf der Serverseite wahrscheinlich nicht verhindert werden kann. Einige clientseitige JS können jedoch auch ausgetrickst werden. Übrigens ist das Ausspionieren von Mitarbeitern in den meisten europäischen Ländern illegal. Als Website-Betreiber möchte ich verhindern, dass meine Kunden getäuscht werden. Daher frage ich mich, ob es eine Möglichkeit gibt, die Vertrauenskette auf sichere Weise zu überprüfen.

— Querruder79

Vielleicht ist es nicht erlaubt. Die meisten Unternehmen spionieren jedoch nicht die Mitarbeiter aus, die nur das Unternehmensnetzwerk sichern möchten, und die meisten Webfilter oder Scanner müssen die SSL-Verbindung trennen, um dies zu überprüfen. Das ist also ein legaler Mann im mittleren Angriff

— beli3ver

Ich verstehe deinen Standpunkt. Bei dieser Frage geht es jedoch darum, wie ich sicherstellen kann, dass eine HTTPS-Verbindung Ende-zu-Ende verschlüsselt wird. Das oben beschriebene Setup ist in Unternehmensumgebungen sehr verbreitet, aber die gleiche Art von Angriff kann von eifersüchtigen Jungen verwendet werden, um ihre Freundinnen auszuspionieren, oder von Vermietern, die den Verkehr ihrer Mieter abfangen. Diese Leute müssen noch dazu verleitet werden, ein Zertifikat zu installieren, aber das ist der einfache Teil. Dies ist jedoch illegal - und ich frage mich immer noch, ob ich auf irgendeine Weise sicherstellen kann, dass eine HTTPS-Verbindung wirklich e2e verschlüsselt ist.

— Querruder79

3

Das ist nicht möglich. Wenn das Stammzertifikat auf dem Client geändert wurde, können Sie es nicht überprüfen. Der Server führt die Prüfung nicht durch, der Client führt die Prüfung durch.

— Beli3ver

3

Sie KöNNTEST (Art), aber die eigentliche Frage ist , ob Sie SOLL .

Aber Vorsicht, es ist nirgends so einfach wie das Ändern eines Flags in der apache.conf.

Da der "Angreifer" (z. B. der Arbeitgeber) den Client-Computer kontrolliert, kann er Ihre Versuche immer vereiteln, wenn er dazu neigt, genügend Aufwand zu betreiben (auf der positiven Seite, wenn Sie kein sehr großer Fisch sind, sind sie es höchstwahrscheinlich nicht geneigt, damit Sie Ihr Ziel erreichen, dass Ihre Benutzer keine Verbindung zu Ihnen herstellen können, es sei denn, es ist sicher))

Sie können TLS in Javascript erneut implementieren und dort überprüfen, ob das Zertifikat, mit dem der Client verbunden ist, das Zertifikat Ihrer Website ist.
Wenn Sie Glück haben , verwendet der Benutzer möglicherweise einen Browser, in dem clientseitiges Javascript Informationen zum verwendeten Remote-Zertifikat abrufen kann (und diese daher leicht anhand des fest codierten Werts des Zertifikats Ihres Servers überprüfen kann).
Sie können JavaScript verwenden, um Ihre benutzerdefinierte Verschlüsselung auszuführen . Selbst wenn das böse TLS MiTM des Unternehmens erfolgreich war, würde es ihm dennoch keinen Zugriff auf Ihre Daten gewähren. Wenn genügend Interesse besteht (und da sie den Client kontrollieren), können sie Ihr sicheres Javascript natürlich sofort durch ein eigenes ersetzen, das auch alle Informationen während des Transports protokolliert (oder ändert).

Da Unternehmen, die TLS MiTM-Proxys verwenden, normalerweise auch den Client-Computer vollständig steuern, können sie Bildschirm und Keylogger genauso einfach installieren, um einfach Videos von allem aufzuzeichnen, was der Benutzer sieht, und alle vom Benutzer eingegebenen Tastenanschläge (und Mausbewegungen) aufzuzeichnen. Wie Sie sehen können, wenn Angreifer SIND der Client gibt es keinen absolut sicheren Weg , um ihn zu täuschen. Es ist wirklich nur eine Frage, wie sehr sie sich die Mühe machen werden ... Und einige der oben genannten Lösungen könnten für Sie gut genug sein.

— Matija Nalis
quelle

" Sie könnten TLS in Javascript neu implementieren " Wie? Wo?

— Neugieriger

@curiousguy dieser Text qouted ist ein Link - klicken Sie darauf, und es wird Sie zu einer anderen Frage und Antwort und schließlich zu digitalbazaar / Forge Projekt führen

— Matija Nalis

Also, wann ist es verwendbar? Zu welchem Zweck?

— Neugieriger

@curiousguy unter vielen anderen Dingen, insbesondere für Zwecke, die in dieser Serverfault-Frage gestellt werden. Wenn auf dem Client ein eigenes JS-TLS ausgeführt wird, weiß dieser Client-JS genau, mit welchem TLS-Server der Client verbunden ist (und mit welchem öffentlichen Schlüssel). Anschließend können Sie diesen öffentlichen Schlüssel mit dem öffentlichen Schlüssel des autorisierten Servers (ebenfalls in Ihrem JS fest codiert) vergleichen und feststellen, ob diese identisch sind. Wenn sie nicht gleich sind, wurde Ihre Verbindung von MiTM entführt.

— Matija Nalis