Soluzione 1:
OpenVPN su TLS
La tua VPN utilizza 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 stunnel hai questo stack di protocollo sul cavo:
[IP ] [OpenVPN ] [TLS ] [TCP(443)] [IP ] [... ]
Poiché il TLS crittografa il suo carico utile, un utente malintenzionato può vedere solo:
[??? ] [TLS ] [TCP(443)] [IP ] [... ]
Quindi sì, è un 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 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 utilizzare anche ALPN, ma attualmente stunnel non lo gestisce.
OpenVPN con TLS integrato
In confronto, se utilizzi OpenVPN, avrai qualcosa del genere:
[IP ] [OpenVPN ] [TCP ] [IP ] [... ]
Che assomiglia a questo:
[??? ] [OpenVPN ] [TCP ] [IP ] [... ]
Il livello TLS integrato non incapsula i pacchetti (IP, Ethernet) ma viene utilizzato solo per configurare la sessione e autenticare:
[TLS ] [OpenVPN ] [TCP ] [IP ] [... ]
In questo caso, il tuo traffico non sembra un semplice traffico TLS ma è ovviamente OpenVPN. Se interpreti questo traffico come OpenVPN in wireshark, riconoscerai i messaggi OpenVPN e al loro interno i messaggi TLS (ma non il payload).
Avviso
Dovresti essere consapevole che se un utente malintenzionato passivo non sarà in grado di dire che il tuo server remoto è in realtà un server OpenVPN, un utente malintenzionato attivo sarà in grado di scoprirlo:semplicemente connettendosi al tuo server tramite TLS, sarà in grado per confermare che non lo è un server HTTP/TLS. Provando a pronunciare 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 del 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.
*Attenzione:** non sto parlando del supporto TLS integrato in OpenVPN (vedi sopra per una spiegazione sul perché non ti aiuterà).
OpenVPN/TLS multiplexato e HTTP/TLS
Un'altra soluzione è servire sia HTTP che OpenVPN sulla sessione TLS. sslh può essere utilizzato per rilevare automaticamente il carico utile del protocollo e inviarlo a un semplice server HTTP/TCP o al tuo server OpenVPN/TCP. Il server avrà l'aspetto di un server HTTP/TLS standard, ma qualcuno che tenta di parlare OpenVPN/TLS con questo server sarà in grado di rilevare che in realtà si tratta anche di un server OpenVPN/TLS.
either OpenVPN/TCP
or HTTP/TCP
[1].---------. .------.HTTP/TCP.-------------.
-->| stunnel |---->| sslh |------->| HTTP server |
'---------' '------'| '-------------'
| .----------------.
'------>| OpenVPN server |
OpenVPN/TCP'----------------'
[1]= Either OpenVPN/TLS/TCP or 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 (squid dovrebbe essere in grado di farlo).
OpenVPN ha un'opzione per utilizzare un proxy HTTP:
http-proxy proxy.example.com
Dovresti essere in grado di combinare questo con un'istanza stunnel che si connette a un PROXY HTTPS 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 stunnel Client
Soluzione 2:
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 proprio a una connessione https in transito, quindi un utente malintenzionato non può leggere il flusso di byte e sapere che tipo di connessione è.
Una tipica connessione https non vivrà 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 durare ore o giorni e invierà molti dati avanti e indietro al server openvpn.
È possibile mitigare la connessione di lunga durata interrompendo e riavviando periodicamente la connessione. Ciò ha presumibilmente implicazioni per il traffico dell'applicazione, ma potrebbe essere fattibile. Lo schema di un sacco di traffico tra te e il server openvpn, tuttavia, sarà molto più difficile da camuffare.