user32847 schrieb:
Wenn jetzt jemand ein Zertifikat für meine Website erstellt (für einen Angriff): Die (neuen) Schlüssel sind ja gar nicht im Server hinterlegt - wie würde das funktionieren?
Dazu musst du die Struktur von TLS-Schlüsseln verstehen.
Jeder kann sich selbst einen Schlüssel erstellen und damit die eigene Webseite verschlüsselt ausliefern lassen. Die Verschlüsselung des Datenverkehrs an sich ist dann einigermaßen sicher – die Kommunikation zwischen den Endpunkten (Server und Client) kann dann nicht belauscht werden. Das Problem ist die Glaubwürdigkeit. Niemand kann sicher sein, dass der Schlüssel wirklich zu dem Server beziehungsweise der Domain gehört. Deshalb akzeptieren Browser sowas immer nur mit einer Sicherheitswarnung.
An der Stelle kommen die Zertifizierungsstellen ins Spiel. Die beglaubigen deinen Schlüssel und bestätigen mit ihrer Unterschrift unter deinem Schlüssel, dass der Schlüssel tatsächlich zur der IP oder der Domain gehört.
Die Unterschriften dieser Zertifizierungsstellen sind im Browser hinterlegt, wenn dein Browser eine TLS-Verbindung herstellt zeigt ihm der Server sein Zertifikat und der Browser prüft, ob eine gültige Unterschrift drunter steht. Also ob eine Zertifizierungsstelle dieses Zertifikat für diese Domain/IP beglaubigt. Ist das der Fall, dann betrachtet der Browser die Verbindung als sicher.
Das hindert natürlich keine Zertifizierungsstelle daran, falsche Zertifikate zu beglaubigen. Es kann also zwei gültige Schlüssel für eine Domain/IP geben, obwohl es natürlich nur einen gültigen Besitzer gibt und es deshalb auch nur ein Zertifikat geben dürfte. Für den Browser macht es keinen Unterschied, mit welchem Zertifikat sich der Server identifiziert. Domain passt, Unterschrift passt, das glaubt der Browser. Solche Zertifizierungsstellen fliegen dann natürlich aus den Browsern, wenn sowas bekannt wird und dann sehen die Browser diese Zertifikate wieder als unsicher an (siehe oben).
Man-in-the-middle-Attack? Also der Angreifer schaltet sich dazwischen und fängt meinen Aufruf für die Website ab und sendet daraufhin einen eigenen HTTPS-Aufruf an die Website, bekommt die Inhalte und verschlüsselt sie mit dem neu erstellten Zertifikat und leitet das dann an den Client weiter? Oder geht das anders?
Richtig. Zum Beispiel.
Es reicht normalerweise nicht aus, das Zertifikat zu fälschen und eine Zertifizierungsstelle dazu zu bekommen, das zu beglaubigen, sondern man muss auch das Routing bzw. das DNS kontrollieren können. Man könnte zum Beispiel dem Nutzer was in die /etc/hosts schreiben, dann werden Aufrufe einer bestimmten Domain auf eine andere IP geleitet, wo der Server mit dem alternativen (falschen) Zertifikat wartet – und der Browser glaubt es. Oder man kann (schwerer) das Routing beeinflussen und auch eine korrekt aufgelöste IP-Adresse an einen anderen Server umleiten.
Wenn man nur mitlauschen möchte, dann kann man die Kommunikation natürlich „Man in the Middle“ an den richtigen Server weiterleiten und keiner merkt was. Oder man hat Phishing im Sinn und verleitet die Nutzer lediglich dazu ihre Login-Daten einzugeben. Die Möglichkeiten sind dann vielfältig.
Deshalb ist übrigens DNSSEC immer wieder ein Thema, als zusätzliche Gegenmaßnahme. Dann könnte man zumindest bei der Namensauflösung Manipulationen verhindern.
~jug