SSL

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который подразумевает более безопасную связь. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко использовался для обмена мгновенными сообщениями и передачи голоса через IP (англ. Voice over IP — VoIP) в таких приложениях, как электронная почта, Интернет-факс и др. В 2014 году правительство США сообщило об уязвимости в текущей версии протокола[1]. SSL должен быть исключен из работы в пользу TLS (см. CVE-2014-3566).

SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Содержание

Описание[править | править вики-текст]

Протокол 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 расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети.

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 (draft)[править | править вики-текст]

С января 2016 года по настоящее время разрабатывается версия 1.3, сейчас доступны драфты — черновики.[источник не указан 92 дня]

Принцип работы[править | править вики-текст]

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

Многослойная среда[править | править вики-текст]

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

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

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

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

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

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

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

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

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

Цифровые сертификаты[править | править вики-текст]

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

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

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

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

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

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 (Standard 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 был использован в первую очередь с надёжными транспортными протоколами, такими как Transmission Control Protocol (TCP). Тем не менее, он также был реализован с датаграммными транспортными протоколами, такими как User Datagram Protocol (UDP) и Datagram Control Protocol (DCCP), использование которого было стандартизировано, что привело к появлению термина Datagram Transport Layer Security (DTLS).

Вебсайты[править | править вики-текст]

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

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

Браузеры[править | править вики-текст]

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

Браузеры, поддерживающие SSL/TLS
Браузер Платформы TLS 1.0 TLS 1.1 TLS 1.2
Chrome 0-21 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8)[a][b] Да Нет Нет
Chrome 29-текущая Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10)[a][b] Да[4] Да[4] Да[5]
Firefox 2 Linux, Mac OS X, Windows (XP, Vista, 7, 8)[c][b] Да[6] Нет[7] Нет[8]
IE 6 Windows (XP)[d] Да Нет Нет
IE 7-8 Windows (XP, Vista)[d] Да Нет Нет
IE 8-9 Windows 7[d] Да Да Да
IE 9 Windows Vista[d] Да Нет Нет
IE 10 Windows (7, 8)[d] Да Да Да
Opera 5-7 Linux, Mac OS X, Windows Да[9] Нет Нет
Opera 8-9 Linux, Mac OS X, Windows Да Да[10] Нет
Opera 10-текущая Linux, Mac OS X, Windows[e] Да Да Да
Safari 4 Mac OS X, Windows (XP, Vista, 7), iOS 4.0[f] Да Нет Нет
Safari 5 Mac OS X, Windows (XP, Vista, 7)[f] Да Нет Нет
Safari 5-текущая iOS 5.0-[g] Да Да Да

Уточнения:

  • В 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 по умолчанию отключены[11][12].
  • Opera 10 имеет поддержку TLS 1.2. Предыдущие версии поддерживали TLS 1.0 и 1.1[13]. TLS 1.1 и 1.2 по умолчанию отключены (за исключением версии 9[14]).
  • Safari использует реализацию операционной системы Mac OS X, Windows (XP, Vista, 7)[15][16]. Safari 5 является последней версией, доступной для Windows.
  • Mobile Safari и программное обеспечение сторонних производителей с использованием библиотечных систем UIWebView поддерживают TLS 1.2, как и iOS 5.0[17][18][19].

Использование и реализация[править | править вики-текст]

Изначально виртуальные частные сети (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 уязвима в некоторых ситуациях[20]:

  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[21], Mozilla Firefox 2[22], Opera 9.5[23] и 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, которая не является устойчивой к коллизиям и, следовательно, не считается безопасной[24].

Виды возможных атак[править | править вики-текст]

Атака по словарю[править | править вики-текст]

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

Вообще для 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, в ЦОД. Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом.

BEAST атака[править | править вики-текст]

23 сентября 2011 года тайские исследователи Дуонг и Джулиано Риццо, используя Java апплет, продемонстрировали «доказательство концепции» под названием Beast («Browser Exploit Against SSL/TLS»), указывающей уязвимость в TLS 1.0[25][26]. Ранее эту уязвимость, которая первоначально была обнаружена Phillip Rogaway[27] в 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[28], так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации[29].

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

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

Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран 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 обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения[31]. Протокол 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 (англ.) (October 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. 1 2 SSSL/TLS Overview (англ.) (6 August 2008). Проверено 9 мая 2013.
  5. Issue 90392: No TLS 1.2 (SHA-2) Support (англ.) (27 June 2013). Проверено 15 июля 2015.
  6. Security in Firefox 2 (англ.) (6 August 2008). Проверено 9 мая 2013.
  7. Bug 733647 - Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default (англ.) (6 March 2012). Проверено 9 мая 2013.
  8. Bug 480514 - Implement support for TLS 1.2 (RFC 5246) (англ.) (17 March 2010). Проверено 9 мая 2013.
  9. «Changelog for Opera 5.x for Windows» at Opera.com
  10. «Changelog for Opera [8] Beta 2 for Windows» at Opera.com
  11. Microsoft. Secure Channel (англ.) (5 September 2012). Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  12. Microsoft. MS-TLSP Appendix A (англ.) (27 February 2009). Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  13. Yngve Nysæter Pettersen. New in Opera Presto 2.2: TLS 1.2 Support (англ.) (25 February 2009). Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  14. «Changelog for Opera 9.0 for Windows» at Opera.com
  15. Adrian, Dimcev. Common browsers/libraries/servers and the associated cipher suites implemented (англ.). TLS Cipher Suites Project. Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  16. Apple. Features (англ.) (10 June 2009). Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  17. Apple. Technical Note TN2287 - iOS 5 and TLS 1.2 Interoperability Issues (англ.) (14 October 2011). Проверено 9 мая 2013.
  18. Liebowitz, Matt. Apple issues huge software security patches (англ.). NBCNews.com (13 October 2011). Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  19. MWR Info Security. Adventures with iOS UIWebviews (англ.) (16 April 2012). Проверено 9 мая 2013. Архивировано из первоисточника 17 апреля 2013., section «HTTPS (SSL/TLS)»
  20. 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.
  21. Lawrence Eric. IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2 (англ.). MSDN Blogs (25 November 2007). Проверено 11 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  22. Mozilla Corporation. Bugzilla@Mozilla — Bug 236933 - Disable SSL2 and other weak ciphers (англ.). Проверено 11 мая 2013.
  23. «Opera 9.5 for Windows Changelog» at Opera.com: «Disabled SSL v2 and weak ciphers.»
  24. National Institute of Standards and Technology. Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program (англ.) (December 2010). Проверено 11 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  25. Dan Goodin. Hackers break SSL encryption used by millions of sites (англ.) (19 September 2011). Проверено 11 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  26. Y Combinator comments on the issue (англ.) (20 September 2011). Проверено 11 мая 2013. Архивировано из первоисточника 17 апреля 2013.
  27. Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures (англ.) (20 May 2004). Проверено 11 мая 2013.
  28. Eric Rescorla. Understanding the TLS Renegotiation Attack (англ.). Educated Guesswork (5 November 2009). Проверено 11 мая 2013. Архивировано из первоисточника 28 апреля 2013.
  29. Simon Josefsson. GnuTLS 2.10.0 released (англ.). GnuTLS release notes (25 June 2010). Проверено 11 мая 2013. Архивировано из первоисточника 28 апреля 2013.
  30. Adrian Dimcev. SSL/TLS version rollbacks and browsers (англ.). Random SSL/TLS 101. Проверено 11 мая 2013. Архивировано из первоисточника 9 марта 2011.
  31. Kaspar Brand. Named-based SSL virtual hosts: how to tackle the problem (англ.) (18 April 2007). Проверено 20 мая 2013.
  32. Christopher Allen, Tim Dierks. Протокол SSL – Перевод – версия 1.0 (рус.). Certicom. Семенов Ю. А.. Проверено 20 мая 2013.
  33. David Wagner. Analysis of the SSL 3.0 Protocol (англ.). University of California. Проверено 24 мая 2013.

Литература[править | править вики-текст]

Книги
  • 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.

Ссылки[править | править вики-текст]

  • Mozilla.org — введение в SSL протокол