Geum.ru

Проверить путь, действительно ли он подтверждает подлинность чего-нибудь. По каждому сертификату. Для каждого сертификата проверяется Его целостность

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

Это такая распределенная и в деталях сложная операция, но нет принципиальных сложностей. Хотя если детализировать это на уровне программ, то каждая операция это много действий.
  1. Поиск сертификационного пути. Если исходного пути нет, то его нужно каким-то образом построить. Полазить по местам, где сертификаты публикуются, выбрать там нужный репозиторий. Эта операция уже не такая тривиальная. И если говорить на абстрактном уровне, то структуру взаимных подписей можно изобразить в качестве графа, и поиск сертификационного пути, это поиск пути в этом графе, задача маршрутизации. Причем, в данном случае не нужно искать оптимальный путь, достаточно найти хотя бы один любой путь, удовлетворяющий определенным ограничениям. То, что эти ограничения выполняются или не выполняются можно узнать только после того, как собран весь путь. И если выясняется, что они не выполняются, тогда нужно искать другой путь. Сложность в том, что все эти сертификаты могут располагаться в репозиториях по разному устроенных, с разными протоколами доступа, и не все из этих способов устройств репозитория и протоколы позволяют извлечь необходимую информацию. А о протоколах мы будем говорить минут через 5, и станет более понятно, что к чему. Но если отправляться только от сертификата, то в нем есть идентификатор выпускающего и это, по крайней мере, ссылка по дереву вверх. Что бы понять, кто выпускающий и поискать его сертификат. Таким образом, пусть вверх всегда есть. А со всем остальным уже гораздо хуже. И особенно сложно, конечно, в ситуациях кросс-сертификации, когда сертификаты принадлежат разным веткам, разным иерархиям удостоверяющих центров.

Протоколы



Есть удостоверяющий центр, УЦ, Certification Authority, CA. Есть пользователи этой системы, которые предстают в разных ролях. То есть это те же самые пользователи, но в разные моменты своего взаимодействия. И по этим ролям их имеет смысл разделить.
  • Заявители. Те, кто хотят, что бы УЦ выпустил им сертификат.
  • Проверяющие. Те, кто хочет проверить подлинность открытого ключа какого-то другого пользователя, с кем они собираются вступить в защищенное соединение.

Внутри самой этой системы, как мы помним, тоже могут быть какие-то деления. Собственно УЦ, публикация сертификатов, публикация списков отзывов, и на границе этой системы есть еще репозитории. Поскольку вся эта система может быть распределенной, то её архитектура предполагает использование разных протоколов. Протоколы, которые относятся к взаимодействию Заявителя с УЦ, разных подразделений УЦ и подразделений с репозиториями называются управляющими. Никаких протоколов можно и не делать, поскольку все можно переслать по почте, на дискете, и здесь скорость не требуется. А протоколы, которые связаны с обращением проверяющих в репозитории и с другими процессами, возникающими при проверке и поиске сертификатов, называются операционными. Вот тут уже скорость важна и эти протоколы важны. Ну не сказать, что управляющие совсем уж не важны, вот например, есть такой специальный элемент данных с определенным форматом – запрос на выпуск сертификатов. Способ доставки может быть разным, но сам этот запрос стандартизирован и структурирован. Можно считать это протоколом. А по поводу операционных протоколов предполагалась и даже вводилась определенным стандартом полная свобода. Вот, например, в качестве протокола доступа к репозиторию допускается использовать протоколы общего назначения TCP и UDP. Этому посвящен целый RFC2538. Разумеется, все сертификаты или списки отзывов должны лежать в определенных каталогах со стандартизированными именами файлов, так что бы можно было более менее автоматически найти и выбрать, но собственно в этом стандарт и заключается. Предлагалось (но широко не использовалось) использовать протоколы DNS в качестве системы доступа к этим репозиториям. Для этого в DNS был даже введен дополнительный тип ресурсной записи CERT, сертификат. Я напомню, что в DNS есть своя система сертификации ключей. Но это способ хранить сертификаты X.509 не для своих нужд, а для нужд каких-то других. Проблема в том, что эти способы хранения позволяют хранить сами списки отзывов, но не позволяют как-то отражать связи между УЦ, в частности, не позволяют отразить информацию, если для поиска пути нужно перескочить в другой репозиторий. Вот такие простые способы. Знаешь доменное имя или URL или имя в смысле X.500 – получаешь сертификат, а не знаешь – ничего получить не можешь.

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

Во-первых, LDAP сам является реализацией ???. Это Lightweight Directory Access Protocol. Облегченный протокол доступа к каталогам. То что LDAP это средство доступа к X.500 это явно написано в спецификациях протокола. Поэтому все эти Distinguished Name, ASN.1 это вполне естественные и встроенные вещи. Тут произошла некая подмена. Исходно X.509 разрабатывался как система аутентификации встроенной в этот стандарт X.500, а тут получается наоборот, X.500 используется для внешних целей, а сам каталог используется для хранения информации, для хранения сертификатов.

Во-первых, LDAP это иерархическая база данных, подобно DNS. Во-вторых, в отличие, к примеру, от DNS, это база данных с изменяемой и расширяемой структурой. В этой базе данных есть язык определения данных. Как в реляционной базе данных есть язык определения данных (Create table bla-bla-bla), так и здесь есть свой язык определения данных, который позволяет описать структуры, которые должны в этой базе хранится. Этот язык основан на ASN.1. Более того, расширяемые структуры между объектами, которые могут там появится – между объектами может стоять отношение наследования. То есть она немножко объектно-ориентирована. Немножко, потому что настоящая объектно-ориентированая БД предполагает что в этой БД еще и хранится поведение, то есть методы, процедуры и пр. И тут хранятся только данные. Но сами структуры данных могут обладать иерархией наследования.

Протокол описан в документах (вообще-то их много, но основные) RFC 1777-1779. Для использования в качестве репозитория в этот протокол были введены еще усовершенствования. В частности, такое усовершенствование как возможность перенаправления запросов. Это проще всего пояснить на примере другого протокола. Вспомним DNS, как разыскивается доменное имя? Исходно сервер получает запрос. Он перенаправляет клиента, он точно знает, куда надо направить этот запрос, и он перенаправляет клиента на другой сервер. Тот, если не может обслужить знает куда дальше перенаправить и отправляет клиента на третий сервер. Иерархическая система DNS просто делает эту процедуру формализованной и она происходит автоматически.

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

А вторая вещь связанная не с самим LDAP, а именно с использованием. Были разработаны специальные схемы баз данных репозитория, сертификатов открытых ключей, списков отзывов. Что значит схемы? Схема это определение на языке ASN.1. Как должна быть устроена база данных LDAP для того что бы служить репозиторием открытых ключей или репозиторием сертификатов. На эту тему тоже есть интернет-стандарт RFC2056, RFC2587. И вот в этих схемах как раз и предусмотрено специально легко обнаруживаемые места для хранения сертификатов и кросс-сертификатов, сертификатов старшего и подчиненным УЦ. Таким образом вся часть этой системы или по крайней мере её обозримая часть может быть отражена в этой структуре. И на основе одной такой БД или нескольких, связанных между собой ссылками перенаправления вполне можно решать задачи поиска путей. Еще был придуман специальный протокол LDAP, предназначенный для того что бы на репозитории в виде LDAP можно было ссылаться из сертификатов как на репозитории исходной публикации этого сертификата так и на репозиторий, хранящий списки отзывов, в которых может появиться этот сертификат. Ну и, в принципе, хорошая практика вот эти все ссылки в сертификат в качестве расширений вкладывать. То есть вы имеете сертификат, а в нем сразу имеются ссылки на все необходимые репозитории, а если вам необходимо что-то достроить, то поисковый процесс начинает искать внутри репозитория, переходит с одного на другой и, в конце концов, определяет сертификационный путь или определяет, что такого пути нет. Исходную информацию, необходимую для раскрутки можно поместить в сам сертификат.


Был придуман еще один протокол OCSP, Online Certificate Status Protocol, RFC2560.

Протокол быстрого доступа к списку отзывов. Что бы при проверке сертификационного пути быстро убеждаться, что некоторые сертификаты отозваны или не отозваны.


Протоколы DPV и DPD, Delegated Path Validation и Delegated Path Discovery, RFC3379.

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


Протокол DVCS, Data Validation And Certification Server Protocol. RFC3029. Это тоже протокол связи с выделенным сервером, то когда на него возлагаются вообще все криптографические операции, связанные с открытыми ключами. Исходно был предложен именно такой протокол, но потом оказалось, что лучше делегировать по частям (протоколы DPV и DPD)


Протокол SCVP, Simple Certificate Validation Protocol. Тоже протокол.


Эталонной библиотекой программного обеспечения для почти всего кроме перечисленных протоколов, для реализации операций с сертификатами на сегодняшний день является библиотека OpenSSL.

Как следует из названия цель этой библиотеки это реализация протокола SSL, но в действительности это огромная библиотека в которую включены разные вспомогательные операции. Симметричные алгоритмы шифрования (почти все известные), ассиметричные алгоритмы (тоже почти все), генерация открытых ключей, выпуск сертификатов, поддержка форматов специальных сообщений типа «запрос на выпуск». Ну и собственно там есть реализация протокола SSL. Конкретно операций с сертификатами там реализованы неудобно, утилиты командной строки, в которых нужно длинно набирать параметры, очень неудобны. Это скорее демо для тех функций, которые включены в библиотеку. Коммерческие компании выпускают специальное программное обеспечение, там более удобные библиотеки для УЦ. Но в принципе, если у вас не на потоке это дело, можно поставить это программное обеспечение, оно бесплатное и из командной строки все это делать, если это не очень частая операция. То есть, необходимый минимум для развертывания УЦ тут имеется.

На этом закончим с X.509.

Протокол SSL. Secure Socket Layer.

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

Исходно он был разработан на базе Netscape Communication. В ходу были версии 2 и 3 этого протокола. По поводу версии 3 Netscape выпустил internet draft в 1996, протокол к тому времени туже вовсю эксплуатировался. Internet draft это такой предварительный документ для включения в RFС, но до состояния RFC этот документ так и не был доработан.

Поводом для разработки этого протокола (я это уже говорил и не раз) была идея организовать дистанционную торговлю. Это надо было передавать защищенным способом разную защищенную информацию. Суммы, реквизиты, номера кредитных карт и прочее. Это было время, когда компания Netscape лидировала в области Интернет-технологий. Ну а потом огромная Microsoft её практически вытеснила и сейчас компания существует но её слава померкла. Стандартизацию этого протокола приняла на себя организация IETF. В связи с этим было введено новое название этого протокола – TLS, Transport Layer Secure. Сейчас в ходу версия 1 этого протокола, RFC224, 1999г. Фактически TLS v1 от SSL v3 ничем не отличается, разница в каких-то битах длинах полей, отдельных названиях. На самом деле это один и тот же протокол.

Для защищенных соединений через интернет придумана специальная аббревиатура https, которая обозначает то же самое что и http, но подразумевает, что весь этот трафик туннелируется через защищенное SSL-соединение. Соответствующий URL https://... Используется порт 443. С тех пор область применения этого протокола расширилась. Сначала это развивалось как и http, то есть для защищенных вариантов smtp, imap и pop3 были зарезервированы отдельные порты. Это до сих пор, кстати, порты imap порт 993, pop3 порт 995, но потом от этой практики отошли и после этого протокол SSL встроен в непосредственно эти протоколы.
  • SMTP, IMAP, POP3
  • Встраиваивание в почтовые протоколы.

Во всех эти протоколах, хотя они разные была введена практически одинаковая команда StartTLS, Это предложение переключится на защищенное соединение. Если другая сторона выражает согласие, то на том же открытом TCP-соединении устанавливается защищенное соединение и сеанс целевого протокола начинается сначала («Привет – Привет – Я такой-то», как и положено в протоколах).

Защищенная версия протокола snews, nntp over ssl, 361 порт. (неразборчиво)

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

Положение этого протокола в стеке протоколов.

Мы знаем, что TCP/IP это стек из четырех уровней. Есть транспортный уровень, и есть прикладной. SSL встраивается между транспортным и прикладным уровнем. Ну даже не сочсем так. Правильнее было бы говорить, что SSL отъедает часть прикладного уровня. И если бы мы выделяли как в модели OSI 7 уровней, а не 4, правильнее было бы сказать, что SSL реализует уровни сеансовый и представлений. Реализуется SSL, как правило, в виде библиотечки, которая входит в состав приложения UserSpace, не в ядре. Транспортные протоколы реализуются в ядре. Если на такой крупно вложенной схеме SSL это просто прослойка между транспортным и прикладным уровнем, то внутри SSL сам состоит из нескольких протоколов и даже есть несколько уровней.

SSL это протокол передачи потока, поэтому в качестве транспорта он может использовать TCP, но не UDP. А тому, кто используется SLL кажется (по максимуму сделано так, что бы казалось) что он использует просто TCP, но не UDP.

Внутренняя структура.



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

Application Data Protocol, ADP, это собственно то, во что инкапсулируются пользовательские данные. То что непосредственно взаимодействует с пользователем, то что имитирует работу сокета обычного, то что снаружи кажется как работа обычного протокола TCP.

Handshake Protocol, HP, это приложение, которое отвечает за установление и разрыв защищенного соединения.

Alert Protocol, AP, это протокол сообщения об ошибке

Change Cipher Spec, CCS – то очень маленький смешной протокол, но важный в своем месте. По ходу дела мы дойдем до него.

Все эти протоколы используют Record Layer как транспорт.


Прежде всего, формат представления информации в форме RecordLayer.

Хотя это протокол передачи потока, при проходе через RecordLayer поток делится на фрагменты, на записи, поэтому и называется Record. Каждая запись выглядит следующим образом.
  • ContentType, 1 байтное поле. Номер протокола следующего уровня. Смешивать в одной записи данные разных протоколов невозможно. А вот поделить запись верхнего протокола на несколько записей RecordLayer можно.
    • 23 – ADP
    • 22 – HP
    • 21 – AP
    • 20 – CCS
  • Version, 2 байтное поле. Версия протокола SSL.
  • Length, 2 байтное поле. Длина самой записи в байтах.
  • Data, часть переменной длины где находятся собственно данные. Это сообщение одного из протоколов следующего уровня.

Вот такой вид имеют данные на верхнем уровне подуровня RecordLayer. Такая структура называется SSLPlainText. Верхнем подуровне – потому что RecordLayer cам состоит из нескольких уровней.



Овальчики это значит что это операция.

Следующее преобразование, которое проводится (может проводиться) в рамках SSL, это компрессирование данных. А соответственно принимающая сторона будет их декомпрессировать. И после этого компрессирования данные представлены в виде структуры, которая называется SSLCompress. Вообще-то она точно такая же как SSLPlainText. Затем проводится еще одна операция, собственно тут все криптографические преобразования проводятся. И в результате возникает еще одна структура, которая называется SSLCipherText. Она уже отличается немножко от того что мы видели.
  • ContentType, 1 байтное поле
  • Version, 2 байта
  • Length, 2 байта
  • Дальше имеются варианты.
    • Рассмотрим сначала самый распространенный вариант. Один вариант это данные и заполнитель плюс MAC-код. Такой вид записи нужен, если используется блочный шифр и заполнитель нужен что бы выровнять данные на границу этого блочного шифра. И все это зашифровано.
    • Используется потоковый шифр и никакого заполнителя нет. А потом опять MAC-код, который тоже имеет переменную длину. Длина MAC-кода зависит от того какой алгоритм используется. И все это зашифровано.



Именно в таком виде данные поступают к протоколу TCP, который и доставляет их на другую сторону соединения. Ну а когда они доставлены, естественно, производится обратное преобразование и именно в таком виде их получает тот протокол, к которому он адресован.

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


Протокол ADP

Собственно никакого протокола и нет. Ставится ContentType, и в область данных попадают те данные, которые собиралось переслать приложение.

Протокол CCS

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

Протокол AP

Сообщение состоит из двух байт.
  • Level – уровень серьезности ошибки
    • 1 – warning
    • 2 – fatal (приводит к немедленному разрыву защищенного соединения)
  • Description – описание, фактически код ошибки для разных ошибок и ситуаций в работе протокола предусмотрены разные коды. Например,
    • unexpected_message(10)
    • bad_record_mac(20),
    • decompression_failure(30),
    • handshake_failure(40)
    • no_certificate(41),
    • bad_certificate(42),
    • unsupported_certificate(43), неподдерживаемый сертификат (либо формат сертификата, либо алгоритм ключа который эта сторона не понимает)
    • certificate_revoked(44), Проверяющая сторона обнаружила, что сертификат отозван.
    • certificate_expired(45), срок действия сертификата вышел
    • certificate_unknown(46),
    • illegal_parameter (47)
    • close_notify(0), обмениваются при разрыве соединения. Предупреждение.

Сообщения 10-40 всегда фатальные. 41-45 могут быть как фатальными, так и предупреждениями в зависимости от политики принятой сторонами.