Чи є спосіб кешувати HTTPS-запити на проксі-сервері?

12

Ми використовуємо проксі-сервер Squid в нашому середовищі і хочемо кешувати HTTPS-запити.

Чи є спосіб налаштувати Squid або взагалі проксі-сервер для кешування запитів HTTPS?

proxy squid https

Це, мабуть, належить на security.se

— Том О'Коннор

1

Щоб було зрозуміло, чи використовуєте ви кальмари перед купою власних серверів, чи використовуєте їх між робочими станціями та Інтернетом?

— Зоредаче

Просто для уточнення. Ви хочете кешувати запити чи відповіді?

— Gqqnbig

12

Існує спосіб це зробити, але це принципово проти причин використання HTTPS.

Ось як би ви це зробили.

Створіть самопідписаний SSL-сертифікат для сайту, з якого ви хочете перехопити та кешувати запити.
Встановіть і запустіть оглушення на вашому проксі-сервері, сказавши йому, що сертифікат, який він повинен мати, є сертифікатом, сформованим на етапі 1.
Попросіть оглушити переслану розшифровані запити на кальмари.
Можливо, вам знадобиться оглушення з іншого боку або openssl_client, щоб повторно зашифрувати запит на верхньому сервері.

Застереження:

Ваші користувачі будуть вас ненавидіти. Кожен SSL-запит на цей веб-сайт представляє недійсне вікно сертифіката.
Ви піддаєте себе потенційним позовам за вчинення неслухняних справ. (IANAL)
Ви зможете отримати лише сертифікат, який підписує власний підпис, який працює на це, через те, як повинна працювати мережа довіри PKI для SSL-сертифікатів. Не кажучи нічого про компрометовані кореневі ЦЗ.

Я не збираюся наводити точну інформацію про те, як це зробити, бо а) я вважаю, що це дещо неетично, і б) вам краще навчитися це робити.

Я пропоную вам дослідити, як працюють оглушення та атаки людини в середині.

— Том О'Коннор
джерело

Ви можете попросити Trustwave zdnet.com/… продати вам кореневий сертифікат, щоб ви могли реалізувати це рішення, не доставляючи незручностей своїм користувачам: P

— Rory

2

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

— Tom O'Connor

1

Довіра SSC + MITM корисна для налагодження протоколу, кешування, глибокої перевірки пакетів та цензури / реєстрації журналів. : / Окрім цих причин, не дуже добре.

6

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

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

— роб
джерело

5

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

— yrk
джерело

1

Чи немає способів досягти цього чи змусити проксі-сервер розшифровувати та кешувати?

— Супратик

Вирішення може дещо нагадувати man-in-middleрозгортання, але це переможе всі причини, які стоять за https

— yrk

5

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

— brunoqc

@brunoqc - це робота VPN.

— yrk

1

Якщо кешування https корисних навантажень важливо з якоїсь причини або налагодження сеансу https, MITM дуже корисний. Насправді так працює Чарльз.

1

Zeus (зараз Riverbed's) менеджер трафіку ZTM може це зробити, оскільки він може перекладати http і https трафік обома способами та кешувати незашифрований вміст - він працює, ми його використовуємо, але це страхітливо дорого - як у ціні Porsche на сервер.

— Подрібнювач3
джерело

5

Але це все ще вимагає від вас встановити новий кореневий сертифікат на клієнта, чи не так? І ви все ще повинні довіряти проксі, чи не так?

— Фігаг