Безопасность транспортного уровня

Transport Layer Security ( TLS ) — это криптографический протокол , предназначенный для обеспечения безопасности связи в компьютерной сети. Протокол электронная широко используется в таких приложениях, как почта , обмен мгновенными сообщениями и передача голоса по IP , но его использование для защиты HTTPS остается наиболее заметным для общественности.

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

Тесно связанный протокол безопасности транспортного уровня дейтаграмм ( DTLS ) — это протокол связи , который обеспечивает безопасность приложений на основе дейтаграмм . В технических текстах ссылки на «( D ) TLS », когда они применяются к обеим версиям. часто встречаются

TLS — это предложенный стандарт Internet Engineering Task Force (IETF), впервые определенный в 1999 году, а текущая версия — TLS 1.3, определенная в августе 2018 года. TLS основан на устаревших спецификациях SSL ( Secure Sockets Layer ) (1994, 1995, 1996), разработанный компанией Netscape Communications для добавления протокола HTTPS в веб-браузер Netscape Navigator .

Описание

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

необходимо Поскольку приложения могут взаимодействовать как с TLS (или SSL), так и без него, клиенту запросить у сервера установку TLS-соединения. Один из основных способов добиться этого — использовать другой номер порта для TLS-соединений. Порт 80 обычно используется для незашифрованного HTTP- трафика, а порт 443 — это общий порт, используемый для зашифрованного HTTPS- трафика. специфичного для протокола запроса STARTTLS Другой механизм заключается в отправке серверу для переключения соединения на TLS — например, при использовании протоколов почты и новостей .

Как только клиент и сервер согласились использовать TLS, они согласовывают соединение с отслеживанием состояния , используя процедуру квитирования (см. § Квитирование TLS ). Протоколы используют рукопожатие с асимметричным шифром для установки не только настроек шифрования, но и общего ключа для конкретного сеанса, с помощью которого дальнейшая связь шифруется с использованием симметричного шифра . Во время этого рукопожатия клиент и сервер согласовывают различные параметры, используемые для обеспечения безопасности соединения:

• Рукопожатие начинается, когда клиент подключается к серверу с поддержкой TLS, запрашивая безопасное соединение, и клиент представляет список поддерживаемых наборов шифров ( шифров и хеш-функций ).
• Из этого списка сервер выбирает шифр и хэш-функцию, которые он также поддерживает, и уведомляет клиента о решении.
• Затем сервер обычно предоставляет идентификацию в форме цифрового сертификата . Сертификат содержит имя сервера , доверенный центр сертификации (CA), который подтверждает подлинность сертификата, и общедоступный ключ шифрования сервера.
• Прежде чем продолжить, клиент подтверждает действительность сертификата.
• Чтобы сгенерировать сеансовые ключи, используемые для безопасного соединения, клиент либо:
  • шифрует случайное число ( PreMasterSecret ) с помощью открытого ключа сервера и отправляет результат на сервер (который только сервер должен иметь возможность расшифровать с помощью своего закрытого ключа); обе стороны затем используют случайное число для генерации уникального сеансового ключа для последующего шифрования и дешифрования данных во время сеанса, или
  • использует обмен ключами Диффи-Хеллмана (или его вариант DH с эллиптической кривой ) для безопасной генерации случайного и уникального сеансового ключа для шифрования и дешифрования, который имеет дополнительное свойство прямой секретности : если закрытый ключ сервера будет раскрыт в будущем, он не может быть раскрыт. используется для расшифровки текущего сеанса, даже если сеанс перехвачен и записан третьей стороной.

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

TLS и SSL не вписываются ни в один уровень модели OSI или модели TCP/IP . TLS работает «поверх какого-либо надежного транспортного протокола (например, TCP)». это означало бы, что он находится над транспортным уровнем . Он обеспечивает шифрование на более высоких уровнях, что обычно является функцией уровня представления . Однако приложения обычно используют TLS, как если бы это был транспортный уровень. даже несмотря на то, что приложения, использующие TLS, должны активно контролировать инициацию рукопожатий TLS и обработку обмененных сертификатов аутентификации.

При защите с помощью TLS соединения между клиентом (например, веб-браузером) и сервером (например, wikipedia.org) будут иметь все следующие свойства:

• Соединение является частным (или имеет конфиденциальность ), поскольку алгоритм симметричного ключа для шифрования передаваемых данных используется . Ключи для этого симметричного шифрования генерируются уникально для каждого соединения и основаны на общем секрете, согласованном в начале сеанса. Сервер и клиент согласовывают детали того, какой алгоритм шифрования и криптографические ключи использовать перед передачей первого байта данных (см. ниже). Согласование общего секрета одновременно безопасно (согласованный секрет недоступен для перехватчиков и не может быть получен даже злоумышленником, оказавшимся в середине соединения) и надежным (ни один злоумышленник не может изменить связь во время согласования, не будучи обнаружено).
• Личность взаимодействующих сторон может быть подтверждена с использованием криптографии с открытым ключом . Эта аутентификация необходима для сервера и необязательна для клиента.
• Соединение является надежным (или имеет целостность ), поскольку каждое передаваемое сообщение включает проверку целостности сообщения с использованием кода аутентификации сообщения, чтобы предотвратить необнаруженную потерю или изменение данных во время передачи.

TLS поддерживает множество различных методов обмена ключами, шифрования данных и проверки целостности сообщений. В результате безопасная конфигурация TLS включает в себя множество настраиваемых параметров, и не все варианты обеспечивают все свойства, связанные с конфиденциальностью, описанные в списке выше (см. таблицы ниже: § Обмен ключами , § Безопасность шифрования и § Целостность данных ).

Были предприняты попытки подорвать аспекты безопасности связи, которые стремится обеспечить TLS, и протокол несколько раз пересматривался для устранения этих угроз безопасности. Разработчики веб-браузеров неоднократно пересматривали свои продукты, чтобы защититься от потенциальных недостатков безопасности после того, как они были обнаружены (см. историю поддержки TLS/SSL веб-браузерами).

Безопасность транспортного уровня дейтаграмм

Безопасность транспортного уровня дейтаграмм, сокращенно DTLS, представляет собой родственный протокол связи , обеспечивающий безопасность приложений на основе дейтаграмм . , позволяя им взаимодействовать способом, разработанным специально для них для предотвращения подслушивания , фальсификации или подделки сообщений . Протокол DTLS основан на потокоориентированном протоколе Transport Layer Security (TLS) и предназначен для предоставления аналогичных гарантий безопасности. Однако, в отличие от TLS, его можно использовать с большинством протоколов, ориентированных на дейтаграммы, включая протокол пользовательских дейтаграмм (UDP), протокол управления перегрузкой дейтаграмм (DCCP), управление и обеспечение точек беспроводного доступа (CAPWAP), инкапсуляцию протокола передачи управления потоком (SCTP), и безопасный транспортный протокол реального времени (SRTP).

Поскольку дейтаграмма протокола DTLS сохраняет семантику базового транспорта — приложение не страдает от задержек, связанных с потоковыми протоколами, однако приложению приходится иметь дело с переупорядочением пакетов , потерей дейтаграммы и данными, превышающими размер дейтаграммной сети . пакет . Поскольку DTLS использует UDP или SCTP, а не TCP, он позволяет избежать «проблемы сбоя TCP». при использовании для создания VPN-туннеля.

Первоначальный выпуск DTLS версии 1.0 2006 года не был отдельным документом. Это было дано как серия дельт к TLS 1.1. Аналогично, последующий выпуск DTLS 2012 года является дельтой TLS 1.2. Ему был присвоен номер версии DTLS 1.2, соответствующий версии TLS. Наконец, DTLS 1.3 2022 года является версией TLS 1.3. Как и две предыдущие версии, DTLS 1.3 предназначен для предоставления «эквивалентных TLS 1.3 гарантий безопасности, за исключением защиты порядка/неповторяемости».

Многие VPN-клиенты , включая Cisco AnyConnect. и InterCloud Fabric, ОпенКоннект , ZScaler туннель, VPN-клиент F5 Networks Edge , и Citrix Systems NetScaler используйте DTLS для защиты UDP-трафика. Кроме того, все современные веб-браузеры поддерживают DTLS-SRTP. для WebRTC .

и

Протоколы SSL и TLS

Протокол	Опубликовано	Положение дел
Старая версия, больше не поддерживается: SSL 1.0.	Неопубликовано	Неопубликовано
Старая версия, больше не поддерживается: SSL 2.0.	1995	Устарело в 2011 году ( RFC 6176 )
Старая версия, больше не поддерживается: SSL 3.0.	1996	Устарело в 2015 году ( RFC 7568 )
Старая версия, больше не поддерживается: TLS 1.0.	1999	Устарело в 2021 году ( RFC 8996 )
Старая версия, больше не поддерживается: TLS 1.1.	2006	Устарело в 2021 году ( RFC 8996 )
Старая версия, но все еще поддерживается: TLS 1.2.	2008	В эксплуатации с 2008 года.
Текущая стабильная версия: TLS 1.3.	2018	В эксплуатации с 2018 года.

защищенной сети

Протокол безопасности транспортного уровня (TLS) вместе с несколькими другими базовыми платформами сетевой безопасности был разработан в рамках совместной инициативы, начатой ​​в августе 1986 года Агентством национальной безопасности, Национальным бюро стандартов, Агентством оборонной связи и двенадцатью организациями связи и связи. компьютерные корпорации, инициировавшие специальный проект под названием Secure Data Network System (SDNS). Программа была описана в сентябре 1987 года на 10-й Национальной конференции по компьютерной безопасности в обширном наборе опубликованных статей. Инновационная исследовательская программа была направлена ​​на разработку следующего поколения защищенной компьютерной сети связи и спецификаций продуктов, которые будут реализованы для приложений в общедоступных и частных сетях Интернет. Он был призван дополнить быстро возникающие новые интернет-стандарты OSI, продвигающиеся вперед как в профилях GOSIP правительства США, так и в огромных интернет-проектах ITU-ISO JTC1 на международном уровне. Первоначально известный как протокол SP4, он был переименован в TLS и впоследствии опубликован в 1995 году как международный стандарт ITU-T X.274|ISO/IEC 10736:1995.

Программирование безопасной сети (SNP)

Ранние исследования в области безопасности транспортного уровня включали Secure Network Programming (API ) интерфейс прикладного программирования (SNP ), который в 1993 году исследовал подход к созданию API безопасного транспортного уровня, очень напоминающего сокеты Беркли , для облегчения модернизации уже существующих сетевых приложений с обеспечением безопасности. меры. SNP был опубликован и представлен на USENIX 1994 года. Летней технической конференции Проект SNP финансировался за счет гранта АНБ профессора Саймона Лама из Юта-Остина в 1991 году. Безопасное сетевое программирование получило в 2004 году премию ACM Software System Award . Саймон Лам был занесен в Зал славы Интернета за «изобретение защищенных сокетов и внедрение первого уровня защищенных сокетов, названного SNP, в 1993 году».

SSL 1.0, 2.0 и 3.0

«SSL 1» перенаправляется сюда. Чтобы узнать об этом ферменте, см. Пресквалэндифосфатсинтаза .

Netscape разработала оригинальные протоколы SSL, а Тахер Эльгамал , главный научный сотрудник Netscape Communications с 1995 по 1998 год, был назван «отцом SSL». SSL версии 1.0 никогда не публиковался публично из-за серьезных недостатков безопасности протокола. Версия 2.0, выпущенная в феврале 1995 года, быстро обнаружила ряд недостатков безопасности и удобства использования. Он использовал одни и те же криптографические ключи для аутентификации и шифрования сообщений. У него была слабая конструкция MAC, в которой использовалась хеш-функция MD5 с секретным префиксом, что делало его уязвимым для атак с расширением длины. Он также не обеспечивал защиты ни при первом рукопожатии, ни при явном закрытии сообщения, что означало, что атаки «человек посередине» могли остаться незамеченными. Более того, SSL 2.0 предполагал единую службу и фиксированный сертификат домена, что противоречило широко используемой функции виртуального хостинга на веб-серверах, поэтому большинство веб-сайтов фактически были лишены возможности использовать SSL.

Эти недостатки потребовали полной переработки протокола до версии SSL 3.0. Выпущенный в 1996 году, он был создан Полом Кохером в сотрудничестве с инженерами Netscape Филом Карлтоном и Аланом Фрейером, а эталонная реализация - Кристофером Алленом и Тимом Дирксом из Certicom. Новые версии SSL/TLS основаны на SSL 3.0. Проект SSL 3.0 1996 года был опубликован IETF как исторический документ в РФК   6101 .

SSL 2.0 устарел в 2011 году. РФК   6176 . В 2014 году было обнаружено, что SSL 3.0 уязвим для атаки POODLE , которая затрагивает все блочные шифры в SSL; RC4 , единственный неблочный шифр, поддерживаемый SSL 3.0, также может быть взломан, как и в SSL 3.0. SSL 3.0 устарел в июне 2015 г. RFC   7568 .

TLS 1.0

TLS 1.0 был впервые определен в RFC   2246, выпущенный в январе 1999 года как обновление SSL версии 3.0 и написанный Кристофером Алленом и Тимом Дирксом из Certicom. Как указано в RFC, «различия между этим протоколом и SSL 3.0 не значительны, но они достаточно значительны, чтобы исключить возможность взаимодействия между TLS 1.0 и SSL 3.0». Тим Диркс позже написал, что эти изменения, а также переименование с «SSL» на «TLS» были жестом спасения лица для Microsoft, «чтобы это не выглядело [как будто] IETF просто штамповал протокол Netscape».

Совет PCI предложил организациям перейти с TLS 1.0 на TLS 1.1 или выше до 30 июня 2018 года. В октябре 2018 года Apple , Google , Microsoft и Mozilla совместно объявили о прекращении поддержки TLS 1.0 и 1.1 в марте 2020 года. TLS 1.0 и 1.1 официально объявлены устаревшими в RFC   8996 в марте 2021 г.

TLS 1.1

TLS 1.1 был определен в RFC 4346 в апреле 2006 года. Это обновление TLS версии 1.0. К существенным отличиям этой версии относятся:

• Добавлена ​​защита от атак с использованием цепочки блоков шифрования (CBC).
  • Вектор неявной инициализации (IV) был заменен явным IV.
  • Изменение в обработке ошибок заполнения .
• Поддержка IANA . регистрации параметров

Поддержка TLS версий 1.0 и 1.1 была широко признана устаревшей на веб-сайтах примерно в 2020 году, что отключило доступ к версиям Firefox до 24 и браузерам на основе Chromium до 29.

TLS 1.2

TLS 1.2 был определен в RFC 5246 в августе 2008 года. Он основан на более ранней спецификации TLS 1.1. Основные различия включают в себя:

• Комбинация MD5 и SHA-1 в псевдослучайной функции (PRF) была заменена на SHA-256 с возможностью использования PRF, указанного набором шифров .
• Комбинация MD5 и SHA-1 в готовом хеше сообщения была заменена на SHA-256 с возможностью использования алгоритмов хэширования, специфичных для набора шифров. Однако размер хеша в готовом сообщении все равно должен быть не менее 96 бит .
• Комбинация MD5 и SHA-1 в элементе с цифровой подписью была заменена одним хешем, согласованным во время рукопожатия , который по умолчанию равен SHA-1.
• Расширение возможностей клиента и сервера указывать, какие хэши и алгоритмы подписи они принимают.
• Расширение поддержки аутентифицированных шифров шифрования, используемых в основном для режима Галуа/счетчика (GCM) и режима CCM шифрования Advanced Encryption Standard (AES).
• Были добавлены определения расширений TLS и наборы шифров AES.

Все версии TLS были дополнительно усовершенствованы в RFC   6176 в марте 2011 года, удаляющий обратную совместимость с SSL, так что сеансы TLS никогда не согласовывают использование Secure Sockets Layer (SSL) версии 2.0. В настоящее время официальной даты прекращения поддержки TLS 1.2 не существует. Спецификации TLS 1.2 также были переопределены в документе Standards Track Document. RFC   8446 , чтобы обеспечить максимальную безопасность, плюс теперь его следует рассматривать как протокол аварийного переключения, предназначенный только для согласования с клиентами, которые не могут обмениваться данными по TLS 1.3 (исходное определение RFC 5246 для TLS 1.2 с тех пор устарело! ).

TLS 1.3

TLS 1.3 был определен в RFC 8446 в августе 2018 года. Он основан на более ранней спецификации TLS 1.2. Основные отличия от TLS 1.2 включают в себя:

• Отделение алгоритмов согласования ключей и аутентификации от наборов шифров.
• Удаление поддержки слабых и редко используемых именованных эллиптических кривых.
• Удаление поддержки криптографических хеш-функций MD5 и SHA-224.
• Требование цифровых подписей даже при использовании предыдущей конфигурации
• Интеграция HKDF и полуэфемерного предложения DH
• Замена возобновления на ПСК и билеты
• Поддержка рукопожатий 1- RTT и начальная поддержка 0- RTT
• Требование полной прямой секретности посредством использования эфемерных ключей во время соглашения о ключах (EC)DH.
• Прекращение поддержки многих небезопасных или устаревших функций, включая сжатие , повторное согласование, отличные от AEAD шифры, , нулевые шифры , обмен ключами, не относящимися к PFS (среди которых статический RSA и статический DH обмен ключами ), пользовательские группы DHE , согласование формата точки EC, протокол изменения спецификации шифрования, время UNIX сообщения Hello и ввод AD поля длины для шифров AEAD
• Запрет согласования SSL или RC4 для обеспечения обратной совместимости.
• Интеграция использования хэша сеанса
• Отказ от использования номера версии слоя записи и замораживание этого номера для улучшения обратной совместимости.
• Перемещение некоторых деталей алгоритма, связанных с безопасностью, из приложения в спецификацию и перенос ClientKeyShare в приложение.
• Добавление потокового шифра ChaCha20 с Poly1305. кодом аутентификации сообщения
• Добавление Ed25519 и Ed448. алгоритмов цифровой подписи
• Добавление x25519 и x448. протоколов обмена ключами
• Добавление поддержки отправки нескольких OCSP ответов
• Шифрование всех сообщений подтверждения после ServerHello

Network Security Services (NSS), криптографическая библиотека, разработанная Mozilla и используемая ее веб-браузером Firefox , по умолчанию включила TLS 1.3 в феврале 2017 года. Впоследствии была добавлена ​​поддержка TLS 1.3, но из-за проблем совместимости для небольшого числа пользователей она не включалась автоматически. — до Firefox 52.0 , выпущенного в марте 2017 года. TLS 1.3 был включен по умолчанию в мае 2018 года с выпуском Firefox 60.0 .

Google Chrome установил TLS 1.3 в качестве версии по умолчанию на короткое время в 2017 году. Затем он удалил его как версию по умолчанию из-за несовместимости промежуточных программ, таких как веб-прокси Blue Coat .

Непереносимость новой версии TLS заключалась в закостенении протокола ; промежуточные коробки закостенели параметр версии протокола. В результате версия 1.3 имитирует образ провода версии 1.2. Это изменение произошло очень поздно в процессе проектирования и было обнаружено только во время развертывания браузера. Обнаружение этой нетерпимости также привело к тому, что стратегия согласования предыдущей версии, в которой выбиралась версия с наибольшим соответствием, была отвергнута из-за неработоспособного уровня окостенения. « Смазка » точки расширения, когда один из участников протокола заявляет о поддержке несуществующих расширений, чтобы гарантировать, что нераспознанные, но фактически существующие расширения допускаются и, таким образом, противостоять оссификации, изначально была разработана для TLS, но с тех пор была принята в других местах. .

IETF 100 Во время хакатона , который проходил в Сингапуре в 2017 году, группа TLS работала над адаптацией приложений с открытым исходным кодом для использования TLS 1.3. Группа TLS состояла из людей из Японии, Великобритании и Маврикия через команду cyberstorm.mu. Эта работа была продолжена на хакатоне IETF 101 в Лондоне . и хакатон IETF 102 в Монреале.

wolfSSL позволил использовать TLS 1.3 начиная с версии 3.11.1, выпущенной в мае 2017 года. WolfSSL 3.11.1, первая коммерческая реализация TLS 1.3, поддерживала Draft 18, а теперь поддерживает Draft 28. финальная версия, а также многие старые версии. Была опубликована серия блогов о разнице в производительности между TLS 1.2 и 1.3.

В Сентябрь 2018 г. популярный проект OpenSSL выпустил версию 1.1.1 своей библиотеки, в которой поддержка TLS 1.3 была «главной новой функцией».

Поддержка TLS 1.3 была добавлена ​​в Secure Channel (schannel) для общедоступных выпусков Windows 11 и Windows Server 2022 .

Транспортная безопасность предприятия

Фонд Electronic Frontier Foundation похвалил TLS 1.3 и выразил обеспокоенность по поводу варианта протокола Enterprise Transport Security (ETS), который намеренно отключает важные меры безопасности в TLS 1.3. ETS, первоначально называвшийся Enterprise TLS (eTLS), представляет собой опубликованный стандарт, известный как « ETSI TS103523-3», «Протокол безопасности промежуточного блока, часть 3: Транспортная безопасность предприятия». Он предназначен для использования исключительно в частных сетях, таких как банковские системы. ETS не поддерживает прямую секретность, чтобы позволить сторонним организациям, подключенным к частным сетям, использовать свой закрытый ключ для мониторинга сетевого трафика с целью обнаружения вредоносного ПО и упростить проведение аудита. Несмотря на заявленные преимущества, EFF предупредил, что потеря прямой секретности может облегчить раскрытие данных, а также заявил, что существуют более эффективные способы анализа трафика.

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

Основная статья: Сертификат открытого ключа

Пример сайта с цифровым сертификатом

Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата и указывает на определенные ожидаемые варианты использования этого ключа. Это позволяет другим (проверяющим сторонам) полагаться на подписи или утверждения, сделанные с помощью закрытого ключа, который соответствует сертифицированному открытому ключу. Хранилища ключей и хранилища доверенных сертификатов могут иметь различные форматы, например .pem , .crt, .pfx и .jks .

Центры сертификации

Основная статья: Центр сертификации

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

По данным Netcraft , которая отслеживает активные сертификаты TLS, ведущим на рынке центром сертификации (CA) была Symantec с начала исследования (или VeriSign до того, как Symantec приобрела бизнес-подразделение служб аутентификации). По данным Netcraft, по состоянию на 2015 год на долю Symantec приходилось чуть менее трети всех сертификатов и 44% действительных сертификатов, используемых 1 миллионом самых загруженных веб-сайтов. В 2017 году Symantec продала свой бизнес TLS/SSL компании DigiCert. В обновленном отчете было показано, что IdenTrust , DigiCert и Sectigo входят в тройку крупнейших центров сертификации по доле рынка с мая 2019 года.

Как следствие выбора сертификатов X.509 , центры сертификации и инфраструктура открытых ключей необходимы для проверки связи между сертификатом и его владельцем, а также для создания, подписания и управления действительностью сертификатов. Хотя это может быть более удобно, чем проверка личности через сеть доверия , раскрытие информации о массовой слежке в 2013 году сделало более широко известным, что центры сертификации являются слабым местом с точки зрения безопасности, допуская атаки «человек посередине» (MITM). если центр сертификации сотрудничает (или скомпрометирован).

Важность

• Шифрование : сертификаты SSL шифруют данные, передаваемые между веб-сервером и браузером пользователя, обеспечивая защиту конфиденциальной информации во время передачи. Эта технология шифрования не позволяет неавторизованным лицам перехватывать и интерпретировать данные, тем самым защищая их от возможных рисков, таких как взлом или утечка данных.
• Аутентификация : SSL-сертификаты также обеспечивают аутентификацию, удостоверяя целостность веб-сайта и то, что посетители подключаются к правильному серверу, а не к злонамеренному самозванцу. Этот метод аутентификации помогает потребителям завоевать доверие, гарантируя, что они имеют дело с надежным и безопасным веб-сайтом.
• Целостность . Еще одна важная роль SSL-сертификатов — обеспечение целостности данных. SSL использует криптографические методы для проверки целостности и неизменности данных, передаваемых между сервером и браузером во время передачи. Это предотвращает вмешательство злоумышленников в данные, обеспечивая их целостность и надежность.

Алгоритмы

См. также: Набор шифров.

Обмен ключами или соглашение о ключах

Прежде чем клиент и сервер смогут начать обмениваться информацией, защищенной TLS, они должны безопасно обменяться или согласовать ключ шифрования и шифр, которые будут использоваться при шифровании данных (см. § Шифр ). Среди методов, используемых для обмена/согласования ключей, можно назвать: открытые и закрытые ключи, генерируемые с помощью RSA (обозначаемые TLS_RSA в протоколе установления связи TLS), Диффи-Хеллмана (TLS_DH), эфемерные ключи Диффи-Хеллмана (TLS_DHE), эллиптические кривые Диффи-Хеллмана ( TLS_ECDH), эфемерная эллиптическая кривая Диффи-Хеллмана (TLS_ECDHE), анонимная Диффи-Хеллмана (TLS_DH_anon), предварительный общий ключ (TLS_PSK) и безопасный удаленный пароль (TLS_SRP).

Методы соглашения о ключах TLS_DH_anon и TLS_ECDH_anon не аутентифицируют сервер или пользователя и, следовательно, используются редко, поскольку они уязвимы для атак «человек посередине» . Только TLS_DHE и TLS_ECDHE обеспечивают прямую секретность .

Сертификаты открытых ключей, используемые во время обмена/согласования, также различаются по размеру открытых/частных ключей шифрования, используемых во время обмена, и, следовательно, по надежности обеспечиваемой безопасности. В июле 2013 года Google объявил, что больше не будет использовать 1024-битные открытые ключи и вместо этого перейдет на 2048-битные ключи, чтобы повысить безопасность шифрования TLS, которое он предоставляет своим пользователям, поскольку надежность шифрования напрямую связана с размером ключа. .

Обмен ключами/согласование и аутентификация

Алгоритм	SSL 2.0	SSL 3.0	ТЛС 1.0	ТЛС 1.1	ТЛС 1.2	ТЛС 1.3	Положение дел
ЮАР	Да	Да	Да	Да	Да	Нет	Определено для TLS 1.2 в RFC.
ДХ – ЮАР	Нет	Да	Да	Да	Да	Нет
И - RSA ( прямая секретность )	Нет	Да	Да	Да	Да	Да
ECDH – ЮАР	Нет	Нет	Да	Да	Да	Нет
ECDHE - RSA (прямая секретность)	Нет	Нет	Да	Да	Да	Да
ДХ  – ДСС	Нет	Да	Да	Да	Да	Нет
DHE - DSS (прямая секретность)	Нет	Да	Да	Да	Да	Нет
И - ECDSA (прямая секретность)	Нет	Нет	Нет	Нет	Нет	Да
ECDH  – ECDSA	Нет	Нет	Да	Да	Да	Нет
ECDHE - ECDSA (прямая секретность)	Нет	Нет	Да	Да	Да	Да
И - EdDSA (прямая секретность)	Нет	Нет	Нет	Нет	Нет	Да
ECDH  – EdDSA	Нет	Нет	Да	Да	Да	Нет
ECDHE – EdDSA (прямая секретность)	Нет	Нет	Да	Да	Да	Да
ПСК	Нет	Нет	Да	Да	Да	Да
ЮАР - ПСК	Нет	Нет	Да	Да	Да	Нет
И - ПСК (прямая секретность)	Нет	Нет	Да	Да	Да	Да
ECDHE - PSK (прямая секретность)	Нет	Нет	Да	Да	Да	Да
рекомендуемая розничная цена	Нет	Нет	Да	Да	Да	Нет
СРП  – ДСС	Нет	Нет	Да	Да	Да	Нет
Рекомендуемая розничная цена – ЮАР	Нет	Нет	Да	Да	Да	Нет
Керберос	Нет	Нет	Да	Да	Да	?
ДХ -АНОН (небезопасно)	Нет	Да	Да	Да	Да	Нет
ECDH -ANON (небезопасно)	Нет	Нет	Да	Да	Да	Нет
ГОСТ Р 34.10-2012.	Нет	Нет	Нет	Нет	Да	Да	Определено для TLS 1.2 и TLS 1.3 в РФК   9189 , 9367 .

Шифр

См. также: Набор шифров , Блочный шифр и Обзор безопасности шифрования.

Шифровая защита от общеизвестных возможных атак

Шифр			Версия протокола						Положение дел
Тип	Алгоритм	Номинальная мощность (биты)	SSL 2.0	SSL 3.0	ТЛС 1.0	ТЛС 1.1	ТЛС 1.2	ТЛС 1.3
Блочный шифр с режим работы	AES GCM	256, 128	—	—	—	—	Безопасный	Безопасный	Определено для TLS 1.2 в RFC.
	АЭС ККМ		—	—	—	—	Безопасный	Безопасный
	АЭС ЦБК		—	Ненадежный	Зависит от смягчения последствий	Зависит от смягчения последствий	Зависит от смягчения последствий	—
	Камелия ГЦМ	256, 128	—	—	—	—	Безопасный	—
	Камелия СВС		—	Ненадежный	Зависит от смягчения последствий	Зависит от смягчения последствий	Зависит от смягчения последствий	—
	АРИА ГЦМ	256, 128	—	—	—	—	Безопасный	—
	АРИЯ ЦБК		—	—	Зависит от смягчения последствий	Зависит от смягчения последствий	Зависит от смягчения последствий	—
	СЕМЕНА CBC	128	—	Ненадежный	Зависит от смягчения последствий	Зависит от смягчения последствий	Зависит от смягчения последствий	—
	3DES ЭДЕ ЦБК	112	Ненадежный	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—
	ГОСТ Р 34.12-2015 Магма ЦТР.	256	—	—	Ненадежный	Ненадежный	Ненадежный	—	Определено в RFC   4357 , 9189
	GOST R 34.12-2015 Кузнечик CTR	256	—	—	—	—	Безопасный	—	Определено в RFC   9189
	ГОСТ Р 34.12-2015 Магма МГМ.	256	—	—	—	—	—	Ненадежный	Определено в RFC   9367
	GOST R 34.12-2015 Кузнечик MGM	256	—	—	—	—	—	Безопасный	Определено в RFC   9367
	ИДЕЯ CBC	128	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	—	Удален из TLS 1.2.
	ДЕС CBC	0 56	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	—
		0 40	Ненадежный	Ненадежный	Ненадежный	—	—	—	Запрещено в TLS 1.1 и более поздних версиях.
	RC2 CBC	0 40	Ненадежный	Ненадежный	Ненадежный	—	—	—
Потоковое шифрование	ЧаЧа20 - Poly1305	256	—	—	—	—	Безопасный	Безопасный	Определено для TLS 1.2 в RFC.
	RC4	128	Ненадежный	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	Запрещено во всех версиях TLS RFC   7465
		0 40	Ненадежный	Ненадежный	Ненадежный	—	—	—
Никто	Нулевой	–	Ненадежный	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	Определено для TLS 1.2 в RFC.

Примечания

Целостность данных

Код аутентификации сообщения (MAC) используется для обеспечения целостности данных. HMAC используется для CBC режима блочных шифров . Шифрование с проверкой подлинности (AEAD), такое как режим GCM и CCM , использует интегрированный с AEAD MAC и не использует HMAC . на основе HMAC PRF или HKDF используется для подтверждения TLS.

Целостность данных

Алгоритм	SSL 2.0	SSL 3.0	ТЛС 1.0	ТЛС 1.1	ТЛС 1.2	ТЛС 1.3	Положение дел
HMAC - MD5	Да	Да	Да	Да	Да	Нет	Определено для TLS 1.2 в RFC.
HMAC  – SHA1	Нет	Да	Да	Да	Да	Нет
HMAC — SHA256/384	Нет	Нет	Нет	Нет	Да	Нет
АЕАД	Нет	Нет	Нет	Нет	Да	Да
ГОСТ 28147-89 ИМИТ.	Нет	Нет	Нет	Нет	Да	Нет	Определено для TLS 1,2 дюйма. РФК   9189 .
ГОСТ Р 34.12-2015 АЕАД.	Нет	Нет	Нет	Нет	Нет	Да	Определено для TLS 1,3 дюйма. RFC   9367 .

и

При разработке приложений TLS обычно реализуется поверх протоколов транспортного уровня, шифруя все связанные с протоколами данные таких протоколов, как HTTP , FTP , SMTP , NNTP и XMPP .

Исторически TLS использовался в основном с надежными транспортными протоколами, такими как протокол управления передачей (TCP). Однако он также был реализован с помощью транспортных протоколов, ориентированных на дейтаграммы, таких как протокол пользовательских дейтаграмм (UDP) и протокол управления перегрузкой дейтаграмм (DCCP), использование которых было стандартизировано независимо с использованием термина безопасность транспортного уровня дейтаграмм ( DTLS ). .

Веб-сайты

Основное использование TLS — защита Всемирной паутины трафика между веб-сайтом и веб-браузером, закодированного по протоколу HTTP. Такое использование TLS для защиты HTTP-трафика представляет собой протокол HTTPS .

Поддержка протокола веб-сайта (май 2024 г.)

Протокол версия	Веб-сайт поддерживать	Безопасность
Старая версия, больше не поддерживается: SSL 2.0.	0.1%	Ненадежный
Старая версия, больше не поддерживается: SSL 3.0.	1.4%	Ненадежный
Старая версия, больше не поддерживается: TLS 1.0.	27.9%	Устарело
Старая версия, больше не поддерживается: TLS 1.1.	30.0%	Устарело
Старая версия, но все еще поддерживается: TLS 1.2.	99.9%	Зависит от шифра и смягчение последствий для клиентов
Текущая стабильная версия: TLS 1.3.	70.1%	Безопасный

Примечания

Веб-браузеры

Дополнительная информация о поддержке TLS/SSL в веб-браузерах: История версий поддержки TLS/SSL в веб-браузерах и Сравнение веб-браузеров.

По состоянию на апрель 2016 г. , последние версии всех основных веб-браузеров поддерживают TLS 1.0, 1.1 и 1.2 и включены по умолчанию. Однако не все поддерживаемые операционные системы Microsoft поддерживают последнюю версию IE. Кроме того, многие операционные системы Microsoft в настоящее время поддерживают несколько версий IE, но это изменилось в соответствии с часто задаваемыми вопросами о политике жизненного цикла поддержки Microsoft Internet Explorer. Архивировано 20 июня 2023 г. на Wayback Machine , «начиная с 12 января 2016 г., только самая последняя версия Internet Explorer, доступный для поддерживаемой операционной системы, получит техническую поддержку и обновления безопасности». Затем на странице отображается последняя поддерживаемая версия IE на тот момент для каждой операционной системы. Следующей критической датой станет момент, когда операционная система достигнет стадии конца жизненного цикла. С 15 июня 2022 года в Internet Explorer 11 прекращена поддержка выпусков Windows 10 , соответствующих Политике современного жизненного цикла Microsoft.

Мер по защите от известных атак пока недостаточно:

• Меры по смягчению последствий атаки POODLE : некоторые браузеры уже предотвращают переход на SSL 3.0; однако это снижение должно поддерживаться не только клиентами, но и серверами. Требуется отключение самого SSL 3.0, реализация «разделения записей анти-POODLE» или отказ от шифров CBC в SSL 3.0.
  • Google Chrome: завершено (TLS_FALLBACK_SCSV реализован с версии 33, переход на SSL 3.0 отключен с версии 39, сам SSL 3.0 отключен по умолчанию с версии 40. Поддержка самого SSL 3.0 прекращена с версии 44.)
  • Mozilla Firefox: завершено (поддержка самого SSL 3.0 прекращена с версии 39. Сам SSL 3.0 отключен по умолчанию, а переход на SSL 3.0 отключен с версии 34 , TLS_FALLBACK_SCSV реализован с версии 35. В ESR сам SSL 3.0 отключен с помощью по умолчанию, а TLS_FALLBACK_SCSV реализован начиная с ESR 31.3.0.)
  • Internet Explorer: частично (только в версии 11, SSL 3.0 по умолчанию отключен с апреля 2015 года. Версия 10 и старше по-прежнему уязвимы для POODLE).
  • Opera : завершено (TLS_FALLBACK_SCSV реализован с версии 20, «разбиение записей анти-POODLE», которое эффективно только при реализации на стороне клиента, реализовано с версии 25, сам SSL 3.0 отключен по умолчанию, начиная с версии 27. Поддержка SSL 3.0 сам будет удален, начиная с версии 31.)
  • Safari: полный (только в OS X 10.8 и более поздних версиях и iOS 8, шифрование CBC при переходе на SSL 3.0 запрещено, но это означает, что он будет использовать RC4, что также не рекомендуется. Поддержка самого SSL 3.0 прекращена в OS X 10.11 и более поздних версий и iOS 9.)
• Защита от атак RC4 :
  • Google Chrome отключил RC4, за исключением резервного варианта, начиная с версии 43. RC4 отключен, начиная с Chrome 48.
  • Firefox отключил RC4, кроме как в качестве запасного варианта, начиная с версии 36. Firefox 44 отключил RC4 по умолчанию.
  • Opera отключила RC4, за исключением запасных вариантов, начиная с версии 30. RC4 отключен, начиная с Opera 35.
  • Internet Explorer для Windows 7 /Server 2008 R2 и Windows 8 /Server 2012 установил самый низкий приоритет RC4 и также может отключить RC4, кроме как в качестве резервного варианта через настройки реестра. Internet Explorer 11 Mobile 11 для Windows Phone 8.1 отключит RC4, за исключением случаев, когда другой включенный алгоритм не работает. Edge и IE 11 полностью отключили RC4 в августе 2016 года.
• Смягчение последствий атаки FREAK :
  • Браузер Android, входящий в состав Android 4.0 и более ранних версий, по-прежнему уязвим для атаки FREAK.
  • Internet Explorer 11 Mobile по-прежнему уязвим для атаки FREAK.
  • В Google Chrome, Internet Explorer (настольный компьютер), Safari (настольный компьютер и мобильный телефон) и Opera (мобильный телефон) предусмотрены ЧУДЕСНЫЕ средства защиты.
  • FREAK не затронул Mozilla Firefox на всех платформах и Google Chrome в Windows.

Библиотеки

Основная статья: Сравнение реализаций TLS

Дополнительная информация о поддержке версий протокола в библиотеках: Сравнение реализаций TLS § Поддержка версий TLS.

Большинство библиотек программирования SSL и TLS являются бесплатным программным обеспечением с открытым исходным кодом .

• BoringSSL — форк OpenSSL для Chrome/Chromium и Android, а также других приложений Google.
• Botan — криптографическая библиотека под лицензией BSD, написанная на C++.
• BSAFE Micro Edition Suite: многоплатформенная реализация TLS, написанная на C с использованием криптографического модуля, проверенного FIPS.
• BSAFE SSL-J: библиотека TLS, предоставляющая как собственный API, так и API JSSE , с использованием криптографического модуля, проверенного FIPS.
• cryptlib : портативная криптографическая библиотека с открытым исходным кодом (включает реализацию TLS/SSL).
• Программисты Delphi могут использовать библиотеку Indy , которая использует OpenSSL , или, альтернативно, ICS, которая теперь поддерживает TLS 1.3.
• GnuTLS : бесплатная реализация (лицензия LGPL)
• Расширение Java Secure Socket Extension (JSSE): Java API и реализация поставщика (названная SunJSSE).
• LibreSSL : форк OpenSSL от проекта OpenBSD.
• MatrixSSL : реализация с двойной лицензией.
• Mbed TLS (ранее PolarSSL): небольшая реализация библиотеки SSL для встроенных устройств, разработанная для простоты использования.
• Службы сетевой безопасности : стандарту FIPS 140. проверенная библиотека с открытым исходным кодом по
• OpenSSL : бесплатная реализация (лицензия BSD с некоторыми расширениями)
• Schannel : реализация SSL и TLS Microsoft Windows как часть ее пакета.
• Secure Transport : реализация SSL и TLS, используемая в OS X и iOS как часть их пакетов.
• wolfSSL (ранее CyaSSL): встроенная библиотека SSL/TLS с упором на скорость и размер.

Документ, представленный на конференции ACM 2012 года по компьютерной и коммуникационной безопасности. показал, что многие приложения неправильно использовали некоторые из этих библиотек SSL, что приводило к уязвимостям. По мнению авторов:

«Основной причиной большинства этих уязвимостей является ужасный дизайн API для базовых библиотек SSL. Вместо того, чтобы выражать высокоуровневые свойства безопасности сетевых туннелей, такие как конфиденциальность и аутентификация, эти API раскрывают низкоуровневые детали протокола SSL. разработчикам приложений. Как следствие, разработчики часто неправильно используют SSL API, неправильно интерпретируя и неправильно понимая их многочисленные параметры, параметры, побочные эффекты и возвращаемые значения».

Другое использование

Простой протокол передачи почты (SMTP) также может быть защищен с помощью TLS. Эти приложения используют сертификаты открытых ключей для проверки подлинности конечных точек.

TLS также можно использовать для туннелирования всего сетевого стека для создания VPN , как в случае с OpenVPN и OpenConnect . Многие поставщики к настоящему времени объединили возможности шифрования и аутентификации TLS с авторизацией. С конца 1990-х годов также произошел значительный прогресс в создании клиентских технологий за пределами веб-браузеров, чтобы обеспечить поддержку клиент-серверных приложений. По сравнению с традиционными технологиями IPsec VPN, TLS имеет некоторые преимущества при обходе брандмауэра и NAT , которые упрощают администрирование для больших групп пользователей, имеющих удаленный доступ.

TLS также является стандартным методом защиты сигнализации приложений протокола инициации сеанса (SIP). TLS может использоваться для обеспечения аутентификации и шифрования сигнализации SIP, связанной с VoIP и другими приложениями на основе SIP.

Безопасность

Атаки на TLS/SSL

Ниже перечислены серьезные атаки на TLS/SSL.

В феврале 2015 года IETF выпустил информационный RFC. суммирование различных известных атак на TLS/SSL.

Атака повторного согласования

В августе 2009 года была обнаружена уязвимость процедуры повторного согласования, которая может привести к атакам путем внедрения открытого текста против SSL 3.0 и всех текущих версий TLS. Например, это позволяет злоумышленнику, который может перехватить https-соединение, вставить свои собственные запросы в начало диалога клиента с веб-сервером. Злоумышленник фактически не может расшифровать связь клиент-сервер, поэтому она отличается от типичной атаки «человек посередине». Краткосрочное решение заключается в том, что веб-серверы перестанут разрешать повторное согласование, которое обычно не требует других изменений, если не сертификата клиента используется проверка подлинности . Чтобы устранить уязвимость, для TLS было предложено расширение индикации повторного согласования. Клиенту и серверу потребуется включать и проверять информацию о предыдущих рукопожатиях при любых рукопожатиях повторного согласования. Это расширение стало предлагаемым стандартом и получило номер РФК   5746 . RFC реализован несколькими библиотеками.

Атаки на понижение версии: и Logjam

Основные статьи: Атака на понижение версии , FREAK и Logjam (компьютерная безопасность)

протокола Атака с понижением версии (также называемая атакой с откатом версии) заставляет веб-сервер согласовывать соединения с предыдущими версиями TLS (такими как SSLv2), от которых уже давно отказались как от небезопасных.

Предыдущие модификации исходных протоколов, такие как фальстарт. (принято и включено Google Chrome ) или Snap Start , как сообщается, ввели ограниченные атаки на понижение версии протокола TLS. или разрешенные изменения в списке наборов шифров, отправленном клиентом на сервер. При этом злоумышленнику может удастся повлиять на выбор набора шифров, пытаясь понизить набор шифров, согласованный для использования либо более слабого алгоритма симметричного шифрования, либо более слабого обмена ключами. В документе, представленном на конференции ACM по компьютерной и коммуникационной безопасности в 2012 году, показано, что расширение False Start находится под угрозой: при определенных обстоятельствах оно может позволить злоумышленнику восстановить ключи шифрования в автономном режиме и получить доступ к зашифрованным данным.

Атаки с понижением шифрования могут заставить серверы и клиенты согласовывать соединение с использованием криптографически слабых ключей. В 2014 году «человек посередине» была обнаружена атака под названием FREAK, затронувшая стек OpenSSL по умолчанию , веб-браузер Android и некоторые браузеры Safari . Атака заключалась в том, чтобы заставить серверы согласовать соединение TLS с использованием криптографически слабых 512-битных ключей шифрования.

Logjam — это уязвимость безопасности , обнаруженная в мае 2015 года, которая использует возможность использования устаревших «экспортного уровня», 512-битных групп Диффи-Хеллмана созданных еще в 1990-х годах. Это вынуждает уязвимые серверы перейти на криптографически слабые 512-битные группы Диффи-Хеллмана. Затем злоумышленник может вывести ключи, которые клиент и сервер определяют, используя обмен ключами Диффи-Хеллмана .

Межпротокольные атаки: DROWN

Основная статья: Атака DROWN

Атака DROWN — это эксплойт, который атакует серверы, поддерживающие современные наборы протоколов SSL/TLS, используя их поддержку устаревшего, небезопасного протокола SSLv2, чтобы использовать атаку на соединения с использованием современных протоколов, которые в противном случае были бы безопасными. DROWN использует уязвимость в используемых протоколах и конфигурации сервера, а не какую-либо конкретную ошибку реализации. Полная информация о DROWN была объявлена ​​в марте 2016 года вместе с патчем для этого эксплойта. На тот момент более 81 000 из 1 миллиона самых популярных веб-сайтов входили в число защищенных TLS веб-сайтов, уязвимых для атаки DROWN.

Атака ЗВЕРЯ

23 сентября 2011 года исследователи Тай Дуонг и Джулиано Риццо продемонстрировали доказательство концепции под названием BEAST ( Browser Exploit Against SSL/TLS ). использование Java-апплета для нарушения ограничений политики одного и того же происхождения для давно известной уязвимости цепочки блоков шифра (CBC) в TLS 1.0: злоумышленник, наблюдая за двумя последовательными блоками зашифрованного текста C0, C1, может проверить, равен ли блок открытого текста P1 x, выбрав следующий блок открытого текста P2 = x ⊕ C0 ⊕ C1 ; согласно операции CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , что будет равно C1, если x = P1 . Практические эксплойты ранее не были продемонстрированы для этой уязвимости , первоначально ее обнаружил Филипп Рогауэй. в 2002 году. Уязвимость атаки была исправлена ​​с помощью TLS 1.1 в 2006 году, но TLS 1.1 не получил широкого распространения до демонстрации этой атаки.

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

Сами Chrome и Firefox не уязвимы для атаки BEAST. однако Mozilla обновила свои библиотеки NSS, , подобные BEAST чтобы смягчить атаки . NSS используется Mozilla Firefox и Google Chrome для реализации SSL. некоторые веб-серверы с некорректной реализацией спецификации SSL могут перестать работать. В результате

10 января 2012 года компания Microsoft выпустила бюллетень по безопасности MS12-006, в котором исправлена ​​уязвимость BEAST путем изменения способа передачи компонентом Windows Secure Channel ( Schannel ) зашифрованных сетевых пакетов со стороны сервера. Пользователи Internet Explorer (до версии 11), работающие в более старых версиях Windows ( Windows 7 , Windows 8 и Windows Server 2008 R2 ), могут ограничить использование TLS до версии 1.1 или выше.

Apple устранила уязвимость BEAST, реализовав разделение 1/n-1 и включив его по умолчанию в OS X Mavericks , выпущенной 22 октября 2013 года.

ПРЕСТУПНОСТИ и НАРУШЕНИЯ

Основные статьи: ПРЕСТУПЛЕНИЕ и НАРУШЕНИЕ

Авторы атаки BEAST также являются создателями более поздней атаки CRIME , которая может позволить злоумышленнику восстановить содержимое веб-cookie при сжатия данных вместе с TLS. использовании При использовании для восстановления содержимого секретных файлов cookie аутентификации злоумышленник может перехватить сеанс в веб-сеансе с аутентификацией.

Хотя атака CRIME была представлена ​​как общая атака, которая могла эффективно работать против большого количества протоколов, включая, помимо прочего, TLS и протоколы прикладного уровня, такие как SPDY или HTTP , были продемонстрированы и в значительной степени смягчены только эксплойты против TLS и SPDY. в браузерах и серверах. Эксплойт CRIME против сжатия HTTP вообще не был устранен, хотя авторы CRIME предупреждают, что эта уязвимость может быть даже более распространенной, чем сжатие SPDY и TLS вместе взятые. В 2013 году было объявлено о новом случае КРИМИНАЛЬНОЙ атаки на сжатие HTTP, получившей название BREACH . На основе атаки CRIME атака BREACH может извлечь токены входа, адреса электронной почты или другую конфиденциальную информацию из зашифрованного TLS веб-трафика всего за 30 секунд (в зависимости от количества байтов, которые необходимо извлечь), при условии, что злоумышленник обманом заставляет жертву посетить вредоносная веб-ссылка или возможность внедрения контента на действительные страницы, которые посещает пользователь (например, беспроводная сеть под контролем злоумышленника). Все версии TLS и SSL подвержены риску НАРУШЕНИЯ независимо от используемого алгоритма шифрования или шифра. В отличие от предыдущих случаев CRIME, от которых можно успешно защититься, отключив сжатие TLS или сжатие заголовков SPDY, BREACH использует сжатие HTTP, которое практически невозможно отключить, поскольку практически все веб-серверы используют его для повышения скорости передачи данных для пользователей. Это известное ограничение TLS, поскольку оно подвержено атакам с использованием выбранного открытого текста против данных уровня приложения, которые он должен был защищать.

Временные атаки на заполнение

Более ранние версии TLS были уязвимы против атаки оракула заполнения, обнаруженной в 2002 году. Новый вариант, названный атакой Lucky Thirteen , был опубликован в 2013 году.

Некоторые эксперты также рекомендуется избегать тройного DES CBC. Поскольку последними поддерживаемыми шифрами, разработанными для поддержки любой программы, использующей Windows XP библиотеку SSL/TLS , например Internet Explorer в Windows XP, являются RC4 и Triple-DES, а также поскольку RC4 теперь устарел (см. обсуждение атак RC4 ), это усложняет задачу. для поддержки любой версии SSL для любой программы, использующей эту библиотеку в XP.

Исправление было выпущено в виде расширения Encrypt-then-MAC спецификации TLS, выпущенного как RFC   7366 . Атаку Lucky Thirteen можно смягчить в TLS 1.2, используя только шифры AES_GCM; AES_CBC остается уязвимым. SSL может защищать электронную почту, VoIP и другие виды связи в незащищенных сетях в дополнение к своему основному варианту использования — безопасной передаче данных между клиентом и сервером.

ПУДЛ атакует

Основная статья: ПУДЛЬ

14 октября 2014 года исследователи Google опубликовали уязвимость в конструкции SSL 3.0, которая делает режим работы CBC с SSL 3.0 уязвимым для атаки заполнения ( CVE — 2014-3566 ). Они назвали эту атаку POODLE ( Padding Oracle On Downgraded Legacy Encryption ). В среднем злоумышленникам достаточно выполнить всего 256 запросов SSL 3.0, чтобы раскрыть один байт зашифрованных сообщений.

Хотя эта уязвимость существует только в SSL 3.0, а большинство клиентов и серверов поддерживают TLS 1.0 и выше, все основные браузеры добровольно переходят на SSL 3.0, если рукопожатия с более новыми версиями TLS завершаются неудачей, если только они не предоставляют пользователю или администратору возможность отключить SSL 3.0. и пользователь или администратор делает это . Таким образом, злоумышленник может сначала провести атаку с откатом версии , а затем воспользоваться этой уязвимостью.

8 декабря 2014 г. было объявлено о варианте POODLE, который влияет на реализации TLS, которые не обеспечивают должным образом требования к байтам заполнения.

Атаки RC4

Основная статья: RC4 § Безопасность

Несмотря на существование атак на RC4 , нарушивших его безопасность, наборы шифров SSL и TLS, основанные на RC4, до 2013 года все еще считались безопасными в зависимости от того, как они использовались в SSL и TLS. В 2011 году пакет RC4 был рекомендован в качестве обходного пути для атаки BEAST . Новые формы атак, раскрытые в марте 2013 года, убедительно продемонстрировали возможность взлома RC4 в TLS, что позволяет предположить, что это не лучший обходной путь для BEAST. Сценарий атаки был предложен АльФарданом, Бернштейном, Патерсоном, Пёттерингом и Шульдтом, в котором использовались недавно обнаруженные статистические отклонения в ключевой таблице RC4. восстановить части открытого текста с помощью большого количества шифрований TLS. Атака на RC4 в TLS и SSL, требующая 13 × 2 ²⁰ Шифрование для взлома RC4 было представлено 8 июля 2013 года и позже описано как «осуществимое» в сопроводительной презентации на симпозиуме по безопасности USENIX в августе 2013 года. В июле 2015 года последующие улучшения в атаке сделали все более практичным преодоление безопасности TLS, зашифрованного RC4.

Поскольку многие современные браузеры разработаны для защиты от атак BEAST (кроме Safari для Mac OS X 10.7 или более ранней версии, для iOS 6 или более ранней версии и для Windows; см. § Веб-браузеры ), RC4 больше не является хорошим выбором для TLS 1.0. Шифры CBC, на которые в прошлом повлияла атака BEAST, стали более популярным выбором для защиты. Mozilla и Microsoft рекомендуют отключать RC4, где это возможно. RFC   7465 запрещает использование наборов шифров RC4 во всех версиях TLS.

1 сентября 2015 года Microsoft, Google и Mozilla объявили, что наборы шифров RC4 будут по умолчанию отключены в их браузерах ( Microsoft Edge , Internet Explorer 11 в Windows 7/8.1/10, Firefox и Chrome ) в начале 2016 года.

Атака усечения

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

Опубликовано в июле 2013 г., атака приводит к тому, что веб-службы, такие как Gmail и Hotmail, отображают страницу, информирующую пользователя об успешном выходе из системы, при этом гарантируя, что браузер пользователя сохраняет авторизацию в службе, позволяя злоумышленнику с последующим доступом к браузеру получить доступ и взять на себя контроль над вошедшей в систему учетной записью пользователя. Атака не предполагает установку вредоносного ПО на компьютер жертвы; злоумышленникам нужно только встать между жертвой и веб-сервером (например, установив мошенническую беспроводную точку доступа). Эта уязвимость также требует доступа к компьютеру жертвы. Другая возможность заключается в том, что при использовании FTP соединение для передачи данных может иметь ложный FIN в потоке данных, и если правила протокола для обмена оповещениями close_notify не соблюдаются, файл может быть усечен.

Атака с открытым текстом на DTLS

В феврале 2013 года два исследователя из Ройял Холлоуэй (Лондонский университет) обнаружили тайминговую атаку. что позволило им восстановить (части) открытого текста из соединения DTLS с использованием реализации DTLS OpenSSL или GnuTLS, когда цепочки блоков шифра использовалось шифрование в режиме .

PAC

Эта атака, обнаруженная в середине 2016 года, использует слабые места в протоколе автообнаружения веб-прокси (WPAD) для раскрытия URL-адреса, к которому веб-пользователь пытается получить доступ через веб-ссылку с поддержкой TLS. Раскрытие URL-адреса может нарушить конфиденциальность пользователя не только из-за посещаемого веб-сайта, но и потому, что URL-адреса иногда используются для аутентификации пользователей. Службы обмена документами, например, предлагаемые Google и Dropbox, также работают, отправляя пользователю токен безопасности, включенный в URL-адрес. Злоумышленник, получивший такие URL-адреса, может получить полный доступ к учетной записи или данным жертвы.

Эксплойт работает практически против всех браузеров и операционных систем.

Атака Sweet32

Атака Sweet32 взламывает все 64-битные блочные шифры, используемые в режиме CBC и TLS, используя атаку «День рождения» , а также атаку «человек посередине» или внедрение вредоносного кода JavaScript на веб-страницу. Цель атаки «человек посередине» или внедрения JavaScript — позволить злоумышленнику перехватить достаточно трафика для организации атаки на день рождения.

реализации: ошибка Heartbleed, Cloudflare

Основные статьи: Heartbleed и Cloudbleed

Ошибка Heartbleed — это серьезная уязвимость, связанная с реализацией SSL/TLS в популярной библиотеке криптографического программного обеспечения OpenSSL , затрагивающая версии с 1.0.1 по 1.0.1f. Эта уязвимость, о которой сообщалось в апреле 2014 года, позволяет злоумышленникам красть закрытые ключи с серверов, которые обычно должны быть защищены. Ошибка Heartbleed позволяет любому пользователю Интернета читать память систем, защищенных уязвимыми версиями программного обеспечения OpenSSL. Это ставит под угрозу секретные частные ключи, связанные с общедоступными сертификатами, используемыми для идентификации поставщиков услуг и шифрования трафика, имен и паролей пользователей, а также фактического контента. Это позволяет злоумышленникам подслушивать коммуникации, красть данные непосредственно у служб и пользователей, а также выдавать себя за службы и пользователей. Уязвимость вызвана ошибкой переполнения буфера в программном обеспечении OpenSSL, а не дефектом спецификации протокола SSL или TLS.

В сентябре 2014 года был обнаружен вариант Дэниела Бляйхенбахера. уязвимости PKCS # 1 v1.5 RSA Signature Forgery было объявлено подразделением Intel Security Advanced Threat Research. Эта атака, получившая название BERserk, является результатом неполного декодирования подписей с открытым ключом по длине ASN.1 в некоторых реализациях SSL и позволяет провести атаку «человек посередине» путем подделки подписи с открытым ключом.

В феврале 2015 года, после того как СМИ сообщили о скрытой предварительной установке рекламного ПО Superfish на некоторые ноутбуки Lenovo, исследователь обнаружил, что доверенный корневой сертификат на затронутых компьютерах Lenovo небезопасен, поскольку к ключам можно легко получить доступ, используя название компании Komodia в качестве парольной фразы. Библиотека Komodia была разработана для перехвата трафика TLS/SSL на стороне клиента в целях родительского контроля и наблюдения, но она также использовалась в многочисленных рекламных программах, включая Superfish, которые часто устанавливались тайно, без ведома пользователя компьютера. В свою очередь, эти потенциально нежелательные программы установили поврежденный корневой сертификат, что позволило злоумышленникам полностью контролировать веб-трафик и подтверждать подлинность ложных веб-сайтов.

В мае 2016 года сообщалось, что десятки датских веб-сайтов, защищенных HTTPS, принадлежащих Visa Inc., были уязвимы для атак, позволяющих хакерам внедрять вредоносный код и подделывать контент в браузеры посетителей. Атаки сработали, поскольку реализация TLS, используемая на затронутых серверах, неправильно повторно использовала случайные числа ( nonce ), которые предназначены для использования только один раз, гарантируя каждого подтверждения TLS . уникальность

В феврале 2017 года ошибка реализации, вызванная одним опечаткой в ​​коде, используемом для анализа HTML, привела к ошибке переполнения буфера на Cloudflare серверах , аналогична по своим последствиям ошибке Heartbleed, обнаруженной в 2014 году. . Эта ошибка переполнения, широко известная как Cloudbleed Она позволяла неавторизованным третьим лицам читать данные в памяти программ, работающих на серверах, — данные, которые в противном случае должны были быть защищены с помощью TLS.

Исследование веб-сайтов, уязвимых для атак

По состоянию на июль 2021 г. , Движение за надежность Интернета оценило долю веб-сайтов, уязвимых для атак TLS.

Обзор TLS-уязвимостей самых популярных сайтов

Атаки	Безопасность
	Ненадежный	Зависит от	Безопасный	Другой
Атака повторного согласования	< 0,1% поддержка небезопасного пересмотра условий	< 0,1% поддерживаю обоих	99.7% поддержка безопасного повторного согласования	0.3% без поддержки
RC4-атаки	0.2% поддержка пакетов RC4, используемых с современными браузерами	3.0% поддержка некоторых наборов RC4	96.9% без поддержки	—
TLS-сжатие (CRIME-атака)	0% уязвимый	—	—	—
Сердцекровие	0% уязвимый	—	—	—
Атака с помощью внедрения ChangeCipherSpec	< 0,1% уязвим и доступен для эксплуатации	< 0,1% уязвимый, не эксплуатируемый	99.5% не уязвим	0.4% неизвестный
Атака POODLE на TLS (Оригинальный POODLE с SSL 3.0 не включен)	< 0,1% уязвим и доступен для эксплуатации	—	99.9% не уязвим	0.1% неизвестный
Понижение версии протокола	4.1% Защита от понижения версии не поддерживается	—	80.2% Поддержка понижения версии защиты	15.7% неизвестный

Прямая секретность

Основная статья: Прямая секретность

Прямая секретность — это свойство криптографических систем, которое гарантирует, что сеансовый ключ, полученный из набора открытого и закрытого ключей, не будет скомпрометирован, если один из закрытых ключей будет скомпрометирован в будущем. Без прямой секретности, если закрытый ключ сервера скомпрометирован, будут скомпрометированы не только все будущие сеансы с шифрованием TLS, использующие этот сертификат сервера, но также и все предыдущие сеансы, которые его использовали (при условии, что эти прошлые сеансы были перехвачены и сохранены в время передачи). Реализация TLS может обеспечить прямую секретность, требуя использования эфемерного обмена ключами Диффи-Хеллмана для установления сеансовых ключей, а некоторые известные реализации TLS делают это исключительно: например, Gmail и другие службы Google HTTPS, которые используют OpenSSL . Однако многие клиенты и серверы, поддерживающие TLS (включая браузеры и веб-серверы), не настроены для реализации таких ограничений. На практике, если веб-служба не использует обмен ключами Диффи-Хеллмана для реализации прямой секретности, весь зашифрованный веб-трафик, входящий и исходящий от этой службы, может быть расшифрован третьей стороной, если она получит главный (закрытый) ключ сервера; например, по решению суда.

Даже там, где реализован обмен ключами Диффи-Хеллмана, механизмы управления сеансами на стороне сервера могут повлиять на прямую секретность. Использование билетов сеанса TLS (расширение TLS) приводит к тому, что сеанс защищается с помощью AES128-CBC-SHA256 независимо от любых других согласованных параметров TLS, включая наборы шифров прямой секретности, а долгоживущие ключи билета сеанса TLS препятствуют попытке реализовать передовая секретность. Исследование Стэнфордского университета в 2014 году также показало, что из 473 802 опрошенных TLS-серверов 82,9% серверов, развертывающих эфемерный обмен ключами Диффи-Хеллмана (DHE) для поддержки прямой секретности, использовали слабые параметры Диффи-Хеллмана. Этот слабый выбор параметров потенциально может поставить под угрозу эффективность прямой секретности, которую стремились обеспечить серверы.

С конца 2011 года Google по умолчанию обеспечивает прямую секретность с помощью TLS для пользователей своей службы Gmail , а также Документов Google и зашифрованного поиска, а также других служб. С ноября 2013 года Twitter обеспечивает прямую секретность с помощью TLS для пользователей своего сервиса. По состоянию на август 2019 г. около 80% веб-сайтов с поддержкой TLS настроены на использование наборов шифров, обеспечивающих прямую секретность для большинства веб-браузеров.

Перехват TLS

См. также: Индикация имени сервера § Зашифрованный клиентский привет.

Перехват TLS (или перехват HTTPS , если он применяется конкретно к этому протоколу) — это практика перехвата зашифрованного потока данных с целью его расшифровки, чтения и, возможно, манипулирования им, а затем повторного шифрования и повторной отправки данных. Это делается с помощью « прозрачного прокси »: программа перехвата завершает входящее соединение TLS, проверяет открытый текст HTTP, а затем создает новое соединение TLS с пунктом назначения.

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

Существенным недостатком перехвата TLS/HTTPS является то, что он сам по себе создает новые риски безопасности. Одним из заметных ограничений является то, что он обеспечивает точку, где сетевой трафик доступен в незашифрованном виде, что дает злоумышленникам стимул атаковать именно эту точку, чтобы получить доступ к защищенному в противном случае контенту. Перехват также позволяет сетевому оператору или лицам, получившим доступ к его системе перехвата, осуществлять атаки «человек посередине» против пользователей сети. Исследование 2017 года показало, что «перехват HTTPS стал поразительно распространенным, и что продукты перехвата как класс оказывают крайне негативное влияние на безопасность соединения».

Подробности протокола

Протокол TLS обменивается записями , которые инкапсулируют данные, подлежащие обмену, в определенном формате (см. ниже). Каждая запись может быть сжата, дополнена, дополнена кодом аутентификации сообщения (MAC) или зашифрована — все в зависимости от состояния соединения. Каждая запись имеет поле типа контента , которое определяет тип инкапсулированных данных, поле длины и поле версии TLS. Инкапсулированные данные могут быть управляющими или процедурными сообщениями самого TLS или просто данными приложения, которые необходимо передать по TLS. Спецификации (набор шифров, ключи и т. д.), необходимые для обмена данными приложения по TLS, согласовываются в «квитировании TLS» между клиентом, запрашивающим данные, и сервером, отвечающим на запросы. Таким образом, протокол определяет как структуру полезных данных, передаваемых в TLS, так и процедуру установления и контроля передачи.

TLS-рукопожатие

Упрощенная иллюстрация полного рукопожатия TLS 1.2 с информацией о времени.

Когда соединение начинается, запись инкапсулирует «управляющий» протокол – протокол обмена сообщениями квитирования ( тип контента 22). Этот протокол используется для обмена всей информацией, необходимой обеим сторонам для обмена фактическими данными приложения по TLS. Он определяет формат сообщений и порядок их обмена. Они могут различаться в зависимости от требований клиента и сервера – т. е. существует несколько возможных процедур установки соединения. Этот первоначальный обмен приводит к успешному соединению TLS (обе стороны готовы передать данные приложения с помощью TLS) или предупреждающему сообщению (как указано ниже).

Базовое рукопожатие TLS

Ниже приведен типичный пример подключения, иллюстрирующий рукопожатие , при котором сервер (но не клиент) аутентифицируется по своему сертификату:

1. Этап переговоров:
   • Клиент отправляет сообщение ClientHello , указывая самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и предлагаемые методы сжатия. Если клиент пытается выполнить возобновленное рукопожатие, он может отправить идентификатор сеанса . Если клиент может использовать согласование протокола уровня приложения , он может включать список поддерживаемых протоколов приложений , таких как HTTP/2 .
   • Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Чтобы подтвердить или разрешить возобновление рукопожатий, сервер может отправить идентификатор сеанса . Выбранная версия протокола должна быть самой высокой, поддерживаемой как клиентом, так и сервером. Например, если клиент поддерживает TLS версии 1.1, а сервер поддерживает версию 1.2, следует выбрать версию 1.1; версию 1.2 выбирать не следует.
   • Сервер отправляет свое сообщение сертификата (в зависимости от выбранного набора шифров оно может быть пропущено сервером).
   • Сервер отправляет сообщение ServerKeyExchange (в зависимости от выбранного набора шифров оно может быть пропущено сервером). Это сообщение отправляется для всех наборов шифров DHE , ECDHE и DH_anon.
   • Сервер отправляет сообщение ServerHelloDone , указывая, что согласование рукопожатия завершено.
   • Клиент отвечает сообщением ClientKeyExchange , которое может содержать PreMasterSecret , открытый ключ или ничего не содержать. (Опять же, это зависит от выбранного шифра.) Этот PreMasterSecret шифруется с использованием открытого ключа сертификата сервера.
   • Затем клиент и сервер используют случайные числа и PreMasterSecret для вычисления общего секрета, называемого «главным секретом». Все остальные ключевые данные ( ключи сеанса , такие как IV , ключ симметричного шифрования , MAC ключ ) для этого соединения получается из этого главного секрета (а также случайных значений, сгенерированных клиентом и сервером), который передается через тщательно разработанную псевдослучайную функцию.
2. Клиент теперь отправляет запись ChangeCipherSpec , по сути сообщая серверу: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если параметры шифрования присутствовали в сертификате сервера)». ChangeCipherSpec сам по себе является протоколом уровня записи с типом контента 20.
   • Клиент отправляет проверенное и зашифрованное сообщение «Готово» , содержащее хэш и MAC-адрес, поверх предыдущих сообщений подтверждения.
   • Сервер попытается расшифровать сообщение клиента Finished и проверить хэш и MAC. Если расшифровка или проверка не удались, считается, что рукопожатие не удалось, и соединение должно быть разорвано.
3. Наконец, сервер отправляет ChangeCipherSpec , сообщая клиенту: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если шифрование было согласовано)».
   • Сервер отправляет проверенное и зашифрованное сообщение «Готово» .
   • Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем шаге.
4. Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом контента 23. Сообщения приложений, которыми обмениваются клиент и сервер, также будут аутентифицированы и, при необходимости, зашифрованы точно так же, как в их готовом сообщении. В противном случае тип контента вернет 25, и клиент не пройдет проверку подлинности.

Рукопожатие TLS с аутентификацией клиента

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

1. Фаза переговоров:
   • Клиент отправляет сообщение ClientHello , указывая самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и методов сжатия.
   • Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Сервер также может отправить идентификатор сеанса как часть сообщения для возобновления рукопожатия.
   • Сервер отправляет свое сообщение сертификата (в зависимости от выбранного набора шифров оно может быть пропущено сервером).
   • Сервер отправляет сообщение ServerKeyExchange (в зависимости от выбранного набора шифров оно может быть пропущено сервером). Это сообщение отправляется для всех наборов шифров DHE, ECDHE и DH_anon. ^[1]
   • Сервер отправляет сообщение CertificateRequest , чтобы запросить сертификат у клиента.
   • Сервер отправляет сообщение ServerHelloDone , указывая, что согласование рукопожатия завершено.
   • Клиент отвечает сообщением о сертификате , которое содержит сертификат клиента, но не его закрытый ключ.
   • Клиент отправляет сообщение ClientKeyExchange , которое может содержать PreMasterSecret , открытый ключ или ничего не содержать. (Опять же, это зависит от выбранного шифра.) Этот PreMasterSecret шифруется с использованием открытого ключа сертификата сервера.
   • Клиент отправляет сообщение CertificateVerify , которое является подписью поверх предыдущих сообщений подтверждения с использованием закрытого ключа сертификата клиента. Эту подпись можно проверить с помощью открытого ключа сертификата клиента. Это позволяет серверу узнать, что клиент имеет доступ к закрытому ключу сертификата и, следовательно, является владельцем сертификата.
   • Затем клиент и сервер используют случайные числа и PreMasterSecret для вычисления общего секрета, называемого «главным секретом». Все остальные ключевые данные («ключи сеанса») для этого соединения извлекаются из этого главного секрета (а также случайных значений, сгенерированных клиентом и сервером), которые передаются через тщательно разработанную псевдослучайную функцию.
2. Клиент теперь отправляет запись ChangeCipherSpec , по сути сообщая серверу: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если было согласовано шифрование). ChangeCipherSpec сам по себе является протоколом уровня записи и имеет тип 20, а не 22. .
   • Наконец, клиент отправляет зашифрованное сообщение о завершении , содержащее хэш и MAC-адрес, поверх предыдущих сообщений подтверждения.
   • Сервер попытается расшифровать сообщение клиента Finished и проверить хэш и MAC. Если расшифровка или проверка завершаются неудачей, считается, что рукопожатие не удалось, и соединение следует разорвать.
3. Наконец, сервер отправляет ChangeCipherSpec , сообщая клиенту: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если было согласовано шифрование)».
   • Сервер отправляет собственное зашифрованное сообщение о завершении .
   • Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем шаге.
4. Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом контента 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут зашифрованы точно так же, как в их готовом сообщении.

Возобновлено рукопожатие TLS

Операции с открытым ключом (например, RSA) относительно дороги с точки зрения вычислительной мощности. TLS предоставляет безопасный ярлык в механизме установления связи, позволяющий избежать этих операций: возобновление сеансов. Возобновленные сеансы реализуются с использованием идентификаторов сеансов или билетов сеанса.

Помимо повышения производительности, возобновленные сеансы также можно использовать для единого входа , поскольку он гарантирует, что как исходный сеанс, так и любой возобновленный сеанс происходят от одного и того же клиента. Это имеет особое значение для протокола FTP через TLS/SSL , который в противном случае пострадал бы от атаки «человек посередине», при которой злоумышленник мог бы перехватить содержимое вторичных подключений к данным.

Рукопожатие TLS 1.3

Подтверждение TLS 1.3 было сокращено до одного двустороннего обмена по сравнению с двумя двусторонними проходами, которые требовались в предыдущих версиях TLS/SSL.

Чтобы начать рукопожатие, клиент угадывает, какой алгоритм обмена ключами будет выбран сервером, и отправляет на сервер сообщение ClientHello , содержащее список поддерживаемых шифров (в порядке предпочтений клиента) и открытые ключи для некоторых или всех его ключей. обменяйтесь предположениями. Если клиент успешно угадывает алгоритм обмена ключами, из рукопожатия исключается 1 обращение туда и обратно. После получения ClientHello сервер выбирает шифр и отправляет обратно ServerHello со своим собственным открытым ключом, за которым следуют сообщения «Сертификат сервера» и «Готово» .

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

Идентификаторы сеансов

При обычном полном рукопожатии сервер отправляет идентификатор сеанса как часть сообщения ServerHello . Клиент связывает этот идентификатор сеанса с IP-адресом и TCP-портом сервера, поэтому, когда клиент снова подключается к этому серверу, он может использовать идентификатор сеанса для сокращения рукопожатия. На сервере идентификатор сеанса сопоставляется с ранее согласованными криптографическими параметрами, в частности с «главным секретом». Обе стороны должны иметь один и тот же «главный секрет», иначе возобновленное рукопожатие не удастся (это не позволит перехватчику использовать идентификатор сеанса ). Случайные данные в сообщениях ClientHello и ServerHello практически гарантируют, что сгенерированные ключи подключения будут отличаться от ключей предыдущего подключения. В RFC этот тип рукопожатия называется сокращенным рукопожатием. В литературе это также описано как рукопожатие перезапуска .

1. Этап переговоров:
   • Клиент отправляет сообщение ClientHello , указывая самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и методов сжатия. В сообщение включен идентификатор сеанса предыдущего TLS-соединения.
   • Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Если сервер распознает идентификатор сеанса, отправленный клиентом, он отвечает тем же идентификатором сеанса . Клиент использует это, чтобы распознать возобновление рукопожатия. Если сервер не распознает идентификатор сеанса , отправленный клиентом, он отправляет другое значение для своего идентификатора сеанса . Это сообщает клиенту, что возобновленное рукопожатие выполняться не будет. На этом этапе и клиент, и сервер имеют «главный секрет» и случайные данные для генерации ключевых данных, которые будут использоваться для этого соединения.
2. Теперь сервер отправляет запись ChangeCipherSpec , по сути сообщая клиенту: «Все, что я скажу вам с этого момента, будет зашифровано». ChangeCipherSpec сам по себе является протоколом уровня записи и имеет тип 20, а не 22.
   • Наконец, сервер отправляет зашифрованное сообщение о завершении , содержащее хэш и MAC-адрес, поверх предыдущих сообщений подтверждения.
   • Клиент попытается расшифровать сообщение сервера Finished и проверить хэш и MAC. Если расшифровка или проверка завершаются неудачей, считается, что рукопожатие не удалось, и соединение следует разорвать.
3. Наконец, клиент отправляет ChangeCipherSpec , сообщая серверу: «Все, что я скажу вам с этого момента, будет зашифровано».
   • Клиент отправляет собственное зашифрованное сообщение о завершении .
   • Сервер выполняет ту же процедуру расшифровки и проверки, что и клиент на предыдущем шаге.
4. Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом контента 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут зашифрованы точно так же, как в их готовом сообщении.

Билеты на сеансы

RFC   5077 расширяет TLS за счет использования билетов сеанса вместо идентификаторов сеанса. Он определяет способ возобновления сеанса TLS без необходимости сохранения состояния конкретного сеанса на сервере TLS.

При использовании билетов сеанса сервер TLS сохраняет свое состояние, зависящее от сеанса, в билете сеанса и отправляет билет сеанса клиенту TLS для хранения. Клиент возобновляет сеанс TLS, отправляя билет сеанса на сервер, а сервер возобновляет сеанс TLS в соответствии с состоянием сеанса в билете. Билет сеанса шифруется и аутентифицируется сервером, а сервер проверяет его достоверность перед использованием его содержимого.

Одним из особых недостатков этого метода с OpenSSL является то, что он всегда ограничивает безопасность шифрования и аутентификации передаваемого билета сеанса TLS. AES128-CBC-SHA256независимо от того, какие другие параметры TLS были согласованы для фактического сеанса TLS. Это означает, что информация о состоянии (билет сеанса TLS) не так хорошо защищена, как сам сеанс TLS. Особое беспокойство вызывает хранение ключей OpenSSL в контексте всего приложения ( SSL_CTX), т.е. на протяжении всего срока действия приложения и не допуская повторного ввода ключей. AES128-CBC-SHA256 Билеты сеанса TLS без сброса контекста OpenSSL в масштабе приложения (что встречается редко, подвержено ошибкам и часто требует ручного административного вмешательства).

TLS-запись

Это общий формат всех записей TLS.

Формат записи TLS, общий

Компенсировать	Байт+0	Байт+1	Байт+2	Байт+3
Байт 0	Тип содержимого	—
Байты 1–4	Устаревшая версия		Длина
	(Главный)	(Незначительный)	(биты 15–8)	(биты 7–0)
Байты 5–( м −1)	Протокольное сообщение(я)
Байты м –( р −1)	MAC (опционально)
Байты р –( q −1)	Заполнение (только блочные шифры)

Тип содержимого

Это поле идентифицирует тип протокола уровня записи, содержащийся в этой записи.

Типы контента

Шестигранник	декабрь	Тип
0×14	20	Ченджиферспек
0×15	21	Тревога
0×16	22	Рукопожатие
0×17	23	Приложение
0×18	24	Сердцебиение

Устаревшая версия

В этом поле указывается основная и дополнительная версия TLS до TLS 1.3 для содержащегося сообщения. Для сообщения ClientHello это не обязательно должна быть самая высокая версия, поддерживаемая клиентом. Для TLS 1.3 и более поздних версий необходимо установить значение 0x0303, а приложение должно отправлять поддерживаемые версии в дополнительном блоке расширения сообщения.

Версии

Главный версия	Незначительный версия	Тип версии
3	0	SSL 3.0
3	1	ТЛС 1.0
3	2	ТЛС 1.1
3	3	ТЛС 1.2
3	4	ТЛС 1.3

Длина

Длина объединенных полей «протокольное сообщение(я)», «MAC» и «заполнение» (т. е. q -5), не должна превышать 2. ¹⁴ байт (16 КиБ).

Протокольное сообщение(я)

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

MAC и дополнение

Код аутентификации сообщения , вычисляемый по полю «сообщения протокола», с включенным дополнительным ключевым материалом. Обратите внимание, что это поле может быть зашифровано или не включено полностью, в зависимости от состояния соединения.

Никакие поля «MAC» или «дополнения» не могут присутствовать в конце записей TLS до того, как все алгоритмы и параметры шифрования будут согласованы и подтверждены, а затем подтверждены отправкой записи CipherStateChange (см. ниже) для сигнализации о том, что эти параметры вступят в силу во всех дальнейшие записи, отправленные тем же узлом.

Протокол рукопожатия

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

Формат записи TLS для протокола рукопожатия

Компенсировать	Байт+0	Байт+1	Байт+2	Байт+3
Байт 0	22	—
Байты 1–4	Устаревшая версия		Длина
	(Главный)	(Незначительный)	(биты 15–8)	(биты 7–0)
Байты 5–8	Тип сообщения	Длина данных сообщения рукопожатия
		(биты 23–16)	(биты 15–8)	(биты 7–0)
Байты 9–( n −1)	Данные сообщения рукопожатия
Байты п –( п +3)	Тип сообщения	Длина данных сообщения рукопожатия
		(биты 23–16)	(биты 15–8)	(биты 7–0)
Байты ( н +4)–	Данные сообщения рукопожатия

Тип сообщения

В этом поле указывается тип сообщения подтверждения.

Типы сообщений

Код	Описание
0	ПриветЗапрос
1	КлиентПривет
2	СерверПривет
4	НовыйСессионныйБилет
8	EncryptedExtensions (только TLS 1.3)
11	Сертификат
12	ServerKeyExchange
13	Запрос сертификата
14	СерверHelloDone
15	СертификатПроверить
16	ClientKeyExchange
20	Законченный

Длина данных сообщения рукопожатия

Это 3-байтовое поле, указывающее длину данных подтверждения, не включая заголовок.

Обратите внимание, что несколько сообщений подтверждения связи могут быть объединены в одну запись.

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

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

Формат записи TLS для протокола оповещений

Компенсировать	Байт+0	Байт+1	Байт+2	Байт+3
Байт 0	21	—
Байты 1–4	Устаревшая версия		Длина
	(Главный)	(Незначительный)	0	2
Байты 5–6	Уровень	Описание	—
Байты 7 –( р −1)	MAC (опционально)
Байты р –( q −1)	Заполнение (только блочные шифры)

Уровень

В этом поле указывается уровень оповещения. Если уровень фатальный, отправителю следует немедленно закрыть сеанс. В противном случае получатель может принять решение о прекращении сеанса самостоятельно, отправив собственное фатальное предупреждение и закрыв сам сеанс сразу после его отправки. Использование записей Alert не является обязательным, однако, если они отсутствуют до закрытия сеанса, сеанс может быть возобновлен автоматически (с его рукопожатиями).

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

Типы уровней оповещений

Код	Тип уровня	Состояние соединения
1	предупреждение	соединение или безопасность могут быть нестабильными.
2	смертельный	соединение или безопасность могут быть нарушены, или произошла неисправимая ошибка.

Описание

В этом поле указывается тип отправляемого оповещения.

Типы описаний оповещений

Код	Описание	Типы уровней	Примечание
0	Закрыть уведомление	предупреждение / фатальный
10	Неожиданное сообщение	смертельный
20	Плохая запись MAC	смертельный	Возможно, неправильная реализация SSL или полезная нагрузка была изменена, например, правилом брандмауэра FTP на сервере FTPS .
21	Расшифровка не удалась	смертельный	Только TLS, зарезервировано
22	Переполнение записи	смертельный	только TLS
30	Сбой декомпрессии	смертельный
40	Ошибка рукопожатия	смертельный
41	Нет сертификата	предупреждение / фатальный	Только SSL 3.0, зарезервировано
42	Плохой сертификат	предупреждение / фатальный
43	Неподдерживаемый сертификат	предупреждение / фатальный	например, в сертификате включено только использование аутентификации сервера и он представлен как сертификат клиента
44	Сертификат отозван	предупреждение / фатальный
45	Срок действия сертификата истек	предупреждение / фатальный	Проверьте срок действия сертификата сервера, а также проверьте, не истек ли срок действия сертификата в представленной цепочке.
46	Сертификат неизвестен	предупреждение / фатальный
47	Недопустимый параметр	смертельный
48	Неизвестный центр сертификации ( центр сертификации )	смертельный	только TLS
49	Доступ запрещен	смертельный	Только TLS — например, сертификат клиента не был представлен (TLS: сообщение о пустом сертификате или SSLv3: предупреждение об отсутствии сертификата), но сервер настроен на его требование.
50	Ошибка декодирования	смертельный	только TLS
51	Ошибка расшифровки	предупреждение / фатальный	только TLS
60	Ограничение экспорта	смертельный	Только TLS, зарезервировано
70	Версия протокола	смертельный	только TLS
71	Недостаточная безопасность	смертельный	только TLS
80	Внутренняя ошибка	смертельный	только TLS
86	Неподходящий запасной вариант	смертельный	только TLS
90	Пользователь отменен	смертельный	только TLS
100	Никаких повторных переговоров	предупреждение	только TLS
110	Неподдерживаемое расширение	предупреждение	только TLS
111	Сертификат недоступен	предупреждение	только TLS
112	Неизвестное имя	предупреждение / фатальный	только TLS; клиента Индикатор имени сервера указал имя хоста , не поддерживаемое сервером
113	Неверный ответ о статусе сертификата	смертельный	только TLS
114	Неверное хэш-значение сертификата	смертельный	только TLS
115	Неизвестный идентификатор PSK (используется в TLS-PSK и TLS-SRP )	смертельный	только TLS
116	Требуется сертификат	смертельный	Только TLS версии 1.3
120 или 255	Нет протокола приложения	смертельный	Только TLS версии 1.3

Протокол ChangeCipherSpec

Формат записи TLS для протокола ChangeCipherSpec

Компенсировать	Байт+0	Байт+1	Байт+2	Байт+3
Байт 0	20	—
Байты 1–4	Устаревшая версия		Длина
	(Главный)	(Незначительный)	0	1
Байт 5	Тип протокола CCS	—

Тип протокола CCS

На данный момент только 1.

Протокол приложения

Формат записи TLS для протокола приложения

Компенсировать	Байт+0	Байт+1	Байт+2	Байт+3
Байт 0	23	—
Байты 1–4	Устаревшая версия		Длина
	(Главный)	(Незначительный)	(биты 15–8)	(биты 7–0)
Байты 5–( м −1)	Данные Приложения
Байты м –( р −1)	MAC (опционально)
Байты р –( q −1)	Заполнение (только блочные шифры)

Длина

Длина данных приложения (исключая заголовок протокола, включая MAC-адрес и завершающие фрагменты)

MAC

32 байта для SHA-256 на основе HMAC , 20 байтов для HMAC на основе SHA-1 , 16 байтов для HMAC на основе MD5 .

Заполнение

Переменная длина; последний байт содержит длину заполнения.

Поддержка виртуальных серверов

С точки зрения протокола приложения TLS принадлежит к более низкому уровню, хотя модель TCP/IP слишком груба, чтобы это показать. Это означает, что подтверждение TLS обычно (за исключением случая STARTTLS ) выполняется до запуска протокола приложения. В функции виртуального сервера на основе имени, предоставляемой уровнем приложения, все совместно размещенные виртуальные серверы используют один и тот же сертификат, поскольку сервер должен выбрать и отправить сертификат сразу после сообщения ClientHello. Это большая проблема в средах хостинга, поскольку это означает либо совместное использование одного и того же сертификата всеми клиентами, либо использование разных IP-адресов для каждого из них.

есть два известных обходных пути В X.509 :

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

Чтобы указать имя сервера, Расширения RFC   4366 Transport Layer Security (TLS) позволяют клиентам включать расширение указания имени сервера (SNI) в расширенное сообщение ClientHello. Это расширение сразу же указывает серверу, к какому имени клиент желает подключиться, поэтому сервер может выбрать соответствующий сертификат для отправки клиентам.

В RFC   2817 также описан метод реализации виртуального хостинга на основе имени путем обновления HTTP до TLS через заголовок обновления HTTP/1.1 . Обычно это делается для безопасной реализации HTTP через TLS в основной схеме URI «http» (что позволяет избежать разветвления пространства URI и уменьшает количество используемых портов), однако в настоящее время это поддерживают лишь немногие реализации.

Стандарты

Первичные стандарты

Текущей утвержденной версией (D)TLS является версия 1.3, которая указана в:

• RFC   8446 : «Протокол безопасности транспортного уровня (TLS) версии 1.3».
• RFC   9147 : «Протокол безопасности транспортного уровня датаграмм (DTLS) версии 1.3»

Текущие стандарты заменяют эти прежние версии, которые сейчас считаются устаревшими:

• RFC   5246 : «Протокол безопасности транспортного уровня (TLS) версии 1.2».
• RFC   6347 : «Безопасность транспортного уровня дейтаграмм, версия 1.2».
• RFC   4346 : «Протокол безопасности транспортного уровня (TLS) версии 1.1».
• RFC   4347 «Безопасность транспортного уровня дейтаграмм»
• RFC   2246 : «Протокол TLS версии 1.0».
• RFC   6101 : «Протокол Secure Sockets Layer (SSL) версии 3.0».
• Интернет-проект (1995) : «Протокол SSL».

Расширения

Другие RFC впоследствии расширили (D)TLS.

Расширения (D)TLS 1.3 включают:

• RFC   9367 : «Наборы шифров ГОСТ для протокола безопасности транспортного уровня (TLS) версии 1.3».

Расширения (D)TLS 1.2 включают:

• RFC   5288 : « режима счетчика Галуа AES (GCM) для TLS». Наборы шифров
• RFC   5289 : «Наборы шифров TLS с эллиптической кривой с SHA-256/384 и режимом счетчика Галуа AES (GCM)».
• RFC   5746 : «Расширение индикации повторного согласования безопасности транспортного уровня (TLS)».
• RFC   5878 : «Расширения авторизации Transport Layer Security (TLS)».
• RFC   5932 : «Наборы шифров Camellia для TLS».
• RFC   6066 : «Расширения Transport Layer Security (TLS): определения расширений», включает указание имени сервера и сшивание OCSP .
• RFC   6091 : «Использование ключей OpenPGP для аутентификации TLS».
• RFC   6176 : «Запрет протокола Secure Sockets Layer (SSL) версии 2.0».
• RFC   6209 : «Добавление наборов шифров ARIA к безопасности транспортного уровня (TLS)».
• RFC   6347 : «Безопасность транспортного уровня дейтаграмм, версия 1.2».
• RFC   6367 : «Добавление наборов шифров Camellia к безопасности транспортного уровня (TLS)».
• RFC   6460 : «Профиль Suite B для безопасности транспортного уровня (TLS)».
• RFC   6655 : «Наборы шифров AES-CCM для безопасности транспортного уровня (TLS)».
• RFC   7027 : «Кривые мозгового пула криптографии на основе эллиптических кривых (ECC) для безопасности транспортного уровня (TLS)».
• RFC   7251 : «Наборы шифров шифрования эллиптических кривых AES-CCM (ECC) для TLS».
• RFC   7301 : « Расширение согласования протокола уровня приложений (TLS) ».
• RFC   7366 : «Зашифровать затем MAC для безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)».
• RFC   7465 : «Запрет наборов шифров RC4».
• RFC   7507 : «Значение резервного набора шифров сигнализации TLS (SCSV) для предотвращения атак с понижением версии протокола».
• RFC   7568 : «Устаревшая версия Secure Sockets Layer версии 3.0».
• RFC   7627 : «Хеш сеанса Transport Layer Security (TLS) и расширенное расширение главного секрета».
• RFC   7685 : «Расширение заполнения ClientHello безопасности транспортного уровня (TLS)».
• RFC   9189 : «Наборы шифров ГОСТ для протокола безопасности транспортного уровня (TLS) версии 1.2».

Расширения (D)TLS 1.1 включают:

• RFC   4366 : «Расширения безопасности транспортного уровня (TLS)» описывает как набор конкретных расширений, так и общий механизм расширений.
• RFC   4492 : « Наборы шифров криптографии с эллиптической кривой (ECC) для безопасности транспортного уровня (TLS)».
• RFC   4680 : «Сообщение установления связи TLS для дополнительных данных».
• RFC   4681 : «Расширение сопоставления пользователей TLS».
• RFC   4785 : «Наборы шифров с предварительным общим ключом (PSK) с нулевым шифрованием для безопасности транспортного уровня (TLS)».
• RFC   5054 : «Использование протокола безопасного удаленного пароля (SRP) для аутентификации TLS». Определяет наборы шифров TLS-SRP .
• RFC   5077 : «Возобновление сеанса Transport Layer Security (TLS) без состояния на стороне сервера».
• RFC   5081 : «Использование ключей OpenPGP для аутентификации безопасности транспортного уровня (TLS)», устаревший. РФК   6091 .
• RFC   5216 : « EAP -TLS». Протокол аутентификации

Расширения TLS 1.0 включают:

• RFC   2595 : «Использование TLS с IMAP, POP3 и ACAP». Определяет расширение служб IMAP, POP3 и ACAP, которое позволяет серверу и клиенту использовать безопасность транспортного уровня для обеспечения частной связи с проверкой подлинности через Интернет.
• RFC   2712 : «Добавление наборов шифров Kerberos к безопасности транспортного уровня (TLS)». 40-битные наборы шифров, определенные в этом документе, используются только с целью документирования того факта, что эти коды набора шифров уже назначены.
• RFC   2817 : «Обновление до TLS в HTTP/1.1» объясняет, как использовать механизм обновления в HTTP/1.1 для инициирования безопасности транспортного уровня (TLS) через существующее TCP-соединение. Это позволяет незащищенному и защищенному HTTP-трафику использовать один и тот же хорошо известный порт (в данном случае http: по адресу 80, а не https: по номеру 443).
• RFC   2818 : «HTTP через TLS» отличает защищенный трафик от незащищенного трафика за счет использования другого «порта сервера».
• RFC   3207 : «Расширение службы SMTP для защиты SMTP через безопасность транспортного уровня». Указывает расширение службы SMTP, которое позволяет SMTP-серверу и клиенту использовать безопасность транспортного уровня для обеспечения частной связи с проверкой подлинности через Интернет.
• RFC   3268 : «Наборы шифров AES для TLS». Добавляет наборы шифров Advanced Encryption Standard (AES) к ранее существовавшим симметричным шифрам.
• RFC   3546 : «Расширения безопасности транспортного уровня (TLS)» добавляет механизм согласования расширений протокола во время инициализации сеанса и определяет некоторые расширения. Устарело по РФК   4366 .
• RFC   3749 : «Методы сжатия протокола безопасности транспортного уровня» определяет структуру для методов сжатия и метода сжатия DEFLATE .
• RFC   3943 : «Сжатие протокола безопасности транспортного уровня (TLS) с использованием Lempel-Ziv-Stac (LZS)».
• RFC   4132 : «Добавление наборов шифров Camellia к безопасности транспортного уровня (TLS)».
• RFC   4162 : «Добавление наборов шифров SEED к безопасности транспортного уровня (TLS)».
• RFC   4217 : «Защита FTP с помощью TLS ».
• RFC   4279 : «Наборы шифров с предварительным общим ключом для безопасности транспортного уровня (TLS)» добавляет три набора новых наборов шифров для протокола TLS для поддержки аутентификации на основе предварительно общих ключей.

Информационные RFC

• RFC   7457 : «Обзор известных атак на безопасность транспортного уровня (TLS) и дейтаграммный TLS (DTLS)».
• RFC   7525 : «Рекомендации по безопасному использованию безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)».

См. также

• Согласование протокола уровня приложений — расширение TLS, используемое для SPDY и TLS False Start.
• Bullrun (программа дешифрования) — секретная программа по борьбе с шифрованием, проводимая Агентством национальной безопасности США.
• Центр сертификации
• Прозрачность сертификата
• Делегированные учетные данные
• Строгая транспортная безопасность HTTP — HSTS
• Файл для ключей
• Private Communications Technology (PCT) — исторический конкурент Microsoft SSL 2.0.
• QUIC (Quick UDP Internet Connections) – «…был разработан для обеспечения защиты, эквивалентной TLS/SSL»; Основная цель QUIC — улучшить воспринимаемую производительность веб-приложений, ориентированных на соединение, которые в настоящее время используют TCP.
• Серверная криптография
• tcpcrypt
• Безопасность транспортного уровня дейтаграмм
• TLS-ускорение

Works cited

• Sullivan, Nick (2017-12-26). "Why TLS 1.3 isn't in browsers yet". The Cloudflare Blog. Archived from the original on 2017-12-26. Retrieved 2020-03-14.
• Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170.

Further reading

• Wagner, David; Schneier, Bruce (November 1996). "Analysis of the SSL 3.0 Protocol" (PDF). The Second USENIX Workshop on Electronic Commerce Proceedings. USENIX Press. pp. 29–40. Archived (PDF) from the original on 2006-10-16. Retrieved 2006-10-12.
• Rescorla, Eric (2001). SSL and TLS: Designing and Building Secure Systems. United States: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
• Stephen A. Thomas (2000). SSL and TLS essentials securing the Web. New York: Wiley. ISBN 978-0-471-38354-3.
• Bard, Gregory (2006). "A Challenging But Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL". International Association for Cryptologic Research (136). Archived from the original on 2011-09-23. Retrieved 2011-09-23.
• Canvel, Brice. "Password Interception in a SSL/TLS Channel". Archived from the original on 2016-04-20. Retrieved 2007-04-20.
• RFC of change for TLS Renegotiation. 2010. doi:10.17487/RFC5746. RFC 5746.
• Creating VPNs with IPsec and SSL/TLS Archived 2015-04-12 at the Wayback Machine Linux Journal article by Rami Rosen
• Joshua Davies (2010). Implementing SSL/TLS. Wiley. ISBN 978-0470920411.
• Polk, Tim; McKay, Kerry; Chokhani, Santosh (April 2014). "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" (PDF). National Institute of Standards and Technology. Archived from the original (PDF) on 2014-05-08. Retrieved 2014-05-07.
• Abdou, AbdelRahman; van Oorschot, Paul (August 2017). "Server Location Verification (SLV) and Server Location Pinning: Augmenting TLS Authentication". Transactions on Privacy and Security. 21 (1). ACM: 1:1–1:26. doi:10.1145/3139294. S2CID 5869541. Archived from the original on 2019-03-22. Retrieved 2018-01-11.
• Ivan Ristic (2022). Bulletproof TLS and PKI, Second Edition. Feisty Duck. ISBN 978-1907117091.

External links

• Internet Engineering Task Force – TLS Workgroup Archived 2014-01-11 at the Wayback Machine