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

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

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

  • Для обміну ключами і перевірки їх справжності використовують комбінації алгоритмів: 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[8].

В серпні 2016 року в оновленні KB3151631 компанія Microsoft заявила, що припиняє використання RC4 в інтернет-браузерах починаючи з Internet Explorer 11 та Microsoft Edge[9].

Вразливості[ред.ред. код]

SSL 2.0[ред.ред. код]

SSL 2.0 мав низку вразливостей:[10]

  • Використання одного ключа для автентифікації повідомлень та шифрування даних. (Протокол SSL 3.0, дозволяє MAC секретам бути довшими за ключі для шифрування, тому секрет може залишатись захищеним навіть якщо буде зламано ключ для шифрування.[11])
  • SSL 2.0 має слабкий алгоритм обчислення MAC-підписів, що використовує хеш-функцію MD5 із таємним префіксом, що робить його вразливим до атаки подовженням повідомлення.
  • SSL 2.0 не має захисту процесу рукостискання (відкриття сеансу обміну даними), що робить його вразливим до атаки на пониження.
  • SSL 2.0 використовує стандартні механізми протоколу транспортного рівня TCP закриття з'єднання для позначення кінця даних. Це робить його вразливим до атаки на передчасне завершення передачі даних. Зловмисник може примусово обірвати з'єднання підробивши команду TCP FIN, отримувач даних тоді може не дізнатись про отримання неповних даних (у SSL 3.0 цю проблему виправлено — завершення сеансу відбувається явно, за відповідним повідомленням).
  • SSL 2.0 передбачає єдиний сертифікат для домену, що робить його несумісним з поширеною практикою віртуального хостингу веб серверів.

SSL 2.0 було вимкнено за замовченням починаючи з Internet Explorer 7,[12] Mozilla Firefox 2,[13] Opera 9.5,[14] та Safari. Якщо після відправлення повідомлення TLS «ClientHello» Mozilla Firefox виявляє, що сервер не здатний завершити рукостискання, то браузер спробує повернутись до використання SSL 3.0 надіславши повідомлення SSL 3.0 «ClientHello» у форматі SSL 2.0 аби збільшити ймовірність успішного завершення рукостискання зі старішими серверами.[15] Підтримка протоколу SSL 2.0 (та слабких 40- та 56- бітних шифрів) повністю прибрана з браузера Opera 10 версії.[16][17]

Атаки проти TLS/SSL[ред.ред. код]

Див. також: Хакерська атака

За час використання протоколів TLS/SSL було виявлено низку важливих атак як проти реалізацій (таких як бібліотека OpenSSL) так і використаних в ньому алгоритмів. В лютому 2015 року IETF оприлюднив «інформаційний» RFC 7457 з оглядом відомих на той час атак проти TLS/SSL[18].

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

  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. Andrei Popov (February 2015). RFC 7465. Prohibiting RC4 Cipher Suites. Internet Engineering Task Force. 
  8. Mark Coppock (Aug 9, 2016). Microsoft deprecates RC4 in both Internet Explorer 11 and Edge. WinBeta. 
  9. Joris Claessens; Valentin Dem; Danny De Cock; Bart Preneel; Joos Vandewalle (2002). On the Security of Today's Online Electronic Banking Systems. Computers & Security 21 (3). с. 253–265. doi:10.1016/S0167-4048(02)00312-7. 
  10. Помилка цитування: Неправильний виклик <ref>: для виносок RFC6101 не вказаний текст
  11. Lawrence, Eric (2005-10-22). IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2. MSDN Blogs. Процитовано 2007-11-25. 
  12. Bugzilla@Mozilla — Bug 236933 – Disable SSL2 and other weak ciphers. Mozilla Corporation. Процитовано 2007-11-25. 
  13. «Opera 9.5 for Windows Changelog» at Opera.com: «Disabled SSL v2 and weak ciphers.»
  14. Firefox still sends SSLv2 handshake even though the protocol is disabled. 2008-09-11. 
  15. «Opera 10 for Windows changelog» at Opera.com: «Removed support for SSL v2 and weak ciphers»
  16. Pettersen, Yngve (2007-04-30). 10 years of SSL in Opera — Implementer's notes. Opera Software. Архів оригіналу за October 12, 2007. Процитовано 2007-11-25. 
  17. 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

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