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

КОНФІГ СТУННЕЛУ ПРО СЕРВЕР:

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 як транспортний протокол. Екземпляр оглушення використовується для інкапсуляції вмісту потоку TCP у TLS / TCP. Ви отримуєте цей стек протоколів:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Клієнт оглушення оглушення сервера

Між екземплярами оглушення у вас є цей стек протоколу на дроті:

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

Оскільки TLS шифрує свою корисну навантаження, зловмисник може бачити лише:

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

Так, так, це звичайний TLS-трафік (це може бути HTTP / TLS, SMTP / TLS, POP / TLS або що-небудь ще для того, хто дивиться на трафік, але він дуже схожий на HTTP / TLS як використовується порт TCP 443). Ви можете перевірити це за допомогою дроту: записуйте трафік між екземплярами оглушення. У інтерфейсі 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 у дротяній скарбці, ви розпізнаєте повідомлення 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 .-------------.
-> | оглушення | ----> | 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 (кальмари повинні це робити).

OpenVPN має можливість використовувати проксі-сервер HTTP:

http-proxy proxy.example.com

Ви повинні мати можливість комбінувати це з екземпляром оглушення, що підключається до віддаленого 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

Відповідь ysdx чудова, і вона дуже добре описує, як буде виглядати трафік.

Однак не можна сказати, що аналіз трафіку може пройти довгий шлях до визначення програм.

Припустимо, що ваше з'єднання OpenVPN виглядає так само, як https-з'єднання на дроті, тому зловмисник не може прочитати потік байтів і знати, що це за з'єднання.

Звичайне https-з'єднання не буде жити надто жахливо. Можливо, ваш браузер підтримує зв’язок відкритим для вашого поштового сервера, я не знаю. Взагалі-то, буде багато відносно коротких підключень до безлічі різноманітних віддалених серверів.

OTOH, підключення OpenVPN може жити годинами або днями і надсилатиме багато даних назад і назад на сервер openvpn.

Ви можете пом'якшити довготривалий зв’язок, періодично припиняючи та перезавантажуючи з'єднання. Це, мабуть, має наслідки для трафіку вашої програми, але може бути працездатним. Однак схема руху багато-багато трафіку між вами та сервером openvpn буде набагато складніше маскуватись.