Налаштування прозорого SSL-проксі

У мене встановлено вікно Linux з двома мережевими картами для огляду трафіку, що проходить через порт 80. Одна карта використовується для виходу в Інтернет, інша підключена до мережевого комутатора. Сенс полягає в тому, щоб мати можливість перевіряти весь трафік HTTP та HTTPS на пристроях, підключених до цього комутатора для налагодження.

Я написав такі правила для iptables:

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

192.168.2.1:1337 у мене з’явився прозорий http-проксі, який використовує Чарльза ( http://www.charlesproxy.com/ ) для запису.

Для порту 80 все добре, але коли я додаю подібні правила для порту 443 (SSL), що вказує на порт 1337, я отримую помилку щодо недійсного повідомлення через Чарльза.

Раніше я використовував SSL-проксі на тому ж комп’ютері разом із Чарльзом ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ), але з певних причин не мав успіху робити це прозоро. Деякі ресурси, за якими я google, кажуть, що це неможливо - я готовий прийняти це як відповідь, якщо хтось може пояснити, чому.

Як зауваження, я маю повний доступ до описаного набору, включаючи всіх клієнтів, підключених до підмережі - тому я можу прийняти Чарльз, який підписав самопідпис. Рішення не повинно бути специфічним для Чарльза, оскільки теоретично будь-який прозорий проксі може робити.

Спасибі!

Редагувати: трохи погравши з ним, я зміг змусити його працювати для конкретного хоста. Коли я змінюю свої iptables на наступні (і відкриваю 1338 у графіках для зворотного проксі):

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Я в змозі отримати відповідь, але без господаря призначення. У зворотному проксі, якщо я просто вказую, що все, починаючи з 1338 року, переходить до конкретного хоста, на який я хотів потрапити, він виконує тремтіння руки належним чином, і я можу включити SSL-проксі для перевірки зв'язку.

Налаштування є менш ніж ідеальним, тому що я не хочу припускати, що все, починаючи з 1338 року, переходить до цього хоста - будь-яка ідея, чому хост призначення знімається?

Знову дякую

Проблеми, які ви бачите, такі ж, що перешкоджають використанню декількох сертифікатів на одній IP-адресі / порту (без використання вказівки імені сервера) .

У звичайному HTTP ваш прозорий проксі може вказати, до якого хоста клієнт хоче підключитися, заглянувши в Hostзаголовок.

Коли прозорий проксі-сервер HTTPS MITM отримує запит, він не може в першу чергу знати, яке ім'я хоста запитував клієнт. (Я навіть не впевнений, що він може отримати IP-адресу з цими правилами, що, принаймні, дозволило йому здогадатися, використовуючи зворотний пошук DNS, хоча це вряд ли працює в загальному випадку.)

• Для отримання очікуваного імені хоста, проксі-сервер MITM повинен був прочитати Hostзаголовок у повідомленні HTTP, що може відбутися лише після успішного стискання руки.
• Для того, щоб мати успішне рукостискання, проксі-сервер MITM повинен генерувати сертифікат підробляння, що відповідає очікуваному імені хоста.

Як результат, проксі-сервер MITM не може знати, який сертифікат потрібно створити перед рукостисканням.

Це може працювати з непрозорим проксі-сервером MITM, оскільки ви хоч би отримали призначене ім'я хоста за допомогою CONNECTметоду HTTP .

Лише основна інформація про цю тему.

Є лише кілька пристроїв, які мені відомі, які можуть успішно зняти цю дію. Однак вони не є доступними для широкої громадськості. Я сам використовую Fortinet Fortigate з SSL Offloading.

В основному це і є; він перехоплює з'єднання SSL, зроблене для хоста, і розшифровує з'єднання в апараті, потім перевіряє, куди ви хочете піти, і приймає рішення про брандмауер на основі цієї інформації.

Після цього він встановлює власне з'єднання з цим хостом для отримання даних та повторного підписання клієнту оригінального запиту, використовуючи CA, наданий користувачем. Щоб зробити цю роботу безперебійною, необхідно мати клієнтський центр у надійному кореневому центрі CA.

Такі налаштування використовуються в організаціях для забезпечення політики компанії щодо використання Інтернету. Оскільки за допомогою Active Directory встановити клієнтський центр компанії у клієнтів легко, для великих організацій це не викликає проблем.

Це ТІЛЬКИ спосіб, коли ви можете це зробити без створення проксі-сервера вручну, оскільки трафік SSL IS зашифрований. В основному це MITM, тому важливо охопити будь-які юридичні питання.

Є ще кілька пропозицій щодо цього іншого питання, яке, можливо, ви бачили: прозорі міфи та факти про проксі-сервери . І ось це посилання пояснює, як саме налаштувати Squid на прозорий SSL-проксі. Це не те, що ви шукаєте, але це може принаймні дати зрозуміти, що може піти не так.

Правила iptables здаються нормальними, але я не маю уявлення, чи вміє проксі-програмне забезпечення, яке ви використовуєте, робити те, що ви намагаєтеся зробити. Документація, безумовно, стверджує, що це так.

Щоб додати рішення Бруно, я трохи дослідив і хотів поділитися тим, як я отримав ще один не менш ідеальний швидкий виправлення.

Після встановлення цих iptables я можу поставити зворотний проксі на порт 1338 і передати його до localhost на порт 1337. Оскільки порт 1337 є прозорим http-проксі, а дані були розшифровані, він візьме заголовок хоста і зробить його призначенням господар.

Основним недоліком є ​​те, що я по суті перетворив https-з'єднання на http - це не завжди працює з кожним сервером (не кажучи вже про дірку безпеки, яку я піддаю цьому).

Я працював у межах мого програмного забезпечення. Я вважаю, що більш чистим рішенням за словами Бруно було б припустити, що весь трафік з 1338 року повинен бути розшифрований. Після дешифрування огляньте хост призначення та проксі проксі за допомогою SSL.