Зробіть Chrome використовувати тунель SSL як проксі (HTTP CONNECT) для HTTP-запитів

2

Я хочу змусити Chrome використовувати SSL для всіх вихідних запитів до проксі (яким я керую). Проксі-сервер може приймати звичайне HTTPS-з'єднання (як прозорий проксі), а також підтримує незашифроване з'єднання HTTP, всередині якого клієнт може зробити HTTP CONNECT і потім узгодити SSL.

Тим НЕ менше, Chrome використовує тільки HTTP CONNECT для HTTP сек URL. Коли я відкриваю URL-адресу http, chrome надсилає HTTP GET до проксі, а не HTTP CONNECT. Це трапляється, навіть якщо я використовую сценарій PAC, який повертає "HTTPS хост: порт" для URL-адрес http та https. І я взагалі не можу змусити хром використовувати звичайні HTTPS під час підключення до проксі.

Моя мета - захистити трафік між браузером та проксі від слухачів пасивної мережі, включаючи приховування будь-яких маркерів аутентифікації проксі, переданих у заголовках HTTP. Як я можу це досягти?

google-chrome proxy ssl

— данармак
джерело

Серйозний Chrome використовує HTTP CONNECT для https-запитів? Чи не використовується натомість прямий запит?

— Печер'є

Будь ласка, уточніть "..внутрі, який клієнт може зробити HTTP CONNECT, а потім узгодити SSL". Не можу зрозуміти

— Pacerier

Лише підказка для майбутніх відвідувачів: комбінуючи проксі з VPN-з'єднанням, ви можете досягти "розділеного тунелювання", де просто трафік браузера направляється через VPN-з'єднання.

— Даніель Б

0

Моя мета - захистити трафік між браузером та проксі від слухачів пасивної мережі, включаючи приховування будь-яких маркерів аутентифікації проксі, переданих у заголовках HTTP. Як я можу це досягти?

CONNECT не є протоколом, який використовується для проксі-проксі-з'єднань HTTP, але він використовується лише для створення тунелю до іншого хоста. Потім з'єднання HTTPS створюють TLS-з'єднання всередині цього тунелю, яке надає необхідний захист.

Це означає, що навіть якщо ви зможете переконати Chrome створити тунель для звичайного HTTP за допомогою CONNECT, він не забезпечить очікуваний захист, оскільки він буде використовувати цей тунель із звичайним HTTP. Шифрування є властивістю HTTPS, а не тунелем CONNECT, і жодне шифрування не буде зроблено для тунелювання HTTP таким чином. Таким чином, зловмисник все одно зможе нюхати всі дані, які ви хочете захистити.

Те, що вам потрібно мати для захисту зв’язку між Chrome і проксі, буде VPN. Але це не захищає зв’язок між проксі і сервером. Цей захист може бути здійснено лише в тому випадку, якщо сам сервер підтримує HTTPS.

— Steffen Ullrich
джерело

Я розумію, що. Ось чому я згадав, що я можу також забезпечити прозорий HTTPS проксі (з правильним серверним сертифікатом). Я не можу сказати своїм користувачам використовувати VPN, мені потрібно рішення, що підтримується самим Chrome (конфігурація модуля проксі).

— danarmak

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

— Steffen Ullrich

@danarmak, зачекайте, ви хочете сказати, що хочете конвертувати всі HTTP-запити Chrome у HTTPS, як, наприклад, те, що робить HTTPS ВСЕ?

— Pacerier

0

Здається, Chrome не може зробити це.

Хочеться зазначити, що, здається, API розширення Chrome для керування налаштуваннями проксі дозволяє використовувати цей сценарій, але немає можливості досягти еквівалентної конфігурації за допомогою налаштувань проксі-сервера або PAC-скрипту.

— данармак
джерело

Дивіться мою відповідь щодо оновлень.

— Pacerier

-2

Я раніше не пробував цього, але ви можете експериментувати з --proxy-serverпрапором .

— Pacerier
джерело

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

— Даніель Б