|
Transport Layer Security
TLS (англ. Transport Layer Security — захист на транспортному рівні), як і його попередник SSL — криптографічний протокол, що надає можливості безпечної передачі даних в інтернеті для навігації, отримання пошти, спілкування, обміну файлами, тощо. Використовує асиметричне шифрування і сертифікати X.509. ОписTLS надає можливості автентифікації і безпечної передачі даних через інтернет з використанням криптографічних засобів. Часто відбувається лише автентифікація сервера, а клієнт залишається неавтентифікованим. Для взаємної автентифікації кожна з сторін мусить підтримувати інфраструктуру відкритих ключів (PKI, англ. public key infrastructure), яка дозволяє захистити клієнт-серверні додатки від перехоплення, редагування повідомлень або ж створення підроблених. TLS включає три основні фази:
ВерсіїTLS 1.3TLS 1.3 був описаний в RFC 8446 [Архівовано 27 серпня 2018 у Wayback Machine.] у серпні 2018 року. Він базується на TLS 1.2. Новий дизайн покращує безпеку та ефективність за рахунок скороченої кількості раундів рукостискань, виключенню з протоколу застарілих небезпечних опцій та шифруванню більшої частини початкової стадії сессії, порівнянно з TLS 1.2. TLS 1.3 використовується за замовчунням в браузерах Firefox (починаючи з версії 60.0) та Google Chrome (починаючи з версії 70). OpenSSL підтримує TLS 1.3 починаючи з версії 1.1.1. Основні крокиВідкриття сеансу (рукостискання)Процедура рукостискання (англ. handshake) потрібна клієнту та серверу для створення та обміну таємним ключем, який буде використаний для шифрування переданих даних. Серед іншого, під час рукостискання сервер та клієнт:
В цілому, процес рукостискання складається з таких основних кроків:[1]
Алгоритми обміну/узгодження спільного ключаПеред тим, як розпочати захищений обмін інформацією, клієнт та сервер мають узгодити алгоритм шифрування та відповідний ключ. Це відбувається під час процедури «рукостикання» — відкриття сеансу зв'язку. Такі алгоритми можуть бути використані для цього завдання: криптографічна система RSA (позначення TLS_RSA під час «рукостискання»), Протокол Діффі-Геллмана (TLS_DH), короткочасні (ефемерні) ключі Діффі-Геллмана (TLS_DHE), Протокол Діффі-Геллмана на еліптичних кривих (TLS_ECDH), короткочасні ключі за протоколом Діффі-Геллмана на еліптичних кривих (TLS_ECDHE), анонімний протокол Діффі-Геллмана (TLS_DH_anon),[2] попередньо узгоджений ключ (TLS_PSK)[3] та Secure Remote Password (TLS_SRP)[4]. Алгоритми TLS_DH_anon та TLS_ECDH_anon не автентифікують сервер та клієнт, і тому вони можуть бути вразливими до атаки типу «людина посередині» через що ними користуються не так часто. Лише алгоритми TLS_DHE та TLS_ECDHE пропонують пряму секретність. Використані під час рукостискання сертифікати з відкритими ключами можуть мати різну довжину і тому різну стійкість до атак. В липні 2013 року Google повідомила про припинення використання ключів довжиною 1024 біт, натомість надалі компанія буде використовувати ключі довжиною 2048 біт[5].
Цифрові сертифікатиДеякі сучасні криптографічні системи, включно з реалізаціями SSL/TLS для навігації в Інтернет, покладаються на інфраструктуру відкритих ключів (англ. Public Key Infrastructure, PKI) з сертифікатами стандарту X.509. Інфраструктура відкритих ключів передбачає, що сторони в обміні даними покладаються на деякі центри сертифікації (англ. Certificate Authority, CA; також довірчий центр) для перевірки ідентичності сервісів та вебсайтів. На центри сертифікації покладена надзвичайно велика відповідальність для запобігання, серед іншого, атак типу «людина посередині»[8]. Інфраструктура відкритих ключів є інтегрованим комплексом методів та засобів (набір служб), призначених забезпечити впровадження та експлуатацію криптографічних систем із відкритими ключами[9]. Технологія PKI полягає у використанні двох математично пов'язаних цифрових ключів, що мають такі властивості:[9]
PKI служить не лише для створення цифрових сертифікатів, але і для зберігання великої кількості сертифікатів і ключів, забезпечення резервування і відновлення ключів, взаємної сертифікації, ведення списків анульованих сертифікатів і автоматичного відновлення ключів та сертифікатів після закінчення терміну їхньої дії[9]. Основними атрибутами сертифіката є ім'я та ідентифікатор суб'єкта, інформація про відкритий ключ суб'єкта, ім'я, ідентифікатор і цифровий підпис уповноваженого з видачі сертифікатів, серійний номер, версія і термін дії сертифіката, інформація про алгоритм підпису тощо. Важливо, що цифровий сертифікат містить цифровий підпис на основі секретного ключа довірчого центру[9]. Центр сертифікації (англ. Certificate Authority — CA), або довірчий центр — об'єкт, уповноважений створювати, підписувати та публікувати сертифікати. Центр має також повноваження ідентифікувати користувачів. Основними операціями, що виконує довірчий центр, є видання, відновлення та анулювання сертифіката[9]. Дії Центру сертифікації обмежені політикою сертифікації, що диктує йому, яку інформацію він має вміщувати в сертифікат. Центр сертифікації публікує свою політику сертифікації в такий спосіб, щоб користувачі могли перевірити відповідність сертифікатів цій політиці[9]. Реалізації TLS (наприклад, веббраузери) мають списки центрів сертифікації яким вони довіряють[10]. Інколи такі списки можуть складатись із понад ста центрів, яким браузер довіряє «беззастережно»: будь-який сертифікат, завірений таким центром, вважається дійсним без жодних додаткових умов. Таким чином, будь-який центр сертифікації зі списку веббраузера може підписувати сертифікати будь-яких веб сайтів, де би вони не знаходились[8]. Сучасні веббраузери також не зважають на зміну сертифікатів: якщо вебсайт А мав сертифікат К1, виданий центром сертифікації Ц1, то веббраузер без жодних застережень прийме сертифікат К2 виданий центром сертифікації Ц2, попри те, що такі зміни можуть служити свідченям несанкційованого перехоплення трафіку[8]. Центри сертифікації можуть бути додані до списку довірених центрів після подання публічної заяви про принципи роботи та проходження зовнішнього аудиту[8]. Відкликання сертифікатівСертифікати можуть бути відкликані (анульовані) та визнані недійсними внаслідок компрометації секретного ключа чи зміни атрибутів сертифіката з моменту його випуску. Центри сертифікації може повідомити решту клієнтів про анулювання ключа додавши його в список відкликаних сертифікатів (англ. Certificate Revocation List, CRL) або ж засобами мережевого протоколу статусу сертифікатів (англ. Online Certificate Status Protocol, OCSP)[11]. Значним недоліком списків анульованих сертифікатів є їхній потенційно великий розмір. Навіть з урахуванням сегментації та інших методів оптимізації розмір списків та деякі інші чинники роблять такий підхід незручним на практиці[11]. Натомість запит за протоколом OCSP дозволяють дізнатись статус окремого сертифікату. Однак, істотним недоліком є те, що таким чином клієнт повідомляє центр сертифікації про вебсайти, які він відвідує[11]. Проте, обидва методи залежать від роботи центру сертифікації — якщо за будь-яких причин клієнт не може отримати інформацію від центру сертифікації, тоді він постає перед двома незадовільними варіантами: або відмовитись приймати сертифікат сервера (тоді доступність вебсайтів може страждати від недоступності центру сертифікації), або ж прийняти сертифікат (під ризиком прийняти анульований сертифікат). Іншим недоліком другого варіанту є те, що він вразливий для атаки «людина посередині»[11]. З огляду на зазначені проблеми деякі сучасні веббраузери не перевіряють статус сертифікату вебсайтів. Натомість, браузери Chrome та Firefox використовують технологію CRLsets та OneCRL відповідно. Ці списки включають лише анульовані сертифікати з високим пріоритетом, в першу чергу — сертифікати центрів сертифікації (довірчих центрів) різних рівнів[11]. Для розв'язання згаданих проблем була запропонована технологія англ. OCSP stapling, буквально — укр. скріплення мережевим протоколом статусу сертифікатів. Вона передбачає, що результат OCSP запиту на перевірку сертифіката сервера та підписаний відповідним центром сертифікації буде включений в заголовки відповіді на HTTP-запит. Також сертифікат сервера міститиме прапорець OCSP Must-Staple аби повідомити клієнта про необхідність перевірки відповідних даних[11]. Технологія прозорості сертифікатів (англ. Certificate Transparency, CT) передбачає, що центри сертифікації будуть зобов'язані оприлюднювати всі завірені ними сертифікати. Завдяки цьому власники вебсайтів матимуть можливість дізнаватись про спроби зловмисників завірити «підроблені» сертифікати на їхні ресурси[11]. Технологія авторизації центрів сертифікації (англ. Certificate Authority Authorisation, CAA) дозволяє власникам вебсайтів додавати інформацію про центр сертифікації в DNS-запис сайту. В такий спосіб клієнт буде поінформований якому центру сертифікації довіряє певний вебсайт[11]. Аби зменшити потенційну шкоду від викрадення сертифікату сервера власники можуть подавати запити на сертифікати зі скороченим терміном дії (замість років — місяці або навіть десятки днів)[11]. Використані алгоритмиМожуть бути доступні такі алгоритми:
Алгоритми можуть доповнюватися в залежності від версії протоколу. Було доведено, що сучасні атаки на RC4 дозволяють зламати його протягом декількох днів або навіть годин. Тому в лютому 2015 року Internet Engineering Task Force (IETF) запропонувала в документі RFC 7465 припинити застосування RC4 в протоколі та реалізаціях TLS[12]. В серпні 2016 року в оновленні KB3151631 компанія Microsoft заявила, що припиняє використання RC4 в інтернет-браузерах починаючи з Internet Explorer 11 та Microsoft Edge[13]. Атаки проти TLS/SSLЗа час використання протоколів TLS/SSL було виявлено низку важливих атак як проти реалізацій (таких як бібліотека OpenSSL) так і використаних в ньому алгоритмів. В лютому 2015 року IETF оприлюднив «інформаційний» RFC 7457 з оглядом відомих на той час атак проти TLS/SSL[14]. В 2016 році група науковців оприлюднила результати дослідження налаштувань HTTPS/TLS у найпопулярніших вебсерверів на той час (Alexa Top Million). Вони встановили, що заради поліпшення швидкодії деякі адміністратори налаштували сервери для підтримки слабшого захисту, який, теоретично, мав поліпшити швидкість обробки запитів. Дослідникам вдалось виявити численні випадки повторного використання секретних значень в алгоритмах DHE та ECDHE, відновлення сеансів TLS, та квитків сеансів TLS. Через це істотно погіршується пряма секретність: до 24 години трафіку 38 % досліджених серверів може бути дешифровано у випадку компрометації сервера, іще у 10 % серверів цей термін становить 30 діб, незалежно від обраного набору шифрів. Через спільне збереження таємних значень TLS та стану сеансів між різними вебдоменами у деяких випадків викрадення єдиного таємного значення може бути достатнім для компрометації десятків тисяч вебсайтів[15]. Застарілі версії протоколуВ березні 2018 року Apple, Google, Microsoft та Mozilla повідомили про рішення припинити з 2020 року підтримку протоколів TLS 1.0 та TLS 1.1 у своїх веббраузерах (Safari, Chrome, Microsoft Edge, Internet Explorer та Firefox). За даними заявників, переважна частина вебсайтів уже використовує протоколи TLS версії 1.2 та 1.3, і лише близько 1 % використовують застарілі версії 1.0 та 1.1[16][17][18][19]. В березні 2020 року розробники Mozilla Firefox були вимушені повернути підтримку TLS 1.0/1.1 в браузер версії 74. Це рішення було спричинено потребою доступу до інформації на деяких вебсайтах уряду США про перебіг коронавірусної хвороби 2019 року[20]. За даними компанії Netcraft, станом на березень 2020 року, близько 850 тисяч вебсайтів працювали з протоколами TLS версій 1.0 та 1.1[20]. На початку вересня 2023 року, корпорація Microsoft нагадала користувачам, що незахищені протоколи безпеки транспортного рівня TLS 1.0/1.1 незабаром будуть вимкнені в нових випусках Windows. Було заявлено, що початкова специфікація TLS 1.0 і її наступник TLS 1.1 використовувалися протягом майже двох десятиліть, причому TLS 1.0 спочатку було представлено в 1999 році, а TLS 1.1 у 2006 році. Після широких обговорень і розробки 28 чернеток протоколів, інженерна робоча група Інтернету (IETF) у березні 2018 року схвалила наступну основну версію протоколу TLS, а саме TLS 1.3. Таким чином, згідно повідомлення Microsoft, у збірках Windows 11 Insider Preview, починаючи з вересня 2023 року, TLS версії 1.0 і 1.1 буде вимкнено за замовчуванням. Існує можливість повторно ввімкнути TLS 1.0 або TLS 1.1 для користувачів, яким потрібно підтримувати сумісність[21]. Примітки
Див. також
Посилання
Основні стандартиПоточна чинна версія протоколу TLS — версія 1.2, яка визначена в документі:
Чинним стандартом були визнані застарілими та недійсними попередні стандарти:
А також проекти стандартів SSL 2.0 та 3.0, які слід вважати недійсними:
РозширенняІнші документи RFC (запити коментарів) якими були розширені протоколи TLS. Розширення протоколу TLS версії 1.0:
Розширення протоколу TLS версії 1.1:
Розширення протоколу TLS версії 1.2:
Серед можливих використань TLS в інших протоколах:
Довідкові документи
|
