Раніше сертифікати часто спливали через те, що їх потрібно було оновлювати вручну. Люди просто забували це зробити. З появою Let's Encrypt та автоматичної процедури оновлення як би проблема має бути вирішена. Але недавня історія з Firefox показує, що насправді вона, як і раніше, актуальна. На жаль, сертифікати продовжують закінчуватися.

Якщо хтось пропустив цю історію, опівночі 4 травня 2019 року раптово припинили працювати майже всі розширення Firefox.

Як з'ясувалося, масовий збій виник через те, що у Mozilla минув термін дії сертифіката, який використовувався для підпису розширень. Тому вони відзначалися як «невалідні» та не проходили перевірку (технічні деталі). На форумах як обхідний шлях рекомендували відключити перевірку підписів розширень у про: конфігурації або переведенням системного годинника.

Mozilla оперативно випустила патч Firefox 66.0.4, який вирішує проблему з невалідним сертифікатом, а розширення повертаються в нормальний вигляд. Розробники рекомендують встановити його та не використовувати ніякі обхідні шляхи для обходу перевірки підписів, оскільки можуть конфліктувати з патчем.

Проте ця історія вкотре показує, що закінчення терміну дії сертифікатів залишається актуальною і сьогодні.

У зв'язку з цим цікаво подивитися на досить оригінальний спосіб, як із цим завданням впоралися розробники протоколу. DNSCrypt. Їхнє рішення можна розділити на дві частини. По-перше, це короткострокові сертифікати. По-друге, попередження користувачів про закінчення терміну дії довгострокових.

DNSCrypt

DNSCrypt – протокол шифрування DNS-трафіку. Він захищає DNS-комунікації від перехоплень та MiTM, а також дозволяє обійти блокування на рівні DNS-запитів.

Протокол обертає DNS-трафік між клієнтом та сервером у криптографічну конструкцію, працюючи за транспортними протоколами UDP та TCP. Щоб його використовувати, клієнт і DNS-резолвер повинні підтримувати DNSCrypt. Наприклад, з березня 2016 року його включив на своїх DNS-серверах та у браузері «Яндекс». Про підтримку оголосили й деякі інші провайдери, зокрема Google та Cloudflare. На жаль, їх не так багато (на офіційному сайті перераховано 152 публічні DNS-сервери). Але програму dnscrypt-proxy можна встановити вручну на клієнтах під Linux, Windows та MacOS. Є та серверні імплементації.

Як працює DNSCrypt? Якщо коротенько, клієнт бере публічний ключ обраного провайдера і з його допомогою перевіряє його сертифікати. Вже там є короткострокові публічні ключі для сесії та ідентифікатор набору шифрів. Клієнтам рекомендується генерувати новий ключ для кожного запиту, а серверам – міняти ключі кожні 24 години. При обміні ключами застосовується алгоритм X25519, для підпису EdDSA, для блокового шифрування XSalsa20-Poly1305 або XChaCha20-Poly1305.

Один із розробників протоколу Френк Денис пише, Що автоматична заміна кожні 24 години вирішила проблему прострочених сертифікатів. В принципі, еталонний клієнт dnscrypt-proxy приймає сертифікати з будь-яким терміном дії, але видає попередження "Період dnscrypt-proxy ключів для цього сервера занадто великий", якщо він дійсний понад 24 години. Одночасно було випущено образ Docker, у якому реалізували швидку зміну ключів (і сертифікатів).

По-перше, це надзвичайно корисно для безпеки: якщо сервер скомпрометований або ключ потік, то вчорашній трафік не може бути розшифрований. Ключ уже змінився. Ймовірно, це становитиме проблему для виконання «закону Ярової», який змушує провайдерів зберігати весь трафік, у тому числі зашифрований. Мається на увазі, що пізніше його можна буде розшифрувати за потреби, запросивши ключ у сайту. Але в даному випадку сайт просто не зможе його надати, тому що використовує короткочасні ключі, видаляючи старі.

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

Коли автоматизація змінює ключі раз на кілька років, на неї не можна покластися, а люди можуть забути про закінчення терміну дії сертифіката. При щоденній зміні ключів це буде знайдено миттєво.

У той же час, якщо автоматизація налаштована нормально, то не має значення, як часто проводиться зміна ключів: щороку, щокварталу або тричі на день. Якщо все працює понад 24 години, то працюватиме вічно, пише Френк Денис. За його словами, рекомендація щодобової зміни ключів у другій версії протоколу разом з готовим чином Docker, що реалізує це, ефективно зменшила кількість серверів із сертифікатами, що закінчилися, одночасно покращивши безпеку.

Однак деякі провайдери все-таки вирішили з якихось технічних причин встановити термін дії сертифіката понад 24 години. Цю проблему в основному вирішили за допомогою декількох рядків коду в dnscrypt-proxy: користувачі отримують інформаційне попередження за 30 днів до закінчення терміну дії сертифіката, інше повідомлення з вищим рівнем серйозності за 7 днів до закінчення терміну дії та критичне повідомлення, якщо сертифікат залишився менше 24 годин. Це стосується лише сертифікатів, що спочатку мають тривалий термін дії.

Такі повідомлення дають користувачам можливість повідомити операторам DNS про майбутній закінчення терміну дії сертифіката, доки не стало занадто пізно.

Можливо, якби всі користувачі Firefox отримали таке повідомлення, то хтось напевно повідомив розробникам і ті б не допустили закінчення терміну дії сертифіката. "Я не пам'ятаю жодного DNSCrypt-сервера зі списку загальнодоступних DNS-серверів, у яких минув термін дії сертифіката за останні два або три роки", - пише Френк Денис. У будь-якому випадку, мабуть, краще спочатку попереджати користувачів, а не вимикати розширення без попередження.

Джерело: habr.com