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

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

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

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

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

Описание

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

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

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

• Руководство начинается, когда клиент подключается к серверу с поддержкой TLS, запрашивающим безопасное соединение, а клиент представляет список поддерживаемых комплексов шифров ( Ciphers и Hash Functions ).
• Из этого списка сервер выбирает функцию шифра и хэш, которая также поддерживает и уведомляет клиента о решении.
• Сервер обычно предоставляет идентификацию в виде цифрового сертификата . Сертификат содержит имя сервера , доверенный авторитет сертификата (CA), который выступает за подлинность сертификата и общедоступный ключ шифрования сервера.
• Клиент подтверждает обоснованность сертификата перед продолжением.
• Чтобы сгенерировать клавиши сеансов, используемые для безопасного соединения, клиент тоже:
  • Шифрует случайное число ( PremasterSecret ) с открытым ключом сервера и отправляет результат на сервер (который должен иметь возможность расшифровывать с его закрытым ключом); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session, or
  • Использует обмен клавишами диффи-Hellman (или его вариант эллиптической кривой DH ), чтобы надежно генерировать случайный и уникальный сеанс для шифрования и дешифрования, который обладает дополнительным свойством прямой секретности : если закрытый ключ сервера раскрывается в будущем, это не может быть используется для расшифровки текущего сеанса, даже если сеанс перехвачен и записан третьей стороной.

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

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

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

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

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

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

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

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

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

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

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

История и развитие

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

Протокол	Опубликовано	Статус
Старая версия, больше не поддерживается: SSL 1.0	Неопубликованный	Неопубликованный
Old version, no longer maintained: 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 -й национальной конференции по компьютерной безопасности в обширном наборе опубликованных документов. Инновационная исследовательская программа была направлена ​​на разработку следующего поколения сети Secure Computer Communications и спецификации продуктов, которые будут реализованы для приложений на государственных и частных интернете. Он был предназначен для дополнения быстро появляющихся новых интернет-стандартов OSI, продвигающихся как в профилях Gosip правительства США, так и в огромных интернет-усилиях ITU-ISO JTC1 на международном уровне. Первоначально известный как протокол SP4, он был переименован в TLS и впоследствии опубликован в 1995 году как международный стандарт ITU-T X.274 | ISO/IEC 10736: 1995.

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

Ранние исследовательские усилия по обеспечению безопасности транспортного уровня включали в себя Secure Network Programming (SNP) интерфейс прикладного программирования (API), который в 1993 году изучал подход к тому, чтобы API безопасного транспортного уровня, близко напоминающий розетки Беркли , для облегчения модернизации предварительных приложений сети с безопасностью с безопасностью с безопасностью меры. SNP was published and presented in the 1994 USENIX Summer Technical Conference. Проект SNP был профинансирован грантом от АНБ профессору Саймону Лэму в UT-Oustin в 1991 году. Secure Network Programming выиграла премию ACM Software System 2004 года . Саймон Лэм был введен в Зал славы Интернета для «изобретения безопасных розетков и внедрения первого уровня безопасных сокетов с именем 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 как исторический документ в RFC 6101.

SSL 2.0 был устарел в 2011 году RFC   6176 . В 2014 году было обнаружено, что SSL 3.0 был уязвим для атаки пуделя , которая затрагивает все блокировки шифров в 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 совместно объявили, что в марте 2020 года они будут осуществлять TLS 1,0 и 1,1. 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 и браузеров на основе хрома до 29.

TLS 1.2

TLS 1.2 был определен в RFC   5246 в августе 2008 года. It is based on the earlier TLS 1.1 specification. Major differences include:

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

Все версии TLS были дополнительно уточнены в RFC   6176 в марте 2011 года, удаляя их обратную совместимость с SSL, так что сессии TLS никогда не обсуждают использование версии 2.0 Secure Sockets Layer (SSL). There is currently no formal date for TLS 1.2 to be deprecated. The specifications for TLS 1.2 became redefined as well by the Standards Track Document RFC   8446 , чтобы сохранить его как можно более безопасным; Сейчас его следует рассматривать как протокол отказа от переключения, означающий только с клиентами, которые не могут говорить о TLS 1.3 (с тех пор устаревшее определение RFC 5246 для TLS 1.2).

TLS 1.3

TLS 1.3 был определен в RFC 8446 в августе 2018 года. It is based on the earlier TLS 1.2 specification. Основные отличия от TLS 1.2 включают:

• Отделение ключевых соглашений и алгоритмов аутентификации от Sipher Suites
• Удаление поддержки слабых и менее используемых эллиптических кривых
• Удаление поддержки криптографических хэш-функций MD5 и SHA-224
• Требование цифровых подписей, даже когда используется предыдущая конфигурация
• Интеграция HKDF и полуэфемеральное предложение DH
• Замена возобновления на PSK и билеты
• Supporting 1-RTT handshakes and initial support for 0-RTT
• Обязательная идеальная прямая секретность с помощью эфемерных ключей во время соглашения (EC) ключа DH
• Отброшение поддержки многих небезопасных или устаревших функций, включая сжатие , пересмотр, не AEAD шифры, нулевые шифры , Обмен ключами не PFS (среди которых являются статические обмены ключами RSA и статическим DH ), пользовательские группы DHE , переговоры о формате точки EC, протокол Spec Spec с изменением шифра, Hello Message Unix и ввод AD в поле длины для Aead Ciphers
• Запрещение переговоров SSL или RC4 для обратной совместимости
• Интеграция использования хэша сеанса
• Универсание использования номера версии уровня записей и замораживание номера для улучшения обратной совместимости
• Перемещение некоторых сведений об алгоритме, связанных с безопасностью, из приложения в спецификацию и перевести ClientKeyShare в приложение
• Добавление шифра потока Chacha20 с Poly1305 кодом аутентификации сообщений
• Adding the Ed25519 and Ed448 digital signature algorithms
• Добавление X25519 и X448 протоколов обмена ключами
• Adding support for sending multiple OCSP responses
• Шифрование всех сообщений рукопожатия после ServerHello

Службы безопасности сети (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 Poat .

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

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

Wolfssl включил использование TLS 1.3 по состоянию на версию 3.11.1, выпущенной в мае 2017 года. В качестве первой коммерческой реализации TLS 1.3 Wolfssl 3.11.1 поддержал проект 18 и теперь поддерживает проект 28, the final version, as well as many older versions. A series of blogs were published on the performance difference between TLS 1.2 and 1.3.

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

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

Enterprise Transport Security

Фонд Electronic Frontier похвалил TLS 1.3 и выразил обеспокоенность по поводу варианта протокола корпоративной транспортной безопасности (ETS), которая намеренно отключает важные меры безопасности в TLS 1.3. Первоначально называемый Enterprise TLS (ETLS), ETS является опубликованным стандартом, известным как « Etsi TS103523-3», «Протокол безопасности Middlebox, часть 3: корпоративная транспортная безопасность». It is intended for use entirely within proprietary networks such as banking systems. ETS не поддерживает прямую секретность, чтобы позволить сторонним организациям, подключенным к проприетарным сетям, чтобы иметь возможность использовать свой личный ключ для мониторинга сетевого трафика для обнаружения вредоносных программ и облегчения проведения аудитов. Несмотря на заявленные преимущества, EFF предупредил, что потеря прямой секретности может облегчить разоблачение данных, а также заявление о том, что есть лучшие способы анализа трафика.

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

Main article: Public key certificate

Example of a website with digital certificate

Цифровой сертификат подтверждает право собственности на открытый ключ по названным предметам сертификата и указывает определенные ожидаемые использование этого ключа. Это позволяет другим (полагаться на стороны) полагаться на подписи или на утверждения, сделанные частным ключом, который соответствует сертифицированному открытому ключу. Keystores and trust stores can be in various formats, such as .pem , .crt, .pfx , and .jks .

Certificate authorities

Main article: Certificate authority

TLS typically relies on a set of trusted third-party certificate authorities to establish the authenticity of certificates. Trust is usually anchored in a list of certificates distributed with user agent software, and can be modified by the relying party.

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

В результате выбора сертификатов X.509 , властей сертификатов и инфраструктуры открытого ключа необходимы для проверки связи между сертификатом и его владельцем, а также для создания, подписи и управления достоверностью сертификатов. Несмотря на то, что это может быть более удобным, чем проверка личности через сеть доверия , раскрытие массового наблюдения за 2013 год сделало более широким известным, что власти сертификатов являются слабым пунктом с точки зрения безопасности, что позволяет атаковать человека в среднем уровне (MITM) if the certificate authority cooperates (or is compromised).

Важность сертификатов SSL

• Шифрование : SSL -сертификаты шифруют данные, отправленные между веб -сервером и браузером пользователя, гарантируя, что конфиденциальная информация защищена на протяжении всей передачи. Эта технология шифрования мешает несанкционированным сторонам перехватить и интерпретировать данные, поэтому защита их от возможных рисков, таких как взлом или нарушения данных.
• Аутентификация : SSL -сертификаты также предлагают аутентификацию, подтверждая целостность веб -сайта и что посетители подключаются к правильному серверу, а не к злоумышленному самозванцу. This authentication method helps consumers gain trust by ensuring that they are dealing with a trustworthy and secure website.
• Integrity: Another important role of SSL certificates is to ensure data integrity. SSL uses cryptographic techniques to verify that data communicated between the server and the browser is intact and unmodified during transit. This keeps malevolent actors from interfering with the data, ensuring its integrity and trustworthiness.

Алгоритмы

See also: Cipher suite

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

Прежде чем клиент и сервер могут начать обменять информацию, защищенную TLS, они должны безопасно обмениваться или договориться о ключке шифрования и шифром для использования при шифровании данных (см. § шифр ). Среди методов, используемых для обмена ключами/соглашением: публичные и частные ключи, сгенерированные с помощью RSA (обозначенный TLS_RSA в протоколе рукопожатия TLS), Diffie -Hellman (TLS_DH), диффер эфемеральный TLS_ECDH), ephemeral elliptic-curve Diffie–Hellman (TLS_ECDHE), anonymous Diffie–Hellman (TLS_DH_anon), pre-shared key (TLS_PSK) and Secure Remote Password (TLS_SRP).

Методы согласия ключей TLS_DH_ANON и TLS_ECDH_ANON не аутентифицируют сервер или пользователя и, следовательно, редко используются, потому что они уязвимы для атак человека в среднем уровне . Only TLS_DHE and TLS_ECDHE provide forward secrecy .

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

Key exchange/agreement and authentication

Алгоритм	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Статус
RSA	Да	Да	Да	Да	Да	Нет	Defined for TLS 1.2 in RFCs
DH - RSA	Нет	Да	Да	Да	Да	Нет
DHE-RSA (forward secrecy)	Нет	Да	Да	Да	Да	Да
ECDH - RSA	Нет	Нет	Да	Да	Да	Нет
ECDHE-RSA (forward secrecy)	Нет	Нет	Да	Да	Да	Да
DH - DSS	Нет	Да	Да	Да	Да	Нет
DHE - DSS (Секретность вперед)	Нет	Да	Да	Да	Да	Нет
И - Ecdsa (прямая секретность)	Нет	Нет	Нет	Нет	Нет	Да
ECDA - ECDSA	Нет	Нет	Да	Да	Да	Нет
ECDHE-ECDSA (forward secrecy)	Нет	Нет	Да	Да	Да	Да
И - Eddsa (форвардный секретарь)	Нет	Нет	Нет	Нет	Нет	Да
ECDH-EdDSA	Нет	Нет	Да	Да	Да	Нет
ECDHE-EdDSA (forward secrecy)	Нет	Нет	Да	Да	Да	Да
PSK	Нет	Нет	Да	Да	Да	Да
RSA - PSK	Нет	Нет	Да	Да	Да	Нет
И - PSK (Секретность вперед)	Нет	Нет	Да	Да	Да	Да
ECDHE-PSK (forward secrecy)	Нет	Нет	Да	Да	Да	Да
SRP	Нет	Нет	Да	Да	Да	Нет
SRP-DSS	Нет	Нет	Да	Да	Да	Нет
SRP - RSA	Нет	Нет	Да	Да	Да	Нет
Kerberos	Нет	Нет	Да	Да	Да	?
DH -Anon (небезопасность)	Нет	Да	Да	Да	Да	Нет
ECDH -Anon (небезопасность)	Нет	Нет	Да	Да	Да	Нет
GOST R 34.10-2012	Нет	Нет	Нет	Нет	Да	Да	Определяется для TLS 1.2 и для TLS 1,3 в RFC   9189 , 9367 .

Шифр

См. Также: Краткое изложение безопасности шифра , блокировки шифра и защиты шифров

Безопасность шифра от общедоступных возможных атак

Шифр			Версия протокола						Статус
Тип	Алгоритм	Номинальная сила (биты)	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Блок шифр с Режим работы	AES GCM	256, 128	—	—	—	—	Безопасный	Безопасный	Defined for TLS 1.2 in RFCs
	AES CCM		—	—	—	—	Безопасный	Безопасный
	AES CBC		—	Ненадежный	Зависит от смягчений	Зависит от смягчений	Зависит от смягчений	—
	Camellia GCM	256, 128	—	—	—	—	Безопасный	—
	Camellia CBC		—	Ненадежный	Зависит от смягчений	Зависит от смягчений	Зависит от смягчений	—
	Ария GCM	256, 128	—	—	—	—	Безопасный	—
	ARIA CBC		—	—	Зависит от смягчений	Зависит от смягчений	Зависит от смягчений	—
	Семя CBC	128	—	Ненадежный	Зависит от смягчений	Зависит от смягчений	Зависит от смягчений	—
	3DES EDE CBC	112	Ненадежный	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—
	GOST R 34.12-2015 MAGMA CTR	256	—	—	Ненадежный	Ненадежный	Ненадежный	—	Определено в RFC   4357 , 9189
	Gost r 34.12-2015 kuznyechik ctr	256	—	—	—	—	Безопасный	—	Определено в RFC   9189
	Gost r 34.12-2015 Magma mgm	256	—	—	—	—	—	Ненадежный	Определено в RFC   9367
	GOST R 34.12-2015 Kuznyechik MGM	256	—	—	—	—	—	Безопасный	Определено в RFC   9367
	Идея CBC	128	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	—	Удалено из TLS 1.2
	Des CBC	0 56	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	—
		0 40	Ненадежный	Ненадежный	Ненадежный	—	—	—	Запрещено в TLS 1.1 и позже
	RC2 CBC	0 40	Ненадежный	Ненадежный	Ненадежный	—	—	—
Поток шифр	Chacha20 - Poly1305	256	—	—	—	—	Безопасный	Безопасный	Defined for TLS 1.2 in RFCs
	RC4	128	Ненадежный	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	Запрещено во всех версиях TLS RFC   7465
		0 40	Ненадежный	Ненадежный	Ненадежный	—	—	—
Никто	Нулевой	–	Ненадежный	Ненадежный	Ненадежный	Ненадежный	Ненадежный	—	Defined for TLS 1.2 in RFCs

Примечания

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

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

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

Алгоритм	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Статус
HMAC - MD5	Да	Да	Да	Да	Да	Нет	Defined for TLS 1.2 in RFCs
HMAC - SHA1	Нет	Да	Да	Да	Да	Нет
HMAC - SHA256/384	Нет	Нет	Нет	Нет	Да	Нет
Аэдж	Нет	Нет	Нет	Нет	Да	Да
GOST 28147-89 Имит	Нет	Нет	Нет	Нет	Да	Нет	Определено для TLS 1,2 в RFC   9189 .
Gost r 34.12-2015 aead	Нет	Нет	Нет	Нет	Нет	Да	Определено для TLS 1,3 в RFC   9367 .

Заявки и принятие

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

Исторически, TLS использовался в основном с надежными транспортными протоколами, такими как протокол контроля передачи (TCP). Тем не менее, он также был реализован с помощью транспортных протоколов, ориентированных на дейтаграмму, такими как протокол Datagram пользователя (UDP) и протокол контроля заторов Datagram (DCCP), использование которого было стандартизировано независимо с использованием термина DataGram Transport Layer Security ( DTL ). Полем

Веб -сайты

Основное использование TLS заключается в обеспечении обеспечения транспорта World Wide Web между веб -сайтом и веб -браузером, закодированным с протоколом HTTP. Это использование TLS для обеспечения HTTP -трафика представляет собой протокол HTTPS .

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

Протокол версия	Веб -сайт поддерживать	Безопасность
Old version, no longer maintained: 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 Support Support Lifecycle Policy Archived 2023-06-20 на The Wayback Machine », начиная с 12 января 2016 года, только самая современная версия Internet Explorer, доступный для поддерживаемой операционной системы, получит техническую поддержку и обновления безопасности ». Затем на странице перечислены последняя поддерживаемая версия IE на эту дату для каждой операционной системы. Следующая критическая дата будет, когда операционная система достигает стадии окончания жизни. С 15 июня 2022 года Internet Explorer 11 отказался от поддержки для Windows 10 Editions , которые следуют политике Microsoft в области современной жизненной политики.

Смягчения против известных атак еще недостаточно:

• Смягчение против атаки пуделя : некоторые браузеры уже предотвращают запасную часть SSL 3.0; Тем не менее, это смягчение должно быть поддержано не только клиентами, но и серверами. Требуется отключение самого SSL 3.0, реализация «расщепления рекордсменов против закупок» или отказ CBC Ciphers в SSL 3.0.
  • Google Chrome: Complete (TLS_FANKBACK_SCSV реализован с момента версии 33, Sharkback to 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_FANKBACK_SCSV реализована с версии 35. В ESR, SSL 3.0 отключена по умолчанию и TLS_FALLBACK_SCSV реализованы с ESR 31.3.0.)
  • Internet Explorer: частично (только в версии 11, SSL 3.0 отключен по умолчанию с апреля 2015 года. Версия 10 и старше по -прежнему уязвима против Пудела.)
  • Opera : завершено (TLS_FANDBACK_SCSV реализована с тех пор, как версия 20 «Расщепление записей против PODLE», которая вступает в силу только с реализацией на стороне клиента, внедрена, поскольку версия 25, SSL 3.0 отключена по умолчанию с момента версии 27. Поддержка SSL 3.0. Сам будет отброшен с версии 31.)
  • SAFARI: Завершите (только на OS X 10,8, а затем и iOS 8, CBC Ciphers во время отступления на 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 (Desktop), Safari (Desktop & Mobile) и Opera (Mobile) имеют на месте.
  • Mozilla Firefox на всех платформах и Google Chrome на Windows не повлиял Freak.

Библиотеки

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

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

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

• Boringssl , вилка OpenSSL для Chrome/Chromium и Android, а также другие приложения Google.
• Ботан , криптографическая библиотека, лицензированная BSD, написанная в C ++.
• BSAFE Micro Edition Suite: многоплатформенная реализация TLS, написанную в C с использованием криптографического модуля с Validated FIPS
• BSAFE SSL-J: библиотека TLS, предоставляемая как проприетарное API, так и API JSSE , используя криптографический модуль с Validated FIPS
• Cryptlib : портативная библиотека криптографии с открытым исходным кодом (включает в себя реализацию TLS/SSL)
• Программисты Delphi могут использовать библиотеку под названием Indy , которая использует OpenSSL или альтернативно ICS, которая теперь поддерживает TLS 1.3.
• Gnutls : бесплатная реализация (LGPL Licensed)
• Java Secure Docket Extension (JSSE): Java API и реализация поставщика (названный Sunjsse)
• Libressl : вилка OpenSSL от OpenBSD Project.
• Matrixssl : двойная лицензированная реализация
• MBED TLS (ранее PolarSSL): крошечная реализация библиотеки SSL для встроенных устройств, предназначенная для простоты использования
• Службы безопасности сети : FIPS 140 Проверенная библиотека с открытым исходным кодом
• OpenSSL : бесплатная реализация (лицензия BSD с некоторыми расширениями)
• Schannel : реализация SSL и TLS Microsoft Windows как часть своего пакета.
• Безопасный транспорт : реализация SSL и TLS, используемых в OS X и iOS как часть их пакетов.
• Wolfssl (ранее CYASSL): встроенная библиотека SSL/TLS с сильным фокусом на скорости и размере.

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

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

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

Простой протокол передачи почты (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 было предложено расширение индикации пересмотра. Это потребует, чтобы клиент и сервер включали и проверяли информацию о предыдущих рукопожатиях в любые рукопожатия пересмотра. Это расширение стало предложенным стандартом и назначили номер RFC   5746 . RFC был реализован несколькими библиотеками.

Атаки понижения: атака Freak и Attack Logjam

Основные статьи: Понижение атаки , урод и logjam (компьютерная безопасность)

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

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

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

Logjam-это эксплойт безопасности , обнаруженный в мае 2015 года, который использует Legacy «Export Grade» . 512-разрядные группы Diffie-Hellman, датируемые Он заставляет восприимчивые серверы понижать в криптографически слабых 512-битных группах дифференцированных. Затем злоумышленник может вывести клавиши, которые клиент и сервер определяют, используя обмен клавишами Diffie - Hellman .

Поперечные атаки: утонуть

Основная статья: утопление атаки

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

Атака зверя

23 сентября 2011 года исследователи Thai Duong и Juliano Rizzo продемонстрировали доказательство концепции под названием Beast ( браузер Exploit против SSL/TLS ) Использование Java Applet для нарушения одинаковых ограничений политики происхождения , для давно известной уязвимости цепочки блоков шифров (CBC) в TLS 1.0: Злоумышленник, наблюдающий 2 последовательных блока зашифрованного текста C0, C1 может проверить, равен ли блоку открытого текста P1, выбирая следующий текстовый блок 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 как шифр потока невосприимчив к атаке зверя. Следовательно, RC4 широко использовался как способ смягчения атаки зверя на стороне сервера. Однако в 2013 году исследователи обнаружили больше слабостей в RC4. После этого включение RC4 на стороне сервера больше не было рекомендовано.

Сами Chrome и Firefox не уязвимы для атаки зверя, however, Mozilla updated their NSS libraries to mitigate BEAST-like attacks . NSS is used by Mozilla Firefox and Google Chrome to implement SSL. Некоторые веб -серверы , которые имеют сломанную реализацию спецификации SSL, могут перестать работать в результате.

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

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

Атаки преступности и нарушения

Основные статьи: преступность и нарушение

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

Хотя криминальная атака была представлена ​​как общая атака, которая могла эффективно работать против большого количества протоколов, включая, помимо прочего, TLS, и протоколы слоя применения, такие как SPDY или HTTP , были продемонстрированы только TLS и SPDY и в значительной степени смягчены и смягчены. в браузерах и серверах. Преступное использование против сжатия HTTP вообще не была смягчена, хотя авторы преступности предупредили, что эта уязвимость может быть даже более распространенной, чем сжатие SPDY и TLS. В 2013 году был объявлен новый случай преступной атаки на сжатие HTTP, получившее название Breach . Основываясь на атаке преступности, атака нарушения может извлечь токены входа в систему, адреса электронной почты или другую конфиденциальную информацию из TLS зашифрованного веб -трафика всего за 30 секунд (в зависимости от количества байтов, которые будут извлечены), при условии, что злоумышленник обманывает жертву в посещение Злоусовеченная веб -ссылка или способна внедрять контент в действительные страницы, которые посещает пользователь (например, беспроводная сеть под управлением злоумышленника). Все версии TLS и SSL подвергаются риску нарушения независимо от использования алгоритма шифрования или шифра. В отличие от предыдущих экземпляров преступности, от которых можно успешно защищать, отключив сжатие TLS или сжатие заголовка SPDY, нарушение использует HTTP сжатие, которое не может быть реалистично отключить, поскольку практически все веб -серверы полагаются на его улучшение скорости передачи данных для пользователей. Это известное ограничение TLS, поскольку он подвержен атаке с выбранным Plaintext против данных, которые он должен был защитить.

Время атаки на прокладку

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

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

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

Атака пуделя

Основная статья: Пудель

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

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

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

RC4 атаки

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

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

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

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

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

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

Опубликовано в июле 2013 года, Атака заставляет веб-сервисы, такие как Gmail и Hotmail, отображают страницу, которая сообщает пользователю, что они успешно подписали, обеспечивая при этом, что браузер пользователя поддерживает авторизацию с помощью службы, позволяя злоумышленнику с последующим доступом к браузеру к доступу и Возьмите контроль над регистральной учетной записью пользователя. Атака не полагается на установку вредоносных программ на компьютер жертвы; Злоумышленники должны разместить себя только между жертвой и веб -сервером (например, путем настройки мошеннической беспроводной точки доступа). This vulnerability also requires access to the victim's computer. Другая возможность заключается в использовании FTP, подключение к данным может иметь ложный плавник в потоке данных, и если правила протокола для обмена оповещениями close_notify не придерживаются файла, могут быть усечены.

Основная атака против DTLS

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

Нечестивая атака PAC

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

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

Sweet32 атака

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

Ошибки реализации: Heartbleed Bug, Berserk Attack, CloudFlare ошибка

Основные статьи: Сердечный и облачный

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

В сентябре 2014 года вариант Daniel Bleichenbacher 's PKCS#1 v1.5 Уязвимость подделки подделки RSA RSA был объявлен Intel Security Advanced Research. Эта атака, получившая название Berserk, является результатом неполного декодирования длины ASN.1 в некоторых реализациях SSL и позволяет атаковать человека в среднем уровне, создавая подпись открытого ключа.

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

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

В феврале 2017 года ошибка реализации, вызванная одним ошибкой символом в коде, используемом для анализа HTML, создала ошибку переполнения буфера на серверах CloudFlare . Подобная по своему эффекту для сердца, обнаруженной в 2014 году, эта ошибка переполнения, широко известная как облачная , позволила несанкционированным третьим сторонам читать данные в памяти программ, работающих на серверах - DATA, которые в противном случае должны были быть защищены TLS.

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

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

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

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

Впередная секретность

Main article: Forward secrecy

Впередная секретность - это свойство криптографических систем, которое гарантирует, что ключ сессии, полученный из набора государственных и частных ключей, не будет скомпрометирован, если в будущем будет скомпрометирован один из частных ключей. Без отстранения секретности, если закрытый ключ сервера будет скомпрометирован, не только будут скомпрометированы все будущие сеансы TLS с использованием этого сертификата сервера, но и любые прошлые сеансы, которые также использовали его (при условии, что эти прошлые сеансы были перехвачены и хранятся в time of transmission). Реализация TLS может обеспечить отсрочку секретности, требуя использования эфемерных обменов ключами дифференцировки - Hellman для создания клавиш сессии, а некоторые примечательные реализации TLS делают это исключительно: например, Gmail и другие услуги Google HTTPS, которые используют OpenSSL . Тем не менее, многие клиенты и серверы, поддерживающие TLS (включая браузеры и веб -серверы), не настроены для реализации таких ограничений. На практике, если веб -сервис не использует обмен ключами диффи - Hellman для реализации прямой секретности, весь зашифрованный веб -трафик в и обратно может быть расшифрована третьей стороной, если она получает мастер -ключ (частный) сервера; eg, by means of a court order.

Даже там, где реализован обмен клавишами Diffie-Hellman, механизмы управления сеансами на стороне сервера могут повлиять на секретность вперед. Использование билетов с сеансами TLS (расширение TLS) приводит к защите сеанса AES128-CBC-SHA256 независимо от любых других согласованных параметров TLS, включая ключи от сессии TLS, которые победили попытки реализовать Впередная секретность. Исследования Стэнфордского университета в 2014 году также показали, что из 473 802 опрошенных серверов TLS 82,9% серверов, развертывающих эфемерные дифференцированные ключевые обмены (DHE) для поддержки прямой секретности, были использованы параметры слабых параметров Diffie -Hellman. These weak parameter choices could potentially compromise the effectiveness of the forward secrecy that the servers sought to provide.

С конца 2011 года Google по умолчанию обеспечил секретность с TLS для пользователей своей службы Gmail , а также Google Docs и зашифрованный поиск, а также другие службы. Since November 2013, Twitter has provided forward secrecy with TLS to users of its service. По состоянию на август 2019 года , about 80% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to most web browsers.

TLS перехват

See also: Server Name Indication § Encrypted Client Hello

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

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

A significant drawback of TLS/HTTPS interception is that it introduces new security risks of its own. Одним из заметных ограничений является то, что он обеспечивает точку, в которой сетевой трафик доступен незашифрован, что дает злоумышленникам стимул атаковать эту точку, в частности, чтобы получить доступ к иным образом безопасному контенту. Перехват также позволяет оператору сети или лицам, которые получают доступ к своей системе перехвата, выполнять атаки человека в среднем уровне против пользователей сети. Исследование 2017 года показало, что «перехват HTTPS стал поразительно широко распространенным, и что продукты перехвата в качестве класса оказывают значительно негативное влияние на безопасность соединения».

Детали протокола

The TLS protocol exchanges records , which encapsulate the data to be exchanged in a specific format (see below). Каждая запись может быть сжата, мягкой, добавленной с кодом аутентификации сообщения (MAC) или зашифрована, все в зависимости от состояния соединения. Each record has a content type field that designates the type of data encapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messages of the TLS itself, or simply the application data needed to be transferred by TLS. Технические характеристики (набор шифров, клавиши и т. Д.), Необходимые для обмена данными приложения с помощью TLS, согласованы в рукопожатии TLS между клиентом, запрашивающим данные, и сервером, отвечающим на запросы. Таким образом, протокол определяет как структуру полезных нагрузок, передаваемых в TLS, так и процедуру для установления и мониторинга передачи.

Руководство TLS

Simplified illustration of the full TLS 1.2 handshake with timing information

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

Basic TLS handshake

A typical connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:

1. Negotiation phase:
   • Клиент отправляет сообщение ClientHello , указывающее самую высокую версию протокола TLS, которое она поддерживает, случайное число, список предлагаемых комплексных наборов и предлагаемых методов сжатия. Если клиент пытается выполнить возобновляемое рукопожатие, он может отправить идентификатор сеанса . Если клиент может использовать переговоры по протоколу приложений , он может включать список поддерживаемых протоколов приложения , таких как HTTP/2 .
   • Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из выбора, предлагаемых клиентом. Чтобы подтвердить или разрешить возобновляемые рукопожатия, сервер может отправить идентификатор сеанса . Выбранная версия протокола должна быть самой высокой поддержкой клиента и сервера. Например, если клиент поддерживает TLS версию 1.1, а сервер поддерживает версию 1.2, должна быть выбрана версия 1.1; Версия 1.2 не должна быть выбрана.
   • Сервер отправляет свое сообщение о сертификате (в зависимости от выбранного набора шифров, это может быть опущено сервером).
   • Сервер отправляет свое сообщение ServerKeyExchange (в зависимости от выбранного набора шифров, это может быть опущено сервером). Это сообщение отправлено для всех люксов DHE , ECDHE и DH_ANON CIPHER.
   • Сервер отправляет сообщение ServerHellodone , указывая, что оно сделано с помощью согласования рукопожатия.
   • Клиент отвечает сообщением ClientKeyExchange , которое может содержать PremesterSecret , Public Key или ничего. (Опять же, это зависит от выбранного шифра.) Этот Premstersecret зашифруется с помощью открытого ключа сертификата сервера.
   • Затем клиент и сервер используют случайные числа и Premstersecret для вычисления общего секрета, называемого «Master Secret». Все другие ключевые данные ( клавиши сеансов , такие как IV , симметричного шифрования клавиша , MAC -ключ ) для этого соединения получено из этого мастер-секрета (и случайных случайных значений, сгенерированных клиентом и сервером), которые передаются через тщательно разработанную псевдоходовую функцию.
2. Теперь клиент отправляет запись Changecipherspec , по сути, сообщая серверу: «Все, что я вам сейчас говорю, будет аутентифицировано (и зашифровано, если в сертификате сервера присутствовали параметры шифрования)». Changecipherspec сам по себе является протоколом на уровне записей с типом контента 20.
   • Клиент отправляет аутентифицированное и зашифрованное готовое готовое сообщение, содержащее хэш и Mac, на предыдущие сообщения рукопожатия.
   • сообщение клиента Сервер попытается расшифровать готовое и проверить хэш и Mac. Если дешифрование или проверка не удастся, считается, что рукопожатие не удалось, а соединение должно быть прекращено.
3. Наконец, сервер отправляет Changecipherspec , сообщая клиенту: «Все, что я вам сейчас говорю, будет аутентифицировано (и зашифровано, если будет согласовано шифрование)».
   • Сервер отправляет свое аутентифицированное и зашифрованное готовое сообщение.
   • Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем шаге.
4. Фаза приложения: На этом этапе «рукопожатие» завершено, и протокол приложения включен, с типом контента 23. Сообщения приложения, обмениваемые между клиентом и сервером, также будут аутентифицированы и необязательно зашифрованы точно так же, как в их готовом сообщении. В противном случае тип контента вернется 25, а клиент не будет аутентифицировать.

Клиентское рукопожатие TLS

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

1. Этап переговоров:
   • Клиент отправляет сообщение ClientHello , указывающее самую высокую версию протокола TLS, которое она поддерживает, случайное число, список предлагаемых комплексов шифров и методов сжатия.
   • Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из выбора, предлагаемых клиентом. Сервер также может отправить идентификатор сеанса как часть сообщения для выполнения возобновления рукопожатия.
   • Сервер отправляет свое сообщение о сертификате (в зависимости от выбранного набора шифров, это может быть опущено сервером).
   • Сервер отправляет свое сообщение ServerKeyExchange (в зависимости от выбранного набора шифров, это может быть опущено сервером). Это сообщение отправлено для всех цифровых судов DHE, ECDHE и DH_ANON. ^[1]
   • Сервер отправляет сообщение SertaTeRequest , чтобы запросить сертификат у клиента.
   • Сервер отправляет сообщение ServerHellodone , указывая, что оно сделано с помощью согласования рукопожатия.
   • Клиент отвечает сообщением о сертификате , которое содержит сертификат клиента, но не его закрытый ключ.
   • Клиент отправляет сообщение ClientKeyExchange , которое может содержать PremesterSecret , Public Key или ничего. (Опять же, это зависит от выбранного шифра.) Этот Premstersecret зашифруется с помощью открытого ключа сертификата сервера.
   • Клиент отправляет сообщение CertaTeerVerify , которое является подписью по предыдущим сообщениям рукопожатия, используя закрытый ключ сертификата клиента. Эта подпись может быть проверена с помощью открытого ключа сертификата клиента. Это позволяет серверу знать, что клиент имеет доступ к закрытому ключу сертификата и, таким образом, владеет сертификатом.
   • Затем клиент и сервер используют случайные числа и Premstersecret для вычисления общего секрета, называемого «Master Secret». Все другие ключевые данные («клавиши сеансов») для этого подключения получены из этого мастер-секрета (и случайных случайных значений, сгенерированных клиентом и сервером), которые передаются через тщательно разработанную функцию псевдорандома.
2. Теперь клиент отправляет запись Changecipherspec , по сути, сообщая серверу: «Все, что я вам сейчас говорю, будет аутентифицировано (и зашифровано, если будет согласовано шифрование)». Bangecipherspec сам по себе является протоколом на уровне рекорда и имеет тип 20, а не 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22. Полем
   • Наконец, клиент отправляет зашифрованное готовое сообщение, содержащее хэш и Mac, на предыдущие сообщения рукопожатия.
   • сообщение клиента Сервер попытается расшифровать готовое и проверить хэш и Mac. Если дешифрование или проверка не удастся, считается, что рукопожатие не удалось, и соединение должно быть снесено.
3. Наконец, сервер отправляет Changecipherspec , сообщая клиенту: «Все, что я вам сейчас говорю, будет аутентифицировано (и зашифровано, если будет согласовано шифрование)».
   • Сервер отправляет свое собственное зашифрованное готовое сообщение.
   • Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем шаге.
4. Фаза приложения: На этом этапе «рукопожатие» завершено, и протокол приложения включен, с типом контента 23. Сообщения приложений, обмениваемые между клиентом и сервером, также будут зашифрованы точно так же, как в их готовом сообщении.

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

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

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

TLS 1.3 Руководство

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

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

После того, как клиент получает готовое сообщение сервера, теперь он координируется с сервером, на котором использовать Sipher Suite.

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

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

1. Negotiation phase:
   • Клиент отправляет сообщение ClientHello , указывающее самую высокую версию протокола TLS, которое она поддерживает, случайное число, список предлагаемых комплексов шифров и методов сжатия. В сообщение включен идентификатор сеанса из предыдущего соединения TLS.
   • Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из выбора, предлагаемых клиентом. Если сервер распознает идентификатор сеанса, отправленный клиентом, он отвечает тем же идентификатором сеанса . Клиент использует это, чтобы узнать, что выполняется возобновляемое рукопожатие. Если сервер не распознает идентификатор сеанса, отправленный клиентом, он отправляет другое значение для своего идентификатора сеанса . Это говорит клиенту, что возобновляемое рукопожатие не будет выполнено. На этом этапе как клиент, так и сервер имеют «мастер -секрет» и случайные данные для генерации ключевых данных, которые будут использоваться для этого соединения.
2. Сервер теперь отправляет запись Changecipherspec , по сути, рассказывает клиенту: «Все, что я вам сейчас говорю, будет зашифровано». Changecipherspec сам по себе является протоколом рекордного уровня и имеет тип 20, а не 22.
   • Наконец, сервер отправляет зашифрованное готовое сообщение, содержащее хэш и Mac на предыдущие сообщения рукопожатия.
   • сообщение сервера Клиент попытается расшифровать готовое и проверить хэш и 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 Record

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

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

Компенсировать	Байт+0	Байт+1	Байт+2	Байт+3
Байт 0	Тип контента	—
Байты 1–4	Наследия версия		Длина
	(Главный)	(Незначительный)	(Биты 15–8)	(биты 7–0)
Байты 5– ( м −1)	Сообщение протокола (ы)
Байты М - ( P -1)	Mac (необязательно)
Байты P - ( Q -1)	Заполнение (только блок шифров)

Тип контента

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

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

Гекс	Декабрь	Тип
0×14	20	Changecipherspec
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	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2
3	4	TLS 1.3

Длина

Длина «сообщений протокола», «mac» и «надое» поля вместе взятые (т.е. q -5), чтобы не превышать 2 ¹⁴ байты (16 киб).

Сообщение протокола (ы)

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

Mac и прокладка

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

Никакие поля «Mac» или «Padding» не могут присутствовать в конце записей 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)	Данные сообщений рукопожатия
Байты n - ( n +3)	Тип сообщения	Длина данных
		(Биты 23–16)	(Биты 15–8)	(биты 7–0)
Байты ( N +4) -	Данные сообщений рукопожатия

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

Это поле идентифицирует тип сообщения рукопожатия.

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

Код	Описание
0	Hellorequest
1	ClientHello
2	ServerHello
4	NewsessionTicket
8	EncryptedExtensions (только TLS 1,3)
11	Сертификат
12	ServerKeyExchange
13	Сертификат
14	ServerHellodone
15	Сертификация
16	ClientKeyExchange
20	Законченный

Длина данных

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

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

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

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

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

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

Уровень

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

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

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

Код	Тип уровня	Состояние связи
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	Неизвестный CA ( орган сертификации )	фатальный	Только TLS
49	Доступ запрещен	фатальный	Только TLS - например, сертификат клиента не был представлен (TLS: пустое сообщение о сертификате или SSLV3: нет предупреждения о сертификате), но сервер настроен на то, чтобы он требовался.
50	Ошибка декодирования	фатальный	Только TLS
51	Decrypt Erry	Предупреждение / смертельный	Только 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)	Данные приложения
Байты М - ( P -1)	Mac (необязательно)
Байты P - ( Q -1)	Заполнение (только блок шифров)

Длина

Продолжительность данных приложения (за исключением заголовка протокола и включающего прицепы Mac и накладки)

Маки

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

Прокладка

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

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

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

Есть два известных обходных путей, предоставленных X.509 :

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

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

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

Смотрите также

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

Дальнейшее чтение

• Вагнер, Дэвид; Шнайер, Брюс (ноябрь 1996 г.). «Анализ протокола SSL 3.0» (PDF) . Второй семинар USENIX по разбирательству в области коммерции . Usenix Press. С. 29–40. Архивировано (PDF) из оригинала 2006-10-16 . Получено 2006-10-12 .
• Rescorla, Eric (2001). SSL и TLS: проектирование и строительство безопасных систем . Соединенные Штаты: Addison-Wesley Pub Co. ISBN  978-0-201-61598-2 .
• Стивен А. Томас (2000). SSL и TLS Essentials, защищающие Интернет . Нью -Йорк: Уайли. ISBN  978-0-471-38354-3 .
• Бард, Грегори (2006). «Тяжелая, но возможная атака с избранной площадью, адаптивная блока, на SSL» . Международная ассоциация криптологических исследований (136). Архивировано из оригинала 2011-09-23 . Получено 2011-09-23 .
• Канвел, Брайс. «Перехват пароля в канале SSL/TLS» . Архивировано с оригинала 2016-04-20 . Получено 2007-04-20 .
• RFC изменений для пересмотра TLS . 2010. DOI : 10.17487/RFC5746 . RFC   5746 .
• Создание VPN с IPSec и SSL/TLS Archived 2015-04-12 в статье Wayback Machine Linux Journal от Rami Rosen
• Джошуа Дэвис (2010). Реализация SSL/TLS . Уайли. ISBN  978-0470920411 .
• Полк, Тим; Маккей, Керри; Чохани, Сантош (апрель 2014 г.). «Рекомендации по выбору, конфигурации и использованию реализаций безопасности транспортного уровня (TLS)» (PDF) . Национальный институт стандартов и технологий. Архивировано из оригинала (PDF) 2014-05-08 . Получено 2014-05-07 .
• Абду, Абдельрахман; Ван Оршот, Пол (август 2017 г.). «Проверка местоположения сервера (SLV) и местоположение сервера: закрепление аутентификации TLS» . ACM транзакции по конфиденциальности и безопасности . 21 (1): 1: 1–1: 26. doi : 10.1145/3139294 . S2CID   5869541 . Архивировано из оригинала 2019-03-22 . Получено 2018-01-11 .
• Иван Рристик (2022). Bulletproof TLS и PKI, второе издание . Злющая утка. ISBN  978-1907117091 .

Основные стандарты

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

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

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

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

Расширения

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

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

• RFC   9367 : «Протокол GOST Cipher Suites для обеспечения безопасности транспортного уровня (TLS) Версия 1.3».

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

• RFC   5288 : « Счетчик AES Galois Counter (GCM) SIPHER Suites для TLS».
• RFC   5289 : «Эллиптическая кривая шифра с эллиптической кривой с SHA-256/384 и режим AES Galois Counter (GCM)».
• RFC   5746 : «Продолжительность безопасности транспортного уровня (TLS) Расширение индикации пересмотра».
• RFC   5878 : «Продолжительность авторизации транспортного уровня (TLS)».
• RFC   5932 : "Camellia Cipher Suites для TLS"
• RFC   6066 : «Расширения безопасности транспортного уровня (TLS): определения расширения» включает индикацию имени сервера и сшивание OCSP .
• RFC   6091 : «Использование клавиш OpenPGP для аутентификации безопасности транспортного уровня (TLS)».
• RFC   6176 : «Запрещение защищенных сокетов (SSL) версия 2.0».
• RFC   6209 : «Добавление авиационных комплексов ARIA для транспортировки безопасности уровня (TLS)».
• RFC   6347 : «Защита транспорта Datagram Transport Version 1.2».
• RFC   6367 : «Добавление камеллии шифровских наборов для транспортировки безопасности уровня (TLS)».
• RFC   6460 : «Профиль Suite B для безопасности транспортного уровня (TLS)».
• RFC   6655 : «AES-CCM SIPHER Suites для безопасности транспортного уровня (TLS)».
• RFC   7027 : «Кривые криптографии эллиптической кривой (ECC) для безопасности транспортного уровня (TLS)».
• RFC   7251 : «Криптография эллиптической кривой AES-CCM (ECC) для TLS».
• RFC   7301 протокола транспортного уровня (TLS) : «Продление переговоров по протоколу протокола ».
• RFC   7366 : «Encrypt-Then-MAC для безопасности транспортного уровня (TLS) и обеспечения транспортного уровня Datagram (DTLS)».
• RFC   7465 : «Запрещение RC4 шифровых апартаментов».
• RFC   7507 : «Значение SICHER SICHER SWARD SWARD SWARKING TLS (SCSV) для предотвращения атак протокола».
• RFC   7568 : «Уничтожая безопасные сокетские слои версии 3.0».
• RFC   7627 : «Сессия транспортного уровня безопасности (TLS) хэш и расширенное расширение мастер -секрета».
• RFC   7685 : «Продолжительность прокладки для прокладки транспортного уровня (TLS).
• RFC   9189 : «Протокол GOST Cipher Suites для безопасности транспортного уровня (TLS) Версия 1.2».

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

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

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

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

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

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

Внешние ссылки

• Целевая группа по интернет-инженерии-TLS Workgroup Archived 2014-01-11 на The Wayback Machine