Що таке TLS і як він працює?

Безпека транспортного шару (TLS) – один з найважливіших і широко використовуваних протоколів безпеки. Він захищає значну частину даних, які передаються в Інтернеті. Це найвизначніше використовується для захисту даних, які пересуваються між веб-браузером та веб-сайтом через HTTPS, але він також може бути використаний для захисту електронної пошти та безлічі інших протоколів.

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

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

Що робить TLS?

Надсилаючи інформацію в Інтернеті, ми стикаємося з трьома основними проблемами безпеки:

• Як ми можемо знати, чи справді людина, з якою ми спілкуємось, є такою, якою вони кажуть?
• Як ми можемо знати, що дані не були підроблені з моменту надсилання?
• Як ми можемо завадити іншим людям бачити та отримувати доступ до даних?

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

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

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

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

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

Ключова фаза встановлення була б трохи схожа на те, якби ваш лист містив половину PIN-коду, який ви мали намір використовувати в майбутніх комунікаціях. Ви попросите свого одержувача придумати другу половину номера і надіслати його вам у своєму зворотному листі.

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

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

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

TLS вирішує всі три наші проблеми відносно подібним чином. Кур’єр служить для аутентифікації одержувача та переконання в тому, що коробка доставлена ​​її призначеній особі. Заблокована скринька служить формою шифрування, не даючи доступу до листів будь-кому, крім вашого партнера. Підписаний конверт дає змогу дізнатися, чи не було підроблено повідомлення.

Це дуже грубе наближення до того, що робить TLS. Насправді, TLS відбувається між клієнтами та серверами, а не двоє людей, які пересилають пошту один одному. Аналогія полягає лише в тому, щоб надати вам уявлення про те, що відбувається, і міркування щодо цього. У наступних розділах ми детально розповімо про те, що насправді відбувається.

TLS проти SSL

Читаючи про TLS, ви часто бачите згадки про SSL або навіть як TLS / SSL. Шар захищених сокетів (SSL) – це стара версія TLS, але багато хто в цій галузі все ще посилаються на TLS під старим інструментом. Ця стаття буде використовувати термін TLS протягом усього часу, але важливо зазначити, що імена часто використовуються як взаємозамінні. Ви можете прочитати більше про SSL в нашому посібнику.

Історія TLS

Все почалося з необхідності закріплення транспортного шару. Як ми вже згадували вище, попередником TLS був SSL. Перші версії SSL були розроблені в дев’яностих роках компанією Netscape, яка створила один з ранніх веб-браузерів.

SSL 1.0 ніколи не випускався, оскільки містив серйозні вразливості. Версія 2.0 вийшла з Netscape Navigator 1.1 в 1995 році, Однак він все ще містив ряд серйозних недоліків. SSL 3.0 був сильно переробленою версією, і вийшов у 1996 році, і було вирішено багато питань безпеки.

У 1996 році, IETF випустив проект SSL 3.0 в RFC 6101. IETF сформував робочу групу для стандартизації SSL, опублікувавши результати в 1999 році як TLS 1.0. Це було задокументовано в RFC 2246, і стандартизація включала деякі зміни в оригінальний протокол, а також зміна імені. Ці зміни відбулися в результаті переговорів між Netscape, Microsoft та робочою групою IETF.

У 2006 році IETF випустив RFC 4346, який документує TLS 1.1. Ця версія містила нові положення безпеки та ряд інших оновлень. Версія 1.2 була випущена лише через два роки у 2008 році. Вона включала підтримку аутентифікованих шифрувальних шифрів, ряд змін у використанні хеш-функцій та багато інших удосконалень..

Наступна версія надійшла до 2023 року, коли було визначено TLS 1.3. Він містить безліч змін, включаючи примусову таємницю вперед, усунення підтримки слабших алгоритмів та багато іншого.

TLS 1.0 та 1.1 тепер устарені в 2023 році, але версія 1.2 широко використовується. Версія 1.3 починає бачити посилене прийняття.

TLS: Технічні деталі

TLS складається з безлічі різних елементів. Основна частина – протокол запису, базовий протокол, відповідальний за загальну структуру всього іншого.

Діаграма, що показує стек TLS. Стек протоколу TLS від Jeffreytedjosukmono. Ліцензовано під CC0.

Протокол запису містить п’ять окремих підпротоколів, кожен з яких відформатований у вигляді записи:

• Рукостискання – Цей протокол використовується для встановлення параметрів безпечного з’єднання.
• Застосування – Протокол програми починається після процесу рукостискання, і саме там дані надійно передаються між двома сторонами.
• Сповіщення – Протокол попередження використовує будь-яка сторона під час з’єднання для сповіщення іншої, якщо є якісь помилки, проблеми зі стабільністю або потенційний компроміс.
• Змінити специфікацію шифру – Цей протокол використовується клієнтом або сервером для зміни параметрів шифрування. Це досить просто, тому ми не будемо детально висвітлювати це в цій статті.
• Серцебиття – Це розширення TLS, яке дозволяє одній стороні з’єднання знати, чи є його одноранговий живий, і не дозволяє брандмауерам закрити неактивні з’єднання. Це не основна частина TLS, тому ми пропустимо її в цьому посібнику.

Кожен з цих підпротоколів використовується на різних етапах для передачі різної інформації. Найважливіші з них, які слід зрозуміти, – це рукостискання та протоколи додатків, оскільки вони відповідають за встановлення з’єднання та надійну передачу даних..

Протокол рукостискання TLS

Тут з’єднання встановлюється надійним чином. Це може здатися складним, якщо ви новачок у деяких поняттях, але про кожне з них ми розповімо далі в статті, якщо вам потрібно посилатися на них.

Існує три основні типи рукостискання TLS: the базове рукостискання TLS, то аутентифікований клієнтом TLS рукостискання і скорочено рукостискання.

Основне рукостискання TLS

Діаграма, що показує процес рукостискання TLS. Повний TLS 1.2 рукостискання від FleshGrinder. Ліцензовано під CC0.

У цьому типі рукостискання аутентифіковано лише сервер, а не клієнт. Він починається з фази переговорів, куди клієнт відправляє Клієнт Привіт повідомлення. Він містить найвищу версію TLS, яку підтримує клієнт, можливі пакети шифрів, вказує, чи підтримує він стиснення, випадкове число та деяку іншу інформацію

Повідомлення Привіт Клієнта зустрічається з Привіт сервера повідомлення. Ця відповідь містить ідентифікатор сеансу, версію протоколу, набір шифрів та компресію (якщо така використовується), яку вибрав сервер зі списку клієнтів. Він також включає інше випадкове число.

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

Якщо використовуються ефемерні обміни ключів Diffie-Hellman або анонімні Diffie-Hellman, то після цього слід Обмін серверними ключами повідомлення. Інші ключові методи обміну пропускають цю частину. Коли сервер закінчив свою сторону переговорів, він надсилає a Привіт сервера повідомлення.

Тепер клієнт знову повернеться. Залежно від обраного набору шифрів, він надішле a Обмін ключами клієнта повідомлення. Це може містити відкритий ключ або секрет передмайстра, який зашифрований відкритим ключем сервера.

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

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

Потім клієнт слідкує за цим Готово повідомлення, яке зашифроване, а також містить код автентифікації повідомлення (MAC) для аутентифікації. Сервер розшифровує це повідомлення і перевіряє MAC. Якщо будь-який із цих процесів не вдасться, зв’язок слід відхилити.

Тепер черга сервера надіслати Змінити специфікацію шифру повідомлення, а також а Готово повідомлення з тим самим вмістом, що і вище. Потім клієнт також намагається розшифрувати та перевірити вміст. Якщо це все успішно завершено, рукостискання закінчено. На цьому етапі встановлюється протокол програми. Потім дані можуть надійно обмінюватися таким же чином, як і Готово повідомлення зверху, з аутентифікацією та необов’язковим шифруванням.

Клієнт TLS, підтверджений клієнтом

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

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

Скорочене рукостискання TLS

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

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

Процес починається з Клієнт Привіт повідомлення. Це дуже схоже на попереднє повідомлення “Привіт клієнта”, але воно також містить ідентифікатор сесії від попереднього з’єднання. Якщо сервер знає ідентифікатор сеансу, він включає його в свій Привіт сервера повідомлення. Якщо він не розпізнає ідентифікатор сеансу, він поверне інше число, і замість цього має відбутися повне рукостискання TLS.

Якщо сервер розпізнає ідентифікатор сеансу, то Свідоцтво і Обмін ключами кроки можна пропустити. The Змінити специфікацію шифру і Готово повідомлення надсилаються так само, як і основне рукостискання TLS, показане вище. Після того, як клієнт розшифрував повідомлення та перевірив MAC, дані можуть надсилатися через захищене TLS-з’єднання.

Також є розширення TLS, яке дозволяє відновити з’єднання за допомогою сеансових квитків замість ідентифікаторів сесії. Сервер шифрує дані про сеанс і надсилає їх клієнту. Коли клієнт хоче відновити це з’єднання, він надсилає серверний квиток на сервер, який розшифровує його для виявлення параметрів.

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

Розпакування рукостискання TLS

Три найважливіші дії рукостискання включають:

• параметри вибираються,
• він проводить аутентифікацію та
• ключі встановлюються.

Розкриємо їх трохи детальніше, щоб ви могли зрозуміти, що відбувається насправді.

Параметри

На початку рукостискання клієнт і сервер узгоджують параметри з’єднання за взаємною згодою. Перша з них – яка версія TLS буде використовуватися. Це найвища версія, яку підтримують обидві сторони, яка, як правило, є найбільш захищеною.

Сторони також вирішують, який алгоритм обміну ключами вони використовуватимуть для встановлення головного ключа. На цьому етапі також узгоджено хеш-функцію, алгоритм шифрування та метод стиснення. Вони будуть детально висвітлені під час обговорення Протокол програми пізніше у статті.

Автентифікація: Цифрові сертифікати

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

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

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

Примітка про відкриті ключі

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

Коротке пояснення полягає в тому Криптографія відкритого ключа використовує пару ключів для шифрування та дешифрування, а не лише один ключ. Відправник використовує відкритий ключ призначеного одержувача для шифрування даних. Після шифрування його можна розшифрувати лише відповідним приватним ключем одержувача. Звичайно, відкритим ключем можна ділитися публічно, тоді як приватний ключ потрібно зберігати в секреті.

Шифрування відкритим ключем дозволяє сторонам безпечно обмінюватися інформацією, навіть якщо вони ніколи раніше не зустрічалися або не мали можливості обмінятися ключами. Це відбувається завдяки деяким унікальним властивостям простих чисел. Ви можете дізнатися більше в нашій статті про шифрування відкритим ключем.

Встановлення головного секрету

Як ми бачили вище, коли ми обговорювали процес базового рукостискання TLS, після того, як сторона (або обидві сторони) підтверджують свою особу своїм публічним сертифікатом, наступний крок – встановлення головного секрету, також відомого як загальний секрет. Головний секрет – це основа для отримання ключів, які використовуються як для шифрування, так і для перевірки цілісності даних, що передаються між двома сторонами.

Рукостискання TLS може використовувати декілька різних механізмів, щоб безпечно поділитися цим секретом. До них належать RSA, кілька різних типів обміну ключами Diffie-Hellman, PSK, Kerberos та інші. У кожного є свої переваги та недоліки, такі як забезпечення прямої таємниці, але ці відмінності виходять за межі цієї статті.

Точний процес буде залежати від того, який метод обміну ключами було обрано, але він слідує грубим крокам, згаданим у Основне рукостискання TLS розділ.

Секрет передмагістратури виводиться відповідно до того, який метод обміну ключами був обраний раніше. Клієнт шифрує секрет передмайстра відкритим ключем сервера, щоб безпечно надсилати його через з’єднання.

Тоді і клієнт, і сервер використовують секрет передмайстра і випадкові номери, які вони надіслали на початку зв’язку, щоб створити головний секрет. Після того, як основний ключ був обчислений, він використовується для створення чотирьох або шести окремих клавіш. Це:

• Клієнт пише MAC-ключ – Цей ключ використовується сервером для перевірки цілісності даних, надісланих клієнтом.
• MAC-ключ запису на сервер – MAC-ключ запису сервера використовується клієнтом для перевірки цілісності даних, надісланих сервером.
• Ключ шифрування запису клієнта – Сервер використовує цей ключ для шифрування даних, надісланих клієнтом.
• Ключ шифрування запису сервера – Клієнт використовує цей ключ для шифрування даних, надісланих сервером.
• Клієнт пише IV ключ – Ключ запису клієнта IV використовується сервером у шифрах AEAD, але не тоді, коли використовуються інші алгоритми обміну ключами.
• Ключ запису сервера IV – Аналогічно, цей ключ використовується клієнтом у шифрах AEAD, але не тоді, коли використовуються інші алгоритми обміну ключами.

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

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

Протокол програми

Після встановлення захищеного з’єднання рукостисканням TLS протокол програми використовується для захисту переданих даних. Він може бути налаштований на використання широкого спектру алгоритмів для відповідності різним сценаріям.

Алгоритми аутентифікації

Цілісність повідомлень можна перевірити за допомогою багатьох різних алгоритмів. До них належать:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Щоб довести цілісність даних, що надсилаються, відправник запускає інформацію через хеш-функцію, щоб повернути унікальний рядок символів. Це спеціальні формули, які завжди будуть повертати один і той же результат, коли вони отримують однаковий вклад.

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

Якщо вони однакові, це означає, що дані не були змінені, оскільки їх підписав відправник. Якщо вони різні, цілком ймовірно, що дані були підроблені, або була якась інша помилка.

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

Алгоритми шифрування

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

TLS може використовувати безліч різних алгоритмів, таких як Камелія або ARIA, хоча найпопулярнішим є AES.

Стиснення

Стиснення – це процес кодування даних, щоб зайняти менше місця. TLS підтримує стиснення, якщо обидві сторони з’єднання вирішили його використовувати. Незважаючи на цю здатність, зазвичай рекомендується уникати використання TLS для стиснення даних, тим більше, що це напад КРИМІ (див Проблеми безпеки TLS розділ нижче) було виявлено, що він може скористатися стислими даними для викрадення сеансу.

Прокладки

Padding додає додаткові дані до повідомлення, перш ніж воно буде зашифровано. Це звичайний криптографічний процес, який використовується, щоб запобігти натякам у структурі зашифрованих даних не надавати справжнього значення. TLS зазвичай застосовує прокладку PKCS # 7 до записів, перш ніж вони зашифровані.

Протокол сповіщення

Якщо з’єднання або безпека стають нестабільними, порушеними або сталася серйозна помилка, протокол попередження дозволяє відправника повідомити іншу сторону. Ці повідомлення мають два типи – або попереджувальні, або фатальні. Попереджувальне повідомлення вказує на те, що сеанс нестабільний і дозволяє одержувачу визначити, чи слід продовжувати сеанс чи ні.

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

TLS & модель OSI

Модель OSI – це спосіб концептуалізації та стандартизації того, як ми дивимось на різні наші комунікаційні системи та протоколи. Важливо зазначити, що це лише модель, і деякі наші протоколи не відповідають їй.

OSI має сім окремих шарів, які показують рівні, на яких працюють протоколи, TLS не вписується в жоден. Він протікає через інший транспортний протокол, як TCP, який повинен означати, що він знаходиться над четвертим шаром, транспортним шаром. Він найбільш відомий як транспортний шар, але оскільки він проводить рукостискання, це означає, що він є частиною шарів презентації або додатків.

Як бачите, TLS просто не відповідає моделі OSI. Це не означає, що TLS зламаний або неправильний, якщо що-небудь, це просто показує, що модель OSI є помилковою та не може враховувати всі наші протоколи зв’язку..

Використання TLS

TLS використовується для забезпечення значної частини нашого інтернет-зв’язку. Зазвичай він реалізується над протоколами типу Протокол управління передачею (TCP), але він також може бути використаний у протоколі управління перевантаженими контурами (DCCP) та протоколом користувача Datagram (UDP).

Він може захищати протоколи, такі як HTTP, SMTP, FTP, XMPP і NNTP, а також інші. Найпоширеніша програма – це протокол Hypertext Transfer Protocol Secure (HTTPS), який захищає зв’язок між веб-браузером та веб-сайтом. Ви можете вказати, коли HTTPS використовується для захисту вашого інтернет-з’єднання, оскільки зліва від URL-адреси у верхній частині веб-переглядача з’явиться маленький зелений значок блокування.

TLS також можна використовувати для створення VPN, наприклад, у OpenConnect та OpenVPN. Він використовує свої можливості шифрування та аутентифікації для формування тунелю, який може з’єднувати хости та мережі один з одним. Технології VPN на основі TLS, такі як OpenVPN, вигідніші за такі альтернативи, як IPsec, оскільки, як відомо, OpenVPN не має серйозних проблем із безпекою. Ці VPN також можна простіше налаштувати.

Ще одне з його застосувань – це захищений електронний лист через STARTTLS. Коли TLS реалізований, він не дозволяє зловмисникам отримувати доступ до повідомлень під час подорожі між поштовими серверами.

Проблеми безпеки TLS

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

Минулі версії, такі як SSL 2.0 та 3.0 (і TLS 1.0, який по суті такий же, як і SSL 3.0), містять численні вади безпеки, але оскільки вони є старими та застарілими протоколами, ми не будемо вникати в деталі. Ви повинні використовувати TLS 1.2 та 1.3 для захисту своїх з’єднань.

Новіші версії TLS мають численні оновлення, які роблять його менш вразливим, ніж SSL. Незважаючи на це, у протоколі все ще були такі проблеми безпеки:

Нападів на повторну переговорну діяльність

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

Цей напад не дозволяє зловмиснику побачити відповідь, але він все ще може нанести шкоду. Розширення, яке запобіжить цим атакам, наразі є пропонованим стандартом.

БІСТ

Напад браузера “Експлуатувати проти SSL / TLS (BEAST)” вперше було виявлено дослідниками в 2011 році. Він використовує перевагу блоку шифру, що ланцюг вразливості в TLS, який може бути використаний для розшифровки повідомлень. Ця атака зачіпає лише TLS 1.0, що є старою і слабшою версією протоколу. Хоча це не буде застарілим до 2023 року, натомість користувачі повинні використовувати версії 1.2 та 1.3.

Часові атаки

Ці атаки бічних каналів аналізують, скільки часу потрібно для запуску алгоритму, а потім використовують цю інформацію, щоб працювати назад і з’ясувати ключ. У 2013 році напад Лакі Тринадцять виявив, що використовує як атаку синхронізації, так і напад оракула, коли перевіряється код автентифікації повідомлення (MAC). Ця атака може використовуватися для порушення алгоритму TLS, хоча не вважається небезпечною для більшості користувачів TLS.

ЗЛОЧИН & НАРУШ

Злочинна атака працює проти низки протоколів. Коли дані стиснуті, вони можуть вилучати вміст із файлів cookie аутентифікації. Ця інформація може бути використана для викрадення сеансу. Хоча це впливає на низку протоколів, напад особливо хвилює, коли використовується стиснення HTTP, оскільки немає ефективних стратегій пом’якшення наслідків.

У 2013 році виявлено, що експлуатування браузера та ексфільтрація за допомогою адаптивної компресії гіпертексту (BREACH) впливають на стиснення HTTP аналогічним чином. Ця версія атаки може відновити адреси електронної пошти та інші цінні дані, які були зашифровані TLS. Атаку BREACH можна пом’якшити, відключивши стиснення HTTP або використовуючи такі методи, як захист підробки між веб-сайтами (CSRF).

Пониження атак

Це атаки, які підманюють сервери використовувати більш ранні та менш безпечні версії TLS. Зловмисники могли використовувати ці методи для узгодження використання менш безпечних обмінів ключів та шифрів. Атака Logjam є хорошим прикладом, оскільки вона може змусити вразливі сервери використовувати 512-бітний Diffie-Hellman, який є слабким. Потім зловмисники можуть зламати цей механізм обміну ключами і витягти ключі, що дозволяє їм повний доступ до сеансу.

Серцеподібні

Heartbleed був недоліком безпеки, який випадково був внесений до бібліотеки криптовалют OpenSSL у 2012 році, але не оприлюднюється до 2014 року. Оскільки це така поширена реалізація TLS, вона завдала значної глобальної шкоди.

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

Оскільки бібліотека OpenSSL впроваджена настільки широко, міжнародна вартість пом’якшення проблеми виявилася досить дорогою. Адміністраторам сервера довелося встановити новий патч та відновити сертифікати та пари ключів, які, можливо, були порушені протягом двох років існування вразливості.

ВІДКРИТИ

Дешифрування RSA з застарілою та ослабленою eNcryption (DROWN) атакою було оголошено в 2016 році, і вона використовує перевагу серверної підтримки для SSL 2.0. Він використовує вибрану шифротекстову атаку проти серверів, які все ще підтримують SSL 2.0, а також тих, які поділяють той же сертифікат відкритого ключа з іншим сервером, що підтримує SSL 2.0.

Коли напад був оголошений, його можна було розпочати із початковими витратами на встановлення близько 18 000 доларів США та близько 400 доларів за кожну окрему атаку. Коли атака DROWN пройшла успішно, вона отримує ключі сеансу.

Атаку можна пом’якшити, не обмінюючись сертифікатами сервера. Група OpenSSL також випустила патчі, які видаляють підтримку старих протоколів і шифрів, але вони працюють лише в тому випадку, якщо сертифікат сервера не надано спільним з іншими серверами, що підтримують SSL 2.0.

Нечесний PAC

Цей напад був знайдений у 2016 році. Він використовує слабкі сторони, виявлені в протоколі автоматичного розкриття веб-проксі (WPAD). Коли користувач намагається зайти на веб-сайт через зашифроване TLS-з’єднання, недолік може зробити URL-адресу видимою. Оскільки URL-адреси іноді надсилаються користувачам як форма автентифікації, атака Unholy PAC дає можливість зловмиснику взяти на себе обліковий запис користувача.

Чи безпечно TLS?

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

Бізнес-технології в галузі кібербезпеки автор: TheDigitalArtist, ліцензований відповідно до CC0