Протокол защищенных каналов SSL

    UNSUPPORTED-CERTIFICATE-TYPE-ERROR

    Этот  отклик присылается, когда клиент/сервер получает тип сертификата, который  он не поддерживает. Эта ошибка устранима (только для аутентификации клиента). 

              * Сообщения протокола  диалога SSL

    Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).

    После того как каждый из партеров определил  пару ключей сессии, тела сообщений  кодируются с помощью этих ключей. Для клиента это происходит, после  того как он верифицировал идентификатор  сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит, после того как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация:

    Char MSG-EXAMPLE

    char FIELD1

    char FIELD2

    char THING-MSB

    char THING-LSB

    char THING-DATA[(MSB<<8)|LSB];

    ...

    Эта нотация определяет данные в протокольном сообщении, включая код типа сообщения. Порядок передачи соответствует  порядку перечисления.

    Для записи "THING-DATA", значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.

    Длина кодов характеризуется целым  числом без знака, и когда MSB и LSB объединяются, результат также является целым  числом без знака. Если не указано  обратного, длины полей измеряются в байтах. 
 

              * Протокольные сообщения  клиента

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

    Различают следующие протокольные сообщения  клиента:

* CLIENT-HELLO (Фаза 1; посылается открыто)

* CLIENT-MASTER-KEY (Фаза 1; посылается открыто)

* CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)

* CLIENT-FINISHED (Фаза 2; посылается шифрованным) 

              * Протокольные сообщения сервера

    Существует  несколько сообщений, которые генерируются только серверами.

    Различают следующие протокольные сообщения  сервера:

* SERVER-HELLO (Фаза 1; посылается открыто) 

* SERVER-VERIFY (Фаза 1; посылается шифрованным)

* SERVER-FINISHED (Фаза 2; посылается шифрованным)

* REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным) 

              * Протокольные сообщения  клиент/сервер 

    Эти сообщения генерируются как клиентом, так и сервером.

    ERROR (посылается открыто  или зашифровано)

    char MSG-ERROR

    char ERROR-CODE-MSB

    char ERROR-CODE-LSB

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

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

    1.4. Атаки на протокол SSL 

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

    Атака №1. Раскрытие шифров

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

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

    Атака №2. Атака открытого  текста

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

    Из-за самой природы SSL атаки открытого  текста возможны. Например, наиболее часто  встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.

    Способ  блокирования атак открытого текста заключается в том, чтобы сделать  объем необходимого общедоступного оборудования неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно времяемкий процесс.

    Другой  способ, с помощью которого SSL может  противостоять данной атаке, заключается  в использовании максимально возможных длин ключей (например, в случае не экспортного варианта).

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

    Атака №3. Атака отклика

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

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

    Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать  “правильную” сессию, основываясь  на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 2⁶⁴ кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

    Атака №4. Человек посередине

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

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

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