HTTPS-Entschlüsselung (Man-in-the-Middle-Angriff, MitM)

Chute kann HTTPS-Verkehr per MitM entschlüsseln. Weitere Informationen finden Sie im Wikipedia-Artikel. Auf iPhone, Apple TV und Android ist dies eine lizenzpflichtige Funktion, und die Engine setzt das durch: Ohne Lizenz wird nichts entschlüsselt, was auch immer die Konfiguration sagt. Siehe Lizenz und Aktivierung.

Der Zertifikatsgenerator kann Ihnen helfen, ein neues CA-Zertifikat für Debugging-Zwecke zu erstellen und es vom System als vertrauenswürdig einstufen zu lassen. Er ist in Chute Mac und im Konfigurationseditor von Chute iOS verfügbar. Dieses Zertifikat wird lokal generiert und nur in Ihrer Profildatei und dem System-Schlüsselbund gespeichert. Der Schlüssel des neuen Zertifikats wird zufällig mit OpenSSL generiert. Chute Android hat keinen Generator: Importieren Sie im Editor unter MitM → CA konfigurieren eine vorhandene PKCS#12-Datei; CA installieren übergibt deren CA-Zertifikat dem Zertifikatsinstaller von Android — siehe CA-Zertifikat installieren und als vertrauenswürdig einstufen.

Sie können auch ein vorhandenes CA-Zertifikat verwenden. Exportieren Sie das Zertifikat im PKCS#12-Format (.p12) mit Passphrase. Bitte beachten Sie, dass die Passphrase nicht leer sein darf; Chute weigert sich, eine PKCS#12-Datei ohne Passphrase zu laden. Verwenden Sie den Befehl base64, um es in einen base64-String zu kodieren, und fügen Sie diese Einstellungen unten in Ihre Konfigurationsdatei ein.

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
hostname = *google.com

Chute entschlüsselt nur den Verkehr zu den hier deklarierten Hosts, setzen Sie den Schlüssel also immer. Auf jeder Plattform entschlüsselt ein eingeschalteter [MITM]-Abschnitt, der kein hostname deklariert, gar nichts — egal ob der Schlüssel ganz fehlt oder nur hostname-disabled-Einträge angegeben sind. Über den HTTP-Proxy wird nur HTTPS entschlüsselt, das per CONNECT ankommt: Eine Klartext-HTTP-Anfrage wird wie gewohnt weitergeleitet, auch wenn ihr Host in hostname steht.

Wildcard-Zeichen und ? werden unterstützt. Beachten Sie, dass ? nur dann als Wildcard fungiert, wenn die Regel auch `enthält; eine Regel, die nur?` enthält, wird wörtlich verglichen.

• Verwenden Sie das Präfix -, um einen Hostnamen auszuschließen. Die Einträge werden in der geschriebenen Reihenfolge geprüft, und der erste passende entscheidet; ein Ausschluss muss daher vor dem Eintrag stehen, aus dem er etwas herausnimmt: hostname = -*.apple.com, * lässt apple.com in Ruhe, während hostname = *, -*.apple.com es entschlüsselt.
• Standardmäßig werden nur Anfragen an Port 443 entschlüsselt.
  • Verwenden Sie das Suffix :port, um andere Ports zu erlauben.
  • Verwenden Sie das Suffix :0, um alle Ports zu erlauben.

Beispiel:

• -*.apple.com: Schließt alle Anfragen an *.apple.com auf Port 443 aus.
• www.google.com: Erlaubt MitM für www.google.com auf Port 443.
• www.google.com:8080: Erlaubt MitM für www.google.com auf Port 8080.
• www.google.com:0: Erlaubt MitM für www.google.com auf allen Ports.
• *: Erlaubt MitM für alle Hostnamen auf Port 443. (Nicht empfohlen)
• *:0: Erlaubt MitM für alle Hostnamen auf allen Ports. (Nicht empfohlen)

Vier Schlüsselwörter stehen für ganze Klassen von Zielen und nehmen wie ein Name das Präfix - und das Suffix :port an: <ip-address> (jede Verbindung zu einem IP-Literal), <ipv4-address>, <ipv6-address> und <simple-hostname> (ein Name ohne Punkt, etwa intranet). hostname = -<simple-hostname>, * entschlüsselt alles außer einteiligen Namen, und hostname = <ip-address> entschlüsselt nur Verbindungen zu einer Adresse. Die Adress-Schlüsselwörter greifen nur bei einem CONNECT zu einer Adresse über den HTTP-Proxy: Eine TUN-Verbindung wird nur anhand des Hostnamens entschlüsselt — des Namens, den Chute für sie aufgelöst hat, oder des Servernamens in ihrem TLS-Handshake, wenn sniffing-enabled aktiv ist —, daher wird eine Verbindung zu einer bloßen Adresse ohne Servernamen nie entschlüsselt.

Ein Hostnamen-Eintrag kann nach dem ersten / auch ein Pfadmuster enthalten. Über die Entschlüsselung wird aber entschieden, wenn die Verbindung aufgebaut wird — beim CONNECT oder beim Start einer TUN-Sitzung —, bevor ein Anfragepfad bekannt ist. Ein pfadgebundener Eintrag entschlüsselt daher bei einem Host-Treffer die gesamte Verbindung, und ein Ausschluss der Form -host/path greift überhaupt nicht. Verlassen Sie sich nicht darauf, um einen Host von der Entschlüsselung fernzuhalten.

• example.com/api/*: Erlaubt MitM für example.com auf Port 443; der Pfad schränkt es nicht ein.

Eine allgemeine Konfiguration könnte wie folgt aussehen:

hostname = -*.apple.com, -*.icloud.com, *

Chute wendet URL-Umschreibungs-, Header-Umschreibungs-, Body-Umschreibungs- und Mock-Regeln ([Map Local]) sowie Skripte auf alle MitM-Anfragen an — auf jede Anfrage einer entschlüsselten Verbindung, nicht nur auf ihre erste. Eine entschlüsselte HTTP/1.1-Verbindung trägt einen einzigen Austausch: Sobald die Antwort draußen ist, schließt Chute die Verbindung, sodass der Client seine nächste Anfrage über eine neue Verbindung sendet, die auf dieselbe Weise behandelt wird. Eine Anfrage, die auf derselben Verbindung hinter der ersten per Pipelining folgt, wird nicht verarbeitet; der Client sendet sie auf der neuen Verbindung erneut. Die Ausnahme ist eine Verbindung, die Chute Android aus dem VPN entschlüsselt: Sie bleibt offen, und jede Anfrage darauf wird der Reihe nach behandelt. Geschlossen wird sie nach einer Antwort, die Chute selbst gibt — einer Mock-Antwort, einer Antwort der URL-Umschreibung, der response eines Skripts — und nach einer Antwort, deren Body von einem http-response-Skript stammt, das am Header lief. HTTP/2-Verbindungen behalten ihre Verbindung, ebenso ein WebSocket-Upgrade: Nach der 101-Antwort laufen die Daten in beide Richtungen unverändert durch.

MitM unterstützt HTTP/2, über den HTTP-Proxy ebenso wie über TUN. Vor dem TLS-Handshake mit dem Server liest Chute, welche Protokolle der Client anbietet (ALPN): Bietet der Client h2 an und setzt [MITM] nicht h2 = false, werden dem Server h2 und http/1.1 angeboten, sonst nur http/1.1. Dem Client wird dann das Protokoll angeboten, das der Server gewählt hat, sodass beide Seiten dasselbe sprechen; hat der Client dieses Protokoll nicht angeboten, antwortet Chute ohne ALPN, und der Handshake geht weiter. Bei HTTP/2 werden Trailer (etwa grpc-status von gRPC) und vorläufige 1xx-Antworten wie 103 Early Hints unverändert weitergegeben; Regeln und Skripte sehen sie nicht. Der Surge-[MITM]-Schlüssel tcp-connection wird in Konfigurationsdateien akzeptiert, aber ignoriert.

Einige Anwendungen haben strenge Sicherheitsrichtlinien mit gepinnten Zertifikaten oder CAs (Certificate Pinning). Die Aktivierung der Entschlüsselung für diese Hosts kann zu Problemen führen.

Chute bewahrt die von ihm ausgestellten Host-Zertifikate in einem Speicher auf und verwirft bei vollem Speicher das am längsten nicht genutzte: 512 Zertifikate unter macOS, 128 unter iOS, tvOS und Android.

CA-Zertifikat installieren und als vertrauenswürdig einstufen

Das Generieren (oder Importieren) der CA ist nur die halbe Einrichtung — das Betriebssystem muss ihr auch vertrauen. Bis beide Schritte erledigt sind, schlägt jede entschlüsselte Website mit einer Zertifikatswarnung fehl. Die Zertifikatsseite in der App zeigt den aktuellen Zustand („Vertrauenswürdiges CA-Zertifikat“ / „Nicht vertrauenswürdiges CA-Zertifikat“).

Chute iOS — öffnen Sie im Konfigurationseditor MITM → CA konfigurieren:

1. Neues CA-Zertifikat generieren (oder P12-Zertifikat importieren für ein vorhandenes).
2. Tippen Sie auf CA-Zertifikat im System installieren. Eine Safari-Seite öffnet sich — tippen Sie auf Install Certificate und erlauben Sie den Download, installieren Sie dann das heruntergeladene Profil unter Einstellungen → Allgemein → VPN & Geräteverwaltung.
3. Vertrauen Sie ihm: Einstellungen → Allgemein → Info → Zertifikatsvertrauenseinstellungen, und aktivieren Sie das volle Vertrauen für die Chute-CA. Diesen Schritt übersehen die meisten — ohne ihn ist das Zertifikat zwar installiert, aber nicht vertrauenswürdig, und die Entschlüsselung schlägt weiterhin fehl.

Chute Mac — öffnen Sie im Konfigurationsfenster MitM:

1. Neues Zertifikat erzeugen (oder Zertifikat aus PKCS#12-Datei importieren für ein vorhandenes).
2. Klicken Sie auf Zertifikat im System installieren. macOS fragt nach einem Administratorpasswort und fügt das Zertifikat dem System-Schlüsselbund als vertrauenswürdiges Root-Zertifikat hinzu — manuelle Schritte in der Schlüsselbundverwaltung sind nicht nötig.
3. Zertifikat exportieren speichert eine .pem-Kopie für die Installation auf anderen Geräten.

Chute Android — öffnen Sie im Konfigurationseditor MitM → CA konfigurieren:

1. P12 importieren schreibt eine vorhandene PKCS#12-Datei als base64 in ca-p12, wie es die Apple-Apps tun, sodass die Konfiguration ihre CA auf andere Geräte mitnimmt; geben Sie deren Passphrase unter CA-Passphrase ein. Chute Android hat keinen Generator. Ein ca-p12-Wert, der eine Datei nennt, wie ihn frühere Versionen des Editors geschrieben haben, wird weiterhin gelesen.
2. CA installieren übergibt das CA-Zertifikat aus dieser P12-Datei dem Zertifikatsinstaller von Android. Ab Android 11 kann eine App ein CA-Zertifikat auf diesem Weg nicht mehr installieren: Installieren Sie es stattdessen aus einer Zertifikatsdatei in den Sicherheitseinstellungen des Systems — einer .pem- oder .crt-Kopie davon, etwa der, die Zertifikat exportieren in Chute Mac speichert.
3. Android legt es unter den Nutzerzertifikaten ab, und Apps, die auf Android 7.0 oder neuer ausgerichtet sind, vertrauen diesen nur, wenn sie sich ausdrücklich dafür entscheiden. Viele Apps scheitern daher auch nach der Installation des Zertifikats am Handshake — schließen Sie ihre Hosts aus hostname aus.

Schlägt eine bestimmte App trotz vertrauenswürdigem Zertifikat weiterhin fehl, pinnt sie höchstwahrscheinlich ihre eigenen Zertifikate — schließen Sie ihre Hosts mit einem --Präfix aus hostname aus, statt dagegen anzukämpfen.

Optionen

skip-server-cert-verify

skip-server-cert-verify = true

Überprüft das Zertifikat des entfernten Hosts beim MitM nicht. Wenn aktiviert, akzeptiert Chute jedes vom Upstream-Server präsentierte Zertifikat, einschließlich selbstsignierter oder ungültiger Zertifikate. Dies ist nützlich für Entwicklungsumgebungen, verringert jedoch die Sicherheit.

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
skip-server-cert-verify = true
hostname = *google.com

Sicherheitshinweis: Die Aktivierung von skip-server-cert-verify macht MitM-Verbindungen anfällig für Man-in-the-Middle-Angriffe zwischen Chute und dem Upstream-Server. Aktivieren Sie dies nur für vertrauenswürdige Netzwerke oder Entwicklungszwecke.

hostname-disabled

hostname-disabled = *.bank.example, pay.example.com:8443

Hosts, die nie entschlüsselt werden, auch wenn ein Eintrag in hostname sie erfasst. Wildcard-Zeichen funktionieren wie in hostname, und :port beschränkt einen Eintrag auf einen Port. Praktisch, um Hosts abzuschalten, die ein Modul hinzugefügt hat, ohne das Modul zu bearbeiten.

auto-quic-block

auto-quic-block = true

Blockiert QUIC zu jedem Host, der entschlüsselt würde, sodass HTTP/3-Clients auf TLS über TCP zurückfallen, wo MitM den Verkehr sieht. Es wirkt zusätzlich zu block-quic, nicht an dessen Stelle.