stunnel vpn 트래픽 및 포트 443의 SSL 트래픽처럼 보임

나가고 들어오는 트래픽을 가능한 한 SSL 트래픽에 최대한 합법적으로 보이도록 만들려고합니다. OpenVPN 트래픽이 아닌 SSL 트래픽처럼 보이도록 DPI를 설정하는 방법이 있습니까? 그리고 내 구성 설정에 따라 모든 트래픽이 SSL 포트 인 포트 443을 사용합니까?

내 구성은 다음과 같습니다.

노트북의 STUNNEL :

[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 ON 노트북 :

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 구성 :

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 구성 :

local REMOTE_SERVER_IP
port 11440
proto tcp

TLS를 통한 OpenVPN

VPN이 TCP를 전송 프로토콜로 사용하고 있습니다. stunnel 인스턴스는 TCP 스트림의 내용을 TLS / TCP로 캡슐화하는 데 사용됩니다. 이 프로토콜 스택을 얻습니다.

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 서버 스터 넬 스터 넬 클라이언트

stunnel 인스턴스 사이에는이 프로토콜 스택이 연결되어 있습니다.

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

TLS가 페이로드를 암호화하면 공격자는 다음 만 볼 수 있습니다.

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

예, 일반 TLS 트래픽입니다 (HTTP / TLS, SMTP / TLS, POP / TLS 또는 트래픽을보고있는 사람을위한 다른 것이 될 수 있지만 TCP 포트 443이 사용됨에 따라 HTTP / TLS와 매우 유사 함). wireshark를 사용하여이를 확인할 수 있습니다. stunnel 인스턴스 간의 트래픽을 기록하십시오. wireshark UI (스트림 패킷의 오른쪽 버튼)에서 wireshark에게 트래픽을 TLS로 해석하도록 요청할 수 있습니다. 트래픽을 TLS 트래픽으로 인식합니다 (TLS 세션의 페이로드가 아닌 다른 TLS 메시지를 볼 수 있음) .

최신 브라우저가하는 것처럼 보이기 위해 클라이언트에서 SNI 를 사용할 수 있습니다 . ALPN 도 사용할 수 있지만 stunnel은 현재이를 처리하지 않습니다.

TLS가 내장 된 OpenVPN

이에 비해 OpenVPN을 사용하는 경우 다음과 같은 결과가 나타납니다.

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

이것은 다음과 같습니다

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

내장 TLS 계층은 (IP, 이더넷) 패킷을 캡슐화하지 않고 세션 설정 및 인증에만 사용됩니다.

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

이 경우, 트래픽은 않습니다 하지 일반 TLS 트래픽처럼 보이지만 분명히 OpenVPN을합니다. wireshark에서이 트래픽을 OpenVPN으로 해석하면 OpenVPN 메시지와 그 내부의 TLS 메시지 (페이로드는 아님)를 인식하게됩니다.

경고

수동 공격자가 원격 서버가 실제로 OpenVPN 서버임을 알 수 없으면 활성 공격자가이를 확인할 수 있습니다. 간단히 TLS를 통해 서버에 연결하면 HTTP / TLS 서버 가 아닌지 확인하십시오 . OpenVPN 프로토콜을 사용하려고 시도하면 서버가 OpenVPN / TLS 서버임을 감지 할 수 있습니다.

클라이언트 인증을 통한 TLS를 통한 OpenVPN

TLS 클라이언트 인증을 활성화 할 수 있다는 것에 대해 걱정하고 있습니다. 공격자는 작업중인 TLS 세션을 시작할 수 없으며 TLS를 통해 캡슐화 된 페이로드를 추측 할 수 없습니다.

* 경고 : ** OpenVPN의 내장 TLS 지원에 대해서는 이야기하고 있지 않습니다 (왜 도움이되지 않는지에 대한 설명은 위를 참조하십시오).

멀티 플렉스 OpenVPN / TLS 및 HTTP / TLS

또 다른 솔루션은 TLS 세션을 통해 HTTP와 OpenVPN을 모두 제공하는 것입니다. sslh 는 프로토콜의 페이로드를 자동으로 감지하여 일반 HTTP / TCP 서버 또는 OpenVPN / TCP 서버로 디스패치하는 데 사용할 수 있습니다. 서버는 표준 HTTP / TLS 서버처럼 보이지만이 서버와 OpenVPN / TLS를 사용하려는 사람은 실제로 OpenVPN / TLS 서버임을 감지 할 수 있습니다.

        OpenVPN / TCP
          또는 HTTP / TCP       
[1].---------. .------. HTTP / TCP .-------------.
-> | 기절 | ----> | sslh | -------> | HTTP 서버 |
   '---------' '------'| '-------------'
                           | .----------------.
                           '------> | OpenVPN 서버 |
                        OpenVPN / TCP '----------------'

[1] = OpenVPN / TLS / TCP 또는 HTTP / TLS / TCP

TLS를 통한 HTTP 연결을 통한 OpenVPN

다른 해결책은 표준 HTTP / TLS 서버를 사용하고 HTTP CONNECT / TLS를 사용하여 OpenVPN 서버에 연결하는 것입니다. 표준 HTTP 서버처럼 보입니다. HTTP CONNECT 요청을 승인하기 위해 클라이언트 인증이 필요할 수도 있습니다 (오징어가이를 수행 할 수 있어야 함).

OpenVPN에는 HTTP 프록시를 사용하는 옵션이 있습니다.

http-proxy proxy.example.com

이것을 원격 HTTPS PROXY에 연결하는 stunnel 인스턴스와 결합 할 수 있어야합니다.

http-proxy 127.0.0.1 8443
remote vpn.example.com

이 프로토콜 스택을 구현하는 것은 다음과 같습니다.

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 서버 HTTPS PROXY 스터 넬 클라이언트

ysdx의 답변은 훌륭하며 트래픽이 어떻게 와이어에서 보일지 잘 설명합니다.

그러나 언급되지 않은 것은 트래픽 분석이 애플리케이션을 식별하는 데 먼 길을 갈 수 있다는 것입니다.

OpenVPN 연결이 유선상에서 https 연결처럼 보인다고 가정하면 공격자가 바이트 스트림을 읽고 어떤 종류의 연결인지 알 수 없습니다.

일반적인 https 연결은 너무 오래 지속되지 않습니다. 브라우저가 메일 서버와의 연결을 유지하고있을 수도 있습니다. 그러나 일반적으로 다양한 원격 서버에 대한 연결이 비교적 짧습니다.

OTOH, OpenVPN 연결은 몇 시간 또는 며칠 동안 지속될 수 있으며 많은 데이터를 openvpn 서버로주고받을 것입니다.

연결을 주기적으로 삭제하고 다시 시작하여 오래 지속되는 연결을 완화 할 수 있습니다. 이것은 아마도 응용 프로그램 트래픽에 영향을 주지만 작동 할 수 있습니다. 그러나 당신과 openvpn 서버 사이를 이동하는 많은 트래픽 패턴은 위장하기가 훨씬 더 어려울 것입니다.