Протокол TLS направлен в первую очередь на обеспечение безопасности, включая конфиденциальность (приватность), целостность и подлинность посредством использования криптографии , например, использования сертификатов , между двумя или более взаимодействующими компьютерными приложениями. Он работает на уровне представления и сам состоит из двух уровней: протоколов записи TLS и протоколов рукопожатия TLS .
Тесно связанный протокол Datagram Transport Layer Security ( DTLS ) — это протокол связи , который обеспечивает безопасность приложений на основе датаграмм . В технической документации часто встречаются ссылки на "( D ) TLS ", когда это относится к обеим версиям. [1]
TLS — это предлагаемый стандарт IETF , впервые определенный в 1999 году, а текущая версия — TLS 1.3, определенная в августе 2018 года. TLS основан на ныне устаревших спецификациях SSL ( Secure Sockets Layer ) (1994, 1995, 1996), разработанных Netscape Communications для добавления протокола HTTPS в веб-браузер Netscape Navigator .
После того, как клиент и сервер согласились использовать 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 года Агентством национальной безопасности, Национальным бюро стандартов, Агентством оборонных коммуникаций и двенадцатью коммуникационными и компьютерными корпорациями, которые инициировали специальный проект под названием Система защищенных сетей передачи данных (SDNS). [26] Программа была описана в сентябре 1987 года на 10-й Национальной конференции по компьютерной безопасности в обширном наборе опубликованных статей.
Инновационная исследовательская программа была сосредоточена на разработке следующего поколения защищенной компьютерной коммуникационной сети и спецификаций продукта для внедрения в приложениях в публичных и частных интернетах. Она была предназначена для дополнения быстро появляющихся новых стандартов интернета OSI, продвигающихся вперед как в профилях GOSIP правительства США, так и в огромных усилиях ITU-ISO JTC1 по интернету на международном уровне. Первоначально известный как протокол SP4, он был переименован в TLS и впоследствии опубликован в 1995 году как международный стандарт ITU-T X.274|ISO/IEC 10736:1995.
Netscape разработала оригинальные протоколы SSL, а Тахер Элгамал , главный научный сотрудник Netscape Communications с 1995 по 1998 год, был назван «отцом SSL». [34] [35] [36] [37] Версия SSL 1.0 никогда не была публично выпущена из-за серьезных недостатков безопасности в протоколе. Версия 2.0, выпущенная в феврале 1995 года, быстро обнаружила ряд недостатков безопасности и удобства использования. Она использовала те же криптографические ключи для аутентификации и шифрования сообщений. Она имела слабую конструкцию MAC, которая использовала хэш-функцию MD5 с секретным префиксом, что делало ее уязвимой для атак на расширение длины. Она также не обеспечивала никакой защиты ни для начального рукопожатия, ни для явного закрытия сообщения, оба из которых означали, что атаки типа «человек посередине» могли остаться незамеченными. Более того, SSL 2.0 предполагал единую службу и фиксированный сертификат домена, что противоречило широко используемой функции виртуального хостинга на веб-серверах, поэтому большинство веб-сайтов были фактически ослаблены из-за использования SSL.
Эти недостатки потребовали полной переработки протокола до версии SSL 3.0. [38] [36] Выпущенный в 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. [39] 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». [40]
Совет PCI предложил организациям перейти с TLS 1.0 на TLS 1.1 или выше до 30 июня 2018 года. [41] [42] В октябре 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 года. [43] Это обновление TLS версии 1.0. Существенные отличия в этой версии включают:
Поддержка TLS версий 1.0 и 1.1 была повсеместно прекращена веб-сайтами примерно в 2020 году, что привело к отключению доступа к версиям Firefox до 24 и браузерам на базе Chromium до 29. [45] [46]
ТЛС 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. [44]
Все версии TLS были дополнительно улучшены в RFC 6176 в марте 2011 года, убрав их обратную совместимость с SSL, так что сеансы TLS никогда не согласовывают использование Secure Sockets Layer (SSL) версии 2.0. В настоящее время нет официальной даты прекращения поддержки TLS 1.2. Спецификации для TLS 1.2 также были переопределены в документе отслеживания стандартов RFC 8446, чтобы сделать его максимально безопасным; теперь его следует рассматривать как протокол отказоустойчивости, предназначенный только для согласования с клиентами, которые не могут общаться по TLS 1.3 (исходное определение RFC 5246 для TLS 1.2 с тех пор устарело).
ТЛС 1.3
TLS 1.3 был определен в RFC 8446 в августе 2018 года. [6] Он основан на более ранней спецификации TLS 1.2. Основные отличия от TLS 1.2 включают: [47]
Отделение алгоритмов согласования ключей и аутентификации от наборов шифров [44] [6] : §11
Требование цифровых подписей даже при использовании предыдущей конфигурации
Интеграция HKDF и полуэфемерного предложения DH
Замена возобновления на PSK и билеты
Поддержка 1- RTT рукопожатий и начальная поддержка 0- RTT
Требование полной прямой секретности посредством использования эфемерных ключей во время согласования ключей (EC)DH
Прекращение поддержки многих небезопасных или устаревших функций, включая сжатие , повторное согласование, не- AEAD шифры, нулевые шифры , [48] не- PFS обмен ключами (среди которых статический RSA и статический DH обмен ключами), настраиваемые группы DHE , согласование формата точек EC, протокол Change Cipher Spec, время UNIX для приветственных сообщений и поле длины AD ввода для AEAD шифров.
Запрет на согласование SSL или RC4 для обратной совместимости
Интеграция использования хэша сеанса
Отказ от использования номера версии слоя записи и заморозка номера для улучшения обратной совместимости
Перемещение некоторых деталей алгоритма, связанных с безопасностью, из приложения к спецификации и перенос ClientKeyShare в приложение
Добавление потокового шифра ChaCha20 с кодом аутентификации сообщений Poly1305
Добавление алгоритмов цифровой подписи Ed25519 и Ed448
Добавление протоколов обмена ключами x25519 и x448
Добавление поддержки отправки нескольких ответов OCSP
Шифрование всех сообщений рукопожатия после ServerHello
Network Security Services (NSS), криптографическая библиотека, разработанная Mozilla и используемая ее веб-браузером Firefox , включила TLS 1.3 по умолчанию в феврале 2017 года. [49] Поддержка TLS 1.3 была впоследствии добавлена — но из-за проблем совместимости для небольшого числа пользователей не была автоматически включена [50] — в Firefox 52.0 , который был выпущен в марте 2017 года. TLS 1.3 был включен по умолчанию в мае 2018 года с выпуском Firefox 60.0 . [51]
Google Chrome установил TLS 1.3 в качестве версии по умолчанию на короткое время в 2017 году. Затем он удалил ее из списка версий по умолчанию из-за несовместимых промежуточных устройств, таких как веб-прокси Blue Coat . [52]
Непереносимость новой версии TLS заключалась в окостенении протокола ; промежуточные устройства окостенели в параметре версии протокола. В результате версия 1.3 имитирует образ провода версии 1.2. Это изменение произошло очень поздно в процессе проектирования и было обнаружено только во время развертывания браузера. [53] Обнаружение этой непереносимости также привело к тому, что предыдущая стратегия согласования версий, в которой выбиралась самая совпадающая версия, была заброшена из-за неработоспособных уровней окостенения. [54] « Смазывание » точки расширения, в которой один участник протокола заявляет о поддержке несуществующих расширений, чтобы гарантировать, что нераспознанные, но фактически существующие расширения допускаются и, таким образом, противостоять окостенению, изначально была разработана для TLS, но с тех пор была принята в других местах. [54]
Во время хакатона IETF 100 , который состоялся в Сингапуре в 2017 году, группа TLS работала над адаптацией приложений с открытым исходным кодом для использования TLS 1.3. [55] [56] Группа TLS состояла из людей из Японии, Великобритании и Маврикия через команду cyberstorm.mu. [56] Эта работа была продолжена на хакатоне IETF 101 в Лондоне , [57] и хакатоне IETF 102 в Монреале. [58]
wolfSSL позволил использовать TLS 1.3 с версии 3.11.1, выпущенной в мае 2017 года. [59] Как первая коммерческая реализация TLS 1.3, wolfSSL 3.11.1 поддерживала Draft 18 и теперь поддерживает Draft 28, [60] финальную версию, а также многие старые версии. Была опубликована серия блогов о разнице в производительности между TLS 1.2 и 1.3. [61]
В, популярный проект OpenSSL выпустил версию 1.1.1 своей библиотеки, в которой поддержка TLS 1.3 была «главной новой функцией». [62]
Electronic Frontier Foundation похвалила TLS 1.3 и выразила обеспокоенность по поводу варианта протокола Enterprise Transport Security (ETS), который намеренно отключает важные меры безопасности в TLS 1.3. [64] Первоначально называвшийся Enterprise TLS (eTLS), ETS является опубликованным стандартом, известным как « ETSI TS103523-3», «Протокол безопасности промежуточного устройства, часть 3: безопасность корпоративной транспортировки». Он предназначен для использования исключительно в закрытых сетях, таких как банковские системы. ETS не поддерживает прямую секретность, чтобы позволить сторонним организациям, подключенным к закрытым сетям, использовать свой закрытый ключ для мониторинга сетевого трафика с целью обнаружения вредоносных программ и упрощения проведения аудита. [65] [66] Несмотря на заявленные преимущества, EFF предупредила, что потеря прямой секретности может облегчить раскрытие данных, а также заявила, что существуют лучшие способы анализа трафика. [64]
Цифровые сертификаты
Пример веб-сайта с цифровым сертификатом
Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата и указывает на определенные ожидаемые использования этого ключа. Это позволяет другим (доверяющим сторонам) полагаться на подписи или на утверждения, сделанные закрытым ключом, который соответствует сертифицированному открытому ключу. Хранилища ключей и хранилища доверия могут быть в различных форматах, таких как .pem , .crt, .pfx и .jks .
Центры сертификации
TLS обычно полагается на набор доверенных сторонних центров сертификации для установления подлинности сертификатов. Доверие обычно закреплено в списке сертификатов, распространяемых с программным обеспечением агента пользователя, [67] и может быть изменено проверяющей стороной.
По данным Netcraft , которая отслеживает активные сертификаты TLS, ведущим на рынке центром сертификации (CA) был Symantec с начала их исследования (или VeriSign до того, как подразделение служб аутентификации было куплено Symantec). По состоянию на 2015 год на долю Symantec приходилось чуть менее трети всех сертификатов и 44% действительных сертификатов, используемых 1 миллионом самых загруженных веб-сайтов, по подсчетам Netcraft. [68] В 2017 году Symantec продала свой бизнес TLS/SSL компании DigiCert. [69] В обновленном отчете было показано, что IdenTrust , DigiCert и Sectigo являются тремя крупнейшими центрами сертификации по доле рынка с мая 2019 года. [70]
В результате выбора сертификатов X.509 необходимы центры сертификации и инфраструктура открытого ключа для проверки связи между сертификатом и его владельцем, а также для генерации, подписания и администрирования действительности сертификатов. Хотя это может быть удобнее, чем проверка личности через сеть доверия , массовые раскрытия слежки в 2013 году сделали более широко известным, что центры сертификации являются слабым местом с точки зрения безопасности, допуская атаки типа «человек посередине» (MITM), если центр сертификации сотрудничает (или скомпрометирован). [71] [72]
Важность SSL-сертификатов
Шифрование : SSL-сертификаты шифруют данные, отправляемые между веб-сервером и браузером пользователя, гарантируя защиту конфиденциальной информации на протяжении всей передачи. Эта технология шифрования не позволяет неавторизованным лицам перехватывать и интерпретировать данные, защищая их от возможных рисков, таких как взлом или утечка данных.
Аутентификация : SSL-сертификаты также предлагают аутентификацию, удостоверяя целостность веб-сайта и то, что посетители подключаются к правильному серверу, а не к злонамеренному самозванцу. Этот метод аутентификации помогает потребителям завоевать доверие, гарантируя, что они имеют дело с надежным и безопасным веб-сайтом.
Целостность : Еще одна важная роль сертификатов SSL — обеспечение целостности данных. SSL использует криптографические методы для проверки того, что данные, передаваемые между сервером и браузером, не повреждены и не изменены во время передачи. Это не позволяет злоумышленникам вмешиваться в данные, обеспечивая их целостность и надежность.
Алгоритмы
Обмен ключами или соглашение о ключах
Прежде чем клиент и сервер смогут начать обмениваться информацией, защищенной TLS, они должны безопасно обменяться или согласовать ключ шифрования и шифр для использования при шифровании данных (см. § Шифр). Среди методов, используемых для обмена ключами/согласования, есть: открытые и закрытые ключи, сгенерированные с помощью RSA (обозначаются TLS_RSA в протоколе рукопожатия TLS), Диффи–Хеллман (TLS_DH), эфемерный Диффи–Хеллман (TLS_DHE), эллиптический-кривой Диффи–Хеллман (TLS_ECDH), эфемерный эллиптический-кривой Диффи–Хеллман (TLS_ECDHE), анонимный Диффи–Хеллман (TLS_DH_anon), [23] предварительный общий ключ (TLS_PSK) [73] и безопасный удаленный пароль (TLS_SRP). [74]
Методы согласования ключей TLS_DH_anon и TLS_ECDH_anon не аутентифицируют сервер или пользователя и поэтому используются редко, поскольку они уязвимы для атак типа «человек посередине» . Только TLS_DHE и TLS_ECDHE обеспечивают прямую секретность.
Сертификаты открытых ключей, используемые во время обмена/соглашения, также различаются по размеру открытых/закрытых ключей шифрования, используемых во время обмена, и, следовательно, по надежности предоставляемой безопасности. В июле 2013 года Google объявила, что больше не будет использовать 1024-битные открытые ключи и перейдет на 2048-битные ключи, чтобы повысить безопасность шифрования TLS, которое она предоставляет своим пользователям, поскольку надежность шифрования напрямую связана с размером ключа . [75] [76]
Шифр
Примечания
^ 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 можно атаковать с помощью атаки «Счастливая тринадцать», если библиотека не написана тщательно для устранения побочных каналов синхронизации.
^ abcdef Атака Sweet32 взламывает блочные шифры с размером блока 64 бита. [86]
^ Хотя длина ключа 3DES составляет 168 бит, эффективная сила безопасности 3DES составляет всего 112 бит, [87] что ниже рекомендуемого минимума в 128 бит. [88]
^ ab IDEA и DES были удалены из TLS 1.2. [89]
^ Наборы шифров abc 40-битной стойкости были намеренно разработаны с уменьшенной длиной ключа, чтобы соответствовать отмененным в настоящее время правилам США, запрещающим экспорт криптографического программного обеспечения, содержащего определенные сильные алгоритмы шифрования (см. Экспорт криптографии из США ). Эти слабые наборы запрещены в TLS 1.1 и более поздних версиях.
^ Использование RC4 во всех версиях TLS запрещено RFC 7465 (поскольку атаки RC4 ослабляют или нарушают RC4, используемый в SSL/TLS).
^ Только аутентификация, без шифрования.
Целостность данных
Код аутентификации сообщения (MAC) используется для обеспечения целостности данных. HMAC используется для режима CBC блочных шифров. Аутентифицированное шифрование (AEAD), такое как режим GCM и CCM, использует интегрированный в AEAD MAC и не использует HMAC . [6] : §8.4 PRF на основе HMAC или HKDF используется для подтверждения связи TLS.
Заявки и принятие
При проектировании приложений TLS обычно реализуется поверх протоколов транспортного уровня, шифруя все данные, связанные с протоколами, такими как HTTP , FTP , SMTP , NNTP и XMPP .
Основное применение TLS — защита трафика World Wide Web между веб-сайтом и веб-браузером, закодированным с помощью протокола HTTP. Такое использование TLS для защиты трафика HTTP составляет протокол HTTPS . [91]
Примечания
^ см. § Таблицу шифров выше
^ см. § Веб-браузеры и § Атаки на разделы TLS/SSL
Веб-браузеры
По состоянию на апрель 2016 года [обновлять]последние версии всех основных веб-браузеров поддерживают TLS 1.0, 1.1 и 1.2 и включают их по умолчанию. Однако не все поддерживаемые операционные системы Microsoft поддерживают последнюю версию IE. Кроме того, многие операционные системы Microsoft в настоящее время поддерживают несколько версий IE, но это изменилось в соответствии с часто задаваемыми вопросами о политике жизненного цикла поддержки Internet Explorer от Microsoft, заархивированными 20 июня 2023 г. на Wayback Machine : «начиная с 12 января 2016 года только самая последняя версия Internet Explorer, доступная для поддерживаемой операционной системы, будет получать техническую поддержку и обновления безопасности». Затем на странице перечисляется последняя поддерживаемая версия IE на эту дату для каждой операционной системы. Следующей критической датой будет дата, когда операционная система достигнет стадии окончания жизненного цикла. С 15 июня 2022 года Internet Explorer 11 прекратил поддержку редакций Windows 10 , которые следуют политике современного жизненного цикла Microsoft. [95] [96]
Меры по снижению уровня известных атак пока недостаточны:
Смягчение против атаки 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 отключён с версии 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 не были затронуты FREAK.
«Основной причиной большинства этих уязвимостей является ужасная конструкция API для базовых библиотек SSL. Вместо того чтобы выражать высокоуровневые свойства безопасности сетевых туннелей, такие как конфиденциальность и аутентификация, эти API раскрывают разработчикам приложений низкоуровневые детали протокола SSL. В результате разработчики часто используют API SSL неправильно, неправильно интерпретируя и не понимая их многочисленные параметры, опции, побочные эффекты и возвращаемые значения».
TLS также может использоваться для туннелирования всего сетевого стека для создания VPN , как в случае с OpenVPN и OpenConnect . Многие поставщики к настоящему времени объединили возможности шифрования и аутентификации TLS с авторизацией. Также с конца 1990-х годов наблюдалось существенное развитие в создании клиентских технологий вне веб-браузеров, чтобы обеспечить поддержку клиент-серверных приложений. По сравнению с традиционными технологиями IPsec VPN, TLS имеет некоторые неотъемлемые преимущества в области межсетевого экрана и обхода NAT , что упрощает администрирование для больших групп удаленного доступа.
TLS также является стандартным методом защиты сигнализации приложения Session Initiation Protocol (SIP). TLS может использоваться для обеспечения аутентификации и шифрования сигнализации SIP, связанной с VoIP и другими приложениями на основе SIP. [99]
Безопасность
Атаки на TLS/SSL
Ниже перечислены наиболее значимые атаки на TLS/SSL.
В феврале 2015 года IETF выпустила информационный RFC [100], в котором обобщены различные известные атаки на TLS/SSL.
Атака повторного согласования
В августе 2009 года была обнаружена уязвимость процедуры повторного согласования, которая может привести к атакам с инъекцией открытого текста против SSL 3.0 и всех текущих версий TLS. [101] Например, она позволяет злоумышленнику, который может перехватить соединение https, вставлять свои собственные запросы в начало разговора клиента с веб-сервером. Злоумышленник фактически не может расшифровать клиент-серверное общение, поэтому это отличается от типичной атаки «человек посередине». Краткосрочное исправление заключается в том, чтобы веб-серверы прекратили разрешать повторное согласование, что обычно не требует других изменений, если только не используется аутентификация клиентского сертификата . Чтобы устранить уязвимость, было предложено расширение индикации повторного согласования для TLS. Оно потребует от клиента и сервера включать и проверять информацию о предыдущих рукопожатиях в любые повторные согласования. [102] Это расширение стало предлагаемым стандартом и ему был присвоен номер RFC 5746. RFC был реализован несколькими библиотеками. [103] [104] [105]
Атаки понижения рейтинга:FREAK атака иАтака в тупике
Атака с понижением версии протокола (также называемая атакой с откатом версии) обманывает веб-сервер, заставляя его устанавливать соединения с предыдущими версиями TLS (например, SSLv2), которые давно заброшены как небезопасные.
Предыдущие модификации исходных протоколов, такие как False Start [106] (принятый и включенный Google Chrome [107] ) или Snap Start , как сообщается, вводили ограниченные атаки понижения версии протокола TLS [108] или позволяли вносить изменения в список наборов шифров, отправляемых клиентом на сервер. При этом злоумышленник мог преуспеть в том, чтобы повлиять на выбор набора шифров, пытаясь понизить версию набора шифров, согласованную для использования либо более слабого симметричного алгоритма шифрования, либо более слабого обмена ключами. [109] Доклад, представленный на конференции ACM по компьютерной и коммуникационной безопасности в 2012 году, продемонстрировал, что расширение False Start находилось под угрозой: при определенных обстоятельствах оно могло позволить злоумышленнику восстановить ключи шифрования в автономном режиме и получить доступ к зашифрованным данным. [110]
Атаки с понижением уровня шифрования могут заставить серверы и клиентов согласовывать соединение с использованием криптографически слабых ключей. В 2014 году была обнаружена атака типа «человек посередине» под названием FREAK, которая затрагивала стек OpenSSL , веб-браузер Android по умолчанию и некоторые браузеры Safari . [111] Атака заключалась в том, чтобы обманом заставить серверы согласовать соединение TLS с использованием криптографически слабых 512-битных ключей шифрования.
Logjam — уязвимость безопасности , обнаруженная в мае 2015 года, которая использует возможность использования устаревших 512-битных групп Диффи–Хеллмана «экспортного класса», датируемых 1990-ми годами. [112] Она заставляет уязвимые серверы перейти на криптографически слабые 512-битные группы Диффи–Хеллмана. Затем злоумышленник может вывести ключи, которые определяют клиент и сервер, используя обмен ключами Диффи–Хеллмана .
Атаки между протоколами: DROWN
Атака DROWN — это эксплойт, который атакует серверы, поддерживающие современные наборы протоколов SSL/TLS, используя их поддержку устаревшего, небезопасного протокола SSLv2 для атаки на соединения, использующие современные протоколы, которые в противном случае были бы безопасными. [113] [114] DROWN использует уязвимость в используемых протоколах и конфигурации сервера, а не какую-либо конкретную ошибку реализации. Полные сведения о DROWN были объявлены в марте 2016 года вместе с исправлением для эксплойта. На тот момент более 81 000 из 1 миллиона самых популярных веб-сайтов были среди защищенных TLS веб-сайтов, которые были уязвимы для атаки DROWN. [114]
ЗВЕРЬ атакует
23 сентября 2011 года исследователи Тай Дуонг и Джулиано Риццо продемонстрировали доказательство концепции под названием BEAST ( Browser Exploit Against SSL/TLS ) [115], использующее Java-апплет для нарушения ограничений политики одного источника для давно известной уязвимости цепочки блоков шифра (CBC) в TLS 1.0: [116] [117] злоумышленник, наблюдающий за 2 последовательными блоками зашифрованного текста C0, C1, может проверить, равен ли блок открытого текста P1 x, выбрав следующий блок открытого текста P2 = x ⊕ C0 ⊕ C1 ; согласно операции CBC, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , что будет равно C1, если x = P1 . Ранее не было продемонстрировано практических эксплойтов для этой уязвимости , которая была первоначально обнаружена Филиппом Рогауэем [118] в 2002 году. Уязвимость атаки была устранена в TLS 1.1 в 2006 году, но TLS 1.1 не получил широкого распространения до этой демонстрации атаки.
RC4 как потоковый шифр неуязвим для атаки BEAST. Поэтому RC4 широко использовался как способ смягчения атаки BEAST на стороне сервера. Однако в 2013 году исследователи обнаружили больше уязвимостей в RC4. После этого включение RC4 на стороне сервера больше не рекомендовалось. [119]
Chrome и Firefox сами по себе не уязвимы для атаки BEAST, [120] [121] однако Mozilla обновила свои библиотеки NSS для смягчения атак типа BEAST . NSS используется Mozilla Firefox и Google Chrome для реализации SSL. Некоторые веб-серверы , имеющие неисправную реализацию спецификации SSL, могут в результате перестать работать. [122]
10 января 2012 года компания Microsoft выпустила бюллетень по безопасности MS12-006, в котором была устранена уязвимость BEAST путем изменения способа, которым компонент Windows Secure Channel ( Schannel ) передает зашифрованные сетевые пакеты с сервера. [123] Пользователи 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 года. [124]
Атаки ПРЕСТУПЛЕНИЯ и НАРУШЕНИЯ
Авторы атаки BEAST также являются создателями более поздней атаки CRIME , которая может позволить злоумышленнику восстановить содержимое веб-cookie-файлов, если используется сжатие данных вместе с TLS. [125] [126] При использовании для восстановления содержимого секретных аутентификационных cookie-файлов она позволяет злоумышленнику выполнить перехват сеанса в аутентифицированном веб-сеансе.
Хотя атака CRIME была представлена как общая атака, которая может эффективно работать против большого количества протоколов, включая, помимо прочего, TLS и протоколы прикладного уровня, такие как SPDY или HTTP , были продемонстрированы и в значительной степени нейтрализованы в браузерах и серверах только эксплойты против TLS и SPDY. Эксплойт CRIME против сжатия HTTP не был нейтрализован вообще, хотя авторы CRIME предупреждали, что эта уязвимость может быть даже более распространенной, чем сжатие SPDY и TLS вместе взятые. В 2013 году был анонсирован новый случай атаки CRIME против сжатия HTTP, получивший название BREACH . На основе атаки CRIME атака BREACH может извлекать токены входа, адреса электронной почты или другую конфиденциальную информацию из зашифрованного TLS веб-трафика всего за 30 секунд (в зависимости от количества извлекаемых байтов), при условии, что злоумышленник обманом заставит жертву посетить вредоносную веб-ссылку или сможет внедрить контент в действительные страницы, которые посещает пользователь (например, беспроводная сеть под контролем злоумышленника). [127] Все версии TLS и SSL подвержены риску BREACH независимо от используемого алгоритма шифрования или шифра. [128] В отличие от предыдущих случаев CRIME, от которых можно успешно защититься, отключив сжатие TLS или сжатие заголовков SPDY, BREACH использует сжатие HTTP, которое в действительности невозможно отключить, поскольку практически все веб-серверы полагаются на него для повышения скорости передачи данных для пользователей. [127] Это известное ограничение TLS, поскольку он подвержен атаке с использованием выбранного открытого текста против данных прикладного уровня, которые он призван защищать.
Некоторые эксперты [88] также рекомендовали избегать тройного DES CBC. Поскольку последние поддерживаемые шифры, разработанные для поддержки любой программы, использующей библиотеку SSL/TLS Windows XP , например Internet Explorer на Windows XP, — это RC4 и Triple-DES, и поскольку RC4 теперь устарел (см. обсуждение атак RC4 ), это затрудняет поддержку любой версии SSL для любой программы, использующей эту библиотеку на XP.
Исправление было выпущено как расширение Encrypt-then-MAC для спецификации TLS, выпущенное как RFC 7366. [129] Атака Lucky Thirteen может быть смягчена в TLS 1.2, используя только шифры AES_GCM; AES_CBC остается уязвимым. SSL может защищать электронную почту, VoIP и другие типы коммуникаций по незащищенным сетям в дополнение к его основному варианту использования безопасной передачи данных между клиентом и сервером [2]
атака ПУДЛЯ
14 октября 2014 года исследователи Google опубликовали уязвимость в конструкции SSL 3.0, которая делает режим работы CBC с SSL 3.0 уязвимым для атаки padding ( CVE - 2014-3566). Они назвали эту атаку POODLE ( Padding Oracle On Downgraded Legacy Encryption ). В среднем злоумышленникам нужно сделать всего 256 запросов SSL 3.0, чтобы раскрыть один байт зашифрованных сообщений. [94]
Хотя эта уязвимость существует только в SSL 3.0, а большинство клиентов и серверов поддерживают TLS 1.0 и выше, все основные браузеры добровольно переходят на SSL 3.0, если рукопожатия с более новыми версиями TLS не удались, если только они не предоставляют пользователю или администратору возможность отключить SSL 3.0, и пользователь или администратор это делают [ требуется цитата ] . Таким образом, посредник может сначала провести атаку отката версии , а затем воспользоваться этой уязвимостью. [94]
8 декабря 2014 года был анонсирован вариант POODLE, который влияет на реализации TLS, не обеспечивающие должным образом соблюдение требований к байтам заполнения. [130]
RC4 атаки
Несмотря на существование атак на RC4 , которые нарушали его безопасность, наборы шифров в SSL и TLS, основанные на RC4, по-прежнему считались безопасными до 2013 года на основе способа, которым они использовались в SSL и TLS. В 2011 году набор RC4 был фактически рекомендован в качестве обходного пути для атаки BEAST . [131] Новые формы атак, раскрытые в марте 2013 года, окончательно продемонстрировали осуществимость взлома RC4 в TLS, что свидетельствует о том, что это не является хорошим обходным путем для BEAST. [93] Аль-Фарданом, Бернстайном, Патерсоном, Пёттерингом и Шульдтом был предложен сценарий атаки, в котором использовались недавно обнаруженные статистические смещения в таблице ключей RC4 [132] для восстановления частей открытого текста с большим количеством шифрований TLS. [133] [134] Атака на RC4 в TLS и SSL, требующая 13 × 2 20 шифрований для взлома RC4, была раскрыта 8 июля 2013 года и позже описана как «осуществимая» в сопутствующей презентации на симпозиуме по безопасности USENIX в августе 2013 года. [135] [136] В июле 2015 года последующие улучшения в атаке сделали ее все более практичной для взлома безопасности TLS, зашифрованного с помощью RC4. [137]
Поскольку многие современные браузеры были разработаны для отражения атак BEAST (за исключением Safari для Mac OS X 10.7 или более ранних версий, для iOS 6 или более ранних версий и для Windows; см. § Веб-браузеры), RC4 больше не является хорошим выбором для TLS 1.0. Шифры CBC, которые в прошлом были затронуты атакой BEAST, стали более популярным выбором для защиты. [88] Mozilla и Microsoft рекомендуют отключать RC4, где это возможно. [138] [139] RFC 7465 запрещает использование наборов шифров RC4 во всех версиях TLS.
1 сентября 2015 года Microsoft, Google и Mozilla объявили, что наборы шифров RC4 будут отключены по умолчанию в их браузерах ( Microsoft Edge , Internet Explorer 11 на Windows 7/8.1/10, Firefox и Chrome ) в начале 2016 года. [140] [141] [142]
Атака усечения
Атака усечения TLS (выход) блокирует запросы на выход из учетной записи жертвы, так что пользователь неосознанно остается в сети. Когда отправляется запрос на выход, злоумышленник вводит незашифрованное сообщение TCP FIN (больше никаких данных от отправителя), чтобы закрыть соединение. Поэтому сервер не получает запрос на выход и не знает об аварийном завершении. [143]
Опубликованная в июле 2013 года, [144] [145] атака заставляет веб-сервисы, такие как Gmail и Hotmail, отображать страницу, которая информирует пользователя об успешном выходе из системы, при этом гарантируя, что браузер пользователя сохраняет авторизацию в службе, позволяя злоумышленнику с последующим доступом к браузеру получить доступ и взять под контроль учетную запись вошедшего в систему пользователя. Атака не основана на установке вредоносного ПО на компьютер жертвы; злоумышленникам нужно только разместить себя между жертвой и веб-сервером (например, настроив мошенническую беспроводную точку доступа). [143] Эта уязвимость также требует доступа к компьютеру жертвы. Другая возможность заключается в том, что при использовании FTP соединение данных может иметь ложный FIN в потоке данных, и если правила протокола для обмена оповещениями close_notify не соблюдаются, файл может быть обрезан.
Атака открытым текстом против DTLS
В феврале 2013 года два исследователя из Royal Holloway, Лондонского университета, обнаружили атаку по времени [146] , которая позволила им восстановить (части) открытого текста из соединения DTLS с использованием реализации DTLS OpenSSL или GnuTLS при использовании режима шифрования Cipher Block Chaining .
Нечестивая атака PAC
Эта атака, обнаруженная в середине 2016 года, использует уязвимости в протоколе автообнаружения веб-прокси (WPAD) для раскрытия URL-адреса, к которому веб-пользователь пытается перейти по веб-ссылке с поддержкой TLS. [147] Раскрытие URL-адреса может нарушить конфиденциальность пользователя не только из-за веб-сайта, к которому осуществляется доступ, но и потому, что URL-адреса иногда используются для аутентификации пользователей. Службы обмена документами, такие как предлагаемые Google и Dropbox, также работают, отправляя пользователю токен безопасности, который включен в URL-адрес. Злоумышленник, получивший такие URL-адреса, может получить полный доступ к учетной записи или данным жертвы.
Эксплойт работает практически против всех браузеров и операционных систем.
атака Sweet32
Атака Sweet32 взламывает все 64-битные блочные шифры, используемые в режиме CBC, как и в TLS, эксплуатируя атаку дня рождения и либо атаку «человек посередине» , либо инъекцию вредоносного JavaScript в веб-страницу. Цель атаки «человек посередине» или инъекции JavaScript — позволить злоумышленнику захватить достаточно трафика для проведения атаки дня рождения. [148]
Ошибка Heartbleed — это серьезная уязвимость, характерная для реализации SSL/TLS в популярной криптографической программной библиотеке OpenSSL , затрагивающая версии 1.0.1–1.0.1f. Эта уязвимость, о которой сообщили в апреле 2014 года, позволяет злоумышленникам красть закрытые ключи с серверов, которые обычно должны быть защищены. [149] Ошибка Heartbleed позволяет любому человеку в Интернете читать память систем, защищенных уязвимыми версиями программного обеспечения OpenSSL. Это ставит под угрозу секретные закрытые ключи, связанные с открытыми сертификатами, используемыми для идентификации поставщиков услуг и шифрования трафика, имен и паролей пользователей и фактического контента. Это позволяет злоумышленникам прослушивать коммуникации, красть данные напрямую из служб и пользователей и выдавать себя за службы и пользователей. [150] Уязвимость вызвана ошибкой перечитывания буфера в программном обеспечении OpenSSL, а не дефектом в спецификации протокола SSL или TLS.
В сентябре 2014 года компания Intel Security Advanced Threat Research объявила о варианте уязвимости Daniel Bleichenbacher PKCS#1 v1.5 RSA Signature Forgery [151] . Эта атака, получившая название BERserk, является результатом неполного декодирования длины ASN.1 подписей открытого ключа в некоторых реализациях SSL и позволяет провести атаку «человек посередине» путем подделки подписи открытого ключа. [152]
В феврале 2015 года, после того как СМИ сообщили о скрытой предварительной установке рекламного ПО Superfish на некоторых ноутбуках Lenovo, [153] исследователь обнаружил, что доверенный корневой сертификат на затронутых машинах Lenovo небезопасен, поскольку к ключам можно было легко получить доступ, используя название компании Komodia в качестве парольной фразы. [154] Библиотека Komodia была разработана для перехвата клиентского трафика TLS/SSL для родительского контроля и наблюдения, но она также использовалась в многочисленных программах рекламного ПО, включая Superfish, которые часто тайно устанавливались без ведома пользователя компьютера. В свою очередь, эти потенциально нежелательные программы устанавливали поврежденный корневой сертификат, позволяя злоумышленникам полностью контролировать веб-трафик и подтверждать подлинность ложных веб-сайтов.
В мае 2016 года сообщалось, что десятки датских веб-сайтов, защищенных HTTPS и принадлежащих Visa Inc., были уязвимы для атак, позволяющих хакерам внедрять вредоносный код и поддельный контент в браузеры посетителей. [155] Атаки срабатывали, поскольку реализация TLS, используемая на затронутых серверах, неправильно повторно использовала случайные числа ( nonces ), которые должны использоваться только один раз, гарантируя уникальность каждого рукопожатия TLS. [155]
В феврале 2017 года ошибка реализации, вызванная одним неправильно набранным символом в коде, используемом для разбора HTML, создала ошибку переполнения буфера на серверах Cloudflare . Похожая по своим последствиям на ошибку Heartbleed, обнаруженную в 2014 году, эта ошибка переполнения, широко известная как Cloudbleed , позволяла неавторизованным третьим лицам считывать данные в памяти программ, работающих на серверах, — данные, которые в противном случае должны были быть защищены TLS. [156]
Обзор веб-сайтов, уязвимых для атак
По состоянию на июль 2021 года [обновлять]Движение за доверие к Интернету оценило долю веб-сайтов, уязвимых для атак TLS. [92]
Прямая секретность
Прямая секретность — это свойство криптографических систем, которое гарантирует, что сеансовый ключ, полученный из набора открытых и закрытых ключей, не будет скомпрометирован, если один из закрытых ключей будет скомпрометирован в будущем. [157] Без прямой секретности, если закрытый ключ сервера скомпрометирован, будут скомпрометированы не только все будущие сеансы, зашифрованные TLS, использующие этот сертификат сервера, но и любые прошлые сеансы, которые его использовали (при условии, что эти прошлые сеансы были перехвачены и сохранены во время передачи). [158] Реализация TLS может обеспечить прямую секретность, требуя использования эфемерного обмена ключами Диффи-Хеллмана для установления сеансовых ключей, и некоторые известные реализации TLS делают это исключительно: например, Gmail и другие службы Google HTTPS, которые используют OpenSSL . [159] Однако многие клиенты и серверы, поддерживающие TLS (включая браузеры и веб-серверы), не настроены на реализацию таких ограничений. [160] [161] На практике, если веб-сервис не использует обмен ключами Диффи-Хеллмана для реализации прямой секретности, весь зашифрованный веб-трафик к этому сервису и от него может быть расшифрован третьей стороной, если она получит главный (закрытый) ключ сервера; например, с помощью постановления суда. [162]
Даже там, где реализован обмен ключами Диффи-Хеллмана, механизмы управления сеансом на стороне сервера могут повлиять на прямую секретность. Использование билетов сеанса TLS (расширение TLS) приводит к тому, что сеанс защищается AES128-CBC-SHA256 независимо от любых других согласованных параметров TLS, включая наборы шифров прямой секретности, а долгоживущие ключи билетов сеанса TLS сводят на нет попытку реализовать прямую секретность. [163] [164] [165] Исследование Стэнфордского университета в 2014 году также показало, что из 473 802 обследованных серверов TLS 82,9% серверов, развертывающих эфемерный обмен ключами Диффи-Хеллмана (DHE) для поддержки прямой секретности, использовали слабые параметры Диффи-Хеллмана. Такой слабый выбор параметров может потенциально поставить под угрозу эффективность прямой секретности, которую серверы стремились обеспечить. [166]
С конца 2011 года Google по умолчанию предоставляет прямую секретность с TLS пользователям своего сервиса Gmail , а также Google Docs и зашифрованного поиска, среди прочих сервисов. [167]
С ноября 2013 года Twitter предоставляет прямую секретность с TLS пользователям своего сервиса. [168] По состоянию на август 2019 года [обновлять]около 80% веб-сайтов с поддержкой TLS настроены на использование наборов шифров, которые обеспечивают прямую секретность для большинства веб-браузеров. [92]
Перехват TLS
Перехват TLS (или перехват HTTPS , если применяется конкретно к этому протоколу) — это практика перехвата зашифрованного потока данных с целью его расшифровки, чтения и, возможно, манипулирования, а затем повторного шифрования и отправки данных по его пути. Это делается с помощью « прозрачного прокси »: программное обеспечение перехвата прерывает входящее соединение TLS, проверяет открытый текст HTTP, а затем создает новое соединение TLS с пунктом назначения. [169]
Перехват TLS/HTTPS используется сетевыми операторами в качестве меры информационной безопасности для того, чтобы иметь возможность сканировать и защищать от проникновения вредоносного контента в сеть, такого как компьютерные вирусы и другие вредоносные программы . [169] В противном случае такой контент не мог бы быть обнаружен, если бы он был защищен шифрованием, что все чаще происходит в результате повседневного использования HTTPS и других защищенных протоколов.
Существенным недостатком перехвата TLS/HTTPS является то, что он сам по себе вносит новые риски безопасности. Одним из заметных ограничений является то, что он предоставляет точку, в которой сетевой трафик доступен в незашифрованном виде, что дает злоумышленникам стимул атаковать эту точку, в частности, чтобы получить доступ к защищенному контенту. Перехват также позволяет оператору сети или лицам, которые получают доступ к его системе перехвата, выполнять атаки типа «человек посередине» против пользователей сети. Исследование 2017 года показало, что «перехват HTTPS стал поразительно распространенным, и что продукты перехвата как класс оказывают резко отрицательное влияние на безопасность соединения». [169]
Подробности протокола
Протокол 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 выбирать не следует.
Сервер отправляет свое сообщение сертификата (в зависимости от выбранного набора шифров это может быть пропущено сервером). [170]
Сервер отправляет свое сообщение ServerKeyExchange (в зависимости от выбранного набора шифров, это может быть пропущено сервером). Это сообщение отправляется для всех наборов шифров DHE , ECDHE и DH_anon. [23]
Сервер отправляет сообщение ServerHelloDone , указывающее на завершение согласования.
Клиент отвечает сообщением ClientKeyExchange , которое может содержать PreMasterSecret , открытый ключ или ничего. (Опять же, это зависит от выбранного шифра.) Этот PreMasterSecret шифруется с использованием открытого ключа сертификата сервера.
Затем клиент и сервер используют случайные числа и PreMasterSecret для вычисления общего секрета, называемого «главным секретом». Все остальные ключевые данные ( сеансовые ключи , такие как IV , симметричный ключ шифрования , ключ MAC [171] ) для этого соединения выводятся из этого главного секрета (и случайных значений, сгенерированных клиентом и сервером), который передается через тщательно разработанную псевдослучайную функцию.
Теперь клиент отправляет запись ChangeCipherSpec , по сути сообщая серверу: «Все, что я вам скажу с этого момента, будет аутентифицировано (и зашифровано, если параметры шифрования присутствовали в сертификате сервера)». ChangeCipherSpec сам по себе является протоколом уровня записи с типом содержимого 20.
Клиент отправляет аутентифицированное и зашифрованное сообщение Finished , содержащее хэш и MAC-адрес предыдущих сообщений о рукопожатии.
Сервер попытается расшифровать сообщение Finished клиента и проверить хэш и MAC. Если расшифровка или проверка не удались, рукопожатие считается неудавшимся и соединение должно быть разорвано.
Наконец, сервер отправляет ChangeCipherSpec , сообщая клиенту: «Все, что я тебе скажу с этого момента, будет аутентифицировано (и зашифровано, если шифрование было согласовано)».
Сервер отправляет аутентифицированное и зашифрованное сообщение Finished .
Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем этапе.
Фаза приложения: на этом этапе "рукопожатие" завершено и протокол приложения включен с типом содержимого 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут аутентифицированы и опционально зашифрованы точно так же, как в их сообщении Finished . В противном случае тип содержимого вернет 25, и клиент не будет аутентифицирован.
TLS-рукопожатие с аутентификацией клиента
В следующем полном примере показана аутентификация клиента (в дополнение к серверу, как в примере выше; см. взаимную аутентификацию ) через TLS с использованием сертификатов, которыми обмениваются оба одноранговых узла.
Фаза переговоров:
Клиент отправляет сообщение ClientHello , в котором указывает самую высокую версию протокола TLS, которую он поддерживает, случайное число, список предлагаемых наборов шифров и методов сжатия.
Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Сервер также может отправить идентификатор сеанса как часть сообщения для выполнения возобновленного рукопожатия.
Сервер отправляет свое сообщение сертификата (в зависимости от выбранного набора шифров это может быть пропущено сервером). [170]
Сервер отправляет свое сообщение ServerKeyExchange (в зависимости от выбранного набора шифров, это может быть пропущено сервером). Это сообщение отправляется для всех наборов шифров DHE, ECDHE и DH_anon. [1]
Сервер отправляет сообщение CertificateRequest , чтобы запросить сертификат у клиента.
Сервер отправляет сообщение ServerHelloDone , указывающее на завершение согласования.
Клиент отвечает сообщением Certificate , которое содержит сертификат клиента, но не его закрытый ключ.
Клиент отправляет сообщение ClientKeyExchange , которое может содержать PreMasterSecret , открытый ключ или ничего. (Опять же, это зависит от выбранного шифра.) Этот PreMasterSecret шифруется с использованием открытого ключа сертификата сервера.
Клиент отправляет сообщение CertificateVerify , которое является подписью предыдущих сообщений о рукопожатии с использованием закрытого ключа сертификата клиента. Эту подпись можно проверить с помощью открытого ключа сертификата клиента. Это позволяет серверу узнать, что клиент имеет доступ к закрытому ключу сертификата и, таким образом, владеет сертификатом.
Затем клиент и сервер используют случайные числа и PreMasterSecret для вычисления общего секрета, называемого «главным секретом». Все остальные ключевые данные («ключи сеанса») для этого соединения выводятся из этого главного секрета (и случайных значений, сгенерированных клиентом и сервером), который передается через тщательно разработанную псевдослучайную функцию.
Теперь клиент отправляет запись ChangeCipherSpec , по сути сообщая серверу: «Все, что я вам скажу с этого момента, будет аутентифицировано (и зашифровано, если шифрование было согласовано). ChangeCipherSpec сам по себе является протоколом уровня записи и имеет тип 20, а не 22.
Наконец, клиент отправляет зашифрованное сообщение Finished , содержащее хэш и MAC-адрес предыдущих сообщений о рукопожатии.
Сервер попытается расшифровать сообщение Finished клиента и проверить хэш и MAC. Если расшифровка или проверка не удались, рукопожатие считается неудавшимся и соединение должно быть разорвано.
Наконец, сервер отправляет ChangeCipherSpec , сообщая клиенту: «Все, что я тебе скажу с этого момента, будет аутентифицировано (и зашифровано, если шифрование было согласовано)».
Сервер отправляет собственное зашифрованное сообщение Finished .
Клиент выполняет ту же процедуру расшифровки и проверки, что и сервер на предыдущем этапе.
Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом содержимого 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут зашифрованы точно так же, как и в их готовом сообщении.
Возобновлено рукопожатие TLS
Операции с открытым ключом (например, RSA) относительно дороги с точки зрения вычислительной мощности. TLS обеспечивает безопасный ярлык в механизме рукопожатия, чтобы избежать этих операций: возобновленные сеансы. Возобновленные сеансы реализуются с использованием идентификаторов сеансов или билетов сеансов.
Помимо повышения производительности, возобновленные сеансы также могут использоваться для единого входа , поскольку это гарантирует, что как исходный сеанс, так и любой возобновленный сеанс происходят от одного и того же клиента. Это имеет особое значение для протокола FTP через TLS/SSL , который в противном случае пострадал бы от атаки типа «человек посередине», в которой злоумышленник мог бы перехватить содержимое вторичных соединений данных. [172]
Рукопожатие TLS 1.3
Подтверждение TLS 1.3 было сокращено до одного кругового обмена по сравнению с двумя круговыми обменами, которые требовались в предыдущих версиях TLS/SSL.
Чтобы начать рукопожатие, клиент угадывает, какой алгоритм обмена ключами будет выбран сервером, и отправляет сообщение ClientHello на сервер, содержащее список поддерживаемых шифров (в порядке предпочтений клиента) и открытые ключи для некоторых или всех его предположений обмена ключами. Если клиент успешно угадывает алгоритм обмена ключами, 1 круговой обход исключается из рукопожатия. После получения ClientHello сервер выбирает шифр и отправляет обратно ServerHello со своим собственным открытым ключом, за которым следуют сообщения Certificate и Finished сервера . [173]
После того, как клиент получает готовое сообщение сервера, он координирует с сервером, какой набор шифров использовать. [174]
Идентификаторы сеансов
При обычном полном рукопожатии сервер отправляет идентификатор сеанса как часть сообщения ServerHello . Клиент связывает этот идентификатор сеанса с IP-адресом сервера и портом TCP, так что когда клиент снова подключается к этому серверу, он может использовать идентификатор сеанса для сокращения рукопожатия. На сервере идентификатор сеанса сопоставляется с ранее согласованными криптографическими параметрами, в частности с «главным секретом». Обе стороны должны иметь один и тот же «главный секрет», иначе возобновленное рукопожатие не удастся (это не позволяет перехватчику использовать идентификатор сеанса ). Случайные данные в сообщениях ClientHello и ServerHello фактически гарантируют, что сгенерированные ключи соединения будут отличаться от ключей в предыдущем соединении. В RFC этот тип рукопожатия называется сокращенным рукопожатием. В литературе он также описывается как рукопожатие перезапуска .
Фаза переговоров:
Клиент отправляет сообщение ClientHello , в котором указывается наивысшая поддерживаемая им версия протокола TLS, случайное число, список предлагаемых наборов шифров и методов сжатия. В сообщение включен идентификатор сеанса из предыдущего соединения TLS.
Сервер отвечает сообщением ServerHello , содержащим выбранную версию протокола, случайное число, набор шифров и метод сжатия из вариантов, предложенных клиентом. Если сервер распознает идентификатор сеанса , отправленный клиентом, он отвечает тем же идентификатором сеанса . Клиент использует это, чтобы распознать, что выполняется возобновленное рукопожатие. Если сервер не распознает идентификатор сеанса, отправленный клиентом, он отправляет другое значение для своего идентификатора сеанса . Это сообщает клиенту, что возобновленное рукопожатие не будет выполнено. На этом этапе и клиент, и сервер имеют «главный секрет» и случайные данные для генерации ключевых данных, которые будут использоваться для этого соединения.
Теперь сервер отправляет запись ChangeCipherSpec , по сути говоря клиенту: «Все, что я тебе скажу с этого момента, будет зашифровано». ChangeCipherSpec сам по себе является протоколом уровня записи и имеет тип 20, а не 22.
Наконец, сервер отправляет зашифрованное сообщение Finished , содержащее хэш и MAC-адрес предыдущих сообщений о рукопожатии.
Клиент попытается расшифровать сообщение Finished сервера и проверить хэш и MAC. Если расшифровка или проверка не удались, рукопожатие считается неудавшимся и соединение должно быть разорвано.
Наконец, клиент отправляет ChangeCipherSpec , сообщая серверу: «Все, что я тебе скажу с этого момента, будет зашифровано».
Клиент отправляет собственное зашифрованное сообщение Finished .
Сервер выполняет ту же процедуру расшифровки и проверки, что и клиент на предыдущем этапе.
Фаза приложения: на этом этапе «рукопожатие» завершено и протокол приложения включен с типом содержимого 23. Сообщения приложения, которыми обмениваются клиент и сервер, также будут зашифрованы точно так же, как и в их готовом сообщении.
Билеты на сеанс
RFC 5077 расширяет TLS посредством использования сеансовых билетов вместо идентификаторов сеансов. Он определяет способ возобновления сеанса TLS без необходимости сохранения состояния сеанса на сервере TLS.
При использовании билетов сеанса сервер TLS сохраняет свое состояние, специфичное для сеанса, в билете сеанса и отправляет билет сеанса клиенту TLS для сохранения. Клиент возобновляет сеанс TLS, отправляя билет сеанса серверу, а сервер возобновляет сеанс TLS в соответствии с состоянием, специфичным для сеанса, в билете. Билет сеанса шифруется и аутентифицируется сервером, и сервер проверяет его действительность перед использованием его содержимого.
Одной из особых слабостей этого метода с OpenSSL является то, что он всегда ограничивает безопасность шифрования и аутентификации переданного билета сеанса TLS до AES128-CBC-SHA256, независимо от того, какие другие параметры TLS были согласованы для фактического сеанса TLS. [164] Это означает, что информация о состоянии (билет сеанса TLS) не так хорошо защищена, как сам сеанс TLS. Особую озабоченность вызывает хранение ключей OpenSSL в контексте всего приложения ( SSL_CTX), т. е. на протяжении всего срока службы приложения, и невозможность повторного ввода ключей билетов AES128-CBC-SHA256сеанса TLS без сброса контекста OpenSSL всего приложения (что встречается редко, подвержено ошибкам и часто требует ручного административного вмешательства). [165] [163]
TLS-запись
Это общий формат всех записей TLS.
Тип контента
В этом поле определяется тип протокола уровня записи, содержащийся в этой записи.
Устаревшая версия
Это поле определяет основную и дополнительную версию TLS до TLS 1.3 для содержащегося сообщения. Для сообщения ClientHello это не обязательно должна быть самая высокая версия, поддерживаемая клиентом. Для TLS 1.3 и более поздних версий это должно быть установлено как 0x0303, и приложение должно отправлять поддерживаемые версии в дополнительном блоке расширения сообщения.
Длина
Длина полей «сообщение(я) протокола», «MAC» и «заполнение» вместе (т.е. q −5) не должна превышать 2 14 байт (16 КиБ).
Протокольное сообщение(я)
Одно или несколько сообщений, идентифицированных полем Протокол. Обратите внимание, что это поле может быть зашифровано в зависимости от состояния соединения.
MAC и заполнение
Код аутентификации сообщения , вычисленный по полю "protocol message(s)", с включенным дополнительным ключевым материалом. Обратите внимание, что это поле может быть зашифровано или не включено полностью, в зависимости от состояния соединения.
Поля «MAC» или «padding» не могут присутствовать в конце записей TLS до тех пор, пока все алгоритмы шифрования и параметры не будут согласованы и подвергнуты рукопожатию, а затем подтверждены путем отправки записи CipherStateChange (см. ниже) для оповещения о том, что эти параметры вступят в силу во всех последующих записях, отправляемых тем же одноранговым узлом.
Протокол рукопожатия
Большинство сообщений, которыми обмениваются во время настройки сеанса TLS, основаны на этой записи, если только не возникает ошибка или предупреждение, о которых необходимо сообщить с помощью записи протокола Alert (см. ниже), или режим шифрования сеанса не изменяется другой записью (см. протокол ChangeCipherSpec ниже).
Тип сообщения
Это поле определяет тип сообщения о рукопожатии.
Длина данных сообщения рукопожатия
Это 3-байтовое поле, указывающее длину данных рукопожатия, не включая заголовок.
Обратите внимание, что несколько сообщений о рукопожатии могут быть объединены в одну запись.
Протокол оповещения
Эта запись обычно не должна отправляться во время обычного рукопожатия или обмена приложениями. Однако это сообщение может быть отправлено в любое время во время рукопожатия и до закрытия сеанса. Если это используется для сигнализации о фатальной ошибке, сеанс будет закрыт немедленно после отправки этой записи, поэтому эта запись используется для указания причины этого закрытия. Если уровень оповещения помечен как предупреждение, удаленный компьютер может решить закрыть сеанс, если он решит, что сеанс недостаточно надежен для его нужд (прежде чем сделать это, удаленный компьютер может также отправить свой собственный сигнал).
Уровень
Это поле определяет уровень оповещения. Если уровень фатальный, отправитель должен немедленно закрыть сеанс. В противном случае получатель может решить завершить сеанс самостоятельно, отправив собственное фатальное оповещение и закрыв сеанс сразу после его отправки. Использование записей оповещений необязательно, однако, если он отсутствует до закрытия сеанса, сеанс может быть возобновлен автоматически (с его рукопожатиями).
Обычное закрытие сеанса после завершения транспортируемого приложения желательно оповещать как минимум с типом оповещения Close notify (с простым уровнем предупреждения), чтобы предотвратить такое автоматическое возобновление нового сеанса. Явное оповещение о нормальном закрытии защищенного сеанса перед фактическим закрытием его транспортного уровня полезно для предотвращения или обнаружения атак (например, попыток усечения безопасно транспортируемых данных, если они по своей сути не имеют предопределенной длины или длительности, которую может ожидать получатель защищенных данных).
Описание
В этом поле указывается тип отправляемого оповещения.
Протокол ChangeCipherSpec
Тип протокола CCS
В настоящее время только 1.
Протокол приложения
Длина
Длина данных приложения (исключая заголовок протокола и включая MAC и завершающие заполнения)
МАК
32 байта для HMAC на основе SHA-256 , 20 байт для HMAC на основе SHA-1 , 16 байт для HMAC на основе MD5 .
Прокладка
Переменная длина; последний байт содержит длину заполнения.
Поддержка виртуальных серверов на основе имен
С точки зрения протокола приложения TLS принадлежит к нижнему уровню, хотя модель TCP/IP слишком груба, чтобы это показать. Это означает, что рукопожатие TLS обычно (за исключением случая STARTTLS ) выполняется до того, как может начаться протокол приложения. В функции виртуального сервера на основе имени, предоставляемой уровнем приложения, все совместно размещенные виртуальные серверы совместно используют один и тот же сертификат, поскольку сервер должен выбрать и отправить сертификат сразу после сообщения ClientHello. Это большая проблема в средах хостинга, поскольку это означает либо совместное использование одного и того же сертификата среди всех клиентов, либо использование разных IP-адресов для каждого из них.
Существуют два известных обходных пути, предоставляемых X.509 :
Если все виртуальные серверы принадлежат к одному домену, можно использовать wildcard-сертификат . [175] Помимо свободного выбора имени хоста, который может быть проблемой или нет, нет общего соглашения о том, как сопоставлять wildcard-сертификаты. Применяются различные правила в зависимости от протокола приложения или используемого программного обеспечения. [176]
Добавьте каждое имя виртуального хоста в расширение subjectAltName. Основная проблема в том, что сертификат необходимо перевыпускать каждый раз, когда добавляется новый виртуальный сервер.
Чтобы предоставить имя сервера, RFC 4366 Transport Layer Security (TLS) Extensions позволяет клиентам включать расширение Server Name Indication (SNI) в расширенное сообщение ClientHello. Это расширение немедленно подсказывает серверу, к какому имени клиент хочет подключиться, поэтому сервер может выбрать соответствующий сертификат для отправки клиентам.
RFC 2817 также документирует метод реализации виртуального хостинга на основе имени путем обновления HTTP до TLS через заголовок обновления HTTP/1.1 . Обычно это делается для безопасной реализации HTTP поверх TLS в рамках основной схемы URI "http" (что позволяет избежать разветвления пространства URI и сокращает количество используемых портов), однако в настоящее время лишь немногие реализации поддерживают это. [ необходима цитата ]
QUIC (Quick UDP Internet Connections) – «…был разработан для обеспечения защиты, эквивалентной TLS/SSL»; основная цель QUIC – улучшить воспринимаемую производительность веб-приложений, ориентированных на соединение, которые в настоящее время используют TCP
^ ie "Делегированные полномочия для (D)TLS". Ietf . Архивировано из оригинала 2024-06-26 . Получено 2024-06-26 .
^ ab Lawrence, Scott; Khare, Rohit (май 2000 г.). Обновление до TLS в HTTP/1.1. Internet Engineering Task Force. doi : 10.17487/RFC2817 . RFC 2817.
^ "SSL/TLS in Detail". TechNet . Microsoft Docs . 8 октября 2009 г. Архивировано из оригинала 2022-08-13 . Получено 2021-10-24 .
^ ab Hooper, Howard (2012). CCNP Security VPN 642–648 Official Cert Guide (2-е изд.). Cisco Press. стр. 22. ISBN9780132966382.
^ ab Spott, Andrew; Leek, Tom; et al. «Какой уровень — TLS?». Information Security Stack Exchange . Архивировано из оригинала 2021-02-13 . Получено 2017-04-13 .
^ abcdef E. Rescorla (август 2018 г.). Протокол Transport Layer Security (TLS) версии 1.3. Рабочая группа IETF TLS. doi : 10.17487/RFC8446 . RFC 8446.Предложенный стандарт. Отменяет RFC 5077, 5246 и 6961; обновляет RFC 5705 и 6066.
^ Рескорла, Эрик; Модадугу, Нагендра (апрель 2006 г.). Безопасность транспортного уровня дейтаграмм. дои : 10.17487/RFC4347 . РФК 4347.
^ Рескорла, Эрик; Модадугу, Нагендра (январь 2012 г.). Безопасность дейтаграммного транспортного уровня версии 1.2. дои : 10.17487/RFC6347 . РФК 6347.
^ Хонда, Осаму; Охсаки, Хироюки; Имасе, Макото; Ишизука, Мика; Мураяма, Дзюнъити (октябрь 2005 г.). «Понимание TCP через TCP: влияние туннелирования TCP на сквозную пропускную способность и задержку». В Atiquzzaman, Mohammed; Баландин, Сергей I (ред.). Производительность, качество обслуживания и управление сетями связи и датчиков следующего поколения III . Том 6011. Bibcode : 2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . doi : 10.1117/12.630496. S2CID 8945952.
^ RFC 4347 § 4
^ Рескорла, Эрик; Чофениг, Ханнес; Модадугу, Нагена (21 апреля 2022 г.). Протокол Datagram Transport Layer Security (DTLS) версии 1.3. doi : 10.17487/RFC9147 . RFC 9147.
^ "AnyConnect FAQ: туннели, поведение повторного подключения и таймер бездействия". Cisco . Архивировано из оригинала 26 февраля 2017 г. . Получено 26 февраля 2017 г. .
^ "Обзор архитектуры Cisco InterCloud" (PDF) . Cisco Systems . Архивировано (PDF) из оригинала 2022-08-09 . Получено 2022-11-29 .
^ "OpenConnect". OpenConnect . Архивировано из оригинала 2 февраля 2017 . Получено 26 февраля 2017 .
^ "f5 Datagram Transport Layer Security (DTLS)". f5 Networks . Архивировано из оригинала 2022-11-29 . Получено 2022-11-29 .
^ "Настройка виртуального сервера DTLS". Citrix Systems . Архивировано из оригинала 2016-12-21 . Получено 2022-11-29 .
^ "WebRTC Interop Notes". Архивировано из оригинала 2013-05-11.
^ abcde Брайт, Питер (17 октября 2018 г.). «Apple, Google, Microsoft и Mozilla объединяются, чтобы положить конец TLS 1.0». Архивировано из оригинала 17 октября 2018 г. Получено 17 октября 2018 г.
^ abcd «Вот что нового и измененного в Firefox 74.0 Stable – gHacks Tech News». www.ghacks.net . 10 марта 2020 г. Архивировано из оригинала 2020-03-11 . Получено 2020-03-10 .
^ abcd "TLS 1.0 и TLS 1.1 – Статус платформы Chrome". chromestatus.com . Архивировано из оригинала 2023-07-07 . Получено 2020-03-10 .
^ abcde T. Dierks; E. Rescorla (август 2008 г.). Протокол Transport Layer Security (TLS) версии 1.2. Рабочая группа IETF TLS. doi : 10.17487/RFC5246 . RFC 5246.Устарело. Устарело из-за RFC 8446; делает устаревшими RFC 3268, 4346 и 4366; обновляет RFC 4492.
^ ab "Использование TLS для защиты данных". www.ncsc.gov.uk . Архивировано из оригинала 21 июля 2021 г. . Получено 24 августа 2022 г. .
^ "TLS 1.3: One Year Later". IETF . Архивировано из оригинала 8 июля 2020 г. Получено 24 августа 2022 г.
^ "Создание TLS: новаторская роль Рут Нельсон". Архивировано из оригинала 2020-06-24 . Получено 2020-07-04 .
^ Woo, Thomas YC; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (июнь 1994 г.). SNP: Интерфейс для безопасного сетевого программирования (PDF) . Труды летней технической конференции USENIX. Архивировано (PDF) из оригинала 2014-12-12 . Получено 2023-07-05 .
^ "Программа летней технической конференции USENIX 1994 года, Бостон, 6–10 июня 1994 года". Архивировано из оригинала 6 октября 2023 года . Получено 21 января 2024 года .
^ Саймон С. Лэм (PI/PD), «Применение теории модулей и интерфейсов к проверке безопасности», грант исследовательской программы NSA INFOSEC University № MDA 904-91-C-7046, с 28.06.91 по 27.06.93.
^ "2004 ACM Software System Award citation". ACM . Архивировано из оригинала 17 июня 2013 года . Получено 25 июля 2012 года .
^ "ACM Press Release, 15 марта 2005 г.". ACM . Архивировано из оригинала 10 января 2016 г. Получено 25 июля 2012 г.
^ "Включенный в Зал славы Интернета Саймон С. Лэм". Архивировано из оригинала 6 февраля 2024 года . Получено 3 марта 2024 года .
^ "Computer Scientist Induced into Internet Hall of Fame". Архивировано из оригинала 8 марта 2024 года . Получено 3 марта 2024 года .
^ Мессмер, Эллен. «Отец SSL, доктор Тахер Элгамал, находит быстроразвивающиеся ИТ-проекты на Ближнем Востоке». Network World . Архивировано из оригинала 31 мая 2014 г. Получено 30 мая 2014 г.
^ Грин, Тим. «Отец SSL говорит, что, несмотря на атаки, у стержня безопасности еще много жизни». Network World . Архивировано из оригинала 31 мая 2014 г. Получено 30 мая 2014 г.
^ ab Oppliger, Rolf (2016). "Введение". SSL и TLS: Теория и практика (2-е изд.). Artech House . стр. 13. ISBN978-1-60807-999-5. Получено 01.03.2018 – через Google Books.
^ "ПРОТОКОЛ SSL". Netscape Corporation. 2007. Архивировано из оригинала 14 июня 1997 года.
^ Рескорла 2001
^ "POODLE: Уязвимость SSLv3 (CVE-2014-3566)". Архивировано из оригинала 5 декабря 2014 г. Получено 21 октября 2014 г.
^ "Стандарты безопасности и изменения названий в войнах браузеров". Архивировано из оригинала 29.02.2020 . Получено 29.02.2020 .
^ «Изменения в соответствии с PCI ожидаются 30 июня. Готов ли ваш бизнес в сфере электронной коммерции?». Forbes . Архивировано из оригинала 21.06.2018 . Получено 20.06.2018 .
^ T. Dierks; E. Rescorla (апрель 2006 г.). Протокол Transport Layer Security (TLS) версии 1.1. Рабочая группа IETF TLS. doi : 10.17487/RFC4346 . RFC 4346.Исторический. Устарело из-за RFC 5246. Устаревший RFC 2246.
^ abc "Параметры безопасности транспортного уровня – Наборы шифров". Internet Assigned Numbers Authority (IANA) . Архивировано из оригинала 2016-12-21 . Получено 2022-12-16 .
^ Mackie, Kurt. "Microsoft откладывает прекращение поддержки TLS 1.0 и 1.1 -". Microsoft Certified Professional Magazine Online . Архивировано из оригинала 2021-06-14 . Получено 2021-06-14 .
^ "TLS 1.2 FAQ – База знаний". Answers.psionline.com . Архивировано из оригинала 20 февраля 2022 г. . Получено 20 февраля 2022 г. .
^ "Различия между TLS 1.2 и TLS 1.3 (#TLS13)". WolfSSL . 2019-09-18. Архивировано из оригинала 2019-09-19 . Получено 2019-09-18 .
^ "NSS 3.29 release notes". Mozilla Developer Network. Февраль 2017. Архивировано из оригинала 22.02.2017.
^ "Включить TLS 1.3 по умолчанию". Bugzilla@Mozilla. 16 октября 2016 г. Архивировано из оригинала 12 августа 2018 г. Получено 10 октября 2017 г.
^ "Firefox — Notes (60.0)". Mozilla . Архивировано из оригинала 2018-05-09 . Получено 2018-05-10 .
^ "ProxySG, ASG и WSS будут прерывать SSL-соединения, когда клиенты, использующие TLS 1.3, получают доступ к сайтам, также использующим TLS 1.3". BlueTouch Online . 16 мая 2017 г. Архивировано из оригинала 12 сентября 2017 г. Получено 11 сентября 2017 г.
^ Салливан, Ник (2017-12-26). "Почему TLS 1.3 пока нет в браузерах". Блог Cloudflare . Архивировано из оригинала 2017-12-26 . Получено 2020-03-14 .
^ ab Томсон, Мартин; Поли, Томми (декабрь 2021 г.). Долгосрочная жизнеспособность механизмов расширения протоколов. doi : 10.17487/RFC9170 . RFC 9170.
^ "TLS 1.3 IETF 100 Hackathon". Архивировано из оригинала 2018-01-15.
^ ab IETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, архивировано из оригинала 2021-10-28 , извлечено 2017-11-14
^ "Ура! TLS 1.3 уже здесь. Теперь осталось внедрить его и поместить в программное обеспечение". Архивировано из оригинала 2018-03-27 . Получено 2018-03-28 .
^ IETF – Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, заархивировано из оригинала 2021-10-28 , извлечено 2018-07-18
^ "wolfSSL TLS 1.3 BETA Release Now Available". [email protected]. 11 мая 2017 г. Архивировано из оригинала 9 июля 2018 г. Получено 11 мая 2017 г.
^ "TLS 1.3 Draft 28 Support in wolfSSL". [email protected]. 14 июня 2018 г. Архивировано из оригинала 9 июля 2018 г. Получено 14 июня 2018 г.
^ "OpenSSL 1.1.1 выпущен". Мэтт Касвелл. 11 сентября 2018 г. Архивировано из оригинала 8 декабря 2018 г. Получено 11 октября 2024 г.
^ "Протоколы в TLS/SSL (Schannel SSP)". Microsoft Docs . 25 мая 2022 г. Архивировано из оригинала 25 января 2023 г. Получено 21 февраля 2023 г.
^ ab Хоффман-Эндрюс, Джейкоб (2019-02-26). "ETS Isn't TLS and You Shouldn't Use It". Electronic Frontier Foundation . Архивировано из оригинала 2019-02-26 . Получено 2019-02-27 .
^ TS 103 523-3 – V1.1.1 – CYBER; Протокол безопасности промежуточных узлов; Часть 3: Профиль для управления доступом к корпоративной сети и центру обработки данных ( PDF ) . ETSI .org. Архивировано (PDF) из оригинала 14 ноября 2018 г.
^ Кори Доктороу (26 февраля 2019 г.). "Monumental Recklessness". Boing Boing . Архивировано из оригинала 27 февраля 2019 г.
^ Rea, Scott (2013). «Альтернативы центрам сертификации для безопасного Интернета» (PDF) . Конференция RSA Asia Pacific. Архивировано (PDF) из оригинала 7 октября 2016 г. . Получено 7 сентября 2016 г. .
^ "Подсчет SSL-сертификатов". Архивировано из оригинала 16 мая 2015 г. Получено 20 февраля 2022 г.
^ Рэймонд, Арт (3 августа 2017 г.). «DigiCert компании Lehi поглощает конкурента по веб-безопасности за 1 миллиард долларов». Deseret News . Архивировано из оригинала 29 сентября 2018 г. Получено 21 мая 2020 г.
^ "Тенденции доли рынка для центров сертификации SSL". W3Techs . Получено 21 мая 2020 г. .
↑ Райан Сингель (24 марта 2010 г.). «Устройства правоохранительных органов подрывают SSL». wired .com . Архивировано из оригинала 12 апреля 2014 г.
^ Сет Шен (24 марта 2010 г.). «Новые исследования предполагают, что правительства могут подделывать SSL-сертификаты». EFF .org . Архивировано из оригинала 25 марта 2010 г.
^ P. Eronen, Ed. (декабрь 2005 г.). Eronen, P; Tschofenig, H (ред.). Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. doi : 10.17487/RFC4279 . RFC 4279 . Получено 9 сентября 2013 г. .
^ D. Taylor, Ed. (ноябрь 2007 г.). Использование протокола Secure Remote Password (SRP) для аутентификации TLS. Internet Engineering Task Force. doi : 10.17487/RFC5054 . RFC 5054 . Получено 21 декабря 2014 г. .
^ Gothard, Peter (31 июля 2013 г.). «Google обновляет сертификаты SSL до 2048-битного шифрования». Computing . Incisive Media. Архивировано из оригинала 22 сентября 2013 г. . Получено 9 сентября 2013 г. .
^ "Значение 2048-битного шифрования: почему длина ключа шифрования имеет значение". SearchSecurity . Архивировано из оригинала 2018-01-16 . Получено 2017-12-18 .
^ Шон Тернер (17 сентября 2015 г.). «Консенсус: удалить DSA из TLS 1.3». Архивировано из оригинала 3 октября 2015 г.
^ «О практической (не)безопасности 64-битных блочных шифров — атаки коллизий на HTTP через TLS и OpenVPN» (PDF) . 2016-10-28. Архивировано (PDF) из оригинала 2017-04-24 . Получено 2017-06-08 .
^ "Специальная публикация NIST 800-57 Рекомендации по управлению ключами — Часть 1: Общие положения (пересмотренные)" (PDF) . 2007-03-08. Архивировано из оригинала (PDF) 6 июня 2014 г. . Получено 2014-07-03 .
^ abc Qualys SSL Labs. "SSL/TLS Deployment Best Practices". Архивировано из оригинала 4 июля 2015 г. Получено 2 июня 2015 г.
^ "Http vs https". Архивировано из оригинала 2015-02-12 . Получено 2015-02-12 .
^ abcd По состоянию на 3 мая 2024 г. «SSL Pulse: Обзор внедрения SSL на самых популярных веб-сайтах». Qualys . Архивировано из оригинала 2021-03-08 . Получено 2024-05-30 .
^ ab ivanr (19 марта 2013 г.). "RC4 в TLS сломан: что теперь?". Qualsys Security Labs. Архивировано из оригинала 27-08-2013 . Получено 30-07-2013 .
^ abc Бодо Мёллер, Тай Дуонг и Кшиштоф Котович. "This POODLE Bites: Exploiting The SSL 3.0 Fallback" (PDF) . Архивировано (PDF) из оригинала 2014-10-14 . Получено 2014-10-15 .
^ «Internet Explorer 11 вышел из эксплуатации и официально не поддерживается — что вам нужно знать». 15 июня 2022 г. Архивировано из оригинала 2022-06-15 . Получено 2022-06-15 .
^ "Поддержка настольного приложения Internet Explorer 11 прекращена для некоторых версий Windows 10" . Получено 2022-06-17 .
^ "Java Secure Socket Extension (JSSE) Reference Guide". Oracle Help Center . Архивировано из оригинала 2022-01-22 . Получено 2021-12-24 .
^ Георгиев, Мартин; Айенгар, Субодх; Яна, Суман; Анубхай, Ришита; Бонех, Дан; Шматиков, Виталий (2012). Самый опасный код в мире: проверка SSL-сертификатов в небраузерном программном обеспечении. Труды конференции ACM 2012 года по компьютерной и коммуникационной безопасности (PDF) . Ассоциация вычислительной техники. стр. 38–49. ISBN978-1-4503-1651-4. Архивировано (PDF) из оригинала 2017-10-22.
^ Оде, Ф. (2009). Использование схемы URI SIPS в протоколе инициирования сеанса (SIP). doi : 10.17487/RFC5630 . RFC 5630.
^ Шеффер, И.; Хольц, Р.; Сент-Андре, П. (2015). Обобщение известных атак на Transport Layer Security (TLS) и Datagram TLS (DTLS). doi : 10.17487/RFC7457 . RFC 7457.
^ "CVE – CVE-2009-3555". Архивировано из оригинала 2016-01-04.
^ Рескорла, Эрик (2009-11-05). "Понимание атаки повторного согласования TLS". Образованное предположение . Архивировано из оригинала 2012-02-11 . Получено 2009-11-27 .
^ "GnuTLS 2.10.0 released". Заметки о выпуске GnuTLS . 2010-06-25. Архивировано из оригинала 2015-10-17 . Получено 2011-07-24 .
^ "NSS 3.12.6 release notes". NSS release notes . 2010-03-03. Архивировано из оригинала 6 марта 2012 года . Получено 2011-07-24 .
^ A. Langley; N. Modadugu; B. Moeller (2010-06-02). "Transport Layer Security (TLS) False Start". Internet Engineering Task Force . IETF. Архивировано из оригинала 2013-09-05 . Получено 2013-07-31 .
^ Грюнер, Вольфганг. "Фальстарт: Google предлагает более быстрый Интернет, Chrome уже его поддерживает". Архивировано из оригинала 2010-10-07 . Получено 2011-03-09 .
^ Смит, Брайан. "Ограниченные атаки отката при фальстарте и мгновенном старте". Архивировано из оригинала 2011-05-04 . Получено 2011-03-09 .
^ Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). Кросс-протокольная атака на протокол TLS. Труды конференции ACM 2012 года по компьютерной и коммуникационной безопасности (PDF) . Ассоциация вычислительной техники. стр. 62–72. ISBN978-1-4503-1651-4. Архивировано (PDF) из оригинала 2015-07-06.
^ "SMACK: State Machine Attacks". Архивировано из оригинала 2015-03-12.
^ Гудин, Дэн (2015-05-20). «HTTPS-паразитическая атака угрожает десяткам тысяч веб- и почтовых серверов». Ars Technica . Архивировано из оригинала 2017-05-19.
^ Лейден, Джон (1 марта 2016 г.). «Треть всех сайтов HTTPS открыты для атаки DROWN». The Register . Архивировано из оригинала 1 марта 2016 г. Получено 2016-03-02 .
^ ab "Более 11 миллионов HTTPS-сайтов подверглись новой атаке дешифрования". Ars Technica . Март 2016. Архивировано из оригинала 2016-03-01 . Получено 2016-03-02 .
^ Thai Duong & Juliano Rizzo (2011-05-13). "Here Come The ⊕ Ninjas". Архивировано из оригинала 2014-06-03.
^ Гудин, Дэн (2011-09-19). "Хакеры взламывают SSL-шифрование, используемое миллионами сайтов". The Register . Архивировано из оригинала 2012-02-10.
^ "Y Combinator комментирует проблему". 20.09.2011. Архивировано из оригинала 31.03.2012.
^ "Безопасность наборов шифров CBC в SSL/TLS: проблемы и контрмеры". 2004-05-20. Архивировано из оригинала 2012-06-30.
^ Ристич, Иван (10 сентября 2013 г.). «Представляет ли BEAST все еще угрозу?». Архивировано из оригинала 12 октября 2014 г. Получено 8 октября 2014 г.
^ "Атака против защищенных TLS коммуникаций". Блог безопасности Mozilla . Mozilla. 2011-09-27. Архивировано из оригинала 2015-03-04 . Получено 2015-02-01 .
^ Смит, Брайан (30.09.2011). "(CVE-2011-3389) Атака с использованием выбранного открытого текста Риццо/Дыонга (BEAST) на SSL/TLS 1.0 (при содействии websockets-76)". Архивировано из оригинала 10.02.2012 . Получено 01.11.2011 .
^ MSRC (2012-01-10). Уязвимость в SSL/TLS может привести к раскрытию информации (2643584). Бюллетени по безопасности (технический отчет). MS12-006 . Получено 2021-10-24 – через Microsoft Docs .
^ Ristic, Ivan (31 октября 2013 г.). "Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks". Архивировано из оригинала 12 октября 2014 г. Получено 8 октября 2014 г.
^ Гудин, Дэн (2012-09-13). «Трещина в основе доверия Интернета позволяет перехватывать сеанс HTTPS». Ars Technica . Архивировано из оригинала 2013-08-01 . Получено 2013-07-31 .
^ Фишер, Деннис (13 сентября 2012 г.). «Атака CRIME использует коэффициент сжатия запросов TLS в качестве побочного канала для перехвата защищенных сеансов». ThreatPost. Архивировано из оригинала 15 сентября 2012 г. Получено 13 сентября 2012 г.
^ ab Goodin, Dan (1 августа 2013 г.). «Угнать за 30 секунд: новая атака извлекает секреты из защищенных HTTPS страниц». Ars Technica . Condé Nast. Архивировано из оригинала 3 августа 2013 г. . Получено 2 августа 2013 г. .
^ Лейден, Джон (2 августа 2013 г.). «Шаг в BREACH: разработана новая атака для чтения зашифрованных веб-данных». The Register . Архивировано из оригинала 5 августа 2013 г. Получено 2 августа 2013 г.
^ P. Gutmann (сентябрь 2014 г.). Encrypt-then-MAC для Transport Layer Security (TLS) и Datagram Transport Layer Security (DTLS). Internet Engineering Task Force. doi : 10.17487/RFC7366 . RFC 7366.
↑ Лэнгли, Адам (8 декабря 2014 г.). «ПУДЛЬ снова кусается». Архивировано из оригинала 8 декабря 2014 г. Получено 08.12.2014 .
^ "ssl – Самые безопасные шифры для использования с BEAST? (эксплойт TLS 1.0) Я читал, что RC4 неуязвим". Serverfault.com . Архивировано из оригинала 20 февраля 2022 г. . Получено 20 февраля 2022 г. .
^ Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Открытие и эксплуатация новых смещений в RC4". В Alex Biryukov; Guang Gong ; Douglas R. Stinson (ред.). Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canada, 12–13 августа 2010 г., Revised Selected Papers . Lecture Notes in Computer Science. Vol. 6544. pp. 74–91. doi :10.1007/978-3-642-19574-7_5. ISBN978-3-642-19573-0.
^ Грин, Мэтью (12 марта 2013 г.). «Атака недели: RC4 немного сломан в TLS». Cryptography Engineering . Архивировано из оригинала 14 марта 2013 г. Получено 12 марта 2013 г.
^ Аль-Фардан, Надхем; Бернстайн, Дэн; Патерсон, Кенни; Пёттеринг, Бертрам; Шульдт, Якоб. «О безопасности RC4 в TLS». Лондонский университет Royal Holloway. Архивировано из оригинала 15 марта 2013 г. Получено 13 марта 2013 г.
^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (8 июля 2013 г.). "О безопасности RC4 в TLS и WPA" (PDF) . Information Security Group . Архивировано (PDF) из оригинала 22 сентября 2013 г. . Получено 2 сентября 2013 г.
^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (15 августа 2013 г.). О безопасности RC4 в TLS (PDF) . 22-й симпозиум по безопасности USENIX . стр. 51. Архивировано (PDF) из оригинала 22 сентября 2013 г. . Получено 2 сентября 2013 г. . Атаки с восстановлением открытого текста против RC4 в TLS возможны, хотя и не совсем практичны
^ Гудин, Дэн (15 июля 2015 г.). «Некогда теоретическая криптоатака против HTTPS теперь граничит с практической реализацией». Ars Technical . Conde Nast. Архивировано из оригинала 16 июля 2015 г. Получено 16 июля 2015 г.
^ "Mozilla Security Server Side TLS Recommended Configurations". Mozilla. Архивировано из оригинала 2015-01-03 . Получено 2015-01-03 .
^ "Совет по безопасности 2868725: Рекомендация по отключению RC4". Microsoft. 2013-11-12. Архивировано из оригинала 2013-11-18 . Получено 2013-12-04 .
^ "Прекращение поддержки шифра RC4 в Microsoft Edge и Internet Explorer 11". Команда Microsoft Edge. 1 сентября 2015 г. Архивировано из оригинала 2 сентября 2015 г.
^ Лэнгли, Адам (1 сентября 2015 г.). "Намерение отменить: RC4". Архивировано из оригинала 23 мая 2013 г. Получено 2 сентября 2015 г.
^ Барнс, Ричард (1 сентября 2015 г.). "Намерение отправить: RC4 отключен по умолчанию в Firefox 44". Архивировано из оригинала 22.01.2011.
^ ab John Leyden (1 августа 2013 г.). "Gmail, Outlook.com и электронное голосование 'pwned' on stage in crypto-dodge hack". The Register . Архивировано из оригинала 1 августа 2013 г. . Получено 1 августа 2013 г. .
^ "BlackHat USA Briefings". Black Hat 2013. Архивировано из оригинала 30 июля 2013. Получено 1 августа 2013 .
^ Смит, Бен; Пиронти, Альфредо (2013). Усечение соединений TLS для нарушения убеждений в веб-приложениях. 7-й семинар USENIX по наступательным технологиям (отчет). Архивировано из оригинала 6 ноября 2015 г. Получено 15 февраля 2016 г.
^ AlFardan, Nadhem; Paterson, Kenneth G (2012). Атаки с восстановлением открытого текста против датаграмм TLS (PDF) . Симпозиум по безопасности сетей и распределенных систем (NDSS 2012). Архивировано из оригинала 2012-01-18.{{cite conference}}: CS1 maint: unfit URL (link)
^ Гудин, Дэн (26 июля 2016 г.). «Новая атака обходит защиту HTTPS на компьютерах Mac, Windows и Linux». Ars Technica . Condé Nast. Архивировано из оригинала 27 июля 2016 г. Получено 28 июля 2016 г.
^ Гудин, Дэн (24 августа 2016 г.). «HTTPS и OpenVPN столкнулись с новой атакой, способной расшифровать секретные файлы cookie». Ars Technica . Архивировано из оригинала 24 августа 2016 г. Получено 24 августа 2016 г.
^ «Почему его называют „Heartbleed Bug“?». The Washington Post . 2014-04-09. Архивировано из оригинала 2014-10-09.
^ "Уязвимость Heartbleed Bug [9 апреля 2014 г.]". Comodo Group . Архивировано из оригинала 5 июля 2014 г.
^ Блейхенбахер, Дэниел (август 2006 г.). «Подделка подписи RSA Блейхенбахера на основе ошибки реализации». Архивировано из оригинала 16.12.2014.
^ "BERserk". Intel Security: Advanced Threat Research. Сентябрь 2014 г. Архивировано из оригинала 2015-01-12.
^ Гудин, Дэн (19 февраля 2015 г.). «Компьютеры Lenovo поставляются с рекламным ПО типа «man-in-the-middle», которое разрывает соединения HTTPS». Ars Technica . Архивировано из оригинала 12 сентября 2017 г. Получено 10 декабря 2017 г.
^ ab Goodin, Dan (26 мая 2016 г.). ««Запрещенная атака» делает десятки сайтов HTTPS Visa уязвимыми для взлома». Ars Technica . Архивировано из оригинала 26 мая 2016 г. . Получено 26 мая 2016 г. .
^ Кларк Эстес, Адам (24 февраля 2017 г.). «Все, что вам нужно знать о Cloudbleed, последней катастрофе в сфере интернет-безопасности». Gizmodo . Архивировано из оригинала 25.02.2017 . Получено 24.02.2017 .
^ Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (июнь 1992 г.). «Аутентификация и аутентифицированные обмены ключами». Designs, Codes and Cryptography . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . doi :10.1007/BF00124891. S2CID 7356608. Архивировано из оригинала 2008-03-13 . Получено 2008-02-11 .
^ "Обсуждение списка рассылки TLS в октябре 2007 г.". Архивировано из оригинала 22 сентября 2013 г. Получено 20 февраля 2022 г.
^ "Защита данных на долгий срок с помощью прямой секретности". Архивировано из оригинала 2013-05-06 . Получено 2012-11-05 .
^ Бернат, Винсент (28 ноября 2011 г.). "SSL/TLS и совершенная прямая секретность". Архивировано из оригинала 2012-08-27 . Получено 2012-11-05 .
^ Ристич, Иван (2013-08-05). "SSL Labs: Deploying Forward Secrecy". Qualsys. Архивировано из оригинала 20-09-2013 . Получено 31-08-2013 .
^ ab Langley, Adam (27 июня 2013 г.). "Как испортить прямую секретность TLS". imperialviolet.org . Архивировано из оригинала 8 августа 2013 г.
^ ab Daignière, Florent. "TLS "Secrets": Whitepaper, представляющий последствия для безопасности развертывания сеансовых билетов (RFC 5077), реализованных в OpenSSL" (PDF) . Matta Consulting Limited. Архивировано (PDF) из оригинала 6 августа 2013 г. . Получено 7 августа 2013 г. .
^ ab Daignière, Florent. "TLS "Secrets": То, о чем все забыли вам рассказать…" (PDF) . Matta Consulting Limited. Архивировано (PDF) из оригинала 5 августа 2013 г. . Получено 7 августа 2013 г. .
^ LS Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). «Экспериментальное исследование развертываний прямой секретности TLS». IEEE Internet Computing . 18 (6): 43–51. CiteSeerX 10.1.1.663.4653 . doi :10.1109/MIC.2014.86. S2CID 11264303. Архивировано из оригинала 20 сентября 2015 г. Получено 16 октября 2015 г.
^ "Защита данных на долгий срок с помощью прямой секретности". Архивировано из оригинала 2014-02-12 . Получено 2014-03-07 .
^ Хоффман-Эндрюс, Джейкоб. "Forward Secrecy at Twitter". Twitter. Архивировано из оригинала 2014-02-16 . Получено 2014-03-07 .
^ abc Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 сентября 2017 г.). «Влияние перехвата HTTPS на безопасность». Симпозиум NDSS . doi :10.14722/ndss.2017.23456. ISBN978-1-891562-46-4. Архивировано из оригинала 22 марта 2019 . Получено 11 марта 2019 .
^ ab В настоящее время это сертификаты X.509 , но RFC 6091 также определяет использование сертификатов на основе OpenPGP .
^ "tls – Различия между терминами "pre-master secret", "master secret", "private key" и "shared secret"?". Cryptography Stack Exchange . Архивировано из оригинала 2020-09-22 . Получено 2020-10-01 .
^ Крис (2009-02-18). "vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication". Scarybeastsecurity. blogspot.com. Архивировано из оригинала 2012-07-07 . Получено 2012-05-17 .
^ Рескорла, Эрик (август 2018 г.). «Криптографическое согласование». Протокол Transport Layer Security (TLS) версии 1.3. IETF. раздел 4.1.1. doi : 10.17487/RFC8446 . RFC 8446.
^ Вальсорда, Филиппо (23 сентября 2016 г.). «Обзор TLS 1.3 и вопросы и ответы». Блог Cloudflare . Архивировано из оригинала 3 мая 2019 г. Получено 3 мая 2019 г.
^ Виртуальные хосты SSL на основе имен: как решить проблему (PDF) , заархивировано (PDF) из оригинала 2012-08-03 , извлечено 2012-05-17
Дальнейшее чтение
На Викискладе есть медиафайлы по теме SSL и TLS .
Вагнер, Дэвид; Шнайер, Брюс (ноябрь 1996 г.). "Анализ протокола SSL 3.0" (PDF) . Второй семинар USENIX по электронной коммерции . USENIX Press. стр. 29–40. Архивировано (PDF) из оригинала 2006-10-16 . Получено 2006-10-12 .
Рескорла, Эрик (2001). SSL и TLS: Проектирование и создание безопасных систем . США: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
Стивен А. Томас (2000). SSL и TLS основы защиты Интернета . Нью-Йорк: Wiley. ISBN 978-0-471-38354-3.
Бард, Грегори (2006). «Сложная, но осуществимая блочно-адаптивная атака с выбранным открытым текстом на SSL». Международная ассоциация криптологических исследований (136). Архивировано из оригинала 2011-09-23 . Получено 2011-09-23 .
Канвел, Брайс. "Перехват пароля в канале SSL/TLS". Архивировано из оригинала 2016-04-20 . Получено 2007-04-20 .
RFC изменений для повторного согласования TLS . 2010. doi :10.17487/RFC5746. RFC 5746 .
Создание VPN с IPsec и SSL/TLS Архивировано 12 апреля 2015 г. в статье журнала Wayback Machine Linux Journal, автор Рами Розен
Джошуа Дэвис (2010). Реализация SSL/TLS . Wiley. ISBN 978-0470920411.
Полк, Тим; Маккей, Керри; Чокани, Сантош (апрель 2014 г.). "Руководство по выбору, настройке и использованию реализаций безопасности транспортного уровня (TLS)" (PDF) . Национальный институт стандартов и технологий. Архивировано из оригинала (PDF) 2014-05-08 . Получено 2014-05-07 .
Abdou, AbdelRahman; van Oorschot, Paul (август 2017 г.). «Проверка местоположения сервера (SLV) и закрепление местоположения сервера: расширение аутентификации TLS». ACM Transactions on Privacy and Security . 21 (1): 1:1–1:26. doi :10.1145/3139294. S2CID 5869541. Архивировано из оригинала 22.03.2019 . Получено 11.01.2018 .
Иван Ристич (2022). Bulletproof TLS and PKI, Второе издание . Feisty Duck. ISBN 978-1907117091.
Первичные стандарты
Текущей утвержденной версией (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 5077: «Возобновление сеанса TLS без состояния на стороне сервера».
RFC 5081: «Использование ключей OpenPGP для аутентификации по протоколу TLS», устарело с появлением RFC 6091.
RFC 5216: « Протокол аутентификации EAP -TLS»
Расширения TLS 1.0 включают в себя:
RFC 2595: «Использование TLS с IMAP, POP3 и ACAP». Определяет расширение для служб IMAP, POP3 и ACAP, позволяющее серверу и клиенту использовать безопасность транспортного уровня для обеспечения конфиденциальной, аутентифицированной связи через Интернет.
RFC 2712: «Добавление наборов шифров Kerberos к безопасности транспортного уровня (TLS)». 40-битные наборы шифров, определенные в этой записке, появляются только с целью документирования того факта, что коды этих наборов шифров уже были назначены.
RFC 2817: "Upgrading to TLS Within HTTP/1.1", объясняет, как использовать механизм Upgrade в HTTP/1.1 для инициирования Transport Layer Security (TLS) по существующему TCP-соединению. Это позволяет незащищенному и защищенному HTTP-трафику совместно использовать один и тот же известный порт (в данном случае http: на 80, а не https: на 443).
RFC 2818: «HTTP Over TLS» отличает защищенный трафик от незащищенного трафика с помощью использования другого «порта сервера».
RFC 3207: «Расширение службы SMTP для безопасного SMTP через безопасность транспортного уровня». Определяет расширение службы SMTP, которое позволяет серверу и клиенту SMTP использовать безопасность транспортного уровня для обеспечения конфиденциальной, аутентифицированной связи через Интернет.
RFC 3268: «AES Ciphersuites for TLS». Добавляет наборы шифров Advanced Encryption Standard (AES) к ранее существовавшим симметричным шифрам.
RFC 3546: "Transport Layer Security (TLS) Extensions", добавляет механизм согласования расширений протокола во время инициализации сеанса и определяет некоторые расширения. Устарело в 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: «Обобщение известных атак на протоколы Transport Layer Security (TLS) и Datagram TLS (DTLS)»
RFC 7525: «Рекомендации по безопасному использованию протокола TLS и протокола DTLS»
Внешние ссылки
Целевая группа по инжинирингу Интернета – рабочая группа TLS Архивировано 11.01.2014 на Wayback Machine
