Przekieruj CAŁY ruch internetowy przez TLS bez VPN

10

Założenia:

Serwer:

  • Mam serwer Debian Squeeze, który można routować w publicznym Internecie, ze statycznym adresem IPv4.
  • Mam nieograniczony dostęp do modyfikowania oprogramowania na serwerze.
  • Serwer może nasłuchiwać na dowolnych portach, rekonfigurować reguły zapory, w zasadzie nie ma ograniczeń co do tego, co serwer może zrobić.

Klient:

  • Mogę uruchamiać Firefox, programy Java, programy .NET i niektóre natywne pliki wykonywalne, które nie wymagają dostępu administratora w moim systemie lokalnym (zablokowany pulpit systemu Windows bez uprawnień administratora).
  • Mogę zainstalować dodatki w przeglądarce Firefox.
  • Mogę nasłuchiwać na dowolnym porcie localhostinterfejsu loopback ( ). Tak więc wspomniane programy mogą łączyć się z portem lokalnym i wykonywać dowolne sieciowe operacje we / wy, bez przechodzenia przez serwer proxy.
  • Cały publiczny dostęp do Internetu jest kierowany przez restrykcyjny serwer proxy HTTP, który blokuje wiele witryn i dokładnie kontroluje stan. Na porcie 80 pozwala wyłącznie na HTTP (bez TLS / SSL). Na porcie 443 umożliwia CONNECToparte na SSL / TLS zdalne hosty, które nie są blokowane przez nazwę domeny / adres IP.
  • Ograniczający serwer proxy HTTP nie przeprowadza głębokiej kontroli pakietów połączeń TLS, które są dozwolone przez serwer proxy, i nie wykonuje ataków typu Man in the Middle na te połączenia.
  • Wyżej wymieniony serwer, do którego mam dostęp, nie jest blokowany przez proxy.

Cel:

Chcę kierować wszystkie żądania HTTP i HTTPS wysyłane przez Firefox przez powyższy serwer przez SSL / TLS.

Inne uwagi na temat „celu”:

  • Nawet jeśli witryna punktu końcowego (na przykład http://superuser.com) nie korzysta z SSL / TLS na moim serwerze, nadal chcę używać SSL / TLS od mojego klienta do mojego serwera i zlecić serwerowi wykonanie żądania HTTP - zaszyfrowanego lub nie - - do mojego pożądanego celu.
  • Nie dbam o to, czy mój serwer patrzy na ruch SSL „w sposób oczywisty”. Innymi słowy, nie wymagam pełnego szyfrowania SSL od mojego lokalnego klienta, aż do zdalnego serwera, jeśli dostęp do zdalnego serwera uzyskuje się np https://google.com. Innymi słowy, ufam serwerowi, że zachowa poufność moich danych.
  • Jestem skłonny zainstalować dowolne oprogramowanie lub dodatki do Firefoksa, które nie wymagają uprawnień administratora i mogą działać w 32-bitowym systemie Windows 7.
  • Oprogramowanie typu open source jest lepsze od praw własności, a freeware jest lepsze od oprogramowania wymagającego opłaty licencyjnej.
  • Istniejące oprogramowanie jest lepsze niż konieczność kodowania nowego oprogramowania, chociaż jestem gotów napisać kod, jeśli jest to jedyny sposób.

Szukam luźno opisanego „rozwiązania”, które opisuje:

  • Jakie oprogramowanie będzie wymagane na kliencie? Jeśli znasz konkretny pakiet oprogramowania, nazwij go; w przeciwnym razie opisz, co musiałoby zrobić oprogramowanie klienckie .
  • Jakie oprogramowanie będzie wymagane na serwerze? Jeśli znasz konkretny pakiet oprogramowania, nazwij go; w przeciwnym razie opisz, co musiałoby zrobić oprogramowanie serwera .
  • Jeśli wyżej wymieniono konkretne pakiety oprogramowania, opisz, jakie parametry konfiguracji byłyby konieczne, aby skonfigurować je, aby osiągnąć mój cel.
  • Jeśli z jakiegoś powodu uważasz, że nie jest to możliwe , opisz dlaczego .

Rzeczy, które próbowałem, które nie działają

  • Instalując squidna moim serwerze, próbowałem skonfigurować własne własne proxy HTTP na moim serwerze. To nie zadziałało, ponieważ kiedy żądam stron internetowych w Firefoksie przez zwykły HTTP, Firefox próbuje również uzyskać dostęp do mojego serwera przez zwykły HTTP! Jest to niedopuszczalne, ponieważ serwer proxy w mojej sieci lokalnej może oczywiście obserwować i / lub blokować regularny ruch HTTP między moim klientem a serwerem.
  • Sieci VPN nie działają , nawet OpenVPN przez nasłuchiwanie TLS na porcie 443, ponieważ nie mam uprawnień na komputerze lokalnym do zainstalowania tunkarty sieciowej, która może wykonywać routing w warstwie 3, ani nie mogę wykonywać żadnego rodzaju routingu w warstwie 2 (np tap.). Krótko mówiąc: potrzebuję uprawnień administratora, aby zainstalować OpenVPN, a nawet gdybym miał te uprawnienia tymczasowo, firma nie byłaby zbyt zadowolona, ​​gdyby dowiedziała się, że został zainstalowany. Program Java lub .NET jest znacznie mniej zauważalny, szczególnie gdy nie jest zainstalowany w Dodaj / Usuń programy i nie ma komponentu sterownika jądra, jak robi to OpenVPN.
allquixotic
źródło
Czy próbujesz Skarpetki? możesz to zdefiniować na porcie 443 na swoim serwerze.
Ashian
Czy możesz skorzystać z rozwiązania opisanego w tym artykule: VPN biednego człowieka ? Zauważ, że jego link do HTTPTunnel jest nieprawidłowy.
harrymc
1
delegate.org może być pomocny.
Arjan,
@Ashian Nie, SOCKS nie będzie działać, chyba że jest zapakowane w TLS. SOCKS nie jest protokołem opartym na HTTP, więc kiedy trafi do wewnętrznego proxy, zostanie zablokowany. A gdybym był w stanie uruchomić go przez TLS, prawdopodobnie użyłbym innego protokołu. Moim pierwszym problemem jest skonfigurowanie tunelu TLS w taki sposób, aby Firefox mógł z niego korzystać. Nadal nie widziałem wyjaśnienia, jak to zrobić.
allquixotic
@harrymc: Tytuł pytania mówi przez TLS . Tunel HTTP kieruje pakiety IP przez HTTP , który jest niezaszyfrowany i nie używa TLS. Sam artykuł mówi, że połączenie nie jest szyfrowane. Nie ma mowy, żeby mój proxy to przepuścił. Co więcej, nie mam socatuprawnień ani uprawnień administracyjnych do skrzynki klienta Windows.
allquixotic

Odpowiedzi:

5

Rozgryzłem to. : D To rozwiązanie spełnia wszystkie moje wymagania i doskonale spełnia wszystkie moje cele. Wydajność też nie jest zła, biorąc pod uwagę poziom pośredni niezbędny do osiągnięcia tego.

Ogólne podejście jest zatem następujące:

  1. Skonfiguruj lokalny ośrodek certyfikacji (CA) i wygeneruj RSA „klucz serwera” i „klucz klienta” (użyłem szyfrowania 256-bitowego). W tym celu użyłem Easy-RSA w wersji 3.0.0-rc2.

  2. Uruchom dowolny standardowy serwer proxy HTTP na „Debian Box” (serwer w publicznym Internecie), upewniając się, że nasłuchuje tylko na lokalnym hoście (NIE powinien być narażony na publiczny Internet). Do moich celów wykorzystałem Privoxy, ale Squidrównie dobrze działałby. Ponieważ słucha tylko na localhost, uwierzytelnianie nie jest konieczne (chyba że istnieją procesy uruchomione w oknie, które się nie ufasz; w takim przypadku, Jezu ...)

  3. Pobierz stunnel i zainstaluj go zarówno na kliencie, jak i serwerze. Proces tego będzie zależał od systemu operacyjnego; w moim przypadku zdecydowałem się skompilować stunnel ze źródła (paranoja ...) dla Windows, co było raczej zaangażowanym procesem, którego tutaj nie będę szczegółowo opisywał. Po stronie serwera był dostępny w menedżerze pakietów :)

  4. Konfiguracja Stunnela była początkowo dość zniechęcająca, ale jest prostsza niż się wydaje! Zasadniczo na serwerze potrzebujesz czegoś takiego jak „stunnel.conf serwera” poniżej. Na kliencie potrzebujesz czegoś w rodzaju „stunnel.conf klienta”.

  5. Uruchom Privoxy; uruchom stunnel na serwerze, wskazując go na plik konfiguracyjny; uruchom stunnel na kliencie, wskazując go na plik konfiguracyjny. Tak naprawdę nie ma nic specjalnego w konfiguracji Privoxy; domyślnie było dla mnie w porządku.

  6. W przeglądarce Firefox, z której wybierasz przeglądarkę po stronie klienta, ustaw HTTP i HTTPS proxy tak, aby były portem, na którym nasłuchuje twój stunnel - prawdopodobnie coś takiego jak localhost: 8080.

Powinienem prawdopodobnie zauważyć, że jeśli serwer proxy twojej sieci lokalnej wymaga pewnego uwierzytelnienia, albo będziesz musiał uzyskać stunnel, aby się uwierzytelnić, albo użyj innego lokalnego serwera przechwytującego proxy i połącz je razem - coś w rodzaju Firefox -> stunnel -> local proxy uwierzytelniające -> proxy LAN / brama -> internet -> stunnel twojego serwera -> privoxy.

To dużo kopiowania, ale działa!

;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

Po skonfigurowaniu wszystkiego wynik końcowy wygląda mniej więcej tak:

  1. Twoja przeglądarka łączy się z localhost:9020(stunnel) i traktuje ją jak serwer proxy, który może akceptować połączenia HTTP i / lub HTTPS.
  2. Gdy stunnel otrzyma połączenie z przeglądarki, dociera za pośrednictwem serwera proxy / bramy zapory sieciowej do ustanowienia sesji TLS ze zdalnym serwerem. W tym momencie klient weryfikuje certyfikat PKI serwera i odwrotnie.
  3. Po ustanowieniu sesji TLS ze zdalnym serwerem stunnel przekazuje dane pochodzące z przeglądarki, np. Żądanie HTTP lub żądanie tunelu SSL, przez lokalny serwer proxy i bezpośrednio do serwera. Ten kanał jest szyfrowany, więc Twoja sieć lokalna nie może stwierdzić, co zawierają dane, mogą jedynie zgadywać, przeprowadzając analizę ruchu.
  4. Gdy stunnelinstancja działająca na serwerze zacznie odbierać dane, otworzy połączenie np. Z miejscem localhost:8118, w którym serwer proxy HTTP (S), w moim przypadku Privoxy, nasłuchuje.
  5. Privoxy następnie działa jak normalny serwer proxy HTTP do przekazywania dalej i przekazuje twoje żądania do publicznego Internetu za pośrednictwem dostawcy ISP serwera.

Ilość gniazd i buforów powoduje, że ta metoda jest bardzo obciążona, szczególnie jeśli zagnieżdżasz połączenie SSL przez proxy, ale ma tę zaletę, że twoja sieć lokalna nie ma możliwości sprawdzenia, które strony odwiedzasz przez SSL. To znaczy, wie, że odwiedzasz swój serwer, ale poza tym nie wie, czy odwiedzasz Gmaila, SuperUser czy cokolwiek innego. Twoja lokalna brama nie ma możliwości filtrowania ani blokowania cię.

allquixotic
źródło
2

Wypróbowałem tę konfigurację na moim komputerze lokalnym i mogę zapewnić, że „restrykcyjny serwer proxy” otrzyma CONNECT DEBIAN_IP:443 HTTP/1.1certyfikat, ale nie zobaczy żadnego certyfikatu, więc nie jestem pewien, czy to zadziała.

Chodźmy asume: Twój Debian ma Apachelub Squidzrobić proxy i serwer SSH. Na komputerze klienckim potrzebujesz putty, który jest programem, który nie wymaga uprawnień administratora do uruchomienia, nie wymaga instalacji i może działać z pendrive'a.

Najpierw twój Debian:

Spraw, aby Twój SSH nasłuchiwał na porcie 443, po prostu dodaj (lub zamień swój obecny port) Port 443na, /etc/ssh/sshd_configa także zezwól na przekazywanie TCP (dodaj AllowTcpForwarding yesdo tego pliku)

Skonfiguruj Squid lub Apache, aby wykonywać proxy. Ponieważ będzie to wykorzystywane przez tunel SSH, wystarczyłoby nasłuchiwać na interfejsie pętli zwrotnej. W przypadku korzystania z Apache:

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

Serwer gotowy, skonfigurujmy komputer kliencki:

Na Kit skonfiguruj publiczny adres IP Debiana jako Hosti 443jako port. Upewnij się, że SSHjest nadal wybrany. Zmień Connection -> Proxyustawienia, wybierz HTTPi wypełnij ustawienia „restrykcyjnego proxy”. Przejdź do Connectionustawień i ustal relację z 30- 60. Zmień na Connection -> SSH -> Tunnels. On source portutwierdzi 8080i na Destination, localhost:8080. Pozostaw Localzaznaczone i naciśnij Add. Powinieneś widzieć w przestrzeni nad czymś takim L8080 locahost:8080. Wróć do Sessionustawień, zapisz nazwę w pierwszym rzędzie Saved sessionsi zapisz wszystkie te żmudne ustawienia, aby przywrócić połączenie w kolejnych dniach.

Teraz możesz spróbować Openpołączyć się z twoim Debianem. Jeśli zobaczysz monit użytkownika, jesteśmy o krok od zakończenia tego. Jeśli nie ... będziemy musieli szukać innej drogi.

Teraz w przeglądarce Firefox ustaw localhostport 8080jako serwer proxy.

NuTTyX
źródło
Niestety to nie zadziała, ponieważ protokół SSH nie jest oparty na SSL / TLS. Kiedy restrykcyjne proxy po mojej stronie klienta wącha połączenie przechodzące przez port 443, natychmiast wie, że to nie jest gniazdo TLS, i upuszcza je. To prawda, że ​​mogę owinąć go TLS, ale nie tak opisuje twoja odpowiedź.
allquixotic
Zrobiłem test z proxy HTTP (BURP) i działałem, więc warto było spróbować. Zawijanie SSH przez TLS i utrzymywanie jego działania może być trudne, ale ...
NuTTyX
SSH przez TLS jest niepotrzebną pośrednią. Jeśli masz już uruchomione gniazdo TLS, tak naprawdę nie potrzebujesz SSH. Zobacz moją odpowiedź poniżej. (Uwaga: nie znałem tej odpowiedzi aż do niedawna, więc to nie tak, że wytrząsnąłem twoją odpowiedź, a potem opublikowałem rozwiązanie. Dosłownie odkryłem to około 25 minut temu.)
allquixotic
Cieszę się, że to rozwiązałeś
NuTTyX
1

Jesteś w połowie drogi do skonfigurowania serwera proxy na swoim serwerze. Druga połowa to SSL na serwerze, a lokalny serwer proxy na kliencie używa putty do łączenia się z serwerem HTTP obsługującym SSL i ustaw Firefox na proxy wszystko na 127.0.0.1.

Właśnie zrobiłem szybkie google dla zestawu kit i znalazłem to: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/

Joe
źródło
Aby być uczciwym, podał znacznie więcej szczegółów w swoim poście. Ale dziękuję za głosowanie.
Joe
@krowe Nigdzie w mojej odpowiedzi nie jest napisane „Apache” lub „PuTTY”.
allquixotic
Nie, nie przeszkadza mi, że głosowałeś na tę odpowiedź! Właśnie zinterpretowałem twój komentarz jako powiedzenie, że w jakiś sposób przekopywałem jego odpowiedź lub zdzierałem ją, podczas gdy tak naprawdę niewiele zyskałem na tej odpowiedzi, gdy szukałem rozwiązania. Z perspektywy czasu blog, do którego prowadzi link, wydaje się być dobrą alternatywą dla odpowiedzi, którą opublikowałem, chociaż nie jestem pewien, jak różni się wydajność, funkcje itp. (Może być lepsza lub gorsza).
allquixotic
+1 Podoba mi się ten, ponieważ i tak prowadzę serwer WWW.
krowe