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

В этой статье обсуждается безопасность Безопасность транспортного уровня (TLS) интернет-протокол.

SSL 2.0

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

  • Идентичные криптографические ключи использовались для проверка подлинности сообщения и шифрование. (В SSL 3.0 секреты MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивыми к взлому, даже если ключи шифрования сломаны.[2])
  • 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,[3] Mozilla Firefox 2,[4] Опера 9.5,[5] и Сафари. Поддержка SSL 2.0 (и слабая 40 бит и 56-битные шифры) был полностью удален из Opera начиная с версии 10.[6][7]

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.[8]

В октябре 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.[9] обобщение различных известных атак на TLS / SSL.

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

В августе 2009 года была обнаружена уязвимость процедуры повторного согласования, которая может привести к атакам путем внедрения открытого текста против SSL 3.0 и всех текущих версий TLS.[10] Например, он позволяет злоумышленнику, который может перехватить https-соединение, вставить свои собственные запросы в начало разговора, который клиент ведет с веб-сервером. На самом деле злоумышленник не может расшифровать обмен данными клиент-сервер, поэтому он отличается от типичной атаки типа «человек посередине». Кратковременное исправление состоит в том, чтобы веб-серверы перестали разрешать повторное согласование, которое обычно не требует других изменений, если только сертификат клиента используется аутентификация. Чтобы исправить уязвимость, для TLS было предложено расширение индикации повторного согласования. Это потребует от клиента и сервера включения и проверки информации о предыдущих рукопожатиях в любые рукопожатия повторного согласования.[11] Это расширение стало предлагаемым стандартом, и ему был присвоен номер RFC  5746. RFC реализован несколькими библиотеками.[12][13][14]

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

Основные статьи: НЕНОРМАЛЬНЫЙ и Logjam (компьютерная безопасность)

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

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

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

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

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

Основная статья: DROWN атака

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

ЗВЕРЬ атака

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

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

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

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

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

CRIME и BREACH атаки

Основные статьи: ПРЕСТУПЛЕНИЕ и НАРУШЕНИЕ

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

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

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

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

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

Исправление было выпущено как расширение Encrypt-then-MAC для спецификации TLS, выпущенное как RFC  7366.[39] Атаку 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, чтобы раскрыть один байт зашифрованных сообщений.[40]

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

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

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

RC4 атаки

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

Несмотря на наличие атак на RC4 что нарушило его безопасность, комплекты шифров в SSL и TLS, основанные на RC4, по-прежнему считались безопасными до 2013 года из-за того, как они использовались в SSL и TLS. В 2011 году пакет RC4 был рекомендован как временное решение для ЗВЕРЬ атака.[43] Новые формы атак, раскрытые в марте 2013 года, убедительно продемонстрировали возможность взлома RC4 в TLS, предполагая, что это не лучший обходной путь для BEAST.[44] Сценарий атаки был предложен АльФарданом, Бернстайном, Патерсоном, Поеттерингом и Шульдтом, в котором использовались недавно обнаруженные статистические ошибки в ключевой таблице RC4.[45] для восстановления частей открытого текста с большим количеством шифрований TLS.[46][47] Атака на RC4 в TLS и SSL, требующая 13 × 220 Шифрование для взлома RC4 было представлено 8 июля 2013 года и позже описано как «выполнимое» в сопроводительной презентации на USENIX Симпозиум по безопасности в августе 2013 года.[48][49] В июле 2015 года последующие улучшения в атаке сделали более практичным взлом безопасности TLS с шифрованием RC4.[50]

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

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

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

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

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

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

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

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

Sweet32 атака

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

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

Основные статьи: Heartbleed и Cloudbleed

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

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

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

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

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

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

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

Обзор TLS-уязвимостей наиболее популярных сайтов
АтакиБезопасность
НенадежныйЗависит отБезопасныйДругой
Атака повторного согласования0.4%
поддерживать небезопасное повторное согласование		0.4%
поддерживать оба		98.3%
поддерживать безопасное повторное согласование		1.2%
без поддержки
RC4 атаки1.3%
поддержка пакетов RC4, используемых с современными браузерами		12.6%
поддержка некоторых наборов RC4		86.1%
без поддержки		Нет данных
Сжатие TLS (ПРЕСТУПНАЯ атака)0.1%
уязвимый		Нет данныхНет данныхНет данных
Heartbleed<0.1%
уязвимый		Нет данныхНет данныхНет данных
Инъекционная атака ChangeCipherSpec0.2%
уязвимый и эксплуатируемый		1.3%
уязвимый, не пригодный для эксплуатации		96.8%
не уязвим		1.8%
неизвестный
Атака POODLE на TLS
(Оригинальный POODLE против SSL 3.0 не включен)		0.3%
уязвимый и эксплуатируемый		Нет данных98.3%
не уязвим		1.4%
неизвестный
Понижение версии протокола11.7%
Защита от перехода на более раннюю версию не поддерживается		Нет данных72.0%
Защита от понижения версии поддерживается		16.3%
неизвестный

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

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

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

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

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

Перехват TLS

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

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

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

Рекомендации

  1. ^ Йорис Классенс; Валентин Дем; Дэнни Де Кок; Барт Пренил; Джоос Вандевалле (2002). «О безопасности современных электронных банковских систем» (PDF). Компьютеры и безопасность. 21 (3): 253–265. Дои:10.1016 / S0167-4048 (02) 00312-7.
  2. ^ А. Фрейер; П. Карлтон; П. Кочер (август 2011 г.). «Протокол уровня защищенных сокетов (SSL) версии 3.0». В архиве из оригинала от 15.01.2012.
  3. ^ Лоуренс, Эрик (2005-10-22). «IEBlog: предстоящие улучшения HTTPS в Internet Explorer 7 Beta 2». MSDN Блоги. В архиве из оригинала от 17.04.2013. Получено 2007-11-25.
  4. ^ «Bugzilla @ Mozilla - Ошибка 236933 - отключение SSL2 и других слабых шифров». Mozilla Corporation. Получено 2007-11-25.
  5. ^ «История изменений Opera 9.5 для Windows» В архиве 2009-06-26 на Wayback Machine в Opera.com: "Отключен SSL v2 и слабые шифры."
  6. ^ «История изменений Opera 10 для Windows» В архиве 2013-03-26 в Wayback Machine в Opera.com: "Убрана поддержка SSL v2 и слабых шифров"
  7. ^ Петтерсен, Ингве (30 апреля 2007 г.). «10 лет SSL в Opera - примечания разработчика». Программное обеспечение Opera. Архивировано из оригинал 12 октября 2007 г.. Получено 2007-11-25.
  8. ^ Национальный институт стандартов и технологий (декабрь 2010 г.). «Руководство по внедрению FIPS PUB 140-2 и программы проверки криптографических модулей» (PDF). Архивировано из оригинал (PDF) 6 ноября 2010 г.
  9. ^ «Обобщение известных атак на безопасность транспортного уровня (TLS) и датаграмму TLS (DTLS)». RFC  7457. В архиве из оригинала от 04.03.2016.
  10. ^ "CVE - CVE-2009-3555". В архиве из оригинала от 04.01.2016.
  11. ^ Эрик Рескорла (2009-11-05). «Понимание атаки повторного согласования TLS». Образованные догадки. В архиве из оригинала от 09.02.2012. Получено 2009-11-27.
  12. ^ "SSL_CTX_set_options SECURE_RENEGOTIATION". Документы OpenSSL. 2010-02-25. В архиве из оригинала 26.11.2010. Получено 2010-11-18.
  13. ^ «Выпущен GnuTLS 2.10.0». Примечания к выпуску GnuTLS. 2010-06-25. В архиве из оригинала от 09.02.2012. Получено 2011-07-24.
  14. ^ «Примечания к выпуску NSS 3.12.6». Примечания к выпуску NSS. 2010-03-03. Архивировано из оригинал 6 марта 2012 г.. Получено 2011-07-24.
  15. ^ А. Лэнгли; Н. Модадугу; Б. Мёллер (02.06.2010). «Фальстарт безопасности транспортного уровня (TLS)». Инженерная группа Интернета. IETF. В архиве из оригинала от 05.09.2013. Получено 2013-07-31.
  16. ^ Грюнер, Вольфганг. «Ложный старт: Google предлагает более быстрый Интернет, Chrome уже поддерживает». Архивировано из оригинал на 2010-10-07. Получено 2011-03-09.
  17. ^ Смит, Брайан. «Атаки с ограниченным откатом при ложном запуске и мгновенном запуске». В архиве из оригинала 2011-05-04. Получено 2011-03-09.
  18. ^ Димцев, Адриан. "Фальстарт". Случайный SSL / TLS 101. В архиве из оригинала 2011-05-04. Получено 2011-03-09.
  19. ^ Маврогианнопулос, Никос; Веркаутерн, Фредерик; Величков, Веселин; Пренил, Барт (2012). Межпротокольная атака на протокол TLS. Материалы конференции ACM 2012 г. по компьютерной и коммуникационной безопасности (PDF). С. 62–72. ISBN  978-1-4503-1651-4. В архиве (PDF) из оригинала от 06.07.2015.
  20. ^ "SMACK: AttaCK государственного автомата". В архиве из оригинала от 12.03.2015.
  21. ^ Гудин, Дэн (2015-05-20). «Атака, разрушающая HTTPS, угрожает десяткам тысяч веб-серверов и почтовых серверов». Ars Technica. В архиве из оригинала от 19.05.2017.
  22. ^ Лейден, Джон (1 марта 2016 г.). «Треть всех HTTPS-сайтов открыта для атаки DROWN». Реестр. В архиве из оригинала на 1 марта 2016 г.. Получено 2016-03-02.
  23. ^ а б «Более 11 миллионов веб-сайтов HTTPS подверглись опасности новой атаки дешифрования». Ars Technica. В архиве из оригинала на 2016-03-01. Получено 2016-03-02.
  24. ^ Тай Дуонг и Джулиано Риццо (13.05.2011). "Вот иди ниндзя". В архиве из оригинала от 03.06.2014.
  25. ^ Дэн Гудин (19 сентября 2011 г.). «Хакеры взламывают шифрование SSL, используемое миллионами сайтов». В архиве из оригинала от 09.02.2012.
  26. ^ "Y Combinator комментирует проблему". 2011-09-20. В архиве из оригинала от 17.04.2013.
  27. ^ «Безопасность CBC Ciphersuites в SSL / TLS: проблемы и меры противодействия». 2004-05-20. Архивировано из оригинал на 30.06.2012.
  28. ^ Ристич, Иван (10 сентября, 2013). "ЗВЕРЬ все еще угроза?". В архиве из оригинала 12 октября 2014 г.. Получено 8 октября 2014.
  29. ^ «Стабильная версия Chrome». Выпуски Chrome. 2011-10-25. В архиве из оригинала от 20.02.2015. Получено 2015-02-01.
  30. ^ «Атака на TLS-защищенные коммуникации». Блог о безопасности Mozilla. Mozilla. 2011-09-27. В архиве из оригинала от 04.03.2015. Получено 2015-02-01.
  31. ^ Брайан Смит (30 сентября 2011 г.). «(CVE-2011-3389) Rizzo / Duong выбрал атаку с открытым текстом (BEAST) на SSL / TLS 1.0 (при поддержке websockets -76)».
  32. ^ «Уязвимость в SSL / TLS может привести к раскрытию информации (2643584)». 2012-01-10. В архиве из оригинала 15.08.2014.
  33. ^ Ристич, Иван (31 октября 2013 г.). «Apple включила средства защиты от BEAST в OS X 10.9 Mavericks». В архиве из оригинала 12 октября 2014 г.. Получено 8 октября 2014.
  34. ^ Дэн Гудин (13 сентября 2012). «Взлом в основе доверия Интернета позволяет перехватить сеанс HTTPS». Ars Technica. В архиве из оригинала от 01.08.2013. Получено 2013-07-31.
  35. ^ Деннис Фишер (13 сентября 2012 г.). «Атака CRIME использует степень сжатия запросов TLS в качестве побочного канала для взлома защищенных сеансов». ThreatPost. Архивировано из оригинал 15 сентября 2012 г.. Получено 2012-09-13.
  36. ^ а б Гудин, Дэн (1 августа 2013 г.). «Угнать за 30 секунд: новая атака извлекает секреты со страниц, защищенных HTTPS». Ars Technica. Condé Nast. В архиве из оригинала от 3 августа 2013 г.. Получено 2 августа 2013.
  37. ^ Лейден, Джон (2 августа 2013 г.). «Шагните в ПРОРЫВ: новая атака, разработанная для чтения зашифрованных веб-данных». Реестр. В архиве из оригинала 5 августа 2013 г.. Получено 2 августа 2013.
  38. ^ а б Qualys SSL Labs. «Рекомендации по развертыванию SSL / TLS». В архиве из оригинала 4 июля 2015 г.. Получено 2 июн 2015.
  39. ^ П. Гутманн (сентябрь 2014 г.). «Шифрование, затем MAC для безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)». В архиве из оригинала от 12.05.2015.
  40. ^ а б Бодо Мёллер, Тайский дуонг и Кшиштоф Котович. "Укусы этого пуделя: использование запасного варианта SSL 3.0" (PDF). В архиве (PDF) с оригинала на 2014-10-14. Получено 2014-10-15.
  41. ^ Хагай Бар-Эл. «Ошибка пуделя и Интернет вещей». В архиве из оригинала 16 марта 2015 г.. Получено 15 октября 2014.
  42. ^ Лэнгли, Адам (8 декабря 2014 г.). «ПУДЕЛЬ снова кусает». В архиве с оригинала 8 декабря 2014 г.. Получено 2014-12-08.
  43. ^ безопасность - Самые безопасные шифры для использования с BEAST? (Эксплойт TLS 1.0) Я читал, что RC4 невосприимчив - Ошибка сервера
  44. ^ ivanr. "RC4 в TLS сломан: что теперь?". Qualsys Security Labs. В архиве из оригинала от 27.08.2013. Получено 2013-07-30.
  45. ^ Пуйан Сепехрдад; Серж Воденэ; Мартин Вуаньу (2011). Обнаружение и использование новых предубеждений в RC4. Конспект лекций по информатике. 6544. С. 74–91. Дои:10.1007/978-3-642-19574-7_5. ISBN  978-3-642-19573-0.
  46. ^ Грин, Мэтью. «Атака недели: RC4 как бы взломан в TLS». Криптография Инжиниринг. В архиве из оригинала 14 марта 2013 г.. Получено 12 марта, 2013.
  47. ^ Надхем АльФардан, Дэн Бернштейн, Кенни Патерсон, Бертрам Поеттеринг и Джейкоб Шульдт. «О безопасности RC4 в TLS». Лондонский Королевский университет Холлоуэй. В архиве из оригинала 15 марта 2013 г.. Получено 13 марта, 2013.CS1 maint: несколько имен: список авторов (связь)
  48. ^ AlFardan, Nadhem J .; Бернштейн, Даниэль Дж .; Paterson, Kenneth G .; Поэттинг, Бертрам; Шульдт, Джейкоб С. Н. (8 июля 2013 г.). «О безопасности RC4 в TLS и WPA» (PDF). В архиве (PDF) из оригинала 22 сентября 2013 г.. Получено 2 сентября 2013. Цитировать журнал требует | журнал = (помощь)
  49. ^ AlFardan, Nadhem J .; Бернштейн, Даниэль Дж .; Paterson, Kenneth G .; Поэттинг, Бертрам; Шульдт, Джейкоб С. Н. (15 августа 2013 г.). О безопасности RC4 в TLS (PDF). 22-е USENIX Симпозиум по безопасности. п. 51. В архиве (PDF) из оригинала 22 сентября 2013 г.. Получено 2 сентября 2013. Атаки восстановления открытого текста на RC4 в TLS возможны, но не совсем практичны
  50. ^ Гудин, Дэн. «Когда-то теоретическая крипто-атака на HTTPS теперь граничит с практичностью». Ars Technical. Conde Nast. В архиве из оригинала 16 июля 2015 г.. Получено 16 июля 2015.
  51. ^ «Рекомендуемые конфигурации TLS на стороне сервера Mozilla Security». Mozilla. В архиве из оригинала от 03.01.2015. Получено 2015-01-03.
  52. ^ «Рекомендация по безопасности 2868725: Рекомендация по отключению RC4». Microsoft. 2013-11-12. В архиве из оригинала 18.11.2013. Получено 2013-12-04.
  53. ^ «Прекращение поддержки шифра RC4 в Microsoft Edge и Internet Explorer 11». Команда Microsoft Edge. 1 сентября 2015 года. В архиве из оригинала от 2 сентября 2015 г.
  54. ^ Лэнгли, Адам (1 сентября 2015 г.). «Намерение отказаться от поддержки: RC4».
  55. ^ Барнс, Ричард (1 сентября 2015 г.). «Намерение отправить: RC4 отключен по умолчанию в Firefox 44». В архиве из оригинала от 22.01.2011.
  56. ^ а б Джон Лейден (1 августа 2013 г.). «Gmail, Outlook.com и электронное голосование« взломали »на сцене в результате взлома криптовалюты». Реестр. В архиве из оригинала от 1 августа 2013 г.. Получено 1 августа 2013.
  57. ^ "Брифинги BlackHat USA". Черная шляпа 2013. В архиве из оригинала 30 июля 2013 г.. Получено 1 августа 2013.
  58. ^ Смит, Бен; Пиронти, Альфредо (2013). «Усечение TLS-соединений для нарушения убеждений в веб-приложениях». 7-й семинар USENIX по наступательным технологиям. В архиве из оригинала от 6 ноября 2015 г.. Получено 15 февраля 2016.
  59. ^ Гудин, Дэн. «Новая атака обходит защиту HTTPS на Mac, Windows и Linux». Ars Technica. Condé Nast. В архиве из оригинала 27 июля 2016 г.. Получено 28 июля 2016.
  60. ^ Гудин, Дэн (24 августа 2016 г.). «HTTPS и OpenVPN сталкиваются с новой атакой, которая может расшифровать секретные файлы cookie». Ars Technica. В архиве с оригинала 24 августа 2016 г.. Получено 24 августа, 2016.
  61. ^ «Почему это называется« Heartbleed Bug »?». Вашингтон Пост. 2014-04-09. В архиве из оригинала от 09.10.2014.
  62. ^ «Уязвимость Heartbleed Bug [9 апреля 2014 г.]». Comodo Group. В архиве из оригинала от 5 июля 2014 г.
  63. ^ Блейхенбахер, Даниэль (август 2006 г.). «Подделка подписи RSA Блейхенбахером на основе ошибки реализации». Архивировано из оригинал на 2014-12-16.
  64. ^ «БЕРСерк». Безопасность Intel: расширенное исследование угроз. Сентябрь 2014 г. В архиве из оригинала от 12.01.2015.
  65. ^ Гудин, Дэн (19 февраля 2015 г.). «ПК Lenovo поставляются с рекламным ПО, которое прерывает HTTPS-соединения». Ars Technica. В архиве из оригинала 12 сентября 2017 г.. Получено 10 декабря, 2017.
  66. ^ Валсорда, Филиппо (20 февраля 2015 г.). "Проверка SSL Komodia / Superfish нарушена". Filippo.io. В архиве из оригинала от 24.02.2015.
  67. ^ а б Гудин, Дэн. ""Запрещенная атака "делает десятки сайтов HTTPS Visa уязвимыми для взлома". Ars Technica. В архиве из оригинала 26 мая 2016 г.. Получено 26 мая 2016.
  68. ^ Кларк Эстес, Адам. «Все, что вам нужно знать о Cloudbleed, последней катастрофе в области безопасности Интернета». Gizmodo. В архиве из оригинала на 2017-02-25. Получено 2017-02-24.
  69. ^ а б По состоянию на 3 мая 2019 г. «SSL Pulse: обзор внедрения SSL на самых популярных веб-сайтах». Qualys. Получено 2019-05-09.
  70. ^ Диффи, Уитфилд; ван Оршот, Пол К.; Винер, Майкл Дж. (Июнь 1992 г.). «Аутентификация и аутентифицированный обмен ключами». Конструкции, коды и криптография. 2 (2): 107–125. CiteSeerX  10.1.1.59.6682. Дои:10.1007 / BF00124891. S2CID  7356608. В архиве из оригинала 13.03.2008. Получено 2008-02-11.
  71. ^ Обсуждение в списке рассылки TLS в октябре 2007 г. В архиве 2013-09-22 в Wayback Machine
  72. ^ «Долгосрочная защита данных с прямой секретностью». В архиве из оригинала от 06.05.2013. Получено 2012-11-05.
  73. ^ Бернат, Винсент. «SSL / TLS и совершенная пересылка секретов». В архиве из оригинала от 27.08.2012. Получено 2012-11-05.
  74. ^ "SSL Labs: развертывание прямой секретности". Qualys.com. 2013-06-25. В архиве из оригинала от 26.06.2013. Получено 2013-07-10.
  75. ^ Ристич, Иван (05.08.2013). "SSL Labs: развертывание прямой секретности". Qualsys. В архиве из оригинала от 20.09.2013. Получено 2013-08-31.
  76. ^ Лэнгли, Адам (27 июня 2013 г.). "Как нарушить секретность пересылки TLS". imperialviolet.org. В архиве из оригинала от 8 августа 2013 г.
  77. ^ Данььер, Флоран. «Секреты TLS»: технический документ, представляющий последствия для безопасности развертывания сессионных билетов (RFC 5077), реализованных в OpenSSL » (PDF). Матта Консалтинг Лимитед. В архиве (PDF) из оригинала от 6 августа 2013 г.. Получено 7 августа 2013.
  78. ^ Данььер, Флоран. «Секреты TLS»: То, что вам все забыли сказать ... » (PDF). Матта Консалтинг Лимитед. В архиве (PDF) из оригинала 5 августа 2013 г.. Получено 7 августа 2013.
  79. ^ Л.С. Хуанг; С. Адхикарла; Д. Бонех; К. Джексон (2014). «Экспериментальное исследование развертываний прямой секретности TLS». Интернет-вычисления IEEE. 18 (6): 43–51. CiteSeerX  10.1.1.663.4653. Дои:10.1109 / MIC.2014.86. S2CID  11264303. В архиве из оригинала 20 сентября 2015 г.. Получено 16 октября 2015.
  80. ^ «Долгосрочная защита данных с прямой секретностью». В архиве из оригинала от 12.02.2014. Получено 2014-03-07.
  81. ^ Хоффман-Эндрюс, Джейкоб. «Прямая секретность в Twitter». Twitter. В архиве из оригинала от 16.02.2014. Получено 2014-03-07.
  82. ^ а б c Дурумерик, Закир; Ма, Зейн; Спринголл, Дрю; Барнс, Ричард; Салливан, Ник; Бурштейн, Эли; Бейли, Майкл; Халдерман, Дж. Алекс; Паксон, Верн (5 сентября 2017 г.). «Влияние перехвата HTTPS на безопасность». Симпозиум NDSS. Дои:10.14722 / ndss.2017.23456. ISBN  978-1-891562-46-4.

Статья основана на материалах, взятых из Бесплатный онлайн-словарь по вычислительной технике до 1 ноября 2008 г. и зарегистрированы в соответствии с условиями «перелицензирования» GFDL, версия 1.3 или новее.