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

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

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

Версії

TLS 1.3 TLS 1.3 був описаний в RFC 8446 у серпні 2018 року. Він базується на TLS 1.2. Новий дизайн покращує безпеку та ефективність за рахунок скороченої кількості раундів рукостискань, виключенню з протоколу застарілих небезпечних опцій та шифруванню більшої частини початкової стадії сесії, порівняно з TLS 1.2.

TLS 1.3 використовується за замовчуванням у браузерах Firefox (починаючи з версії 60.0) та Google Chrome (починаючи з версії 70). OpenSSL підтримує TLS 1.3, починаючи з версії 1.1.1.

Основні кроки

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

В цілому, процес рукостискання складається з таких основних кроків: Клієнт відправляє вітання (), в якому повідомляє серверу про підтримувану ним версію протоколу та список підтримуваних алгоритмів шифрування в порядку їх бажаності. Також це повідомлення має рядок випадкових байтів. Протокол дозволяє зазначати підтримувані клієнтом методи стиснення даних. У відповідь сервер відправляє власне вітання (), в якому називає вибраний ним шифр (CipherSuite) із запропонованого клієнтом переліку, ідентифікатор сеансу () та рядок випадкових байтів. Також сервер відправляє свій цифровий сертифікат. Якщо сервер потребує цифровий сертифікат клієнта для його автентифікації, то до відповіді додається відповідний запит () та перелік підтримуваних типів сертифікатів та унікальні імена (; DN) центрів сертифікації (; CA). Клієнт перевіряє (верифікує) отриманий цифровий сертифікат сервера. Клієнт відправляє у відповідь рядок випадкових байтів, зашифрований відкритим ключем сервера. Цей рядок необхідний для шифрування даних при подальшому обміні. Якщо сервер запитав сертифікат клієнта, то до відповіді додається рядок із випадковими байтами, який клієнт шифрує своїм приватним ключем, та цифровий сертифікат клієнта. Якщо клієнт не має сертифіката, то у відповідь відправляється відповідне попередження (). Якщо сервер налаштований на обов'язкову автентифікацію клієнтів, то на цьому процедура рукостискання може перерватись. Сервер перевіряє (верифікує) сертифікат клієнта. Клієнт відправляє повідомлення про успішне завершення рукостискання (). Сервер відправляє повідомлення про успішне завершення рукостискання, яке зашифроване таємним ключем. Тепер протягом сеансу клієнт та сервер можуть обмінюватись даними, зашифрованими спільним таємним ключем.

Алгоритми обміну/узгодження спільного ключа Перед тим, як розпочати захищений обмін інформацією, клієнт та сервер мають узгодити алгоритм шифрування та відповідний ключ. Це відбувається під час процедури «рукостикання» — відкриття сеансу зв'язку. Для цього завдання можуть бути використані такі алгоритми: криптографічна система RSA (позначення TLS_RSA під час «рукостискання»), Протокол Діффі-Геллмана (TLS_DH), короткочасні (ефемерні) ключі Діффі-Геллмана (TLS_DHE), Протокол Діффі-Геллмана на еліптичних кривих (TLS_ECDH), короткочасні ключі за протоколом Діффі-Геллмана на еліптичних кривих (TLS_ECDHE), анонімний протокол Діффі-Геллмана (TLS_DH_anon)RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2, попередньо узгоджений ключ (TLS_PSK) та Secure Remote Password (TLS_SRP).

Алгоритми TLS_DH_anon та TLS_ECDH_anon не автентифікують сервер та клієнт, і тому вони можуть бути вразливими до атаки типу «людина посередині», через що ними користуються не так часто. Лише алгоритми TLS_DHE та TLS_ECDHE пропонують пряму секретність.

Використані під час рукостискання сертифікати з відкритими ключами можуть мати різну довжину і тому різну стійкість до атак. У липні 2013 року Google повідомила про припинення використання ключів довжиною 1024 біт, натомість надалі компанія буде використовувати ключі довжиною 2048 біт .

+ Алгоритми обміну/узгодження спільного ключа Алгоритм SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3(проект) Стан Визначено для TLS 1.2 у відповідних RFC Визначено у

Цифрові сертифікати

Деякі сучасні криптографічні системи, включно з реалізаціями SSL/TLS для навігації в Інтернет, покладаються на інфраструктуру відкритих ключів (, PKI) з сертифікатами стандарту X.509. Інфраструктура відкритих ключів передбачає, що сторони в обміні даними покладаються на деякі центри сертифікації (, CA; також довірчий центр) для ідентифікації сервісів та вебсайтів. На центри сертифікації покладена надзвичайно велика відповідальність для запобігання, серед іншого, атак типу «людина посередині».

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

Технологія PKI полягає у використанні двох математично пов'язаних цифрових ключів, що мають такі властивості: один ключ може бути використаний для шифрування повідомлення, що може бути розшифровано тільки за допомогою другого ключа; навіть якщо відомий один ключ, за допомогою обчислень практично неможливо визначити другий. Один із ключів відкритий для всіх, а другий має приватний характер і зберігається в захищеному місці. Ці ключі можуть бути використані для автентифікації чи шифрування цифрового підпису електронних даних.

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

Основними атрибутами сертифіката є ім'я та ідентифікатор суб'єкта, інформація про відкритий ключ суб'єкта, ім'я, ідентифікатор і цифровий підпис уповноваженого з видачі сертифікатів, серійний номер, версія і термін дії сертифіката, інформація про алгоритм підпису тощо. Важливо, що цифровий сертифікат містить цифровий підпис на основі секретного ключа довірчого центру.

Центр сертифікації ( — CA), або довірчий центр — об'єкт, уповноважений створювати, підписувати та публікувати сертифікати. Центр має також повноваження ідентифікувати користувачів. Основними операціями, що виконує довірчий центр, є видання, відновлення та анулювання сертифіката.

Дії Центру сертифікації обмежені політикою сертифікації, що диктує йому, яку інформацію він має вміщувати в сертифікат. Центр сертифікації публікує свою політику сертифікації в такий спосіб, щоб користувачі могли перевірити відповідність сертифікатів цій політиці.

Реалізації TLS (наприклад, веббраузери) мають списки центрів сертифікації яким вони довіряють. Інколи такі списки можуть складатись із понад ста центрів, яким браузер довіряє «беззастережно»: будь-який сертифікат, завірений таким центром, вважається дійсним без жодних додаткових умов. Таким чином, будь-який центр сертифікації зі списку веббраузера може підписувати сертифікати будь-яких вебсайтів, де би вони не знаходились.

Сучасні веббраузери також не зважають на зміну сертифікатів: якщо вебсайт мав сертифікат , виданий центром сертифікації , то веббраузер без жодних застережень прийме сертифікат виданий центром сертифікації , попри те, що такі зміни можуть служити свідченям несанкційованого перехоплення трафіку.

Центри сертифікації можуть бути додані до списку довірених центрів після подання публічної заяви про принципи роботи та проходження зовнішнього аудиту.

Відкликання сертифікатів Сертифікати можуть бути відкликані (анульовані) та визнані недійсними внаслідок компрометації секретного ключа чи зміни атрибутів сертифіката з моменту його випуску. Центри сертифікації може повідомити решту клієнтів про анулювання ключа, додавши його в список відкликаних сертифікатів (, CRL) або ж засобами мережевого протоколу статусу сертифікатів (, OCSP).

Значним недоліком списків анульованих сертифікатів є їхній потенційно великий розмір. Навіть з урахуванням сегментації та інших методів оптимізації розмір списків та деякі інші чинники роблять такий підхід незручним на практиці.

Натомість запит за протоколом OCSP дозволяють дізнатись статус окремого сертифікату. Однак, істотним недоліком є те, що таким чином клієнт повідомляє центр сертифікації про вебсайти, які він відвідує.

Проте, обидва методи залежать від роботи центру сертифікації — якщо за будь-яких причин клієнт не може отримати інформацію від центру сертифікації, тоді він постає перед двома незадовільними варіантами: або відмовитись приймати сертифікат сервера (тоді доступність вебсайтів може страждати від недоступності центру сертифікації), або ж прийняти сертифікат (під ризиком прийняти анульований сертифікат). Іншим недоліком другого варіанту є те, що він вразливий для атаки «людина посередині».

З огляду на зазначені проблеми деякі сучасні веббраузери не перевіряють статус сертифікату вебсайтів. Натомість, браузери Google Chrome та Firefox використовують технологію CRLsets та OneCRL відповідно. Ці списки включають лише анульовані сертифікати з високим пріоритетом, в першу чергу — сертифікати центрів сертифікації (довірчих центрів) різних рівнів.

Для розв'язання згаданих проблем була запропонована технологія , буквально — . Вона передбачає, що результат OCSP запиту на перевірку сертифіката сервера та підписаний відповідним центром сертифікації буде включений в заголовки відповіді на HTTP-запит. Також сертифікат сервера міститиме прапорець OCSP Must-Staple аби повідомити клієнта про необхідність перевірки відповідних даних.

Технологія прозорості сертифікатів (, CT) передбачає, що центри сертифікації будуть зобов'язані оприлюднювати всі завірені ними сертифікати. Завдяки цьому власники вебсайтів матимуть можливість дізнаватись про спроби зловмисників завірити «підроблені» сертифікати на їхні ресурси.

Технологія авторизації центрів сертифікації (, CAA) дозволяє власникам вебсайтів додавати інформацію про центр сертифікації в DNS-запис сайту. В такий спосіб клієнт буде поінформований, якому центру сертифікації довіряє певний вебсайт.

Аби зменшити потенційну шкоду від викрадення сертифікату сервера власники можуть подавати запити на сертифікати зі скороченим терміном дії (замість років — місяці або навіть десятки днів).

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