Das 'S' in HTTPS steht für 'sicher' (Hypertext Transfer Protocol Secure). Es ist ein Kommunikationsprotokoll für die sichere Kommunikation, das Transport Layer Security (TLS) und seinen Vorgänger Secure verwendet Sockets Layer (SSL).

TLS / SSL wird auf Schicht 5 ( Sitzungsschicht) initialisiert und arbeitet dann auf Schicht 6 ( Präsentationsschicht). . Die meisten Anwendungen, wie Webbrowser, E-Mail-Clients oder Instant Messaging, enthalten Funktionen der OSI-Schichten 5, 6 und 7.

Wenn auf HTTPS verwiesen wird, handelt es sich um eine Implementierung von SSL / TLS im Kontext von das HTTP-Protokoll. SSL / TLS wird dann in den Browsern (und dem Webserver) implementiert, um Vertraulichkeit und Integrität für den HTTPS-Verkehr (tatsächliche Verschlüsselung der Daten) zu gewährleisten.

Chromium und Firefox verwenden eine API namens NSS zur Implementierung von SSL / TLS in ihrem jeweiligen Browser.

Microsoft Windows verfügt beispielsweise über ein Sicherheitspaket namens SChannel (Secure Channel), das implementiert wird SSL / TLS, um die Authentifizierung zwischen Clients und Servern bereitzustellen. Schannel wird beispielsweise von Microsoft Windows-Clients / -Servern in einer Active Directory-Umgebung verwendet.

Der Proxy und die Manipulation der Daten hängen vom Protokoll ab, mit dem Sie arbeiten. Ein gutes Beispiel, um sich in einem HTTP (S) -Kontext vertraut zu machen, ist ein Blick auf Burp Proxy.

Hier gibt es viele gute Antworten darauf, wie HTTPS vom Browser behandelt wird, aber ich bin nicht sicher, ob Ihre echte Frage beantwortet wurde.

Kann Diese Daten können erfolgreich über einen Proxy (auf demselben System, nicht im Netzwerk) manipuliert werden.

Hier lautet die Antwort . Dies kann auf zwei Arten geschehen:

• Der Browser selbst wird durch ein böswilliges Plugin, eine Erweiterung oder ein Update gefährdet.
• Das System ist mit Malware gefährdet, die das geändert hat Vom Browser verwendete vertrauenswürdige Stammzertifikate (die möglicherweise mit dem vom Betriebssystem verwendeten identisch sind oder nicht).

Die Antwort lautet ... möglicherweise .

Wenn Sie https:// angeben, übernimmt der Browser die Verantwortung für die Verschlüsselung. Einige Browser verwenden vom Betriebssystem bereitgestellte APIs (siehe IE hier), während andere (z. B. Firefox) ihre eigene Krypto verwenden und die vom Betriebssystem bereitgestellte Krypto vollständig ignorieren.

Die Manipulationssicherheit wird von der PKI garantiert. Wenn also der vertrauenswürdige Zertifikatspeicher Ihres Systems beschädigt wird, sind alle Wetten ungültig. Einige Unternehmen installieren beispielsweise ein eigenes CA-Zertifikat für die interne Signatur, mit dem sie gesicherte Browsersitzungen in der Mitte des Proxys verwalten können, ohne dass der Browser Alarme auslöst. Auch hier werden unter Windows die CAs-Zertifikate vom Betriebssystem verwaltet, wenn Sie IE oder Chrome verwenden, während Firefox über eine eigene eindeutige und separate Liste vertrauenswürdiger CAs verfügt.

Wenn Ihr System jedoch gefährdet ist, ist dies der Fall Sie stoßen an. Es kann keine Sicherheit garantiert werden, nicht einmal SSL. Dies liegt daran, dass sich böswillige Agenten überall in der Kette einbetten können. Vielleicht auf Netzwerkebene, aber vielleicht auch im Browser oder im Bildschirmtreiber oder beim Abhören von Tastenanschlägen ... nichts ist sicher. Es gibt heute eine beliebte Klasse von Malware, die sich in den Browser einfügt, um verschlüsselte Daten zu lesen und zu ändern, bevor sie verschlüsselt werden und nachdem sie entschlüsselt werden. Ein Ziel ist es beispielsweise, Ihre Erfahrung auf einer Online-Banking-Website geringfügig zu ändern, um Bankkonten zu belasten und Ihr gesamtes Geld an den Angreifer zu überweisen.

Der Browser verschlüsselt die Daten, sofern er dem SSL-Zertifikat / öffentlichen Schlüssel vertraut, den er von dem Server erhalten hat, auf den er zugreift. Dieser wird dann an den Server übergeben und entschlüsselt, um eine verschlüsselte "Sitzung" zwischen dem zu starten zwei Entitäten.

Hervorragende, leicht verständliche Erklärung hier.

1. Der Browser stellt eine Verbindung zu einem mit SSL gesicherten Webserver (Website) her (https). Der Browser fordert den Server auf, sich selbst zu identifizieren.
2. Der Server sendet eine Kopie seines SSL-Zertifikats, einschließlich des öffentlichen Schlüssels des Servers.
3. Der Browser überprüft den Zertifikatstamm anhand einer Liste vertrauenswürdiger Zertifizierungsstellen Das Zertifikat ist nicht abgelaufen, nicht widerrufen und sein allgemeiner Name gilt für die Website, zu der eine Verbindung hergestellt wird. Wenn der Browser dem Zertifikat vertraut, erstellt, verschlüsselt und sendet er einen symmetrischen Sitzungsschlüssel mit dem öffentlichen Schlüssel des Servers zurück.
4. Der Server entschlüsselt den symmetrischen Sitzungsschlüssel mit seinem privaten Schlüssel und sendet eine mit dem verschlüsselte Bestätigung zurück Sitzungsschlüssel zum Starten der verschlüsselten Sitzung.
5. Server und Browser verschlüsseln jetzt alle übertragenen Daten mit dem Sitzungsschlüssel.
ol>

Einige wertvolle Informationen zu Zertifizierungsstellen (Zertifikat) Behörden): https://en.wikipedia.org/wiki/Certificate_authority

Die SSL-Verschlüsselung wird vom Browser (oder einer beliebigen Anwendung, die SSL verwendet) eingerichtet, auch wenn sich ein lokaler Proxy auf dem System befindet. Ein Beispiel ist beispielsweise, dass Sie bei einem Pentest einen lokalen Proxy einrichten müssen, um über ein eigenes Zertifikat zu verfügen, mit dem der Datenverkehr zwischen dem Browser und dem Endpunkt entschlüsselt werden kann.

Der Browser behandelt die Entschlüsselung normal. Es gibt jedoch einige Ausnahmen. Proxys können SSL entfernen (in diesem Fall wird das Schlosssymbol nicht normal angezeigt) oder sie können etwas intelligenter sein und das SSL mit einem Zertifikat zurücktreten, dem der Client vertraut, sodass die Sperre weiterhin angezeigt wird, jedoch die Informationen zum Zertifikat ist geändert. Wirklich fortgeschrittene Setups können die SSL-Verbindung tatsächlich überwachen, wenn sie Zugriff auf den privaten Schlüssel des Servers haben, ohne etwas zu ändern, obwohl sie serverseitig und nicht clientseitig verwendet werden (aufgrund der Art und Weise, wie der Schlüssel für eine SSL-Sitzung abgeleitet wird).

Die SSL / TLS-Spezifikationen bestimmen das Over-the-Wire-Protokoll, sagen jedoch nichts darüber aus, wie ein Client implementiert wird. In der Regel bietet der Betriebssystemkern einen unverschlüsselten TCP-Socket. Um die SSL-Schicht zu implementieren, ruft der Browser Funktionen in einer kryptografischen Bibliothek auf (z. B. OpenSSL, SSLeay, GNUtls oder NSS). Daher erfolgt die SSL-Unterstützung normalerweise im Benutzerbereich im selben Prozess wie der Rest des Browsers.

Ob Sie die SSL-Unterstützung als von " System "- es kommt darauf an. Der Browser kann statisch oder dynamisch eine Verknüpfung zur kryptografischen Bibliothek herstellen. Eine dynamische Bibliothek (oder DLL) kann mit dem Betriebssystem verteilt werden, oder der Browserhersteller sendet möglicherweise eine eigene Kopie der Bibliothek.

Auf der Serverseite ist die Situation bei einem Webserver häufig ähnlich Das Modul bietet SSL-Unterstützung (im Benutzerbereich im selben Prozess wie der Rest des Webservers). Es sind jedoch auch alternative Setups üblich. Die kryptografische Unterstützung kann hardwarebeschleunigt sein. Ein umgekehrter Proxy , z. B. ein Load Balancer, befindet sich möglicherweise vor dem realen Webserver und übersetzt zwischen HTTP und HTTPS. In diesem Fall werden die Daten möglicherweise unverschlüsselt im Netzwerk des Inhaltsanbieters übertragen. P. >

Um das Problem des Abfangens und Manipulierens von Daten anzugehen: Jeder, der Zugriff auf den privaten Schlüssel des Servers hat, kann die Übertragung leicht entschlüsseln . Folglich kann jeder Server, der ein Zertifikat vorlegt, das von einer von Ihrem Browser vertrauenswürdigen Zertifizierungsstelle signiert ist, die Website fälschen , solange der Hostname auf dem Zertifikat mit dem Hostnamen in der URL übereinstimmt. (Opera betreibt beispielsweise einen Proxy für sein Produkt Opera Mini. Der Opera Mini-Browser leitet den gesamten Datenverkehr über den Opera-Proxy und vertraut vollständig auf das vom Proxy vorgelegte Zertifikat. Daher wird zwar der Datenverkehr zwischen dem Browser und dem Der Proxy kann verschlüsselt sein und der Datenverkehr zwischen dem Proxy und dem Inhaltswebserver kann verschlüsselt sein. Opera verfügt über die technische Fähigkeit, alle Daten zu lesen, die über den Proxy übertragen werden.) Schließlich jeder, der die Möglichkeit hat, den Browser zu manipulieren (durch Einige Erweiterungs- oder Plugin-Mechanismen) oder der dynamische Linker (unter Verwendung von LD_PRELOAD) oder die Liste der vertrauenswürdigen Zertifikate des Browsers könnten die Daten ebenfalls abfangen, obwohl zu diesem Zeitpunkt die Integrität des Clients so beeinträchtigt wurde, dass keine Hoffnung auf eine sinnvolle Sicherheit besteht.

Ein auf dem Clientcomputer installierter Proxy kann tatsächlich einen entschlüsselten HTTPS-Verkehr abfangen.

Dazu muss jedoch ein eigenes Zertifikat im vertrauenswürdigen Stammzertifikatspeicher abgelegt werden. Dabei wird der Benutzer mit mehreren Sicherheitsherausforderungen konfrontiert, die nicht einfach umgangen werden können. Daher ist es unwahrscheinlich, dass diese Technik von Malware verwendet wird, es sei denn, der Benutzer war dumm genug, dies zuzulassen.

Ein großartiges Beispiel für Software, die diese Technik für nicht schändliche Zwecke verwendet, ist Fiddler - ein HTTP / HTTPS-Debugging-Tool für Webentwickler.

• Informationen zum Aktivieren der HTTPS-Entschlüsselung in Fiddler finden Sie hier.
• Sie können Screenshots der Dialoge sehen, die der Benutzer hier akzeptieren muss.

Was meinst du mit "System"? Die Verschlüsselung sollte in einigen Bibliotheken erfolgen. Dies kann in gewisser Weise als Teil des Systems und in anderer Hinsicht als Teil des Browsers angesehen werden. (Auch der Browser selbst ist Teil des Systems, da er für alle Benutzer installiert ist, die die ausführbare Datei gemeinsam nutzen.)

Die Sicherheitsgranularität besteht darin, dass sich der gesamte Browser und seine Komponenten im selben Sicherheitskontext befinden (zB Betriebssystemprozess mit eigenem Adressraum). Die Krypto findet in diesem Prozess statt.

Um die Klartextdaten abzufangen, müsste die Software einen Weg finden, um den Sicherheitskontext des Browsers zu verletzen. Dies ist normalerweise in Betriebssystemen möglich, die nur grobkörnige Sicherheitsrichtlinien für Code haben, der irgendwie Superuser-Berechtigungen erworben hat.

ZB. In Unix-ähnlichen Betriebssystemen können wir den Systemaufruf ptrace verwenden, um eine Verbindung zu einem Prozess herzustellen, und verschiedene Dinge ausführen, z. B. die Ausführung anhalten und fortsetzen, Systemaufrufe überwachen oder seinen Speicher untersuchen / ändern.

In den Browser eingehende Daten, wie z. B. Tastenanschläge, die Sie in Formulare eingeben, stammen aus einem anderen Sicherheitskontext, nämlich demjenigen, der den Tastaturtreiber im Betriebssystemkern enthält. Dies kann auch von privilegierten Programmen angegriffen werden, die Zugriff auf Daten erhalten, die über Treiber übertragen werden.

Auf dem wird jedoch ein HTTP / HTTPS-Proxy (im Gegensatz zu einem böswilligen Superuser-Programm, das in Prozesse hineinschaut) ausgeführt Dieselbe Maschine hätte keinen Zugriff auf Klartextverkehr. Was durch einen Proxy geht, ist das verschlüsselte HTTPS-Protokoll.