Back
Перед технічними директорами бізнесу часто стоїть дилема - що обирати:
- найбільш суворі засоби захисту, які не дають змоги працювати з веб- та мобільними додатками власникам стареньких Android та Windows, - або використати менш надійні шифри на своїх веб порталах та REST API, але дозволити доступ широкому загалу користувачів?
Щоб прийняти вірне рішення зазвичай потрібно порахувати збитки від зменшення клієнтської аудиторії та ризики. І якщо збитки ще більш менш зрозуміло як моделювати, то ризик використання TLS1.2 vs TLS1.3 не такий вже очевидний. Спробуємо розібратися в цьому питанні.
По перше в чому ключові особливості дизайну TLS 1.3:
- він швидший, особливо на з'єднаннях з високою латентністю, наприклад у мобільних користувачів. Це досягається за рахунок скороченої фази ініціації протоколу (рукостискання), яка вимагає один раунд рукостискання в TLS 1.3, замість двох в старих версіях. Також вже в перших пакетах TLS 1.3 можливо направляти HTTP GET запит, що ще більше прискорює обмін даними. Сучасний веб-додаток робить сотні запитів, і зменшення часу відгуку наприклад з 250мс до 50мс значно покращує враження користувачів. Також для відновлення з'єднання TLS 1.3 може використовувати 0-RTT (“нульова кількість раундів”) для відновлення з”єднаннь. Більшість сучасних з'єднань TLS то повторні з'єднання, тому це значно збільшує швидкість. Cloudflrare підтримує 0-RTT TLS 1.3 вже кілька років, Google Chrome додав підтримку в травні 2021р. Зауважу, що включення 0-RTT робить з'єднання вразливим до атак повтору (replay attacks), і прибирає важливу властивість forward secrecy (без неї зловмисник по записам трафіку може відновити шифровані дані, якщо йому вдасться вкрасти приватні ключі серверу або клієнта). Для багатьох випадків відсутність захисту від повторних запитів не критична, адже браузер дуже часто їх робить, навіть просто через погане мережеве з'єднання. - EncryptedClientHello фіча дозвляє приховати ім'я серверу до якого робить запит браузер, таким чином, якщо сервер за Cloudflare чи іншою CDN то перехоплення трафіку не дасть змоги побачити використання нашого серверу. Зауважу, що додатково потрібно вмикнути в браузері DNS over HTTP. Ці налаштування значно збільшують приватність користувачів. ** - Прибрана стара та небезпечна (ризикована) функціональність, яка була присутня в TLS 1.2: SHA-1, RC4, DES, 3DES, AES-CBC, MD5, вразливі групи DH, експортовані шифри (причина успіху атак FREAK/LogJam)
Розглянемо історичні вразливості більш старих версій TLS/SSL:
POODLE - вразливість в SSL3.0. Через те, що імплементація режиму зчеплення шифроблоків шифрування некоректно повідомляла про помилку в доповнені( padding) повідомлення (використовується в останньому шифроблоці). В цій версії SSL доповнення не захищено кодом аутентифікації (MAC). Під час атаки зловмисник, що може перехоплювати трафік змушує користувача відкриті в iframe сценарій, який робить запити до легітимного сайту із використанням сесійних ідентифікаторів (кукі). Зробивши запит, зловмисник його модифікує і спостерігає за помилками серверу. В цілому достатньо 256 запитів щоб відновити один байт кукі.
Golden poodle, Zombie poodle, 0-length OpenSSL, Sleeping POODLE - модифікації атак на SSLv3 та режим CBC коли використовуються трохи інші оракули ніж в оригінальному POODLE. TLS1.3 не вразливий через відсутність режиму CBC.
BEAST - використовує той факт, що TLS 1.0 та попередники замість випадкового вектора ініціалізації (IV), використовували останній шифроблок з попереднього повідомлення. Атакуючий знову через iframe відправляє спеціальні запити і спостерігає, чи вийде в нього повторити шифроблок в якому знаходиться один з байтів сесійного кукі, який треба відновити. Для цього йому знову ж таки достатньо 256 запитів.
Lucky13 - використовує побічний канал витоку інформації через час обчислення коду автентифікації (MAC). TLS (1.2 і старіші) в режимі CBC використовує схему - MAC-Encode-Encrypt. Тоб-то від відкритого текстру рахується код автентифікації, кодується для зручності і шифрується. MAC (HMAC насправді) вираховується від 64 байтного блоку, але через особливості TLS (наявності заголовку, що не є частиною шифрування даних), ефективно HMAC рахується від 55 байт. Якщо в блоці більше ніж 55 байт, тоді треба рахувати HMAC від двох блоків, що вимагає більшої кількості циклів процесору і відповідно часу. Зловмисник по схемі як у BEAST відправляє через iframe+JavaScript запити, замінює в них пару байт в кінці зашифрованого блоку і виявляє чи коротший час відповіді серверу. Якщо він коротший, то зловмисник може знайти останній байт відкритого тексту (він дорівнює XOR байтів наданих зловмисником та 0x1 - бо це ми знаємо байти доповнення (padding) а не даних, через коротший час відповіді серверу). Знову ж таки час розшифрування пропорційний 256. Сучасні реалізації OpenSSL та інших бібліотек прагнуть усунути можливі канали витоку по часу, але найбільш надійним механізмом є відмова від CBC режиму.
Lucky microseconds – Amazon випустив свою реалізацію TLS, що серед іншого впровадила спроби захисту від Lucky13 за рахунок постійної кількості викликів HMAC функції та випадокових затримок у випадку помилки TLS. Але дослідники знайшли недоліки в реалізації (навіть при постійній кількості викликів HMAC, кількість викликів внутрішньої функції стискання HMAC буде різна для даних різної структури). А випадкові затримки не були випадковими, через недоліки реалізацій стандартних функцій sleep/usleep в бібліотеках Unix.
CRIME - основана на вразливості, яка виникає під час стискання даних перед шифруванням. Зловмисник, наприклад, відправляє HTTP запит з iframe + JavaScript в якому в контрольованому ним полі вставляє Cookie: sessionid=?, де ? - перебирається. Якщо зловмисник вгадає перший байт з реального хедеру кукі, то шифрований запит буде трохи коротший. Таким чином байт за байтом він відновлює весь сесійний кукі. Атака мала кілька демонстрацій, можна вважати її доволі практичною. Більшість сучасних TLS клієнтів та серверів вимкнули компресію TLS (хоч вона може працювати і в TLS 1.2). TLS 1.3 повністю виключив можливість стискання і не вразливий для цієї атаки.
TIME - атака використовує наявність стискання HTTP відповіді. Для її успішного виконання зловмиснику треба мати можливість вимірювати час відповіді серверу (через недоліки SOP і витоки даних це буває можливим), та впливати на зміст відповіді серверу. Приміром, коли він хоче дізнатись CSRF токен, то він його дублює у відповіді серверу (але звісно замість невідомих байтів самого токену ставить певні символи). І починає перебирати значення першого байту. Якщо він вгадує, то завдяки стисненню відповідь серверу буде коротша за інші. Розмір відповіді спеціально підбирається таким чином, щоб бути на кордоні сегментів TCP. І довша відповідь вимагає відправки двох пакетів TCP, замість одного (при вірно вгаданому байті). Атака була практично продемонстрована. Не залежить від версії TLS.
BREACH - схожа на атаку TIME, використовує наявність стиснення HTTP відповіді. Відрізняє вірно вгаданий байт за зменшенням розміру відповіді серверу. Для практичного виконання вимагає подолання особливостей кодування стиснених даних, але ці методики відпрацьовані і за кілька тисяч запитів дозволяють відновити короткий секрет у відповіді серверу. Не залежить від версії TLS
FREAK - атака використовує факт підтримки клієнтом і сервером слабких експортних шифрів (512 біт RSA). Зловмисник підміняє запит клієнта з переліком підтримуємих шифрів і залишає в ньому лише експортні. TLS 1.3 заборонив експортні шифри, і не вразливий. Атака цілком практична на ранішні версії TLS.
Logjam - схожа на FREAK, лише зловмисник ламає не експортний RSA, а DH обмін ключами (512 біт). Наслідки обтяжуються тим, що використовуються популярні параметри груп DH. Якщо завчасно обчислити необхідні для зламу значення, то експоненти (секрети серверу та та клієнту TLS) можна ламати за хвилину (а зараз ще менше), і це в межах тривалості TCP з”єднання TLS сесії.
ECHE/DHE перемішування. Принаймні TLS 1.2 може невірно інтерпретувати значення EDHE обміну ключами, як значення DHE. Відповідно параметри DHE будуть слабкими, і можливе відновлення спільного ключа. Ймовірність доволі низька (треба зробити біля 2^32 мережевих з”єднань щоб це спрацювало). Виглядає малопрактичною.
Raccoon. TLS 1.2 та більш ранні версії вимагають, щоб нулі на початку премастер секрету (premaster secret) були відкинуті. Це впливає на час розрахунку спільного ключа за допомогою геш функції. Знаючи значення першого біту g^a та відправляючи модифіковані версії g^(a+ri) і вимірюючи їх старші біти зловмисник може вирішити математичну задачу і віднайти g^a . Атака малопрактична, але все одно виправлена в TLS 1.3
Потрійне рукостискання (Tripple handshake). TLS 1.2 (та певне більш ранні версії) вразливі до атаки “потрійного рукостискання”. Атакуючий вимагає клієнта аутентифікуватись за допомогою клієнтського сертифікату, але пересилає ці дані на сервер жертву і таким чином аутентифікується там як клієнт. TLS 1.3 виправив цю проблему.
Використовуючи стиснення TLS можна знаходити які файли з серверу завантажує жертва (знаючи розміри цих файлів). TLS 1.3 виправив цю проблему.
SWEET32 - атака на шифри з розміром блоку 64 біти. Завдяки парадоксу дня народження досить зібрати 2^32 блоків щоб винайти колізію між ними. А в режимі CBC це дозволяє знайти XOR двох блоків відкритого тексту. Якщо ми знаємо перший блок з даними (Cookie: sessionid=) то можемо знайти і другий (сам секретний кукі). Атака цілком практична (через iframe + JavaScript). TLS 1.3 поборов цю проблему прибравши шифри з коротким блоком (3DES/Blowfish).
SLOTH, використовує той факт, що протокол TLS1.2 дозволяє обирати механізм аутентифікації клієнт (а саме геш функцію MD5 як частину цього механізму). Досить 2^39 операцій щоб підібрати колізію (геш від всіх попередніх повідомлень, що надіслані під час TLS рукостискання), і додати до неї цифровий підпис клієнта, щоб імперсоніфікувати його. Практичний час для виконання атаки кілька годин при доволі малому бюджеті. Атака практична, виправлена в TLS 1.3.
CurveSwap В TLS1.2 та більш ранніх версіях перелік підтримуємих еліптичних кривих впродовж TLS рукостискання не аутентифікується до фінального повідомлення. Тому атакуючий, може вставити власну слабку криву, і під час обміну даними вирахувати дискретний логарифм одного з параметрів DH і відновити мастер ключ (і підробити фінальне повідомлення). Найменш слабка крива - sect163k була знайдена у 0.1 відсотка найбільших сайтів. Також реалізації еліптичних кривих мають перевіряти, що точки обрані клієнтом під час EDCH відповідають певним властивостям, інакше можливий цілий ряд атак - передача точок, що не належать кривій (invalid point attack), визначення секрету через невірну реалізацію оптимізованих методів мультиплікації, вибір точок що є членами підгруп малого порядку, та інш.
HEIST - для довідки - це загальний фреймворк, що дозволяє визначати розмір відповіді серверу за кількість переданих TCP сегментів. Дуже схожа на атаку TIME, але більш універсальна.
SMACK, SKIP-TLS. Як виявилось деякі вразливі імплементації TLS (наприклад клієнтів), не повністю слідують специфікації протоколу і можуть продовжувати працювати якщо пропущені деякі обов'язкові повідомлення іншої сторони. Це дозволяє, наприклад, зловмиснику просто видалити (drop) повідомлення під час перехоплення і привести до нешифрованого з'єднання. В цілому, я би не вважав то багами якоїсь конкретної версії TLS. SMACK загальна назва атак на порушення порядку переходу між станами TLS з”єднання.
ROCA -через помилку в реалізації бібліотеки RSA (генерації простих чисел слабкого виду) в популярному продукті були затронуті чисельні ключі. Проблема пов'язана із сертифікатами, а не з механізмом обміну ключами, тому чіпляє всі версії TLS.
DUHK - ряд Fortinet пристроїв використовував старий генератор випадкових чисел, що ініціалізувався вбудованим в прошивку ключем. Витягнувши ключ з прошивки будь-якого пристрою можна було легко розшифрувати VPN трафік інших. Ця помилка не залежала від версії TLS.
DROWN - атака на TLS1.2 з використанням SSLv2 (якщо той вмикнений на сервері). Атакуючий за кілька десятків тисяч з'єднань із серверов може винайти спільний ключ шифрування сесії TLS 1.2 Використовується той факт, що навіть якщо атака Bleichenbacher на TLS1.2 “напряму” недієва (через відсутність оракулу), але SSLv2 з підтримкою експортних ключів може розшифровувати невеличку частинку від спільного ключа TLS1.2 і служити таким Bleichenbacher оракулом для зламу протоколу обміну ключами на базі RSA. Атака практична. TLS1.3 захищений від неї, бо не використовує RSA для обміну ключами. Але деякі роботи показують, що якщо сертифікат серверу використовується для протоколу TLS1.2 і нижче, то зловмисник може його використати як оракул для атаки на сесії TLS1.3.
BERserk - через помилку в реалізації перевірки PKCS#1.5 доповнення в RSA в бібліотеці Mozilla можливо було підробити підпис. Не залежить від версії TLS.
CREAM - атака з використанням особливостей кеш пам'яті комп'ютера та роботи AES. Надана лише заради цікавості, є ціла низка таких атак на реалізації TLS з використанням просто статистики доступу до пам'яті, часу на появу певних значень в кеші процесора, можливості вимірювати час доступу до кешу (FLUSH+RELOAD/clflush), PRIME/PROBE (за допомогою rdtsc). Spectre/Meltdown також підпадають в цю категорію.
ROBOT - реалізація старої атаки Bleichenbacher за рахунок відхилення від стандартного ходу TLS протоколу і виявлення нових оракулів (механізмів), що повідомляють про вірне чи не вірне значення PKCS#1.5 доповнення під час обміну ключами за допомогою RSA. TLS1.3 не використовує RSA для обміну ключами і не вразливий.
Bleichenbacher - стара атака 1998р., але яка була повернута то життя атакою ROBOT через помилки в закритті оригінальної атаки Bleichenbacher. Як відомо зловмисник що дізнається хоча б один біт відкритого тексту під час атаки обраного шифротексту може відновити згодом все повідомлення. Через недоліки перевірки PKCS#1.5 доповнення (padding) в реалізаціях TLS атакуючий може дізнатись чи вірний біт доповнення після розшифровки (00 02 чи щось інше). Під час перевірки старі реалізації TLS повідомляли про невірне доповнення і дозволяли вияснити десь за 2^20 == 1 млн. повідомлень оригінальний відкритий текст. TLS1.3 не використовує RSA для обміну ключами і не вразливий.
RC4NOMORE - атака використовує слабкість RC4. В ньому багато залежностей між байтами шифрованого тексту (вони не виглядають випадковими). Автори атаки використали більш старі атаки (що вимагали 500ГБ шифротексту - AlFardan et al./Isobe et al. атаки) але додали до них винайдені ними нові залежності (схожі на Mantin’s ABSAB у комбінації з Fluhrer-McGrew). Взагалі залежності вже відомі давно (Mantin and Shamir, Maitra et al., y Sen Gupta et al, Paul and Preneel), але не вважались практичними для зламу шифру. Атакуючий використовуючи iframe + JavaScript генерує біля 75ГБ трафіку, в якому скажімо, секретний cookie оточений вже відомим текстом. Враховуючи залежності між шифрованими байтами відомих шматків тексту можливо за лічені хвилини відновити невідомий фрагмент (cookie). Атака практична, TLS 1.3 повністю заборонив RC4.
Bar Mizvan атака на RC4. Використовує дослідження Invariance weaknes (властивості ключів, що зберігаються під час шифрування) FMS (S. R. Fluhrer, I. Mantin, and A. Shamir. Weaknesses in the key scheduling algorithm of RC4.). Найменш значимі біти шифротексту не випадкові, і це дозволяє викривати інформацію про байти відкритого тексту. Всього доступно до 100 байт тексту (якщо відкинути заголовки то 64), і всього 1 найменш значимий біт доступний для вгадування. При цьому треба зібрати великий обсяг повідомлень TLS щоб там знайшовся слабкий тимчасовий RC4 ключ. Відкидання бітів зменшує обсяг перебору (наприклад сесійних кукі). Наприклад для 16 значного кукі з ентропією 5 бітів на символ ця атака усуває 16 біт, і зменшує обсяг перебору з (2^80 до 2^64 ). В цілому виглядає не дуже практичною, але TLS1.3 заборонив RC4 і не вразливий.
CSS injection. Атака специфічна для реалізації OpenSSL, але для цікавості ми приводимо її тут також. Була винайдена під час формального моделювання TLS протоколу (для цього використовувалась мова ATS, але більш доречно згідно думки автора використати Coq). OpenSSL некоректно дозволяє змінити шифри сеансу вже після встановлення сесії (і використати слабкі шифри). TLS 1.3 заборонивши слабкі шифри усуває цей недолік.
Alert attack. TLS (як ми розуміємо 1.2 та більш рані версії) дозволяє ігнорувати помилки TLS протоколу за рахунок використання фрагментації повідомлень про помилки. Зловмисник відправляє фрагментовану помилку (цілісність якої протокол не перевіряє), і потім реальна помилка дописується в кінець і невірно інтерпретується. TLS1.3 як ми бачимо в RFC8446 забороняє фрагментацію повідомлень про помилки і не вразливий (5.1 та 6 розділи RFC).