Питання та відповіді №1: чи захистить HTTPS?

середній 17:50 дивитися на YouTube ↗ переглянуто

Розділи

Про що це відео

Перший випуск Q&A на каналі — відповіді на коментарі під попередніми відео, головно під популярним відео про DHCP, плюс питання про повнотекстовий пошук, індекси баз даних і Base64. Головне питання: якщо зловмисник підмінив мережу, але сайт працює через HTTPS, чи є ще загроза? Його відповідь — так, і він перелічує конкретні атаки. Також він весело зачитує й спростовує кілька зневажливих коментарів «хейтерів» (людей, які подивилися перші три хвилини й оголосили все фейком, не додивившись до живого демо), зазначаючи, що відео про DHCP набрало 70 000 переглядів і 400+ коментарів, на 99% позитивних, тож формат Q&A триватиме.

Головне

HTTPS не рятує, коли зловмисник контролює мережу: (1) віддати сторінку по звичайному HTTP — вона виглядає ідентично, але логін чи дані картки ви вводите на фейковому сайті; (2) перенаправити вас на схожий домен (rozetka.com.ua → rozetka.com.ui) з власним валідним HTTPS, який проксіює ваші запити й збирає дані карток; (3) заблокувати весь трафік і сказати «для інтернету в кафе потрібен цей сертифікат — двічі клацніть, щоб встановити», після чого можна проводити MITM усього вашого HTTPS, випускаючи сертифікати, яким довіряє щойно встановлений; (4) експлуатувати 0-day у браузері (він згадує Spectre/Meltdown, які експлуатувалися з JavaScript для читання пам'яті процесу й пошуку приватних ключів).
Заголовки HSTS заблокували б трюки з HTTP-даунгрейдом/перенаправленням, але багато великих сайтів (включно з Rozetka) їх не ставлять, тож атака працює на практиці.
На звичайному HTTP зловмисник бачить увесь трафік і може на льоту підмінити файл, який ви завантажуєте (zip/xz), на пошкоджений або зі шкідливим кодом. VPN перемагає все це — зашифрований тунель до VPN-сервера не проінспектуєш.
DHCP starvation — тривіальна річ: скрипт на ~100 рядків, що ганяє DHCP-запити з випадковими MAC-адресами, вичерпує 100 чи 1000+ адрес; вручну прописати DNS 8.8.8.8 не допомагає, бо зловмисник усе одно може видати вам шкідливий default gateway і пустити весь трафік через себе.
Зберігання UUID первинних ключів як BINARY(16) у MySQL замість 32-символьного тексту допомагає, але не драматично — 16-байтний ключ усе одно часто перевищує половину розміру індексу (наприклад, ~55% проти 70%), а з binary незручно працювати (для читання/показу треба конвертувати); він радше тримав би UUID окремою колонкою.
Про інвертовані індекси: інвертований індекс і є ефективною структурою даних — його не переписують у «щось краще», змінюють лише формат серіалізації. Дельта-компресія важлива, бо стискає великі ID до маленьких чисел (що вмикає подальше стиснення на кшталт VByte-кодування зі згаданої статті), пришвидшує читання з файлової системи й дозволяє більшому індексу поміститися в RAM.
Base64 відпрацьовує свої ~33% збільшення розміру всюди, де бінарні дані мають їхати всередині текстового формату: HTTP-заголовки (у значенні не можна переносити рядки), Basic auth, логи, які хочеться відкривати текстовим редактором, JSON/XML-пейлоади, CSV без екранування, вкладення SMTP і PEM-файли SSH-ключів.
Цінність JWT: він несе всю підписану сесію (stateless), а не ID сесії, тож його за задумом НЕ потрібно зберігати в БД; з асиметричним підписом ви роздаєте публічний ключ будь-кому — і будь-який сервіс може перевірити, що токен від вас. Він зауважує, що rate-limiter в Express не стосується сесій — це просто обмежувач частоти запитів.