|
SSLSSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который подразумевает более безопасную связь между хостом и клиентом. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко использовался для обмена мгновенными сообщениями и передачи голоса через IP (англ. Voice over IP — VoIP) в таких приложениях, как электронная почта, интернет-факс и др. SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. В 2014 году правительство США сообщило об уязвимости в текущей версии протокола[1] и на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS. SSL должен быть исключён из работы в пользу TLS (см. CVE-2014-3566). ОписаниеПротокол SSL обеспечивает защищённый обмен данными за счёт двух следующих элементов:
SSL использует асимметричную криптографию для аутентификации ключей обмена, симметричный шифр для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол SSL предоставляет «безопасный канал», который имеет три основных свойства:
Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложений (HTTP, FTP, TELNET и т. д.) могут работать поверх протокола SSL совершенно прозрачно, то есть SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того, как приложение примет или передаст первый байт сообщения. История и развитиеSSL 1.0, 2.0 и 3.0Протокол SSL был изначально разработан компанией Netscape Communications. Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL версии 3.0[2]. SSL версии 3.0, выпущенный в 1996 году, послужил основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF), который впервые был определён в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети. С марта 2011 года, согласно RFC 6176, TLS-клиенты не должны использовать протокол SSL 2.0 при запросе подключения к серверу, и серверы должны отклонять такие запросы. TLS 1.0TLS 1.0 впервые был определён в RFC 2246 в январе 1999 года в качестве обновления версии SSL 3.0. Как указано в RFC, «различия между этим протоколом и SSL 3.0 не критичны, но они значительны для появления несовместимости при взаимодействии TLS 1.0 и SSL 3.0». TLS 1.0 действительно включает средства, с помощью которых реализация подключения TLS к SSL 3.0 ослабит безопасность. TLS 1.1TLS 1.1 презентовали в RFC 4346 в апреле 2006 года[3]. Это было обновление TLS версии 1.0. Значительные изменения в этой версии включают в себя:
TLS 1.2TLS 1.2 был анонсирован в RFC 5246 в августе 2008 года. Он основан на ранее предложенной версии TLS 1.1. TLS 1.3TLS 1.3 был признан стандартом в RFC 8446 в августе 2018 года. Принцип работы
SSL использует среду с несколькими слоями, что обеспечивает безопасность обмена информацией. Конфиденциальность общения присутствует за счет того, что безопасное соединение открыто только целевым пользователям. Многослойная средаПротокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т. д.) и транспортным протоколом TCP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передаёт их далее на транспортный уровень[4][5]. Работу протокола можно разделить на два уровня:
Первый слой, в свою очередь, состоит из трёх подпротоколов:
Протокол подтверждения подключения используется для согласования данных сессии между клиентом и сервером. К данным сессии относятся:
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хеширование и сжатие. Следующий этап — аутентификация участников, которая осуществляется также протоколом подтверждения подключения. Протокол изменения параметров шифра используется для изменения данных ключа (keyingmaterial) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей. Предупредительный протокол содержит сообщение, которое показывает сторонам изменение статуса или сообщает о возможной ошибке. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию. Цифровые сертификатыПротокол SSL использует сертификаты для проверки принадлежности открытого ключа его реальному владельцу. Способы получения SSL-сертификата:
Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде. Среди сертификатов SSL выделяют сертификаты, подтверждающие домен (англ. Domain-validated certificate) и расширенной проверки. Последний связывает доменное имя с реальным физическим или юридическим лицом. Типы SSL-сертификатовВсе сертификаты выпускаются в Центрах сертификации. Существует несколько разновидностей SSL-удостоверений. Обычно выделяют три типа — в соответствии с уровнем проверки, которая проводится перед выдачей:
Также есть различия в количестве доменов и поддоменов, к которым можно подключить один сертификат. WildCard-сертификат позволяет защитить одно основное имя и неограниченное число субдоменов, а мультидоменные сертификаты (MDC) распространяются сразу на несколько уникальных доменов (например, в разных зонах регистрации).[6] Механизмы образования ключа для текущей сессии в SSL/TLSСуществует 4 основных алгоритма для образования ключей: RSA, Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman RSAПри «утере» приватного ключа RSA криптоаналитик, получивший его, получает возможность расшифровать все записанные прошлые сообщения и будущие сообщения. Реализация обмена ключей в RSA является односторонней: вся необходимая информация для образования симметричного ключа, который создается на этапе рукопожатия, пересылается на сервер и шифруется публичным ключом сервера. Раскрытие приватного ключа даёт возможность узнать симметричный ключ данной сессии. Diffie-HellmanМеханизм Fixed Diffie-Hellman использует постоянный публичный ключ, который прописан в сертификате сервера. Это также означает, что при каждом новом соединении клиент предоставляет свою часть ключа. После обмена ключами образуется новый симметричный ключ для обмена информацией для текущей сессии. При раскрытии приватного ключа сервера криптоаналитик может расшифровать ранее записанные сообщения, а также все будущие сообщения. Это становится возможным из-за самого механизма. Так как криптоаналитик знает приватный ключ сервера, он сможет узнать симметричный ключ каждой сессии, и даже тот факт, что механизм образования ключа является двусторонним, не поможет. Особенности шифрованияСуществует два основных способа шифрования данных: симметричное шифрование (общий секретный ключ) и асимметричное шифрование (пара открытый/приватный ключ). SSL использует как асимметричную, так и симметричную криптографию. Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из ключей называется открытым (как правило, он публикуется в самом сертификате владельца), а второй ключ называется приватным — он держится в тайне. Оба ключа используются в паре: открытый ключ используется для того, чтобы зашифровать данные, а приватный — для того, чтобы расшифровать их. Такая взаимосвязь позволяет делать две важные вещи.
RSA — один из самых распространённых алгоритмов асимметричного шифрования. При использовании симметричного шифрования один и тот же ключ используется как для шифрования, так и для расшифровывания данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных (так как симметричное шифрование является более быстрым). Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES. Протокол SSL использует шифрование с открытым ключом для взаимной аутентификации клиента и сервера (с помощью технологии цифровых подписей), а также для выработки сессионного ключа, который, в свою очередь, используется более быстрыми алгоритмами симметричной криптографии для шифрования большого объёма данных. ХешированиеХеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создаёт 128-битное хеш-значение, SHA-1 (Secure Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных. Уровень записи
Протокол на уровне слоя записи получает зашифрованные данные от программы-клиента и передаёт их на транспортный слой. Протокол записи берёт данные, разбивает их на блоки и выполняет шифрование (расшифровывание) данных. При этом активно используется информация, которая была согласована во время подтверждения данных. Протокол SSL позволяет использовать шифрование симметричным ключом, используя либо блочные, либо потоковые шифры. Обычно на практике применяются блочные шифры. Принцип работы блочного шифра заключается в отображении блока открытого текста в такой же блок шифрованного текста. Этот шифр можно представить в виде таблицы, содержащей 2128 строк, каждая строка содержит блок открытого текста M и соответствующий ему блок шифрованного текста C. Подобная таблица существует для каждого ключа. Шифрование можно обозначить в виде функции C = E(Key, M), где M — исходные данные, Key — ключ шифрования, С — зашифрованные данные. Как правило, блоки имеют небольшой размер (обычно 16 байт), поэтому возникает вопрос: как зашифровать длинное сообщение?
ПрименениеПри проектировании приложений SSL реализуется «под» любым другим протоколом прикладного уровня, таким как HTTP, FTP, SMTP, NNTP и XMPP, таким образом обеспечивая «прозрачность» его использования. Исторически SSL был использован, в первую очередь, с надёжными транспортными протоколами, такими как TCP (Transmission Control Protocol). Тем не менее, он также был реализован с датаграммными транспортными протоколами, такими как UDP (User Datagram Protocol) и DCCP (Datagram Control Protocol), использование которого было стандартизировано, что привело к появлению термина Datagram Transport Layer Security (DTLS). Веб-сайтыЧастое использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL (или уже TLS), тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется во Всемирной паутине для приложений, в которых важна безопасность соединения, например в платёжных системах. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.
Браузеры
По состоянию на начало 2017 г. все основные веб-браузеры, поддерживающие SSL/TLS:
Уточнения:
Использование и реализацияИзначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна, сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте. Наиболее распространённая реализация SSL — криптографический пакет с открытым исходным кодом OpenSSL, основанный на SSLeay, написанной Эриком Янгом. Последняя версия OpenSSL поддерживает SSLv3. Пакет предназначен для создания и управления различного рода сертификатами. Также в его состав входит библиотека для поддержки SSL различными программами. Библиотека используется, например, модулем SSL в распространенном HTTP-сервере Apache. Спецификация протокола записей SSLФормат заголовка записей SSLВсе данные в SSL пересылаются в виде записей (рекордов) — объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит 2 или 3 байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель, и полная длина заголовка равна 3 байтам. В случае длинного (3 байта) заголовка второй по старшинству бит первого байта имеет специальное значение. Если он равен 0 — рекорд является информационным, если он равен 1 — рекорд является security escape. Код длины рекорда не включает в себя число байт заголовка. Для 2-байтового заголовка его длина вычисляется так: RECORD-LENGTH = ((byte[0] & 0x7F) << 8) | byte[1]; Здесь byte[0] — первый полученный байт, а byte[1] — второй полученный байт. RECORD-LENGTH = ((byte[0] & 0x3F) <<8) | byte[1]; Значение PADDING специфицирует число байтов, добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра. Отправитель добавляет PADDING после имеющихся данных, а затем шифрует всё это, так как длина этого массива кратна размеру блока используемого шифра. Поскольку известен объём передаваемых данных, заголовок сообщения может быть сформирован с учётом объёма PADDING. Получатель сообщения дешифрует всё поле данных и получает исходную информацию, затем вычисляет истинное значение RECORD-LENGTH, при этом PADDING из поля «данные» удаляется. Формат информационных записей SSLЧасть данных рекорда SSL состоит из 3 компонентов:
MAC-DATA — код аутентификации сообщения MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ] Здесь SECRET передается хеш-функции первым, затем следует ACTUAL-DATA и PADDING-DATA, за которыми передается SEQUENCE-NUMBER — порядковый номер. Для 2-байтового заголовка максимальная длина сообщения равно 32767 байтов, для 3-байтового 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL, а сообщения прикладного протокола могут занимать несколько рекордов SSL. Протокол диалога SSLПротокол диалога SSL содержит 2 основные фазы. Фаза 1Первая фаза используется для установления конфиденциального канала коммуникаций. Фаза 2Фаза 2 называется фазой аутентификации. Так как сервер уже аутентифицирован на первой фазе, то на второй фазе осуществляется аутентификация клиента. Сервер отправляет запрос клиенту, и если у клиента есть необходимая информация — он присылает позитивный отклик, если же нет — сообщение об ошибке. Когда один партнёр выполнил аутентификацию другого партнёра — он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация была неудачной, сервер посылает сообщение ERROR. Типовой протокол обмена сообщениямиНиже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. Клиент — C , сервер — S. «{smth}key» означает что «smth» зашифровано с помощью ключа. При отсутствии идентификатора сессии
Идентификатор сессии найден клиентом и сервером
Использован идентификатор сессии и аутентификация клиента
SSL поддерживает 3 типа аутентификации:
Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отозван. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима для такой атаки. Анонимный сервер не может аутентифицировать клиента. Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret). Анонимный обмен ключамиПолностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнаёт из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret). Аутентификация и обмен ключами при использовании RSAВ этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS (???). Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает приватный ключ, соответствующий сертификату сервера. Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывает значение, вычисленное из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия (???). Аутентификация и обмен ключами при использовании Diffie-HellmanВ этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу. Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами. Протокол записиПротокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента. Существует четыре протокола записи:
Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол, созданный для использования совместно с SSL, должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик. Протокол рукопожатияSSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения:
На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается. Протокол изменения параметров шифрованияПротокол изменения параметров шифрования существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1. struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
Сообщение изменения шифра посылается клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение «finished». Протокол тревогиОдин из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения. Протокол приложенияСообщение приложения данных работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи. БезопасностьSSL 2.0Существует ряд атак, которые могут быть предприняты против протокола SSL. Однако SSL устойчив к этим атакам при условии, что пользователь использует только доверенные сервера для обработки информации. SSL 2.0 уязвима в некоторых ситуациях[24]:
SSL 2.0 по умолчанию отключена в браузерах начиная с Internet Explorer 7[25], Mozilla Firefox 2[26], Opera 9.5[27] и Safari. SSL 3.014 октября 2014 года была выявлена уязвимость CVE-2014-3566, названная POODLE (Padding Oracle On Downgraded Legacy Encryption). Данная уязвимость позволяет злоумышленнику осуществить атаку Man-in-the-Middle на соединение, зашифрованное с помощью SSL 3.0. Уязвимость POODLE — это уязвимость протокола, а не какой-либо его реализации, соответственно, ей подвержены все соединения зашифрованные SSL v3. В SSL 3.0 есть и иные слабые моменты. К примеру, половина мастер-ключа (master key), которая устанавливается, полностью зависит от хеш-функции MD5, которая не является устойчивой к коллизиям и, следовательно, не считается безопасной[28]. Виды возможных атакАтака по словарюТакой тип атак производится, когда атакующий имеет представление о том, какого типа сообщения посылаются. Вообще для SSL такие атаки возможны. Но SSL пытается противостоять этим атакам, используя большие ключи сессии — клиент генерирует ключ, который длиннее, чем допускается экспортными ограничениями, часть которого посылается серверу открытым текстом, а остальная часть объединяется с секретной частью, чтобы получить достаточно длинный ключ (например, 128 бит, как этого требует RC4). Способ блокирования атак открытого текста заключается в том, чтобы сделать объём необходимого текста неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в 2 раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (в случае не экспортного варианта). Следствием этого является то, что самым простым и дешёвым способом атаки становится лобовая атака ключа, но для 128-битного ключа стоимость его раскрытия можно считать бесконечной. Атака отражениемЗлоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 264 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 264 достаточно большое число, что делает эти атаки бессмысленными. Атака протокола рукопожатияЗлоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес. Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения «finished». Без знания секрета злоумышленник не сможет исправить сообщение «finished», поэтому атака может быть обнаружена. Взлом SSL-соединений внутри ЦОДНаиболее известный инцидент по массовому взлому информации, защищенной протоколами SSL, был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T, который установил данные комплексы для взлома криптографически защищенной информации. Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей, технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установлены в самом ЦОД, где находились серверы, ведущие SSL-соединения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путём прослушивания не SSL-соединения, а внутреннего трафика между серверами приложений внутри самого ЦОД, уже после того как данные, поступившие по SSL, были расшифрованы самим сервером, принявшим их от внешних пользователей. Тем не менее, указанный инцидент показал, что SSL не может являться надёжным средством криптозащиты данных серверов в Интернете, так как спецслужбы могут установить системы прослушивания, такие как NarusInsight или СОРМ-2[29], в ЦОД. Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учётом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом. BEAST атака23 сентября 2011 года Зыонг Нгок Тхай (вьет. Dương Ngọc Thái)[30] и Джулиано Риццо, используя Java апплет, продемонстрировали «доказательство концепции» под названием Beast («Browser Exploit Against SSL/TLS»), указывающей уязвимость в TLS 1.0[31][32]. Ранее эту уязвимость, которая первоначально была обнаружена Phillip Rogaway[33] в 2002 году, практически никто не мог продемонстрировать. Уязвимость TLS 1.1 была зафиксирована в 2006 году. Ci = E(Key, Mi xor Ci-1), где Ci -зашифрованный блок, Mi — секретный текст Предположим что пароль А — P. Мы можем проверить правильность нашего предположения: Итак, мы смогли перехватить вектор инициализации, который используется для шифрования первого блока следующего сообщения, но это же есть последний блок предыдущего сообщения(в зашифрованном виде) — IV. Также мы перехватили Ci-1.При помощи этих данных мы формируем сообщение так, чтобы первый блок стал равен следующему: M1 = Ci-1 xor IV xor P Если криптоаналитик сможет передать сообщение по тому же защищенному каналу, то первый блок нового сообщения примет вид: C1 = E(Key, M1 xor IV) = E(Key, (Ci-1 xor IV xor P) xor P) xor IV) = E(Key, (Ci-1 xor P)) = Ci Получается, если P = M, то первый зашифрованный блок нового сообщения С1 будет равен ранее перехваченному Сi. На практике возникает проблема: блок М — 16 байтов в длину, даже если мы знаем все байты кроме двух нам потребуется 215 попыток чтобы угадать оставшееся. А если мы не знаем ничего? Об уязвимости знали гораздо раньше, но разработчики утилиты — первые, кому удалось реализовать все условия для данной атаки. А именно:
Вот список различных технологий и браузерных плагинов, которые могут выполнить внедрение агента в браузер жертвы: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API, и Silverlight WebClient API. RC4 атакаВ 2013 году в Сингапуре прошла конференция, на которой профессор Дэн Бернстейн представил новую технику для взлома протоколов SSL/TLS, если в таковых используется шифр RC4, который в 2011 году был предложен как средство защиты от BEAST. Уязвимость обнаруженная в RC4 связана с недостаточной случайностью потока битов, которым скремблируется сообщение. Прогнав через него одно и то же сообщение много раз было выявлено достаточное количество повторяющихся паттернов для восстановления исходного текста. Для атаки придется прогнать через шифр гигантский объём данных. В представленной реализации взлом занимал до 32 часов, однако не исключалась возможность оптимизации процесса. Но данная атака трудно реализуема на практике. Создатели утверждают, что для восстановления 80 байт из 256 необходимо 256 шифротекстов. Раскрытие шифровКак известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определённые коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. Атака «злоумышленник посередине»Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и её источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL[34], так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации[35]. Атака будет успешной, если:
Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft или прокси-сервер Blue Coat Proxy SG. В данном случае «злоумышленник» находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного центра сертификации сам прокси-сервер (либо как корневого, либо как дочернего по отношению к корпоративному корневому). Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS. Наиболее спорным становится вопрос информированности пользователя о возможности перехвата данных, так как в случае подмены корневого сертификата никаких сообщений безопасности выводиться не будет и пользователь будет ожидать конфиденциальности передаваемых данных. Кроме того, при использовании Forefront TMG в качестве SSL-прокси возникает возможность проведения второй MitM-атаки на стороне интернета, так как оригинальный сертификат не будет передан пользователю, а Forefront TMG может быть настроен на приём и последующую подмену самоподписанных или отозванных сертификатов. Для защиты от подобной атаки необходимо полностью запретить работу с веб-серверами, чьи сертификаты содержат какие-либо ошибки, что безусловно приведет к невозможности работы по протоколу HTTPS со множеством сайтов. Blue Coat Proxy SG от второй MitM-атаки защищен: система позволяет настроить политику таким образом, что в случае недоверенного сертификата веб-сервера система также выпускает сертификат, подписанный не доверенной цепочкой, а временной самоподписанной. THC-SSL-DOS24 октября 2011 года организация The Hacker’s Choice (THC) выпустила утилиту THC-SSL-DOS, которую можно использовать для проведения DoS-атак на SSL серверы. Данная утилита использует уязвимость в функции повторного подтверждения SSL — SSL Renegotiation, которая изначально была предназначена для обеспечения большей безопасности SSL. Повторное подтверждение позволяет серверу создавать новый секретный ключ поверх уже имеющегося SSL-соединения. Эта функция по умолчанию включена в большинство серверов. Установка безопасного соединения, а также выполнение повторного подтверждения SSL, требуют в несколько раз больше ресурсов на стороне сервера, чем на стороне клиента, то есть если клиент отправляет множество запросов на повторное подтверждение SSL, это истощает системные ресурсы сервера. Согласно одному из участников THC, для успешного проведения атаки нужен ноутбук с установленной утилитой и доступ в интернет. Программа была опубликована в свободном доступе, потому что её аналог появился в сети уже несколько месяцев тому назад. Также, по утверждениям разработчиков, атака может быть произведена даже в том случае, если сервер не поддерживает функцию повторного подтверждения, хотя для этого придется модифицировать метод атаки. В этом случае устанавливается множество TCP-соединений для нового рукопожатия SSL, но для эффективной атаки необходимо больше ботов. SSLstripВ 2009 году на конференции Black Hat в Вашингтоне Мокси Марлинспайк — независимый хакер — продемонстрировал новую утилиту SSLstrip, при помощи которой можно достать важную информацию, заставив пользователей поверить, что они находятся на защищенной странице, хотя на самом деле это не так. Этого можно достичь конвертируя страницы, обычно защищенные протоколом SSL в их незащищенные аналоги, причем обманывается как сервер, так и клиент. Утилита работает потому, что многие сайты использующие защиту SSL имеют незащищенную главную страницу. Они шифруют только те разделы, где передается важная информация. И когда пользователь кликает по странице авторизации утилита подменяет ответ сайта меняя https на http. В SSLstrip используются следующие приёмы: во-первых, в локальной сети разворачивается прокси-сервер, имеющий действительный сертификат — отсюда в адресной строке пользователь продолжает видеть https, во вторых используется техника для создания длинных URL содержащих в адресной строке фальшивые ‘/‘ — это нужно, чтобы избежать преобразования символов браузерами. Для доказательства работы системы Мокси запустил SSLstrip на сервере, обслуживающем сеть Tor и за 24 часа выловил 254 пароля пользователей Yahoo, Gmail, Ticketmaster, PayPal и Linkedln. Обработка ошибок в протоколе SSLВ протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения[37]. Протокол SSL определяет следующие ошибки:
Алгоритмы, использующиеся в SSL
См. такжеПримечания
Литература
Ссылки
|
Portal di Ensiklopedia Dunia
