HTTPS-проксі означає два з'єднання TLS, а не одне

Назва HTTPS-проксі описує лише передавання між вашим клієнтом і проксі, і більше нічого. Вона не означає, що вебсайт за ним шифрується тим самим з'єднанням, і не означає, що проксі може читати сторінку. Коли ви розділите ці два з'єднання, помилки сертифікатів перестають бути загадковими, а порівняння з VPN стає конкретним.

Дві пари кінцевих точок, дві перевірки

У звичайному режимі тунелю є два відносини TLS. Перше йде від вашого клієнта до проксі й автентифікує проксі. Друге йде від вашого клієнта до вебсайту всередині тунелю й автентифікує вебсайт. Вони зазнають невдачі незалежно й налаштовуються незалежно.

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

Сприймайте їх як два з'єднання, що випадково мають спільний сокет, бо саме так воно і є.

Що насправді тунелює CONNECT

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

Ця відмінність і є всім аргументом безпеки для режиму тунелю, і вона ж є його межею.

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

Який сертифікат не пройшов

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

curl розділяє ці параметри саме з цієї причини. Файл CA проксі налаштовує перевірку проксі, тоді як файл CA налаштовує перевірку сервера, а поведінка відповідного сховища довіри також залежить від того, як зібрано curl.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Придушення перевірки не є виправленням. Воно нічого не доводить про жодну з кінцевих точок.

Інспекція — це інша схема

Інспекція TLS не є тунелюванням. Інспекційний посередник завершує відносини довіри, спрямовані до вебсайту, і подає клієнтові власний сертифікат, тож клієнт перевіряє посередника, а не сайт. За затвердженим дизайном це може бути законно, і це суттєво інше твердження, ніж побайтове пересилання. Не припускайте, що кожен проксі інспектує, і не припускайте, що зашифрований перехід через проксі це виключає.

Корпоративний CA у вашому сховищі довіри — це підказка про те, у якій схемі ви перебуваєте, а не доказ. Питайте про дизайн, а не виводьте його з ланцюжка сертифікатів.

Ці дві схеми дають різні відповіді на питання, хто може читати сторінку.

Порівняйте проксі та VPN за тими самими чотирма рядками

Порівняння стає корисним лише тоді, коли обидві схеми розгортання описані однаково.

Проксі, налаштований для одного запиту, охоплює лише цей запит. Він не пропускає через себе кожен процес на пристрої, і приклад команди саме такий вузький. Покриття VPN залежить від його маршрутизації та політики застосунків, які також треба перевіряти, а не припускати. Жоден варіант не охоплює все лише тому, що його встановили.

Запишіть ці чотири рядки для кожного варіанта, і суперечка зазвичай вирішується сама. Корисне порівняння не в тому, яка назва звучить більш зашифрованою. Воно в тому, які сегменти захищені, хто підтверджений на їхніх кінцях, яким посередникам ви довіряєте і який трафік політика справді охоплює.