Leiten Sie den gesamten Webverkehr über TLS ohne VPN um

Annahmen:

Server:

• Ich habe einen Debian Squeeze-Server, der im öffentlichen Internet routingfähig ist und eine statische IPv4-Adresse hat.
• Ich habe uneingeschränkten Zugriff, um die Software auf dem Server zu ändern.
• Der Server kann beliebige Ports abhören, Firewall-Regeln neu konfigurieren. Grundsätzlich gibt es keine Einschränkungen für die Funktionsweise des Servers.

Klient:

• Ich kann Firefox, Java-Programme, .NET-Programme und einige native ausführbare Dateien ausführen, für die auf meinem lokalen System kein Administratorzugriff erforderlich ist (ein gesperrter Windows-Desktop ohne Administratorrechte).
• Ich kann Addons in Firefox installieren.
• Ich kann jeden Port auf der loopback ( localhost) - Schnittstelle abhören . Die oben genannten Programme können sich also an einen lokalen Port binden und beliebige Netzwerk-E / A ausführen, ohne einen Proxy zu durchlaufen.
• Der gesamte öffentliche Internetzugang wird über einen restriktiven HTTP-Proxy geleitet, der viele Websites blockiert und eine sorgfältige Statusprüfung durchführt. An Port 80 ist ausschließlich HTTP (kein TLS / SSL) zulässig. An Port 443 können CONNECTRemote-Hosts, die nicht durch den Domänennamen / die IP-Adresse blockiert sind, SSL / TLS basierend verwenden.
• Der restriktive HTTP-Proxy führt keine Deep Packet Inspection von TLS-Verbindungen durch, die über den Proxy zulässig sind, und führt keine Man in the Middle-Angriffe auf diese Verbindungen durch.
• Der oben genannte Server, auf den ich Zugriff habe, wird vom Proxy nicht blockiert.

Tor:

Ich möchte alle von Firefox über den oben genannten Server über SSL / TLS gesendeten HTTP- und HTTPS-Anforderungen weiterleiten.

Weitere Hinweise zum "Ziel":

• Auch wenn die Endpunktsite (zum Beispiel http://superuser.com) kein SSL / TLS für meinen Server verwendet, möchte ich dennoch SSL / TLS von meinem Client zu meinem Server verwenden und meinen Server die HTTP-Anforderung ausführen lassen - ob verschlüsselt oder nicht - - zu meinem gewünschten Ziel.
• Es ist mir egal, ob mein Server den SSL-Verkehr "im Klartext" betrachtet. Mit anderen Worten, ich benötige keine vollständige End-to-End-SSL-Verschlüsselung von meinem lokalen Client bis zum Remote-Server, wenn auf den Remote-Server z https://google.com. Mit anderen Worten, ich vertraue darauf, dass der Server meine Daten vertraulich behandelt.
• Ich bin bereit, Software oder Firefox-Addons zu installieren, für die keine Administratorrechte erforderlich sind und die unter 32-Bit-Windows 7 ausgeführt werden können.
• Open-Source-Software wird proprietärer Software vorgezogen, und Freeware wird Software vorgezogen, für die eine Lizenzgebühr erforderlich ist.
• Bestehende Software wird der Codierung neuer Software vorgezogen, obwohl ich bereit bin, Code zu schreiben, wenn dies der einzige Weg ist.

Ich suche eine lose beschriebene "Lösung", die beschreibt:

• Welche Software wäre auf dem Client erforderlich? Wenn Ihnen ein bestimmtes Softwarepaket bekannt ist, benennen Sie es. Andernfalls beschreiben Sie, was die Client-Software tun müsste .
• Welche Software wäre auf dem Server erforderlich? Wenn Ihnen ein bestimmtes Softwarepaket bekannt ist, benennen Sie es. Andernfalls beschreiben Sie, was die Serversoftware tun müsste .
• Wenn Sie oben bestimmte Softwarepakete benannt haben, beschreiben Sie, welche Konfigurationsparameter erforderlich sind, um sie so einzurichten, dass sie mein Ziel erreichen.
• Wenn Sie aus irgendeinem Grund glauben, dass dies nicht möglich ist , beschreiben Sie warum .

Dinge, die ich versucht habe, die nicht funktionieren

• Bei der Installation squidauf meinem Server habe ich versucht, einen eigenen Standard-HTTP-Proxy auf meinem Server einzurichten. Dies hat nicht geklappt, denn wenn ich Websites in Firefox über normales HTTP anfordere, versucht Firefox, auch über normales HTTP auf meinen Server zuzugreifen! Dies ist nicht akzeptabel, da der Proxy in meinem lokalen Netzwerk natürlich den regulären HTTP-Verkehr zwischen meinem Client und dem Server beobachten und / oder blockieren kann.
• VPNs funktionieren nicht , nicht einmal OpenVPN über TLS, das Port 443 überwacht, da ich auf dem lokalen Computer nicht die Berechtigung habe, einen tunNetzwerkadapter zu installieren , der Layer-3-Routing ausführen kann, und auch kein Layer-2-Routing durchführen kann (zB tap). Kurz gesagt: Ich benötige Administratorrechte, um OpenVPN zu installieren, und selbst wenn ich diese Administratorrechte vorübergehend hätte, wäre das Unternehmen nicht besonders erfreut, wenn es feststellen würde, dass es installiert ist. Ein Java- oder .NET-Programm fällt viel weniger auf, insbesondere wenn es nicht in Add / Remove Programs installiert ist und keine Kerneltreiberkomponente wie OpenVPN enthält.

Ich habe es herausgefunden. : D Diese Lösung erfüllt alle meine Anforderungen und erfüllt alle meine Ziele perfekt. Die Leistung ist auch nicht schlecht, wenn man bedenkt, wie viel Indirektion erforderlich ist, um dies zu erreichen.

Der allgemeine Ansatz lautet also:

1. Richten Sie eine lokale Zertifizierungsstelle (CA) ein und generieren Sie einen RSA- "Serverschlüssel" und einen "Clientschlüssel" (ich habe eine 256-Bit-Verschlüsselung verwendet). Dafür habe ich Easy-RSA Version 3.0.0-rc2 verwendet.

2. Führen Sie einen beliebigen Standard-HTTP-Proxy auf der "Debian Box" (dem Server im öffentlichen Internet) aus und achten Sie darauf, dass er nur auf localhost lauscht (er sollte NICHT dem öffentlichen Internet ausgesetzt sein). Für meine Zwecke habe ich verwendet Privoxy, Squidhätte aber genauso gut funktioniert. Da nur localhost abgehört wird, ist keine Authentifizierung erforderlich (es sei denn, auf Ihrer Box werden Prozesse ausgeführt, denen Sie nicht vertrauen. In diesem Fall, yikes ...)

3. Laden Sie stunnel herunter und installieren Sie es sowohl auf dem Client als auch auf dem Server. Der Prozess dafür wird betriebssystemspezifisch sein. In meinem Fall habe ich mich entschieden, Stunnel aus dem Quellcode (Paranoia ...) für Windows zu kompilieren. Dies war ein ziemlich komplizierter Prozess, auf den ich hier nicht näher eingehen werde. Auf der Serverseite war es im Paketmanager verfügbar :)

4. Die Konfiguration von Stunnel war anfangs ziemlich entmutigend, aber es ist einfacher als es scheint! Grundsätzlich benötigen Sie auf dem Server so etwas wie die folgende "Server's stunnel.conf". Auf dem Client benötigen Sie so etwas wie die folgende "client's stunnel.conf".

5. Starten Sie Privoxy; Stunnel auf dem Server starten und auf die Konfigurationsdatei verweisen. Starten Sie stunnel auf dem Client und zeigen Sie auf die Konfigurationsdatei. Es gibt wirklich nichts Besonderes an Privoxys Konfiguration. Die Standardeinstellung war in Ordnung für mich.

6. Stellen Sie in Firefox, Ihrem bevorzugten Browser auf der Clientseite, den HTTP- und HTTPS-Proxy so ein, dass er mit dem Port übereinstimmt, den der Stunnel Ihres Clients überwacht - wahrscheinlich so etwas wie localhost: 8080.

Ich sollte wahrscheinlich beachten, dass Sie, wenn der Proxy Ihres lokalen Netzwerks eine Authentifizierung erfordert, entweder einen Stunnel benötigen, um sich für Sie zu authentifizieren, oder einen anderen lokalen Intercepting-Proxy verwenden und diese miteinander verketten müssen - so etwas wie Firefox -> Stunnel -> lokal Authentifizierung des Proxys -> LAN-Proxy / Gateway -> Internet -> Stunnel Ihres Servers -> Privoxy.

Das ist viel Kopieren, aber es funktioniert!

;This is the *client's* stunnel.conf.
[https]
accept = localhost:9020
connect = your.lan.proxy:80
client = yes
protocol = connect
;protocolHost should be the same as the "accept" for the server
protocolHost = 1.2.3.4:443
;Same CAfile, different cert and key pair
CAfile = ca.crt
cert = client.crt
key = client.key
;VERY IMPORTANT!!! Make sure it's really your server and not a MITM attempt by your local network by making sure that the certificate authority "ca.crt" really signed the server's cert
verify = 2
;More performance tweaks...
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

.

;This is the *server's* stunnel.conf.
[https]
;1.2.3.4 is a publicly-routable, static IP address that can be connected to by your box that's under the firewall
accept = 1.2.3.4:443
;localhost:8118 is an example of where your local forwarding HTTP(S) proxy might reside.
connect = localhost:8118
CAfile = ca.crt
cert = server.crt
key = server.key
;VERY IMPORTANT!!! Without this, anyone in the world can use your public stunnel port as an open proxy!
verify = 2
;Set some timeouts higher for performance reasons
sessionCacheTimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

Sobald alles konfiguriert ist, sieht das Endergebnis ungefähr so ​​aus:

1. Ihr Webbrowser stellt eine Verbindung zu localhost:9020(stunnel) her und behandelt ihn wie einen Proxy, der HTTP- und / oder HTTPS-Verbindungen akzeptieren kann.
2. Sobald stunnel eine Verbindung von Ihrem Browser erhält, versucht es über den Proxy / das Gateway Ihrer Firewall, eine TLS-Sitzung mit Ihrem Remote-Server einzurichten. Zu diesem Zeitpunkt überprüft Ihr Client das PKI-Zertifikat Ihres Servers und umgekehrt.
3. Sobald die TLS-Sitzung mit Ihrem Remote-Server eingerichtet ist, leitet stunnel die von Ihrem Browser kommenden Daten, z. B. eine HTTP-Anforderung oder eine SSL-Tunnelanforderung, über den lokalen Proxy und direkt an Ihren Server weiter. Dieser Kanal ist verschlüsselt, sodass Ihr lokales Netzwerk nicht erkennen kann, was die Daten enthalten. Sie können dies nur durch eine Verkehrsanalyse erraten.
4. Sobald die auf Ihrem Server ausgeführtestunnel Instanz Daten empfängt, wird eine Verbindung zu z. B. hergestellt , wo Ihr HTTP (S) -Proxy-Server, in meinem Fall Privoxy, lauscht.localhost:8118
5. Privoxy verhält sich dann wie ein normaler Weiterleitungs-HTTP-Proxyserver und leitet Ihre Anforderungen über den ISP des Servers an das öffentliche Internet weiter.

Die Menge an Steckdosen und beteiligten Puffer macht dieses Verfahren sehr hohen Aufwand, vor allem , wenn Sie eine SSL - Verbindung über den Proxy sind nisten, aber es hat den Vorteil , dass Ihr lokales Netzwerk keine Möglichkeit zu wissen hat , welche Websites Sie SSL gerade besuchen über. Ich meine, es weiß, dass Sie Ihren Server besuchen, aber abgesehen davon weiß es nicht, ob Sie Google Mail oder SuperUser oder was auch immer besuchen. Und Ihr lokales Gateway kann Sie nicht filtern oder blockieren.

Ich habe dieses Setup auf meinem lokalen Computer ausprobiert und kann versichern, dass der "restriktive Proxy" ein CONNECT DEBIAN_IP:443 HTTP/1.1Zertifikat erhalten würde , aber es wird kein Zertifikat angezeigt. Daher bin ich mir nicht sicher, ob dies funktionieren würde.

Nehmen wir an: Ihr Debian hat Apacheoder Squidmuss den Proxy und einen SSH-Server ausführen . Auf Ihrem Client-PC benötigen Sie puttyein Programm, für dessen Ausführung keine Administratorrechte erforderlich sind , das nicht installiert werden muss und das von einem Pendrive ausgeführt werden kann.

Zuerst dein Debian:

Machen Sie Ihre SSH hören auf Port 443, fügen Sie einfach (oder ersetzen Sie die aktuellen Port) ein Port 443auf /etc/ssh/sshd_configund auch TCP - Weiterleitung zulassen (addieren AllowTcpForwarding yesauf dieser Datei)

Konfigurieren Sie Ihren Squid oder Apache für das Proxying. Da dies über einen SSH-Tunnel verwendet werden soll, müsste nur die Loopback-Schnittstelle abgehört werden. Falls Sie einen Apache verwenden:

Listen 127.0.0.1:8080
ProxyRequests On
<Proxy *>
  Order deny,allow
</Proxy>

Server fertig, konfigurieren wir Ihren Client-PC:

Konfigurieren Sie auf Putty die öffentliche IP Ihres Debian als Hostund 443als Port. Stellen Sie sicher, dass SSHnoch ausgewählt ist. Ändern Sie die Connection -> ProxyEinstellungen, wählen Sie HTTPIhre "restriktiven Proxy" -Einstellungen aus und füllen Sie sie aus. Ändern Sie die ConnectionEinstellungen und erstellen Sie ein Keepalive von 30- 60. Wechseln Sie zu Connection -> SSH -> Tunnels. Auf source portstabilisieren 8080und auf Destination, localhost:8080. Lassen Sie Localausgewählt und drücken Sie Add. Sie sollten in dem Raum über so etwas sehen L8080 locahost:8080. Wechseln Sie zurück zu den SessionEinstellungen, notieren Sie sich einen Namen in der ersten Zeile von Saved sessionsund speichern Sie alle diese mühsamen Einstellungen , um die Verbindung an den folgenden Tagen wiederherzustellen.

Jetzt können Sie versuchen, Opendie Verbindung zu Ihrem Debian herzustellen. Wenn Sie die Eingabeaufforderung des Benutzers sehen, sind wir nur einen Schritt davon entfernt. Wenn nicht ... müssen wir nach einem anderen Weg suchen.

Legen Sie jetzt in Firefox den localhostPort 8080als Proxy fest.

Sie sind auf halbem Weg mit der Einrichtung eines Proxys auf Ihrem Server. Die andere Hälfte ist SSL auf dem Server und ein lokaler Proxy auf dem Client, der Putty verwendet, um eine Verbindung zu Ihrem SSL-fähigen HTTP-Proxy herzustellen, und Firefox so eingestellt, dass alles auf 127.0.0.1 als Proxy ausgeführt wird.

Ich habe gerade schnell nach einem Kitt-Setup gesucht und Folgendes gefunden: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/