_ qstnhdr stunnel vpn tráfego e garantir que se parece com o tráfego SSL na porta 443 ____ qstntxt _

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

Minha configuração é a seguinte:

STUNNEL no laptop:
%pre%
OPENVPN CONFIG NO laptop:
%pre%
CONFIGURAÇÃO DO STUNNEL NO SERVIDOR:
%pre%
OPENVPN CONFIG no servidor:
%pre%
____ azszpr681497 _

OpenVPN por TLS

Sua VPN está usando o TCP como um protocolo de transporte. A instância stunnel é usada para encapsular o conteúdo do fluxo TCP em TLS / TCP. Você obtém esta pilha de protocolos:
%pre%
Entre as instâncias do stunnel, você tem essa pilha de protocolos no fio:
%pre%
Como o TLS criptografa sua carga útil, um invasor só consegue ver:
%pre%
Então, sim, é um tráfego TLS simples (pode ser HTTP / TLS, SMTP / TLS, POP / TLS ou qualquer outra coisa para alguém que esteja olhando para o tráfego, mas se parece muito com HTTP / TLS, pois a porta TCP 443 é usava). Você pode verificar isso usando wireshark: registre o tráfego entre as instâncias do stunnel. Na interface do usuário wireshark (botão direito em um pacote do fluxo), você pode solicitar 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 querer usar SNI no cliente para parecer com o que um navegador moderno faria Faz. Você pode querer usar o ALPN , mas stunnel atualmente não lida com isso.

OpenVPN com TLS incorporado

Em comparação, se você estiver usando o OpenVPN, você terá algo assim:
%pre%
Que se parece com isso:
%pre%
A camada TLS incorporada não encapsula os pacotes (IP, Ethernet), mas é usada apenas para configurar a sessão e autenticar:
%pre%
Nesse caso, o tráfego não parece um tráfego TLS simples, mas é obviamente o OpenVPN. Se você interpretar esse tráfego como OpenVPN no wireshark, você reconhecerá as mensagens OpenVPN e dentro delas as mensagens TLS (mas não a carga útil).

Aviso

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

OpenVPN sobre TLS com autenticação de cliente

Se você está preocupado com isso, é possível ativar a autenticação de cliente TLS: um invasor não poderá iniciar uma sessão de TLS em funcionamento e não poderá adivinhar qual carga útil será encapsulada por TLS.

* Aviso: ** Eu não estou falando sobre o suporte ao TLS embutido no OpenVPN (veja acima para explicação sobre por que ele não irá ajudá-lo).

OpenVPN / TLS e HTTP / TLS multiplexados

Outra solução é servir HTTP e OpenVPN na sessão TLS. sslh pode ser usado para detectar automaticamente a carga útil do protocolo e despachar para um servidor HTTP / TCP simples ou Servidor OpenVPN / TCP. O servidor será parecido com o servidor HTTP / TLS padrão, mas alguém que tente falar OpenVPN / TLS com esse servidor será capaz de detectar que ele também é um servidor OpenVPN / TLS.
%pre%
OpenVPN sobre HTTP CONNECT over TLS

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

O OpenVPN tem a opção de usar um proxy HTTP:
%pre%
Você deve conseguir combinar isso com uma instância stunnel conectando-se a um HTTPS PROXY remoto:
%pre%
Qual implementaria essa pilha de protocolos:
%pre%
____ azszpr681636 _

A resposta do ysdx é ótima e descreve muito bem como o tráfego ficará no fio.
Não mencionado, no entanto, é que a análise de tráfego pode percorrer um longo caminho para a identificação de aplicativos.

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

Uma conexão típica de https não vai durar muito tempo. Talvez o seu navegador mantenha uma conexão aberta ao seu servidor de e-mail, eu não sei. Em geral, no entanto, haverá muitas conexões relativamente curtas para diversos servidores remotos.

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

Você pode atenuar a conexão de longa duração periodicamente descartando e reiniciando a conexão. Isso supostamente tem implicações para o tráfego de aplicativos, mas pode ser viável. O padrão de lotes e lotes de tráfego entre você e o servidor openvpn, no entanto, será muito mais difícil de camuflar.

___

Question

_ qstnhdr stunnel vpn tráfego e garantir que se parece com o tráfego SSL na porta 443 ____ qstntxt _

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

Minha configuração é a seguinte:

STUNNEL no laptop:
%pre%
OPENVPN CONFIG NO laptop:
%pre%
CONFIGURAÇÃO DO STUNNEL NO SERVIDOR:
%pre%
OPENVPN CONFIG no servidor:
%pre%
____ azszpr681497 _

OpenVPN por TLS

Sua VPN está usando o TCP como um protocolo de transporte. A instância stunnel é usada para encapsular o conteúdo do fluxo TCP em TLS / TCP. Você obtém esta pilha de protocolos:
%pre%
Entre as instâncias do stunnel, você tem essa pilha de protocolos no fio:
%pre%
Como o TLS criptografa sua carga útil, um invasor só consegue ver:
%pre%
Então, sim, é um tráfego TLS simples (pode ser HTTP / TLS, SMTP / TLS, POP / TLS ou qualquer outra coisa para alguém que esteja olhando para o tráfego, mas se parece muito com HTTP / TLS, pois a porta TCP 443 é usava). Você pode verificar isso usando wireshark: registre o tráfego entre as instâncias do stunnel. Na interface do usuário wireshark (botão direito em um pacote do fluxo), você pode solicitar 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 querer usar SNI no cliente para parecer com o que um navegador moderno faria Faz. Você pode querer usar o ALPN , mas stunnel atualmente não lida com isso.

OpenVPN com TLS incorporado

Em comparação, se você estiver usando o OpenVPN, você terá algo assim:
%pre%
Que se parece com isso:
%pre%
A camada TLS incorporada não encapsula os pacotes (IP, Ethernet), mas é usada apenas para configurar a sessão e autenticar:
%pre%
Nesse caso, o tráfego não parece um tráfego TLS simples, mas é obviamente o OpenVPN. Se você interpretar esse tráfego como OpenVPN no wireshark, você reconhecerá as mensagens OpenVPN e dentro delas as mensagens TLS (mas não a carga útil).

Aviso

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

OpenVPN sobre TLS com autenticação de cliente

Se você está preocupado com isso, é possível ativar a autenticação de cliente TLS: um invasor não poderá iniciar uma sessão de TLS em funcionamento e não poderá adivinhar qual carga útil será encapsulada por TLS.

* Aviso: ** Eu não estou falando sobre o suporte ao TLS embutido no OpenVPN (veja acima para explicação sobre por que ele não irá ajudá-lo).

OpenVPN / TLS e HTTP / TLS multiplexados

Outra solução é servir HTTP e OpenVPN na sessão TLS. sslh pode ser usado para detectar automaticamente a carga útil do protocolo e despachar para um servidor HTTP / TCP simples ou Servidor OpenVPN / TCP. O servidor será parecido com o servidor HTTP / TLS padrão, mas alguém que tente falar OpenVPN / TLS com esse servidor será capaz de detectar que ele também é um servidor OpenVPN / TLS.
%pre%
OpenVPN sobre HTTP CONNECT over TLS

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

O OpenVPN tem a opção de usar um proxy HTTP:
%pre%
Você deve conseguir combinar isso com uma instância stunnel conectando-se a um HTTPS PROXY remoto:
%pre%
Qual implementaria essa pilha de protocolos:
%pre%
____ azszpr681636 _

A resposta do ysdx é ótima e descreve muito bem como o tráfego ficará no fio.
Não mencionado, no entanto, é que a análise de tráfego pode percorrer um longo caminho para a identificação de aplicativos.

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

Uma conexão típica de https não vai durar muito tempo. Talvez o seu navegador mantenha uma conexão aberta ao seu servidor de e-mail, eu não sei. Em geral, no entanto, haverá muitas conexões relativamente curtas para diversos servidores remotos.

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

Você pode atenuar a conexão de longa duração periodicamente descartando e reiniciando a conexão. Isso supostamente tem implicações para o tráfego de aplicativos, mas pode ser viável. O padrão de lotes e lotes de tráfego entre você e o servidor openvpn, no entanto, será muito mais difícil de camuflar.

___

#1 resposta do (19 votos)
#2 resposta do (4 votos)

10

Estou tentando fazer com que meu tráfego de entrada e saída pareça o mais legítimo possível perto do tráfego SSL. Existe uma maneira de proteger meu próprio tráfego para garantir que ele se pareça com o tráfego SSL e não com o tráfego do OpenVPN? E com base na configuração da 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

vpn openvpn linux stunnel

por Jason 14.03.2015 / 20:49

2 respostas

4

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

Não mencionado, no entanto, é que a análise de tráfego pode percorrer um longo caminho para a identificação de aplicativos.

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

Uma conexão típica de https não vai durar muito tempo. Talvez o seu navegador mantenha uma conexão aberta ao seu servidor de e-mail, eu não sei. Em geral, no entanto, haverá muitas conexões relativamente curtas para diversos servidores remotos.

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

Você pode atenuar a conexão de longa duração periodicamente descartando e reiniciando a conexão. Isso supostamente tem implicações para o tráfego de aplicativos, mas pode ser viável. O padrão de lotes e lotes de tráfego entre você e o servidor openvpn, no entanto, será muito mais difícil de camuflar.

por 09.04.2015 / 20:46

Tags vpn openvpn linux stunnel

alias do usuário unix Como posso descobrir por que meu php5-fpm falhou ao iniciar?

score 19 · Accepted Answer

OpenVPN por TLS

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

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

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

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

Como o TLS criptografa sua carga útil, um invasor só consegue ver:

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

Então, sim, é um tráfego TLS simples (pode ser HTTP / TLS, SMTP / TLS, POP / TLS ou qualquer outra coisa para alguém que esteja olhando para o tráfego, mas se parece muito com HTTP / TLS, pois a porta TCP 443 é usava). Você pode verificar isso usando wireshark: registre o tráfego entre as instâncias do stunnel. Na interface do usuário wireshark (botão direito em um pacote do fluxo), você pode solicitar 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 querer usar SNI no cliente para parecer com o que um navegador moderno faria Faz. Você pode querer usar o ALPN , mas stunnel atualmente não lida com isso.

OpenVPN com TLS incorporado

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

[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, o tráfego não parece um tráfego TLS simples, mas é obviamente o OpenVPN. Se você interpretar esse tráfego como OpenVPN no wireshark, você reconhecerá as mensagens OpenVPN e dentro delas as mensagens TLS (mas não a carga útil).

Aviso

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

OpenVPN sobre TLS com autenticação de cliente

Se você está preocupado com isso, é possível ativar a autenticação de cliente TLS: um invasor não poderá iniciar uma sessão de TLS em funcionamento e não poderá adivinhar qual carga útil será encapsulada por TLS.

* Aviso: ** Eu não estou falando sobre o suporte ao TLS embutido no OpenVPN (veja acima para explicação sobre por que ele não irá ajudá-lo).

OpenVPN / TLS e HTTP / TLS multiplexados

Outra solução é servir HTTP e OpenVPN na sessão TLS. sslh pode ser usado para detectar automaticamente a carga útil do protocolo e despachar para um servidor HTTP / TCP simples ou Servidor OpenVPN / TCP. O servidor será parecido com o servidor HTTP / TLS padrão, mas alguém que tente falar OpenVPN / TLS com esse servidor será capaz de detectar que ele também é um servidor 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 sobre HTTP CONNECT over TLS

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

O OpenVPN tem a opção de usar um proxy HTTP:

http-proxy proxy.example.com

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

http-proxy 127.0.0.1 8443
remote vpn.example.com

Qual implementaria essa pilha de protocolos:

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