SSL

From CryptoWiki
Jump to: navigation, search

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает безопасность связи. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко используется для обмена мгновенными сообщениями и передачи голоса через IP, в таких приложениях, как электронная почта, Интернет-факс и др.

Contents

Описание

Протокол SSL позволяет общаться клиенту с сервером в сети, предотвращая перехват или фальсификацию. Так как протоколы могут работать либо без SSL либо поверх SSL, то для клиента необходимо указать серверу, хочет ли он установить соединение SSL или нет. Есть две возможности сделать это. Одним из вариантов является использование различных номеров портов для соединения SSL (например, порт 443 для HTTPS). Другой заключается в использовании регулярного номера порта, сервер установит соединение с клиентом, используя протокол конкретного механизма (например, STARTTLS для почты и новостных протоколов). После того как клиент и сервер решили использовать SSL, они ведут переговоры, отслеживая состояние соединения с помощью процедуры рукопожатия. Во время этого рукопожатия клиент и сервер соглашаются на различные параметры, используемые для установки безопасного соединения. После завершения процедуры рукопожатия начинается защищенное соединение. Клиент и сервер используют сеансовые ключи для шифрования и расшифрования данных, которые они посылают друг другу. Это нормальный алгоритм работы по защищенному каналу. В любое время, в связи с внутренним или внешним раздражителем (автоматическое вмешательство или вмешательство пользователя), любая из сторон может пересмотреть сеанс связи. В этом случае, весь процесс повторяется. SSL работает модульным способом.

Применение

При проектировании приложений SSL обычно реализуется поверх любого другого протокола транспортного уровня, инкапсулируя в себе протоколы уровня приложений, такие как HTTP, FTP, SMTP, NNTP и XMPP. Исторически SSL был использован в первую очередь с надежными транспортными протоколами, такими как Transmission Control Protocol (TCP). Тем не менее, он также был реализован с датаграммным транспортным протоколом, таким как User Datagram Protocol (UDP) и Datagram Control Protocol (DCCP), использование которого было стандартизировано, что привело к использованию термина Datagram Transport Layer Security (DTLS).

Вебсайты

Частое использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

Сайт поддержки протокола
Версия протокола Безопасность Поддержка сайтами
SSL 2.0 Нет 28.4%
SSL 3.0 Может быть 99.8%
TLS 1.0 Может быть 99.4%
TLS 1.1 Да 10.4%
TLS 1.2 Да 12.7%

Использование и реализация

Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте. Наиболее распространенная реализация SSL — криптографический пакет с открытым исходным кодом OpenSSL, основанный на SSLeay, написанной Эриком Янгом. Последняя версия OpenSSL поддерживает SSLv3. Пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Библиотека используется, например, модулем SSL в распространенном HTTP-сервере Apache.

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

Существует ряд атак, которые могут быть предприняты против протокола SSL. Однако SSL устойчив к этим атакам, при условии, что пользователь использует только доверенные сервера для обработки информации. SSL 2.0 уязвима в некоторых ситуациях.

  1. Идентичные криптографические ключи используются для аутентификации и шифрования сообщений,
  2. SSL 2.0 имеет слабую MAC конструкцию, которая использует MD5 хэш-функцию с секретом префикса, что делает его уязвимым для атак,
  3. SSL 2.0 не имеет никакой защиты для протокола рукопожатия, то есть атака типа злоумышленник посередине (man-in-the-middle) могут остаться незамеченными,
  4. SSL 2.0 использует закрытие TCP соединения, чтобы указать конец данных. Это означает что возможна следующая атака: злоумышленник просто подделывает TCP FIN, оставив получателя без сообщения о конце передачи данных (в SSL 3.0 эту ошибку исправили)
  5. SSL 2.0 предполагает наличие единой службы поддержки и фиксированного домена, что идет вразрез со стандартной функцией виртуального хостинга на веб-серверах.

SSL 2.0 по умолчанию отключена в браузерах, начиная с Internet Explorer 7, Mozilla Firefox 2, Opera 9.5, и Safari. TLS имеет целый ряд мер безопасности. С точки зрения безопасности, SSL 3.0 следует считать менее надежным, чем TLS 1.0. В SSL 3.0 есть слабые моменты. К примеру, половина мастер-ключа (master key), которая устанавливается, полностью зависит от хэш-функции MD5, которая не является устойчивой к коллизиям и, следовательно, не считается безопасной.

Атака отклика

Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 2^64 кодов nonce, чтобы получить вероятность угадывания 50%. Но 2^64 достаточно большое число, что делает эти атаки бессмысленными.

Атака протокола рукопожатия

Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес.

Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения "finished". Без знания секрета злоумышленник не сможет исправить сообщение "finished", поэтому атака может быть обнаружена.

Взлом SSL-соединений агентами ФБР с помощью систем Carnivore и NarusInsight

Наиболее известный инцидент по массовому взлому информации, защищенной протоколами SSL, был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T, который установил данные комплексы для взлома криптографически защищенной информации.

Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей, технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установлены в самом ЦОД, где находились сервера, ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные, поступившие по SSL, были расшифрованы самим сервером, их принявшим от внешних пользователей.

Тем не менее, указанный инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернете, так как спецслужбы могут установить системы прослушивания, такие как NarusInsight или СОРМ-2, в ЦОД. Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом.

BEAST атака

23 сентября 2011 года тайские исследователи Дуонг и Джулиано Риццо продемонстрировали "доказательство концепции" под названием Beast, ("Browser Exploit Against SSL/TLS") используя Java апплет, продемонстрировали уязвимость в TLS 1.0. Практически, ранее эту уязвимость, которая первоначально была обнаружена Phillip Rogaway в 2002 году, никто не мог продемонстрировать. Уязвимость TLS 1.1 была зафиксирована в 2006 году.

RC4 атака

Несмотря на существующие атаки на RC4, шифр на основе RC4 в SSL и TLS считали безопасным. В 2011 RC4 был рекомендован как средство защиты от Beast атаки. Однако в 2013 году было совершено нападение по сценарию, предложенному Алфардом, Бернштейном, Патерсоном, Поттерингом и Шхултдом, которые использовали новые статистические погрешности в RC4 ключе.

Раскрытие шифров

Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA.

Из-за того, что большинство SSL-сайтов не используют алгоритмы со свойством perfect forward secrecy (PFS), злоумышленник записавший зашифрованные сессии, сможет их прочитать после того как получит приватный ключ RSA.

Злоумышленник посередине

Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака практически невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации.

Атака будет успешной, если:

  • Сервер не имеет подписанного сертификата.
  • Клиент не проверяет сертификат сервера.
  • Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или сообщение о несовпадении сертификата с кэшированным

Данный вид атаки можно встретить в крупных организациях, использующих межсетевые экраны с возможностью работы в режиме SSL Interception proxy, например Forefront TMG компании Microsoft. В данном случае "злоумышленник" находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря добавлению на клиентские компьютеры в список доверенных корневых центров сертификата, используемого в данном экране. Подобная процедура добавления может производиться прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.

Наиболее спорным становится вопрос информированности пользователя о возможности перехвата данных, т.к. в случае подмены корневого сертификата никаких сообщений безопасности выводиться не будет и пользователь будет ожидать конфиденциальности передаваемых данных. Кроме того, при использовании Forefront TMG в качестве SSL-прокси возникает возможность проведения второй MitM-атаки на стороне интернета, т.к. оригинальный сертификат не будет передан пользователю, а Forefront TMG может быть настроен на прием и последующую подмену самоподписанных или отозванных сертификатов. Для защиты от подобной атаки необходимо полностью запретить работу с веб-серверами, чьи сертификаты содержат какие-либо ошибки, что безусловно приведет к невозможности работы по протоколу HTTPS со множеством сайтов.

См. также

Вернуться к оглавлению

Исполнитель: Нестеренко Д.Г. Б9-03