Безопасность транспортного уровня (TLS) является одним из наиболее важных и широко используемых протоколов безопасности. Он защищает значительную часть данных, которые передаются онлайн. Это наиболее заметно используется для защиты данных, которые перемещаются между веб-браузером и веб-сайтом через HTTPS, но он также может быть использован для защиты электронной почты и множества других протоколов.
TLS является ценным, поскольку он гарантирует, что другая сторона в соединении является тем, кем они себя называют, показывает, сохраняет ли данные свою первоначальную целостность, и обеспечивает конфиденциальность посредством шифрования..
TLS использует ряд различных алгоритмов и схем для достижения этих целей. Это может показаться сложным, но эта статья будет охватывать один аспект за раз, чтобы дать вам углубленный взгляд на то, как TLS работает для защиты соединений.
Что делает TLS?
Отправляя информацию онлайн, мы сталкиваемся с тремя основными проблемами безопасности:
- Как мы можем узнать, действительно ли человек, с которым мы общаемся, является тем, кем они себя называют??
- Как мы можем знать, что данные не были подделаны с момента их отправки?
- Как мы можем помешать другим людям видеть и получать доступ к данным?
Эти вопросы имеют решающее значение, особенно когда мы отправляем конфиденциальную или ценную информацию. TLS использует ряд криптографических методов для решения каждой из этих трех проблем. Вместе они позволяют протоколу проверять подлинность другой стороны в соединении, проверять целостность данных и обеспечивать зашифрованную защиту.
Давайте упростим ситуацию и представим, что вы пытаетесь передавать информацию туда-сюда с другом, который живет по всей стране. Если информация конфиденциальна, вы будете очень обеспокоены тремя основными проблемами, упомянутыми выше..
Вы не можете просто отправить письмо и надеяться на лучшее, особенно если вы подозреваете, что ваши сообщения будут направлены злоумышленниками. Вместо этого вам нужна система, которая позволяет вам проверить, является ли ваш получатель легитимным, способ, которым вы можете проверить, были ли сообщения изменены, и способ защитить их от посторонних глаз..
TLS выполняет эти требования с использованием ряда различных процессов. Это начинается с того, что известно как TLS рукопожатие, где происходит аутентификация и устанавливаются ключи.
Чтобы вернуться к нашей аналогии с письмом, аутентификационная часть TLS была бы подобна отправке письма через курьера, который требует идентификации. Когда курьер доставляет письмо, он сравнивает удостоверение личности с лицом и проверяет, был ли получатель правильным лицом..
Этап установления ключа был бы немного похож на то, если бы ваше письмо содержало половину номера пин-кода, который вы намеревались использовать в будущих сообщениях. Вы бы попросили получателя придумать вторую половину номера и отправить его вам в ответном письме..
После того как курьер подтвердит личность и установит пин-код, у вас будет все необходимое для безопасной отправки информации. На самом деле эти этапы намного сложнее, но мы вернемся к этому позже..
TLS безопасно обменивается информацией с протоколом приложения. Чтобы продолжить нашу аналогию, безопасная передача данных по TLS была бы равносильна написанию сообщения и помещению его в конверт. Вы бы написали свою подпись на печати, чтобы, если письмо было подделано, ваш получатель мог узнать это по разорванной подписи (на самом деле это делается с помощью математики, но, опять же, мы рассмотрим это позже).
Затем вы поместите письмо в небольшую металлическую коробку с кодовым замком, указав в качестве номера булавки номер, который вы совместно установили с получателем. Вы бы отправили коробку через курьера, который проверяет идентификацию при доставке посылки. Ваш получатель будет отвечать таким же образом, и любые будущие сообщения будут следовать тем же шагам.
TLS решает все три наши проблемы относительно одинаково. Курьер служит для проверки подлинности получателя и проверки того, что ящик доставляется предполагаемому лицу. Запертая коробка служит формой шифрования, предотвращая доступ к письмам никому, кроме вашего партнера. Подписанный конверт позволяет узнать, не было ли сообщение подделано.
Это очень грубое приближение того, что делает TLS. В реальности, TLS происходит между клиентами и серверами, а не два человека, которые отправляют почту друг другу. Аналогия просто для того, чтобы дать вам визуализацию того, что происходит, и причины этого. В следующих разделах мы рассмотрим, что на самом деле происходит подробно.
TLS против SSL
Читая о TLS, вы часто увидите упоминание о SSL или даже как TLS / SSL. Secure Sockets Layer (SSL) – это старая версия TLS, но многие в отрасли все еще ссылаются на TLS под старым прозвищем. В этой статье будет использоваться термин TLS, но важно отметить, что имена часто используются взаимозаменяемо. Подробнее о SSL вы можете прочитать в нашем руководстве.
История ТЛС
Все началось с необходимости обеспечения безопасности транспортного уровня. Как мы упоминали выше, предшественником 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 году. Она включала поддержку аутентифицированных шифровальных шифров, ряд изменений в том, как использовались хэш-функции, и много других улучшений..
Следующая версия не поступила до [year] года, когда был определен TLS 1.3. Он содержит множество изменений, включая принудительную прямую секретность, устранение поддержки более слабых алгоритмов и многое другое..
TLS 1.0 и 1.1 теперь объявлены устаревшими в [year] году, но версия 1.2 широко используется. Версия 1.3 начинает расширяться.
TLS: технические детали
TLS состоит из множества различных элементов. Фундаментальной частью является протокол записи, базовый протокол, отвечающий за всеобъемлющую структуру всего остального.
Диаграмма, показывающая стек TLS. Стек протокола TLS Джеффрейтеджосукмоно. Лицензировано под CC0.
Протокол записи содержит пять отдельных подпротоколов, каждый из которых отформатирован как учет:
- Рукопожатие – Этот протокол используется для настройки параметров безопасного соединения..
- заявка – Протокол приложения начинается после процесса рукопожатия, и именно там данные надежно передаются между двумя сторонами..
- бдительный – Протокол оповещения используется любой стороной в соединении, чтобы уведомить другую, если есть какие-либо ошибки, проблемы стабильности или потенциальный компромисс.
- Изменить спецификацию шифра – Этот протокол используется либо клиентом, либо сервером для изменения параметров шифрования. Это довольно просто, поэтому мы не будем подробно останавливаться на этом в этой статье.
- Сердцебиение – Это расширение TLS, которое позволяет одной стороне соединения знать, жив ли его партнер, и не позволяет брандмауэрам закрывать неактивные соединения. Это не основная часть TLS, поэтому мы пропустим его в этом руководстве..
Каждый из этих подпротоколов используется на разных этапах для передачи различной информации. Наиболее важными для понимания являются рукопожатие и прикладные протоколы, поскольку они отвечают за установление соединения и затем безопасную передачу данных..
Протокол рукопожатия TLS
Здесь соединение устанавливается безопасным способом. Это может показаться сложным, если вы новичок в некоторых из концепций, но каждый из них будет рассмотрен позже в статье, если вам нужно обратиться к ним.
Существует три основных типа рукопожатия TLS: базовое рукопожатие TLS, рукопожатие TLS с аутентификацией клиента и сокращенное рукопожатие.
Основное рукопожатие TLS
Диаграмма, показывающая процесс рукопожатия TLS. Полный TLS 1.2 Рукопожатие от FleshGrinder. Лицензировано под CC0.
При таком типе рукопожатия аутентифицируется только сервер, а не клиент. Он начинается с этапа согласования, когда клиент отправляет Клиент Привет сообщение. Он содержит самую высокую версию TLS, которую поддерживает клиент, возможные наборы шифров, указание того, поддерживает ли он сжатие, случайное число и некоторую другую информацию.
Приветствие клиента приветствуется Сервер Привет сообщение. Этот ответ содержит идентификатор сеанса, версию протокола, комплект шифров и сжатие (если оно используется), которое сервер выбрал из списка клиентов. Это также включает другое случайное число.
Это зависит от выбранного набора шифров, но сервер обычно следует этому, отправляя сертификат сообщение для аутентификации. Это подтверждает его личность и содержит его открытый ключ.
Если используются временные обмены ключами Диффи-Хеллмана или анонимными ключами Диффи-Хеллмана, то за этим следует Обмен ключами сервера сообщение. Другие методы обмена ключами пропускают эту часть. Когда сервер завершил свою сторону согласования, он отправляет Сервер Hello Done сообщение.
Теперь снова очередь за клиентом. В зависимости от выбранного набора шифров, он отправит Обмен ключами клиентов сообщение. Это может содержать открытый ключ или секретный ключ, который зашифрован открытым ключом сервера.
Затем обе стороны используют случайные числа и секрет перед мастером, чтобы придумать главный секрет. Ключи являются производными от главного секрета, который затем используется для аутентификации и шифрования сообщений..
Затем клиент отправляет Изменить спецификацию шифра сообщение. Это говорит серверу, что следующие сообщения теперь будут аутентифицированы и зашифрованы (хотя иногда шифрование может не использоваться).
Затем клиент следует это с Законченный сообщение, которое зашифровано и также содержит код аутентификации сообщения (MAC) для аутентификации. Сервер расшифровывает это сообщение и проверяет MAC. Если какой-либо из этих процессов завершится неудачно, соединение должно быть отклонено.
Теперь очередь сервера отправлять Изменить спецификацию шифра сообщение, а также Законченный сообщение с тем же содержанием, что и выше. Затем клиент также пытается расшифровать и проверить содержимое. Если все это успешно завершено, рукопожатие закончено. На этом этапе протокол приложения установлен. Затем данные можно безопасно обменивать так же, как Законченный сообщение сверху, с аутентификацией и необязательным шифрованием.
Подтвержденное клиентом рукопожатие TLS
Это рукопожатие очень похоже на базовое рукопожатие TLS, но клиент также проходит проверку подлинности. Основное отличие состоит в том, что после того, как сервер сертификат сообщение, оно также отправляет Запрос сертификата сообщение, запрашивающее сертификат клиента. Как только сервер закончил, клиент отправляет свой сертификат в сертификат сообщение.
Затем клиент отправляет свой Обмен ключами клиентов сообщение, как в базовом рукопожатии TLS. Затем следует Сертификат Подтвердить сообщение, которое включает цифровую подпись клиента. Поскольку он рассчитывается на основе личного ключа клиента, сервер может проверить подпись, используя открытый ключ, который был отправлен как часть цифрового сертификата клиента. Остаток от Подтвержденное клиентом рукопожатие TLS следует по тому же принципу, что и базовое рукопожатие TLS.
Сокращенное рукопожатие TLS
После того, как рукопожатие уже состоялось, TLS позволяет сократить большую часть процесса, используя вместо этого сокращенное рукопожатие. Эти рукопожатия используют идентификатор сеанса, чтобы связать новое соединение с предыдущими параметрами.
Сокращенное рукопожатие позволяет обеим сторонам возобновить безопасное соединение с той же настройкой, которая была согласована ранее. Поскольку некоторая криптография, которая обычно используется для инициации рукопожатия, может быть довольно тяжелой для вычислительных ресурсов, это экономит время и облегчает соединение.
Процесс начинается с Клиент Привет сообщение. Это очень похоже на предыдущее сообщение Client Hello, но оно также содержит идентификатор сессии из более раннего соединения. Если сервер знает идентификатор сеанса, он включает его в свой Сервер Привет сообщение. Если он не распознает идентификатор сеанса, он вернет другое число, и вместо этого должно произойти полное рукопожатие TLS..
Если сервер распознает идентификатор сеанса, то сертификат и Обмен ключами шаги могут быть пропущены. Изменить спецификацию шифра и Законченный сообщения отправляются так же, как и базовое рукопожатие TLS, показанное выше. Как только клиент расшифровал сообщение и проверил MAC, данные могут быть отправлены через безопасное соединение TLS.
Существует также расширение TLS, которое позволяет возобновлять соединения с билетами сеанса вместо идентификаторов сеансов. Сервер шифрует данные о сеансе и отправляет их клиенту. Когда клиент хочет возобновить это соединение, он отправляет билет сеанса на сервер, который расшифровывает его, чтобы показать параметры.
Билеты на сеансы используются не так часто, потому что они требуют расширения. Несмотря на это, они могут быть полезны в определенных ситуациях, потому что серверу не нужно ничего хранить.
Распаковка рукопожатия TLS
Три наиболее важных шага рукопожатия включают в себя:
- параметры выбраны,
- проводит аутентификацию и
- ключи установлены.
Давайте рассмотрим их немного подробнее, чтобы вы могли понять, что на самом деле происходит.
Параметры
В начале рукопожатия клиент и сервер согласовывают параметры соединения по взаимному согласию. Первая из них – какая версия TLS будет использоваться. Это самая высокая версия, которую поддерживают обе стороны, которая, как правило, наиболее безопасна.
Стороны также решают, какой алгоритм обмена ключами они будут использовать для установления мастер-ключа. Хеш-функция, алгоритм шифрования и метод сжатия также согласовываются на этом этапе. Они будут подробно рассмотрены, когда мы обсудим Протокол приложения позже в статье.
Аутентификация: цифровые сертификаты
Аутентификация является ключевой частью защиты канала связи, поскольку она позволяет обеим сторонам знать, что они на самом деле говорят с тем, кем они себя считают, а не с самозванцем. В TLS и многих других механизмах безопасности это достигается с помощью так называемых цифровых сертификатов..
Цифровые сертификаты – это электронные документы, которые показывают связь между физическим или юридическим лицом и его открытым ключом.. Эта ссылка проверяется центром сертификации (ЦС), который является доверенной организацией, которая проверяет, действительно ли эти два фактора связаны, а затем использует свою собственную репутацию для предоставления доверия сертификату..
Различные уровни сертификатов представляют различные степени доверия. Важно знать, что если у клиента или сервера есть надежный и действительный сертификат, то разумно предположить, что открытый ключ является законным и что вы не имеете дело с злоумышленником.
Примечание об открытых ключах
Шифрование с открытым ключом (также известное как асимметричное шифрование) является важной частью криптографии и широко используется в различных аспектах TLS. Вот краткий учебник для тех, кто не знает, как это работает.
Краткое объяснение состоит в том, что криптография с открытым ключом использует пару ключей для шифрования и дешифрования, а не только один ключ. Отправитель использует открытый ключ получателя для шифрования данных. После того как он был зашифрован, он может быть расшифрован только с помощью соответствующего закрытого ключа получателя. Конечно, открытый ключ может быть открыт публично, в то время как закрытый ключ должен храниться в секрете..
Шифрование с открытым ключом позволяет сторонам безопасно обмениваться информацией, даже если они никогда не встречались или не имели возможности обмениваться ключами заранее. Это достигается за счет некоторых уникальных свойств простых чисел. Вы можете узнать больше в нашей статье о шифровании с открытым ключом.
Установление мастер-секрета
Как мы видели выше, когда мы обсуждали процесс основного рукопожатия TLS, после того, как сторона (или обе стороны) подтверждает свою личность с помощью своего открытого сертификата, Следующий шаг – установить главный секрет, также известный как общий секрет.. Главный секрет является основой для получения ключей, используемых для шифрования и проверки целостности данных, передаваемых между двумя сторонами..
Рукопожатие TLS может использовать несколько различных механизмов для безопасного обмена этим секретом. К ним относятся RSA, несколько различных типов обмена ключами Диффи-Хеллмана, PSK, Kerberos и другие. У каждого есть свои преимущества и недостатки, такие как обеспечение секретности, но эти различия выходят за рамки данной статьи..
Точный процесс будет зависеть от того, какой метод обмена ключами был выбран, но он следует грубым шагам, упомянутым в Основное рукопожатие TLS раздел.
Секрет мастера передается в соответствии с выбранным ранее методом обмена ключами. Клиент шифрует секрет premaster с помощью открытого ключа сервера, чтобы безопасно отправить его через соединение.
Затем клиент и сервер используют секрет предварительного мастера и случайные числа, которые они отправили в начале сеанса связи, чтобы получить главный секрет. Как только главный ключ рассчитан, он используется для создания четырех или шести отдельных ключей. Эти:
- Клиент пишет MAC-ключ – Этот ключ используется сервером для проверки целостности данных, отправленных клиентом.
- MAC-ключ записи сервера – MAC-ключ записи сервера используется клиентом для проверки целостности данных, отправленных сервером..
- Ключ шифрования записи клиента – Сервер использует этот ключ для шифрования данных, отправленных клиентом..
- Ключ шифрования записи сервера – клиент использует этот ключ для шифрования данных, отправленных сервером.
- Клиент пишет IV ключ – Ключ IV записи клиента используется сервером в шифрах AEAD, но не при использовании других алгоритмов обмена ключами.
- Сервер пишет IV ключ – Аналогично, этот ключ используется клиентом в шифрах AEAD, но не при использовании других алгоритмов обмена ключами..
Создание главного ключа является важной частью рукопожатия TLS, поскольку оно позволяет обеим сторонам соединения безопасно получать ключи, которые можно использовать как для аутентификации, так и для шифрования. Отдельные ключи используются для обоих процессов в качестве меры предосторожности.
После того как ключи аутентификации и шифрования получены, они используются для защиты обоих Законченный сообщения, а также записи, отправленные через протокол приложения.
Протокол приложения
Как только рукопожатие TLS установило безопасное соединение, прикладной протокол используется для защиты передаваемых данных. Он может быть настроен на использование широкого спектра алгоритмов в соответствии с различными сценариями.
Алгоритмы аутентификации
Целостность сообщений может быть проверена многими различными алгоритмами. Это включает:
- HMAC-MD5
- HMAC-SHA1
- HMAC-SHA2
- AEAD
Чтобы доказать целостность отправляемых данных, отправитель пропускает информацию через хеш-функцию, чтобы вернуть уникальную строку символов. Это специальные формулы, которые всегда будут возвращать один и тот же результат всякий раз, когда они получают один и тот же вход.
Отправитель подписывает эти данные своим закрытым ключом, чтобы сформировать так называемую цифровую подпись. Затем цифровая подпись присоединяется к сообщению и отправляется получателю. Чтобы проверить, сохраняют ли данные целостность и не были ли они изменены, получатель расшифровывает хеш с помощью открытого ключа отправителя. Затем они используют ту же хеш-функцию для отправленных данных. Затем получатель сравнивает два значения.
Если они одинаковы, это означает, что данные не были изменены с момента их подписания отправителем. Если они отличаются, вероятно, что данные были подделаны, или произошла какая-то другая ошибка.
Вот краткая версия того, как хеш-функции могут использоваться для демонстрации целостности данных. Если вы хотите получить более глубокое понимание, ознакомьтесь с нашей статьей о шифровании, засолке и хешировании.
Алгоритмы шифрования
TLS использует шифрование с симметричным ключом для обеспечения конфиденциальности передаваемых данных. В отличие от шифрования с открытым ключом, в процессах шифрования и дешифрования используется только один ключ. Как только данные были зашифрованы с помощью алгоритма, они появятся в виде беспорядочного зашифрованного текста. Пока используется соответствующий алгоритм, злоумышленники не смогут получить доступ к фактическим данным, даже если они их перехватывают.
TLS может использовать множество различных алгоритмов, таких как Camellia или ARIA, хотя наиболее популярным является AES.
компрессия
Сжатие – это процесс кодирования данных, чтобы они занимали меньше места. TLS поддерживает сжатие, если обе стороны соединения решают его использовать. Несмотря на эту возможность, обычно рекомендуется избегать использования TLS для сжатия данных, особенно после атаки CRIME (см. Проблемы безопасности TLS раздел ниже) было обнаружено, что можно использовать сжатые данные для перехвата сеанса.
набивка
Заполнение добавляет дополнительные данные к сообщению до его шифрования. Это обычный криптографический процесс, который используется, чтобы не дать подсказкам в структуре зашифрованных данных дать истинное значение. TLS обычно применяет заполнение PKCS # 7 к записям до того, как они зашифрованы.
Протокол оповещения
Если соединение или безопасность становятся нестабильными, скомпрометированы или произошла серьезная ошибка, протокол оповещения позволяет отправителю уведомить другую сторону. Эти сообщения имеют два типа: предупреждение или фатальное. Предупреждающее сообщение указывает на нестабильность сеанса и позволяет получателю определить, следует ли продолжать сеанс..
Фатальное сообщение сообщает получателю, что соединение было взломано или произошла серьезная ошибка. Отправитель должен закрыть соединение после отправки сообщения. Протокол оповещения также содержит информацию о том, что вызывает конкретную проблему подключения. Это может включать такие вещи, как сбой дешифрования, неизвестный центр сертификации, недопустимый параметр и многое другое.
TLS & модель OSI
Модель OSI – это способ концептуализации и стандартизации того, как мы смотрим на наши различные коммуникационные системы и протоколы. Важно отметить, что это всего лишь модель, и некоторые наши протоколы не соответствуют ей.
OSI имеет семь отдельных уровней, которые показывают уровни, на которых работают протоколы, однако, TLS не подходит ни к одному. Он передается по другому транспортному протоколу, такому как TCP, что должно означать, что он находится выше четвертого уровня, транспортного уровня. Он наиболее заметно используется как транспортный уровень, но поскольку он выполняет рукопожатия, это подразумевает, что он является частью уровня представления или приложений..
Как видите, TLS просто не соответствует модели OSI. Это не означает, что TLS сломан или неправильн, во всяком случае, это просто показывает, что модель OSI имеет недостатки и не в состоянии учитывать все наши протоколы связи.
Использование TLS
TLS используется для обеспечения значительной части наших онлайн-коммуникаций. Обычно это осуществляется через протоколы, такие как Протокол управления передачей (TCP), но его также можно использовать в протоколе управления перегрузкой дейтаграмм (DCCP) и протоколе дейтаграмм пользователя (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 году было обнаружено, что это может быть использовано злоумышленниками, чтобы они могли вводить трафик, чтобы он выглядел так, как будто он исходит от клиента. Серверы примут запрос как законный, что означает, что злоумышленники потенциально могут манипулировать исходящими сообщениями.
Эта атака не позволяет злоумышленнику увидеть ответ, но все еще может нанести ущерб. Расширение, которое предотвратит эти атаки, в настоящее время является предлагаемым стандартом..
BEAST
Атака с использованием браузера с использованием SSL / TLS (BEAST) была впервые обнаружена исследователями в 2011 году. Она использует уязвимость цепочки блоков шифрования в TLS, которую можно использовать для расшифровки сообщений. Эта атака затрагивает только TLS 1.0, которая является старой и более слабой версией протокола. Хотя до [year] года он не будет устаревшим, пользователям следует использовать версии 1.2 и 1.3..
Сроки атаки
Эти атаки по побочным каналам анализируют время, необходимое для запуска алгоритма, а затем используют эту информацию для обратной работы и выяснения ключа. В 2013 году была обнаружена атака Lucky Thirteen, которая использовала как временную атаку, так и атаку с добавлением оракула во время проверки кода аутентификации сообщений (MAC). Эту атаку можно использовать для взлома алгоритма TLS, хотя он не считается опасным для большинства пользователей TLS..
ПРЕСТУПНОСТЬ & НАРУШЕНИЯ
Атака CRIME работает против ряда протоколов. Когда данные сжаты, они могут извлекать содержимое из файлов cookie аутентификации. Эта информация может быть использована для захвата сессии. Хотя эта атака затрагивает несколько протоколов, она вызывает особую тревогу, когда используется сжатие HTTP, поскольку не существует эффективных стратегий смягчения последствий..
В 2013 году было обнаружено, что эксплойт в браузерной разведке и эксфильтрации с помощью адаптивного сжатия гипертекста (BREACH) аналогичным образом влияет на сжатие HTTP. Эта версия атаки может восстановить адреса электронной почты и другие ценные данные, которые были зашифрованы с помощью TLS. Атака BREACH может быть смягчена путем отключения сжатия HTTP или использования таких методов, как защита от подделки межсайтовых запросов (CSRF).
Понижение атаки
Это атаки, которые заставляют серверы использовать более ранние и менее безопасные версии TLS. Злоумышленники могут использовать эти методы для согласования использования менее защищенных обменов ключами и шифров. Атака Logjam – хороший пример, потому что она может заставить уязвимые серверы использовать 512-битный Диффи-Хеллмана, который слаб. Затем злоумышленники могут сломать этот механизм обмена ключами и извлечь ключи, предоставив им полный доступ к сеансу..
Heartbleed
Heartbleed был уязвимостью, которая была случайно введена в библиотеку криптографии OpenSSL в 2012 году, но не публикуется до 2014 года. Поскольку это такая распространенная реализация TLS, она нанесла значительный глобальный ущерб.
Один из разработчиков расширения сердцебиения TLS добавил уязвимость переполнения буфера, которая позволяет отображать некоторые дополнительные данные. Ошибка не была обнаружена при проверке кода, что привело к ряду значительных атак.
Поскольку библиотека OpenSSL реализована так широко, международные затраты на смягчение этой проблемы оказались довольно дорогими. Администраторы сервера должны были установить новое исправление и заново создать сертификаты и пары ключей, которые могли быть скомпрометированы в течение двухлетнего периода существования уязвимости..
тонуть
Атака «Расшифровка RSA с устаревшим и ослабленным шифрованием» (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 по лицензии СС0
