SSL

Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 13 декабря 2019 года; проверки требуют 56 правок.
Перейти к навигации Перейти к поиску
У этого термина существуют и другие значения, см. SSL (значения).

SSL (англ. 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 предоставляет «безопасный канал», который имеет три основных свойства:

  1. Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
  2. Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, а клиентская делает это опционально.
  3. Канал надёжен. Транспортировка сообщений включает в себя проверку целостности.

Преимуществом 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.0

[править | править код]

TLS 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.1

[править | править код]

TLS 1.1 презентовали в RFC 4346 в апреле 2006 года[3]. Это было обновление TLS версии 1.0. Значительные изменения в этой версии включают в себя:

  • добавлена защита от атак, использующих режим сцепления блоков шифротекста (Cipher Block Chaining);
    • неявный Вектор инициализации (IV) был заменен на явный IV;
    • было проведено изменение в обработке ошибок;
  • введена поддержка IANA регистрации параметров.

TLS 1.2

[править | править код]

TLS 1.2 был анонсирован в RFC 5246 в августе 2008 года. Он основан на ранее предложенной версии TLS 1.1.

TLS 1.3

[править | править код]

TLS 1.3 был признан стандартом в RFC 8446 в августе 2018 года.

Принцип работы

[править | править код]

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

Многослойная среда

[править | править код]

Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т. д.) и транспортным протоколом TCP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передаёт их далее на транспортный уровень[4][5].

Работу протокола можно разделить на два уровня:

  1. Слой протокола подтверждения подключения (Handshake Protocol Layer)
  2. Слой протокола записи

Первый слой, в свою очередь, состоит из трёх подпротоколов:

  1. Протокол подтверждения подключения (Handshake Protocol)
  2. Протокол изменения параметров шифра (Cipher Spec Protocol)
  3. Предупредительный протокол (Alert Protocol)

Протокол подтверждения подключения используется для согласования данных сессии между клиентом и сервером. К данным сессии относятся:

  • Идентификационный номер сессии
  • Сертификаты обеих сторон
  • Параметры алгоритма шифрования
  • Алгоритм сжатия информации
  • «Общий секрет» применён для создания ключей; открытый ключ

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

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

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

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

[править | править код]
Основная статья: Сертификат открытого ключа

Протокол SSL использует сертификаты для проверки принадлежности открытого ключа его реальному владельцу. Способы получения SSL-сертификата:

  1. Использовать сертификат, выданный CA
  2. Использовать самоподписанный сертификат
  3. Использовать «пустой» сертификат

Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.

Среди сертификатов SSL выделяют сертификаты, подтверждающие домен (англ. Domain-validated certificate) и расширенной проверки. Последний связывает доменное имя с реальным физическим или юридическим лицом.

Типы SSL-сертификатов

[править | править код]

Все сертификаты выпускаются в Центрах сертификации. Существует несколько разновидностей SSL-удостоверений. Обычно выделяют три типа — в соответствии с уровнем проверки, которая проводится перед выдачей:

  1. Domain Validation (DV) или проверка на уровне домена требует только подтверждения права владения адресом, для которого нужен сертификат. В данном случае центр удостоверяет связь доменного имени с сервером и сайтом. Это гарантирует пользователю, что он попал именно на тот домен, на который заходил. Информация кодируется, но сведения о владельце сертификата не указаны.
  2. Organization Validation (OV) или проверка на уровне организации подразумевает, что помимо доменного имени удостоверяется и юридическое лицо, которое им владеет. Физическим лицам сертификаты такого уровня не выдаются. Они необходимы для проектов, которые проводят, например, банковские транзакции (интернет-магазины, в том числе).
  3. Extended Validation (EV) или сертификат расширенной проверки является самым серьёзным и дорогим. Здесь данные о домене и юрлице проверяются не единожды перед выдачей, а каждый год. Кроме того, центр не просто подтверждает существование организации, а изучает её правовую деятельность. На сайтах с таким сертификатом в адресной строке также указывается название компании-владельца и страна.

Также есть различия в количестве доменов и поддоменов, к которым можно подключить один сертификат. WildCard-сертификат позволяет защитить одно основное имя и неограниченное число субдоменов, а мультидоменные сертификаты (MDC) распространяются сразу на несколько уникальных доменов (например, в разных зонах регистрации).[6]

Механизмы образования ключа для текущей сессии в SSL/TLS

[править | править код]

Существует 4 основных алгоритма для образования ключей: RSA, Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman

RSA

[править | править код]
Основная статья: RSA

При «утере» приватного ключа RSA криптоаналитик, получивший его, получает возможность расшифровать все записанные прошлые сообщения и будущие сообщения. Реализация обмена ключей в RSA является односторонней: вся необходимая информация для образования симметричного ключа, который создается на этапе рукопожатия, пересылается на сервер и шифруется публичным ключом сервера. Раскрытие приватного ключа даёт возможность узнать симметричный ключ данной сессии.

Diffie-Hellman

[править | править код]
Основная статья: Протокол Диффи — Хеллмана

Механизм Fixed Diffie-Hellman использует постоянный публичный ключ, который прописан в сертификате сервера. Это также означает, что при каждом новом соединении клиент предоставляет свою часть ключа. После обмена ключами образуется новый симметричный ключ для обмена информацией для текущей сессии. При раскрытии приватного ключа сервера криптоаналитик может расшифровать ранее записанные сообщения, а также все будущие сообщения. Это становится возможным из-за самого механизма. Так как криптоаналитик знает приватный ключ сервера, он сможет узнать симметричный ключ каждой сессии, и даже тот факт, что механизм образования ключа является двусторонним, не поможет.
Механизм Anonymous Diffie-Hellman не предоставляет гарантий секретности, ибо данные передаются незашифрованными.
Единственный вариант, при котором гарантируется безопасность прошлых и будущих сообщений — Ephemeral Diffie-Hellman. Разница по сравнению с ранее рассмотренными методами заключается в том, что при каждом новом соединении сервером и клиентом создается одноразовый ключ. Таким образом, даже если криптоаналитику достанется текущий приватный ключ, он сможет расшифровать только текущую сессию, но не предыдущие или будущие сессии.

Особенности шифрования

[править | править код]

Существует два основных способа шифрования данных: симметричное шифрование (общий секретный ключ) и асимметричное шифрование (пара открытый/приватный ключ).

SSL использует как асимметричную, так и симметричную криптографию.

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

  1. Любой пользователь может получить открытый ключ и использовать его для шифрования данных, расшифровать которые сможет только пользователь, владеющий приватным ключом.
  2. Если владелец ключевой пары «зашифрует» (подпишет) данные своим приватным ключом, то каждый сможет убедиться в том, что данные были отправлены именно владельцем приватного ключа и не были изменены третьей стороной. Именно это является основой цифровых подписей.

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 байт), поэтому возникает вопрос: как зашифровать длинное сообщение?
Первый режим для подобного шифрования называется ECB (Electronic Codebook) или режим простой замены. Его суть состоит в том, что мы разбиваем исходное сообщение на блоки (по те же 16 байт) и шифруем каждый блок отдельно. Однако данный режим применяет редко из-за проблемы сохранения статистических особенностей исходного текста: 2 одинаковых блока открытого текста после шифрования превратятся в два одинаковых блока зашифрованного текста.
Для решения этой проблемы был разработан второй режим — CBC (Cipher-block chaining). В этом случае каждый новый блок шифротекста XOR’ится с предыдущим результатом шифрования. Первый блок XOR’ится c некоторым вектором инициализации (Initialization Vector, IV). Однако вся вышеизложенная теория разработана для одного большого объекта, в то время как SSL, являясь криптографическим протоколом, должен шифровать серию пакетов. В такой ситуации существует два способа применения CBC:

  1. Обрабатывать каждое сообщение как отдельный объект, генерируя для него каждый раз новый вектор инициализации
  2. Обрабатывать все сообщения как один большой объект, сохраняя режим CBC между ними. В таком случае в качестве вектора инициализации для сообщения n будет использоваться последний блок шифрования предыдущего сообщения (n-1)

Применение

[править | править код]

При проектировании приложений 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.

Поддержка веб-сайтами протокола[7]
Версия протокола Безопасность Поддержка сайтами
SSL 2.0 Нет 4.9 %
SSL 3.0 Нет 16.6 %
TLS 1.0 Может быть 94.7 %
TLS 1.1 Да 82.6 %
TLS 1.2 85.5 %

Браузеры

[править | править код]

По состоянию на начало 2017 г. все основные веб-браузеры, поддерживающие SSL/TLS:

Браузеры, поддерживающие SSL/TLS
Браузер Платформы TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Chrome 1-21 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да Нет Нет Нет
Chrome 29-53 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) Да[8] Да[8] Да[9] Нет
Chrome 58+ Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) Да Да Да Да
Firefox 1-27 Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да[10] Нет[11] Нет[12] Нет
Firefox 27-53 Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да Да Да Нет
Firefox 54+ Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да Да Да Да
IE 6 Windows (XP) Да Нет Нет Нет
IE 7-8 Windows (XP, Vista) Да Нет Нет Нет
IE 8-9 Windows 7 Да Да Да Нет
IE 9 Windows Vista Да Нет Нет Нет
IE 10+ Windows (7, 8) Да Да Да Нет
Edge 12-15 Windows 10 Да Да Да Нет
Opera 5-7 Linux, Mac OS X, Windows Да[13] Нет Нет Нет
Opera 8-9 Linux, Mac OS X, Windows Да Да[14] Нет Нет
Opera 10+ Linux, Mac OS X, Windows Да Да Да Нет
Opera 44+ Linux, Mac OS X, Windows Да Да Да Да
Safari 4 Mac OS X, Windows (XP, Vista, 7), iOS 4.0 Да Нет Нет Нет
Safari 5 Mac OS X, Windows (XP, Vista, 7) Да Нет Нет Нет
Safari 7-10 iOS 5.0- Да Да Да Нет

Уточнения:

  • В OS X используется TLS, предоставляемый Network Security Services (NSS). По состоянию на март 2013 года NSS 3.14.3 поддерживает TLS 1.0 и 1.1, но не версию 1.2.
  • Firefox 31.2 поддерживает TLS 1.0, 1.1 и 1.2, поддержка SSL 3.0 по умолчанию отключена.
  • IE использует реализацию TLS от операционной системы Microsoft Windows, предоставляемый SChannel. TLS 1.1 и 1.2 по умолчанию отключены[15][16].
  • Opera 10 имеет поддержку TLS 1.2. Предыдущие версии поддерживали TLS 1.0 и 1.1[17]. TLS 1.1 и 1.2 по умолчанию отключены (за исключением версии 9[18]).
  • Safari использует реализацию операционной системы Mac OS X, Windows (XP, Vista, 7)[19][20]. Safari 5 является последней версией, доступной для Windows.
  • Mobile Safari и программное обеспечение сторонних производителей с использованием библиотечных систем UIWebView поддерживают TLS 1.2, как и iOS 5.0[21][22][23].

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

[править | править код]

Изначально виртуальные частные сети (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] — второй полученный байт.
Для 3-байтового заголовка длина рекорда вычисляется следующим образом:

RECORD-LENGTH = ((byte[0] & 0x3F) <<8) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) !=0;
PADDING = byte[2];

Значение PADDING специфицирует число байтов, добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра. Отправитель добавляет PADDING после имеющихся данных, а затем шифрует всё это, так как длина этого массива кратна размеру блока используемого шифра. Поскольку известен объём передаваемых данных, заголовок сообщения может быть сформирован с учётом объёма PADDING. Получатель сообщения дешифрует всё поле данных и получает исходную информацию, затем вычисляет истинное значение RECORD-LENGTH, при этом PADDING из поля «данные» удаляется.

Формат информационных записей SSL

[править | править код]

Часть данных рекорда SSL состоит из 3 компонентов:

  1. MAC-DATA[MAC-SIZE]
  2. ACTUAL-DATA[N]
  3. PADDING-DATA[PADDING]

MAC-DATA — код аутентификации сообщения
MAC-SIZE — функция используемого алгоритма вычисления хеш-суммы
ACTUAL-DATA — реально переданные данные или поле данных сообщения
PADDING-DATA — данные PADDING (при блочном шифровании)

MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]

Здесь SECRET передается хеш-функции первым, затем следует ACTUAL-DATA и PADDING-DATA, за которыми передается SEQUENCE-NUMBER — порядковый номер.
Значение SECRET зависит от того, кто именно посылает сообщение. Если это делает клиент, то SECRET равен CLIENT-WRITE-KEY. Если же клиент получает сообщение, SECRET равен CLIENT-READ-KEY.
Порядковый номер представляет собой 32-битовый код, который передается хеш-функции в виде 4 байт, используя сетевой порядок передачи «от старшего к младшему». Порядковый номер — счетчик для сервера или клиента. Для каждого направления передачи используется пара счетчиков — для отправителя и для получателя; каждый раз, когда отправляется сообщение, счетчик увеличивает своё значение на 1.
Получатель сообщения использует ожидаемое значение порядкового номера для передачи MAC (тип хеш-функции определяется параметром CIPHER-CHOICE). Вычисленное значение MAC-DATA должно совпадать с переданным значением. Если сравнение не прошло, сообщение считается поврежденным, что приводит к возникновению ошибки, которая вызывает закрытие соединения.
Окончательная проверка соответствия выполняется, когда используется блочный шифр. Объём данных в сообщении (RECORD-LENGTH) должен быть кратен размеру блока шифра. Если данное условие не выполнено, сообщение считается поврежденным, что приводит к разрыву соединения.

Для 2-байтового заголовка максимальная длина сообщения равно 32767 байтов, для 3-байтового 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL, а сообщения прикладного протокола могут занимать несколько рекордов SSL.

Протокол диалога SSL

[править | править код]

Протокол диалога SSL содержит 2 основные фазы.

Фаза 1

[править | править код]

Первая фаза используется для установления конфиденциального канала коммуникаций.
Эта фаза инициализирует соединение, когда оба партнёра обмениваются сообщениями «hello». Клиент посылает сообщение CLIENT-HELLO. Сервер получает это сообщение, обрабатывает его и посылает в ответ сообщение SERVER-HELLO.
В этот момент и сервер и клиент имеют достаточно информации, чтобы знать, нужен ли новый master key. Если ключ не нужен, сервер и клиент переходят в фазу 2.
Когда возникает необходимость создания нового master key, сообщение сервера SERVER-HELLO уже содержит достаточно данных для того, чтобы клиент мог сгенерировать master key. В эти данные входят подписанный сертификат сервера, список базовых шифров и идентификатор соединения (случайное число, сгенерированное сервером, которое используется на протяжении всей сессии). После генерации клиентом master key он посылает серверу сообщение CLIENT-MASTER-KEY или же сообщение об ошибке, когда клиент и сервер не могут согласовать базовый шифр.
После определения master key сервер посылает клиенту сообщение SERVER-VERIFY, которое аутентифицирует сервер.

Фаза 2

[править | править код]

Фаза 2 называется фазой аутентификации. Так как сервер уже аутентифицирован на первой фазе, то на второй фазе осуществляется аутентификация клиента. Сервер отправляет запрос клиенту, и если у клиента есть необходимая информация — он присылает позитивный отклик, если же нет — сообщение об ошибке. Когда один партнёр выполнил аутентификацию другого партнёра — он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация была неудачной, сервер посылает сообщение ERROR.
Когда один из партнёров послал сообщение finished — он должен принимать сообщения до тех пор, пока не получит сообщение finished от другого партнёра, и только когда оба партнёра послали и получили сообщения finished, протокол диалога SSL закончит свою работу. С этого момента начинает работу прикладной протокол.

Типовой протокол обмена сообщениями

[править | править код]

Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. Клиент — C , сервер — S. «{smth}key» означает что «smth» зашифровано с помощью ключа.

При отсутствии идентификатора сессии

[править | править код]
Client-hello C ® S: challenge, cipher_specs
Server-hello S ® C: connection-id,server_certificate,cipher_specs
Client-master-key C ® S: {master_key}server_public_key
Client-finish C ® S: {connection-id}client_write_key
Server-verify S ® C: {challenge}server_write_key
Server-finish S ® C: {new_session_id}server_write_key

Идентификатор сессии найден клиентом и сервером

[править | править код]
Client-hello C ® S: challenge, session_id, cipher_specs
Server-hello S ® C: connection-id, session_id_hit
Client-finish C ® S: {connection-id}client_write_key
Server-verify S ® C: {challenge}server_write_key
Server-finish S ® C: {session_id}server_write_key

Использован идентификатор сессии и аутентификация клиента

[править | править код]
Client-hello C ® S: challenge, session_id, cipher_specs
Server-hello S ® C: connection-id, session_id_hit
Client-finish C ® S: {connection-id}client_write_key
Server-verify S ® C: {challenge}server_write_key
Request-certificate S ® C: {auth_type ,challenge'}server_write_key
Client-certificate C ® S: {cert_type,client_cert, response_data}client_write_key
Server-finish S ® C: {new_session_id}server_write_key

Аутентификация и обмен ключами

[править | править код]

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), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

  1. Протокол рукопожатия (handshake protocol);
  2. Протокол тревоги (alert protocol);
  3. Протокол изменения шифра (the change cipher spec protocol);
  4. Протокол приложения (application data protocol);

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

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

[править | править код]

SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения:

  1. Клиент посылает серверу номер версии SSL клиента, поддерживаемые алгоритмы шифрования и сжатия, специфичные данные для сеанса и другую информацию, которая нужна серверу, чтобы общаться с клиентом, используя SSL.
  2. Сервер посылает клиенту номер версии SSL сервера, алгоритм сжатия и шифрования (выбранные из посланных ранее клиентом), специфичные данные для сеанса и другую информацию, которая нужна клиенту, чтобы общаться с сервером по протоколу SSL. Сервер также посылает свой сертификат, который требует проверки подлинности клиента. После идентификации сервер запрашивает сертификат клиента.
  3. Клиент использует информацию, переданную сервером для проверки подлинности. Если сервер не может быть проверен, пользователь получает предупреждение о проблеме и о том, что шифрование и аутентификация соединения не может быть установлена. Если сервер успешно прошел проверку, то клиент переходит к следующему шагу.
  4. Используя все данные, полученные до сих пор от процедуры рукопожатие, клиент (в сотрудничестве с сервером) создаёт предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера, отправленного на 2-м шаге), а затем отправляет его на сервер.
  5. Если сервер запросил аутентификацию клиента (необязательный шаг рукопожатия), клиент также подписывает ещё один кусок данных, который является уникальным для этого рукопожатия и известным как для клиента, так и сервера. В этом случае, клиент отправляет все подписанные данные и собственный сертификат клиента на сервер вместе с предварительно зашифрованным секретом.
  6. Сервер пытается аутентифицировать клиента. Если клиент не может пройти проверку подлинности, сеанс заканчивается. Если клиент может быть успешно аутентифицирован, сервер использует свой закрытый ключ для расшифровки предварительного секрета, а затем выполняет ряд шагов (которые клиент также выполняет), чтобы создать главный секрет.
  7. И клиент, и сервер используют секрет для генерации ключей сеансов, которые являются симметричными ключами, использующиеся для шифрования и расшифрования информации, которой обмениваются во время SSL сессии. Происходит проверка целостности (то есть, для обнаружения любых изменений в данных между временем когда он был послан, и временем его получения на SSL-соединении).
  8. Клиент посылает сообщение серверу, информируя его, что будущие сообщения от клиента будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.
  9. И в заключение, сервер посылает сообщение клиенту, информируя его, что будущие сообщения от сервера будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.

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

Протокол изменения параметров шифрования

[править | править код]

Протокол изменения параметров шифрования существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1. 

struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

Сообщение изменения шифра посылается клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение «finished».

Протокол тревоги

[править | править код]

Один из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения.

Протокол приложения

[править | править код]

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

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

[править | править код]

SSL 2.0

[править | править код]

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

  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[25], Mozilla Firefox 2[26], Opera 9.5[27] и Safari.

SSL 3.0

[править | править код]

14 октября 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 году.
Атака строится на нескольких допущениях, но, как оказалось, их вполне реально реализовать. Во-первых, криптоаналитик должен иметь возможность перехватывать трафик, передаваемый браузером. Во-вторых, необходимо как-то заставить пользователя передавать данные по тому же самому безопасному каналу связи. Пусть между компьютерами Боба (B) и Алисы (А) установлено безопасное соединение. Предположим, что i-ый блок попавшего к нам сообщения содержит секретную информацию (например, пароль).

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 попыток чтобы угадать оставшееся. А если мы не знаем ничего?
Отсюда вывод что данная практика может сработать в том случае, если криптоаналитик имеет ограниченное количество предположений относительно значения М, а точнее большую часть содержимого данного блока. Следующее допущение: криптоаналитик может контролировать расположение данных в блоке, например знать что пароль — n символов в длину. Зная это, криптоаналитик располагает пароль таким образом чтобы в первый блок попал только 1 символ, а оставшиеся (n-1) в следующий — то есть в первых 15 байтах лежат заведомо известные данные. А для угадывания 1 символа злоумышленнику потребуется в худшем 256 попыток.

Об уязвимости знали гораздо раньше, но разработчики утилиты — первые, кому удалось реализовать все условия для данной атаки. А именно:

  1. Криптоаналитик имеет возможность прослушивать сетевые соединения, инициированные браузером атакуемого компьютера
  2. У криптоаналитика есть возможность внедрить агент в браузер жертвы
  3. Агент имеет возможность отправлять произвольные HTTPS-запросы

Вот список различных технологий и браузерных плагинов, которые могут выполнить внедрение агента в браузер жертвы: 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].

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

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

Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft или прокси-сервер Blue Coat Proxy SG. В данном случае «злоумышленник» находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного центра сертификации сам прокси-сервер (либо как корневого, либо как дочернего по отношению к корпоративному корневому). Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.

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

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

Blue Coat Proxy SG от второй MitM-атаки защищен: система позволяет настроить политику таким образом, что в случае недоверенного сертификата веб-сервера система также выпускает сертификат, подписанный не доверенной цепочкой, а временной самоподписанной.

THC-SSL-DOS

[править | править код]

24 октября 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 определяет следующие ошибки:

  1. Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента).
  2. No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.
  3. Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).
  4. No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима.

Алгоритмы, использующиеся в SSL

[править | править код]

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ US-CERT. TA14-290A: SSL 3.0 Protocol Vulnerability and POODLE Attack (англ.) (октябрь 2015). Архивировано 6 ноября 2014 года.
  2. ↑ THE SSL PROTOCOL (англ.). Netscape Corporation. Дата обращения: 20 мая 2013. Архивировано 14 июня 1997 года.
  3. ↑ Dierks, T. and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346 (англ.). Дата обращения: 9 мая 2013. Архивировано 9 февраля 2012 года.
  4. ↑ Overview of SSL/TLS Encryption Microsoft TechNet. Updated July 31, 2003.
  5. ↑ SSL/TLS in Detail Microsoft TechNet. Updated July 31, 2003.
  6. ↑ Что такое SSL-сертификат Архивная копия от 7 января 2023 на Wayback Machine. Updated November 21, 2022.
  7. ↑ SSL Pulse. Дата обращения: 27 апреля 2017. Архивировано из оригинала 15 мая 2017 года.
  8. ↑ 1 2 SSL/TLS Overview (англ.) (6 августа 2008). Дата обращения: 9 мая 2013. Архивировано из оригинала 3 июля 2013 года.
  9. ↑ Issue 90392: No TLS 1.2 (SHA-2) Support (англ.) (27 июня 2013). Дата обращения: 15 июля 2015. Архивировано 3 августа 2013 года.
  10. ↑ Security in Firefox 2 (англ.) (6 августа 2008). Дата обращения: 9 мая 2013. Архивировано из оригинала 23 июля 2012 года.
  11. ↑ Bug 733647 - Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default (англ.) (6 марта 2012). Дата обращения: 9 мая 2013. Архивировано 30 мая 2013 года.
  12. ↑ Bug 480514 - Implement support for TLS 1.2 (RFC 5246) (англ.) (17 марта 2010). Дата обращения: 9 мая 2013. Архивировано 31 мая 2013 года.
  13. ↑ «Changelog for Opera 5.x for Windows» Архивная копия от 19 октября 2014 на Wayback Machine at Opera.com
  14. ↑ «Changelog for Opera [8] Beta 2 for Windows» Архивная копия от 23 ноября 2005 на Wayback Machine at Opera.com
  15. ↑ Microsoft. Secure Channel (англ.) (5 сентября 2012). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  16. ↑ Microsoft. MS-TLSP Appendix A (англ.) (27 февраля 2009). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  17. ↑ Yngve Nysæter Pettersen. New in Opera Presto 2.2: TLS 1.2 Support (англ.) (25 февраля 2009). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  18. ↑ «Changelog for Opera 9.0 for Windows» Архивная копия от 31 августа 2006 на Wayback Machine at Opera.com
  19. ↑ Adrian, Dimcev. Common browsers/libraries/servers and the associated cipher suites implemented (англ.). TLS Cipher Suites Project. Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  20. ↑ Apple. Features (англ.) (10 июня 2009). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  21. ↑ Apple. Technical Note TN2287 - iOS 5 and TLS 1.2 Interoperability Issues (англ.) (14 октября 2011). Дата обращения: 9 мая 2013. Архивировано 8 сентября 2010 года.
  22. ↑ Liebowitz, Matt. Apple issues huge software security patches (англ.). NBCNews.com (13 октября 2011). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  23. ↑ MWR Info Security. Adventures with iOS UIWebviews (англ.) (16 апреля 2012). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года., section «HTTPS (SSL/TLS)»
  24. ↑ Joris Claessens, Valentin Dem, Danny De Cock, Bart Preneel, Joos Vandewalle. On the Security of Today's Online Electronic Banking Systems (англ.) 253–265 (2002). Дата обращения: 11 мая 2013. Архивировано 17 октября 2015 года.
  25. ↑ Lawrence Eric. IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2 (англ.). MSDN Blogs (25 ноября 2007). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  26. ↑ Mozilla Corporation. Bugzilla@Mozilla — Bug 236933 - Disable SSL2 and other weak ciphers (англ.). Дата обращения: 11 мая 2013. Архивировано 14 февраля 2017 года.
  27. ↑ «Opera 9.5 for Windows Changelog» Архивная копия от 26 июня 2009 на Wayback Machine at Opera.com: «Disabled SSL v2 and weak ciphers.»
  28. ↑ National Institute of Standards and Technology. Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program (англ.) (декабрь 2010). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  29. ↑ Игорь Савчук. Это СОРМ, детка. Часть 1. Возможности современных средств шифрования // «БИТ. Бизнес&Информационные технологии» : Журнал. — М.: ООО «Издателький дом «Положевец и партнеры», 2014. — Вып. 1, № 34. — ISSN 2313-8718. Архивировано 28 октября 2020 года.
  30. ↑ Tấn công BEAST lên bộ giao thức SSL/TLS. Дата обращения: 30 сентября 2023. Архивировано 9 мая 2020 года.
  31. ↑ Dan Goodin. Hackers break SSL encryption used by millions of sites (англ.) (19 сентября 2011). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  32. ↑ Y Combinator comments on the issue (англ.) (20 сентября 2011). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  33. ↑ Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures (англ.) (20 мая 2004). Дата обращения: 11 мая 2013. Архивировано 30 июня 2012 года.
  34. ↑ Eric Rescorla. Understanding the TLS Renegotiation Attack (англ.). Educated Guesswork (5 ноября 2009). Дата обращения: 11 мая 2013. Архивировано 28 апреля 2013 года.
  35. ↑ Simon Josefsson. GnuTLS 2.10.0 released (англ.). GnuTLS release notes (25 июня 2010). Дата обращения: 11 мая 2013. Архивировано 28 апреля 2013 года.
  36. ↑ Adrian Dimcev. Random SSL/TLS 101 - SSL/TLS version rollbacks and browsers (англ.). Random SSL/TLS 101. Дата обращения: 11 мая 2013. Архивировано 28 апреля 2013 года.
  37. ↑ Kaspar Brand. Named-based SSL virtual hosts: how to tackle the problem (англ.) (18 апреля 2007). Дата обращения: 20 мая 2013. Архивировано 3 августа 2012 года.
  38. ↑ Christopher Allen, Tim Dierks. Протокол SSL – Перевод – версия 1.0. Certicom. Семенов Ю. А.. Дата обращения: 20 мая 2013. Архивировано 11 июля 2012 года.
  39. ↑ David Wagner. Analysis of the SSL 3.0 Protocol (англ.). University of California. Дата обращения: 24 мая 2013. Архивировано 31 октября 2014 года.

Литература

[править | править код]
Книги
  • Pouyan Sepehrdad. Discovery and Exploitation of New Biases in RC4. — 1-st. — Springer Berlin Heidelberg, 2011. — Т. 1. — С. 24. — 91 с. — ISBN 978-3-642-19573-0.
  • Joris Claessens. COmputer Security and Industrial Cryptography. — 3-t. — Leuven—Heverlee, Belgium, 2002. — Т. 1. — С. 253–265. — 287 с. — ISBN 0167-4048.
  • John Viega. Network Security with OpenSSL. — 1-st. — O'Reilly Media, USA, June 15, 2002. — Т. 1. — 386 pages с. — ISBN 978-0596002701.
  • Eric Rescorla. SSL and TLS: Designing and Building Secure Systems. — 1-st. — Addison-Wesley Professional, October 27, 2000. — Т. 1. — 528 pages с. — ISBN 978-0201615982.
  • Stephen Thomas. SSL & TLS Essentials: Securing the Web. — 1-st. — Wiley, February 11, 2000. — Т. 1. — 224 pages с. — ISBN 978-0471383543.
Статьи
  • Описание протоколов SSL/TLS // 3. — ООО "КРИПТО-ПРО"., 2002. — P. 49.
  • Семенов Ю.А. Протокол SSL. Безопасный уровень соединителей. — 2000. — № 1.
  • E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2 // 1-st. — RTFM, Inc., August 2008. — № 1. — P. 101.
  • P. Karlton. The Secure Sockets Layer (SSL) Protocol Version 3.0 // 1-st. — RTFM, Inc., August 2011. — № 1. — P. 67.
  • T. Dierks. The Secure Sockets Layer (SSL) // 1-st. — RTFM, Inc., August 2008. — № 1. — P. 207.

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=SSL&oldid=138605863