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

Через 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 для кореневих доменів, що потенційно може спричинити атаку типу «людина посередині» (man-in-the-middle) для відвідувачів

Як перевірити, чи застосовується HTTP Strict Transport Security?

  1. Перейдіть на вкладку Network (Мережа) в інструментах розробника веб-браузера Chrome, а потім введіть URL-адресу, яку ви раніше відвідали (без префіксу «https://»).
  2. Якщо ви отримали код статусу 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 пункти:

  1. Проблеми керування: технологія додаткового захисту https-з’єднань key pinning (тобто зберігання списку дозволених для домену ключів) ускладнюється тим, що ключі/сертифікати шифрування потрібно час від часу змінювати, а керування цим процесом з поточними інструментами є великим головним болем для системних адміністраторів. Отже, процес key pinning повністю застарів і HSTS недостатньо для захисту публічного з’єднання.
  2. Необхідні потужні компетенції та знання в широкому діапазоні: безпеку завжди складно впроваджувати правильно.
  3. Ми просто не переймаємося такою проблемою і не приділяємо їй достатньо уваги.

Проблеми довіри в інтернеті

Все наведене вище ускладнюється ще більше тим фактом, що сьогодні шифрування в інтернеті залежить від довіри органам сертифікації (CA) для точного підтвердження автентичності ключів шифрування, які використовуються під час початкового «рукостискання» між клієнтом-браузером та сервером. Ще гірше, що вибір алгоритму для конфіденційного з’єднання відбувається саме під час початкового рукостискання, тобто кожного разу обирається новий алгоритм, а мережа переповнена клієнтами та серверами, які містять несумісні комбінації більш/менш безпечних алгоритмів і версій. 

Ось як працює захищене з’єднання TLS. Перш за все, під час початкового «рукостискання» клієнт Аліса (наприклад, веб-браузер), який хоче безпечно спілкуватися з об’єктом Боб (веб-сервером), повинен досягти згоди з Бобом про визначення каналу «безпечних комунікацій». Далі, для того, щоб Аліса встановила захищений канал з Бобом (назвемо його канал №1), Аліса до цього має використати інший захищений канал зв’язку з Бобом (канал №2) для обміну ключами для шифрування першого каналу. А щоб переконатися, що і другий канал є надійним, Аліса спочатку перевіряє (через канал №3) сертифікаційний центр «Val», щоб бути впевненим в тому, що третя особа в інтернеті – Єва, яка хоче перехопити повідомлення – не замаскувалася під Боба.

Отже, для того, щоб Аліса повірила в те, що зв’язок з Бобом захищений від чужих вух (тобто від Єви), Аліса повинна повірити Бобу, також має повірити, що центр «Val» насправді не є ФБР, і до того ж довіритися протоколам, які використовуються для створення каналів 1, 2 і 3.

Цей процес відомий як ланцюг довіри. Але хто спостерігає за спостерігачами? І чи існує рішення Trust No One (не довіряти нікому)?

Висновки

Отже, коротко про результати дослідження: велика частина веб-трафіку залишається незашифрованим, до того ж без поважної причини; популярні веб-сайти, включно з google.com, netflix.com та деякими великими фінансовими сервісами неправильно встановлюють заголовки HTTP, пов’язані з безпекою, що потенційно може піддавати користувачів атакам man-in-the-middle; DNS все ще підриває основи захисту інтернету; мережа довіри в інтернеті є дуже складною для правильної реалізації.

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

Чи обов’язково потрібне ефективне шифрування? Відповідь – ні. З іншого боку,  інтернет побудований на системах довіри і всі парадигми довіри залежать від створення безпечного та шифрованого каналу. Цілісність ланцюжків визначається найслабшою ланкою, але в цілому надійні безпечні канали – це фундаментальна фізична система, яка утримує будь-які комунікації в купі. То ж в підсумку надійна мережа/мережа довіри повинна ґрунтуватися на потужній математиці.

ЧИТАЙТЕ ТАКОЖ:

Джерело: Hackernoon

Читайте также:

Суперкомп’ютер MIT здатний аналізувати веб-трафік усього інтернету

Starlink чи OneWEB? Kuiper чи Telesat LEO? Супутниковий інтернет стає все більш доступним

Що нова теорія про увагу розповідає про свідомість

Чи справді безпечні банківські карти без номера?