Протокол SSL

Протокол SSL

МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РФ

ФГОУ ВПО КОСТРОМСКАЯ ГСХА

Кафедра информационных технологий в энергетике

Реферат по предмету: Компьютерные сети

на тему: «Протокол SSL»

КОСТРОМА 2011

Протокол SSL

Протокол SSL Handshake (Secure Sockets Layer - защищенный протокол) разработан корпорацией Netscape Communications для обеспечения безопасности и секретности интернет-соединений. Протокол поддерживает аутентификацию (установление подлинности) клиента и сервера, не зависит от приложений и прозрачен для протоколов HTTP, FTP и Telnet. Однако, SSL оптимизирован для протокола HTTP, а для FTP более предпочтителен IPSec.

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

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

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

SSL поддерживает разнообразные криптографические алгоритмы. В ходе установления связи используется криптосистема открытого ключа RSA. После обмена ключами используется много разных шифров: RC2, RC4, IDEA, DES и TripleDES. Также используется MD5 - алгоритм создания дайджеста сообщений. Синтаксис сертификатов открытого ключа описан в X.509.

SSL в действии

Главным назначением SSL-протокола, является обеспечение приватного и надежного способа обмена информацией между двумя удаленно взаимодействующими приложениями. Протокол реализуется в виде двухслойной (многослойной) среды, специально предназначенной для безопасного переноса секретной информации, через не засекреченные каналы связи. В качестве первого слоя, в такой среде используется некоторый надежный транспортный протокол; TCP к примеру. По слову "транспортный", не трудно догадаться, что TCP берет на себя функции "несущей", и в дальнейшем, становится извозчиком, для всех лежащих выше слоев (протоколов). Вторым по счету слоем, накладываемым на TCP, является SSL Record Protocol. Вместе, эти два слоя, TCP и SSL Record Protocol, формируют своеобразное ядро SSL. В дальнейшем, это ядро становится первичной герметизирующей оболочкой, для всех последующих более сложных протокольных инфраструктур. В качестве одной из таких структур, используется SSL Handshake Protocol - позволяющий серверу и клиенту идентифицировать друг друга и согласовывать криптографические алгоритмы и ключи, перед тем как приложения, работающие на серверной и клиентской стороне, смогут начать передачу или прием информационных байтов в защищенном режиме.

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

Вы начинаете использовать SSL в тот момент, когда вводите в адресной строке своего браузера URL начинающийся с аббревиатуры HTTPS, рис. 6. В результате, вы подключаетесь к порту за номером 443, который для SSL обычно используется по умолчанию; для стандартного  HTTP соединения, чаще всего используется порт 80. В процессе подключения, браузер пользователя (в дальнейшем клиент), посылает серверу приветственное сообщение (hello message). В свою очередь сервер, также должен посылать клиенту свое приветственное сообщение. Приветственные сообщения, являются первичными, инициализирующими сообщениями и содержат информацию, используемую при дальнейшей настройке открываемого секретного канала. В общем случае, приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа; и сервер, и клиент, генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.

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

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

Обзор SSL

Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:

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

Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.

Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

Не секрет, что можно без особых технических ухищрений просматривать данные, которыми обмениваются между собой клиенты и серверы. Был даже придуман специальный термин для этого - sniffer. А в связи с увеличением объема использования Интернета в коммерческих целях, неизбежно вставал вопрос о защите передаваемых данных. И пользователи не очень были бы рады, если номер их кредитной карточки, был бы перехвачен, каким-нибудь предприимчивым хакером по дороге к виртуальному магазину. И, в общем, появление такого протокола как SSL было вполне закономерным явлением. С одной стороны остаются все возможности сервисных протоколов (для программ-серверов), плюс к этому все данные передаются в зашифрованном виде. И разкодировать их довольно трудно. Следует отметить, что SSL не только обеспечивает защиту данных в Интернете, но так же производит опознание сервера и клиента (server/client authentication). В данный момент протокол SSL принят W3 консорциумом (W3 Consortium) на рассмотрение, как основной защитный протокол для клиентов и серверов (WWW browsers and servers) в сети Интернет.

Рис. 1 - Закодированные данные, передаваемые между сервером и клиентом

Использование SSL

Чаще всего, этот протокол используется в составе любого Интернет-ресурса, осуществляющего манипуляции с личными или финансовыми данными посещающих его пользователей Интернета. Чаще всего, это банки, Интернет-магазины или любые другие виртуальные места, в которых приходящие по своим делам пользователи, вынуждены передавать свои личные, и зачастую, секретные данные. Этого может потребовать и простая регистрация, и процедура оплаты какого-либо товара, или любая другая процедура, при которой пользователи вынуждены честно выдавать свои паспортные данные, PIN-ы и пароли. Если бы все жители земного шара являлись бы порядочными и честными людьми, необходимость бы в использовании SSL, отпала бы сама собой, за не надобностью, ведь защищать информацию было бы просто не от кого. Но, поскольку в реалии мы имеем несколько другое положение вещей, то приходится думать о том, как защитить передаваемую пользователем информацию от посягательств со стороны третьих лиц. Используя обычный HTTP протокол, мы передаем и получаем информацию в чистом, не зашифрованном виде. Таким образом, передаваемая нами информация, может быть легко перехвачена, и использована совершенно посторонним человеком. Помимо этого, существует и другая, на первый взгляд просто смешная угроза. Представьте, ваш банк расположен по адресу #"656414.files/image002.gif">

Рис. 2 - Просмотр информации о шифре браузера

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

Но все эти и им подобные прорехи, не идут ни в какое сравнение с той угрозой, которую могут представлять для пользователя вовремя не отозванные сертификаты. Дело в том, что браузеры обычно поставляются с неким, вполне определенным набором действительных сертификатов, но автоматического механизма проверки этой годности по прошествии некоторого времени - не существует. Таким образом, возможно, что действие, того или иного, используемого вашим браузером сертификата, уже, давно кончилось; мог истечь срок годности, мог быть потерян контроль над личным ключом соответствующим этому сертификату и.т.д. В любом из этих случаев, сертификат автоматически отзывается, и помещается в специальный, так называемый revocation list, или список не годных сертификатов, создаваемый и обновляемый тем или иным сертификационным сообществом (CA). Теперь, если не удалить такой сертификат из вашего браузера, он по прежнему будет числиться как годный, со всеми вытекающими отсюда последствиями.

Следует заметить, что идея, заложенная в протоколе SSL безусловно, хороша. Хотя у нее есть и свои плюсы, и свои минусы, но в целом, этот протокол можно назвать одним из наиболее удачных решений проблемы защиты пользовательских данных при их распространении "открытым" каналом. Этот протокол вполне бы мог стать некой сетевой панацеей. Но, к сожалению, практика, показывает что идея это еще не решение. Без соответствующей практической составляющей, идея так и остается идеей, а потому, пользователи безусловно, должны помнить, что символ замка, появляющийся в строке состояния их Интернет-браузеров, еще не гарантия того, что все наши секреты и тайны находятся под действительно надежной защитой.

Обмен данными по протоколу SSL

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

Наблюдать за диалогом между сервером и клиентом можно с помощью программы «EtherSnoop - Network Sniffer. Программа работает как обычный пакетный сниффер. Который позволяет фиксировать все исходящие и входящие пакеты, в режиме реального времени. Программа имеет простой и понятный интерфейс с легкой навигацией в виде дерева, возможно просматривать содержимое пакетов в hex и текстовом виде, а также применение фильтров на отображение данных. Все данные могут быть сохранены в файл и загружены в программу позднее для более подробного изучения.

Рис. 3 - Интерфейс программы EtherSnoop

Попробуем войти в защищенный канал по адресу https://vkontakte.ru. Как видим, в начале строки у нас вместо привычного «http», стоит «https». Как видно, используется 443 порт для отправки сообщений друг другу.

Рис. 4 - Соединения с сервером

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

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

Первая фаза используется для установления конфиденциального канала коммуникаций.

Вторая - служит для аутентификации клиента.

Фаза 1

Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.

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

Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа,SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

Наконец, после того как мастерный ключ определен, сервер посылает клиенту сообщение SERVER-VERIFY.

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

Фаза 2

Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение «finished». В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

Раз партнер послал сообщение «finished» он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения «finished», протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.

На рисунке представлен SSL диалог.

Рис. 5 - Алгоритм работы SSL

Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что “нечто” зашифровано с помощью ключа "key".

Таблица 1 - При отсутствии идентификатора сессии

Теперь рассмотрим практически наш диалог. Мы будем выступать в качестве клиента с ip адресом 10.10.3.166, а Сервер как видно из рисунка имеет адрес 93.186.227.126.

Рис. 6 - Диалог клиента с сервером

Первые 6 сообщений диалога, похожи на диалог из таблицы 1 и это значит, что у нас отсутствует идентификатор сессии.

Справа вид сообщения в шестнадцатеричном виде. Сообщения можно изменять и переотправлять.

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

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

установить личность владельца;

сделать доступным первичный ключ владельца.

Цифровой сертификат выпускается проверенной полномочной организацией - источником сертификатов (certificate authority - CA) и выдается только на ограниченное время. После истечения срока действия сертификата его необходимо заменить. Протокол SSL использует цифровые сертификаты для обмена ключами, аутентификации серверов и, при необходимости, аутентификации клиентов.

Рис. 7 - Предложение на подписку сертификата

Цифровой сертификат содержит следующие фрагменты информации о личности владельца сертификата и источнике сертификатов:

полное (уникальное) имя владельца сертификата;

публичный ключ владельца;

дата выдачи цифрового сертификата;

дата окончания действия сертификата;

полное (уникальное) имя издателя (источника сертификата);

цифровая подпись издателя.

Подключение по SSL всегда инициируется клиентом вызовом URL-адреса, начинающегося с https:// вместо #"656414.files/image008.gif">

Рис. 8 - Сертификат

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

Рис. 9 - Пересылаемый сертификат на клиента

Более простой и ясный алгоритм такой:

Представьте себе, что есть два человека, которые общаются посредством Интернета и соответственно не видят друг друга. И лишены возможности, узнать, о том кто же его абонент. Их имена - Алиса и Боб. Допустим Алисе надо, узнать действительно она разговаривает с Бобом или нет. В этом случае диалог может выглядеть следующим образом: Алиса отправляет Бобу случайное сообщение. Боб шифрует его с помощью своего приватного ключа и отправляет его Алисе. Алиса дешифрует это сообщение (с помощью публичного ключа Боба). И сравнив это сообщение с посланным, может убедиться в том, что его действительно послал Боб. Но на самом деле со стороны Боба не очень удачная идея шифровать сообщение от Алисы с помощью своего приватного ключа. И возвращать его. Это аналогично подписи документа, о которой Боб мало что знает. С такой позиции Боб должен сам придумать сообщение. И послать его Алисе в двух экземплярах. В первом сообщение передается открытым текстом, а второе сообщение зашифровано с помощью приватного ключа Боба. Такое сообщение называется message digest. А способ шифрования сообщения с помощью своего приватного ключа - цифровой подписью (digital signature).

Теперь закономерно встает вопрос о том, каким образом распространять свои публичные ключи. Для этого (и не только) была придумана специальная форма - сертификат (certificate). Сертификат состоит из следующих частей: Имя человека/организации выпускающего сертификат. Для кого был выпущен данный сертификат (субъект сертификата). Публичный ключ субъекта. Некоторые временные параметры (срок действия сертификата и т.п.). Сертификат подписывается приватным ключом человека (или огрганизации), который выпускает сертификаты. Организации, которые производят подобные операции называются Certificate authority (CA). Если в стандартном Web-клиенте (web-browser), который поддерживает SSL, зайти в раздел security, то там можно увидеть список известных организаций, которые подписывают сертификаты. С технической стороны, создать свою собственную CA достаточно просто. Но против этого могут действовать скорее юридические препятствия.

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

Алиса: привет.

Боб: привет, я Боб (выдает свой сертификат).

Алиса: а ты точно Боб?

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

Алиса: все нормально, ты действительно Боб. (И присылает Бобу секретное сообщение, зашифрованное с помощью публичного ключа Боба).

Боб: А вот и мое сообщение (посылает сообщение, которое было зашифровано с помощью секретного ключа, например того же шифрованного сообщения Алисы).

Поскольку Боб знает сообщение Алисы, потому что он владеет приватным ключом и Алиса знает, что было в том сообщении. Теперь они могут использовать симметричный шифровальный алгоритм (где в качестве секретного ключа выступает сообщение Алисы) и безбоязненно обмениваться шифрованными сообщениями. А для контроля над пересылкой сообщений (от случайного/преднамеренного изменения) используется специальный алгоритм - Message Authentication Code (MAC). Довольно распространенным является алгоритм MD5. Обычно, и сам MAC-code так же шифруется. В связи с этим достоверность сообщений повышается в несколько раз. И внести изменения в процесс обмена практически невозможно.

Список использованных источников

протокол программа интерфейс ключ

1. http://book.itep.ru

. http://oradb1.jinr.dubna.su/Netscape/MISC/SSL.htm

. http://kunegin.narod.ru/ref5/ssl/

. http://delphiworld.narod.ru/base/ssl_protocol.html

. http://www.ibm.com/developerworks/ru/library/ac-iscssl1/index.html

. http://freessl.ru/

. http://www.securitylab.ru/software/1272/ (программы и описание к

ним)

. http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

. http://nsa.by.ru/docs/security/s23.html

10. <http://ru.wikipedia.org>