Протокол TLS в первую очередь направлен на обеспечение безопасности, включая конфиденциальность , целостность и подлинность за счет использования криптографии , например использования сертификатов , между двумя или более взаимодействующими компьютерными приложениями. Он работает на уровне представления и сам состоит из двух уровней: записи TLS и протоколов установления связи TLS .
Тесно связанный протокол безопасности транспортного уровня дейтаграмм ( DTLS ) — это протокол связи , который обеспечивает безопасность приложений на основе дейтаграмм . В технических текстах часто встречаются ссылки на «( D ) TLS », когда они применяются к обеим версиям. [1]
TLS — это предложенный стандарт Internet Engineering Task Force (IETF), впервые определенный в 1999 году, а текущая версия — TLS 1.3, определенная в августе 2018 года. TLS основан на устаревших спецификациях SSL ( Secure Sockets Layer ) (1994, 1995, 1996), разработанный Netscape Communications для добавления протокола HTTPS в их веб-браузер Navigator .
Поскольку приложения могут взаимодействовать как с TLS (или SSL), так и без него, клиенту необходимо запросить у сервера установку соединения TLS. [2] Один из основных способов добиться этого — использовать другой номер порта для соединений TLS. Порт 80 обычно используется для незашифрованного HTTP- трафика, а порт 443 — это общий порт, используемый для зашифрованного HTTPS- трафика. Другой механизм заключается в отправке серверу специфичного для протокола запроса STARTTLS для переключения соединения на TLS — например, при использовании протоколов почты и новостей .
Как только клиент и сервер согласились использовать TLS, они согласовывают соединение с отслеживанием состояния , используя процедуру установления связи (см. § Подтверждение связи TLS). [3] Протоколы используют рукопожатие с асимметричным шифром для установления не только настроек шифрования, но и общего ключа для конкретного сеанса, с помощью которого дальнейшая связь шифруется с использованием симметричного шифра . Во время этого рукопожатия клиент и сервер согласовывают различные параметры, используемые для обеспечения безопасности соединения:
Рукопожатие начинается, когда клиент подключается к серверу с поддержкой TLS, запрашивая безопасное соединение, и клиент представляет список поддерживаемых наборов шифров ( шифров и хэш-функций ).
Из этого списка сервер выбирает шифр и хэш-функцию, которые он также поддерживает, и уведомляет клиента о решении.
Затем сервер обычно предоставляет идентификацию в форме цифрового сертификата . Сертификат содержит имя сервера , доверенный центр сертификации (CA), который подтверждает подлинность сертификата, и общедоступный ключ шифрования сервера.
Прежде чем продолжить, клиент подтверждает действительность сертификата.
Чтобы сгенерировать сеансовые ключи, используемые для безопасного соединения, клиент либо:
шифрует случайное число ( PreMasterSecret ) с помощью открытого ключа сервера и отправляет результат на сервер (который только сервер должен иметь возможность расшифровать с помощью своего закрытого ключа); обе стороны затем используют случайное число для генерации уникального сеансового ключа для последующего шифрования и дешифрования данных во время сеанса, или
использует обмен ключами Диффи-Хеллмана (или его вариант DH с эллиптической кривой ) для безопасной генерации случайного и уникального сеансового ключа для шифрования и дешифрования, который имеет дополнительное свойство прямой секретности : если закрытый ключ сервера будет раскрыт в будущем, он не может быть раскрыт. используется для расшифровки текущего сеанса, даже если сеанс перехвачен и записан третьей стороной.
На этом рукопожатие завершается и начинается защищенное соединение, которое шифруется и расшифровывается с помощью сеансового ключа до тех пор, пока соединение не закроется. Если какой-либо из вышеперечисленных шагов завершается неудачей, подтверждение TLS завершается неудачей и соединение не создается.
TLS и SSL не вписываются ни в один уровень модели OSI или модели TCP/IP . [4] [5] TLS работает «поверх некоторого надежного транспортного протокола (например, TCP)» [6] : §1 , что подразумевает, что он находится над транспортным уровнем . Он обеспечивает шифрование на более высоких уровнях, что обычно является функцией уровня представления . Однако приложения обычно используют TLS, как если бы это был транспортный уровень, [4] [5] , хотя приложения, использующие TLS, должны активно контролировать инициацию рукопожатий TLS и обработку обмененных сертификатов аутентификации. [6] : §1
При защите с помощью TLS соединения между клиентом (например, веб-браузером) и сервером (например, wikipedia.org) будут иметь все следующие свойства: [6] : §1
Соединение является частным (или имеет конфиденциальность ), поскольку для шифрования передаваемых данных используется алгоритм симметричного ключа . Ключи для этого симметричного шифрования генерируются уникально для каждого соединения и основаны на общем секрете, согласованном в начале сеанса. Сервер и клиент согласовывают детали того, какой алгоритм шифрования и криптографические ключи использовать перед передачей первого байта данных (см. ниже). Согласование общего секрета является одновременно безопасным (согласованный секрет недоступен для перехватчиков и не может быть получен даже злоумышленником, оказавшимся в центре соединения) и надежным (ни один злоумышленник не может изменить связь во время согласования, не будучи обнаружено).
Личность взаимодействующих сторон может быть подтверждена с использованием криптографии с открытым ключом . Эта аутентификация необходима для сервера и необязательна для клиента.
Соединение является надежным (или имеет целостность ), поскольку каждое передаваемое сообщение включает проверку целостности сообщения с использованием кода аутентификации сообщения , чтобы предотвратить необнаруженную потерю или изменение данных во время передачи.
TLS поддерживает множество различных методов обмена ключами, шифрования данных и проверки целостности сообщений. В результате безопасная конфигурация TLS включает в себя множество настраиваемых параметров, и не все варианты обеспечивают все свойства конфиденциальности, описанные в списке выше (см. таблицы ниже: § Обмен ключами, § Безопасность шифрования и § Целостность данных).
Были предприняты попытки подорвать аспекты безопасности связи, которые стремится обеспечить TLS, и протокол несколько раз пересматривался для устранения этих угроз безопасности. Разработчики веб-браузеров неоднократно пересматривали свои продукты, чтобы защититься от потенциальных недостатков безопасности после того, как они были обнаружены (см. историю поддержки TLS/SSL веб-браузерами).
Поскольку дейтаграмма протокола DTLS сохраняет семантику базового транспорта — приложение не страдает от задержек, связанных с потоковыми протоколами, однако приложению приходится иметь дело с переупорядочением пакетов , потерей дейтаграммы и данными, превышающими размер дейтаграммной сети . пакет . Поскольку DTLS использует UDP или SCTP, а не TCP, он позволяет избежать «проблемы сбоя TCP» [9] [10] при использовании для создания VPN-туннеля.
Первоначальный выпуск DTLS версии 1.0 2006 года не был отдельным документом. Это было дано как серия дельт к TLS 1.1. [11] Аналогичным образом, последующий выпуск DTLS 2012 года является дельтой TLS 1.2. Ему был присвоен номер версии DTLS 1.2, соответствующий версии TLS. Наконец, DTLS 1.3 2022 года является версией TLS 1.3. Как и две предыдущие версии, DTLS 1.3 предназначен для предоставления «эквивалентных TLS 1.3 гарантий безопасности, за исключением защиты порядка/неповторяемости». [12]
Протокол безопасности транспортного уровня (TLS) вместе с несколькими другими базовыми платформами сетевой безопасности был разработан в рамках совместной инициативы, начатой в августе 1986 года Агентством национальной безопасности, Национальным бюро стандартов, Агентством оборонной связи и двенадцатью организациями связи и связи. компьютерные корпорации, инициировавшие специальный проект под названием Secure Data Network System (SDNS). [26] Программа была описана в сентябре 1987 года на 10-й Национальной конференции по компьютерной безопасности в обширном наборе опубликованных статей. Инновационная исследовательская программа была направлена на разработку следующего поколения защищенной компьютерной сети связи и спецификаций продуктов, которые будут реализованы для приложений в общедоступном и частном Интернете. Он был призван дополнить быстро возникающие новые интернет-стандарты OSI, продвигающиеся вперед как в профилях GOSIP правительства США, так и в огромных интернет-проектах ITU-ISO JTC1 на международном уровне. Первоначально известный как протокол SP4, он был переименован в TLS и впоследствии опубликован в 1995 году как международный стандарт ITU-T X.274|ISO/IEC 10736:1995.
Безопасное сетевое программирование
Ранние исследования в области безопасности транспортного уровня включали интерфейс прикладного программирования (API ) Secure Network Programming (SNP ), который в 1993 году исследовал подход к созданию безопасного API транспортного уровня, очень напоминающего сокеты Беркли , для облегчения модернизации уже существующих сетевых приложений с обеспечением безопасности. меры. [27] [28]
SSL 1.0, 2.0 и 3.0
Netscape разработала оригинальные протоколы SSL, а Тахер Эльгамал , главный научный сотрудник Netscape Communications с 1995 по 1998 год, был назван «отцом SSL». [29] [30] [31] [32] SSL версии 1.0 никогда не была публично выпущена из-за серьезных недостатков безопасности в протоколе. Версия 2.0, выпущенная в феврале 1995 года, быстро обнаружила ряд недостатков безопасности и удобства использования. Он использовал одни и те же криптографические ключи для аутентификации и шифрования сообщений. У него была слабая конструкция MAC, в которой использовалась хеш-функция MD5 с секретным префиксом, что делало его уязвимым для атак с расширением длины. Он также не обеспечивал защиты ни при открытии рукопожатия, ни при явном закрытии сообщения, что означало, что атаки «человек посередине» могли остаться незамеченными. Более того, SSL 2.0 предполагал единую службу и фиксированный сертификат домена, что противоречило широко используемой функции виртуального хостинга на веб-серверах, поэтому большинство веб-сайтов фактически были лишены возможности использовать SSL.
Эти недостатки потребовали полной переработки протокола до версии SSL 3.0. [33] [31] Выпущенный в 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 уязвим для атаки POODLE , которая затрагивает все блочные шифры в SSL; RC4 , единственный неблочный шифр, поддерживаемый SSL 3.0, также может быть взломан, как и в SSL 3.0. [34] SSL 3.0 объявлен устаревшим в июне 2015 года согласно RFC 7568.
ТЛС 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». [35]
Совет PCI предложил организациям перейти с TLS 1.0 на TLS 1.1 или выше до 30 июня 2018 года. [36] [37] В октябре 2018 года Apple , Google , Microsoft и Mozilla совместно объявили о прекращении поддержки TLS 1.0 и 1.1 в марте. 2020. [20] TLS 1.0 и 1.1 были официально признаны устаревшими в RFC 8996 в марте 2021 года.
ТЛС 1.1
TLS 1.1 был определен в RFC 4346 в апреле 2006 года. [38] Это обновление TLS версии 1.0. К существенным отличиям этой версии относятся:
Поддержка TLS версий 1.0 и 1.1 была широко признана устаревшей на веб-сайтах примерно в 2020 году, что отключило доступ к версиям Firefox до 24 и браузерам на базе Chromium до 29. [40] [41] [42]
ТЛС 1.2
TLS 1.2 был определен в RFC 5246 в августе 2008 года. [23] Он основан на более ранней спецификации TLS 1.1. Основные различия включают в себя:
Комбинация MD5 и SHA-1 в готовом хеше сообщения была заменена на SHA-256 с возможностью использования алгоритмов хеширования, специфичных для набора шифров. Однако размер хеша в готовом сообщении все равно должен быть не менее 96 бит . [23] : §7.4.9
Комбинация MD5 и SHA-1 в элементе с цифровой подписью была заменена одним хешем, согласованным во время рукопожатия , который по умолчанию равен SHA-1.
Расширение возможностей клиента и сервера указывать, какие хэши и алгоритмы подписи они принимают.
Были добавлены определения расширений TLS и наборы шифров AES. [39]
Все версии TLS были дополнительно усовершенствованы в RFC 6176 в марте 2011 года, в результате чего была удалена их обратная совместимость с SSL, так что сеансы TLS никогда не согласовывают использование Secure Sockets Layer (SSL) версии 2.0. В настоящее время официальной даты прекращения поддержки TLS 1.2 не существует.
ТЛС 1.3
TLS 1.3 был определен в RFC 8446 в августе 2018 года. [6] Он основан на более ранней спецификации TLS 1.2. Основные отличия от TLS 1.2 включают: [43]
Отделение алгоритмов согласования ключей и аутентификации от наборов шифров [39] [6] : §11
Требование цифровых подписей даже при использовании предыдущей конфигурации
Интеграция HKDF и полуэфемерного предложения DH
Замена возобновления на ПСК и билеты
Поддержка рукопожатий 1- RTT и начальная поддержка 0- RTT
Требование полной прямой секретности посредством использования эфемерных ключей во время соглашения о ключах (EC)DH.
Прекращение поддержки многих небезопасных или устаревших функций, включая сжатие , повторное согласование, шифры , отличные от AEAD , обмен ключами, не относящимися к PFS (среди которых статический обмен ключами RSA и статический DH ), пользовательские группы DHE , согласование формата точки EC, протокол изменения спецификации шифрования, Приветственное сообщение, время UNIX и поле длины, входные данные AD для шифров AEAD.
Запрет согласования SSL или RC4 для обеспечения обратной совместимости.
Интеграция использования хэша сеанса
Отказ от использования номера версии слоя записи и замораживание этого номера для улучшения обратной совместимости.
Перемещение некоторых деталей алгоритма, связанных с безопасностью, из приложения в спецификацию и перенос ClientKeyShare в приложение.
Добавление потокового шифра ChaCha20 с кодом аутентификации сообщения Poly1305 .
Добавление алгоритмов цифровой подписи Ed25519 и Ed448.
Добавление протоколов обмена ключами x25519 и x448.
Добавление поддержки отправки нескольких ответов OCSP
Шифрование всех сообщений подтверждения после ServerHello
Network Security Services (NSS), криптографическая библиотека, разработанная Mozilla и используемая ее веб-браузером Firefox , включила TLS 1.3 по умолчанию в феврале 2017 года. [44] Впоследствии была добавлена поддержка TLS 1.3, но из-за проблем совместимости для небольшого числа пользователи, не включенные автоматически [45] — для Firefox 52.0 , выпущенного в марте 2017 года. TLS 1.3 был включен по умолчанию в мае 2018 года с выпуском Firefox 60.0 . [46]
Google Chrome установил TLS 1.3 в качестве версии по умолчанию на короткое время в 2017 году. Затем он удалил его как версию по умолчанию из-за несовместимости промежуточных программ, таких как веб-прокси Blue Coat . [47]
Непереносимость новой версии TLS заключалась в закостенении протокола ; промежуточные коробки закостенели параметр версии протокола. В результате версия 1.3 имитирует образ провода версии 1.2. Это изменение произошло очень поздно в процессе проектирования и было обнаружено только во время развертывания браузера. [48] Обнаружение этой нетерпимости также привело к тому, что стратегия согласования предыдущей версии, в которой выбиралась наиболее соответствующая версия, была отвергнута из-за неработоспособного уровня окостенения. [49] « Смазка » точки расширения, когда один из участников протокола заявляет о поддержке несуществующих расширений, чтобы гарантировать, что нераспознанные, но фактически существующие расширения допускаются и, таким образом, противостоять оссификации, изначально была разработана для TLS, но с тех пор она была разработана был принят в другом месте. [50]
Во время хакатона IETF 100 , который проходил в Сингапуре в 2017 году, группа TLS работала над адаптацией приложений с открытым исходным кодом для использования TLS 1.3. [51] [52] Группа TLS состояла из людей из Японии, Великобритании и Маврикия через команду cyberstorm.mu. [52] Эта работа была продолжена на хакатоне IETF 101 в Лондоне , [53] и на хакатоне IETF 102 в Монреале. [54]
wolfSSL позволял использовать TLS 1.3 начиная с версии 3.11.1, выпущенной в мае 2017 года. [55] Будучи первой коммерческой реализацией TLS 1.3, wolfSSL 3.11.1 поддерживал проект 18, а теперь поддерживает проект 28, [56] окончательную версию, а также многие старые версии. Была опубликована серия блогов о разнице в производительности между TLS 1.2 и 1.3. [57]
Впопулярный проект OpenSSL выпустил версию 1.1.1 своей библиотеки, в которой поддержка TLS 1.3 была «главной новой функцией». [58]
Фонд Electronic Frontier Foundation похвалил TLS 1.3 и выразил обеспокоенность по поводу варианта протокола Enterprise Transport Security (ETS), который намеренно отключает важные меры безопасности в TLS 1.3. [60] ETS, первоначально называвшийся Enterprise TLS (eTLS), представляет собой опубликованный стандарт, известный как « ETSI TS103523-3», «Протокол безопасности промежуточного блока, часть 3: Транспортная безопасность предприятия». Он предназначен для использования исключительно в частных сетях, таких как банковские системы. ETS не поддерживает прямую секретность, чтобы позволить сторонним организациям, подключенным к частным сетям, использовать свой закрытый ключ для мониторинга сетевого трафика с целью обнаружения вредоносного ПО и упростить проведение аудита. [61] [62] Несмотря на заявленные преимущества, EFF предупредил, что потеря прямой секретности может облегчить раскрытие данных, а также заявил, что существуют более эффективные способы анализа трафика.
Цифровые сертификаты
Пример сайта с цифровым сертификатом
Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата и указывает на определенные ожидаемые варианты использования этого ключа. Это позволяет другим (проверяющим сторонам) полагаться на подписи или утверждения, сделанные с помощью закрытого ключа, который соответствует сертифицированному открытому ключу. Хранилища ключей и хранилища доверенных сертификатов могут иметь различные форматы, например .pem , .crt, .pfx и .jks .
Центры сертификации
TLS обычно полагается на набор доверенных сторонних центров сертификации для установления подлинности сертификатов. Доверие обычно закрепляется в списке сертификатов, распространяемых вместе с программным обеспечением пользовательского агента [63] , и может быть изменено проверяющей стороной.
По данным Netcraft , которая отслеживает активные сертификаты TLS, ведущим на рынке центром сертификации (CA) была Symantec с начала исследования (или VeriSign до того, как Symantec приобрела бизнес-подразделение служб аутентификации). По данным Netcraft, по состоянию на 2015 год на долю Symantec приходилось чуть менее трети всех сертификатов и 44% действительных сертификатов, используемых 1 миллионом самых загруженных веб-сайтов. [64] В 2017 году Symantec продала свой бизнес TLS/SSL компании DigiCert. [65] В обновленном отчете было показано, что IdenTrust , DigiCert и Sectigo входят в тройку крупнейших центров сертификации по доле рынка с мая 2019 года. [66]
Как следствие выбора сертификатов X.509 , центры сертификации и инфраструктура открытых ключей необходимы для проверки связи между сертификатом и его владельцем, а также для создания, подписания и управления действительностью сертификатов. Хотя это может быть более удобно, чем проверка личности через сеть доверия , раскрытие информации о массовой слежке в 2013 году сделало более широко известным, что центры сертификации являются слабым местом с точки зрения безопасности, допуская атаки «человек посередине» (MITM). если центр сертификации сотрудничает (или скомпрометирован). [67] [68]
Алгоритмы
Обмен ключами или соглашение о ключах
Прежде чем клиент и сервер смогут начать обмениваться информацией, защищенной TLS, они должны безопасно обменяться или согласовать ключ шифрования и шифр, которые будут использоваться при шифровании данных (см. § Шифр). Среди методов, используемых для обмена/согласования ключей, можно назвать: открытые и закрытые ключи, генерируемые с помощью RSA (обозначаемые TLS_RSA в протоколе установления связи TLS), Диффи-Хеллмана (TLS_DH), эфемерные Диффи-Хеллмана (TLS_DHE), эллиптические кривые Диффи-Хеллмана ( TLS_ECDH), эфемерная эллиптическая кривая Диффи-Хеллмана (TLS_ECDHE), анонимный Диффи-Хеллман (TLS_DH_anon), [23] предварительный общий ключ (TLS_PSK) [69] и безопасный удаленный пароль (TLS_SRP). [70]
Методы соглашения о ключах TLS_DH_anon и TLS_ECDH_anon не аутентифицируют сервер или пользователя и, следовательно, используются редко, поскольку они уязвимы для атак «человек посередине» . Только TLS_DHE и TLS_ECDHE обеспечивают прямую секретность.
Сертификаты открытых ключей, используемые во время обмена/согласования, также различаются по размеру открытых/частных ключей шифрования, используемых во время обмена, и, следовательно, по надежности обеспечиваемой безопасности. В июле 2013 года Google объявил, что больше не будет использовать 1024-битные открытые ключи и вместо этого перейдет на 2048-битные ключи, чтобы повысить безопасность шифрования TLS, которое он предоставляет своим пользователям, поскольку надежность шифрования напрямую связана с размером ключа . . [71] [72]
Шифр
Примечания
^ abcd RFC 5746 должен быть реализован, чтобы исправить ошибку повторного согласования, которая в противном случае привела бы к нарушению этого протокола.
^ Если библиотеки реализуют исправления, перечисленные в RFC 5746, это нарушает спецификацию SSL 3.0, которую IETF не может изменить в отличие от TLS. Большинство современных библиотек реализуют исправление и игнорируют вызванное этим нарушение.
^ ab Атака BEAST взламывает все блочные шифры (шифры CBC), используемые в SSL 3.0 и TLS 1.0, если только они не предотвращены клиентом и/или сервером. См. § Веб-браузеры.
^ Атака POODLE взламывает все блочные шифры (шифры CBC), используемые в SSL 3.0, если только они не смягчены клиентом и/или сервером. См. § Веб-браузеры.
^ abcdefg Шифры AEAD (такие как GCM и CCM ) можно использовать только в TLS 1.2 или более поздней версии.
^ abcdefgh Шифры CBC могут быть атакованы с помощью атаки Lucky Thirteen , если библиотека не написана тщательно для устранения побочных каналов синхронизации.
^ abcdef Атака Sweet32 взламывает блочные шифры с размером блока 64 бита. [82]
^ Хотя длина ключа 3DES составляет 168 бит, эффективная надежность безопасности 3DES составляет всего 112 бит, [83] что ниже рекомендуемого минимума в 128 бит. [84]
^ ab IDEA и DES были удалены из TLS 1.2. [85]
^ Наборы шифров с 40-битной стойкостью abc были намеренно разработаны с уменьшенной длиной ключа, чтобы соответствовать отмененным с тех пор правилам США, запрещающим экспорт криптографического программного обеспечения, содержащего определенные надежные алгоритмы шифрования (см. Экспорт криптографии из США ). Эти слабые пакеты запрещены в TLS 1.1 и более поздних версиях.
^ Использование RC4 во всех версиях TLS запрещено RFC 7465 (поскольку атаки RC4 ослабляют или нарушают RC4, используемый в SSL/TLS).
^ Только аутентификация, без шифрования.
Целостность данных
Код аутентификации сообщения (MAC) используется для обеспечения целостности данных. HMAC используется для режима блочных шифров CBC . Шифрование с проверкой подлинности (AEAD), такое как режим GCM и CCM, использует MAC-адрес, интегрированный в AEAD, и не использует HMAC . [6] : §8.4 PRF на основе HMAC или HKDF используется для установления связи TLS.
Приложения и принятие
При разработке приложений TLS обычно реализуется поверх протоколов транспортного уровня, шифруя все связанные с протоколами данные таких протоколов, как HTTP , FTP , SMTP , NNTP и XMPP .
Основное использование TLS — защита трафика Всемирной паутины между веб-сайтом и веб-браузером , закодированного по протоколу HTTP. Такое использование TLS для защиты HTTP-трафика представляет собой протокол HTTPS . [87]
Примечания
^ см. § Таблицу шифров выше.
^ см. § Веб-браузеры и § Атаки на разделы TLS/SSL.
Веб-браузеры
По состоянию на апрель 2016 года [update]последние версии всех основных веб-браузеров поддерживают TLS 1.0, 1.1 и 1.2 и включены по умолчанию. Однако не все поддерживаемые операционные системы Microsoft поддерживают последнюю версию IE. Кроме того, многие операционные системы Microsoft в настоящее время поддерживают несколько версий IE, но это изменилось в соответствии с часто задаваемыми вопросами о политике жизненного цикла поддержки Microsoft Internet Explorer: «Начиная с 12 января 2016 года, только самая последняя версия Internet Explorer, доступная для поддерживаемой операционной системы, будет получать техническая поддержка и обновления безопасности». Затем на странице отображается последняя поддерживаемая версия IE на тот момент для каждой операционной системы. Следующей критической датой станет момент, когда операционная система достигнет стадии конца жизненного цикла. С 15 июня 2022 года в Internet Explorer 11 прекращена поддержка выпусков Windows 10 , соответствующих Политике современного жизненного цикла Microsoft. [91] [92]
Мер по защите от известных атак пока недостаточно:
Меры защиты от атаки POODLE: некоторые браузеры уже предотвращают переход на SSL 3.0; однако это снижение должно поддерживаться не только клиентами, но и серверами. Требуется отключение самого SSL 3.0, реализация «разделения записей анти-POODLE» или отказ от шифров CBC в SSL 3.0.
Google Chrome: завершено (TLS_FALLBACK_SCSV реализован с версии 33, переход на SSL 3.0 отключен с версии 39, сам SSL 3.0 отключен по умолчанию с версии 40. Поддержка самого SSL 3.0 прекращена с версии 44.)
Mozilla Firefox: завершено (поддержка самого SSL 3.0 прекращена с версии 39. Сам SSL 3.0 отключен по умолчанию, а переход на SSL 3.0 отключен с версии 34 , TLS_FALLBACK_SCSV реализован с версии 35. В ESR сам SSL 3.0 отключен с помощью по умолчанию, а TLS_FALLBACK_SCSV реализован начиная с ESR 31.3.0.)
Internet Explorer: частично (только в версии 11, SSL 3.0 по умолчанию отключен с апреля 2015 года. Версия 10 и старше по-прежнему уязвимы для POODLE).
Opera : завершено (TLS_FALLBACK_SCSV реализован с версии 20, «разбиение записей анти-POODLE», которое эффективно только при реализации на стороне клиента, реализовано с версии 25, сам SSL 3.0 отключен по умолчанию, начиная с версии 27. Поддержка SSL 3.0 сам будет удален, начиная с версии 31.)
Safari: завершено (только в OS X 10.8 и более поздних версиях и iOS 8, шифрование CBC при переходе на SSL 3.0 запрещено, но это означает, что будет использоваться RC4, что также не рекомендуется. Поддержка самого SSL 3.0 прекращена в OS X 10.11 и более поздних версий и iOS 9.)
Защита от атак RC4:
Google Chrome отключил RC4, за исключением резервного варианта, начиная с версии 43. RC4 отключен, начиная с Chrome 48.
Firefox отключил RC4, кроме как в качестве запасного варианта, начиная с версии 36. Firefox 44 отключил RC4 по умолчанию.
Opera отключила RC4, за исключением запасных вариантов, начиная с версии 30. RC4 отключен, начиная с Opera 35.
Internet Explorer для Windows 7 /Server 2008 R2 и Windows 8 /Server 2012 установил самый низкий приоритет RC4 и также может отключить RC4, кроме как в качестве резервного варианта через настройки реестра. Internet Explorer 11 Mobile 11 для Windows Phone 8.1 отключит RC4, за исключением случаев, когда другой включенный алгоритм не работает. Edge и IE 11 полностью отключили RC4 в августе 2016 года.
Смягчение последствий атаки FREAK:
Браузер Android, входящий в состав Android 4.0 и более ранних версий, по-прежнему уязвим для атаки FREAK.
Internet Explorer 11 Mobile по-прежнему уязвим для атаки FREAK.
В Google Chrome, Internet Explorer (настольный компьютер), Safari (настольный компьютер и мобильный телефон) и Opera (мобильный телефон) предусмотрены ЧУДЕСНЫЕ средства защиты.
FREAK не затронул Mozilla Firefox на всех платформах и Google Chrome в Windows.
«Основная причина большинства этих уязвимостей — ужасный дизайн API для базовых библиотек SSL. Вместо того, чтобы выражать высокоуровневые свойства безопасности сетевых туннелей, такие как конфиденциальность и аутентификация, эти API раскрывают низкоуровневые детали протокола SSL. разработчикам приложений. Как следствие, разработчики часто неправильно используют SSL API, неправильно интерпретируя и неправильно понимая их многочисленные параметры, параметры, побочные эффекты и возвращаемые значения».
TLS также можно использовать для туннелирования всего сетевого стека для создания VPN , как в случае с OpenVPN и OpenConnect . Многие поставщики к настоящему времени объединили возможности шифрования и аутентификации TLS с авторизацией. С конца 1990-х годов также произошел значительный прогресс в создании клиентских технологий за пределами веб-браузеров, чтобы обеспечить поддержку клиент-серверных приложений. По сравнению с традиционными технологиями IPsec VPN, TLS имеет некоторые преимущества при обходе брандмауэра и NAT , которые упрощают администрирование для больших групп пользователей, имеющих удаленный доступ.
TLS также является стандартным методом защиты сигнализации приложений протокола инициации сеанса (SIP). TLS может использоваться для обеспечения аутентификации и шифрования сигнализации SIP, связанной с VoIP и другими приложениями на основе SIP. [95]
Безопасность
Атаки на TLS/SSL
Ниже перечислены серьезные атаки на TLS/SSL.
В феврале 2015 года IETF выпустил информационный RFC [96], в котором суммированы различные известные атаки на TLS/SSL.
Атака повторного согласования
В августе 2009 года была обнаружена уязвимость процедуры повторного согласования, которая может привести к атакам путем внедрения открытого текста против SSL 3.0 и всех текущих версий TLS. [97] Например, это позволяет злоумышленнику, который может перехватить https-соединение, вставить свои собственные запросы в начало диалога клиента с веб-сервером. Злоумышленник фактически не может расшифровать связь клиент-сервер, поэтому она отличается от типичной атаки «человек посередине». Краткосрочное решение заключается в том, что веб-серверы перестанут разрешать повторное согласование, которое обычно не требует других изменений, если не используется проверка подлинности сертификата клиента . Чтобы устранить уязвимость, для TLS было предложено расширение индикации повторного согласования. Клиенту и серверу потребуется включать и проверять информацию о предыдущих рукопожатиях при любых рукопожатиях повторного согласования. [98] Это расширение стало предлагаемым стандартом и получило номер RFC 5746. RFC был реализован несколькими библиотеками. [99] [100] [101]
Атаки на понижение версии:FREAK атака иАтака затора
Атака с понижением версии протокола (также называемая атакой с откатом версии) заставляет веб-сервер согласовывать соединения с предыдущими версиями TLS (такими как SSLv2), от которых уже давно отказались как от небезопасных.
Предыдущие модификации исходных протоколов, такие как False Start [102] (принятый и активированный Google Chrome [103] ) или Snap Start , как сообщается, вводили ограниченные атаки на понижение версии протокола TLS [104] или позволяли вносить изменения в список наборов шифров, отправленный клиентом. на сервер. При этом злоумышленнику может удастся повлиять на выбор набора шифров, пытаясь понизить набор шифров, согласованный для использования либо более слабого алгоритма симметричного шифрования, либо более слабого обмена ключами. [105] В документе, представленном на конференции ACM по компьютерной и коммуникационной безопасности в 2012 году, было продемонстрировано, что расширение False Start находится под угрозой: при определенных обстоятельствах оно может позволить злоумышленнику восстановить ключи шифрования в автономном режиме и получить доступ к зашифрованным данным. [106]
Атаки с понижением шифрования могут заставить серверы и клиенты согласовывать соединение с использованием криптографически слабых ключей. В 2014 году была обнаружена атака « человек посередине» под названием FREAK, затронувшая стек OpenSSL , веб-браузер Android по умолчанию и некоторые браузеры Safari . [107] Атака заключалась в том, чтобы заставить серверы согласовать TLS-соединение с использованием криптографически слабых 512-битных ключей шифрования.
Logjam — это уязвимость безопасности , обнаруженная в мае 2015 года, которая использует возможность использования устаревших 512-битных групп Диффи-Хеллмана «экспортного уровня» , созданных еще в 1990-х годах. [108] Это вынуждает уязвимые серверы перейти на криптографически слабые 512-битные группы Диффи-Хеллмана. Затем злоумышленник может вывести ключи, которые клиент и сервер определяют, используя обмен ключами Диффи-Хеллмана .
Межпротокольные атаки: DROWN
Атака DROWN — это эксплойт, который атакует серверы, поддерживающие современные наборы протоколов SSL/TLS, используя их поддержку устаревшего, небезопасного протокола SSLv2, чтобы использовать атаку на соединения с использованием современных протоколов, которые в противном случае были бы безопасными. [109] [110] DROWN использует уязвимость в используемых протоколах и конфигурации сервера, а не какую-либо конкретную ошибку реализации. Полная информация о DROWN была объявлена в марте 2016 года вместе с патчем для этого эксплойта. На тот момент более 81 000 из 1 миллиона самых популярных веб-сайтов входили в число защищенных TLS веб-сайтов, уязвимых для атаки DROWN. [110]
ЗВЕРЬ атака
23 сентября 2011 года исследователи Тай Дуонг и Джулиано Риццо продемонстрировали доказательство концепции под названием BEAST ( Browser Exploit Against SSL/TLS ) [111] с использованием Java-апплета для нарушения ограничений политики одного и того же происхождения для давно известной цепочки блоков шифра ( CBC) уязвимость в TLS 1.0: [112] [113] злоумышленник, наблюдающий за двумя последовательными блоками зашифрованного текста C0, C1, может проверить, равен ли блок открытого текста P1 x, выбрав следующий блок открытого текста P2 = x ⊕ C0 ⊕ C1 ; согласно операции CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , что будет равно C1, если x = P1 . Практические эксплойты для этой уязвимости ранее не были продемонстрированы , которая была первоначально обнаружена Филиппом Рогауэем [114] в 2002 году. Уязвимость атаки была исправлена с помощью TLS 1.1 в 2006 году, но TLS 1.1 не получил широкого распространения до этой атаки. демонстрация.
RC4 как поточный шифр невосприимчив к атаке BEAST. Поэтому RC4 широко использовался как способ смягчения атаки BEAST на стороне сервера. Однако в 2013 году исследователи обнаружили больше слабых мест в RC4. После этого включение RC4 на стороне сервера больше не рекомендовалось. [115]
Сами Chrome и Firefox не уязвимы для атаки BEAST, [116] [117] однако Mozilla обновила свои библиотеки NSS для смягчения атак , подобных BEAST . NSS используется Mozilla Firefox и Google Chrome для реализации SSL. В результате некоторые веб-серверы с некорректной реализацией спецификации SSL могут перестать работать. [118]
10 января 2012 года компания Microsoft выпустила бюллетень по безопасности MS12-006, в котором исправлена уязвимость BEAST путем изменения способа передачи компонентом Windows Secure Channel ( Schannel ) зашифрованных сетевых пакетов со стороны сервера. [119] Пользователи Internet Explorer (до версии 11), работающего в более старых версиях Windows ( Windows 7 , Windows 8 и Windows Server 2008 R2 ), могут ограничить использование TLS до версии 1.1 или выше.
Apple устранила уязвимость BEAST, внедрив разделение 1/n-1 и включив его по умолчанию в OS X Mavericks , выпущенной 22 октября 2013 года. [120]
ПРЕСТУПЛЕНИЕ И НАРУШЕНИЯ
Авторы атаки BEAST также являются создателями более поздней атаки CRIME , которая может позволить злоумышленнику восстановить содержимое веб-cookie при использовании сжатия данных вместе с TLS. [121] [122] При использовании для восстановления содержимого секретных файлов cookie аутентификации он позволяет злоумышленнику выполнить перехват сеанса в аутентифицированном веб-сеансе.
Хотя атака CRIME была представлена как общая атака, которая могла эффективно работать против большого количества протоколов, включая, помимо прочего, TLS и протоколы прикладного уровня, такие как SPDY или HTTP , были продемонстрированы и в значительной степени смягчены только эксплойты против TLS и SPDY. в браузерах и серверах. Эксплойт CRIME против сжатия HTTP вообще не был устранен, хотя авторы CRIME предупреждают, что эта уязвимость может быть даже более распространенной, чем сжатие SPDY и TLS вместе взятые. В 2013 году было объявлено о новом случае КРИМИНАЛЬНОЙ атаки на сжатие HTTP, получившей название BREACH . На основе атаки CRIME атака BREACH может извлечь токены входа, адреса электронной почты или другую конфиденциальную информацию из зашифрованного TLS веб-трафика всего за 30 секунд (в зависимости от количества байтов, которые необходимо извлечь), при условии, что злоумышленник обманом заставляет жертву посетить вредоносная веб-ссылка или возможность внедрения контента на действительные страницы, которые посещает пользователь (например, беспроводная сеть под контролем злоумышленника). [123] Все версии TLS и SSL подвержены риску НАРУШЕНИЯ, независимо от используемого алгоритма шифрования или шифра. [124] В отличие от предыдущих случаев ПРЕСТУПЛЕНИЯ, от которых можно успешно защититься, отключив сжатие TLS или сжатие заголовков SPDY, BREACH использует сжатие HTTP, которое невозможно отключить, поскольку практически все веб-серверы полагаются на него для повышения скорости передачи данных для пользователи. [123] Это известное ограничение TLS, поскольку он подвержен атакам с использованием выбранного открытого текста против данных прикладного уровня, которые он должен был защищать.
Некоторые эксперты [84] также рекомендовали избегать тройного DES CBC. Поскольку последними поддерживаемыми шифрами, разработанными для поддержки любой программы, использующей библиотеку SSL/TLS Windows XP , например Internet Explorer в Windows XP, являются RC4 и Triple-DES, а также поскольку RC4 теперь устарел (см. обсуждение атак RC4 ), это усложняет задачу. для поддержки любой версии SSL для любой программы, использующей эту библиотеку в XP.
Исправление было выпущено как расширение Encrypt-then-MAC к спецификации TLS, выпущенное как RFC 7366. [125] Атаку Lucky Thirteen можно смягчить в TLS 1.2, используя только шифры AES_GCM; AES_CBC остается уязвимым. SSL может защищать электронную почту, VoIP и другие виды связи в незащищенных сетях в дополнение к своему основному варианту использования — безопасной передаче данных между клиентом и сервером [2].
ПУДЕЛЬ атакует
14 октября 2014 года исследователи Google опубликовали уязвимость в конструкции SSL 3.0, которая делает режим работы CBC с SSL 3.0 уязвимым для атаки заполнения ( CVE — 2014-3566). Они назвали эту атаку POODLE ( Padding Oracle On Downgraded Legacy Encryption ). В среднем злоумышленникам достаточно выполнить всего 256 запросов SSL 3.0, чтобы раскрыть один байт зашифрованных сообщений. [90]
Хотя эта уязвимость существует только в SSL 3.0, а большинство клиентов и серверов поддерживают TLS 1.0 и выше, все основные браузеры добровольно переходят на SSL 3.0, если рукопожатия с более новыми версиями TLS завершаются неудачей, если только они не предоставляют пользователю или администратору возможность отключить SSL 3.0. и пользователь или администратор делает это . Таким образом, злоумышленник может сначала провести атаку с откатом версии , а затем воспользоваться этой уязвимостью. [90]
8 декабря 2014 г. было объявлено о варианте POODLE, который влияет на реализации TLS, которые не обеспечивают должным образом требования к байтам заполнения. [126]
RC4-атаки
Несмотря на существование атак на RC4 , нарушивших его безопасность, наборы шифров SSL и TLS, основанные на RC4, до 2013 года все еще считались безопасными в зависимости от того, как они использовались в SSL и TLS. В 2011 году пакет RC4 был рекомендован в качестве обходного пути для атаки BEAST . [127] Новые формы атак, раскрытые в марте 2013 года, убедительно продемонстрировали возможность взлома RC4 в TLS, что позволяет предположить, что это не лучший обходной путь для BEAST. [89] Сценарий атаки был предложен АльФарданом, Бернштейном, Патерсоном, Пёттерингом и Шульдтом, который использовал недавно обнаруженные статистические отклонения в таблице ключей RC4 [128] для восстановления частей открытого текста с помощью большого количества шифрований TLS. [129] [130] Атака на RC4 в TLS и SSL, которая требует шифрования 13 × 2 20 для взлома RC4, была обнародована 8 июля 2013 года и позже описана как «осуществимая» в сопроводительной презентации на симпозиуме по безопасности USENIX в августе 2013 года. [131] [132] В июле 2015 года последующие улучшения в атаке сделали все более практичным преодоление безопасности TLS, зашифрованного RC4. [133]
Поскольку многие современные браузеры разработаны для защиты от атак BEAST (кроме Safari для Mac OS X 10.7 или более ранней версии, для iOS 6 или более ранней версии и для Windows; см. § Веб-браузеры), RC4 больше не является хорошим выбором для TLS 1.0. Шифры CBC, на которые в прошлом повлияла атака BEAST, стали более популярным выбором для защиты. [84] Mozilla и Microsoft рекомендуют отключать RC4, где это возможно. [134] [135] RFC 7465 запрещает использование наборов шифров RC4 во всех версиях TLS.
1 сентября 2015 года Microsoft, Google и Mozilla объявили, что в начале 2016 года наборы шифров RC4 будут по умолчанию отключены в их браузерах ( Microsoft Edge , Internet Explorer 11 в Windows 7/8.1/10, Firefox и Chrome ). [136 ] [137] [138]
Атака усечения
Атака усечения TLS (выход из системы) блокирует запросы на выход из учетной записи жертвы, так что пользователь, сам того не зная, остается подключенным к веб-службе. Когда отправляется запрос на выход, злоумышленник вводит незашифрованное сообщение TCP FIN (больше нет данных от отправителя), чтобы закрыть соединение. Таким образом, сервер не получает запрос на выход из системы и не знает об аварийном завершении. [139]
Опубликованная в июле 2013 года [140] [141] атака приводит к тому, что веб-службы, такие как Gmail и Hotmail, отображают страницу, информирующую пользователя об успешном выходе из системы, гарантируя при этом, что браузер пользователя поддерживает авторизацию в службе, что позволяет злоумышленник с последующим доступом к браузеру для доступа и контроля над учетной записью пользователя, вошедшей в систему. Атака не предполагает установку вредоносного ПО на компьютер жертвы; злоумышленникам нужно всего лишь встать между жертвой и веб-сервером (например, установив мошенническую беспроводную точку доступа). [139] Эта уязвимость также требует доступа к компьютеру жертвы. Другая возможность заключается в том, что при использовании FTP соединение для передачи данных может иметь ложный FIN в потоке данных, и если правила протокола для обмена оповещениями close_notify не соблюдаются, файл может быть усечен.
Атака с открытым текстом на DTLS
В феврале 2013 года два исследователя из Ройял Холлоуэй, Лондонский университет, обнаружили временную атаку [142] , которая позволила им восстановить (части) открытый текст из соединения DTLS с использованием реализации DTLS OpenSSL или GnuTLS, когда использовалось шифрование в режиме цепочки блоков шифра. .
Нечестивая атака PAC
Эта атака, обнаруженная в середине 2016 года, использует слабые места в протоколе автообнаружения веб-прокси (WPAD) для раскрытия URL-адреса, к которому веб-пользователь пытается получить доступ через веб-ссылку с поддержкой TLS. [143] Раскрытие URL-адреса может нарушить конфиденциальность пользователя не только из-за посещаемого веб-сайта, но и потому, что URL-адреса иногда используются для аутентификации пользователей. Службы обмена документами, например, предлагаемые Google и Dropbox, также работают, отправляя пользователю токен безопасности, включенный в URL-адрес. Злоумышленник, получивший такие URL-адреса, может получить полный доступ к учетной записи или данным жертвы.
Эксплойт работает практически против всех браузеров и операционных систем.
Sweet32 атака
Атака Sweet32 взламывает все 64-битные блочные шифры, используемые в режиме CBC и используемые в TLS, используя атаку «День рождения» , а также атаку «человек посередине» или внедрение вредоносного кода JavaScript на веб-страницу. Цель атаки «человек посередине» или внедрения JavaScript — позволить злоумышленнику перехватить достаточно трафика для организации атаки на день рождения. [144]
Ошибка Heartbleed — это серьезная уязвимость, связанная с реализацией SSL/TLS в популярной библиотеке криптографического программного обеспечения OpenSSL , затрагивающая версии с 1.0.1 по 1.0.1f. Эта уязвимость, о которой сообщалось в апреле 2014 года, позволяет злоумышленникам красть закрытые ключи с серверов, которые обычно должны быть защищены. [145] Ошибка Heartbleed позволяет любому пользователю Интернета читать память систем, защищенных уязвимыми версиями программного обеспечения OpenSSL. Это ставит под угрозу секретные частные ключи, связанные с общедоступными сертификатами , используемыми для идентификации поставщиков услуг и шифрования трафика, имен и паролей пользователей, а также фактического контента. Это позволяет злоумышленникам подслушивать коммуникации, красть данные непосредственно у служб и пользователей, а также выдавать себя за службы и пользователей. [146] Уязвимость вызвана ошибкой переполнения буфера в программном обеспечении OpenSSL, а не дефектом в спецификации протокола SSL или TLS.
В сентябре 2014 года компания Intel Security Advanced Threat Research объявила о варианте уязвимости PKCS#1 v1.5 RSA Signature Forgery Дэниела Бляйхенбахера [147] . Эта атака, получившая название BERserk, является результатом неполного декодирования подписей с открытым ключом по длине ASN.1 в некоторых реализациях SSL и позволяет провести атаку «человек посередине» путем подделки подписи с открытым ключом. [148]
В феврале 2015 года, после того как СМИ сообщили о скрытой предварительной установке рекламного ПО Superfish на некоторые ноутбуки Lenovo, [149] исследователь обнаружил, что доверенный корневой сертификат на затронутых компьютерах Lenovo небезопасен, поскольку к ключам можно было легко получить доступ по названию компании. Комодия, как парольная фраза. [150] Библиотека Komodia была разработана для перехвата трафика TLS/SSL на стороне клиента в целях родительского контроля и наблюдения, но она также использовалась в многочисленных рекламных программах, включая Superfish, которые часто устанавливались тайно, без ведома пользователя компьютера. В свою очередь, эти потенциально нежелательные программы установили поврежденный корневой сертификат, что позволило злоумышленникам полностью контролировать веб-трафик и подтверждать подлинность ложных веб-сайтов.
В мае 2016 года сообщалось, что десятки датских веб-сайтов, защищенных HTTPS, принадлежащих Visa Inc., были уязвимы для атак, позволяющих хакерам внедрять вредоносный код и подделывать контент в браузеры посетителей. [151] Атаки сработали, поскольку реализация TLS, используемая на затронутых серверах, неправильно повторно использовала случайные числа ( nonce ), которые предназначены для использования только один раз, гарантируя, что каждое рукопожатие TLS является уникальным. [151]
В феврале 2017 года ошибка реализации, вызванная одним опечаткой в коде, используемом для анализа HTML, привела к ошибке переполнения буфера на серверах Cloudflare . Эта ошибка переполнения, широко известная как Cloudbleed , по своим последствиям аналогична ошибке Heartbleed, обнаруженной в 2014 году. Она позволяла неавторизованным третьим лицам читать данные в памяти программ, работающих на серверах, — данные, которые в противном случае должны были быть защищены с помощью TLS. [152]
Исследование веб-сайтов, уязвимых для атак
По состоянию на июль 2021 года [update]Движение за надежность Интернета оценило долю веб-сайтов, уязвимых для атак TLS. [88]
Прямая секретность
Прямая секретность — это свойство криптографических систем, которое гарантирует, что сеансовый ключ, полученный из набора открытого и закрытого ключей, не будет скомпрометирован, если один из закрытых ключей будет скомпрометирован в будущем. [153] Без прямой секретности, если закрытый ключ сервера скомпрометирован, будут скомпрометированы не только все будущие сеансы с шифрованием TLS, использующие этот сертификат сервера, но также и все предыдущие сеансы, которые его использовали (при условии, что эти прошлые сеансы были перехвачены и сохраняется на момент передачи). [154] Реализация TLS может обеспечить прямую секретность, требуя использования эфемерного обмена ключами Диффи-Хеллмана для установления сеансовых ключей, а некоторые известные реализации TLS делают это исключительно: например, Gmail и другие службы Google HTTPS, которые используют OpenSSL . [155] Однако многие клиенты и серверы, поддерживающие TLS (включая браузеры и веб-серверы), не настроены для реализации таких ограничений. [156] [157] На практике, если веб-служба не использует обмен ключами Диффи-Хеллмана для реализации прямой секретности, весь зашифрованный веб-трафик, входящий и исходящий от этой службы, может быть расшифрован третьей стороной, если она получит главный (частный) сервер сервера. ) ключ; например, по решению суда. [158]
Даже там, где реализован обмен ключами Диффи-Хеллмана, механизмы управления сеансами на стороне сервера могут повлиять на прямую секретность. Использование билетов сеанса TLS (расширение TLS) приводит к тому, что сеанс защищается с помощью AES128-CBC-SHA256 независимо от любых других согласованных параметров TLS, включая наборы шифров прямой секретности, а долгоживущие ключи билета сеанса TLS препятствуют попытке реализовать передовая секретность. [159] [160] [161] Исследование Стэнфордского университета в 2014 году также показало, что из 473 802 опрошенных TLS-серверов 82,9% серверов, развертывающих эфемерный обмен ключами Диффи-Хеллмана (DHE) для поддержки прямой секретности, использовали слабые параметры Диффи-Хеллмана. Этот слабый выбор параметров потенциально может поставить под угрозу эффективность прямой секретности, которую стремились обеспечить серверы. [162]
С конца 2011 года Google по умолчанию обеспечивает прямую секретность с помощью TLS для пользователей своей службы Gmail , а также Документов Google и зашифрованного поиска, а также других служб. [163]
С ноября 2013 года Twitter обеспечивает прямую секретность с помощью TLS для пользователей своего сервиса. [164] По состоянию на август 2019 года [update]около 80% веб-сайтов с поддержкой TLS настроены на использование наборов шифров, обеспечивающих прямую секретность для большинства веб-браузеров. [88]
TLS-перехват
Перехват TLS (или перехват HTTPS , если он применяется конкретно к этому протоколу) — это практика перехвата зашифрованного потока данных с целью его расшифровки, чтения и, возможно, манипулирования им, а затем повторного шифрования и повторной отправки данных. Это делается с помощью « прозрачного прокси »: программа перехвата завершает входящее соединение TLS, проверяет открытый текст HTTP, а затем создает новое соединение TLS с пунктом назначения. [165]
Перехват TLS/HTTPS используется сетевыми операторами в качестве меры информационной безопасности , чтобы иметь возможность сканировать и защищать от проникновения в сеть вредоносного контента, такого как компьютерные вирусы и другие вредоносные программы . [165] В противном случае такой контент не мог бы быть обнаружен, пока он защищен шифрованием, что все чаще происходит в результате повседневного использования HTTPS и других безопасных протоколов.
Существенным недостатком перехвата TLS/HTTPS является то, что он сам по себе создает новые риски безопасности. Одним из заметных ограничений является то, что он обеспечивает точку, где сетевой трафик доступен в незашифрованном виде, что дает злоумышленникам стимул атаковать именно эту точку, чтобы получить доступ к защищенному в противном случае контенту. Перехват также позволяет сетевому оператору или лицам, получившим доступ к его системе перехвата, осуществлять атаки «человек посередине» против пользователей сети. Исследование 2017 года показало, что «перехват HTTPS стал поразительно распространенным, и что продукты перехвата как класс оказывают крайне негативное влияние на безопасность соединения». [165]
Детали протокола
Протокол TLS обменивается записями , которые инкапсулируют данные, подлежащие обмену, в определенном формате (см. ниже). Каждая запись может быть сжата, дополнена, дополнена кодом аутентификации сообщения (MAC) или зашифрована — все в зависимости от состояния соединения. Каждая запись имеет поле типа контента , которое определяет тип инкапсулированных данных, поле длины и поле версии TLS. Инкапсулированные данные могут быть управляющими или процедурными сообщениями самого TLS или просто данными приложения, которые необходимо передать по TLS. Спецификации (набор шифров, ключи и т. д.), необходимые для обмена данными приложения по TLS, согласовываются в «квитировании TLS» между клиентом, запрашивающим данные, и сервером, отвечающим на запросы. Таким образом, протокол определяет как структуру полезных данных, передаваемых в TLS, так и процедуру установления и мониторинга передачи.
TLS-рукопожатие
Упрощенная иллюстрация полного рукопожатия TLS 1.2 с информацией о времени.
Когда соединение начинается, запись инкапсулирует «управляющий» протокол – протокол обмена сообщениями квитирования ( тип контента 22). Этот протокол используется для обмена всей информацией, необходимой обеим сторонам для обмена фактическими данными приложения по TLS. Он определяет формат сообщений и порядок их обмена. Они могут различаться в зависимости от требований клиента и сервера – т. е. существует несколько возможных процедур установки соединения. Этот первоначальный обмен приводит к успешному соединению TLS (обе стороны готовы передать данные приложения с помощью TLS) или предупреждающему сообщению (как указано ниже).
Базовое подтверждение TLS
Ниже приведен типичный пример подключения, иллюстрирующий рукопожатие , при котором сервер (но не клиент) аутентифицируется по своему сертификату:
Этап переговоров:
Клиент отправляет сообщение ClientHello , указывая самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и предлагаемые методы сжатия. Если клиент пытается выполнить возобновленное рукопожатие, он может отправить идентификатор сеанса . Если клиент может использовать согласование протокола уровня приложения , он может включать список поддерживаемых протоколов приложений , таких как HTTP/2 .
Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Чтобы подтвердить или разрешить возобновление рукопожатий, сервер может отправить идентификатор сеанса . Выбранная версия протокола должна быть самой высокой, поддерживаемой как клиентом, так и сервером. Например, если клиент поддерживает TLS версии 1.1, а сервер поддерживает версию 1.2, следует выбрать версию 1.1; версию 1.2 выбирать не следует.
Сервер отправляет свое сообщение сертификата (в зависимости от выбранного набора шифров оно может быть пропущено сервером). [166]
Сервер отправляет сообщение ServerKeyExchange (в зависимости от выбранного набора шифров оно может быть пропущено сервером). Это сообщение отправляется для всех наборов шифров DHE , ECDHE и DH_anon. [23]
Сервер отправляет сообщение ServerHelloDone , указывая, что согласование рукопожатия завершено.
Клиент отвечает сообщением ClientKeyExchange , которое может содержать PreMasterSecret , открытый ключ или ничего не содержать. (Опять же, это зависит от выбранного шифра.) Этот PreMasterSecret шифруется с использованием открытого ключа сертификата сервера.
Затем клиент и сервер используют случайные числа и PreMasterSecret для вычисления общего секрета, называемого «главным секретом». Все остальные ключевые данные ( сеансовые ключи , такие как IV , ключ симметричного шифрования , ключ MAC [167] ) для этого соединения извлекаются из этого главного секрета (и случайных значений, сгенерированных клиентом и сервером), который передается через тщательно разработанный алгоритм. псевдослучайная функция.
Клиент теперь отправляет запись ChangeCipherSpec , по сути сообщая серверу: «Все, что я вам скажу с этого момента, будет аутентифицировано (и зашифровано, если параметры шифрования присутствовали в сертификате сервера)». ChangeCipherSpec сам по себе является протоколом уровня записи с типом контента 20.
Клиент отправляет проверенное и зашифрованное сообщение «Готово» , содержащее хэш и MAC-адрес, поверх предыдущих сообщений подтверждения.
Сервер попытается расшифровать сообщение клиента Finished и проверить хэш и MAC. Если расшифровка или проверка не удались, считается, что рукопожатие не удалось, и соединение должно быть разорвано.
Наконец, сервер отправляет ChangeCipherSpec , сообщая клиенту: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если шифрование было согласовано)».
Сервер отправляет проверенное и зашифрованное сообщение «Готово» .
Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем шаге.
Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом контента 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут аутентифицированы и, при необходимости, зашифрованы точно так же, как в их готовом сообщении. В противном случае тип контента вернет 25, и клиент не пройдет проверку подлинности.
Рукопожатие TLS с проверкой подлинности клиента
В следующем полном примере показана проверка подлинности клиента (в дополнение к серверу, как в примере выше; см. взаимную аутентификацию ) через TLS с использованием сертификатов, которыми обмениваются оба узла.
Фаза переговоров:
Клиент отправляет сообщение ClientHello , указывая самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и методов сжатия.
Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Сервер также может отправить идентификатор сеанса как часть сообщения для возобновления рукопожатия.
Сервер отправляет свое сообщение сертификата (в зависимости от выбранного набора шифров оно может быть пропущено сервером). [166]
Сервер отправляет сообщение ServerKeyExchange (в зависимости от выбранного набора шифров оно может быть пропущено сервером). Это сообщение отправляется для всех наборов шифров DHE, ECDHE и DH_anon. [1]
Сервер отправляет сообщение CertificateRequest , чтобы запросить сертификат у клиента.
Сервер отправляет сообщение ServerHelloDone , указывая, что согласование рукопожатия завершено.
Клиент отвечает сообщением о сертификате , которое содержит сертификат клиента, но не его закрытый ключ.
Клиент отправляет сообщение ClientKeyExchange , которое может содержать PreMasterSecret , открытый ключ или ничего не содержать. (Опять же, это зависит от выбранного шифра.) Этот PreMasterSecret шифруется с использованием открытого ключа сертификата сервера.
Клиент отправляет сообщение CertificateVerify , которое является подписью поверх предыдущих сообщений подтверждения с использованием закрытого ключа сертификата клиента. Эту подпись можно проверить с помощью открытого ключа сертификата клиента. Это позволяет серверу узнать, что клиент имеет доступ к закрытому ключу сертификата и, следовательно, является владельцем сертификата.
Затем клиент и сервер используют случайные числа и PreMasterSecret для вычисления общего секрета, называемого «главным секретом». Все остальные ключевые данные («ключи сеанса») для этого соединения извлекаются из этого главного секрета (а также случайных значений, сгенерированных клиентом и сервером), которые передаются через тщательно разработанную псевдослучайную функцию.
Клиент теперь отправляет запись ChangeCipherSpec , по сути сообщая серверу: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если было согласовано шифрование). ChangeCipherSpec сам по себе является протоколом уровня записи и имеет тип 20, а не 22. .
Наконец, клиент отправляет зашифрованное сообщение о завершении , содержащее хэш и MAC-адрес, поверх предыдущих сообщений подтверждения.
Сервер попытается расшифровать сообщение клиента Finished и проверить хэш и MAC. Если расшифровка или проверка завершаются неудачей, считается, что рукопожатие не удалось, и соединение следует разорвать.
Наконец, сервер отправляет ChangeCipherSpec , сообщая клиенту: «Все, что я скажу вам с этого момента, будет аутентифицировано (и зашифровано, если было согласовано шифрование)».
Сервер отправляет собственное зашифрованное сообщение о завершении .
Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем шаге.
Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом контента 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут зашифрованы точно так же, как в их готовом сообщении.
Возобновлено рукопожатие TLS
Операции с открытым ключом (например, RSA) относительно дороги с точки зрения вычислительной мощности. TLS предоставляет безопасный ярлык в механизме установления связи, позволяющий избежать этих операций: возобновление сеансов. Возобновленные сеансы реализуются с использованием идентификаторов сеансов или билетов сеанса.
Помимо повышения производительности, возобновленные сеансы также можно использовать для единого входа , поскольку он гарантирует, что как исходный сеанс, так и любой возобновленный сеанс происходят от одного и того же клиента. Это имеет особое значение для протокола FTP через TLS/SSL , который в противном случае пострадал бы от атаки «человек посередине», при которой злоумышленник мог бы перехватить содержимое вторичных подключений к данным. [168]
Рукопожатие TLS 1.3
Подтверждение TLS 1.3 было сокращено до одного двустороннего обмена по сравнению с двумя двусторонними проходами, которые требовались в предыдущих версиях TLS/SSL.
Чтобы начать рукопожатие, клиент угадывает, какой алгоритм обмена ключами будет выбран сервером, и отправляет на сервер сообщение ClientHello , содержащее список поддерживаемых шифров (в порядке предпочтений клиента) и открытые ключи для некоторых или всех его ключей. обменяйтесь предположениями. Если клиент успешно угадывает алгоритм обмена ключами, из рукопожатия исключается 1 обращение туда и обратно. После получения ClientHello сервер выбирает шифр и отправляет обратно ServerHello со своим собственным открытым ключом, за которым следуют сообщения «Сертификат сервера» и «Готово» . [169]
После того, как клиент получает готовое сообщение от сервера, оно согласовывается с сервером, какой набор шифров использовать. [170]
Идентификаторы сеансов
При обычном полном рукопожатии сервер отправляет идентификатор сеанса как часть сообщения ServerHello . Клиент связывает этот идентификатор сеанса с IP-адресом и TCP-портом сервера, чтобы при повторном подключении клиента к этому серверу он мог использовать идентификатор сеанса для сокращения рукопожатия. На сервере идентификатор сеанса сопоставляется с ранее согласованными криптографическими параметрами, в частности с «главным секретом». Обе стороны должны иметь один и тот же «главный секрет», иначе возобновленное рукопожатие не удастся (это не позволит перехватчику использовать идентификатор сеанса ). Случайные данные в сообщениях ClientHello и ServerHello практически гарантируют, что сгенерированные ключи подключения будут отличаться от ключей предыдущего подключения. В RFC этот тип рукопожатия называется сокращенным рукопожатием. В литературе это также описано как рукопожатие перезапуска .
Этап переговоров:
Клиент отправляет сообщение ClientHello , указывая самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и методов сжатия. В сообщение включен идентификатор сеанса предыдущего TLS-соединения.
Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Если сервер распознает идентификатор сеанса, отправленный клиентом, он отвечает тем же идентификатором сеанса . Клиент использует это, чтобы распознать возобновление рукопожатия. Если сервер не распознает идентификатор сеанса, отправленный клиентом, он отправляет другое значение для своего идентификатора сеанса . Это сообщает клиенту, что возобновленное рукопожатие не будет выполнено. На этом этапе и клиент, и сервер имеют «главный секрет» и случайные данные для генерации ключевых данных, которые будут использоваться для этого соединения.
Теперь сервер отправляет запись ChangeCipherSpec , по сути сообщая клиенту: «Все, что я скажу вам с этого момента, будет зашифровано». ChangeCipherSpec сам по себе является протоколом уровня записи и имеет тип 20, а не 22.
Наконец, сервер отправляет зашифрованное сообщение о завершении , содержащее хэш и MAC-адрес, поверх предыдущих сообщений подтверждения.
Клиент попытается расшифровать сообщение сервера Finished и проверить хэш и MAC. Если расшифровка или проверка завершаются неудачей, считается, что рукопожатие не удалось, и соединение следует разорвать.
Наконец, клиент отправляет ChangeCipherSpec , сообщая серверу: «Все, что я скажу вам с этого момента, будет зашифровано».
Клиент отправляет собственное зашифрованное сообщение о завершении .
Сервер выполняет ту же процедуру расшифровки и проверки, что и клиент на предыдущем шаге.
Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом контента 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут зашифрованы точно так же, как в их готовом сообщении.
Билеты на сеансы
RFC 5077 расширяет TLS за счет использования билетов сеанса вместо идентификаторов сеанса. Он определяет способ возобновления сеанса TLS без необходимости сохранения состояния конкретного сеанса на сервере TLS.
При использовании билетов сеанса сервер TLS сохраняет свое состояние, зависящее от сеанса, в билете сеанса и отправляет билет сеанса клиенту TLS для хранения. Клиент возобновляет сеанс TLS, отправляя билет сеанса на сервер, а сервер возобновляет сеанс TLS в соответствии с состоянием сеанса в билете. Билет сеанса шифруется и аутентифицируется сервером, а сервер проверяет его достоверность перед использованием его содержимого.
Одним из особых недостатков этого метода с OpenSSL является то, что он всегда ограничивает безопасность шифрования и аутентификации передаваемого билета сеанса TLS значением AES128-CBC-SHA256, независимо от того, какие другие параметры TLS были согласованы для фактического сеанса TLS. [160] Это означает, что информация о состоянии (билет сеанса TLS) не так хорошо защищена, как сам сеанс TLS. Особую озабоченность вызывает хранение OpenSSL ключей в контексте всего приложения ( SSL_CTX), то есть на протяжении всего срока службы приложения, и невозможность повторного ввода AES128-CBC-SHA256ключей сеанса TLS без сброса контекста OpenSSL всего приложения (что встречается редко). , подвержен ошибкам и часто требует ручного административного вмешательства). [161] [159]
TLS-запись
Это общий формат всех записей TLS.
Тип содержимого
Это поле идентифицирует тип протокола уровня записи, содержащийся в этой записи.
Устаревшая версия
В этом поле указывается основная и дополнительная версия TLS до TLS 1.3 для содержащегося сообщения. Для сообщения ClientHello это не обязательно должна быть самая высокая версия, поддерживаемая клиентом. Для TLS 1.3 и более поздних версий необходимо установить значение 0x0303, а приложение должно отправлять поддерживаемые версии в дополнительном блоке расширения сообщения.
Длина
Длина объединенных полей «протокольное сообщение(я)», «MAC» и «дополнение» (т. е. q -5) не должна превышать 2–14 байтов (16 КиБ).
Протокольное сообщение(я)
Одно или несколько сообщений, идентифицируемых полем Протокол. Обратите внимание, что это поле может быть зашифровано в зависимости от состояния соединения.
MAC и дополнение
Код аутентификации сообщения , вычисляемый по полю «сообщения протокола», с включенным дополнительным ключевым материалом. Обратите внимание, что это поле может быть зашифровано или не включено полностью, в зависимости от состояния соединения.
Никакие поля «MAC» или «дополнения» не могут присутствовать в конце записей TLS до того, как все алгоритмы и параметры шифрования будут согласованы и подтверждены, а затем подтверждены отправкой записи CipherStateChange (см. ниже) для сигнализации о том, что эти параметры вступят в силу во всех дальнейшие записи, отправленные тем же узлом.
Протокол рукопожатия
Большинство сообщений, которыми обмениваются во время установки сеанса TLS, основаны на этой записи, за исключением случаев, когда возникает ошибка или предупреждение, о которых необходимо сигнализировать записью протокола оповещений (см. ниже), или режим шифрования сеанса не изменяется другой записью ( см. протокол ChangeCipherSpec ниже).
Тип сообщения
В этом поле указывается тип сообщения подтверждения.
Длина данных сообщения рукопожатия
Это 3-байтовое поле, указывающее длину данных подтверждения, не включая заголовок.
Обратите внимание, что несколько сообщений подтверждения связи могут быть объединены в одну запись.
Протокол оповещений
Эту запись обычно не следует отправлять во время обычного установления связи или обмена приложениями. Однако это сообщение может быть отправлено в любой момент во время рукопожатия и вплоть до закрытия сеанса. Если это используется для обозначения фатальной ошибки, сеанс будет закрыт сразу после отправки этой записи, поэтому эта запись используется для указания причины закрытия. Если уровень оповещения помечен как предупреждение, удаленное устройство может решить закрыть сеанс, если решит, что сеанс недостаточно надежен для его нужд (перед этим удаленное устройство также может отправить свой собственный сигнал).
Уровень
В этом поле указывается уровень оповещения. Если уровень фатальный, отправителю следует немедленно закрыть сеанс. В противном случае получатель может принять решение о прекращении сеанса самостоятельно, отправив собственное фатальное предупреждение и закрыв сам сеанс сразу после его отправки. Использование записей Alert не является обязательным, однако, если они отсутствуют до закрытия сеанса, сеанс может быть возобновлен автоматически (с его рукопожатиями).
Обычное закрытие сеанса после завершения транспортируемого приложения должно быть предупреждено по крайней мере с помощью типа уведомления о закрытии (с простым уровнем предупреждения), чтобы предотвратить такое автоматическое возобновление нового сеанса. Явная сигнализация о нормальном закрытии защищенного сеанса перед фактическим закрытием его транспортного уровня полезна для предотвращения или обнаружения атак (например, попыток усечения безопасно транспортируемых данных, если они по своей сути не имеют заранее определенной длины или длительности, которую получатель защищенных данных может можно ожидать).
Описание
В этом поле указывается тип отправляемого оповещения.
Протокол ChangeCipherSpec
Тип протокола CCS
На данный момент только 1.
Протокол приложения
Длина
Длина данных приложения (исключая заголовок протокола, включая MAC-адрес и завершающие фрагменты)
MAC
32 байта для HMAC на основе SHA-256 , 20 байтов для HMAC на основе SHA-1 , 16 байтов для HMAC на основе MD5 .
Заполнение
Переменная длина; последний байт содержит длину заполнения.
Поддержка виртуальных серверов на основе имен.
С точки зрения протокола приложения TLS принадлежит к более низкому уровню, хотя модель TCP/IP слишком груба, чтобы это показать. Это означает, что подтверждение TLS обычно (за исключением случая STARTTLS ) выполняется до запуска протокола приложения. В функции виртуального сервера на основе имени, предоставляемой уровнем приложения, все совместно размещенные виртуальные серверы используют один и тот же сертификат, поскольку сервер должен выбрать и отправить сертификат сразу после сообщения ClientHello. Это большая проблема в средах хостинга, поскольку это означает либо совместное использование одного и того же сертификата всеми клиентами, либо использование разных IP-адресов для каждого из них.
Если все виртуальные серверы принадлежат одному домену, можно использовать групповой сертификат . [171] Помимо произвольного выбора имени хоста, который может быть проблемой или нет, не существует общего соглашения о том, как сопоставлять групповые сертификаты. В зависимости от протокола приложения или используемого программного обеспечения применяются разные правила. [172]
Добавьте каждое имя виртуального хоста в расширение subjectAltName. Основная проблема заключается в том, что сертификат необходимо перевыпускать каждый раз при добавлении нового виртуального сервера.
Чтобы предоставить имя сервера, расширения RFC 4366 Transport Layer Security (TLS) позволяют клиентам включать расширение указания имени сервера (SNI) в расширенное сообщение ClientHello. Это расширение немедленно указывает серверу, к какому имени клиент желает подключиться, поэтому сервер может выбрать соответствующий сертификат для отправки клиентам.
В RFC 2817 также описан метод реализации виртуального хостинга на основе имени путем обновления HTTP до TLS через заголовок обновления HTTP/1.1 . Обычно это делается для безопасной реализации HTTP через TLS в основной схеме URI «http» (что позволяет избежать разветвления пространства URI и уменьшает количество используемых портов), однако в настоящее время это поддерживают лишь немногие реализации. [ нужна цитата ]
Стандарты
Первичные стандарты
Текущей утвержденной версией (D)TLS является версия 1.3, которая указана в:
RFC 8446: «Протокол безопасности транспортного уровня (TLS) версии 1.3».
RFC 9147: «Протокол безопасности транспортного уровня (DTLS) датаграмм, версия 1.3»
Текущие стандарты заменяют эти прежние версии, которые сейчас считаются устаревшими:
RFC 5246: «Протокол безопасности транспортного уровня (TLS) версии 1.2».
RFC 6347: «Безопасность транспортного уровня дейтаграмм, версия 1.2».
RFC 4346: «Протокол безопасности транспортного уровня (TLS) версии 1.1».
RFC 4347 "Безопасность транспортного уровня дейтаграмм"
RFC 2246: «Протокол TLS версии 1.0».
RFC 6101: «Протокол Secure Sockets Layer (SSL) версии 3.0».
Интернет-проект (1995 г.): «Протокол SSL».
Расширения
Другие RFC впоследствии расширили (D)TLS.
Расширения (D)TLS 1.3 включают:
RFC 9367: «Наборы шифров ГОСТ для протокола безопасности транспортного уровня (TLS) версии 1.3».
RFC 2595: «Использование TLS с IMAP, POP3 и ACAP». Определяет расширение служб IMAP, POP3 и ACAP, которое позволяет серверу и клиенту использовать безопасность транспортного уровня для обеспечения частной связи с проверкой подлинности через Интернет.
RFC 2712: «Добавление наборов шифров Kerberos к безопасности транспортного уровня (TLS)». 40-битные наборы шифров, определенные в этом документе, используются только с целью документирования того факта, что эти коды набора шифров уже назначены.
RFC 2817: «Обновление до TLS в HTTP/1.1» объясняет, как использовать механизм обновления в HTTP/1.1 для инициирования безопасности транспортного уровня (TLS) через существующее TCP-соединение. Это позволяет незащищенному и защищенному HTTP-трафику использовать один и тот же хорошо известный порт (в данном случае http: по адресу 80, а не https: по номеру 443).
RFC 2818: «HTTP Over TLS» отличает защищенный трафик от незащищенного трафика за счет использования другого «порта сервера».
RFC 3207: «Расширение службы SMTP для защиты SMTP через безопасность транспортного уровня». Указывает расширение службы SMTP, которое позволяет SMTP-серверу и клиенту использовать безопасность транспортного уровня для обеспечения частной связи с проверкой подлинности через Интернет.
RFC 3268: «Наборы шифров AES для TLS». Добавляет наборы шифров Advanced Encryption Standard (AES) к ранее существовавшим симметричным шифрам.
RFC 3546: «Расширения безопасности транспортного уровня (TLS)» добавляет механизм согласования расширений протокола во время инициализации сеанса и определяет некоторые расширения. Устарело по RFC 4366.
RFC 3749: «Методы сжатия протокола безопасности транспортного уровня» определяет структуру для методов сжатия и метода сжатия DEFLATE .
RFC 3943: «Сжатие протокола безопасности транспортного уровня (TLS) с использованием Lempel-Ziv-Stac (LZS)».
RFC 4132: «Добавление наборов шифров Camellia к безопасности транспортного уровня (TLS)».
RFC 4162: «Добавление наборов шифров SEED к безопасности транспортного уровня (TLS)».
RFC 4279: «Наборы шифров с предварительным общим ключом для безопасности транспортного уровня (TLS)» добавляет три набора новых наборов шифров для протокола TLS для поддержки аутентификации на основе предварительно общих ключей.
Информационные RFC
RFC 7457: «Обзор известных атак на безопасность транспортного уровня (TLS) и дейтаграммный TLS (DTLS)».
RFC 7525: «Рекомендации по безопасному использованию безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)».
QUIC (Quick UDP Internet Connections) – «…был разработан для обеспечения защиты, эквивалентной TLS/SSL»; Основная цель QUIC — улучшить воспринимаемую производительность веб-приложений, ориентированных на соединение, которые в настоящее время используют TCP.
^ т.е. «Делегированные учетные данные для (D)TLS». Ietf Datatracker . Проверено 29 ноября 2022 г.
^ аб Лоуренс, Скотт; Кхаре, Рохит (май 2000 г.). «Обновление до TLS в HTTP/1.1». Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC2817 . Проверено 15 декабря 2018 г.
^ «Подробно о SSL/TLS» . ТехНет . Документы Майкрософт . 8 октября 2009 года . Проверено 24 октября 2021 г.
^ Аб Хупер, Ховард (2012). Официальное руководство по сертификации CCNP Security VPN 642-648 (2-е изд.). Сиско Пресс. п. 22. ISBN9780132966382.
^ аб Спотт, Эндрю; Лук-порей, Том; и другие. «Какой уровень TLS?». Обмен стеками информационной безопасности .
^ abcdef Э. Рескорла (август 2018 г.). Протокол безопасности транспортного уровня (TLS) версии 1.3. Рабочая группа IETF TLS. дои : 10.17487/RFC8446 . РФК 8446.Предлагаемый стандарт. Устаревшие RFC 5077, 5246 и 6961; обновляет RFC 5705 и 6066.
^ Рескорла, Эрик; Модадугу, Нагендра (апрель 2006 г.). Безопасность транспортного уровня дейтаграмм. дои : 10.17487/RFC4347 . РФК 4347.
^ Рескорла, Эрик; Модадугу, Нагендра (январь 2012 г.). Безопасность дейтаграммного транспортного уровня версии 1.2. дои : 10.17487/RFC6347 . РФК 6347.
^ Титц, Олаф (23 апреля 2001 г.). «Почему TCP поверх TCP — плохая идея» . Проверено 17 октября 2015 г.
^ Хонда, Осаму; Осаки, Хироюки; Имасе, Макото; Исидзука, Мика; Мураяма, Дзюнъити (октябрь 2005 г.). «Понимание TCP поверх TCP: влияние туннелирования TCP на сквозную пропускную способность и задержку». В Атикуззамане, Мохаммед; Баландин, Сергей I (ред.). Производительность, качество обслуживания и управление коммуникационными и сенсорными сетями следующего поколения III . Том. 6011. Бибкод : 2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . дои : 10.1117/12.630496. S2CID 8945952.
^ RFC 4347 § 4
^ Рескорла, Эрик; Чофениг, Ханнес; Модадугу, Нагена (21 апреля 2022 г.). «Протокол безопасности транспортного уровня датаграмм (DTLS) версии 1.3».
^ «Часто задаваемые вопросы AnyConnect: туннели, поведение повторного подключения и таймер бездействия» . Циско . Проверено 26 февраля 2017 г.
^ «Обзор архитектуры Cisco InterCloud» (PDF) . Сиско Системы .
^ "ОпенКоннект". ОпенКоннект . Проверено 26 февраля 2017 г.
^ "Заметки о взаимодействии WebRTC" . Архивировано из оригинала 11 мая 2013 г.
^ abcde Брайт, Питер (17 октября 2018 г.). «Apple, Google, Microsoft и Mozilla объединились, чтобы положить конец TLS 1.0» . Проверено 17 октября 2018 г.
^ abcd «Вот что нового и изменено в стабильной версии Firefox 74.0 — технические новости gHacks». www.ghacks.net . 10 марта 2020 г. Проверено 10 марта 2020 г.
^ abcd «TLS 1.0 и TLS 1.1 — состояние платформы Chrome». chromestatus.com . Проверено 10 марта 2020 г.
^ abcde Т. Диркс; Э. Рескорла (август 2008 г.). Протокол безопасности транспортного уровня (TLS) версии 1.2. Рабочая группа IETF TLS. дои : 10.17487/RFC5246 . РФК 5246.Устаревший. Устарело согласно RFC 8446; устаревшие RFC 3268, 4346 и 4366; обновляет RFC 4492.
^ ab «Использование TLS для защиты данных». www.ncsc.gov.uk. _ Архивировано из оригинала 21 июля 2021 года . Проверено 24 августа 2022 г.
^ «TLS 1.3: Год спустя» . IETF . Архивировано из оригинала 8 июля 2020 года . Проверено 24 августа 2022 г.
^ «Создание TLS: новаторская роль Рут Нельсон».
^ Ву, Томас Ю.К.; Биндигнавле, Рагурам; Су, Шаовэн; Лам, Саймон С. (июнь 1994 г.). SNP: Интерфейс для безопасного сетевого программирования (PDF) . Материалы летней технической конференции USENIX.
^ «Программа летней технической конференции USENIX 1994 г., Бостон, 6-10 июня 1994 г.» .
^ Мессмер, Эллен. «Отец SSL, доктор Тахер Эльгамаль, находит быстро развивающиеся ИТ-проекты на Ближнем Востоке». Сетевой мир . Архивировано из оригинала 31 мая 2014 года . Проверено 30 мая 2014 г.
^ Грин, Тим. «Отец SSL говорит, что, несмотря на атаки, у стержня безопасности еще много жизни». Сетевой мир . Архивировано из оригинала 31 мая 2014 года . Проверено 30 мая 2014 г.
^ аб Опплигер, Рольф (2016). "Введение". SSL и TLS: теория и практика (2-е изд.). Артех Хаус . п. 13. ISBN978-1-60807-999-5. Проверено 1 марта 2018 г. - через Google Книги.
^ "ПРОТОКОЛ SSL" . Корпорация Нетскейп. 2007. Архивировано из оригинала 14 июня 1997 года.
^ Рескорла 2001
^ «ПУДЛ: уязвимость SSLv3 (CVE-2014-3566)» . Архивировано из оригинала 5 декабря 2014 года . Проверено 21 октября 2014 г.
^ «Стандарты безопасности и изменения имен в войнах браузеров» . Проверено 29 февраля 2020 г.
^ «Изменения в соблюдении требований PCI вступят в силу 30 июня. Готов ли ваш бизнес в сфере электронной коммерции?». Форбс . Проверено 20 июня 2018 г.
^ Т. Диркс; Э. Рескорла (апрель 2006 г.). Протокол безопасности транспортного уровня (TLS) версии 1.1. Рабочая группа IETF TLS. дои : 10.17487/RFC4346 . РФК 4346.Исторический. Устарело по RFC 5246. Устарело по RFC 2246.
^ abc «Параметры безопасности транспортного уровня — наборы шифров». Управление по присвоению номеров в Интернете (IANA) . Проверено 16 декабря 2022 г.
^ «Twitter прекратит поддержку TLS 1.0, TLS 1.1 15 июля» . Хешировано SSL Store . 12 июля 2019 г. Проверено 14 июня 2021 г.
^ Маки, Курт. «Microsoft откладывает прекращение поддержки TLS 1.0 и 1.1 -». Интернет-журнал сертифицированных профессионалов Microsoft .
^ «Часто задаваемые вопросы по TLS 1.2 - База знаний» . Ответы.psionline.com . Проверено 20 февраля 2022 г.
^ «Различия между TLS 1.2 и TLS 1.3 (#TLS13)» . ВольфSSL . 18 сентября 2019 г. Архивировано из оригинала 19 сентября 2019 г. Проверено 18 сентября 2019 г.
^ «Примечания к выпуску NSS 3.29» . Сеть разработчиков Mozilla. Февраль 2017 г. Архивировано из оригинала 22 февраля 2017 г.
^ «Включить TLS 1.3 по умолчанию» . Багзилла@Mozilla. 16 октября 2016 г. Проверено 10 октября 2017 г.
^ «Firefox — Примечания (60.0)» . Мозилла . Проверено 10 мая 2018 г.
^ «ProxySG, ASG и WSS прерывают SSL-соединения, когда клиенты, использующие TLS 1.3, получают доступ к сайтам, также использующим TLS 1.3». BlueTouch онлайн . 16 мая 2017 года. Архивировано из оригинала 12 сентября 2017 года . Проверено 11 сентября 2017 г.
^ Салливан 2017.
^ Томсон и Поли 2021, А.6. ТЛС.
^ Томсон и Поли 2021, 3.3. Фальсификация активного использования.
^ «Хакатон TLS 1.3 IETF 100» . Архивировано из оригинала 15 января 2018 г.
^ ab IETF - Целевая группа по интернет-инжинирингу (12 ноября 2017 г.), Презентации и награды хакатона IETF, заархивировано из оригинала 28 октября 2021 г. , получено 14 ноября 2017 г.
^ «Ура! TLS 1.3 уже здесь. Теперь его нужно реализовать и внедрить в программное обеспечение» . Проверено 28 марта 2018 г.
^ IETF - Целевая группа по проектированию Интернета (15 июля 2018 г.), IETF102-HACKATHON-20180715-1400, заархивировано из оригинала 28 октября 2021 г. , получено 18 июля 2018 г.
^ «БЕТА-версия wolfSSL TLS 1.3 уже доступна» . [email protected]. 11 мая 2017 года . Проверено 11 мая 2017 г.
^ «Поддержка TLS 1.3 Draft 28 в wolfSSL» . [email protected]. 14 июня 2018 года . Проверено 14 июня 2018 г.
^ «Выпущен OpenSSL 1.1.1» . Мэтт Касвелл. 11 сентября 2018 г. Проверено 19 декабря 2018 г.
^ «Протоколы в TLS/SSL (Schannel SSP)» . Документы Майкрософт . 25 мая 2022 г. Проверено 21 февраля 2023 г.
^ Хоффман-Эндрюс, Джейкоб (26 февраля 2019 г.). «ETS — это не TLS, и вам не следует его использовать». Фонд электронных границ . Проверено 27 февраля 2019 г.
^ ТС 103 523-3 - В1.1.1 - КИБЕР; Протокол безопасности Миддлбокса; Часть 3: Профиль для контроля доступа к корпоративной сети и центру обработки данных ( PDF ) . ETSI.org . Архивировано (PDF) из оригинала 14 ноября 2018 г.
↑ Кори Доктороу (26 февраля 2019 г.). «Монументальное безрассудство». Боинг-Боинг . Архивировано из оригинала 27 февраля 2019 года.
^ Ри, Скотт (2013). «Альтернативы центрам сертификации для безопасного Интернета» (PDF) . Конференция ЮАР Азиатско-Тихоокеанский регион. Архивировано (PDF) из оригинала 7 октября 2016 года . Проверено 7 сентября 2016 г.
^ «Подсчет SSL-сертификатов». Архивировано из оригинала 16 мая 2015 года . Проверено 20 февраля 2022 г.
↑ Раймонд, Арт (3 августа 2017 г.). «DigiCert от Lehi поглощает конкурента по веб-безопасности в сделке на 1 миллиард долларов» . Новости Дезерета . Проверено 21 мая 2020 г.
^ «Тенденции доли рынка центров сертификации SSL» . W3Techs . Проверено 21 мая 2020 г.
↑ Райан Сингел (24 марта 2010 г.). «Устройство правоохранительных органов подрывает SSL». проводной .com . Архивировано из оригинала 12 апреля 2014 года.
↑ Сет Шон (24 марта 2010 г.). «Новое исследование предполагает, что правительства могут подделывать сертификаты SSL». EFF.org . _ Архивировано из оригинала 25 марта 2010 года.
^ П. Эронен, Ред. (декабрь 2005 г.). Эронен, П; Чофениг, Х. (ред.). «Наборы шифров с предварительным общим ключом для безопасности транспортного уровня (TLS)». Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC4279. РФК 4279 . Архивировано из оригинала 5 сентября 2013 года . Проверено 9 сентября 2013 г.
^ Д. Тейлор, Эд. (ноябрь 2007 г.). «Использование протокола безопасного удаленного пароля (SRP) для аутентификации TLS». Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC5054 . РФК 5054 . Архивировано из оригинала 7 декабря 2014 года . Проверено 21 декабря 2014 г.
↑ Готард, Питер (31 июля 2013 г.). «Google обновляет сертификаты SSL до 2048-битного шифрования». Вычисление . Острые СМИ. Архивировано из оригинала 22 сентября 2013 года . Проверено 9 сентября 2013 г.
^ «Ценность 2048-битного шифрования: почему длина ключа шифрования имеет значение» . Поисковая безопасность . Архивировано из оригинала 16 января 2018 г. Проверено 18 декабря 2017 г.
^ Шон Тернер (17 сентября 2015 г.). «Консенсус: удалить DSA из TLS 1.3». Архивировано из оригинала 3 октября 2015 года.
^ RFC 8422
^ abcdefg RFC 5830, 6986, 7091, 7801, 8891
^ RFC 5288, 5289
^ RFC 6655, 7251
^ RFC 6367
^ RFC 5932, 6367
^ ab RFC 6209
^ RFC 4162
^ «О практической (не)безопасности 64-битных блочных шифров — коллизионные атаки на HTTP через TLS и OpenVPN» (PDF) . 28 октября 2016 г. Архивировано (PDF) из оригинала 24 апреля 2017 г. Проверено 8 июня 2017 г.
^ «Специальная публикация NIST 800-57, Рекомендации по управлению ключами. Часть 1: Общие сведения (пересмотренные)» (PDF) . 08 марта 2007 г. Архивировано из оригинала (PDF) 6 июня 2014 года . Проверено 3 июля 2014 г.
^ abc Qualys SSL Labs. «Лучшие практики развертывания SSL/TLS». Архивировано из оригинала 4 июля 2015 года . Проверено 2 июня 2015 г.
^ RFC 5469
^ RFC 7905
^ «Http против https» . Архивировано из оригинала 12 февраля 2015 г. Проверено 12 февраля 2015 г.
^ abcd По состоянию на 3 сентября 2023 г. «SSL Pulse: исследование внедрения SSL на самых популярных веб-сайтах». Квалис . Проверено 5 октября 2023 г.
^ Аб Иванр (19 марта 2013 г.). «RC4 в TLS сломан: что теперь?». Лаборатории безопасности Qualsys. Архивировано из оригинала 27 августа 2013 г. Проверено 30 июля 2013 г.
^ abc Бодо Мёллер, Тай Дуонг и Кшиштоф Котович. «Этот пудель кусается: использование резервного варианта SSL 3.0» (PDF) . Архивировано (PDF) из оригинала 14 октября 2014 г. Проверено 15 октября 2014 г.
^ «Internet Explorer 11 вышел из эксплуатации и официально не поддерживается — что вам нужно знать» . 15 июня 2022 г. . Проверено 15 июня 2022 г.
^ «Поддержка классических приложений Internet Explorer 11 прекращена для некоторых версий Windows 10» . Проверено 17 июня 2022 г.
^ «Справочное руководство по расширению Java Secure Socket Extension (JSSE)» . Справочный центр Oracle . Проверено 24 декабря 2021 г.
^ Георгиев, Мартин; Айенгар, Субодх; Яна, Суман; Анубхай, Ришита; Боне, Дэн; Шматиков, Виталий (2012). Самый опасный код в мире: проверка SSL-сертификатов в небраузерном ПО. Материалы конференции ACM 2012 г. по компьютерной и коммуникационной безопасности (PDF) . Ассоциация вычислительной техники. стр. 38–49. ISBN978-1-4503-1651-4. Архивировано (PDF) из оригинала 22 октября 2017 г.
^ Одет, Ф. (2009). Использование схемы URI SIPS в протоколе инициации сеанса (SIP). дои : 10.17487/RFC5630 . РФК 5630.
^ Шеффер, Ю.; Хольц, Р.; Сен-Андре, П. (2015). Обзор известных атак на безопасность транспортного уровня (TLS) и дейтаграммный TLS (DTLS). дои : 10.17487/RFC7457 . РФК 7457.
^ «CVE – CVE-2009-3555» . Архивировано из оригинала 4 января 2016 г.
^ Рескорла, Эрик (5 ноября 2009 г.). «Понимание атаки повторного согласования TLS». Образованные догадки . Архивировано из оригинала 11 февраля 2012 г. Проверено 27 ноября 2009 г.
^ "SSL_CTX_set_options SECURE_RENEGOTIATION". Документация OpenSSL . 25 февраля 2010 г. Архивировано из оригинала 26 ноября 2010 г. Проверено 18 ноября 2010 г.
^ «Выпущен GnuTLS 2.10.0» . Примечания к выпуску GnuTLS . 25 июня 2010 г. Архивировано из оригинала 17 октября 2015 г. Проверено 24 июля 2011 г.
^ «Примечания к выпуску NSS 3.12.6» . Примечания к выпуску NSS . 03.03.2010. Архивировано из оригинала 6 марта 2012 года . Проверено 24 июля 2011 г.
^ А. Лэнгли; Н. Модадугу; Б. Мёллер (2 июня 2010 г.). «Фальстарт безопасности транспортного уровня (TLS)». Рабочая группа по интернет-инжинирингу . IETF. Архивировано из оригинала 5 сентября 2013 г. Проверено 31 июля 2013 г.
^ Грюнер, Вольфганг. «Фальстарт: Google предлагает более быстрый Интернет, Chrome уже поддерживает его». Архивировано из оригинала 7 октября 2010 г. Проверено 9 марта 2011 г.
^ Смит, Брайан. «Ограниченные атаки отката при фальстарте и мгновенном старте». Архивировано из оригинала 4 мая 2011 г. Проверено 9 марта 2011 г.
^ Димцев, Адриан. "Фальстарт". Случайный SSL/TLS 101 . Архивировано из оригинала 4 мая 2011 г. Проверено 9 марта 2011 г.
^ Маврояннопулос, Никос; Веркотерн, Фредерик; Величков, Веселин; Пренил, Барт (2012). Межпротокольная атака на протокол TLS. Материалы конференции ACM 2012 г. по компьютерной и коммуникационной безопасности (PDF) . Ассоциация вычислительной техники. стр. 62–72. ISBN978-1-4503-1651-4. Архивировано (PDF) из оригинала 6 июля 2015 г.
^ «SMACK: Атаки на конечный автомат» . Архивировано из оригинала 12 марта 2015 г.
^ Гудин, Дэн (20 мая 2015 г.). «Атака с использованием HTTPS угрожает десяткам тысяч веб- и почтовых серверов». Арс Техника . Архивировано из оригинала 19 мая 2017 г.
↑ Лейден, Джон (1 марта 2016 г.). «Одна треть всех HTTPS-сайтов открыта для атаки DROWN». Регистр . Архивировано из оригинала 1 марта 2016 года . Проверено 2 марта 2016 г.
^ ab «Более 11 миллионов веб-сайтов HTTPS подвергаются опасности из-за новой атаки дешифрования» . Арс Техника . Март 2016 г. Архивировано из оригинала 01 марта 2016 г. Проверено 2 марта 2016 г.
^ Тай Дуонг и Джулиано Риццо (13 мая 2011 г.). «А вот и ⊕ ниндзя». Архивировано из оригинала 3 июня 2014 г.
^ Гудин, Дэн (19 сентября 2011 г.). «Хакеры взламывают SSL-шифрование, используемое миллионами сайтов». Регистр . Архивировано из оригинала 10 февраля 2012 г.
^ «Комментарий Y Combinator по этому вопросу» . 20 сентября 2011 г. Архивировано из оригинала 31 марта 2012 г.
^ «Безопасность наборов шифров CBC в SSL/TLS: проблемы и меры противодействия». 20 мая 2004 г. Архивировано из оригинала 30 июня 2012 г.
↑ Ристич, Иван (10 сентября 2013 г.). «ЗВЕРЬ все еще представляет угрозу?». Архивировано из оригинала 12 октября 2014 года . Проверено 8 октября 2014 г.
^ «Стабильная версия Chrome» . Релизы Chrome . 25 октября 2011 г. Архивировано из оригинала 20 февраля 2015 г. Проверено 1 февраля 2015 г.
^ «Атака на коммуникации, защищенные TLS». Блог о безопасности Mozilla . Мозилла. 27 сентября 2011 г. Архивировано из оригинала 4 марта 2015 г. Проверено 1 февраля 2015 г.
^ Смит, Брайан (30 сентября 2011 г.). «(CVE-2011-3389) Rizzo/Duong выбрала атаку открытого текста (BEAST) на SSL/TLS 1.0 (при поддержке websockets-76)».
^ MSRC (10 января 2012 г.). Уязвимость в SSL/TLS может привести к раскрытию информации (2643584). Бюллетени безопасности (Технический отчет). MS12-006 . Получено 24 октября 2021 г. - через Microsoft Docs .
↑ Ристич, Иван (31 октября 2013 г.). «Apple включила средства защиты BEAST в OS X 10.9 Mavericks». Архивировано из оригинала 12 октября 2014 года . Проверено 8 октября 2014 г.
^ Гудин, Дэн (13 сентября 2012 г.). «Взлом в фундаменте доверия в Интернете позволяет перехватить сеанс HTTPS» . Арс Техника . Архивировано из оригинала 1 августа 2013 г. Проверено 31 июля 2013 г.
↑ Фишер, Деннис (13 сентября 2012 г.). «Преступная атака использует степень сжатия запросов TLS в качестве побочного канала для перехвата защищенных сеансов». ThreatPost. Архивировано из оригинала 15 сентября 2012 года . Проверено 13 сентября 2012 г.
^ Аб Гудин, Дэн (1 августа 2013 г.). «Угнать за 30 секунд: новая атака выхватывает секреты из страниц, защищенных HTTPS». Арс Техника . Конде Наст. Архивировано из оригинала 3 августа 2013 года . Проверено 2 августа 2013 г.
↑ Лейден, Джон (2 августа 2013 г.). «Шаг в НАРУШЕНИЕ: разработана новая атака для чтения зашифрованных веб-данных». Регистр . Архивировано из оригинала 5 августа 2013 года . Проверено 2 августа 2013 г.
^ П. Гутманн (сентябрь 2014 г.). «Зашифровать, а затем MAC для безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)». Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC7366. Архивировано из оригинала 12 мая 2015 г.
↑ Лэнгли, Адам (8 декабря 2014 г.). «ПУДЛЬ снова кусается». Архивировано из оригинала 8 декабря 2014 года . Проверено 8 декабря 2014 г.
^ «Ssl — самые безопасные шифры для использования с BEAST? (Эксплойт TLS 1.0) Я читал, что RC4 невосприимчив» . Serverfault.com . Проверено 20 февраля 2022 г.
^ Пуян Сепердад; Серж Водене; Мартин Вуанью (2011). «Открытие и использование новых предубеждений в RC4». У Алекса Бирюкова; Гуан Гун; Дуглас Р. Стинсон (ред.). Избранные области криптографии: 17-й международный семинар, SAC 2010, Ватерлоо, Онтарио, Канада, 12–13 августа 2010 г., Пересмотренные избранные статьи . Конспекты лекций по информатике. Том. 6544. стр. 74–91. дои : 10.1007/978-3-642-19574-7_5. ISBN978-3-642-19573-0.
↑ Грин, Мэтью (12 марта 2013 г.). «Атака недели: RC4 немного сломан в TLS». Криптографическая инженерия . Архивировано из оригинала 14 марта 2013 года . Проверено 12 марта 2013 г.
^ АльФардан, Надхем; Бернштейн, Дэн; Патерсон, Кенни; Пёттеринг, Бертрам; Шульдт, Джейкоб. «О безопасности RC4 в TLS». Лондонский Королевский университет Холлоуэй. Архивировано из оригинала 15 марта 2013 года . Проверено 13 марта 2013 г.
^ АльФардан, Надхем Дж.; Бернштейн, Дэниел Дж.; Патерсон, Кеннет Г.; Пёттеринг, Бертрам; Шульдт, Джейкоб К.Н. (8 июля 2013 г.). «О безопасности RC4 в TLS и WPA» (PDF) . Группа информационной безопасности . Архивировано (PDF) из оригинала 22 сентября 2013 года . Проверено 2 сентября 2013 г.
^ АльФардан, Надхем Дж.; Бернштейн, Дэниел Дж.; Патерсон, Кеннет Г.; Пёттеринг, Бертрам; Шульдт, Джейкоб CN (15 августа 2013 г.). О безопасности RC4 в TLS (PDF) . 22-й симпозиум USENIX по безопасности. п. 51. Архивировано (PDF) из оригинала 22 сентября 2013 года . Проверено 2 сентября 2013 г. Атаки с восстановлением открытого текста на RC4 в TLS возможны, но не совсем практичны.
↑ Гудин, Дэн (15 июля 2015 г.). «Некогда теоретическая криптоатака на HTTPS теперь граничит с практичностью». Арс Технический . Конде Наст. Архивировано из оригинала 16 июля 2015 года . Проверено 16 июля 2015 г.
^ «Рекомендуемые конфигурации TLS на стороне сервера Mozilla Security» . Мозилла. Архивировано из оригинала 3 января 2015 г. Проверено 03 января 2015 г.
^ «Рекомендации по безопасности 2868725: Рекомендация отключить RC4» . Майкрософт. 12 ноября 2013 г. Архивировано из оригинала 18 ноября 2013 г. Проверено 4 декабря 2013 г.
^ «Прекращение поддержки шифра RC4 в Microsoft Edge и Internet Explorer 11» . Команда Microsoft Edge. 1 сентября 2015 г. Архивировано из оригинала 2 сентября 2015 г.
↑ Лэнгли, Адам (1 сентября 2015 г.). «Намерение прекратить поддержку: RC4».
↑ Барнс, Ричард (1 сентября 2015 г.). «Намерение к отправке: RC4 отключен по умолчанию в Firefox 44». Архивировано из оригинала 22 января 2011 г.
^ аб Джон Лейден (1 августа 2013 г.). «Gmail, Outlook.com и электронное голосование были «захвачены» на сцене в результате взлома криптовалюты» . Регистр . Архивировано из оригинала 1 августа 2013 года . Проверено 1 августа 2013 г.
^ "Брифинги BlackHat USA" . Черная шляпа 2013 . Архивировано из оригинала 30 июля 2013 года . Проверено 1 августа 2013 г.
^ Смит, Бен; Пиронти, Альфредо (2013). Усечение TLS-соединений для нарушения правил в веб-приложениях. 7-й семинар USENIX по наступательным технологиям (отчет). Архивировано из оригинала 6 ноября 2015 года . Проверено 15 февраля 2016 г.
^ АльФардан, Надхем; Патерсон, Кеннет Дж. (2012). Атаки с восстановлением открытого текста на датаграммы TLS (PDF) . Симпозиум по безопасности сетей и распределенных систем (NDSS 2012). Архивировано из оригинала 18 января 2012 г.{{cite conference}}: CS1 maint: unfit URL (link)
↑ Гудин, Дэн (26 июля 2016 г.). «Новая атака обходит защиту HTTPS на Mac, Windows и Linux». Арс Техника . Конде Наст. Архивировано из оригинала 27 июля 2016 года . Проверено 28 июля 2016 г.
↑ Гудин, Дэн (24 августа 2016 г.). «HTTPS и OpenVPN сталкиваются с новой атакой, которая может расшифровать секретные файлы cookie». Арс Техника . Архивировано из оригинала 24 августа 2016 года . Проверено 24 августа 2016 г.
^ «Почему это называется «Жук с кровоточащим сердцем»?». Вашингтон Пост . 09.04.2014. Архивировано из оригинала 9 октября 2014 г.
^ «Уязвимость Heartbleed Bug [9 апреля 2014 г.]» . Группа Комодо . Архивировано из оригинала 5 июля 2014 года.
^ Бляйхенбахер, Дэниел (август 2006 г.). «Подделка подписи RSA Бляйхенбахера на основе ошибки реализации» . Архивировано из оригинала 16 декабря 2014 г.
^ "БЕРсерк". Безопасность Intel: расширенное исследование угроз. Сентябрь 2014 г. Архивировано из оригинала 12 января 2015 г.
↑ Гудин, Дэн (19 февраля 2015 г.). «Компьютеры Lenovo поставляются с рекламным ПО «посредник», которое разрывает HTTPS-соединения». Арс Техника . Архивировано из оригинала 12 сентября 2017 года . Проверено 10 декабря 2017 г.
^ Вальсорда, Филиппо (20 февраля 2015 г.). «Проверка SSL Komodia/Superfish нарушена». Филиппо.io. Архивировано из оригинала 24 февраля 2015 г.
↑ Аб Гудин, Дэн (26 мая 2016 г.). ««Запрещенная атака» делает десятки сайтов HTTPS Visa уязвимыми для взлома». Арс Техника . Архивировано из оригинала 26 мая 2016 года . Проверено 26 мая 2016 г.
↑ Кларк Эстес, Адам (24 февраля 2017 г.). «Все, что вам нужно знать о Cloudbleed, последней катастрофе в области интернет-безопасности». Гизмодо . Архивировано из оригинала 25 февраля 2017 г. Проверено 24 февраля 2017 г.
^ Диффи, Уитфилд; ван Оршот, Пол С; Винер, Майкл Дж. (июнь 1992 г.). «Аутентификация и обмен ключами с проверкой подлинности». Проекты, коды и криптография . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . дои : 10.1007/BF00124891. S2CID 7356608. Архивировано из оригинала 13 марта 2008 г. Проверено 11 февраля 2008 г.
^ «Обсуждение в списке рассылки TLS в октябре 2007 г.» Архивировано из оригинала 22 сентября 2013 года . Проверено 20 февраля 2022 г.
^ «Защита данных в долгосрочной перспективе с помощью прямой секретности» . Архивировано из оригинала 6 мая 2013 г. Проверено 5 ноября 2012 г.
↑ Бернат, Винсент (28 ноября 2011 г.). «SSL/TLS и идеальная секретность пересылки». Архивировано из оригинала 27 августа 2012 г. Проверено 5 ноября 2012 г.
^ «Лаборатории SSL: внедрение прямой секретности» . Qualys.com. 25 июня 2013 г. Архивировано из оригинала 26 июня 2013 г. Проверено 10 июля 2013 г.
^ Ристич, Иван (5 августа 2013 г.). «SSL Labs: внедрение прямой секретности». Квалсис. Архивировано из оригинала 20 сентября 2013 г. Проверено 31 августа 2013 г.
^ аб Лэнгли, Адам (27 июня 2013 г.). «Как испортить секретность пересылки TLS». Imperialviolet.org . Архивировано из оригинала 8 августа 2013 года.
^ аб Денььер, Флоран. «Секреты TLS: Технический документ, описывающий последствия для безопасности развертывания билетов сеанса (RFC 5077), реализованные в OpenSSL» (PDF) . Матта Консалтинг Лимитед. Архивировано (PDF) из оригинала 6 августа 2013 года . Проверено 7 августа 2013 г.
^ аб Денььер, Флоран. «ТЛС «Секреты»: То, что вам все забыли сказать…» (PDF) . Матта Консалтинг Лимитед. Архивировано (PDF) из оригинала 5 августа 2013 года . Проверено 7 августа 2013 г.
^ Л.С. Хуан; С. Адхикарла; Д. Бонех; К. Джексон (2014). «Экспериментальное исследование развертывания прямой секретности TLS». IEEE Интернет-вычисления . 18 (6): 43–51. CiteSeerX 10.1.1.663.4653 . дои : 10.1109/MIC.2014.86. S2CID 11264303. Архивировано из оригинала 20 сентября 2015 года . Проверено 16 октября 2015 г.
^ «Защита данных в долгосрочной перспективе с помощью прямой секретности» . Архивировано из оригинала 12 февраля 2014 г. Проверено 7 марта 2014 г.
^ Хоффман-Эндрюс, Джейкоб. «Прямая секретность в Твиттере». Твиттер. Архивировано из оригинала 16 февраля 2014 г. Проверено 7 марта 2014 г.
^ abc Durumeric, Закир; Ма, Зейн; Спринголл, Дрю; Барнс, Ричард; Салливан, Ник; Бурштейн, Эли; Бейли, Майкл; Халдерман, Дж. Алекс; Паксон, Верн (5 сентября 2017 г.). «Влияние перехвата HTTPS на безопасность». Симпозиум НДСС . doi : 10.14722/ndss.2017.23456. ISBN978-1-891562-46-4.
^ ab Эти сертификаты в настоящее время имеют формат X.509 , но RFC 6091 также определяет использование сертификатов на основе OpenPGP .
^ "tls - Различия между терминами "предварительный главный секрет", "главный секрет", "закрытый ключ" и "общий секрет"?". Обмен стеками криптографии . Проверено 1 октября 2020 г.
^ Крис (18 февраля 2009 г.). «Выпущен vsftpd-2.1.0 — использование возобновления сеанса TLS для аутентификации подключения к данным FTPS». Страшная безопасность. blogspot.com. Архивировано из оригинала 7 июля 2012 г. Проверено 17 мая 2012 г.
^ Рескорла, Эрик (август 2018 г.). «Протокол безопасности транспортного уровня (TLS) версии 1.3». Редактор IETF RFC .
↑ Валсорда, Филиппо (23 сентября 2016 г.). «Обзор TLS 1.3 и вопросы и ответы». Блог Cloudflare .
^ Обзор SSL-сертификата Wildcard, заархивировано из оригинала 23 июня 2015 г. , получено 2 июля 2015 г.
^ Именованные виртуальные хосты SSL: как решить проблему (PDF) , заархивировано (PDF) из оригинала 3 августа 2012 г. , получено 17 мая 2012 г.
Цитируемые работы
Салливан, Ник (26 декабря 2017 г.). «Почему TLS 1.3 еще нет в браузерах». Блог Cloudflare . Проверено 14 марта 2020 г.
Томсон, Мартин; Поли, Томми (декабрь 2021 г.). Долгосрочная жизнеспособность механизмов расширения протоколов. дои : 10.17487/RFC9170 . РФК 9170.
дальнейшее чтение
Викискладе есть медиафайлы, связанные с SSL и TLS .
Вагнер, Дэвид; Шнайер, Брюс (ноябрь 1996 г.). «Анализ протокола SSL 3.0» (PDF) . Второй семинар USENIX по процедурам электронной коммерции . ЮСЕНИКС Пресс. стр. 29–40.
Стивен А. Томас (2000). Основы SSL и TLS для защиты Интернета . Нью-Йорк: Уайли. ISBN 978-0-471-38354-3.
Бард, Грегори (2006). «Сложная, но осуществимая блочная адаптивная атака с использованием выбранного открытого текста на SSL». Международная ассоциация криптологических исследований (136) . Проверено 23 сентября 2011 г.
Канвель, Брайс. «Перехват пароля в канале SSL/TLS». Архивировано из оригинала 20 апреля 2016 г. Проверено 20 апреля 2007 г.
RFC изменений для повторного согласования TLS . 2010. номер документа : 10.17487/RFC5746. РФК 5746 .
Создание VPN с помощью IPsec и SSL/TLS Статья в Linux Journal Рами Розена
Джошуа Дэвис (2010). Реализация SSL/TLS . Уайли. ISBN 978-0470920411.
Полк, Тим; Маккей, Керри; Чокхани, Сантош (апрель 2014 г.). «Руководство по выбору, настройке и использованию реализаций безопасности транспортного уровня (TLS)» (PDF) . Национальный институт стандартов и технологий. Архивировано из оригинала (PDF) 8 мая 2014 г. Проверено 7 мая 2014 г.
Абду, АбдельРахман; ван Оршот, Пол (август 2017 г.). «Проверка местоположения сервера (SLV) и закрепление местоположения сервера: расширение аутентификации TLS». Сделки о конфиденциальности и безопасности . АКМ. 21 (1): 1:1–1:26. дои : 10.1145/3139294. S2CID 5869541.
Иван Ристич (2022). Bulletproof TLS и PKI, второе издание . Злющая утка. ISBN 978-1907117091.
Внешние ссылки
Рабочая группа по интернет-инжинирингу – Рабочая группа TLS
