stunnel traffico vpn e assicurarsi che assomigli al traffico SSL sulla porta 443

Sto cercando di rendere il mio traffico in uscita e in entrata il più vicino possibile al traffico SSL. Esiste un modo per DPI il mio traffico per garantire che assomigli al traffico SSL e non al traffico OpenVPN? E in base alla mia configurazione di configurazione, tutto il traffico utilizza la porta 443 che è la porta SSL?

La mia configurazione è la seguente:

STUNNEL su laptop:

[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

CONFIGURAZIONE OPENVPN SU laptop:

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

CONFIGURAZIONE STUNNEL SUL SERVER:

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 sul server:

local REMOTE_SERVER_IP
port 11440
proto tcp

OpenVPN su TLS

La tua VPN sta usando TCP come protocollo di trasporto. L'istanza stunnel viene utilizzata per incapsulare il contenuto del flusso TCP in TLS / TCP. Ottieni questo stack di protocollo:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Server stunnel stunnel Client

Tra le istanze di stunnel hai questo stack di protocollo sul filo:

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

Poiché TLS crittografa il suo payload, un utente malintenzionato può vedere solo:

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

Quindi sì, è semplice traffico TLS (potrebbe essere HTTP / TLS, SMTP / TLS, POP / TLS o qualsiasi altra cosa per qualcuno che guarda il traffico ma assomiglia molto a HTTP / TLS poiché viene utilizzata la porta TCP 443). Puoi verificarlo usando WireShark: registra il traffico tra le istanze di stunnel. Nell'interfaccia utente di WireShark (pulsante destro su un pacchetto dello stream), puoi chiedere a WireShark di interpretare il traffico come TLS: lo riconoscerà come traffico TLS (vedrai i diversi messaggi TLS ma non il payload della sessione TLS) .

Potresti voler utilizzare SNI nel client per assomigliare a quello che farebbe un browser moderno. Potresti voler usare anche ALPN ma lo stunnel attualmente non lo gestisce.

OpenVPN con TLS integrato

In confronto, se stai usando OpenVPN, avrai qualcosa del genere:

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

Che assomiglia a questo:

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

Il livello TLS incorporato non incapsula i pacchetti (IP, Ethernet) ma viene utilizzato solo per impostare la sessione e autenticare:

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

In questo caso, il tuo traffico non sembra un semplice traffico TLS ma è ovviamente OpenVPN. Se interpretate questo traffico come OpenVPN in WireShark, riconoscerete i messaggi OpenVPN e al loro interno i messaggi TLS (ma non il payload).

avvertimento

Dovresti essere consapevole che se un attaccante passivo non sarà in grado di dire che il tuo server remoto è in realtà un server OpenVPN, un attaccante attivo sarà in grado di scoprirlo: semplicemente connettendosi al tuo server su TLS, sarà in grado per confermare che si tratta non è un server HTTP / TLS. Provando a parlare il protocollo OpenVPN, sarà in grado di rilevare che il tuo server è un server OpenVPN / TLS.

OpenVPN su TLS con autenticazione client

Se sei preoccupato per questo, potresti abilitare l'autenticazione client TLS: un utente malintenzionato non sarà in grado di avviare una sessione TLS funzionante e non sarà in grado di indovinare quale payload è incapsulato su TLS.

* Avvertenza: ** Non sto parlando del supporto TLS integrato in OpenVPN (vedi sopra per una spiegazione del perché non ti aiuterà).

OpenVPN / TLS multiplo e HTTP / TLS

Un'altra soluzione è quella di servire sia HTTP che OpenVPN sulla sessione TLS. sslh può essere utilizzato per rilevare automaticamente il payload del protocollo e inviarlo a un semplice server HTTP / TCP o al server OpenVPN / TCP. Il server sembrerà un server HTTP / TLS standard ma qualcuno che cerca di parlare OpenVPN / TLS con questo server sarà in grado di rilevare che in realtà è anche un server OpenVPN / TLS.

        OpenVPN / TCP
          o HTTP / TCP       
[1] .---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | Server HTTP |
   '---------' '------' | '-------------'
                           | .----------------.
                           '------> | Server OpenVPN |
                        OpenVPN / TCP '----------------'

[1] = OpenVPN / TLS / TCP o HTTP / TLS / TCP

OpenVPN su HTTP CONNECT su TLS

Un'altra soluzione è utilizzare un server HTTP / TLS standard e utilizzare HTTP CONNECT / TLS per connettersi al server OpenVPN: sembrerà un server HTTP standard. Puoi anche richiedere l'autenticazione del client per autorizzare la richiesta HTTP CONNECT (calamari dovrebbero essere in grado di farlo).

OpenVPN ha un'opzione per usare un proxy HTTP:

http-proxy proxy.example.com

Dovresti essere in grado di combinare questo con un'istanza stunnel che si connette a un HTTPS PROXY remoto:

http-proxy 127.0.0.1 8443
remote vpn.example.com

Che implementerebbe questo stack di protocollo:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Server HTTPS PROXY client stunnel

La risposta di ysdx è ottima e descrive molto bene come apparirà il traffico sul filo.

Non menzionato, tuttavia, è che l'analisi del traffico può fare molto per identificare le applicazioni.

Supponiamo che la tua connessione OpenVPN assomigli ad una connessione https sul filo, quindi un utente malintenzionato non può leggere il flusso di byte e sapere che tipo di connessione è.

Una tipica connessione https non durerà troppo a lungo. Forse il tuo browser mantiene una connessione aperta al tuo server di posta, non lo so. In generale, tuttavia, ci saranno molte connessioni relativamente brevi a molti server remoti diversi.

OTOH, la connessione OpenVPN potrebbe vivere per ore o giorni e invierà molti dati avanti e indietro al server openvpn.

È possibile mitigare la connessione di lunga durata eliminando e riavviando periodicamente la connessione. Ciò presumibilmente ha implicazioni per il traffico dell'applicazione, ma potrebbe essere praticabile. Lo schema di un sacco di traffico tra te e il server openvpn, tuttavia, sarà molto più difficile da mimetizzare.