Kurz gesagt, ja, es kann das richtige Tool sein, aber in der Tat macht es keine Chancen, wenn Sie SSLStrip , SSLSplit , Mitmproxy oder ein anderes Tool verwenden, das Ihre Arbeit erledigen kann. Sie sollten sich nur vor der Funktionsweise hüten.
Wie @Quantim erwähnt hat, ist dies nicht möglich, ohne ein benutzerdefiniertes Zertifikat / eine benutzerdefinierte Zertifizierungsstelle im Gerät hinter dem Router zu installieren / zu haben, da eine benutzerdefinierte Zertifizierungsstelle als Man-in-the-Middle für SSL-Verbindungen erforderlich ist und in der Lage sein muss, und zu generieren Bescheinigungen, denen das Opfer vertraut . Dabei muss das Opfer das Stammzertifizierungsstellenzertifikat des Angreifers in seinem Vertrauensspeicher haben. Die Erklärung, wie Zertifizierungsstellen funktionieren und wie Sie mit den genannten Tools das gewünschte Ergebnis erzielen können, geht über den Rahmen dieser Antwort hinaus. Je nach Clienttyp - Desktop-Browser oder Mobiltelefon - sollten Sie jedoch beachten, dass sich die Installation der Stammzertifikate etwas unterscheidet.
SSLsplit funktioniert ganz ähnlich wie andere transparente SSL-Proxy-Tools - wie Mitmproxy, das mehr Funktionen bietet und komplexer ist. Es fungiert als Man-in-the-Middle zwischen dem Client und dem eigentlichen Server. Vorausgesetzt, der Datenverkehr wird auf den Server umgeleitet, auf dem SSLsplit ausgeführt wird und abgehört wird, indem das Standard-Gateway , ARP-Spoofing , das Fälschen von DNS-Einträgen oder andere Mittel geändert werden . Mit anderen Worten, wie Sie vielleicht vermutet haben, nimmt SSLsplit SSL-Verbindungen auf eine Weise auf, die vorgibt, der eigentliche Server zu sein, mit dem der Client eine Verbindung herstellt und mit dem er kommunizieren möchte. Tatsächlich generiert es dynamisch ein Zertifikat und signiert es mit dem privaten Schlüssel eines CA-Zertifikats, dem der Client vertrauen muss - wird.
Um Ihre Frage zu beantworten: " Ist SSLsplit das richtige Tool, um HTTPS-Verkehr auf einem WLAN-Router abzufangen und neu zu verschlüsseln? ", Kann dies der Fall sein, aber wissen Sie genug, um dies zu tun? Wenn ja, knacken Sie den Jackpot mit Ihren Recherchen.
Und um zu antworten: " Ist SSLsplit mit geänderten iptables-Regeln ausreichend und ein vernünftiger Weg, dies zu tun, oder müsste ich auch andere Teile des Linux-Netzwerksystems ändern? ", Sollte ich sagen, wenn Sie Ihre IPTables korrekt konfiguriert haben Regelsätze und NAT / DNAT-Regeln, und wenn Ihre Clients das CA-Zertifikat als vertrauenswürdig betrachten können, ist dies ausreichend - mit geänderten iptables-Regelsätzen und der Umleitung des Client-Datenverkehrs zum Server werden Sie die Clients abfangen 'Verkehr weiter, wie bereits erwähnt. Übrigens müssen Sie beachten, dass das Wort " transparent " beim Rechnen bedeutet (eines Prozesses oder einer Schnittstelle), dass es funktioniert, ohne dass der Benutzer sich seiner Anwesenheit bewusst ist.
Auszug aus der Originaldokumentation:
SSLsplit unterstützt einfache TCP-, einfache SSL-, HTTP- und HTTPS-Verbindungen über IPv4 und IPv6. Für SSL- und HTTPS-Verbindungen generiert und signiert SSLsplit gefälschte X509v3-Zertifikate im laufenden Betrieb , basierend auf dem ursprünglichen Serverzertifikat Betreff DN und der
Erweiterung subjectAltName . SSLsplit unterstützt die Server Name Indication (SNI) vollständig und kann mit RSA-, DSA- und ECDSA-Schlüsseln sowie DHE- und ECDHE-Chiffresuiten arbeiten. Abhängig von der OpenSSL-Version unterstützt SSLsplit SSL 3.0, TLS 1.0, TLS 1.1 und TLS 1.2 sowie optional auch SSL 2.0.
SSLsplit kann auch vorhandene Zertifikate verwenden, für die der private Schlüssel verfügbar ist, anstatt gefälschte Zertifikate zu generieren. SSLsplit unterstützt CN-Zertifikate mit NULL-Präfix und kann OCSP-Anforderungen generisch ablehnen. Bei HTTP- und HTTPS-Verbindungen entfernt SSLsplit Antwortheader für HPKP , um das Anheften von öffentlichen Schlüsseln zu verhindern ,
damit HSTS dem Benutzer das Akzeptieren nicht vertrauenswürdiger Zertifikate ermöglicht , und alternative Protokolle, um das Umschalten auf QUIC / SPDY zu verhindern. Als experimentelles Feature unterstützt SSLsplit generisch STARTTLS-Mechanismen.
Umleitung
Da das OP wissen muss, wie Anforderungen an SSLsplit umgeleitet werden, aber keinen Proxy einrichten möchte - wie in den Kommentaren erwähnt -, werde ich einen kurzen Einblick in diese Vorgehensweise geben und hoffe, dass dies helfen wird:
Scenario 1 : If SSLsplit is on the OpenWRT which you are using - i.e. if SSLsplit is set on the GateWay which victims (clients) are connecting to :
|
VICTIMS | ATTACKER
|
+-------~+ | (GATEWAY) If SSLsplit is set on the Gateway users are gonna connect to, you only need to redirect some ports to those SSLsplit is listening on
| | | SSLsplit will be running on two ports: 8080 for non-SSL TCP connections and 8443 for SSL connections.
| | ---> |
| | | sysctl -w net.ipv4.ip_forward=1
+~~~~~~~~+ | iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
| \ iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443 (HTTPS)
+-------~+ | \ +~~~~~~~~+ iptables -t nat -A PREROUTING -p tcp --dport 636 -j REDIRECT --to-ports 8443 (LDAPS)
| | | \ | | iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443 (MSA) Encryption = StartTLS
| | ---> | ===➤ | | iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443 (SMTPS) Encryption = SSL
| | | / | | iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443 (IMAPS) Encryption = StartTLS
+~~~~~~~~+ | / +~~~~~~~~+ iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080 (XMPP)
| / ...
+-------~+ |
| | |
| | ---> |
| | |
+~~~~~~~~+ |
|
|
Scenario 2 : AND IF SSLsplit is not set on the GateWay whic clients are connecting to - You will be in need of setting DNAT as the following :
VICTIMS | GATEWAY
|
+-------~+ |
| | |
| | ---> | IPTables will be like this :
| | |
+~~~~~~~~+ | SSLsplit iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 443 -j DNAT --to-destination z.z.z.z:8443
| \ iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 465 -j DNAT --to-destination z.z.z.z:8443
+-------~+ | \ +~~~~~~~~+ +~~~~~~~~+ ...
| | | \ | | | |
| | ---> | ===➤ | | ---------> | | In this scenario, all packets arriving on the router with a destination of x.x.x.x/CIDR will
| | | / | | | | depart from the router with a destination of z.z.z.z
+~~~~~~~~+ | / +~~~~~~~~+ +~~~~~~~~+
| /
+-------~+ | Redirects desired connection from somewhere
| | | to somewhere else to desired ports.
| | ---> |
| | |
+~~~~~~~~+ |
|
|
Achten Sie darauf, den Wert net.ipv4.ip_forwardauf 1 zu setzen. Der Befehl, den ich oben verwendet habe, sysctl -wist nicht permanent. Wenn Sie es dauerhaft festlegen möchten, sollten Sie die Datei bearbeiten, in der /etc/sysctl.confSie eine Zeile mit hinzufügen können net.ipv4.ip_forward = 1.
Standardmäßig ist bei den meisten Linux-Distributionen die IP-Weiterleitung deaktiviert. Und meiner Meinung nach ist dies eine gute Idee, da die meisten Benutzer sie nicht benötigen. Da Sie jedoch einen Linux-Router / Gateway einrichten, der auch für VPN-Server (pptp oder ipsec) nützlich ist, müssen Sie die Weiterleitung aktivieren. Dies kann auf verschiedene Arten geschehen, wie ich Ihnen gezeigt habe.