Код
#статьи

Протокол TLS: что это, зачем нужен и как работает

Если вы что-то оплачиваете в интернете, то мошенники до сих пор не опустошили ваши карточки именно благодаря TLS.

Иллюстрация: Оля Ежак для Skillbox Media

Давным-давно, когда интернет был ещё совсем юным, данные летали по Сети как есть — в открытом виде. Но время шло, и всё больше наших повседневных действий стало уходить на сайты: от покупок до записи к врачу, от общения до сделок с недвижимостью. Стало ясно, что весь этот трафик надо как-то шифровать.

Первой попыткой защитить ценные данные при передаче стал протокол SSL — о нём у нас уже есть отдельная статья. Сейчас из-за некоторых уязвимостей чистый SSL используют редко — зато его версия на максималках, протокол шифрования данных TLS, надёжно охраняет транзакции по всему миру. О нём и поговорим сегодня.

Из этой статьи вы узнаете:


Что такое TLS

TLS, или transport layer security, — это протокол, который защищает данные во время их передачи по Сети. Он работает на четвёртом, транспортном, уровне сетевой модели OSI, где отвечает за создание безопасных сессий обмена данными между браузером и сервером.

Изначально TLS использовали в основном для соединения со страницами оплаты — однако сейчас он работает почти на каждом уважающем себя сайте. Понять, что сайт использует TLS, легко: если его адрес начинается с https, а рядом красуется символ замочка — значит, ваши данные защищены.

Аббревиатура HTTPS означает, что сайт использует защищённую версию протокола HTTP — Hypertext Transfer Protocol Secure. По сути, это и есть обычный HTTP, только нашпигованный средствами защиты, за которые как раз и отвечает TLS.

Скриншот: Skillbox Media

Чтобы понять, как работает TLS, проведём аналогию с фильмом «Чёрная пантера». Если помните, у вакандийцев есть два характерных атрибута коммуникации. Во-первых, это фирменные приветствия со скрещёнными на груди руками, которые позволяют им узнавать друг друга. А во-вторых, конечно, вакандийский язык, понятный в основном жителям этой страны.

То же самое и с компьютерами. Когда вы заходите на сайт, защищённый TLS, ваш браузер и сервер сначала жмут друг другу руки: устанавливают соединение, обмениваются секретными ключами и выбирают алгоритмы шифрования. А потом начинают общение на загадочном языке, понятном только им.

Дальше в статье мы подробнее разберём процесс рукопожатия и обмена сообщениями в TLS — но перед этим обсудим ещё одну важную тему.

В чём разница между SSL и TLS

Если вы уже читали нашу статью про SSL, то наверняка заметили, что между двумя протоколами много общего: оба шифруют данные, оба используют секретные ключи, оба создают защищённые сессии. Так в чём же разница? Чтобы в этом разобраться, погрузимся ненадолго в историю.

Протокол SSL разработала компания Netscape в середине 1990-х, чтобы улучшить свой браузер Navigator (олды помнят). Для своей эпохи SSL был вполне хорош, но со временем в его безопасности нашлись серьёзные бреши. Одной из самых критичных стала небезопасная проверка паддинга.

Паддинг — это блок данных, который компьютер добавляет к исходным данным при отправке, чтобы сообщение соответствовало определённой обязательной длине, зависящей от пропускной способности сетевого оборудования.

Хакеры придумали хитрость: они вклинивались в сессию и отправляли сообщения с неправильным паддингом, при расшифровке которого сервер выдавал ошибку, где с потрохами сдавал внутренние процессы дешифрации. Эти данные мошенники использовали, чтобы вычислить исходное сообщение.

Чтобы лучше понять, как это работает, представьте, что вы пытаетесь угадать чей-то пароль. Но вместо обычного «пароль неверный» система говорит вам ещё и о том, что он слишком длинный или в нём нет каких-то символов. Тем самым система помогает хакеру сузить количество вариантов «паролей».

Изображение: Skillbox Media

Исправить эту уязвимость одними обновлениями было невозможно — она была связана с самим дизайном SSL, а не конкретными реализациями. Именно из-за подобных проблем, а также из-за банкротства Netscape, разработка перешла в так называемый Инженерный совет интернета — IETF. Там протокол улучшили, исправили косяки безопасности и выпустили под новым названием — TLS.

Новый протокол обзавёлся более совершенными механизмами шифрования и аутентификации, а также проверкой добавленных блоков. Да, атаку с неправильным паддингом стало провернуть не так-то просто:

Изображение: Skillbox Media

Сегодня протокол SSL считается устаревшим — использовать его не рекомендуется из-за вышеуказанных проблем. Однако термины SSL и TLS до сих пор часто путают и используют как синонимы. Но теперь вы знаете, как всё обстоит на самом деле, и можете помочь «распутаться» окружающим.

Как TLS шифрует данные

Чтобы защитить данные, TLS создаёт во время передачи специальный канал, где их нельзя прочитать или изменить без секретного ключа. Ключ — это подсказка, как именно читать сообщение. Самый простой пример ключа — это чтение первых букв в строке:

Вашими молитвами только и живём, дорогой Игорь Николаевич!

Совсем не ограничиваем себя.

Если урожай хороший народится — доведём мельницу до порядку.

Покуда в Петербурге гуляния, уж дайте себе волю.

Любуйтесь красотами и с людьми знакомьтесь.

О нас не беспокойтесь, Бог даст — Тверь не пропадёт.

Хорошо живём, ни на что не жалуемся.

Ответа скорого не ждём, но пишите уж по возможности.

В реальности ключи, конечно, намного сложнее, но смысл тот же — подсказка для правильного чтения.

В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.

Симметричное шифрование — это когда используется один и тот же ключ для шифрования и дешифрования данных. Оно работает эффективно и быстро, но требует предварительного обмена ключом между компьютером и сервером, в ходе которого ключ могут перехватить.

Асимметричное шифрование использует два ключа: публичный для шифрования и приватный для дешифровки. Публичный ключ можно свободно распространять, а приватный должен быть хорошо защищён. Асимметричное шифрование безопаснее, но требует больше вычислительных ресурсов и работает медленнее, чем симметричное.

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

Ещё TLS обеспечивает проверку подлинности сервера при помощи специальных сертификатов, которые заверяет специальный центр сертификации. С таким сертификатом ваш браузер будет уверен, что не обменивается данными с хакером.

Помимо шифрования в TLS используется несколько алгоритмов хеширования.

Хеширование — это преобразование массива данных в строку фиксированной длины. Для хеш-функции неважно, что именно вы через неё пропустите: полный текст «Войны и мира», трёхзначное число или email-адрес — на выходе будет всегда строка из заранее известного количества символов. Если поменять в исходном массиве хоть один знак, то хеш тоже изменится.

Когда ваш браузер отправляет данные с помощью протокола TLS, вместе с ними автоматически отправляется их хеш. Сервер получает данные и пропускает их через ту же хеш-функцию, что и браузер. Если данные не поменяли — хеши совпадут и обмен сообщениями пройдёт успешно.

На сайте wtools.io можно сделать хеш из любого текста — мы, например, захешировали текст этой статьи:

e2f1811ccf1a88a5cb22750a6ae72e21abf8bfb65b34dfe30877fd08a22e899f69d45ca9fb507e4271b84a206bfc110898361f08bf4f6dbfa433e3ab65ad9875

Основной алгоритм хеширования в TLS — это SHA на 256, 512 или 384 бит. Использование MD5 и SHA-1 не рекомендуется — с современными мощностями их слишком легко взломать обычным перебором.

Основные алгоритмы шифрования в TLS

С механикой работы шифрования разобрались — теперь давайте коротко расскажем, с помощью каких алгоритмов весь этот процесс происходит.

AES (Advanced Encryption Standard). Симметричный алгоритм шифрования, использующий для защиты данных ключи длиной от 128 до 256 бит. Чем длиннее ключ, тем выше защита, но ниже производительность.

3DES (Triple Data Encryption Standard). Чуть менее безопасный алгоритм. Он делает то же самое, что и AES, но тремя разными ключами. Это как если бы вы спрятали свои данные в коробку, эту коробку в другую коробку, а её в свою очередь убрали в третью коробку. Получается сложная конструкция из коробок, которая не даёт посторонним людям узнать, что внутри.

ChaCha20-Poly1305. Симметричный алгоритм, который использует ChaCha20 для генерации ключей и Poly1305 для создания MAC — кода аутентификации сообщений. Сервер вычисляет MAC и сравнивает его с полученным значением от клиента. Если совпало — значит, данные никто не менял.

Как работает TLS

Настало время выложить карты на стол. На самом деле, TLS — это не один протокол, а целых два: протокол рукопожатия и протокол записи. Каждый из них отвечает за свой набор функций. Коротко расскажем, в чём их смысл.

Допустим, вы заходите на сайт Skillbox Media, чтобы почитать статью про ИИ общего назначения. На этом этапе ни ваш браузер, ни сервер ещё ничего друг о друге не знают. Чтобы исправить эту ситуацию, начинает свою работу протокол рукопожатия (handshake protocol). Вот из каких этапов состоит процесс его исполнения:

Приветствие

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

Обмен ключами

Клиент и сервер убеждаются в подлинности друг друга и выполняют обмен ключами для дальнейшего использования при шифровании данных.

Завершение рукопожатия

Клиент и сервер подтверждают, что установка соединения прошла успешно и что они готовы к защищённой передаче данных.

Когда соединение установлено, самое время наконец отправить вам нужную статью. И тут в игру вступает протокол записи (record protocol): он отвечает за шифрование и передачу данных между сайтом и браузером. Он работает поверх установленного соединения по параметрам, о которых клиент и сервер договорились во время рукопожатия. И совершается эта магия за пять шагов:

Фрагментация

Данные разбиваются на фрагменты меньшего размера для последующего шифрования.

Компрессия

Данные сжимаются, их объём уменьшается (если применяется сжатие).

Шифрование

Фрагменты данных шифруются по выбранному алгоритму симметричного шифрования, использующему общий секретный ключ, установленный на этапе рукопожатия.

Аутентификация

Каждый фрагмент данных подписывается цифровой подписью или кодом аутентификации, чтобы соблюсти целостность и подлинность данных.

Передача данных

Зашифрованные и аутентифицированные фрагменты данных передаются по Сети между клиентом и сервером.

Как несложно догадаться, процесс обмена данными с помощью TLS — штука непростая и довольно требовательная к ресурсам компьютера. Но у инженеров и на этот счёт нашёлся выход — механизм возобновления сессий, который помогает срезать углы и пропустить этап рукопожатия.

Что такое механизм возобновления сессий

Чтобы ускорить обмен сообщениями, разработчики добавили в TLS механизм возобновления сессий — 0-RTT (zero round trip time resumption, нулевое время приёма-передачи). Он позволяет клиенту и серверу возобновить сессию, если она почему-то была прервана — например, из-за ошибки сети или бага на стороне сервера.

Работает этот механизм просто: во время обмена данными и клиент, и сервер кэшируют данные о сессии в специальные токены. Если эти токены совпадут, стороны могут пропустить этап рукопожатия и сразу перейти к обмену данными — мол, не нужны мне твои ключи, дорогой, заходи, здесь все свои :)

На первый взгляд, выглядит круто — но есть у этого механизма и недостатки:

❌ Недостаточная безопасность. Клиент отправляет зашифрованные данные на сервер, используя предварительно согласованные симметричные ключи. Однако если эти ключи перехватил хакер, то он может вклиниться в сессию.

❌ «Перегрузка» токенами. Если сервер обслуживает сайт с миллионами пользователей, хранить в памяти токены каждой сессии может быть проблематично. К счастью, на этот случай придумали механизм session ticket, который позволяет серверу «не держать всё в себе».

❌ Ограниченные динамические параметры. Динамические параметры — это своего рода условные знаки, которые стороны используют во время сессии, чтобы подтвердить, что они — это всё ещё они. В механизме 0-RTT эти параметры используются реже, чем в обычном режиме.

❌ Задержки в ответах. В рамках сессии 0-RTT клиент отправляет порцию данных на сервер до того, как получит ответ о «доставке» предыдущей. Это может привести к рассинхрону между сервером и клиентом — клиент может отправить несколько запросов до того, как получит ответ на первый.

Защита от атак типа man-in-the-middle

Атака типа man-in-the-middle («человек посередине») — одна из частых угроз безопасности в сетевых коммуникациях. Так называют ситуацию, когда злоумышленник внедряется в коммуникационный канал между клиентом и сервером, перехватывает и модифицирует передаваемые данные.

В TLS есть механизмы для защиты от таких атак:

  • Шифрование данных. Самый очевидный пункт: протокол TLS обеспечивает шифрование данных, что делает их непригодными для прослушивания или изменения злоумышленником.
  • Аутентификация сервера. Клиент проверяет подлинность сайта при помощи публичного ключа и убеждается, что связывается с нужным сервером, а не с посредником. Если сертификат не проходит проверку или отсутствует, клиент может предупредить о потенциальной атаке.
  • Аутентификация клиента. В некоторых случаях, когда требуется двусторонняя аутентификация, клиент предоставляет свой собственный сертификат серверу. Сервер может проверить этот сертификат и убедиться в подлинности клиента.
  • Обмен ключами по протоколу Диффи — Хеллмана. Протокол TLS позволяет клиенту и серверу согласовать общий секретный ключ с помощью протокола Диффи — Хеллмана.
  • Цифровая подпись. В протоколе TLS используют цифровые подписи для проверки подлинности и целостности передаваемых данных. Цифровая подпись гарантирует, что данные не были изменены в процессе передачи.

Конечно, совершенных средств защиты нет нигде, кроме… ну, может быть, Форт-Нокса или бункера Бэтмена. Атаки типа «человек посередине» периодически случаются даже с таким навороченным протоколом, как TLS, особенно если уделить не слишком много времени его настройке.

Версии TLS: чем различаются и какую использовать

Сейчас самая быстрая и защищённая версия TLS — 1.3. Всё благодаря современным алгоритмам шифрования, отказу от устаревших функций, а также механизму возобновления сессий. В некоторых случаях допускается использование версии 1.2. Всё, что ниже, — рекомендуется применять с большой осторожностью и только для работы с совсем уж архаичными браузерами и приложениями.

Давайте посмотрим, как менялся протокол TLS и какие фишки в нём появлялись от версии к версии.

TLS 1.0 (1999 год)

Что изменилось (по сравнению с SSL 3.0):

  • Добавлены новые функции, используемые для генерации ключей и вычисления MAC (message authentication code).
  • Изменены форматы сообщений, завершающих рукопожатие (finished messages).
  • Появились новые коды ошибок (alerts).
  • Добавлена обязательная поддержка протокола Диффи — Хеллмана.

TLS 1.1 (2006 год)

Что изменилось:

  • Произведена замена уязвимых алгоритмов хеширования MD5 и SHA-1 на более безопасные, такие как SHA-256.
  • Внедрены продвинутые алгоритмы шифрования, такие как AES и Camellia.
  • Добавлена защита от атак на паддинг с помощью генерации случайных чисел.
  • Улучшена защита от атак с использованием цепочки блоков шифрования (CBC).

TLS 1.2 (2008 год)

Что изменилось:

  • Добавлены новые алгоритмы шифрования, такие как AES-GCM (Advanced Encryption Standard — Galois/Counter Mode).
  • Улучшена проверка целостности данных и аутентификации.
  • Добавлены расширения, позволяющие клиенту и серверу согласовывать поддерживаемые функции и параметры.

TLS 1.3 (2018 год)

Что изменилось:

  • Добавлен механизм возобновления сессий RTT (0-RTT), о котором мы подробно рассказывали чуть выше.
  • Сократилось время установки соединения благодаря оптимизации протокола рукопожатия.
  • Удалены устаревшие и уязвимые функции: алгоритмы шифрования на основе CBC, проверка подписи на основе RSA/DSA и другие.
  • У клиента появилась возможность отправлять данные без ожидания подтверждения от сервера.

Уязвимости протокола TLS

Абсолютной защиты данных не существует. Как и у любой технологии, у TLS есть свои уязвимости:

  • Атаки на слабые алгоритмы шифрования в старых версиях TLS. Вычислительные мощности сегодняшних компьютеров позволяют относительно легко взломать алгоритмы шифрования, которые какое-то время назад считались неприступными. Используйте современные алгоритмы шифрования.
  • Уязвимости в реализации и настройке. Использование сторонних библиотек, попустительское отношение к проверкам сертификатов и обновлениям снижает защиту ваших данных.
  • Социальная инженерия и фишинг. Даже с последней корректно настроенной версией TLS не нарушайте правила безопасности в Сети — не переходите по подозрительным ссылкам и не оставляйте конфиденциальные данные там, откуда их могут извлечь злоумышленники.
  • Утечка информации и анализ трафика. Использование одних и тех же логина и пароля может скомпрометировать безопасность ваших данных.
  • Уязвимости в ОС. Отключённый файрвол и пренебрежение обновлениями операционной системы сделают ваши данные уязвимыми.

Большинство угроз безопасности и сценариев атак, перечисленных выше, остаются актуальными и для TLS 1.3. Однако TLS 1.3 привнёс улучшения и изменения, чтобы справиться с некоторыми из этих угроз и сценариев атак.

  • Улучшенная криптография. Современные алгоритмы шифрования и хеширования, которые обеспечивают более надёжную защиту данных и устойчивость к известным атакам.
  • Изъятие слабых алгоритмов шифрования, таких как MD5 и SHA-1, для уменьшения рисков, связанных с их использованием.
  • Обновлённый процесс установки соединения. В последней версии оптимизировали установку соединения, чтобы сократить обмен сообщениями и улучшить производительность.
  • Прямая секретность (forward secrecy). Даже если долгосрочные ключи сервера или клиента скомпрометированы, предыдущие сессии останутся защищёнными.
  • Улучшенная защита от атак типа MITM. Четвёртая версия протокола TLS включает ряд изменений для повышения защиты от атак MITM, таких как более строгая проверка сертификатов и использование надёжных алгоритмов аутентификации.

Хотя TLS 1.3 предлагает значительные улучшения в области безопасности, всё равно важно оставаться внимательным к новым угрозам и сценариям атак, которые могут возникнуть в будущем.

Рекомендации: как обеспечить безопасность TLS

Напоследок — несколько советов для сетевиков и администраторов сайтов о том, как правильно использовать протокол TLS, чтобы добиться максимальной безопасности своих ресурсов:

  • Используйте TLS 1.3, который является наиболее современной и безопасной версией протокола. Он включает множество улучшений и исправлений, связанных с безопасностью.
  • Отдавайте предпочтение безопасным алгоритмам шифрования, таким как AES-GCM или ChaCha20-Poly1305, а также безопасным алгоритмам хеширования, таким как SHA-256.
  • Убедитесь, что ваш сервер поддерживает прямую секретность, что означает, что даже при компрометации долгосрочных ключей сессионные ключи не будут скомпрометированы.
  • Убедитесь, что сертификаты настроены правильно и соответствуют реальным доменным именам сервера. Тщательно проверяйте сертификаты клиентов, чтобы предотвратить подделку.
  • Используйте современные и безопасные криптографические примитивы, такие как эллиптические кривые и протокол Диффи — Хеллмана с большой длиной ключа.
  • Используйте проверку сертификатов, чтобы убедиться, что клиент подключается к доверенному серверу, и обеспечьте целостность сертификатов через механизмы проверки отзыва сертификатов.
  • Рассмотрите использование дополнительных механизмов защиты, таких как файрволы, системы обнаружения вторжений (intrusion detection systems) и системы защиты от DDoS-атак.

Больше интересного про код — в нашем телеграм-канале. Подписывайтесь!

Проверьте свой английский. Бесплатно ➞
Нескучные задания: small talk, поиск выдуманных слов — и не только. Подробный фидбэк от преподавателя + персональный план по повышению уровня.
Пройти тест
Понравилась статья?
Да

Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪

Ссылка скопирована