squid кешує https сторінки. це можливо?

[anatolijd]

Привіт,

справа така: люди в офісі часто ходять на один сайт по https://somesite.com.
Сторінки на сайті важкі, і середньому > 100Кб кожна.

Чи відомий комусь спосіб кешувати https:// - сторінки за допомогою squid?

[piktor]

Ну, squid позиціонується як кешуючий проксі. У squid.conf має бути параметр (забув як зветься - немає під рукою), що відповідає за розмір кешу. Але це немає ніякого сенсу, якщо сторінки динамічні.

[anatolijd]

ясно, але справа не в розмірі сторінки.

питання стоїть чи squid в принципі вміє _кешувати_HTTPS_ (secured httpd) ?


А стосовно динамічних сторінок - я не дуже досвічений.
буду вдячний як поясните наступну ситуацію:

http://site.com/showimage.do?img_id=1234
http://site.com/showimage.do?img_id=1234&gid=3
http://site.com/showarticle.do?id=1234&group=7

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

Тобто кешування цього контенту є дуже бажаним.

Питання  - ці три динамічні ріквести можуть бути кешовані by squid? А бровзером?

[noddeat]

до чого тут сквід? кешуйте браузером. кешування сквідом — це дуже погана ідея.

у фаєрфоксі колупайте, наприклад, about:config -> пошук за словом cache.

[piktor]

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

[borman]

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

Інший варіант — розширювати канал в Інтернет або обмежувати апетити користувачів.

[anatolijd]

про - https://  

по ідеї,  squid міг би розшифрувати дані які приходять від сервера, але не дані які йдуть від клієнта серверу.
Але не знаючи клієнтського ріквеста сквід просто тупо не має алгоритму за яким би можна було визначити які дані треба класти в кеш а які вже протухли (expired).

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


вобщем кешування https://   на проксі-сервері відпадає, бо не є можливим.

Єдиний варіант кешування https://  -  це надіятись на кешування самим бровзером.
Бровзер дійсно може кешувати https:// , і тут все залежить лише від хідерів які приходять від сервера.

бачу не буде мені з тим щастя...

[borman]

про - https://  

по ідеї,  squid міг би розшифрувати дані які приходять від сервера, але не дані які йдуть від клієнта серверу.
Але не знаючи клієнтського ріквеста сквід просто тупо не має алгоритму за яким би можна було визначити які дані треба класти в кеш а які вже протухли (expired).

Хто вам сказав таку дурницю? Негайно оформіть свою громадянську позицію щодо некомпетентних висловлювань, давши йому добрячого штурхана. Під час обміну даними між переглядачем та сервером формується захищений криптографічно канал (див. SSL), і ніхто і ні в якому разі не може розшифрувати ні запити, ні відповіді (не знаючи приватного ключа для сертфікату сервера). squid, як ви можете пересвідчитись самостійно, для обробки такої сесії використовує метод CONNECT, який передбачає просту "сиру" передачу даних, без намагання втрутитись і розпізнати протокол.

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

[anatolijd]

ага-а-а, тепер ясно чого то дурниця - http://en.wikipedia.org/wiki/Transport_Layer_Security#How_it_works

пара public/private key насправді використовується для того щоби згенерувати і безпечно обмінятись унікальним "master secret" ключем, яким власне й шифруватимуться дані в встановленому захищеному з`єднанні.
Отже, від цього моменту навіть знаючи private key вже неможливо розшифрувати дані , правильно?

[Praporshic]

ага-а-а, тепер ясно чого то дурниця - http://en.wikipedia.org/wiki/Transport_Layer_Security#How_it_works

пара public/private key насправді використовується для того щоби згенерувати і безпечно обмінятись унікальним "master secret" ключем, яким власне й шифруватимуться дані в встановленому захищеному з`єднанні.
Отже, від цього моменту навіть знаючи private key вже неможливо розшифрувати дані , правильно?

Звісно ж. Хоча, можна зробити man-in-the-midlle, встромивши проксі такими чином, щоб він замість клієнта шифруванням займався, але це небезпечно або протизаконно.

[anatolijd]

Єдино можливий варінт, коли проксі має можливість втрутитись в процес передачі даних, полягає в тому, що проксі в момент встановлення з'єднання самостійно генерує самопідписаний сертифікат на ім'я сервера та організовує взаємодію з клієнтом за допомогою цього сертифікату (клієнт отримає попередження про самопідписаний сертифікат на те зможе однозначно дізнатись, чи є сервер справжній).

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

[borman]

Саме цей варіант я й описав.

[piktor]

Не додивився, що саме https в попередніх постах.