SSLTLS - стан справ Dipl-Inform
Інформація про ІТ-безпеку
SSL/TLS - Сучасний рівень
Яка ситуація зараз із безпекою SSL/TLS? Минув деякий час з часу останньої статті на цю тему, і є кілька нових розробок.
Алгоритм RC4 стає проблемою
Остання атака була опублікована на початку березня 2013 року: Надхем Алфардан, Ден Бернштейн, Кенні Патерсон, Бертрам Поеттерінг та Якоб Шульдт довели, що алгоритм RC4, що використовується для шифрування, може бути частково зламаний, щоб можна було ідентифікувати частини відкритого тексту. Напад отримав ідентифікатор CVE CVE-2013-2566.
Зокрема, в даний час атаку можна використовувати для атаки перших 256 байт потоку відкритого тексту. Оскільки перші 36 байтів складаються з непередбачуваного повідомлення від найбільш часто використовуваного хеш-алгоритму SHA-1, їх неможливо визначити. Отже, 220 байт зашифрованого тексту можна ефективно розшифрувати. Для цього потрібно приблизно 2 30 сеансів; з приблизно 2 24 сеансами певні байти вже можна надійно розшифрувати.
Це звучить як багато, і це так. Принаймні на даний момент така атака малоймовірна, тим більше, що її спочатку потрібно було б адаптувати, щоб надати дані, що цікавлять зловмисника. Наприклад, код JavaScript, введений на веб-сайт, може неодноразово викликати одну і ту ж URL-адресу HTTPS і використовувати його для дешифрування файлу cookie сеансу. Але це лише теоретичні міркування, практичного впровадження ще не було.
Контрзаходи
Потоковий шифр RC4 останнім часом дуже часто використовується для TLS. Головним чином тому, що його можна швидко розрахувати і є (тепер уже не) безпечною альтернативою режиму CBC для SSL/TLS, якому загрожують атаки BEAST та Lucky13 (про це далі). Тим часом, однак, режим CBC захищений від BEAST і Lucky13, так що тепер він може служити альтернативою RC4. Якщо ви використовуєте відповідну виправлену реалізацію TLS 1.0 або 1.1, ви можете використовувати режим CBC замість RC4 для шифрування.
Іншою альтернативою є алгоритми AEAD, запроваджені з TLS 1.2. Атака на RC4 може призвести до поширення TLS 1.2. У довгостроковій перспективі це найкраще рішення.
Теоретично TLS може змінити використання RC4, наприклад, відкинувши початок потоку ключів RC4. На практиці, однак, такий підхід марний, оскільки він захищає лише від реалізованої в даний час атаки, але не від можливих нових та подальших розробок. Не кажучи вже про те, що немає можливості домовитись про таку відмову в рамках протоколу TLS, тому необхідні значні зміни до реалізації TLS на клієнтах і серверах.
Те саме стосується змін у браузері, які можуть зробити атаку менш ефективною.
TLS і Lucky 13
На початку лютого 2013 року Надхем АльФардан і Кенні Патерсон опублікували атаку на CBC-шифрування TLS і DTLS (Datagram Transport Layer Security) під назвою "Lucky Thirteen". Нападу було надано ідентифікатор CVE CVE-2013-0169.
Атака використовує помилку в специфікації TLS і була успішно протестована проти OpenSSL та GnuTLS. У випадку OpenSSL можна було визначити весь звичайний текст, використовуючи GnuTLS принаймні його частини (точніше: 4 біти останнього байта кожного простого текстового блоку).
Надхем АльФардан та Кенні Патерсон користуються тим, що обчислення коду автентифікації повідомлень (MAC), за допомогою якого звичайний текст захищений від невизначених маніпуляцій, займає різну довжину для певної довжини повідомлення. Це дозволяє розрізнити повідомлення з принаймні двома правильними байтами заповнення (за допомогою яких блок заповнюється до відповідної довжини) та повідомленнями з одним правильним байтом або неправильно відформатованим заповненням.
Атаки - це багатосесійні атаки, тому бажаний звичайний текст повинен передаватися кілька разів в одну і ту ж точку потоку звичайного тексту за кілька сеансів TLS. Маніпулюючи зашифрованим текстом, згенерованим зловмисником, провокуються повідомлення про помилки, і невеликі різниці в часі між ними для різних маніпуляцій можуть бути використані для статистичного виведення простого тексту.
У найпростішому випадку, під час тестування в локальній мережі, повний блок зашифрованого TLS звичайного тексту може бути визначений приблизно через 2 32 сеансу TLS. якщо в якості алгоритму MAC використовувався HMAC-SHA1 (складність атаки залежить від використовуваного алгоритму MAC). Якщо відомо, що звичайний текст кодується Base64, достатньо 2 19 сеансів, якщо вже відомий один байт простого тексту в одній з останніх двох позицій блоку, достатньо навіть 2 13 сеансів.
Занадто багато сеансів для практичної атаки на TLS, особливо в Інтернеті, і різниця в часі, яку можна спостерігати, дуже мала. Однак тут також можливі атаки через маніпульовані веб-сайти. Однак DTLS вже можна атакувати, оскільки сеанс не припиняється негайно з першою помилкою.
Атаку назвали "Lucky 13", оскільки при обчисленні MAC використовується 13 байт заголовка, без яких атака була б неможливою. Хоча насправді 13 - це невдале число, принаймні для зловмисника тут це щасливе число.
Контрзаходи
Теоретично випадкові затримки можуть ускладнити синхронізацію атак, але це не працює на практиці, оскільки ці випадкові затримки також можна реєструвати статистично; збільшується лише кількість сеансів, необхідних для атаки.
Як альтернативу шифруванню CBC, RC4 запропонував себе. Бот, бо коли Lucky 13 був звільнений, атака проти RC4 ще не була відома. Тим часом краще уникати RC4, щоб виключити цю альтернативу.
Як і у випадку з RC4, можна перейти на один з алгоритмів AEAD, такий як AES-GCM.
І останнє, але не менш важливе, реалізація CBC TLS може бути адаптована таким чином, що синхронізація атак бічних каналів більше неможлива.
У більшості реалізацій TLS, таких як OpenSSL, NSS, GnuTLS, yaSSL та PolarSSL, зараз реалізовані контрзаходи проти атаки Lucky 13.
ЗЛОЧИН - наступник ЗВІРА
Розробники BEAST Джуліано Ріццо та Тайланд Дуонг представили нову атаку на SSL/TLS у вересні 2012 року на конференції з питань безпеки ecoparty 2012 під назвою "The CRIME Attack" (презентація у форматі PDF).
CRIME розшифровується як "C.стиснення Р.atio Яnfo-витік М.дупу E.експлоатація "(або". М.до побачення E.asy ") і дозволяє, наприклад, сеансові файли cookie розшифровуватись із з'єднання HTTPS. Передумовою успішної атаки є те, що
- зловмисник може спостерігати за мережевим трафіком жертви, наприклад, тому що вони обидва використовують спільну відкриту WLAN та
- жертва відвідує шкідливий або належним чином підготовлений веб-сайт. Потім зловмисник використовує його для введення коду JavaScript у браузер жертви, яка здійснила атаку.
Звичайно, і те, і інше особливо вірно, якщо зловмисник може діяти як людина посередині.
Крім того, клієнт і сервер повинні використовувати стиснення, таке як стискання TLS із стисканням або стиснення на рівні програми, таке як SPDY.
Потім зловмисник може спостерігати за тривалістю переданих запитів і, вміло маніпулюючи відправленими даними, розшифровувати або, краще вгадувати, їх частини. Якщо частини запиту, якими маніпулює зловмисник, збігаються, наприклад, файли cookie сеансу, довжина запиту відповідно зменшується. Таким чином, значення файлу cookie можна визначити поетапно. Відео демонструє напад.
Контрзаходи
Атаку CRIME можна запобігти, вимкнувши стиснення для з'єднань HTTPS. З тих пір веб-переглядачі були виправлені відповідним чином, якщо це впливає.
Висновок
Підводячи підсумок, можна сказати, що SSL/TLS як протокол далеко не мертвий, а з TLS 1.2 доступна нова захищена версія.
Це виглядає гірше із використаною системою сертифікації, занадто часто з’являються «підроблені» (краще: помилково видані) або інакше виникають проблемні сертифікати. Простіше кажучи: система сертифікації базується на довірі, і органи сертифікації раз за разом доводять, що не заслуговують на довіру. Тож на цьому етапі існує нагальна необхідність змін.
Трекбеки
Dipl.-Inform. Карстен Ейлерз у вівторок, 2 квітня 2013 р .: Новини про версії Java, пакети Android, руткіт та SSL/TLS
Dipl.-Inform. Карстен Ейлерз у вівторок, 14 квітня 2015 р .: SSL/TLS - знову погані новини!
Dipl.-інформувати. Карстен Ейлерс у середу, 13 травня 2015 року: Друковані видання: PHP Magazin 4.2015 - Підробка фальшивих запитів
Dipl.-Inform. Карстен Ейлерс у понеділок, 21 грудня 2015 р.: Нова електронна книга: "Веб-безпека - атаки з SSRF, CSRF та XML"
Бічна панель
Про мене.
Dipl.-інформувати. Карстен Ейлерз
Слідуй за мною.
Поточні записи
Категорії
календар
| ← Назад | Грудень '20 | |||||
| 1 | 2 | 3 | 4-й | 5 | 6-й | |
| 7-й | 8-й | 9 | 10 | 11 | 12-й | 13 |
| 14-е | 15-й | 16 | 17-й | 18-го | 19-го | 20-го |
| 21-го | 22-го | 23 | 24 | 25-й | 26-й | 27 |
| 28 | 29 | 30-й | 31 | |||
архів
Вас зламали!
Вас зламали!
Книга, 578 сторінок
Грудень 2018, Rheinwerk Computing
ISBN: 978-3-8362-4460-2
Також доступна як електронна книга
Безпека iOS
Безпека iOS
Книга, 274 сторінки
Січень 2014, developer.press
ISBN: 978-3-86802-101-1
Також доступний у форматі PDF та ePub-eBook
Веб-безпека
Веб-безпека
Електронна книга у форматі EPUB
Грудень 2015 р., Розробник.прес
ISBN: 978-3-86802-569-9
Безпека даних
Безпека даних
Електронна книга у форматі EPUB
Листопад 2015, developer.press
ISBN: 978-3-86802-568-2
Щорічний огляд веб-безпеки 2014
Щорічний огляд веб-безпеки 2014
Електронна книга у форматі EPUB
Березень 2015 р., Developer.press
ISBN: 978-3-86802-537-8
Безпека JavaScript
Безпека JavaScript
Електронна книга у форматі EPUB
Січень 2015, developer.press
ISBN: 978-3-86802-531-6
Цільовий інтерфейс
Цільовий інтерфейс
Електронна книга у форматі EPUB
Січень 2015, developer.press
ISBN: 978-3-86802-532-3
Безпека Android
Безпека Android
Електронна книга у форматі EPUB
Жовтень 2014, developer.press
ISBN: 978-3-86802-521-7
Шифрування у віці АНБ
Шифрування у вік АНБ
Електронна книга у форматі EPUB
Червень 2014, developer.press
ISBN: 978-3-86802-508-8
Захист HTML5
Захист HTML5
Електронна книга у форматі EPUB
Травень 2012, developer.press
ISBN: 978-3-86802-417-3
Працює на Serendipity & the 2k11-CE теми.