stunnel vpn трафик и убедитесь, что он выглядит как трафик SSL на порту 443

Я пытаюсь сделать мой исходящий и входящий трафик максимально приближенным к SSL-трафику. Есть ли способ добавить DPI в мой собственный трафик, чтобы он выглядел как трафик SSL, а не как трафик OpenVPN? И на основании моих настроек конфигурации весь трафик использует порт 443, который является портом SSL?

Моя конфигурация выглядит следующим образом:

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 CONFIG ON 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 на сервере:

local REMOTE_SERVER_IP
port 11440
proto tcp

OpenVPN через TLS

Ваш VPN использует TCP в качестве транспортного протокола. Экземпляр stunnel используется для инкапсуляции содержимого потока TCP в TLS / TCP. Вы получаете этот стек протоколов:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Сервер Stunnel Stunnel Клиент

Между экземплярами Stunnel у вас есть стек протоколов на проводе:

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

Поскольку TLS шифрует свою полезную нагрузку, злоумышленник может видеть только:

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

Так что да, это обычный трафик TLS (это может быть HTTP / TLS, SMTP / TLS, POP / TLS или что-то еще для того, кто смотрит на трафик, но он очень похож на HTTP / TLS, когда используется TCP-порт 443). Вы можете проверить это с помощью wireshark: запишите трафик между экземплярами Stunnel. В пользовательском интерфейсе wireshark (правая кнопка на пакете потока) вы можете попросить wireshark интерпретировать трафик как TLS: он распознает его как трафик TLS (вы увидите разные сообщения TLS, но не полезную нагрузку сеанса TLS) ,

Возможно, вы захотите использовать SNI в клиенте, чтобы выглядеть так, как поступил бы современный браузер. Возможно, вы захотите использовать ALPN, но в настоящее время stunnel не справляется с этим.

OpenVPN со встроенным TLS

Для сравнения, если вы используете OpenVPN, у вас будет что-то вроде этого:

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

Который выглядит так:

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

Встроенный уровень TLS не инкапсулирует пакеты (IP, Ethernet), а используется только для настройки сеанса и аутентификации:

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

В этом случае ваш трафик не выглядит как обычный трафик TLS, но, очевидно, является OpenVPN. Если вы интерпретируете этот трафик как OpenVPN в Wireshark, вы узнаете сообщения OpenVPN и внутри них сообщения TLS (но не полезную нагрузку).

Предупреждение

Вы должны знать, что если пассивный злоумышленник не сможет сказать, что ваш удаленный сервер на самом деле является сервером OpenVPN, активный злоумышленник сможет это выяснить: просто подключившись к вашему серверу по TLS, он сможет чтобы подтвердить, что это не сервер HTTP / TLS. Пытаясь говорить по протоколу OpenVPN, он сможет обнаружить, что ваш сервер является сервером OpenVPN / TLS.

OpenVPN через TLS с аутентификацией клиента

Если вас это беспокоит, вы можете включить проверку подлинности клиента TLS: злоумышленник не сможет инициировать рабочий сеанс TLS и не сможет угадать, какая полезная нагрузка инкапсулирована в TLS.

* Предупреждение: ** Я не говорю о встроенной поддержке TLS в OpenVPN (см. Выше объяснение того, почему это не поможет).

Мультиплексированный OpenVPN / TLS и HTTP / TLS

Другое решение состоит в том, чтобы обслуживать HTTP и OpenVPN через сеанс TLS. sslh может использоваться для автоматического определения полезной нагрузки протокола и отправки на обычный сервер HTTP / TCP или на сервер OpenVPN / TCP. Сервер будет выглядеть как стандартный HTTP / TLS-сервер, но кто-то, пытающийся говорить на OpenVPN / TLS с этим сервером, сможет обнаружить, что он на самом деле также является сервером OpenVPN / TLS.

        либо OpenVPN / TCP
          или HTTP / TCP       
[1] .---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | HTTP сервер |
   '---------' '------' | '-------------'
                           | .----------------.
                           «------> | OpenVPN сервер |
                        OpenVPN / TCP '----------------'

[1] = либо OpenVPN / TLS / TCP, либо HTTP / TLS / TCP

OpenVPN через HTTP CONNECT через TLS

Другое решение состоит в том, чтобы использовать стандартный сервер HTTP / TLS и использовать HTTP CONNECT / TLS для подключения к серверу OpenVPN: он будет выглядеть как стандартный сервер HTTP. Вы даже можете потребовать аутентификацию клиента, чтобы авторизовать HTTP-запрос CONNECT (squid должен это сделать).

OpenVPN имеет возможность использовать HTTP-прокси:

http-proxy proxy.example.com

Вы должны быть в состоянии объединить это с экземпляром Stunnel, подключающимся к удаленному HTTPS PROXY:

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 stunnel Клиент

Ответ ysdx великолепен и очень хорошо описывает, как будет выглядеть трафик в сети.

Однако не упоминается, что анализ трафика может иметь большое значение для идентификации приложений.

Предположим, что ваше OpenVPN-соединение выглядит как соединение https на проводе, поэтому злоумышленник не может прочитать поток байтов и узнать, что это за соединение.

Типичное соединение https не будет жить слишком долго. Может быть, ваш браузер поддерживает соединение с почтовым сервером, я не знаю. В общем, будет много относительно коротких подключений ко многим разнородным удаленным серверам.

OTOH, соединение OpenVPN может существовать часами или днями и отправлять много данных туда и обратно на сервер openvpn.

Вы могли бы смягчить долгоживущее соединение, периодически сбрасывая и перезапуская соединение. Предположительно это имеет значение для трафика вашего приложения, но может быть работоспособным. Тем не менее, структура большого и большого трафика, проходящего между вами и сервером openvpn, будет намного сложнее замаскировать.