Який ефект має https-трафік на проксі-серверах веб-кешу?

Я щойно пройшов два університетські курси з комп'ютерної безпеки та програмування в Інтернеті. Я думав про це днями:

Проксі-сервери веб-кеша кешують популярний вміст із серверів в Інтернеті. Це корисно, наприклад, якщо ваша компанія має внутрішнє підключення до мережі 1 Гбіт / с (включаючи проксі-сервер веб-кешу), але лише 100 Мбіт / с. Проксі-сервер веб-кешу може набагато швидше подавати кешований вміст на інші комп'ютери в локальній мережі.

Тепер розглянемо з'єднання, зашифровані TLS. Чи може зашифрований вміст кешуватися будь-яким корисним способом? Існує велика ініціатива від letsencrypt.org, яка має за мету зробити весь інтернет-трафік зашифрованим через SSL за замовчуванням. Вони роблять це, роблячи дійсно легким, автоматизованим та безкоштовним отримання сертифікатів SSL для вашого сайту (починаючи з літа 2015 року). З огляду на поточні щорічні витрати на SSL-серти, БЕЗКОШТОВНО дійсно привабливо.

Моє запитання: чи зрештою трафік HTTPS зробить проксі-сервери веб-кешу застарілими? Якщо так, то яка плата буде брати на себе навантаження на глобальний інтернет-трафік?

Так, HTTP поставить демпфер для кешування мережі.

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

У корпоративному середовищі ви можете змусити всі ПК довіряти сертифікатам кеш-сервера. Але інші машини видадуть помилки сертифікатів - які вони повинні. Зловмисний кеш може легко змінювати сторінки.

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

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

Це можливо завдяки методу підключення HTTP , який SQUID правильно реалізує . Іншими словами, для будь-якого запиту HTTPS, який отримує проксі, він просто "передає" його без будь-якого втручання при зашифрованому зашифрованому трафіку.

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

Отже, повертаючись до вашого первинного запитання: "Чи з часом трафік HTTPS зробить проксі-сервери веб-кешу застарілими? ", Моя відповідь така:

• ТАК : якщо ви покладаєтесь на веб-проксі лише з точки зору кешування;
• НІ : якщо ви покладаєтесь на веб-проксі для речей, окрім кешування (наприклад: автентифікація користувача; реєстрація URL-адрес тощо).

PS: аналогічна / основна проблема HTTPS стосується імені на основі віртуального хоста мультихомінгу, що часто зустрічається у веб-хостингових рішеннях, але .... стає складним при роботі з сайтами HTTPS (я не обговорюю детально, тому що це суворо не пов'язане з цим питанням).

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