Через 30 років після винаходу WWW близько 25% веб-сайтів все ще відвідують без шифрування трафіку. Давайте розглянемо, в чому причина.
HTTPS – не для всіх?
Отже, якщо увійти у свій екаунт на поштовому сервісі або в соціальній мережі, то все виглядає, на перший погляд, чудово. В назві домену є префікс «https://», увесь трафік шифрується і є захищеним. Але що станеться, коли закрити вікно, а потім знову відкрити веб-сайт, та вже не вказувати «https://» на початку? Чи перейде веб-браузер автоматично на використання протоколу HTTPS для пересилання трафіку? Це має відбутися, якщо веб-сайт правильно реалізує політику HTTP Strict Transport Security (HSTS) – механізму, що примусово активує захищене з’єднання через протокол HTTPS. Дана політика безпеки дозволяє відразу ж встановлювати безпечне з’єднання замість використання незахищеного HTTP-протоколу. Механізм застосовує особливий заголовок Strict-Transport-Security для примусового використання браузером протоколу HTTPS навіть в разі переходу по посиланнях з явним зазначенням протоколу HTTP (http://).
Експерт з кібербезпеки Патрик Ф. Уілбур (Patrick F. Wilbur) в рамках свого дослідження вирішив відкрити нову вкладку у веб-браузері і ввести назву сайту «google.com», навмисно не вказуючи «https://». Він очікував, що механізм HSTS стартує автоматично і процедура обміну даних перейде на захищений канал HTTPS.
Напевно ж Google, як один з найбільш популярних веб-сайтів у світі, повинен правильно реалізовувати технологію HSTS, чи не так? Відповідь – ні. Вводимо «netflix.com» – чи запущена політика HSTS? Ні. Тоді Патрик Ф. Уілбур відвідав веб-сайт популярного банку, спробував ще кілька додаткових популярних веб-сайтів. Ні, ні і ні – як Firefox, так і Chrome показав ідентичні результати. Але сайт «accounts.google.com» таки виконав вимоги політики HSTS. Це означає, що HSTS (не завжди) застосовується лише для субдоменів, а не для батьківських доменів популярних веб-сайтів.
Патрик Ф. Уілбур перевірив, що «www.google.com», «www.netflix.com» та «github.com» ніколи не переходять на незахищений протокол HTTP. Здається, що веб-браузери правильно реалізували правила HSTS, але… більшість інших популярних веб-сайтів виконують політику HSTS лише для субдоменів, а не для батьківських доменів, або ж взагалі не виконують HSTS. Це підриває увесь сенс технології HSTS та призводить до того, що трафік передається незашифрованим і створює зручну можливість атаки на будь-яку загальнодоступну мережу.
Популярні веб-сайти не завжди вдаються до застосування технології HTTP Strict Transport Security для кореневих доменів, що потенційно може спричинити атаку типу «людина посередині» (man-in-the-middle) для відвідувачів
Як перевірити, чи застосовується HTTP Strict Transport Security?
- Перейдіть на вкладку Network (Мережа) в інструментах розробника веб-браузера Chrome, а потім введіть URL-адресу, яку ви раніше відвідали (без префіксу «https://»).
- Якщо ви отримали код статусу 307 Internal Redirect з заголовком відповіді «Non-Authoritative-Reason: HSTS», то вимоги протоколу HTTP Strict Transport Security виконуються. Якщо вказано будь-який інший тип редиректу як першого редиректу, то це не так.
Отже, неможливо в цілому пояснити, звідки береться так багато небезпечного трафіку HTTP, але, як мінімум, зрозуміло, що веб-сайти, до яких має бути доступ лише через HTTPS, не завжди налаштовані правильно. Це означає, що користувачі, які не перевіряють ретельно сертифікати та URL-адреси HTTPS, знаходяться під загрозою фішингової атаки типу man-in-the-middle (MITM).
Але HSTS також не є супернадійним
Порт UDP 123 використовується протоколом NTP (Network Time Protocol) і є не шифрованим і відкритим. HSTS інформує веб-браузери, що політики HSTS мають виконуватися до раніше визначеного часу, тобто поки не скінчився їх термін дії. Та проблема в тому, що всі годинникові сервіси, які визначають цей час, можуть бути підроблені просто шляхом MITM-атаки через NTP. Це означає, що через злам протоколу NTP можна виконати TLS/SSL-Strip атаку навіть на веб-сайти, де реалізований HSTS.
Окрім того, використання HSTS також викликає значні побоювання щодо конфіденційності. Потужні рекламні агенції, які хочуть відстежувати поведінку людей на сайті, можуть використовувати HSTS як файли supercookie.
DNS — означає «динозавр»
Наступна проблема пов’язана з системою доменних імен (DNS). Взагалі DNS є ефективною технологією, але надзвичайно небезпечною, і про це відомо вже досить давно. Наприклад, варто звернути увагу на такі пункти:
- Відсутня будь-яка перевірка того, що відповіді з IP-адреси, отримані через DNS, справді надіслані легітимними DNS-серверами, а не зловмисниками.
- Не існує шифрування запитів DNS.
- Також немає зв’язку між записами DNS та шифруванням веб-серверів (єдиним виключенням є DomainKeys для зменшення підробленої електронної спам-пошти), тому можна підмінити DNS-відповіді, щоб переадресувати запит на небезпечні сервери та використати той факт, що політики HSTS не завжди налаштовані правильно.
Отже, у 2019 році ми все ще використовуємо стару, небезпечну систему DNS (попри такі методи, як HSTS), тому користувачі практично вразливі до атак.
Чому ми все ще не «полагодили» безпеку в інтернеті?
На це питання немає короткої відповіді, але можна виділити як мінімум 3 пункти:
- Проблеми керування: технологія додаткового захисту https-з’єднань key pinning (тобто зберігання списку дозволених для домену ключів) ускладнюється тим, що ключі/сертифікати шифрування потрібно час від часу змінювати, а керування цим процесом з поточними інструментами є великим головним болем для системних адміністраторів. Отже, процес key pinning повністю застарів і HSTS недостатньо для захисту публічного з’єднання.
- Необхідні потужні компетенції та знання в широкому діапазоні: безпеку завжди складно впроваджувати правильно.
- Ми просто не переймаємося такою проблемою і не приділяємо їй достатньо уваги.
Проблеми довіри в інтернеті
Все наведене вище ускладнюється ще більше тим фактом, що сьогодні шифрування в інтернеті залежить від довіри органам сертифікації (CA) для точного підтвердження автентичності ключів шифрування, які використовуються під час початкового «рукостискання» між клієнтом-браузером та сервером. Ще гірше, що вибір алгоритму для конфіденційного з’єднання відбувається саме під час початкового рукостискання, тобто кожного разу обирається новий алгоритм, а мережа переповнена клієнтами та серверами, які містять несумісні комбінації більш/менш безпечних алгоритмів і версій.
Ось як працює захищене з’єднання TLS. Перш за все, під час початкового «рукостискання» клієнт Аліса (наприклад, веб-браузер), який хоче безпечно спілкуватися з об’єктом Боб (веб-сервером), повинен досягти згоди з Бобом про визначення каналу «безпечних комунікацій». Далі, для того, щоб Аліса встановила захищений канал з Бобом (назвемо його канал №1), Аліса до цього має використати інший захищений канал зв’язку з Бобом (канал №2) для обміну ключами для шифрування першого каналу. А щоб переконатися, що і другий канал є надійним, Аліса спочатку перевіряє (через канал №3) сертифікаційний центр «Val», щоб бути впевненим в тому, що третя особа в інтернеті – Єва, яка хоче перехопити повідомлення – не замаскувалася під Боба.
Отже, для того, щоб Аліса повірила в те, що зв’язок з Бобом захищений від чужих вух (тобто від Єви), Аліса повинна повірити Бобу, також має повірити, що центр «Val» насправді не є ФБР, і до того ж довіритися протоколам, які використовуються для створення каналів 1, 2 і 3.
Цей процес відомий як ланцюг довіри. Але хто спостерігає за спостерігачами? І чи існує рішення Trust No One (не довіряти нікому)?
Висновки
Отже, коротко про результати дослідження: велика частина веб-трафіку залишається незашифрованим, до того ж без поважної причини; популярні веб-сайти, включно з google.com, netflix.com та деякими великими фінансовими сервісами неправильно встановлюють заголовки HTTP, пов’язані з безпекою, що потенційно може піддавати користувачів атакам man-in-the-middle; DNS все ще підриває основи захисту інтернету; мережа довіри в інтернеті є дуже складною для правильної реалізації.
У майбутньому в інтернеті має бути прийнята парадигма безпеки, що основана на недовірі, це дозволить зменшити ризик і підвищити прозорість, підзвітність і аудит. Ми будемо довіряти лише системам та (віртуальній) політиці, що ґрунтуються на математично доказових і верифікованих гарантіях. Інституції будуть замінені спільнотами, узгодженими через консенсусні алгоритми.
Чи обов’язково потрібне ефективне шифрування? Відповідь – ні. З іншого боку, інтернет побудований на системах довіри і всі парадигми довіри залежать від створення безпечного та шифрованого каналу. Цілісність ланцюжків визначається найслабшою ланкою, але в цілому надійні безпечні канали – це фундаментальна фізична система, яка утримує будь-які комунікації в купі. То ж в підсумку надійна мережа/мережа довіри повинна ґрунтуватися на потужній математиці.
ЧИТАЙТЕ ТАКОЖ:
- Безкоштовний сир: чим небезпечне підключення до відкритої мережі Wi-Fi?
- Атаки типу Man-In-The-Middle: що треба знати кожному
- Фішинг та цільовий фішинг: поради по захисту
Джерело: Hackernoon