interromper o tráfego VPN e garantir que ele se pareça com o tráfego SSL na porta 443

Estou tentando fazer com que meu tráfego de entrada e saída pareça o mais legítimo possível o tráfego SSL. Existe uma maneira de fazer o DPI do meu próprio tráfego para garantir que ele se pareça com o tráfego SSL e não com o tráfego OpenVPN? E com base na minha configuração, todo o tráfego usa a porta 443, que é a porta SSL?

Minha configuração é a seguinte:

STUNNEL no 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

OPENVPN CONFIG NO 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

CONFIGURAÇÃO DO STUNNEL NO SERVIDOR:

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 no servidor:

local REMOTE_SERVER_IP
port 11440
proto tcp

OpenVPN sobre TLS

Sua VPN está usando o TCP como um protocolo de transporte. A instância do stunnel é usada para encapsular o conteúdo do fluxo TCP no TLS / TCP. Você recebe esta pilha de protocolos:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Servidor stunnel stunnel Cliente

Entre as instâncias do stunnel, você tem esta pilha de protocolos no fio:

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

Como o TLS criptografa sua carga, um invasor pode ver apenas:

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

Portanto, sim, é um tráfego TLS simples (pode ser HTTP / TLS, SMTP / TLS, POP / TLS ou qualquer outra coisa para alguém olhando para o tráfego, mas se parece muito com HTTP / TLS quando a porta TCP 443 é usada). Você pode verificar isso usando o wireshark: registre o tráfego entre as instâncias do stunnel. Na interface do usuário do wireshark (botão direito em um pacote do fluxo), você pode pedir ao wireshark para interpretar o tráfego como TLS: ele o reconhecerá como tráfego TLS (você verá as diferentes mensagens TLS, mas não a carga útil da sessão TLS) .

Você pode usar o SNI no cliente para se parecer com o que um navegador moderno faria. Você também pode usar o ALPN , mas o stunnel atualmente não lida com isso.

OpenVPN com TLS embutido

Em comparação, se você estiver usando o OpenVPN, terá algo parecido com isto:

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

Que se parece com isso:

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

A camada TLS incorporada não encapsula os pacotes (IP, Ethernet), mas é usada apenas para configurar a sessão e autenticar:

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

Nesse caso, seu tráfego não se parece com um tráfego TLS simples, mas é obviamente OpenVPN. Se você interpretar esse tráfego como OpenVPN no wireshark, reconhecerá as mensagens OpenVPN e dentro delas as mensagens TLS (mas não a carga útil).

Atenção

Você deve estar ciente de que, se um invasor passivo não conseguir dizer que seu servidor remoto é de fato um servidor OpenVPN, um invasor ativo poderá descobrir isso: simplesmente conectando-se ao servidor por TLS, ele poderá para confirmar que é não um servidor HTTP / TLS. Ao tentar falar o protocolo OpenVPN, ele poderá detectar que seu servidor é um servidor OpenVPN / TLS.

OpenVPN sobre TLS com autenticação de cliente

Se você está preocupado com isso, pode ativar a autenticação do cliente TLS: um invasor não poderá iniciar uma sessão TLS em funcionamento e não poderá adivinhar qual carga útil está encapsulada no TLS.

* Aviso: ** Eu não estou falando sobre o suporte TLS interno no OpenVPN (veja acima para obter uma explicação sobre por que ele não ajudará).

OpenVPN / TLS e HTTP / TLS multiplexados

Outra solução é servir HTTP e OpenVPN durante a sessão TLS. sslh pode ser usado para detectar automaticamente a carga útil do protocolo e despachar para um servidor HTTP / TCP simples ou para o servidor OpenVPN / TCP. O servidor se parecerá com o servidor HTTP / TLS padrão, mas alguém tentando falar OpenVPN / TLS com este servidor poderá detectar que também é um servidor OpenVPN / TLS.

        ou OpenVPN / TCP
          ou HTTP / TCP       
[1] .---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | Servidor HTTP |
   '---------' '------' | '-------------'
                           | .----------------.
                           '------> | Servidor OpenVPN |
                        OpenVPN / TCP '----------------'

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

OpenVPN sobre HTTP CONNECT sobre TLS

Outra solução é usar um servidor HTTP / TLS padrão e usar o HTTP CONNECT / TLS para conectar-se ao servidor OpenVPN: ele se parecerá com um servidor HTTP padrão. Você pode até exigir autenticação do cliente para autorizar a solicitação HTTP CONNECT (o squid deve ser capaz de fazer isso).

O OpenVPN tem uma opção para usar um Proxy HTTP:

http-proxy proxy.example.com

Você deve poder combinar isso com uma instância de stunnel conectando-se a um HTTPS PROXY remoto:

http-proxy 127.0.0.1 8443
remote vpn.example.com

O que implementaria essa pilha de protocolos:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Cliente de stunnel HTTPS PROXY do servidor

A resposta do ysdx é ótima e descreve muito bem como o tráfego ficará no arame.

Não mencionado, no entanto, é que a análise de tráfego pode ajudar bastante na identificação de aplicativos.

Vamos supor que sua conexão OpenVPN se pareça com uma conexão https na conexão, para que um invasor não possa ler o fluxo de bytes e saber que tipo de conexão é.

Uma conexão https típica não dura muito tempo. Talvez o seu navegador mantenha uma conexão aberta com o servidor de correio, não sei. Em geral, porém, haverá muitas conexões relativamente curtas com muitos servidores remotos diversos.

OTOH, a conexão OpenVPN pode permanecer por horas ou dias e enviará muitos dados para o servidor openvpn.

Você pode atenuar a conexão de longa duração periodicamente eliminando e reiniciando a conexão. Presumivelmente, isso tem implicações no tráfego do aplicativo, mas pode ser viável. O padrão de muito e muito tráfego entre você e o servidor openvpn, no entanto, será muito mais difícil de camuflar.