Transport Layer Security

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

TLS (англ. Transport Layer Security — захист на транспортному рівні), як і його попередник SSL — криптографічний протокол, що надає можливості безпечної передачі даних в Інтернет для навігації, отримання пошти, спілкування та передачі інших даних. Використовує асиметричне шифрування і сертифікати X.509. Існують незначні відмінності між TLS та SSL, але, в основі, протокол той самий.

Опис[ред.ред. код]

TLS надає можливості автентифікації і безпечної передачі даних через Інтернет з використанням криптографічних засобів. Часто відбувається лише автентифікація сервера, а клієнт залишається неавтентифікованим. Для взаємної автентифікації кожна з сторін мусить підтримувати інфраструктуру відкритого ключа (PKI), яка дозволяє захистити клієнт-серверні додатки від перехоплення, редагування повідомлень або ж створення підроблених.

SSL включає три основні фази:

Основні кроки[ред.ред. код]

Відкриття сеансу (рукостискання)[ред.ред. код]

Процедура рукостискання (англ. handshake) потрібна клієнту та серверу для створення та обміну таємним ключем, який буде використаний для шифрування переданих даних. Серед іншого, під час рукостискання сервер та клієнт:

  • Погоджують версію протоколу, якою вони користуватимуться.
  • Обирають криптографічні алгоритми.
  • Автентифікують один-одного із використанням цифрових підписів (цифрових сертифікатів).
  • Використовують асиметричні алгоритми для створення спільного таємного ключа. Спільний ключ потім служить для шифрування даних симетричними алгоритмами. Перевага симетричних алгоритмів шифрування перед асиметричними, в цьому випадку, — вища швидкодія[1].

В цілому, процес рукостискання складається з таких основних кроків:[1]

  1. Клієнт відправляє вітання (англ. client hello) в якому повідомляє сервер про підтримувану ним версію протоколу та список підтримуваних алгоритмів шифрування в порядку їх бажаності. Також це повідомлення має рядок випадкових байтів. Протокол дозволяє зазначати підтримувані клієнтом методи стиснення даних.
  2. У відповідь сервер відправляє власне вітання (англ. server hello), в якому називає вибраний ним шифр (CipherSuite) із запропонованого клієнтом переліку, ідентифікатор сеансу (англ. session ID) та рядок випадкових байтів. Також сервер віправляє свій цифровий сертифікат. Якщо сервер потребує цифровий сертифікат клієнта для його автентифікації, то до відповіді додається відповідний запит (англ. client certificate request) та перелік підтримуваних типів сертифікатів та унікальні імена (англ. Distinguished Name; DN) центрів сертифікації (англ. Certification Authority; CA).
  3. Клієнт перевіряє (верифікує) отриманий цифровий сертифікат сервера.
  4. Клієнт відправляє у відповідь рядок випадкових байтів зашифровану відкритим ключем сервера. Цей рядок необхідний для шифрування даних при подальшому обміні.
  5. Якщо сервер запитав сертифікат клієнта, то до відповіді додається рядок з випадковими байтами, який клієнт шифірує своїм приватним ключем, та цифровий сертифікат клієнта. Якщо клієнт не має сертифіката, то у відповідь відправляється відповідне попередження (англ. no digital certificate alert). Якщо сервер налаштований на обов'язкову автентифікацію клієнтів, то на цьому процедура рукостискання може перерватись.
  6. Сервер перевіряє (верифікує) сертифікат клієнта.
  7. Клієнт відправляє повідомлення про успішне завершення рукостискання (англ. finished).
  8. Сервер відправляє повідомлення про успішне завершення рукостискання, яке зашифроване таємним ключем.
  9. Тепер протягом сеансу клієнт та сервер можуть обмінюватись даними, зашифрованими спільним таємним ключем.

Алгоритми обміну/узгодження спільного ключа[ред.ред. код]

Перед тим, як розпочати захищений обмін інформацією, клієнт та сервер мають узгодити алгоритм шифрування та відповідний ключ. Це відбувається під час процедури «рукостикання» — відкриття сеансу зв'язку. Такі алгоритми можуть бути використані для цього завдання: криптографічна система 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 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
(проект)
Стан
RSA Так Так Так Так Так Ні Визначено для TLS 1.2 у відповідних RFC
DH-RSA Ні Так Так Так Так Ні
DHE-RSA (пряма таємність) Ні Так Так Так Так Так
ECDH-RSA Ні Ні Так Так Так Ні
ECDHE-RSA (пряма таємність) Ні Ні Так Так Так Так
DH-DSS Ні Так Так Так Так Ні
DHE-DSS (пряма таємність) Ні Так Так Так Так Ні[6]
ECDH-ECDSA Ні Ні Так Так Так Ні
ECDHE-ECDSA (пряма таємність) Ні Ні Так Так Так Так
PSK Ні Ні Так Так Так
PSK-RSA Ні Ні Так Так Так
DHE-PSK (пряма таємність) Ні Ні Так Так Так
ECDHE-PSK (пряма таємність) Ні Ні Так Так Так
SRP Ні Ні Так Так Так
SRP-DSS Ні Ні Так Так Так
SRP-RSA Ні Ні Так Так Так
Kerberos Ні Ні Так Так Так
DH-ANON (insecure) No Yes Yes Yes Yes
ECDH-ANON (небезпечно) No No Yes Yes Yes
ГОСТ Р 34.10-94/34.10-2001[7] Ні Ні Так Так Так Запропоновано в проектах наступних RFC

Цифрові сертифікати[ред.ред. код]

Деякі сучасні криптографічні системи, включно з реалізаціями 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].

Використані алгоритми[ред.ред. код]

Можуть бути доступні такі алгоритми:

  • Для обміну ключами і перевірки їх справжності використовують комбінації алгоритмів: RSA (асиметричний шифр), Diffie-Hellman (безпечний обмін ключами), DSA (алгоритм цифрового підпису) і алгоритми технології Fortezza.
  • Для симетричного шифрування: RC2, RC4, IDEA, DES, Triple DES або AES;
  • Для хеш-функцій: MD5 або SHA.

Алгоритми можуть доповнюватися в залежності від версії протоколу.

Було доведено, що сучасні атаки на 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].

Примітки[ред.ред. код]

  1. а б An overview of the SSL or TLS handshake. IBM Knowledge Center. 12 December 2016. 
  2. RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
  3. P. Eronen, Ed. RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. Процитовано 9 September 2013. 
  4. D. Taylor, Ed. RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication. Internet Engineering Task Force. Процитовано December 21, 2014. 
  5. Gothard, Peter. Google updates SSL certificates to 2048-bit encryption. Computing. Incisive Media. Процитовано 9 September 2013. 
  6. Sean Turner (September 17, 2015). Consensus: remove DSA from TLS 1.3. 
  7. а б в г New Research Suggests That Governments May Fake SSL Certificates. EFF. 2010-03-24. 
  8. а б в г д е Гончарова Л. Л., Возненко А. Д., Стасюк О. І., Коваль Ю. О. (2013). 4.5. Алгоритми з використанням ключів. Основи захисту інформації в телекомунікаційних та комп'ютерних мережах. Державний економіко-технологічний університет транспорту. 
  9. Rea, Scott (2013). Alternatives to Certification Authorities for a Secure Web. RSA Conference Asia Pacific. Процитовано 7 September 2016. 
  10. а б в г д е ж и к Scott Helme (July 03, 2017). Revocation is broken. 
  11. Andrei Popov (February 2015). RFC 7465. Prohibiting RC4 Cipher Suites. Internet Engineering Task Force. 
  12. Mark Coppock (Aug 9, 2016). Microsoft deprecates RC4 in both Internet Explorer 11 and Edge. WinBeta. 
  13. RFC 7457 : Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). 

Див. також[ред.ред. код]

Програмне забезпечення
  • OpenSSL: реалізація з відкритим кодом (ліцензія BSD)
  • GnuTLS: реалізація з відкритим кодом
  • JSSE: реалізація на Java, входить до складу стандартної платформи Java
  • Network Security Services (NSS): бібліотека з відкритими кодами, сертифікована FIPS 140

Посилання[ред.ред. код]

Основні стандарти[ред.ред. код]

Поточна чинна версія протоколу TLS — версія 1.2, яка визначена в документі:

  • RFC 5246: «The Transport Layer Security (TLS) Protocol Version 1.2».

Чинним стандартом були визнані застарілими та недійсними попередні стандарти:

  • RFC 2246: «The TLS Protocol Version 1.0».
  • RFC 4346: «The Transport Layer Security (TLS) Protocol Version 1.1».

А також проекти стандартів SSL 2.0 та 3.0, які слід вважати недійсними:

Розширення[ред.ред. код]

Інші документи RFC (запити коментарів) якими були розширені протоколи TLS.

Розширення протоколу TLS версії 1.0:

  • RFC 2595: «Using TLS with IMAP, POP3 and ACAP»
    Описує розширення протоколів IMAP, POP3 та ACAP завдяки яким клієнт та сервер можуть захищено пересилати дані та проводити автентифікацію через відкриті мережі Інтернет.
  • RFC 2712: «Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)»
    Описані в цьому документі алгоритми шифрування з ключем 40-біт для фіксації того факту, що ними вже зайняті відповідні коди.
  • RFC 2817: «Upgrading to TLS Within HTTP/1.1»
    Описує механізм використання алгоритму підвищення в HTTP/1.1 для переходу до передачі даних за протоколом TLS через добре відомий порт (в цьому випадку, дозволяє розпочати захищену передачу даних при під'єднанні до порту 80 замість звичного 443).
  • RFC 2818: «HTTP Over TLS»
    Розрізняє захищений та незахищений обмін даними в залежності від використаного порту на сервері.
  • RFC 3207: «SMTP Service Extension for Secure SMTP over Transport Layer Security»
    Описує розширення протоколу SMTP завдяки якому сервер та клієнт можуть мати захищений канал для передачі даних на транспортному рівні.
  • RFC 3268: «AES Ciphersuites for TLS»
    Додає шифри Advanced Encryption Standard (AES) до переліку підтримуваних симетричних алгоритмів шифрування.
  • RFC 3546: «Transport Layer Security (TLS) Extensions»
    Додає механізм погодження розширень протоколу під час процедури рукостискання. Також описує низку розширень до протоколу. Замінений стандартом RFC 4366.
  • RFC 3749: «Transport Layer Security Protocol Compression Methods»
    Описує загальні методи для стиснення даних в протоколі та описує алгоритм DEFLATE.
  • RFC 3943: «Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)».
  • RFC 4132: «Addition of Camellia Cipher Suites to Transport Layer Security (TLS)».
  • RFC 4162: «Addition of SEED Cipher Suites to Transport Layer Security (TLS)».
  • RFC 4217: «Securing FTP with TLS»
    Описує стандарт для створення захищених каналів передачі даних з прикладним протоколом FTP
  • RFC 4279: «Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)»
    Додає підтримку нових криптографічних алгоритмів, в тому числі — алгоритмів шифрування спільними ключами.

Розширення протоколу TLS версії 1.1:

  • RFC 4347: «Datagram Transport Layer Security»
    Описує варіант TLS для роботи з протоколами датаграм (наприклад, UDP).
  • RFC 4366: «Transport Layer Security (TLS) Extensions»
    Описує деякі розширення а також загальний магазин впровадження розширень в протокол.
  • RFC 4492: «Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)».
  • RFC 4680: «TLS Handshake Message for Supplemental Data».
  • RFC 4681: «TLS User Mapping Extension».
  • RFC 4785: «Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)».
  • RFC 5054: «Using the Secure Remote Password (SRP) Protocol for TLS Authentication»
    Описує набори шифрів TLS-SRP.
  • RFC 5077: «Transport Layer Security (TLS) Session Resumption without Server-Side State».
  • RFC 5081: «Using OpenPGP Keys for Transport Layer Security (TLS) Authentication»
    Визнаний недійсним стандартом RFC 6091.

Розширення протоколу TLS версії 1.2:

  • RFC 5288: «AES Galois Counter Mode (GCM) Cipher Suites for TLS».
  • RFC 5289: «TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)».
  • RFC 5746: «Transport Layer Security (TLS) Renegotiation Indication Extension».
  • RFC 5878: «Transport Layer Security (TLS) Authorization Extensions».
  • RFC 5932: «Camellia Cipher Suites for TLS»
  • RFC 6066: «Transport Layer Security (TLS) Extensions: Extension Definitions»
    Описує розширення протоколу Server Name Indication та OCSP stapling.
  • RFC 6091: «Using OpenPGP Keys for Transport Layer Security (TLS) Authentication».
  • RFC 6176: «Prohibiting Secure Sockets Layer (SSL) Version 2.0».
  • RFC 6209: «Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)».
  • RFC 6347: «Datagram Transport Layer Security Version 1.2».
  • RFC 6367: «Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)».
  • RFC 6460: «Suite B Profile for Transport Layer Security (TLS)».
  • RFC 6655: «AES-CCM Cipher Suites for Transport Layer Security (TLS)».
  • RFC 7027: «Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)».
  • RFC 7251: «AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS».
  • RFC 7301: «Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension».
  • RFC 7366: «Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)».
  • RFC 7465: «Prohibiting RC4 Cipher Suites».
    Про заборону клієнтам та серверам використання алгоритму RC4 під час рукостискання
  • RFC 7507: «TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks».
  • RFC 7568: «Deprecating Secure Sockets Layer Version 3.0».
  • RFC 7627: «Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension».
  • RFC 7685: «A Transport Layer Security (TLS) ClientHello Padding Extension».

Серед можливих використань TLS в інших протоколах:

  • RFC 5216: «The EAP-TLS Authentication Protocol»
    Описує використання TLS в реалізації розширюваного протоколу автентифікації (EAP)

Довідкові документи[ред.ред. код]

  • RFC 7457: «Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)»
    Випущений в лютому 2015 року огляд відомих методів атаки на протоколи TLS та їхні реалізації
  • RFC 7525: «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)»
    Випущені в травні 2015 року загальні поради з налаштування та використання реалізацій TLS, вибору криптографічних алгоритмів, тощо