Безопасность транспортного уровня - Transport Layer Security

Безопасность транспортного уровня (TLS), и его теперь устаревший предшественник, Уровень защищенных гнезд (SSL),^[1] находятся криптографические протоколы предназначен для обеспечения безопасность связи через компьютерная сеть.^[2] Несколько версий протоколов широко используются в таких приложениях, как просмотр веб-страниц, электронное письмо, обмен мгновенными сообщениями и передача голоса по IP (VoIP). Веб-сайты могут использовать TLS для защиты всех сообщений между своими серверы и веб-браузеры.

Протокол TLS в первую очередь предназначен для Конфиденциальность и целостность данных между двумя или более взаимодействующими компьютерными приложениями.^[2]:3 При защите с помощью TLS соединения между клиентом (например, веб-браузером) и сервером (например, wikipedia.org) должны иметь одно или несколько из следующих свойств:

• Связь частный (или же безопасный) потому что симметричная криптография используется, чтобы зашифровать переданные данные. В ключи для этого симметричного шифрования генерируются уникально для каждого соединения и основаны на поделился секретом это было согласовано в начале сессия (увидеть § Рукопожатие TLS ). Сервер и клиент согласовывают детали того, какой алгоритм шифрования и криптографические ключи использовать перед первым байт данных передается (см. § Алгоритмы ниже). Согласование общего секрета является безопасным (согласованный секрет недоступен для подслушивающие и не может быть получен даже злоумышленником, который находится в середине соединения) и надежен (злоумышленник не может изменить обмен данными во время переговоров, не будучи обнаруженным).
• Личность сообщающихся сторон может быть аутентифицированный с помощью криптография с открытым ключом. Эту аутентификацию можно сделать необязательной, но обычно она требуется по крайней мере для одной из сторон (обычно сервера).
• Связь надежный поскольку каждое переданное сообщение включает проверку целостности сообщения с использованием код аутентификации сообщения для предотвращения необнаруженной потери или изменения данных во время коробка передач.^[2]:3

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

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

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

Протокол TLS состоит из двух уровней: Запись TLS и Рукопожатие TLS протоколы.

TLS - это предлагаемая рабочая группа по развитию Интернета (IETF ) стандарт, впервые определен в 1999 году, а текущая версия - TLS 1.3, определенная в RFC  8446 (Август 2018 г.). TLS основан на более ранних спецификациях SSL (1994, 1995, 1996), разработанных Netscape Communications^[5]для добавления HTTPS протокол к их Навигатор веб-браузер.

Описание

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

Поскольку приложения могут обмениваться данными с TLS (или SSL) или без него, это необходимо для клиент указать сервер настройка TLS-соединения.^[6] Один из основных способов добиться этого - использовать другой номер порта для соединений TLS, например порт 443 для HTTPS. Другой механизм заключается в том, что клиент делает запрос к серверу для переключения соединения на TLS; например, сделав STARTTLS запрос при использовании почты и Новости протоколы.

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

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

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

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

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

Система безопасной передачи данных

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

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

Ранние исследования в области безопасности транспортного уровня включали Безопасное сетевое программирование (SNP) интерфейс прикладного программирования (API), который в 1993 году исследовал подход к созданию API безопасного транспортного уровня, очень похожего на Розетки Berkeley, чтобы облегчить модернизацию уже существующих сетевых приложений с помощью мер безопасности.^[15]

SSL 1.0, 2.0 и 3.0

Netscape разработала оригинальные протоколы SSL и Тахер Эльгамал, главный научный сотрудник Netscape Communications с 1995 по 1998 год, был назван «отцом SSL».^{[16][17][18][19]} Версия 1.0 SSL никогда не выпускалась публично из-за серьезных недостатков безопасности в протоколе. Версия 2.0, выпущенная в феврале 1995 года, содержала ряд недостатков в системе безопасности, которые потребовали разработки версии 3.0.^[20][18] Выпущенная в 1996 году версия SSL 3.0 представляла собой полную переработку протокола, разработанного Пол Кохер работал с инженерами Netscape Филом Карлтоном и Аланом Фрейером, используя эталонную реализацию Кристофера Аллена и Тима Диркса из Consensus Development. Более новые версии SSL / TLS основаны на SSL 3.0. Проект SSL 3.0 1996 г. был опубликован IETF как исторический документ в RFC  6101.

SSL 2.0 устарел в 2011 г. RFC  6176. В 2014 году было обнаружено, что SSL 3.0 уязвим для ПУДЕЛЬ атака, которая затрагивает всех блочные шифры в SSL; RC4, единственный неблочный шифр, поддерживаемый SSL 3.0, также может быть взломан, как и в SSL 3.0.^[21] Поддержка SSL 3.0 была прекращена в июне 2015 г. RFC  7568.

TLS 1.0

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

TLS 1.0 включает средства, с помощью которых реализация TLS может понизить уровень соединения до SSL 3.0, тем самым ослабив безопасность.^[23]:1–2

В Совет PCI предложил организациям перейти с TLS 1.0 на TLS 1.1 или выше до 30 июня 2018 г.^[24][25] В октябре 2018 г. яблоко, Google, Microsoft, и Mozilla совместно объявили о прекращении поддержки TLS 1.0 и 1.1 в марте 2020 года.^[11]

TLS 1.1

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

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

TLS 1.2

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

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

Все версии TLS были дополнительно доработаны в RFC  6176 в марте 2011 года, удалив их обратную совместимость с SSL, так что сеансы TLS никогда не согласовывают использование Secure Sockets Layer (SSL) версии 2.0.

TLS 1.3

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

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

Услуги сетевой безопасности (NSS), криптографическая библиотека, разработанная Mozilla и используется его веб-браузером Fire Fox, включил TLS 1.3 по умолчанию в феврале 2017 года.^[29] Впоследствии была добавлена ​​поддержка TLS 1.3, но из-за проблем с совместимостью для небольшого числа пользователей не была включена автоматически^[30] - чтобы Firefox 52.0, который был выпущен в марте 2017 года. TLS 1.3 был включен по умолчанию в мае 2018 года с выпуском Firefox 60.0.^[31]

Гугл Хром установить TLS 1.3 в качестве версии по умолчанию на короткое время в 2017 году. Затем он удалил его по умолчанию из-за несовместимости промежуточных ящиков, таких как Веб-прокси Blue Coat.^[32]

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

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

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

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

В Фонд электронных рубежей похвалил TLS 1.3 и выразил озабоченность по поводу варианта протокола Безопасность транспорта предприятия (ETS), который намеренно отключает важные меры безопасности в TLS 1.3.^[41] ETS - это опубликованный стандарт, известный как ETSI TS103523-3, «Протокол безопасности промежуточного ящика, часть 3: безопасность транспорта предприятия» и предназначен для использования исключительно в частных сетях, таких как банковские системы, для обнаружения размещения вредоносных программ, незаконной кражи данных и соблюдения нормативных требований в отношении аудита.

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

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

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

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

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

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

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

Алгоритмы

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

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

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

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

Шифр

Примечания

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

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

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

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

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

Сайты

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

Примечания

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

По состоянию на апрель 2016 г.^{[Обновить]}, последние версии всех основных веб-браузеров поддерживают TLS 1.0, 1.1 и 1.2, и по умолчанию они включены. Однако не все поддерживаются Операционные системы Microsoft поддерживает последнюю версию IE. Кроме того, многие операционные системы в настоящее время поддерживают несколько версий IE, но это изменилось в соответствии с Microsoft Часто задаваемые вопросы о политике жизненного цикла поддержки Internet Explorer, "начиная с 12 января 2016 года только самая последняя версия Internet Explorer, доступная для поддерживаемой операционной системы, будет получать техническую поддержку и обновления безопасности". Затем на странице отображается список последних поддерживаемых версий IE на указанную дату для каждой операционной системы. Следующая критическая дата наступит, когда операционная система достигнет стадии окончания жизненного цикла, что в Microsoft Информационный бюллетень о жизненном цикле Windows.

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

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

Примечания

Библиотеки

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

• BoringSSL, форк OpenSSL для Chrome / Chromium и Android, а также других приложений Google.
• Ботан, лицензированная BSD криптографическая библиотека, написанная на C ++.
• cryptlib: переносимая библиотека криптографии с открытым исходным кодом (включает реализацию TLS / SSL)
• Delphi программисты могут использовать библиотеку под названием Инди который использует OpenSSL или, альтернативно, ICS, который теперь поддерживает TLS 1.3.
• GnuTLS: бесплатная реализация (под лицензией LGPL)
• Расширение защищенного сокета Java: а Ява реализация включена в Среда выполнения Java поддерживал TLS 1.1 и 1.2, начиная с Java 7. (TLS 1.1 / 1.2 изначально были отключены по умолчанию для клиента на Java 7, но были включены в январе 2017 года.^[197]) Java 11 поддерживает TLS 1.3.^[198]
• LibreSSL: форк OpenSSL от проекта OpenBSD.
• MatrixSSL: реализация с двойной лицензией
• mbed TLS (ранее PolarSSL): крошечная реализация библиотеки SSL для встроенных устройств, которая разработана для простоты использования.
• Услуги сетевой безопасности: FIPS 140 проверенная библиотека с открытым исходным кодом
• OpenSSL: бесплатная реализация (лицензия BSD с некоторыми расширениями)
• RSA BSAFE Micro Edition Suite: мультиплатформенная реализация TLS, написанная на C с использованием проверенного FIPS криптографического модуля
• RSA BSAFE SSL-J: библиотека TLS, предоставляющая проприетарный API и JSSE API, с использованием проверенного FIPS криптографического модуля
• SChannel: реализация SSL и TLS Майкрософт Виндоус как часть его пакета.
• Безопасный транспорт: реализация SSL и TLS, используемых в OS X и iOS как часть их пакетов.
• wolfSSL (ранее CyaSSL): встроенная библиотека SSL / TLS с упором на скорость и размер.

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

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

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

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

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

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

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

SSL 2.0

В SSL 2.0 было несколько недостатков:^[226]

• Идентичные криптографические ключи использовались для проверка подлинности сообщения и шифрование. (В SSL 3.0 секреты MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивыми к взлому, даже если ключи шифрования сломаны.^[5])
• SSL 2.0 имел слабую структуру MAC, в которой использовалась хеш-функция MD5 с секретным префиксом, что делало его уязвимым для атаки удлинения длины.
• SSL 2.0 не имел никакой защиты для рукопожатия, то есть человек посередине атака на понижение версии может остаться незамеченным.
• SSL 2.0 использовал близкое TCP-соединение для обозначения конца данных. Это означало, что атаки с усечением были возможны: злоумышленник просто подделывает TCP FIN, оставляя получателя в неведении о незаконном конце сообщения с данными (SSL 3.0 устранил эту проблему с помощью явного предупреждения о закрытии).
• SSL 2.0 предполагал единую службу и фиксированный сертификат домена, что противоречило стандартной функции виртуального хостинга на веб-серверах. Это означает, что большинство веб-сайтов практически не смогли использовать SSL.

SSL 2.0 был отключен по умолчанию, начиная с Internet Explorer 7,^[227] Mozilla Firefox 2,^[228] Опера 9.5,^[229] и Сафари. Поддержка SSL 2.0 (и слабая 40 бит и 56-битные шифры) был полностью удален из Opera начиная с версии 10.^[230][231]

SSL 3.0

SSL 3.0 улучшен по сравнению с SSL 2.0 за счет добавления шифров на основе SHA-1 и поддержки аутентификации по сертификату.

С точки зрения безопасности SSL 3.0 следует считать менее желательным, чем TLS 1.0. Комплекты шифров SSL 3.0 имеют более слабый процесс получения ключей; половина установленного главного ключа полностью зависит от хэш-функции MD5, которая не устойчива к коллизиям и, следовательно, не считается безопасной. В рамках TLS 1.0 установленный главный ключ зависит как от MD5, так и от SHA-1, поэтому процесс его создания в настоящее время не считается слабым. По этой причине реализации SSL 3.0 не могут быть проверены в соответствии с FIPS 140-2.^[232]

В октябре 2014 года было сообщено об уязвимости в конструкции SSL 3.0, в результате чего режим работы CBC с SSL 3.0 стал уязвимым для атаки дополнением (см. # ПУДЕЛЬ нападение ).

TLS

TLS имеет ряд мер безопасности:

• Защита от понижения версии протокола до предыдущей (менее безопасной) версии или более слабого набора шифров.
• Нумерация последующих записей приложения с порядковым номером и использование этого порядкового номера в коды аутентификации сообщений (MAC).
• Использование дайджеста сообщения, дополненного ключом (чтобы только обладатель ключа мог проверить MAC). В HMAC конструкция, используемая большинством наборов шифров TLS, указана в RFC  2104 (SSL 3.0 использовал другой MAC-адрес на основе хэша).
• Сообщение, завершающее рукопожатие («Завершено»), отправляет хэш всех обмененных сообщений рукопожатия, увиденных обеими сторонами.
• В псевдослучайный функция разбивает входные данные пополам и обрабатывает каждый из них с помощью другого алгоритма хешированияMD5 и SHA-1 ), тогда XOR их вместе, чтобы создать MAC. Это обеспечивает защиту, даже если один из этих алгоритмов оказывается уязвимым.

Атаки на TLS / SSL

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

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

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

В августе 2009 года была обнаружена уязвимость процедуры повторного согласования, которая может привести к атакам путем внедрения открытого текста против SSL 3.0 и всех текущих версий TLS.^[234] Например, он позволяет злоумышленнику, который может перехватить https-соединение, вставить свои собственные запросы в начало разговора, который клиент ведет с веб-сервером. На самом деле злоумышленник не может расшифровать обмен данными клиент-сервер, поэтому он отличается от типичной атаки типа «человек посередине». Кратковременное исправление состоит в том, чтобы веб-серверы перестали разрешать повторное согласование, которое обычно не требует других изменений, если только сертификат клиента используется аутентификация. Чтобы исправить уязвимость, для TLS было предложено расширение индикации повторного согласования. Это потребует от клиента и сервера включения и проверки информации о предыдущих рукопожатиях в любые рукопожатия повторного согласования.^[235] Это расширение стало предлагаемым стандартом, и ему был присвоен номер RFC  5746. RFC реализован несколькими библиотеками.^{[236][237][238]}

Атаки на понижение версии: FREAK атака и Тупиковая атака

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

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

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

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

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

В DROWN атака - это эксплойт, который атакует серверы, поддерживающие современные наборы протоколов SSL / TLS, используя их поддержку устаревшего, небезопасного протокола SSLv2 для атаки на соединения с использованием современных протоколов, которые в противном случае были бы безопасными.^[246][247] DROWN использует уязвимость в используемых протоколах и конфигурации сервера, а не конкретную ошибку реализации. Полная информация о DROWN была объявлена ​​в марте 2016 года вместе с патчем для эксплойта. В то время более 81000 из 1 миллиона самых популярных веб-сайтов были среди веб-сайтов, защищенных TLS, которые были уязвимы для атаки DROWN.^[247]

ЗВЕРЬ атака

23 сентября 2011 года исследователи Тай Дуонг и Джулиано Риццо продемонстрировали доказательство концепции под названием ЗВЕРЬ (Использование браузера против SSL / TLS)^[248] с помощью Java-апплет нарушить та же политика происхождения ограничения, давно известные цепочка блоков шифра (CBC) уязвимость в TLS 1.0:^[249][250] злоумышленник, наблюдающий 2 последовательных блока зашифрованного текста C0, C1, может проверить, равен ли блок открытого текста P1 x, выбрав следующий блок открытого текста P2 = x ${ displaystyle oplus}$ C0 ${ displaystyle oplus}$ C1; согласно операции CBC, C2 = E (C1 ${ displaystyle oplus}$ P2) = E (C1 ${ displaystyle oplus}$ Икс ${ displaystyle oplus}$ C0 ${ displaystyle oplus}$ C1) = E (C0 ${ displaystyle oplus}$ x), который будет равен C1, если x = P1. Практичный подвиги ранее не демонстрировались для этого уязвимость, который был первоначально обнаружен Филип Рогавей^[251] в 2002 году. Уязвимость атаки была устранена с помощью TLS 1.1 в 2006 году, но TLS 1.1 не получил широкого распространения до демонстрации этой атаки.

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

Сами Chrome и Firefox не уязвимы для атаки BEAST,^[79][99] однако Mozilla обновила свои НСС библиотеки для смягчения BEAST-подобных нападения. NSS используется Mozilla Firefox и Гугл Хром для реализации SSL. Немного веб-серверы у которых нарушена реализация спецификации SSL, могут в результате перестать работать.^[253]

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

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

CRIME и BREACH атаки

Авторы атаки BEAST также являются создателями более позднего ПРЕСТУПЛЕНИЕ атака, которая может позволить злоумышленнику восстановить содержимое веб-файлов cookie, когда Сжатие данных используется вместе с TLS.^[256][257] Когда используется для восстановления содержимого секрета файлы cookie аутентификации, это позволяет злоумышленнику выполнить захват сеанса в аутентифицированном веб-сеансе.

В то время как атака CRIME была представлена ​​как общая атака, которая может эффективно работать против большого количества протоколов, включая, помимо прочего, TLS и протоколы прикладного уровня, такие как SPDY или HTTP, были продемонстрированы только эксплойты против TLS и SPDY, и в браузерах и на серверах они были существенно уменьшены. ПРЕСТУПЛЕНИЕ против HTTP-сжатие не была устранена вообще, хотя авторы CRIME предупредили, что эта уязвимость может быть даже более распространенной, чем сжатие SPDY и TLS вместе взятые. В 2013 году появился новый пример CRIME-атаки на HTTP-сжатие, получивший название НАРУШЕНИЕ, было объявлено. На основе CRIME-атаки, BREACH-атака может извлекать токены входа, адреса электронной почты или другую конфиденциальную информацию из зашифрованного TLS веб-трафика всего за 30 секунд (в зависимости от количества байтов, которые нужно извлечь), при условии, что злоумышленник обманом заставляет жертву посетить вредоносная веб-ссылка или может внедрять контент на действительные страницы, которые посещает пользователь (например, беспроводная сеть под контролем злоумышленника).^[258] Все версии TLS и SSL подвержены риску BREACH независимо от используемого алгоритма шифрования или шифра.^[259] В отличие от предыдущих экземпляров CRIME, от которых можно успешно защититься, отключив сжатие TLS или сжатие заголовков SPDY, BREACH использует сжатие HTTP, которое невозможно отключить, поскольку практически все веб-серверы полагаются на него для повышения скорости передачи данных для пользователей.^[258] Это известное ограничение TLS, поскольку он подвержен атака по выбранному открытому тексту от данных прикладного уровня, которые он должен был защищать.

Атаки по времени на заполнение

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

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

Исправление было выпущено как расширение Encrypt-then-MAC для спецификации TLS, выпущенное как RFC  7366.^[260] Атаку Lucky Thirteen можно смягчить в TLS 1.2, используя только шифры AES_GCM; AES_CBC остается уязвимым.^{[нужна цитата ]}

ПУДЕЛЬ нападение

14 октября 2014 г. исследователи Google опубликовали уязвимость в конструкции SSL 3.0, которая делает CBC режим работы с SSL 3.0 уязвим к атака набивкой (CVE -2014-3566 ). Они назвали эту атаку ПУДЕЛЬ (Дополнение Oracle к устаревшему шифрованию с пониженной версией). В среднем злоумышленникам нужно всего 256 запросов SSL 3.0, чтобы раскрыть один байт зашифрованных сообщений.^[69]

Хотя эта уязвимость существует только в SSL 3.0 и большинство клиентов и серверов поддерживают TLS 1.0 и выше, все основные браузеры добровольно переходят на SSL 3.0, если квитирование с более новыми версиями TLS не удается, если они не предоставляют пользователю или администратору возможность отключить SSL 3.0. и пользователь или администратор делает это^{[нужна цитата ]}. Поэтому человек посередине может сначала провести атака отката версии а затем использовать эту уязвимость.^[69]

В общем, постепенное снижение безопасности ради функциональной совместимости трудно осуществить таким образом, чтобы его нельзя было использовать. Это сложно, особенно в доменах с высокой фрагментацией.^[261]

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

RC4 атаки

Несмотря на наличие атак на RC4 что нарушило его безопасность, комплекты шифров в SSL и TLS, основанные на RC4, по-прежнему считались безопасными до 2013 года из-за того, как они использовались в SSL и TLS. В 2011 году пакет RC4 был рекомендован как временное решение для ЗВЕРЬ атака.^[263] Новые формы атак, раскрытые в марте 2013 года, убедительно продемонстрировали возможность взлома RC4 в TLS, предполагая, что это не лучший обходной путь для BEAST.^[68] Сценарий атаки был предложен АльФарданом, Бернстайном, Патерсоном, Поеттерингом и Шульдтом, в котором использовались недавно обнаруженные статистические ошибки в ключевой таблице RC4.^[264] для восстановления частей открытого текста с большим количеством шифрования TLS.^[265][266] Атака на RC4 в TLS и SSL, требующая 13 × 2²⁰ Шифрование для взлома RC4 было представлено 8 июля 2013 г. и позже описано как «выполнимое» в сопроводительной презентации на USENIX Симпозиум по безопасности в августе 2013 года.^[267][268] В июле 2015 года последующие улучшения в атаке сделали более практичным взлом безопасности TLS с шифрованием RC4.^[269]

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

1 сентября 2015 года Microsoft, Google и Mozilla объявили, что наборы шифров RC4 будут отключены по умолчанию в их браузерах (Microsoft Edge, Internet Explorer 11 в Windows 7 / 8.1 / 10, Fire Fox, и Хром ) в начале 2016 года.^{[272][273][274]}

Усеченная атака

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

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

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

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

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

Sweet32 атака

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

Ошибки реализации: Heartbleed ошибка, Атака BERserk, ошибка Cloudflare

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

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

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

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

В феврале 2017 года ошибка реализации, вызванная одним неверным символом в коде, используемом для синтаксического анализа HTML, привела к ошибке переполнения буфера на Cloudflare серверы. По своим эффектам похожая на ошибку Heartbleed, обнаруженную в 2014 году, эта ошибка переполнения, широко известная как Cloudbleed, позволяла неавторизованным третьим сторонам читать данные в памяти программ, запущенных на серверах, - данные, которые в противном случае должны были быть защищены TLS.^[287]

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

По состоянию на август 2019 г.^{[Обновить]}организация Trustworthy Internet Movement оценила долю веб-сайтов, уязвимых для TLS-атак.^[67]

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

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

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

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

Перехват TLS

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

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

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

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

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

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

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

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

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

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

Подтвержденное клиентом рукопожатие TLS

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

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

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

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

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

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

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

Сначала клиент отправляет на сервер сообщение clientHello, которое содержит список поддерживаемых шифров в порядке предпочтений клиента и делает предположение о том, какой алгоритм ключа будет использоваться, чтобы он мог отправить секретный ключ для совместного использования в случае необходимости. Угадывая, какой ключевой алгоритм будет использоваться, сервер исключает обход. После получения clientHello сервер отправляет serverHello со своим ключом, сертификатом, выбранным набором шифров и готовым сообщением.

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

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

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

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

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

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

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

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

Запись TLS

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