На початку року, у звіті про проблеми та доступність інтернету за 2018-2019 , Що поширення TLS 1.3 неминуче. Якийсь час тому ми самі розгорнули версію 1.3 протоколу Transport Layer Security і, після збирання та аналізу даних, нарешті, готові розповісти про особливості цього переходу.
Голови робочої групи IETF TLS :
«Стисло, TLS 1.3 має надати фундамент більш безпечного та ефективного Інтернету на наступні 20 років».
Розробка зайняла довгі 10 років. Ми в Qrator Labs, разом з усією галуззю, уважно стежили за процесом створення протоколу від початкового проекту. За цей час потрібно було написати 28 послідовних версій чернетки для того, щоб у кінцевому рахунку в 2019 році світло побачило збалансований і зручний у розгортанні протокол. Активна підтримка TLS 1.3 ринком вже очевидна: впровадження перевіреного та надійного протоколу безпеки відповідає вимогам часу.
За словами Еріка Рескорли (технічного директора Firefox та єдиного автора TLS 1.3) :
"Це повна заміна TLS 1.2, яка використовує ті ж ключі та сертифікати, тому клієнт і сервер можуть автоматично спілкуватися по TLS 1.3, якщо обидва його підтримують", - сказав він. "Вже є хороша підтримка на рівні бібліотек, а Chrome і Firefox за замовчуванням включають TLS 1.3".
Паралельно у робочій групі IETF TLS закінчується , що оголошує старі версії TLS (за винятком тільки TLS 1.2) застарілими та непридатними для використання. Найімовірніше, фінальний RFC побачить світ до кінця літа. Це ще один сигнал IT-індустрії: оновлення протоколів шифрування не варто відкладати.
Список поточних реалізацій TLS 1.3 доступний на Github для всіх, хто шукає найбільш відповідну бібліотеку: . Очевидно, що ухвалення та підтримка оновленого протоколу буде — і вже йде — швидкими кроками. Розуміння того, наскільки фундаментальним стало шифрування у світі, поширилося досить широко.
Що змінилося порівняно з TLS 1.2?
З :
«Як TLS 1.3 робить світ кращим?
TLS 1.3 включає певні технічні переваги, такі як спрощений процес рукостискання (handshake) для встановлення безпечного з'єднання, а також дозволяє клієнтам швидше відновлювати сесії з серверами. Ці заходи покликані зменшити затримку на встановлення з'єднання та кількість невдалих з'єднань на слабких каналах, які часто використовуються як виправдання для надання лише нешифрованих HTTP-з'єднань.
Не менш важливо і те, що усунуто підтримку декількох застарілих і небезпечних алгоритмів шифрування та хешування, які все ще дозволено (хоча і не рекомендується) використовувати з більш ранніми версіями TLS, включаючи SHA-1, MD5, DES, 3DES та AES-CBC, одночасно додаючи підтримку нових наборів шифрів. Інші вдосконалення включають більше зашифрованих елементів рукостискання (наприклад, тепер зашифрований обмін інформацією про сертифікат), щоб зменшити обсяг підказок потенційному перехоплювачу трафіку, а також поліпшення в forward secrecy при використанні певних режимів обміну ключами, так що зв'язок в будь-який момент часу повинен залишатися безпечною, навіть якщо алгоритми, які використовуються для її шифрування, будуть скомпрометовані у майбутньому».
Розробка сучасних протоколів та DDoS
Як ви, можливо, вже читали під час розробки протоколу , у робочій групі IETF TLS . Вже тепер очевидно, що окремим підприємствам (включаючи фінансові установи) доведеться змінити спосіб забезпечення безпеки власної мережі для того, щоб пристосуватися до вбудованої в протокол .
Причини, з яких це може знадобитися, викладено у документі, . У 20-сторінковому папері згадується кілька прикладів, коли підприємство може захотіти виконати розшифрування out-of-band трафіку (що PFS робити не дозволяє), з метою моніторингу, відповідності нормативним вимогам або забезпечення захисту від DDoS-атак на прикладному рівні (L7).
Хоча ми безумовно не готові міркувати про нормативні вимоги, наш власний продукт для нейтралізації прикладних DDoS-атак (включаючи рішення, чутливої та/або конфіденційної інформації) було створено в 2012 році з урахуванням PFS, тому нашим клієнтам та партнерам жодних змін в їхній інфраструктурі після оновлення версії TLS на стороні сервера не потрібно було виробляти.
Також, за час, що минув з моменту впровадження, жодних проблем, пов'язаних з транспортним шифруванням, виявлено не було. Офіційно: TLS 1.3 готовий до використання у продакшені.
Втім, є все ж таки проблема, пов'язана з розробкою протоколів наступного покоління. Вона полягає в тому, що зазвичай прогрес у розвитку протоколів у IETF сильно залежить від результатів наукових досліджень, а стан академічних досліджень у галузі нейтралізації розподілених атак на відмову в обслуговуванні — дуже плачевний.
Так, добрим прикладом може виступати чернетки IETF “QUIC Manageability” («Управління QUIC»), що є частиною майбутнього набору протоколів QUIC: у ньому говориться, що «сучасні методи виявлення та нейтралізації [DDoS-атак] зазвичай включають пасивне вимірювання з використанням даних про мережеві потоки».
Останнє, насправді, дуже рідко зустрічається в реальних корпоративних середовищах (і лише частково застосовується до інтернет-провайдерів), і в будь-якому випадку навряд чи є «загальним випадком» у реальному світі — але постійно фігурує в наукових публікаціях, які зазвичай не підкріплені тестуванням всього спектра потенційних DDoS-атак, включаючи атаки прикладного рівня. Останні, в силу хоча б всесвітнього розгортання TLS, явно не можуть бути виявлені пасивним вимірюванням мережних пакетів та потоків.
Аналогічно, ми поки що не знаємо, як виробники обладнання для нейтралізації DDoS адаптуватимуться до реалій TLS 1.3. Через технічну складність підтримки out-of-band протоколу, може піти деякий час на апгрейд.
Постановка правильних цілей для спрямування наукових досліджень – серйозне завдання для провайдерів послуг нейтралізації DDoS. Одна з областей, у якій можна розпочати розвиток у IRTF, де дослідники можуть співпрацювати з галуззю для уточнення власних знань у проблемній галузі та пошуку нових напрямків досліджень. Ми також готові тепло привітати всіх дослідників, якщо такі знайдуться — з нами можна зв'язатися з питань чи пропозицій, пов'язаних з DDoS-дослідженнями або з дослідною групою SMART, за адресою
Джерело: habr.com