stunnel ruch VPN i upewnij się, że wygląda jak ruch SSL na porcie 443

Staram się, aby mój ruch wychodzący i przychodzący wyglądał na możliwie jak najbardziej zgodny z ruchem SSL. Czy istnieje sposób na DPI własny ruch, aby upewnić się, że wygląda jak ruch SSL, a nie ruch OpenVPN? I w oparciu o moją konfigurację konfiguracji, czy cały ruch wykorzystuje port 443, który jest portem SSL?

Moja konfiguracja jest następująca:

STUNNEL na laptopie:

[openvpn]
# Set sTunnel to be in client mode (defaults to server)
client = yes  
# Port to locally connect to
accept = 127.0.0.1:1194  
# Remote server for sTunnel to connect to
connect = REMOTE_SERVER_IP:443

OPENVPN CONFIG NA laptopie:

client
dev tun
proto tcp
remote 127.0.0.1 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun

STUNNEL CONFIG NA SERWERZE:

sslVersion = all
options = NO_SSLv2
;chroot = /var/lib/stunnel4/
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Debugging stuff (may useful for troubleshooting)
 debug = 7
 output = /var/log/stunnel4/stunnel4.log
setuid = root
setgid = root
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
[openvpn]
accept = REMOTE_SERVER_IP:443
connect = REMOTE_SERVER_IP:11440
cert=/etc/stunnel/server.pem
key=/etc/stunnel/server.key

OPENVPN CONFIG na serwerze:

local REMOTE_SERVER_IP
port 11440
proto tcp

OpenVPN przez TLS

Twoja sieć VPN używa protokołu TCP jako protokołu transportowego. Instancja stunnel służy do enkapsulacji zawartości strumienia TCP w TLS / TCP. Otrzymasz ten stos protokołów:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Serwer stunnel stunnel Klient

Między instancjami stunnela masz ten stos protokołów na drucie:

[IP]
[OpenVPN]
[TLS]
[TCP (443)]
[IP]
[...]

Ponieważ TLS szyfruje ładunek, osoba atakująca może zobaczyć tylko:

[??? ]
[TLS]
[TCP (443)]
[IP]
[...]

Tak, jest to zwykły ruch TLS (może to być HTTP / TLS, SMTP / TLS, POP / TLS lub cokolwiek innego dla kogoś, kto patrzy na ruch, ale wygląda bardzo podobnie do HTTP / TLS, ponieważ używany jest port TCP 443). Możesz to sprawdzić za pomocą wireshark: rejestruj ruch między instancjami stunnel. W interfejsie wireshark (prawy przycisk na pakiecie strumienia) możesz poprosić wireshark o interpretację ruchu jako TLS: rozpozna go jako ruch TLS (zobaczysz różne komunikaty TLS, ale nie ładunek sesji TLS) .

Możesz użyć SNI w kliencie, aby wyglądać jak nowoczesna przeglądarka. Możesz także chcieć użyć ALPN, ale stunnel obecnie tego nie obsługuje.

OpenVPN z wbudowanym TLS

Dla porównania, jeśli używasz OpenVPN, będziesz mieć coś takiego:

[IP]
[OpenVPN]
[TCP]
[IP]
[...]

Który wygląda tak:

[??? ]
[OpenVPN]
[TCP]
[IP]
[...]

Wbudowana warstwa TLS nie hermetyzuje pakietów (IP, Ethernet), ale służy jedynie do konfigurowania sesji i uwierzytelniania:

[TLS]
[OpenVPN]
[TCP]
[IP]
[...]

W takim przypadku ruch nie wygląda jak zwykły ruch TLS, ale oczywiście jest OpenVPN. Jeśli zinterpretujesz ten ruch jako OpenVPN w wireshark, rozpoznasz wiadomości OpenVPN, a wewnątrz nich wiadomości TLS (ale nie ładunek).

Ostrzeżenie

Powinieneś zdawać sobie sprawę, że jeśli pasywny atakujący nie będzie w stanie stwierdzić, że twój zdalny serwer jest w rzeczywistości serwerem OpenVPN, aktywny atakujący będzie mógł się tego dowiedzieć: po prostu łącząc się z twoim serwerem przez TLS, będzie mógł aby potwierdzić, że to nie HTTP / serwer TLS. Próbując odczytać protokół OpenVPN, będzie w stanie wykryć, że twój serwer jest serwerem OpenVPN / TLS.

OpenVPN przez TLS z uwierzytelnianiem klienta

Jeśli martwisz się tym, możesz włączyć uwierzytelnianie klienta TLS: osoba atakująca nie będzie w stanie zainicjować działającej sesji TLS i nie będzie w stanie odgadnąć, który ładunek jest zamknięty w TLS.

* Ostrzeżenie: ** Nie mówię o wbudowanej obsłudze TLS w OpenVPN (patrz wyżej, aby uzyskać wyjaśnienie, dlaczego to ci nie pomoże).

Multipleksowane OpenVPN / TLS i HTTP / TLS

Innym rozwiązaniem jest obsługa zarówno HTTP, jak i OpenVPN podczas sesji TLS. sslh może być używany do automatycznego wykrywania ładunku protokołu i wysyłania go do zwykłego serwera HTTP / TCP lub do serwera OpenVPN / TCP. Serwer będzie wyglądał jak standardowy serwer HTTP / TLS, ale ktoś próbujący mówić OpenVPN / TLS na tym serwerze będzie w stanie wykryć, że tak naprawdę jest to również serwer OpenVPN / TLS.

        albo OpenVPN / TCP
          lub HTTP / TCP       
[1] .---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | Serwer HTTP |
   „---------” „------” | „-------------”
                           | .----------------.
                           „------> | Serwer OpenVPN |
                        OpenVPN / TCP '----------------'

[1] = Albo OpenVPN / TLS / TCP lub HTTP / TLS / TCP

OpenVPN przez HTTP CONNECT przez TLS

Innym rozwiązaniem jest użycie standardowego serwera HTTP / TLS i użycie HTTP CONNECT / TLS do połączenia z serwerem OpenVPN: będzie wyglądał jak standardowy serwer HTTP. Możesz nawet wymagać uwierzytelnienia klienta w celu autoryzacji żądania HTTP CONNECT (kałamarnica powinna być w stanie to zrobić).

OpenVPN ma opcję użycia proxy HTTP:

http-proxy proxy.example.com

Powinieneś być w stanie połączyć to z instancją stunnel łączącą się ze zdalnym HTTPS PROXY:

http-proxy 127.0.0.1 8443
remote vpn.example.com

Co zaimplementuje ten stos protokołów:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Serwer stunnel HTTPS PROXY Klient

Odpowiedź ysdx jest świetna i bardzo dobrze opisuje, jak ruch będzie wyglądał na przewodzie.

Nie wspomina się jednak, że analiza ruchu może znacznie przyczynić się do identyfikacji aplikacji.

Załóżmy, że twoje połączenie OpenVPN wygląda tak samo jak połączenie https na kablu, więc osoba atakująca nie może odczytać strumienia bajtów i wiedzieć, jakie to połączenie.

Typowe połączenie https nie będzie trwało zbyt długo. Może twoja przeglądarka utrzymuje otwarte połączenie z twoim serwerem poczty, nie wiem. Ogólnie jednak będzie wiele stosunkowo krótkich połączeń z wieloma różnorodnymi zdalnymi serwerami.

OTOH, połączenie OpenVPN może trwać kilka godzin lub dni i będzie wysyłać wiele danych tam iz powrotem na serwer openvpn.

Można złagodzić długotrwałe połączenie, okresowo przerywając i ponownie uruchamiając połączenie. Prawdopodobnie ma to wpływ na ruch aplikacji, ale może być wykonalne. Jednak dużo ruchu między tobą a serwerem openvpn będzie o wiele trudniejszy do kamuflażu.