Der Zweck der Warnung besteht darin, dass bei Verwendung von HTTPS eine angemessene Sicherheit erwartet wird, ein selbstsigniertes oder abgelaufenes Zertifikat jedoch Sicherheitslücken aufweist, die der Benutzer beachten muss.

Das " Risiko "ist, dass man denkt, dass sie richtig gesichert sind, aber sie sind nicht vollständig gesichert, im Gegensatz zu HTTP, wo man weiß, dass es überhaupt keine Verschlüsselung gibt.

Es würde keine Warnung für HTTP geben, weil Es gibt keine Sicherheit (dh Verschlüsselung), die gefährdet werden könnte.

Sicherheitsunterschied

Lassen Sie uns zunächst über SSL (übrigens jetzt TLS genannt) sprechen, das das 'S' am Ende von HTTP S hinzufügt und verantwortlich ist von " Sichern der Kommunikation ". Der Schlüssel zur Beantwortung dieser Frage besteht in der Tat darin, vollständig zu verstehen, was wir unter "Sichern der Kommunikation" verstehen.

SSL, unabhängig davon, ob es sich um ein selbstsigniertes Zertifikat handelt, das verwendet wird, oder um ein von einem Vertrauenswürdigen signiertes Zertifikat CA stellt sicher, dass die Kommunikation zwischen Ihnen und dem Remote-Host vertraulich bleibt und dass niemand die ausgetauschten Daten manipulieren kann.

Die Warnung bezieht sich daher nicht darauf.

Allerdings Wie können Sie sicher sein, dass dieser Remote-Host, der auf Ihre Anfragen antwortet, wirklich der ist, den Sie erwarten? Bei öffentlichen Websites, für die Sie keine direkte Möglichkeit haben, das Zertifikat allein zu authentifizieren, ist dies einfach unmöglich. Hier kommt eine externe vertrauenswürdige Zertifizierungsstelle: Wenn Sie einer Zertifizierungsstelle vertrauen, gehen Sie davon aus, dass alle von ihr signierten Zertifikate nur zu legitimen Zwecken verwendet werden, um den Datenverkehr mit den im Zertifikat explizit genannten Servern zu sichern.

Dies ist alles Bei dieser Warnung geht es um: Ihr Browser warnt Sie, dass die Kommunikation selbst zwar gesichert ist, das Zertifikat jedoch nicht automatisch authentifiziert werden kann. Daher müssen Sie es akzeptieren oder ablehnen.

Wenn das selbstsignierte Zertifikat einem Ihrer Server zugeordnet ist, sollten Sie mit dieser manuellen Authentifizierung fortfahren können: Sie sollten in der Lage sein, den Zertifikatfingerabdruck zu überprüfen, oder zumindest sollten Sie wissen, ob das Zertifikat vorhanden ist wurde kürzlich geändert oder nicht.

Sobald diese manuelle Authentifizierung durchgeführt wurde, bietet Ihnen Ihr Browser die Möglichkeit, sich an dieses Zertifikat zu erinnern. Dies bedeutet, dass der Browser dieses selbstsignierte Zertifikat dem URL-Host zuordnet und keine Warnung in der Zukunft geben, da jetzt die br Der Owner verfügt über eine automatisierte Methode zur Authentifizierung des Zertifikats.

Sobald jedoch das selbstsignierte Zertifikat auf dem Server geändert wird, zeigt der Browser die Warnung erneut an, und es ist wieder Sache des Endbenutzers, zu bestimmen, ob diese Zertifikatänderung normal ist und ob das Das vom Server vorgelegte neue Zertifikat ist in der Tat ein echtes.

UX-Unterschied

Meine Antwort deckte den Aspekt der Benutzeroberfläche des Browsers Ihrer Frage bis jetzt nicht ab.

Ich fand die Standardmethode, mit der Browser den Benutzer über die aktuelle Sicherheit informieren, größtenteils ineffektiv. Benutzer kümmern sich nur nicht um das Vorhängeschloss und bemerken nicht, wenn die SSL-Sicherheit fehlt. Selbst Benutzer, die sich darum kümmern, haben keinen Zugriff auf die richtigen Informationen (nichts hindert eine Website daran, ein erweitertes Validierungszertifikat anzuzeigen, um ihre Website für die Verwendung schlechter und schwacher Kryptografiesysteme zu konfigurieren oder sich auf weniger gesicherte Inhalte von Drittanbietern zu verlassen : Die Benutzeroberfläche des Standardbrowsers wird sich weiterhin darüber freuen und die grüne Leiste "Erstklassige Sicherheit" anzeigen.

Abhängig vom verwendeten Browser gibt es hoffentlich einige Plugins, die versuchen, diese Situation zu beheben. In Firefox haben Sie SSLeuth, wodurch standardmäßig links oder in der URL-Leiste (neben dem Vorhängeschloss, falls vorhanden) ein neuer Benachrichtigungsbereich hinzugefügt wird.

Dieser neue Benachrichtigungsbereich hat die folgenden Eigenschaften:

• Die Hintergrundfarbe reicht von Rot (keine Sicherheit: HTTP) über Orange (schlechte Sicherheitseinstellungen) bis zu Blau und Grün (gute und beste Sicherheit gemäß den aktuellen Best Practices) ).
• Mit einer Option können Sie diese Farbe auf die gesamte URL-Leiste erweitern, sodass auf HTTP-Websites jetzt eine vollständig rote URL-Leiste angezeigt wird.
• Zuletzt wird eine Punktzahl (zwischen 0 und 10) angezeigt, um eine Schätzung der aktuellen SSL / TLS-Sicherheitsstufe anzuzeigen. Dabei werden verschiedene Kriterien berücksichtigt, darunter die Art des Zertifikats (selbstsigniert, CA-signiert, erweitertes Validierungszertifikat), die verwendete kryptografische Konfiguration, die Inhaltssicherheit von Drittanbietern usw. Durch Klicken auf den Benachrichtigungsbereich werden hauptsächlich alle Bewertungsdetails angezeigt nützlich, wenn das Ergebnis nicht das erwartete ist (auch bekannt als " Warum wird meiner Bankwebsite eine orangefarbene URL-Leiste zugewiesen? ").

Ohne Warnungen für selbstsignierte oder abgelaufene Zertifikate, unangemessene Auswahl von Chiffresuiten und andere fehlerhafte HTTPS-Konfigurationen wird die Darstellung des Sicherheitsstatus einer Website für den Benutzer binär - entweder Sie haben HTTPS auf der Site oder Sie nicht. Dies würde eine Reihe von Nuancen verbergen, die sich erheblich darauf auswirken können, wie sehr das "S" in "HTTPS" Sie wirklich schützt.

Bei einer ordnungsgemäßen HTTPS-Implementierung wird das Zertifikat der Site von einem Drittanbieter signiert dass das Client-System vertraut. Dies stellt für den Kunden die Gewissheit dar, dass der Inhalt von dem System geliefert wird, das er erwartet, und dass sich niemand dazwischen befindet.

Das Problem mit einem selbstsignierten Zertifikat besteht darin, dass jeder einen erstellen kann. Dieses Zertifikat könnte also genauso gut von einem System generiert werden, das als Man-in-the-Middle fungiert und die Daten abfängt und möglicherweise sogar manipuliert, die zwischen Ihnen und dem vertrauenswürdigen System hin und her gehen. Wenn das vertrauenswürdige System normalerweise ein selbstsigniertes Zertifikat verwendet und Sie dieses Zertifikat nicht außerhalb des Bandes oder während einer früheren vertrauenswürdigen Verbindung persönlich validiert haben, werden Sie den Unterschied nie erfahren.

Wie unterscheidet sich das von normalem HTTP? Auf den ersten Blick scheint dies nicht der Fall zu sein. In beiden Szenarien kann ein MitM die Verbindung relativ einfach anzeigen und manipulieren, und Sie werden es nicht bemerken. Die Verwendung von HTTPS mit einem selbstsignierten Zertifikat bietet Ihnen jedoch etwas, was HTTP nicht kann: Die Gewissheit, dass Ihre Daten bei der Übertragung immer noch verschlüsselt werden, auch wenn sich jemand dazwischen befindet. Abhängig von der Umgebung (z. B. dicht besiedeltes öffentliches WLAN) kann dies die Zielgruppe, die Zugriff auf Ihre Daten hat, drastisch reduzieren, selbst wenn tatsächlich ein MitM im Spiel ist.

Möglicherweise möchten Sie dies Weitere Informationen hierzu finden Sie in meiner Antwort auf eine andere verwandte Frage. Troy Hunts Artikel "Bei SSL geht es nicht um Verschlüsselung" könnte für Sie von Interesse sein, obwohl er für Ihre Seite der Debatte hier möglicherweise nicht sehr hilfreich ist.

Diese Antworten sind großartig. Aber ich muss oft eine vereinfachte Antwort ohne den ganzen Jargon geben.

HTTP - Es ist nicht verschlüsselt und die über die Leitung gesendeten Daten können leicht gelesen werden.

HTTPS - Das ist es Von einer vertrauenswürdigen Partei verschlüsselt und verifiziert. Die Daten werden von der richtigen Quelle verarbeitet.

HTTPS (selbstsigniert) - Es wird verschlüsselt, aber es gibt keine Überprüfung durch eine vertrauenswürdige Partei, dass sie von der richtigen Quelle verarbeitet werden .

Deshalb erhalten selbstsignierte Zertifikate den sehr wichtigen Hinweis. Auch wenn dies nicht bedeutet, dass das Zertifikat unsicher ist, kann der Browser nicht bestätigen, dass das Zertifikat bei der Verwendung / Übertragung Ihrer Daten sicher ist. Ohne diesen wichtigen Hinweis könnte ein Betrüger / Hacker das Zertifikat durch ein eigenes ersetzen, und Sie wären nicht klüger.

Der Besuch einer https-URL bringt Sicherheitserwartungen mit sich. Der Besuch einer http-URL funktioniert nicht. Dies gilt nicht nur für die manuelle Eingabe von URLs, sondern möglicherweise noch wichtiger für das Folgen von Links und das Senden von Formularen.

Eine Lösung wäre, ein weiteres URL-Schema für "verschlüsselt, aber nicht authentifiziert" hinzuzufügen. Selbst wenn alle Browser dies morgen unterstützen würden, würde es lange dauern, bis es für Websites weit genug verbreitet ist, um sich darauf zu verlassen es. Es wäre möglicherweise auch schwierig, den Benutzern die Sicherheitsunterschiede zu erklären.

Eine weitere Lösung wäre die opertunistische Verschlüsselung nach dem http-URL-Schema. Auch hier wäre es ein harter Kampf, Unterstützung für Browser zu erhalten.