Ssl и Integrated Solutions Console
Приложение ISC - это единая среда Web-консолей администрирования для развертывания и интеграции консольных модулей, позволяющая заказчикам управлять решениями, а не конкретными продуктами IBM. Эта среда включает в себя контейнер портлетов, Java-компоненты (JMX) для управления приложениями и модули справки Eclipse.
Для реализации конфиденциальности и шифрования можно использовать протокол SSL. С помощью SSL можно защитить взаимодействие между Web-браузером пользователя и сервером ISC. Шифрование важно потому, что в ISC используется аутентификация, основанная на формах; при этом идентификатор и пароль пользователя для входа в систему не шифруются при пересылке по сети. Если консольному модулю требуется доступ к внутренним ресурсам через безопасное соединение, его портлеты могут использовать SSL.
Какие преимущества дает использование ssl?
Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам - это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей. В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе - крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.
В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.
Третий
Любому пользователю Интернета хорошо известна аббревиатура HTTP. Чаще всего она попадается нам на глаза, в каталогах со ссылками или в адресной строке наших браузеров. Данная аббревиатура обозначает один из основных, используемых в Интернете, протоколов обмена информацией, а именно Hypertext Transfer Protocol, или протокол передачи гипертекста, того самого текста, с помощью которого построена вся информационная инфраструктура Интернета. Благодаря такой популярности и распространенности, аббревиатура HTTP, попадается и узнается сплошь и рядом, но вот весьма похожая на нее, и по виду, и по сути, аббревиатура HTTPS, почему-то гораздо менее известна и узнаваема. Основной причиной к тому, наверно является, уж слишком большая похожесть - разница составляет всего одну латинскую букву. Но, первое впечатление, как всегда, довольно обманчиво. Именно эта латинская буква "s" превращает обычный, не защищенный канал передачи данных в Интернете, в засекреченный или защищенный; и при более пристальном разглядывании URL-ов, посещаемых нами ресурсов, встречается не так уж и редко.
Использование SSL
Чаще всего, этот протокол используется в составе любого Интернет-ресурса, осуществляющего манипуляции с личными или финансовыми данными посещающих его пользователей Интернета. Чаще всего, это банки, Интернет-магазины или любые другие виртуальные места, в которых приходящие по своим делам пользователи, вынуждены передавать свои личные, и зачастую секретные, данные. Этого может потребовать и простая регистрация, и процедура оплаты какого-либо товара, или любая другая процедура, при которой пользователи вынуждены честно выдавать свои паспортные данные, PIN-ы и пароли. Если бы все жители земного шара являлись бы порядочными и честными людьми, необходимость бы в использовании SSL, отпала бы сама собой, за не надобностью, ведь защищать информацию было бы просто не от кого. Но, поскольку в реалии мы имеем несколько другое положение вещей, то приходится думать о том, как защитить передаваемую пользователем информацию от посягательств со стороны третьих лиц. Используя обычный HTTP протокол, мы передаем и получаем информацию в чистом, не зашифрованном виде. Таким образом, передаваемая нами информация, может быть легко перехвачена, и использована совершенно посторонним человеком. Помимо этого, существует и другая, на первый взгляд просто смешная угроза. Представьте, ваш банк расположен по адресу http://MyHomeBank.com. Теперь представьте, что некий злоумышленник, регистрирует другой адрес, скажем http://MyH0meBank.com, и создает на нем сайт, внешне похожий на сайт вашего банка. Эти адреса так похожи, что рано или поздно, вы наверняка ошибетесь, и случайно попадете не в банк, а на сайт злоумышленника. Ну а далее, схема примерно ясна - ваша персональная информация становится известна третьему лицу. Таким образом, появляются два довольно веских довода, первый, передаваемую информацию надо шифровать, и второй, мы должны быть уверены, что передаем информацию именно туда, куда нужно. Именно для решения этих двух вопросов и используется SSL. Теперь, рассмотрим принцип действия этого протокола не много подробнее.
HTTP и HTTPS
Попытки разработать универсальный сетевой протокол, способный обеспечить надлежащий уровень безопасности при работе в Интернет, предпринимались достаточно давно, и достаточно большим количеством различных фирм и организаций. HTTP протокол предлагал достаточно простой, парольный способ идентификации того или иного пользователя. В момент соединения с сервером, пользователь вводил пароль, пароль передавался серверу в открытом, не зашифрованном виде, и далее, проверив соответствие пароля и имени пользователя, сервер открывал или не открывал затребованное соединение. Далее, по мере развития Интернета, было создано несколько различных безопасных протоколов. Официальный протокол, разработку которого спонсировала IETF, назывался Secure HTTP (SHTTP), (http://www.faqs.org/rfcs/rfc2660.html). Помимо него, разрабатывались, и были созданы, еще несколько не официальных проектов, один из которых, под названием SSL (Secure Sockets Layer), созданный Netscape, получил большую популярность и широкое распространение. Правда, не смотря на свою популярность, SSL не является официальным Интернет стандартом, а потому, подробную информацию о нем, можно найти на сайте разработчиков Netscape (http://home.netscape.com/eng/ssl3/draft302.txt).
SSL в действии
Главным назначением SSL-протокола, является обеспечение приватного и надежного способа обмена информацией между двумя удаленно взаимодействующими приложениями. Протокол реализуется в виде двухслойной (многослойной) среды, специально предназначенной для безопасного переноса секретной информации, через не засекреченные каналы связи. В качестве первого слоя, в такой среде используется некоторый надежный транспортный протокол; TCP к примеру. По слову "транспортный", не трудно догадаться, что TCP берет на себя функции "несущей", и в дальнейшем, становится извозчиком, для всех лежащих выше слоев (протоколов). Вторым по счету слоем, накладываемым на TCP, является SSL Record Protocol. Вместе, эти два слоя, TCP и SSL Record Protocol, формируют своеобразное ядро SSL. В дальнейшем, это ядро становится первичной герметизирующей оболочкой, для всех последующих более сложных протокольных инфраструктур. В качестве одной из таких структур, используется SSL Handshake Protocol - позволяющий серверу и клиенту идентифицировать друг друга и согласовывать криптографические алгоритмы и ключи, перед тем как приложения, работающие на серверной и клиентской стороне, смогут начать передачу или прием информационных байтов в защищенном режиме.
Одним из не мало важных преимуществ SSL, является его полная программно-платформенная независимость. Протокол разработан на принципах переносимости, и идеология его построения, не зависит, от тех приложений, в составе которых он используется. Помимо этого, важно и то, что поверх протокола SSL, могут прозрачно накладываться и другие протоколы; либо для еще большего увеличения степени защиты целевых информационных потоков, либо, для адаптации криптографических способностей SSL под какую-нибудь другую, вполне определенную задачу.
Вы
начинаете использовать SSL в тот момент,
когда вводите в адресной строке своего
браузера URL начинающийся с аббревиатуры
HTTPS, рис. 1. В результате, вы подключаетесь
к порту за номером 443, который для SSL
обычно используется по умолчанию; для
стандартного HTTP соединения, чаще всего
используется порт 80. В процессе
подключения, браузер пользователя (в
дальнейшем клиент), посылает серверу
приветственное сообщение (hello message). В
свою очередь сервер, также должен
посылать клиенту свое приветственное
сообщение. Приветственные сообщения,
являются первичными, инициализирующими
сообщениями и содержат информацию,
используемую при дальнейшей настройке
открываемого секретного канала. В общем
случае, приветственное сообщение
устанавливает четыре основных параметра:
версия протокола, идентификатор сессии,
способ шифрования, метод компрессии, а
также, два специально сгенерированных
случайных числа; и сервер, и клиент,
генерируют такие числа независимо друг
от друга, а затем, просто обмениваются
ими друг с другом. 
После получения приветственного сообщения от клиента, сервер отсылает свой сертификат, если таковой у него имеется. Также, при необходимости, сервер может послать и некое ключевое сообщение, например в случае отсутствии сертификата. Если сервер авторизирован (т.е. имеет соответствующий сертификат), он может потребовать и клиентский сертификат, если того потребует выбранный способ шифрования данных. После этого, производится еще ряд промежуточных обменных операций, в процессе которых, производится окончательное уточнение выбранного алгоритма шифрования, ключей и секретов, и далее, сервер посылает клиенту некое финальное сообщение, после чего обе стороны приступают к обмену зашифрованной информации.
На практике, процесс обмена ключами и сертификатами, иногда может занимать относительно много времени. С этой целью, часто предусматривается возможность повторного использования одних и тех же идентификационных данных. Бывают ситуации, когда после установления соединения с SSL-сервером, у пользователя появляется желание открыть еще одно окно браузера, и через него, осуществить еще одно подключение к тому же SSL-серверу. В этом случае, чтобы не повторять весь цикл предварительных обменных операций, браузер может отправить серверу идентификатор сессии предыдущего соединения, и если сервер примет этот идентификатор, весь набор шифровочных и компрессионных параметров, будет взят от предыдущего соединения. Браузеры от Netscape, также могут осуществлять и так называемый "keep alive" запрос. При этом по завершению передачи шифрованных данных, установленное SSL-соединение закрывается не сразу, а лишь по истечении некоторого времени.
Ложка дегтя
SSL как таковой, теоретически, может обеспечить практически полную защиту любого Интернет соединения. Но, любая вещь в этом мире не существует в пустоте. Это означает, что для успешного функционирования SSL, кроме него самого, необходимы также и чисто программные средства, претворяющие технологию SSL в жизнь. Программы, так или иначе использующие SSL протокол, как ни странно, является порой самым уязвимым местом этой технологии. Именно из-за ошибок в этих программах, возможна почти полная потеря, всех, достигнутых после использования SSL щитов и заслонов. К таким программным инструментам, прежде всего, относятся активно используемые нами Интернет-браузеры.
Одним из самых показательных критериев уровня защиты, является размер используемых ключей или, говоря иначе, стойкость используемого шифра. Чем больше этот размер, тем соответственно надежнее защита. Браузеры в основном используют три размера: 40, 56 и 128 бит, соответственно. Причем, 40-а битный вариант ключа достаточно не надежен; его вполне можно раскрыть меньше чем за сутки. Таким образом, предпочтительнее использовать именно 128-ми битные ключи. Применительно к Internet Explorer-у от Microsoft, это означает загрузку дополнительного пакета (security pack). Так как интернациональные версии этого браузера, всегда снабжаются исключительно 40-а или 56-и битной защитой, а 128-ми битная защита, ставится только на североамериканские версии этого браузера (США, Канада). Для того чтобы установить, какой именно размер ключа используется в вашем браузере, в Netscape Navigator вам достаточно открыть подменю "Options/Security Preferences", а в Internet Explorer, подменю "Help/About".
Но размер ключа, не будет играть решающий роли, если в защите браузера имеется внутренняя брешь. Сообщения об открытии таких брешей, в тех или иных браузерах, появляются с регулярными интервалами. Такая брешь напоминает открытую форточку в протапливаемой комнате - все тепло мгновенно выветривается. По этому поводу, уместно вспомнить случай произошедший с Netscape Navigator, в мае 2000 года. Тогда, один корейский студент обнаружил такую, довольно не приятную особенность, этого браузера. При попытке соединения с сервером, обладающим не годным сертификатом, с дальнейшим отказом от продолжения такого соединения, происходило следующее. Netscape, по ошибке, помещал этот сертификат в список годных, и соответственно, при последующем подключение уже не выдавал пользователю ни каких предупреждающих сообщений, спокойно подключаясь к этому, не вполне надежному, серверу (http://www.cert.org/advisories/CA-2000-05.html).
Но все эти и им подобные прорехи, не идут ни в какое сравнение с той угрозой, которую могут представлять для пользователя вовремя не отозванные сертификаты. Дело в том, что браузеры обычно поставляются с неким, вполне определенным набором действительных сертификатов, но автоматического механизма проверки этой годности по прошествию некоторого времени - не существует. Таким образом, возможно, что действие, того или иного, используемого вашим браузером сертификата, уже, давно кончилось; мог истечь срок годности, мог быть потерян контроль над личным ключом соответствующим этому сертификату и.т.д. В любом из этих случаев, сертификат автоматически отзывается, и помещается в специальный, так называемый revocation list, или список не годных сертификатов, создаваемый и обновляемый тем или иным сертификационным сообществом (CA). Теперь, если не удалить такой сертификат из вашего браузера, он по прежнему будет числиться как годный, со всеми вытекающими отсюда последствиями.
Здесь, пожалуй стоит остановиться, и подвести некую финальную черту, под всем вышесказанным. Идея, заложенная в протоколе SSL безусловно, хороша. Хотя у нее есть и свои плюсы, и свои минусы, но в целом, этот протокол можно назвать одним из наиболее удачных решений проблемы защиты пользовательских данных при их распространении "открытым" каналом. Этот протокол вполне бы мог стать некой сетевой панацеей. Но, к сожалению, практика, показывает что идея это еще не решение. Без соответствующей практической составляющей, идей так и остается идеей, а потому, пользователи безусловно, должны помнить, что символ замка, появляющийся в строке состояния их Интернет-браузеров, еще не гарантия того, что все ваши секреты и тайны находятся под действительно надежной защитой
Четвертый
Алгоритм SSL
Алгоритм работы SSL построен на принципе публичных ключей. Этот принцип построен на использовании пары асимметричных ключей (публичном и приватном) для кодирования/декодирования информации. Публичный ключ раздается всем желающим. И с его помощью шифруются необходимые данные, которые можно дешифровать только с помощью приватного ключа. Отходя от темы, можно сказать, что так оно выглядит в теории. На практике все несколько менее строго. Из-за юридических ограничений на длину ключей, они поддаются взлому, хотя для этого и необходимы достаточно большие вычислительные мощности.
Теперь рассмотрим, каким образом все-таки работает SSL. Представьте себе, что есть два человека, которые общаются посредством Интернета и соответственно не видят друг друга. И лишены возможности, узнать, о том кто же его абонент. Их имена - Алиса и Боб. Допустим Алисе надо, узнать действительно она разговаривает с Бобом или нет. В этом случае диалог может выглядеть следующим образом: Алиса отправляет Бобу случайное сообщение. Боб шифрует его с помощью своего приватного ключа и отправляет его Алисе. Алиса дешифрует это сообщение (с помощью публичного ключа Боба). И сравнив это сообщение с посланным, может убедиться в том, что его действительно послал Боб. Но на самом деле со стороны Боба не очень удачная идея шифровать сообщение от Алисы с помощью своего приватного ключа. И возвращать его. Это аналогично подписи документа, о которой Боб мало что знает. С такой позиции Боб должен сам придумать сообщение. И послать его Алисе в двух экземплярах. В первом сообщение передается открытым текстом, а второе сообщение зашифровано с помощью приватного ключа Боба. Такое сообщение называется message digest. А способ шифрования сообщения с помощью своего приватного ключа - цифровой подписью (digital signature).
Теперь закономерно встает вопрос о том, каким образом распространять свои публичные ключи. Для этого (и не только) была придумана специальная форма - сертификат (certificate). Сертификат состоит из следующих частей: Имя человека/организации выпускающего сертификат. Для кого был выпущен данный сертификат (субъект сертификата). Публичный ключ субъекта. Некоторые временные параметры (срок действия сертификата и т.п.). Сертификат подписывается приватным ключом человека (или огрганизации), который выпускает сертификаты. Организации, которые производят подобные операции называются Certificate authority (CA). Если в стандартном Web-клиенте (web-browser), который поддерживает SSL, зайти в раздел security, то там можно увидеть список известных организаций, которые подписывают сертификаты. С технической стороны, создать свою собственную CA достаточно просто. Но против этого могут действовать скорее юридические препятсвия.
Теперь рассмотрим, каким образом происходит обмен данными в Интернете. Воспользуемся все теми же действующими лицами.
Алиса: привет. Боб: привет, я Боб (выдает свой сертификат). Алиса: а ты точно Боб? Боб: Алиса я Боб. (Сообщение передается два раза, один раз в открытую, второй раз, зашифрованный с помощью приватного ключа Боба). Алиса: все нормально, ты действительно Боб. (И присылает Бобу секретное сообщение, зашифрованное с помощью публичного ключа Боба). Боб: А вот и мое сообщение (посылает сообщение, которое было зашифровано с помощью секретного ключа, например того же шифрованного сообщения Алисы).
Поскольку Боб знает сообщение Алисы, потому что он владеет приватным ключом и Алиса знает, что было в том сообщении. Теперь они могут использовать симметричный шифровальный алгоритм (где в качестве секретного ключа выступает сообщение Алисы) и безбоязненно обмениваться шифрованными сообщениями. А для контроля над пересылкой сообщений (от случайного/преднамеренного изменения) используется специальный алгоритм - Message Authentication Code (MAC). Довольно распространенным является алгоритм MD5. Обычно, и сам MAC-code так же шифруется. В связи с этим достоверность сообщений повышается в несколько раз. И внести изменения в процесс обмена практически невозможно.
пятый
SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS. Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причём для шифрования используется асимметричный алгоритм с открытым ключом. При шифровании с открытым ключом используется два ключа, причем любой из них может использоваться для шифрования сообщения. Тем самым, если используется один ключ для шифрования, то соответственно для расшифровки нужно использовать другой ключ. В такой ситуации можно получать защищённые сообщения, публикуя открытый ключ, и храня в тайне секретный ключ.
Протокол SSL состоит из двух подпротоколов: протокол SSL записи и рукопожатия. Протокол SSL записи определяет формат, используемый для передачи данных. Протокол SSL включает рукопожатие с использованием протокола SSL записи для обмена сериями сообщений между сервером и клиентом, во время установления первого соединения. Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат. SSL предоставляет канал, имеющий 3 основных свойства: Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма. Надёжность. Обмен сообщениями включает в себя проверку целостности. Частность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений. В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2х байтового заголовка: RecLength=(byte[0] & 0x7F<<8) | byte[1]; Здесь byte[0] и byte[1] первый и второй полученные байты. Длина записи 3х байтового заголовка: RecLength = (byte[0] & 0x3F<<8)|byte[1]; Escape = (byte[0] & 0x40)!=0; Padding = byte[2]; Здесь Padding определяет число байтов добавленных отправителем к исходному тексту, для того чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра. Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных, и шифрует всё это. Причем содержимое заполнителя никакой роли не играет. Из-за того, что известен объём передаваемых данных, то заголовок может быть сформирован с учетом Padding. В свою очередь получатель записи дешифрует всё поле данных и получает полную исходную информацию. Затем производится вычисление значение RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3х компонент: MAC_Data[Mac_Size] — (Message Authentication Code) — код аутентификации сообщения Padding_Data[Padding] — данные заполнителя Actual_Data[N] — реальные данные Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования, Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data: MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number); Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счетчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32х битовый код, передаваемый хэш-функции в виде 4х байт, причем первым передается старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2х байтового заголовка максимальная длина записи равна 32767 байтов, а для 3х байтного заголовка 16383 байтов.
Применение: Значительное использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. В настоящее время HTTPS поддерживается наиболее популярными браузерами. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.
Основные цели протокола в порядке приоритетности:
Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
Совместимость: Программисты, независимо друг от друга могут создавать приложения использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине SSL протокол был включен в необязательную сессию схемы кеширования для уменьшения числа соединений, которые необходимо устанавливать с нуля. Кроме того, большое внимание уделяется тому, чтобы уменьшить сетевую активность.
Аутентификация и обмен ключами:
SSL поддерживает три типа аутентификации: аутентификация обеих сторон (клиент — сервер), аутентификация сервера с неаутентифицированным клиентом и полная анонимность. Всякий раз, когда сервер аутентифицируется, канал безопасен против атаки человек посредине, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами — это создание секрета клиента (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), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента. Существует четыре протокола записи: протокол рукопожатия (handshake protocol), протокол тревоги (alert protocol), протокол изменения шифра (the change cipher spec protocol), протокол приложения (application data protocol). Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол созданный для использования совместно с SSL должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик. Протокол рукопожатия (handshake) SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения. Рукопожатие начинается тогда, когда клиент подключается к SSL серверу. Запрос безопасного соединения представляет собой список поддерживаемых шифров и хэш-функций. Из этого списка сервер выбирает самый сильный шифр и хэш-функцию, которую он также поддерживает, и уведомляет клиентов о сделанном решении. Сервер отсылает это решение в виде цифрового сертификата. Сертификат, обычно, содержит имя сервера, доверенный Центр Сертификации, и открытый ключ шифрования сервера. Клиент может связаться с сервером, который выдал сертификат (доверенного центра сертификации, выше) и убедиться, что сертификат является подлинным прежде чем продолжить. Для того, чтобы сгенерировать ключи сеанса, используется безопасное соединение. Клиент шифрует случайное число с помощью открытого ключа (ОК) сервера и отправляет результат на сервер. Только сервер в состоянии расшифровать его (с его закрытым ключом (ЗК)), и только этот факт делает ключи скрытыми от третьей стороны, так как только сервер и клиент имели доступ к этим данным. Клиент знает открытый ключ и случайное число, а сервер знает закрытый ключ и (после расшифровки сообщения клиента) случайное число. Третья сторона, возможно, знает только открытый ключ, если закрытый ключ не был взломан. Из случайного числа, обе стороны создают ключевые данные для шифрования и расшифрования. На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается. Протокол изменения шифра (The Change Cipher Spec Protocol) Он существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1. struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; Сообщение изменения шифра посылается и клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение ‘finished’. Протокол тревоги (Alert Protocol) Один из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения. Протокол приложения (Application Data Protocol) Сообщение приложения данных работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи. Ошибки в протоколе SSL В протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения. Протокол SSL определяет следующие ошибки: Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент-сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента). No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и сервером. Ошибка неустранима. Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента). No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима. Атаки Опишем ряд атак, которые могут быть предприняты против протокола SSL. Однако, SSL устойчив к этим атакам. Раскрытие шифров Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. SSL же делает такую атаку невыгодной, так как тратится большое количество времени и денег. Злоумышленник посередине Также известна как MIM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации. Замечание. Однако работа HTTPS-фильтра (который устанавливает туннель в обе стороны и отдает свой сертификат клиенту) в MS Forefront TGM, работающая по этой схеме, не является атакой, но средством защиты и контроля. Атака отклика Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 2127 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 2127 достаточно большое число, чтобы сделать эти атаки бессмысленными. Атака против протокола рукопожатия Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают 40-битное экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес. Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения Finished. Без секрета злоумышленник не может исправить сообщение Finished, вот почему атака будет обнаружена. [править] Алгоритмы, использующиеся в SSL Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK. Для аутентификации: RSA, DSA, ECDSA. Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES, Camellia. Для хеш-функций: SHA, MD5, MD4 и MD2.
Сам алгоритм
шестой
SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS. Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причём для шифрования используется асимметричный алгоритм с открытым ключом. При шифровании с открытым ключом используется два ключа, причем любой из них может использоваться для шифрования сообщения. Тем самым, если используется один ключ для шифрования, то соответственно для расшифровки нужно использовать другой ключ. В такой ситуации можно получать защищённые сообщения, публикуя открытый ключ, и храня в тайне секретный ключ.
Протокол SSL состоит из двух подпротоколов: протокол SSL записи и рукопожатия. Протокол SSL записи определяет формат, используемый для передачи данных. Протокол SSL включает рукопожатие с использованием протокола SSL записи для обмена сериями сообщений между сервером и клиентом, во время установления первого соединения. Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат. SSL предоставляет канал, имеющий 3 основных свойства: Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма. Надёжность. Обмен сообщениями включает в себя проверку целостности. Частность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений. В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2х байтового заголовка: RecLength=(byte[0] & 0x7F<<8) | byte[1]; Здесь byte[0] и byte[1] первый и второй полученные байты. Длина записи 3х байтового заголовка: RecLength = (byte[0] & 0x3F<<8)|byte[1]; Escape = (byte[0] & 0x40)!=0; Padding = byte[2]; Здесь Padding определяет число байтов добавленных отправителем к исходному тексту, для того чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра. Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных, и шифрует всё это. Причем содержимое заполнителя никакой роли не играет. Из-за того, что известен объём передаваемых данных, то заголовок может быть сформирован с учетом Padding. В свою очередь получатель записи дешифрует всё поле данных и получает полную исходную информацию. Затем производится вычисление значение RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3х компонент: MAC_Data[Mac_Size] — (Message Authentication Code) — код аутентификации сообщения Padding_Data[Padding] — данные заполнителя Actual_Data[N] — реальные данные Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования, Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data: MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number); Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счетчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32х битовый код, передаваемый хэш-функции в виде 4х байт, причем первым передается старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2х байтового заголовка максимальная длина записи равна 32767 байтов, а для 3х байтного заголовка 16383 байтов.
Применение: Значительное использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. В настоящее время HTTPS поддерживается наиболее популярными браузерами. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.
Основные цели протокола в порядке приоритетности:
Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
Совместимость: Программисты, независимо друг от друга могут создавать приложения использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине SSL протокол был включен в необязательную сессию схемы кеширования для уменьшения числа соединений, которые необходимо устанавливать с нуля. Кроме того, большое внимание уделяется тому, чтобы уменьшить сетевую активность.
Аутентификация и обмен ключами:
SSL поддерживает три типа аутентификации: аутентификация обеих сторон (клиент — сервер), аутентификация сервера с неаутентифицированным клиентом и полная анонимность. Всякий раз, когда сервер аутентифицируется, канал безопасен против атаки человек посредине, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами — это создание секрета клиента (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), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента. Существует четыре протокола записи: протокол рукопожатия (handshake protocol), протокол тревоги (alert protocol), протокол изменения шифра (the change cipher spec protocol), протокол приложения (application data protocol). Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол созданный для использования совместно с SSL должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик. Протокол рукопожатия (handshake) SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения. Рукопожатие начинается тогда, когда клиент подключается к SSL серверу. Запрос безопасного соединения представляет собой список поддерживаемых шифров и хэш-функций. Из этого списка сервер выбирает самый сильный шифр и хэш-функцию, которую он также поддерживает, и уведомляет клиентов о сделанном решении. Сервер отсылает это решение в виде цифрового сертификата. Сертификат, обычно, содержит имя сервера, доверенный Центр Сертификации, и открытый ключ шифрования сервера. Клиент может связаться с сервером, который выдал сертификат (доверенного центра сертификации, выше) и убедиться, что сертификат является подлинным прежде чем продолжить. Для того, чтобы сгенерировать ключи сеанса, используется безопасное соединение. Клиент шифрует случайное число с помощью открытого ключа (ОК) сервера и отправляет результат на сервер. Только сервер в состоянии расшифровать его (с его закрытым ключом (ЗК)), и только этот факт делает ключи скрытыми от третьей стороны, так как только сервер и клиент имели доступ к этим данным. Клиент знает открытый ключ и случайное число, а сервер знает закрытый ключ и (после расшифровки сообщения клиента) случайное число. Третья сторона, возможно, знает только открытый ключ, если закрытый ключ не был взломан. Из случайного числа, обе стороны создают ключевые данные для шифрования и расшифрования. На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается. Протокол изменения шифра (The Change Cipher Spec Protocol) Он существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1. struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; Сообщение изменения шифра посылается и клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение ‘finished’. Протокол тревоги (Alert Protocol) Один из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения. Протокол приложения (Application Data Protocol) Сообщение приложения данных работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи. Ошибки в протоколе SSL В протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения. Протокол SSL определяет следующие ошибки: Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент-сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента). No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и сервером. Ошибка неустранима. Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента). No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима. Атаки Опишем ряд атак, которые могут быть предприняты против протокола SSL. Однако, SSL устойчив к этим атакам. Раскрытие шифров Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. SSL же делает такую атаку невыгодной, так как тратится большое количество времени и денег. Злоумышленник посередине Также известна как MIM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации. Замечание. Однако работа HTTPS-фильтра (который устанавливает туннель в обе стороны и отдает свой сертификат клиенту) в MS Forefront TGM, работающая по этой схеме, не является атакой, но средством защиты и контроля. Атака отклика Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 2127 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 2127 достаточно большое число, чтобы сделать эти атаки бессмысленными. Атака против протокола рукопожатия Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают 40-битное экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес. Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения Finished. Без секрета злоумышленник не может исправить сообщение Finished, вот почему атака будет обнаружена. [править] Алгоритмы, использующиеся в SSL Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK. Для аутентификации: RSA, DSA, ECDSA. Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES, Camellia. Для хеш-функций: SHA, MD5, MD4 и MD2.
седьмой
http://kunegin.com/ref5/ssl/index.htm
http://www.rsdn.ru/forum/network/618824.all.aspx
ВЗЛОМ
1.
15 марта был взломан корневой центр компании Comodo, благодаря чему хакеры получили доступы к SSL-сертификатам таких крупных компаний как Google, Microsoft, Skype и др. В итоге для пользователей ничего страшного не произошло, но данная история показывает, что насколько бы ни казалась надёжной защита данных, всегда можно найти ходы, чтобы её взломать. Напомним, что под новой учетной записью были созданы подделки сайтов www.google.com, mail.google.com, mail.yahoo.com, login.skype.com, login.live.com. Чтобы понять, в чём смысл такого взлома и чем это могло грозить пользователям, надо разобраться в принципе действия SSL-сертификатов. Полагаем, что всем известно, что преобразованием доменного имени, которое пользователь вводит в адресной строке браузера, в IP-адрес, который будет указан в TCP/IP-пакетах, занимаются DNS-сервера(Domain name system). Таким образом, у злоумышленников возникает соблазн взломать DNS-сервер провайдера так, чтобы, например, при запросе браузером пользователя IP-адреса paypal.com отдавался бы не настоящий адрес сервера крупнейшей в мире электронной платёжной системы Paypal, а IP-адрес фишингового сайта, который бы похищал учётные данные пользователей системы. Чтобы этого избежать, используются SSL-сертификаты, которые подтверждают подлинность сайта, и работа по соответствующему протоколу HTTPS, который помимо получения сертификата обеспечивает шифрование передаваемых данных. Для начала немного истории. Протокол SSL (Secure Sockets Layer) был разработан компанией Netscape и вышел в свет сразу в версии 2.0 в феврале 1995 года (версия 1.0 публично не выпускалась). Из-за большого числа недостатков очень быстро, в 1996 году, вышла версия SSL 3.0, а на её базе в 1999 году разработан протокол TLS (Transport Layer Security), который сейчас и используется в интернете. Однако, т.к. различия между ним и SSL 3.0 незначительны, то наравне с TLS по прежнему используется термин SSL. Итак, как же происходит защита домена от подделки? Владелец сайта получает в специальном центре сертификации SSL сертификат (от $80 до $1000 в год в зависимости от типа и числа защищаемых доменов), а также публичный и приватный ключи для шифрования информации. При первом обращении к сайту по HTTPS-протоколу браузер получает SSL-сертификат и публичный ключ, которым он был подписан . Списки доверенных центров сертификации с их ключами есть в каждом браузере, и ключ, который получает браузер, должен совпадать с соответствующим ключом в этом списке. Если браузер удостоверяется, что полученный сертификат выдан доверенным центром сертификации, то далее продолжается нормальная работа, в противном же случае — если пользователь попал на фишинговый сайт, ему будет выдано соответствующее предупреждение. Итак, из всего вышесказанного можно сделать вывод, что для перехвата трафика, который идёт от пользователя к интересующему хакеров сайту, работающему по протоколу HTTPS, необходимо не только взломать DNS, но и получить настоящий SSL-сертификат для этого сайта, чтобы браузер не выдавал никаких тревожных сообщений. Как утверждают представители компании Comodo, центр сертификатов которой был взломан, хакеры находились в Иране. Если это действительно так, и, учитывая, что злоумышленниками были получены сертификаты для таких коммуникационных сервисов, как mail.google.com, mail.yahoo.com, login.skype.com, login.live.com, то можно предположить, что целью были вовсе не деньги пользователей, а их переписка. И действовали хакеры по заданию правительства Ирана, которое хотело перехватить сообщения оппозиционно настроенных граждан. Учитывая, что интернет в Иране полностью контролируется властями, то изменить записи у DNS-провайдеров для нужных доменов не составило бы труда (и, главное, это не получило бы огласки), и логины-пароли иранских пользователей от их почты в gmail и аккаунтов в Skype иранское правительство вполне могло бы получить. Однако, так как в Comodo вовремя заметили факт взлома, то затея эта, кто бы за ней ни стоял, не удалась. Как видим, даже несмотря на произошедший взлом, система SSL-сертификатов подтвердила свою надёжность, т.к. мало взломать сервер, надо ещё скрыть следы взлома, что совсем непросто. После того, как о взломе стало известно, SSL-сертификаты просто меняются центром сертификатов на новые, и тем самым взломщики не достигают поставленных целей. Наверняка многие из вас сталкивались с тем, что посещая серьёзные сайты, работающие по HTTPS-протоколу, вы получали от браузера Firefox сообщения типа «site.ru использует недействительный сертификат безопасности. К сертификату нет доверия, так как сертификат его издателя неизвестен», и далее предлагается нажать либо на «Уходим отсюда», либо на «Я понимаю риск» и «Добавить исключение…». Что это такое? Это использование сервером самоподписанных SSL-сертификатов, которые пригодны для шифрования трафика, но непригодны для идентификации домена. Поскольку владелец сайта сам создаёт сертификат (т.е. экономит деньги на покупке сертификата у соответствующей компании), то у браузера нет в его списке доверенных центров сертификации соответствующего центра, отсюда и возникает сообщение «сертификат его издателя неизвестен». Учитывая, что очень многие уже не раз с этим сообщением сталкивались и привыкли уже нажимать на “Я понимаю риск”, то для хакеров возникает соблазн взломать DNS для соответствующих сайтов, а на фишинговом сайте, куда будет перенаправляться трафик, опять создать самоподписанный сертификат, чтобы пользователь по привычке нажал «Я понимаю риск». Теперь немного о том, почему работа по протоколу HTTPS с нормальными, полученными у доверенных центров сертификации SSL-сертификатами не используется повсеместно. Во-первых, это в принципе нужно далеко не всем сайтам. Не все используют авторизацию на сайтах, и даже там, где она есть, далеко не везде в учётных данных пользователя скрывается информация, несанкционированный доступ к которой может принести ему какой-то серьёзный финансовый или моральный ущерб. Во-вторых, за SSL-сертификаты надо платить. В-третьих, шифровка и расшифровка трафика не происходит сама по себе — этим занимается сервер, а значит на него растёт нагрузка. В-четвёртых, использование шифрования увеличивает объём передаваемых данных, а значит загрузку каналов. В-пятых, самая главная причина — протокол HTTPS рассчитан на то, что сайт находится на выделенном IP-адресе, в то время как сейчас самым популярным видом хостинга является виртуальный хостинг, когда много сайтов находится на одном IP. Для решения этой проблемы разработано расширение к протоколу TLS, однако пока что оно не получило широкого распространения.