Протокол 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 года Агентством национальной безопасности, Национальным бюро стандартов, Агентством оборонных коммуникаций и двенадцатью коммуникационными и компьютерными корпорациями, которые инициировали специальный проект под названием Secure Data Network System (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 года [update]последние версии всех основных веб-браузеров поддерживают 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 года [update]Движение за доверие к Интернету оценило долю веб-сайтов, уязвимых для атак TLS. [92]
Прямая секретность
Forward secrecy is a property of cryptographic systems which ensures that a session key derived from a set of public and private keys will not be compromised if one of the private keys is compromised in the future.[157] Without forward secrecy, if the server's private key is compromised, not only will all future TLS-encrypted sessions using that server certificate be compromised, but also any past sessions that used it as well (provided that these past sessions were intercepted and stored at the time of transmission).[158] An implementation of TLS can provide forward secrecy by requiring the use of ephemeral Diffie–Hellman key exchange to establish session keys, and some notable TLS implementations do so exclusively: e.g., Gmail and other Google HTTPS services that use OpenSSL.[159] However, many clients and servers supporting TLS (including browsers and web servers) are not configured to implement such restrictions.[160][161] In practice, unless a web service uses Diffie–Hellman key exchange to implement forward secrecy, all of the encrypted web traffic to and from that service can be decrypted by a third party if it obtains the server's master (private) key; e.g., by means of a court order.[162]
Even where Diffie–Hellman key exchange is implemented, server-side session management mechanisms can impact forward secrecy. The use of TLS session tickets (a TLS extension) causes the session to be protected by AES128-CBC-SHA256 regardless of any other negotiated TLS parameters, including forward secrecy ciphersuites, and the long-lived TLS session ticket keys defeat the attempt to implement forward secrecy.[163][164][165] Stanford University research in 2014 also found that of 473,802 TLS servers surveyed, 82.9% of the servers deploying ephemeral Diffie–Hellman (DHE) key exchange to support forward secrecy were using weak Diffie–Hellman parameters. These weak parameter choices could potentially compromise the effectiveness of the forward secrecy that the servers sought to provide.[166]
Since late 2011, Google has provided forward secrecy with TLS by default to users of its Gmail service, along with Google Docs and encrypted search, among other services.[167]Since November 2013, Twitter has provided forward secrecy with TLS to users of its service.[168] As of August 2019[update], about 80% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to most web browsers.[92]
TLS interception
TLS interception (or HTTPS interception if applied particularly to that protocol) is the practice of intercepting an encrypted data stream in order to decrypt it, read and possibly manipulate it, and then re-encrypt it and send the data on its way again. This is done by way of a "transparent proxy": the interception software terminates the incoming TLS connection, inspects the HTTP plaintext, and then creates a new TLS connection to the destination.[169]
TLS/HTTPS interception is used as an information security measure by network operators in order to be able to scan for and protect against the intrusion of malicious content into the network, such as computer viruses and other malware.[169] Such content could otherwise not be detected as long as it is protected by encryption, which is increasingly the case as a result of the routine use of HTTPS and other secure protocols.
A significant drawback of TLS/HTTPS interception is that it introduces new security risks of its own. One notable limitation is that it provides a point where network traffic is available unencrypted thus giving attackers an incentive to attack this point in particular in order to gain access to otherwise secure content. The interception also allows the network operator, or persons who gain access to its interception system, to perform man-in-the-middle attacks against network users. A 2017 study found that "HTTPS interception has become startlingly widespread, and that interception products as a class have a dramatically negative impact on connection security".[169]
Protocol details
The TLS protocol exchanges records, which encapsulate the data to be exchanged in a specific format (see below). Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the connection. Each record has a content type field that designates the type of data encapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messages of the TLS itself, or simply the application data needed to be transferred by TLS. The specifications (cipher suite, keys etc.) required to exchange application data by TLS, are agreed upon in the "TLS handshake" between the client requesting the data and the server responding to requests. The protocol therefore defines both the structure of payloads transferred in TLS and the procedure to establish and monitor the transfer.
TLS handshake
Simplified illustration of the full TLS 1.2 handshake with timing information
When the connection starts, the record encapsulates a "control" protocol – the handshake messaging protocol (content type 22). This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS. It defines the format of messages and the order of their exchange. These may vary according to the demands of the client and server – i.e., there are several possible procedures to set up the connection. This initial exchange results in a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).
Basic TLS handshake
A typical connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:
Negotiation phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. If the client can use Application-Layer Protocol Negotiation, it may include a list of supported application protocols, such as HTTP/2.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[170]
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon cipher suites.[23]
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data (session keys such as IV, symmetric encryption key, MAC key[171]) for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
The client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be terminated.
Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."
The server sends its authenticated and encrypted Finished message.
The client performs the same decryption and verification procedure as the server did in the previous step.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.
Client-authenticated TLS handshake
The following full example shows a client being authenticated (in addition to the server as in the example above; see mutual authentication) via TLS using certificates exchanged between both peers.
Negotiation Phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[170]
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon ciphersuites.[1]
The server sends a CertificateRequest message, to request a certificate from the client.
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a Certificate message, which contains the client's certificate, but not its private key.
The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data ("session keys") for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). "The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)."
The server sends its own encrypted Finished message.
The client performs the same decryption and verification procedure as the server did in the previous step.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message.
Resumed TLS handshake
Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions are implemented using session IDs or session tickets.
Apart from the performance benefit, resumed sessions can also be used for single sign-on, as it guarantees that both the original session and any resumed session originate from the same client. This is of particular importance for the FTP over TLS/SSL protocol, which would otherwise suffer from a man-in-the-middle attack in which an attacker could intercept the contents of the secondary data connections.[172]
TLS 1.3 handshake
The TLS 1.3 handshake was condensed to only one round trip compared to the two round trips required in previous versions of TLS/SSL.
To start the handshake, the client guesses which key exchange algorithm will be selected by the server and sends a ClientHello message to the server containing a list of supported ciphers (in order of the client's preference) and public keys for some or all of its key exchange guesses. If the client successfully guesses the key exchange algorithm, 1 round trip is eliminated from the handshake. After receiving the ClientHello, the server selects a cipher and sends back a ServerHello with its own public key, followed by server Certificate and Finished messages.[173]
After the client receives the server's finished message, it now is coordinated with the server on which cipher suite to use.[174]
Session IDs
In an ordinary full handshake, the server sends a session id as part of the ServerHello message. The client associates this session id with the server's IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello and ServerHello messages virtually guarantee that the generated connection keys will be different from in the previous connection. In the RFCs, this type of handshake is called an abbreviated handshake. It is also described in the literature as a restart handshake.
Negotiation phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. Included in the message is the session id from the previous TLS connection.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. If the server recognizes the session id sent by the client, it responds with the same session id. The client uses this to recognize that a resumed handshake is being performed. If the server does not recognize the session id sent by the client, it sends a different value for its session id. This tells the client that a resumed handshake will not be performed. At this point, both the client and server have the "master secret" and random data to generate the key data to be used for this connection.
The server now sends a ChangeCipherSpec record, essentially telling the client, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
Finally, the server sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The client will attempt to decrypt the server's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
Finally, the client sends a ChangeCipherSpec, telling the server, "Everything I tell you from now on will be encrypted."
The client sends its own encrypted Finished message.
The server performs the same decryption and verification procedure as the client did in the previous step.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message.
Session tickets
RFC 5077 extends TLS via use of session tickets, instead of session IDs. It defines a way to resume a TLS session without requiring that session-specific state is stored at the TLS server.
When using session tickets, the TLS server stores its session-specific state in a session ticket and sends the session ticket to the TLS client for storing. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session according to the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server verifies its validity before using its contents.
One particular weakness of this method with OpenSSL is that it always limits encryption and authentication security of the transmitted TLS session ticket to AES128-CBC-SHA256, no matter what other TLS parameters were negotiated for the actual TLS session.[164] This means that the state information (the TLS session ticket) is not as well protected as the TLS session itself. Of particular concern is OpenSSL's storage of the keys in an application-wide context (SSL_CTX), i.e. for the life of the application, and not allowing for re-keying of the AES128-CBC-SHA256 TLS session tickets without resetting the application-wide OpenSSL context (which is uncommon, error-prone and often requires manual administrative intervention).[165][163]
TLS record
This is the general format of all TLS records.
Content type
This field identifies the Record Layer Protocol Type contained in this record.
Legacy version
This field identifies the major and minor version of TLS prior to TLS 1.3 for the contained message. For a ClientHello message, this need not be the highest version supported by the client. For TLS 1.3 and later, this must to be set 0x0303 and application must send supported versions in an extra message extension block.
Length
The length of "protocol message(s)", "MAC" and "padding" fields combined (i.e. q−5), not to exceed 214 bytes (16 KiB).
Protocol message(s)
One or more messages identified by the Protocol field. Note that this field may be encrypted depending on the state of the connection.
MAC and padding
A message authentication code computed over the "protocol message(s)" field, with additional key material included. Note that this field may be encrypted, or not included entirely, depending on the state of the connection.
No "MAC" or "padding" fields can be present at end of TLS records before all cipher algorithms and parameters have been negotiated and handshaked and then confirmed by sending a CipherStateChange record (see below) for signalling that these parameters will take effect in all further records sent by the same peer.
Handshake protocol
Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record (see below), or the encryption mode of the session is modified by another record (see ChangeCipherSpec protocol below).
Message type
This field identifies the handshake message type.
Handshake message data length
This is a 3-byte field indicating the length of the handshake data, not including the header.
Note that multiple handshake messages may be combined within one record.
Alert protocol
This record should normally not be sent during normal handshaking or application exchanges. However, this message can be sent at any time during the handshake and up to the closure of the session. If this is used to signal a fatal error, the session will be closed immediately after sending this record, so this record is used to give a reason for this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs (before doing so, the remote may also send its own signal).
Level
This field identifies the level of alert. If the level is fatal, the sender should close the session immediately. Otherwise, the recipient may decide to terminate the session itself, by sending its own fatal alert and closing the session itself immediately after sending it. The use of Alert records is optional, however if it is missing before the session closure, the session may be resumed automatically (with its handshakes).
Normal closure of a session after termination of the transported application should preferably be alerted with at least the Close notify Alert type (with a simple warning level) to prevent such automatic resume of a new session. Signalling explicitly the normal closure of a secure session before effectively closing its transport layer is useful to prevent or detect attacks (like attempts to truncate the securely transported data, if it intrinsically does not have a predetermined length or duration that the recipient of the secured data may expect).
Description
This field identifies which type of alert is being sent.
ChangeCipherSpec protocol
CCS protocol type
Currently only 1.
Application protocol
Length
Length of application data (excluding the protocol header and including the MAC and padding trailers)
MAC
32 bytes for the SHA-256-based HMAC, 20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC.
Padding
Variable length; last byte contains the padding length.
Support for name-based virtual servers
From the application protocol point of view, TLS belongs to a lower layer, although the TCP/IP model is too coarse to show it. This means that the TLS handshake is usually (except in the STARTTLS case) performed before the application protocol can start. In the name-based virtual server feature being provided by the application layer, all co-hosted virtual servers share the same certificate because the server has to select and send a certificate immediately after the ClientHello message. This is a big problem in hosting environments because it means either sharing the same certificate among all customers or using a different IP address for each of them.
There are two known workarounds provided by X.509:
If all virtual servers belong to the same domain, a wildcard certificate can be used.[175] Besides the loose host name selection that might be a problem or not, there is no common agreement about how to match wildcard certificates. Different rules are applied depending on the application protocol or software used.[176]
Add every virtual host name in the subjectAltName extension. The major problem being that the certificate needs to be reissued whenever a new virtual server is added.
To provide the server name, RFC 4366 Transport Layer Security (TLS) Extensions allow clients to include a Server Name Indication extension (SNI) in the extended ClientHello message. This extension hints to the server immediately which name the client wishes to connect to, so the server
can select the appropriate certificate to send to the clients.
RFC 2817 also documents a method to implement name-based virtual hosting by upgrading HTTP to TLS via an HTTP/1.1 Upgrade header. Normally this is to securely implement HTTP over TLS within the main "http" URI scheme (which avoids forking the URI space and reduces the number of used ports), however, few implementations currently support this.[citation needed]
QUIC (Quick UDP Internet Connections) – "…was designed to provide security protection equivalent to TLS/SSL"; QUIC's main goal is to improve perceived performance of connection-oriented web applications that are currently using TCP
^i.e. "Delegated Credentials for (D)TLS". Ietf. Archived from the original on 2024-06-26. Retrieved 2024-06-26.
^ a bLawrence, Scott; Khare, Rohit (May 2000). Upgrading to TLS Within HTTP/1.1. Internet Engineering Task Force. doi:10.17487/RFC2817. RFC 2817.
^"SSL/TLS in Detail". TechNet. Microsoft Docs. October 8, 2009. Archived from the original on 2022-08-13. Retrieved 2021-10-24.
^ a bHooper, Howard (2012). CCNP Security VPN 642–648 Official Cert Guide (2 ed.). Cisco Press. p. 22. ISBN 9780132966382.
^ a bSpott, Andrew; Leek, Tom; et al. "What layer is TLS?". Information Security Stack Exchange. Archived from the original on 2021-02-13. Retrieved 2017-04-13.
^ a b c d e fE. Rescorla (August 2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF TLS workgroup. doi:10.17487/RFC8446. RFC 8446. Proposed Standard. Obsoletes RFC 5077, 5246 and 6961; updates RFC 5705 and 6066.
^Rescorla, Eric; Modadugu, Nagendra (January 2012). Datagram Transport Layer Security Version 1.2. doi:10.17487/RFC6347. RFC 6347.
^Titz, Olaf (2001-04-23). "Why TCP Over TCP Is A Bad Idea". Archived from the original on 2023-03-10. Retrieved 2015-10-17.
^Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (October 2005). "Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency". In Atiquzzaman, Mohammed; Balandin, Sergey I (eds.). Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III. Vol. 6011. Bibcode:2005SPIE.6011..138H. CiteSeerX10.1.1.78.5815. doi:10.1117/12.630496. S2CID 8945952.
^RFC 4347 § 4
^Rescorla, Eric; Tschofenig, Hannes; Modadugu, Nagena (April 21, 2022). The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. doi:10.17487/RFC9147. RFC 9147.
^"AnyConnect FAQ: tunnels, reconnect behavior, and the inactivity timer". Cisco. Archived from the original on 26 February 2017. Retrieved 26 February 2017.
^"Cisco InterCloud Architectural Overview" (PDF). Cisco Systems. Archived (PDF) from the original on 2022-08-09. Retrieved 2022-11-29.
^"OpenConnect". OpenConnect. Archived from the original on 2 February 2017. Retrieved 26 February 2017.
^"ZScaler ZTNA 2.0 Tunnel". ZScaler. Archived from the original on 2022-11-29. Retrieved 2022-11-29.
^"f5 Datagram Transport Layer Security (DTLS)". f5 Networks. Archived from the original on 2022-11-29. Retrieved 2022-11-29.
^"Configuring a DTLS Virtual Server". Citrix Systems. Archived from the original on 2016-12-21. Retrieved 2022-11-29.
^"WebRTC Interop Notes". Archived from the original on 2013-05-11.
^ a b c d eBright, Peter (17 October 2018). "Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0". Archived from the original on 17 October 2018. Retrieved 17 October 2018.
^ a b c d"Here is what is new and changed in Firefox 74.0 Stable – gHacks Tech News". www.ghacks.net. 10 March 2020. Archived from the original on 2020-03-11. Retrieved 2020-03-10.
^ a b c d"TLS 1.0 and TLS 1.1 – Chrome Platform Status". chromestatus.com. Archived from the original on 2023-07-07. Retrieved 2020-03-10.
^ a b c d eT. Dierks; E. Rescorla (August 2008). The Transport Layer Security (TLS) Protocol Version 1.2. IETF TLS workgroup. doi:10.17487/RFC5246. RFC 5246. Obsolete. Obsoleted by RFC 8446; obsoletes RFC 3268, 4346 and 4366; updates RFC 4492.
^ a b"Using TLS to protect data". www.ncsc.gov.uk. Archived from the original on July 21, 2021. Retrieved August 24, 2022.
^"TLS 1.3: One Year Later". IETF. Archived from the original on July 8, 2020. Retrieved August 24, 2022.
^"Creating TLS: The Pioneering Role of Ruth Nelson". Archived from the original on 2020-06-24. Retrieved 2020-07-04.
^Woo, Thomas Y. C.; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (June 1994). SNP: An interface for secure network programming (PDF). Proceedings USENIX Summer Technical Conference. Archived (PDF) from the original on 2014-12-12. Retrieved 2023-07-05.
^"1994 USENIX Summer Technical Conference Program, Boston, 6–10 June 1994". Archived from the original on 6 October 2023. Retrieved 21 January 2024.
^Simon S. Lam (PI/PD), "Applying a Theory of Modules and Interfaces to Security Verification," NSA INFOSEC University Research Program grant no. MDA 904-91-C-7046, 6/28/91 to 6/27/93.
^"2004 ACM Software System Award citation". ACM. Archived from the original on 17 June 2013. Retrieved 25 July 2012.
^"ACM Press Release, March 15, 2005". ACM. Archived from the original on 10 January 2016. Retrieved 25 July 2012.
^"Internet Hall of Fame inductee Simon S. Lam". Archived from the original on 6 February 2024. Retrieved 3 Mar 2024.
^"Computer Scientist Inducted into Internet Hall of Fame". Archived from the original on 8 March 2024. Retrieved 3 Mar 2024.
^Messmer, Ellen. "Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East". Network World. Archived from the original on 31 May 2014. Retrieved 30 May 2014.
^Greene, Tim. "Father of SSL says despite attacks, the security linchpin has lots of life left". Network World. Archived from the original on 31 May 2014. Retrieved 30 May 2014.
^ a bOppliger, Rolf (2016). "Introduction". SSL and TLS: Theory and Practice (2nd ed.). Artech House. p. 13. ISBN 978-1-60807-999-5. Retrieved 2018-03-01 – via Google Books.
^"THE SSL PROTOCOL". Netscape Corporation. 2007. Archived from the original on 14 June 1997.
^Rescorla 2001
^"POODLE: SSLv3 vulnerability (CVE-2014-3566)". Archived from the original on 5 December 2014. Retrieved 21 October 2014.
^"Security Standards and Name Changes in the Browser Wars". Archived from the original on 2020-02-29. Retrieved 2020-02-29.
^Laura K. Gray (2015-12-18). "Date Change for Migrating from SSL and Early TLS". Payment Card Industry Security Standards Council blog. Archived from the original on 2015-12-20. Retrieved 2018-04-05.
^"Changes to PCI Compliance are Coming June 30. Is Your Ecommerce Business Ready?". Forbes. Archived from the original on 2018-06-21. Retrieved 2018-06-20.
^T. Dierks; E. Rescorla (April 2006). The Transport Layer Security (TLS) Protocol Version 1.1. IETF TLS workgroup. doi:10.17487/RFC4346. RFC 4346. Historic. Obsoleted by RFC 5246. Obsoletes RFC 2246.
^ a b c"Transport Layer Security Parameters – Cipher Suites". Internet Assigned Numbers Authority (IANA). Archived from the original on 2016-12-21. Retrieved 2022-12-16.
^Mackie, Kurt. "Microsoft Delays End of Support for TLS 1.0 and 1.1 -". Microsoft Certified Professional Magazine Online. Archived from the original on 2021-06-14. Retrieved 2021-06-14.
^"TLS 1.2 FAQ – Knowledge Base". Answers.psionline.com. Archived from the original on 20 February 2022. Retrieved 20 February 2022.
^"Differences between TLS 1.2 and TLS 1.3 (#TLS13)". WolfSSL. 2019-09-18. Archived from the original on 2019-09-19. Retrieved 2019-09-18.
^"Archived copy". Archived from the original on 2024-03-17. Retrieved 2024-03-17.{{cite web}}: CS1 maint: archived copy as title (link)
^"NSS 3.29 release notes". Mozilla Developer Network. February 2017. Archived from the original on 2017-02-22.
^"Enable TLS 1.3 by default". Bugzilla@Mozilla. 16 October 2016. Archived from the original on 12 August 2018. Retrieved 10 October 2017.
^"Firefox — Notes (60.0)". Mozilla. Archived from the original on 2018-05-09. Retrieved 2018-05-10.
^"ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3". BlueTouch Online. 16 May 2017. Archived from the original on 12 September 2017. Retrieved 11 September 2017.
^Sullivan, Nick (2017-12-26). "Why TLS 1.3 isn't in browsers yet". The Cloudflare Blog. Archived from the original on 2017-12-26. Retrieved 2020-03-14.
^ a bThomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170.
^"TLS 1.3 IETF 100 Hackathon". Archived from the original on 2018-01-15.
^ a bIETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, archived from the original on 2021-10-28, retrieved 2017-11-14
^"Hurrah! TLS 1.3 is here. Now to implement it and put it into software". Archived from the original on 2018-03-27. Retrieved 2018-03-28.
^IETF – Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, archived from the original on 2021-10-28, retrieved 2018-07-18
^"wolfSSL TLS 1.3 BETA Release Now Available". [email protected]. 11 May 2017. Archived from the original on 9 July 2018. Retrieved 11 May 2017.
^"TLS 1.3 PROTOCOL SUPPORT". [email protected]. Archived from the original on 2018-07-09. Retrieved 2018-07-09.
^"TLS 1.3 Draft 28 Support in wolfSSL". [email protected]. 14 June 2018. Archived from the original on 9 July 2018. Retrieved 14 June 2018.
^"OpenSSL 1.1.1 Is Released". Matt Caswell. 11 Sep 2018. Archived from the original on 8 December 2018. Retrieved 19 Dec 2018.
^"Protocols in TLS/SSL (Schannel SSP)". Microsoft Docs. May 25, 2022. Archived from the original on 25 January 2023. Retrieved 21 February 2023.
^ a bHoffman-Andrews, Jacob (2019-02-26). "ETS Isn't TLS and You Shouldn't Use It". Electronic Frontier Foundation. Archived from the original on 2019-02-26. Retrieved 2019-02-27.
^TS 103 523-3 – V1.1.1 – CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control (PDF). ETSI.org. Archived (PDF) from the original on November 14, 2018.
^Cory Doctorow (February 26, 2019). "Monumental Recklessness". Boing Boing. Archived from the original on February 27, 2019.
^Rea, Scott (2013). "Alternatives to Certification Authorities for a Secure Web" (PDF). RSA Conference Asia Pacific. Archived (PDF) from the original on 7 October 2016. Retrieved 7 September 2016.
^"Counting SSL certificates". Archived from the original on 16 May 2015. Retrieved 20 February 2022.
^Raymond, Art (3 August 2017). "Lehi's DigiCert swallows web security competitor in $1 billion deal". Deseret News. Archived from the original on 29 September 2018. Retrieved 21 May 2020.
^"Market share trends for SSL certificate authorities". W3Techs. Retrieved 21 May 2020.
^Ryan Singel (March 24, 2010). "Law Enforcement Appliance Subverts SSL". wired.com. Archived from the original on April 12, 2014.
^Seth Schoen (March 24, 2010). "New Research Suggests That Governments May Fake SSL Certificates". EFF.org. Archived from the original on March 25, 2010.
^P. Eronen, Ed. (December 2005). Eronen, P; Tschofenig, H (eds.). Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. doi:10.17487/RFC4279. RFC 4279. Retrieved 9 September 2013.
^D. Taylor, Ed. (November 2007). Using the Secure Remote Password (SRP) Protocol for TLS Authentication. Internet Engineering Task Force. doi:10.17487/RFC5054. RFC 5054. Retrieved December 21, 2014.
^Gothard, Peter (31 July 2013). "Google updates SSL certificates to 2048-bit encryption". Computing. Incisive Media. Archived from the original on 22 September 2013. Retrieved 9 September 2013.
^"The value of 2,048-bit encryption: Why encryption key length matters". SearchSecurity. Archived from the original on 2018-01-16. Retrieved 2017-12-18.
^Sean Turner (September 17, 2015). "Consensus: remove DSA from TLS 1.3". Archived from the original on October 3, 2015.
^RFC 8422
^ a b c d e f gRFC 5830, 6986, 7091, 7801, 8891
^RFC 5288, 5289
^RFC 6655, 7251
^RFC 6367
^RFC 5932, 6367
^ a bRFC 6209
^RFC 4162
^"On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN" (PDF). 2016-10-28. Archived (PDF) from the original on 2017-04-24. Retrieved 2017-06-08.
^"NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)" (PDF). 2007-03-08. Archived from the original (PDF) on June 6, 2014. Retrieved 2014-07-03.
^ a b cQualys SSL Labs. "SSL/TLS Deployment Best Practices". Archived from the original on 4 July 2015. Retrieved 2 June 2015.
^RFC 5469
^RFC 7905
^"Http vs https". Archived from the original on 2015-02-12. Retrieved 2015-02-12.
^ a b c dAs of May 03, 2024. "SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites". Qualys. Archived from the original on 2021-03-08. Retrieved 2024-05-30.
^ a bivanr (19 March 2013). "RC4 in TLS is Broken: Now What?". Qualsys Security Labs. Archived from the original on 2013-08-27. Retrieved 2013-07-30.
^ a b cBodo Möller, Thai Duong & Krzysztof Kotowicz. "This POODLE Bites: Exploiting The SSL 3.0 Fallback" (PDF). Archived (PDF) from the original on 2014-10-14. Retrieved 2014-10-15.
^"Internet Explorer 11 has retired and is officially out of support—what you need to know". June 15, 2022. Archived from the original on 2022-06-15. Retrieved 2022-06-15.
^"Internet Explorer 11 desktop app support ended for certain versions of Windows 10". Retrieved 2022-06-17.
^"Java Secure Socket Extension (JSSE) Reference Guide". Oracle Help Center. Archived from the original on 2022-01-22. Retrieved 2021-12-24.
^Georgiev, Martin; Iyengar, Subodh; Jana, Suman; Anubhai, Rishita; Boneh, Dan; Shmatikov, Vitaly (2012). The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). Association for Computing Machinery. pp. 38–49. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2017-10-22.
^Audet, F. (2009). The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). doi:10.17487/RFC5630. RFC 5630.
^Sheffer, Y.; Holz, R.; Saint-Andre, P. (2015). Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). doi:10.17487/RFC7457. RFC 7457.
^"CVE – CVE-2009-3555". Archived from the original on 2016-01-04.
^Rescorla, Eric (2009-11-05). "Understanding the TLS Renegotiation Attack". Educated Guesswork. Archived from the original on 2012-02-11. Retrieved 2009-11-27.
^"SSL_CTX_set_options SECURE_RENEGOTIATION". OpenSSL Docs. 2010-02-25. Archived from the original on 2010-11-26. Retrieved 2010-11-18.
^"GnuTLS 2.10.0 released". GnuTLS release notes. 2010-06-25. Archived from the original on 2015-10-17. Retrieved 2011-07-24.
^"NSS 3.12.6 release notes". NSS release notes. 2010-03-03. Archived from the original on March 6, 2012. Retrieved 2011-07-24.
^A. Langley; N. Modadugu; B. Moeller (2010-06-02). "Transport Layer Security (TLS) False Start". Internet Engineering Task Force. IETF. Archived from the original on 2013-09-05. Retrieved 2013-07-31.
^Gruener, Wolfgang. "False Start: Google Proposes Faster Web, Chrome Supports It Already". Archived from the original on 2010-10-07. Retrieved 2011-03-09.
^Smith, Brian. "Limited rollback attacks in False Start and Snap Start". Archived from the original on 2011-05-04. Retrieved 2011-03-09.
^Dimcev, Adrian. "False Start". Random SSL/TLS 101. Archived from the original on 2011-05-04. Retrieved 2011-03-09.
^Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). Association for Computing Machinery. pp. 62–72. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2015-07-06.
^"SMACK: State Machine AttaCKs". Archived from the original on 2015-03-12.
^Goodin, Dan (2015-05-20). "HTTPS-crippling attack threatens tens of thousands of Web and mail servers". Ars Technica. Archived from the original on 2017-05-19.
^Leyden, John (1 March 2016). "One-third of all HTTPS websites open to DROWN attack". The Register. Archived from the original on 1 March 2016. Retrieved 2016-03-02.
^ a b"More than 11 million HTTPS websites imperiled by new decryption attack". Ars Technica. March 2016. Archived from the original on 2016-03-01. Retrieved 2016-03-02.
^Thai Duong & Juliano Rizzo (2011-05-13). "Here Come The ⊕ Ninjas". Archived from the original on 2014-06-03.
^Goodin, Dan (2011-09-19). "Hackers break SSL encryption used by millions of sites". The Register. Archived from the original on 2012-02-10.
^"Y Combinator comments on the issue". 2011-09-20. Archived from the original on 2012-03-31.
^"Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures". 2004-05-20. Archived from the original on 2012-06-30.
^Ristic, Ivan (Sep 10, 2013). "Is BEAST Still a Threat?". Archived from the original on 12 October 2014. Retrieved 8 October 2014.
^"Chrome Stable Release". Chrome Releases. 2011-10-25. Archived from the original on 2015-02-20. Retrieved 2015-02-01.
^"Attack against TLS-protected communications". Mozilla Security Blog. Mozilla. 2011-09-27. Archived from the original on 2015-03-04. Retrieved 2015-02-01.
^Smith, Brian (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets-76)". Archived from the original on 2012-02-10. Retrieved 2011-11-01.
^MSRC (2012-01-10). Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584). Security Bulletins (Technical report). MS12-006. Retrieved 2021-10-24 – via Microsoft Docs.
^Ristic, Ivan (Oct 31, 2013). "Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks". Archived from the original on 12 October 2014. Retrieved 8 October 2014.
^Goodin, Dan (2012-09-13). "Crack in Internet's foundation of trust allows HTTPS session hijacking". Ars Technica. Archived from the original on 2013-08-01. Retrieved 2013-07-31.
^Fisher, Dennis (September 13, 2012). "CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions". ThreatPost. Archived from the original on September 15, 2012. Retrieved 2012-09-13.
^ a bGoodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Archived from the original on 3 August 2013. Retrieved 2 August 2013.
^Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Archived from the original on 5 August 2013. Retrieved 2 August 2013.
^P. Gutmann (September 2014). Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Internet Engineering Task Force. doi:10.17487/RFC7366. RFC 7366.
^Langley, Adam (December 8, 2014). "The POODLE bites again". Archived from the original on December 8, 2014. Retrieved 2014-12-08.
^"ssl – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune". Serverfault.com. Archived from the original on 20 February 2022. Retrieved 20 February 2022.
^Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Discovery and Exploitation of New Biases in RC4". In Alex Biryukov; Guang Gong; Douglas R. Stinson (eds.). Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canada, August 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. ISBN 978-3-642-19573-0.
^Green, Matthew (12 March 2013). "Attack of the week: RC4 is kind of broken in TLS". Cryptography Engineering. Archived from the original on March 14, 2013. Retrieved March 12, 2013.
^AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. "On the Security of RC4 in TLS". Royal Holloway University of London. Archived from the original on March 15, 2013. Retrieved March 13, 2013.
^AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013). "On the Security of RC4 in TLS and WPA" (PDF). Information Security Group. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013.
^AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). On the Security of RC4 in TLS (PDF). 22nd USENIX Security Symposium. p. 51. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013. Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical
^Goodin, Dan (15 July 2015). "Once-theoretical crypto attack against HTTPS now verges on practicality". Ars Technical. Conde Nast. Archived from the original on 16 July 2015. Retrieved 16 July 2015.
^"Mozilla Security Server Side TLS Recommended Configurations". Mozilla. Archived from the original on 2015-01-03. Retrieved 2015-01-03.
^"Security Advisory 2868725: Recommendation to disable RC4". Microsoft. 2013-11-12. Archived from the original on 2013-11-18. Retrieved 2013-12-04.
^"Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11". Microsoft Edge Team. September 1, 2015. Archived from the original on September 2, 2015.
^Langley, Adam (Sep 1, 2015). "Intent to deprecate: RC4". Archived from the original on May 23, 2013. Retrieved September 2, 2015.
^Barnes, Richard (Sep 1, 2015). "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22.
^ a bJohn Leyden (1 August 2013). "Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack". The Register. Archived from the original on 1 August 2013. Retrieved 1 August 2013.
^"BlackHat USA Briefings". Black Hat 2013. Archived from the original on 30 July 2013. Retrieved 1 August 2013.
^Smyth, Ben; Pironti, Alfredo (2013). Truncating TLS Connections to Violate Beliefs in Web Applications. 7th USENIX Workshop on Offensive Technologies (report). Archived from the original on 6 November 2015. Retrieved 15 February 2016.
^AlFardan, Nadhem; Paterson, Kenneth G (2012). Plaintext-recovery attacks against datagram TLS (PDF). Network and distributed system security symposium (NDSS 2012). Archived from the original on 2012-01-18.{{cite conference}}: CS1 maint: unfit URL (link)
^Goodin, Dan (26 July 2016). "New attack bypasses HTTPS protection on Macs, Windows, and Linux". Ars Technica. Condé Nast. Archived from the original on 27 July 2016. Retrieved 28 July 2016.
^Goodin, Dan (August 24, 2016). "HTTPS and OpenVPN face new attack that can decrypt secret cookies". Ars Technica. Archived from the original on August 24, 2016. Retrieved August 24, 2016.
^"Why is it called the 'Heartbleed Bug'?". The Washington Post. 2014-04-09. Archived from the original on 2014-10-09.
^"Heartbleed Bug vulnerability [9 April 2014]". Comodo Group. Archived from the original on 5 July 2014.
^Bleichenbacher, Daniel (August 2006). "Bleichenbacher's RSA signature forgery based on implementation error". Archived from the original on 2014-12-16.
^"BERserk". Intel Security: Advanced Threat Research. September 2014. Archived from the original on 2015-01-12.
^Goodin, Dan (February 19, 2015). "Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections". Ars Technica. Archived from the original on September 12, 2017. Retrieved December 10, 2017.
^Valsorda, Filippo (2015-02-20). "Komodia/Superfish SSL validation is broken". Filippo.io. Archived from the original on 2015-02-24.
^ a bGoodin, Dan (26 May 2016). ""Forbidden attack" makes dozens of HTTPS Visa sites vulnerable to tampering". Ars Technica. Archived from the original on 26 May 2016. Retrieved 26 May 2016.
^Clark Estes, Adam (February 24, 2017). "Everything You Need to Know About Cloudbleed, the Latest Internet Security Disaster". Gizmodo. Archived from the original on 2017-02-25. Retrieved 2017-02-24.
^Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges". Designs, Codes and Cryptography. 2 (2): 107–125. CiteSeerX10.1.1.59.6682. doi:10.1007/BF00124891. S2CID 7356608. Archived from the original on 2008-03-13. Retrieved 2008-02-11.
^"Discussion on the TLS mailing list in October 2007". Archived from the original on 22 September 2013. Retrieved 20 February 2022.
^"Protecting data for the long term with forward secrecy". Archived from the original on 2013-05-06. Retrieved 2012-11-05.
^Bernat, Vincent (28 November 2011). "SSL/TLS & Perfect Forward Secrecy". Archived from the original on 2012-08-27. Retrieved 2012-11-05.
^"SSL Labs: Deploying Forward Secrecy". Qualys.com. 2013-06-25. Archived from the original on 2013-06-26. Retrieved 2013-07-10.
^Ristic, Ivan (2013-08-05). "SSL Labs: Deploying Forward Secrecy". Qualsys. Archived from the original on 2013-09-20. Retrieved 2013-08-31.
^ a bLangley, Adam (27 June 2013). "How to botch TLS forward secrecy". imperialviolet.org. Archived from the original on 8 August 2013.
^ a bDaignière, Florent. "TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL" (PDF). Matta Consulting Limited. Archived (PDF) from the original on 6 August 2013. Retrieved 7 August 2013.
^ a bDaignière, Florent. "TLS "Secrets": What everyone forgot to tell you…" (PDF). Matta Consulting Limited. Archived (PDF) from the original on 5 August 2013. Retrieved 7 August 2013.
^L.S. Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "An Experimental Study of TLS Forward Secrecy Deployments". IEEE Internet Computing. 18 (6): 43–51. CiteSeerX10.1.1.663.4653. doi:10.1109/MIC.2014.86. S2CID 11264303. Archived from the original on 20 September 2015. Retrieved 16 October 2015.
^"Protecting data for the long term with forward secrecy". Archived from the original on 2014-02-12. Retrieved 2014-03-07.
^Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Archived from the original on 2014-02-16. Retrieved 2014-03-07.
^ a b cDurumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 September 2017). "The Security Impact of HTTPS Interception". NDSS Symposium. doi:10.14722/ndss.2017.23456. ISBN 978-1-891562-46-4. Archived from the original on 22 March 2019. Retrieved 11 March 2019.
^ a bThese certificates are currently X.509, but RFC 6091 also specifies the use of OpenPGP-based certificates.
^"tls – Differences between the terms "pre-master secret", "master secret", "private key", and "shared secret"?". Cryptography Stack Exchange. Archived from the original on 2020-09-22. Retrieved 2020-10-01.
^Chris (2009-02-18). "vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication". Scarybeastsecurity. blogspot.com. Archived from the original on 2012-07-07. Retrieved 2012-05-17.
^Rescorla, Eric (August 2018). "Cryptographic Negotiation". The Transport Layer Security (TLS) Protocol Version 1.3. IETF. sec. 4.1.1. doi:10.17487/RFC8446. RFC 8446.
^Valsorda, Filippo (23 September 2016). "An overview of TLS 1.3 and Q&A". The Cloudflare Blog. Archived from the original on 3 May 2019. Retrieved 3 May 2019.
^Wildcard SSL Certificate overview, archived from the original on 2015-06-23, retrieved 2015-07-02
^Named-based SSL virtual hosts: how to tackle the problem (PDF), archived (PDF) from the original on 2012-08-03, retrieved 2012-05-17
Further reading
Wikimedia Commons has media related to SSL and TLS.
Wagner, David; Schneier, Bruce (November 1996). "Analysis of the SSL 3.0 Protocol" (PDF). The Second USENIX Workshop on Electronic Commerce Proceedings. USENIX Press. pp. 29–40. Archived (PDF) from the original on 2006-10-16. Retrieved 2006-10-12.
Rescorla, Eric (2001). SSL and TLS: Designing and Building Secure Systems. United States: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2.
Stephen A. Thomas (2000). SSL and TLS essentials securing the Web. New York: Wiley. ISBN 978-0-471-38354-3.
Bard, Gregory (2006). "A Challenging But Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL". International Association for Cryptologic Research (136). Archived from the original on 2011-09-23. Retrieved 2011-09-23.
Canvel, Brice. "Password Interception in a SSL/TLS Channel". Archived from the original on 2016-04-20. Retrieved 2007-04-20.
RFC of change for TLS Renegotiation. 2010. doi:10.17487/RFC5746. RFC 5746.
Creating VPNs with IPsec and SSL/TLS Archived 2015-04-12 at the Wayback Machine Linux Journal article by Rami Rosen
Joshua Davies (2010). Implementing SSL/TLS. Wiley. ISBN 978-0470920411.
Polk, Tim; McKay, Kerry; Chokhani, Santosh (April 2014). "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" (PDF). National Institute of Standards and Technology. Archived from the original (PDF) on 2014-05-08. Retrieved 2014-05-07.
Abdou, AbdelRahman; van Oorschot, Paul (August 2017). "Server Location Verification (SLV) and Server Location Pinning: Augmenting TLS Authentication". ACM Transactions on Privacy and Security. 21 (1): 1:1–1:26. doi:10.1145/3139294. S2CID 5869541. Archived from the original on 2019-03-22. Retrieved 2018-01-11.
Ivan Ristic (2022). Bulletproof TLS and PKI, Second Edition. Feisty Duck. ISBN 978-1907117091.
Primary standards
The current approved version of (D)TLS is version 1.3, which are specified in:
RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
RFC 9147: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"
The current standards replaces these former versions, which are now considered obsolete:
RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
RFC 6347: "Datagram Transport Layer Security Version 1.2"
RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".
RFC 4347" "Datagram Transport Layer Security"
RFC 2246: "The TLS Protocol Version 1.0".
RFC 6101: "The Secure Sockets Layer (SSL) Protocol Version 3.0".
Internet Draft (1995): "The SSL Protocol"
Extensions
Other RFCs subsequently extended (D)TLS.
Extensions to (D)TLS 1.3 include:
RFC 9367: "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3".
RFC 5081: "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", obsoleted by RFC 6091.
RFC 5216: "The EAP-TLS Authentication Protocol"
Extensions to TLS 1.0 include:
RFC 2595: "Using TLS with IMAP, POP3 and ACAP". Specifies an extension to the IMAP, POP3 and ACAP services that allow the server and client to use transport-layer security to provide private, authenticated communication over the Internet.
RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". The 40-bit cipher suites defined in this memo appear only for the purpose of documenting the fact that those cipher suite codes have already been assigned.
RFC 2817: "Upgrading to TLS Within HTTP/1.1", explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).
RFC 2818: "HTTP Over TLS", distinguishes secured traffic from insecure traffic by the use of a different 'server port'.
RFC 3207: "SMTP Service Extension for Secure SMTP over Transport Layer Security". Specifies an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet.
RFC 3268: "AES Ciphersuites for TLS". Adds Advanced Encryption Standard (AES) cipher suites to the previously existing symmetric ciphers.
RFC 3546: "Transport Layer Security (TLS) Extensions", adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by RFC 4366.
RFC 3749: "Transport Layer Security Protocol Compression Methods", specifies the framework for compression methods and the DEFLATE compression method.
RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", adds three sets of new cipher suites for the TLS protocol to support authentication based on pre-shared keys.
Informational RFCs
RFC 7457: "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)"
RFC 7525: "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
External links
Internet Engineering Task Force – TLS Workgroup Archived 2014-01-11 at the Wayback Machine
