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

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

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

• Діалог між сторонами, метою якого є вибір алгоритму шифрування.
• Обмін ключами на основі криптосистем з відкритим ключем або ж автентифікація на основі сертифікатів.
• Передача даних, що шифруються за допомогою симетричних алгоритмів шифрування

TLS 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].

В цілому, процес рукостискання складається з таких основних кроків:^[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/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 було виявлено низку важливих атак як проти реалізацій (таких як бібліотека 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].

• SSL
• Асиметричні алгоритми шифрування

Програмне забезпечення

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

• Робоча група TLS [Архівовано 4 квітня 2017 у Wayback Machine.] на сайті IETF

Поточна чинна версія протоколу 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, які слід вважати недійсними:

• Internet Draft (1995), SSL Version 2.0
• RFC 6101: «The Secure Sockets Layer (SSL) Protocol Version 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, вибору криптографічних алгоритмів, тощо