ОСНОВНЫЕ НОВОВВЕДЕНИЯ S-HTTP
Как уже отмечалось, в протоколе S-HTTP предусмотрено несколько механизмов обеспечения безопасности клиентов и серверов HTTP. Все они разработаны для того, чтобы удовлетворить требованиям различных приложений Web. Более того, в S-HTTP клиенту и серверу предоставляются равные возможности (т. е. запросы и ответы обрабатываются одинаковым образом; кроме того, одинаково обрабатываются и параметры обеих сторон). Однако это ничуть не мешает поддерживать модель транзакций HTTP. Протокол позволяет поддерживать различные режимы и методы шифрования, а полная его установка позволяет изменять процесс шифрования в зависимости от запросов клиента.
Можно внедрить в сервер или клиент S-HTTP неограниченное количество стандартов шифрования информации (включая PKCS-7 и РЕМ). В этом протоколе предусмотрена поддержка взаимодействия различных реализаций, а также полная совместимость с HTTP. Таким образом, клиенты, работающие с протоколом S-HTTP, могут сообщаться с серверами, работающими по протоколу HTTP, и наоборот. Однако в подобных транзакциях не будут использоваться встроенные в S-HTTP возможности защиты информации.
В S-HTTP от клиента не требуется наличие сертификата открытого ключа (или самого ключа — в зависимости от настройки сервера). Вместо этого в протоколе используется режим работы с симметричным одноразовым ключом. Этот режим очень важен потому, что с его помощью пользователи могут насладиться всеми преимуществами нового протокола, не обладая при этом сертификатом. Однако это не значит, что в протоколе нет поддержки цифровых сертификатов — просто они не обязательны. Мы подробнее поговорим об этом в следующей главе.
В S-HTTP введены средства защиты сквозных транзакций. Новые средства намного отличаются от механизмов идентификации HTTP. Для создания безопасной транзакции в протоколе HTTP требуется, чтобы сервер особым образом ответил на запрос клиента. В этом случае сервер может «заставить» клиента начать безопасную транзакцию (обычно для этого используется информация, расположенная в анкере HTTP). Серверы могут использовать этот метод для поддержки шифрования форм без использования шифрования и обеспечения безопасности на всем сервере.
Алгоритм шифрования и режимь цифровой подписи s-http
Протокол S-HTTP обладает достаточно гибкими алгоритмами шифрования, режимами и параметрами. Для того чтобы клиент и сервер могли договориться об используемых режимах безопасной транзакции (вроде использования в запросах и ответах цифровых подписей, шифрования или обоих этих методов), в S-HTTP
есть специальная возможность согласования. Кроме того, в новом протоколе есть возможность согласования алгоритмов шифрования (для создания цифровых подписей - RSA или DSA; для шифрования - DES или RC2 и т. д.) и сертификатов (вроде запроса на создание подписи при помощи «сертификата Mastercard»). В S-HTTP не предусматривается какой-либо конкретной модели. Наоборот, предполагается, что каждая из сторон может обладать целым набором сертификатов.
В защита сообщений обеспечивается тремя методами: цифровая подпись, идентификация сообщения и шифрование передаваемой информации. Все они могут использоваться по отдельности и в различных комбинациях (а могут не использоваться вообще). Кроме того, в S-HTTP предусмотрены механизмы управления несколькими ключами, обмен открытыми ключами и распространение билетов Kerberos. В частности, протокол предоставляет возможность использовать заранее установленный симметричный одноразовый ключ. С его помощью можно пересылать информацию пользователям, не имеющим набора ключей. Вдобавок в S-HTTP предусмотрена возможность проверки состояния соединения.
ЦИФРОВЫЕ подписи и S-HTTP
Для поддержки цифровых подписей в S-HTTP используется один из видов стандарта PKCS-7 - SignedData (или SignedAndEnvelopedData).Если сервер запрашивает цифровую подпись, клиент может поместить соответствующий сертификат в сообщение или ожидать, что сервер сам разыщет его. Обратите внимание: в S-HTTP строго запрещено использование «самодельных» сертификатов (созданных и подписанных самим пользователем, а не ведомством сертификатов). Как сервер отнесется к подобному сертификату, зависит от его настройки. Например, многие сайты, поддерживающие работу с банками, могут потребовать от пользователя приобрести сертификат у компании третьей стороны. Именно таким образом эти сайты пытаются защититься от «мнимых» личностей. В любом случае, все подписи сообщений совместимы с PKCS-7.
ОБМЕН КЛЮЧАМИ и ШИФРОВАНИЕ
Как уже говорилось, сервер S-HTTP зашифровывает каждое послание. Если к серверу одновременно присоединено несколько клиентов (что, согласитесь, не такая уж редкость в Web), то ему придется одновременно обрабатывать и зашифровывать десятки сообщений. Как вы усвоили из предыдущих глав, шифрование с открытым ключом занимает гораздо больше времени, чем шифрование с единым ключом. Поэтому для обеспечения нормальной производительности в S-HTTP определены два механизма передачи ключей: обмен ключами во время передачи и использование внешних ключей. В первом случае сервер зашифровывает личный ключ при помощи открытого ключа клиента и пересылает его клиенту. Как показано в главе 4, получателем такого сообщения может быть только тот, у кого есть личный ключ. После того как получатель расшифрует ключ, вся дальнейшая информация будет зашифрована при помощи этого ключа. Обмен ключами во время передачи схематично показан 15.
Во втором случае (который больше подходит для корпоративных сетей) для получения доступа к S-HTTP-серверу отправитель должен зашифровать сообщение при помощи заранее условленного одноразового ключа. При этом в зависимости от вида передаваемых данных информация о ключе помещается в одной из строк заголовка запроса или заголовка объекта (6). Кроме того, пользователи могут воспользоваться билетами Kerberos. О них будет рассказано в главе 10. показан обмен при помощи внешних ключей.
ЦЕЛОСТНОСТЬ ДАННЫХ и ИДЕНТИФИКАЦИЯ ОТПРАВИТЕЛЯ
Как уже говорилось, в S-HTTP реализована возможность проверки целостности данных и идентификации отправителя сообщения. Для этого в протоколе используется метод цифровой подписи (в S-HTTP он называется кодом идентификации сообщения [MAC - Message Authentication Code]). Приложения S-HTTP вычисляют MAC как смешанное с ключом значение: сначала вычисляется смешанное значение документа, а затем оно зашифровывается при помощи симметричного ключа. Для размещения MAC в файле можно воспользоваться различными методами (вроде Kerberos или ручного внедрения). Для работы с MAC использование шифрования с открытым ключом не требуется.
Механизм MAC также позволяет общающимся сторонам проводить идентификацию сообщений без использования цифровых сертификатов. Разработчики S-НТТРбыли уверены, что создание подписей транзакций в будущем будет широко использоваться всеми пользователями сети. Поэтому они и включили в протокол механизм MAC. Однако этот механизм не запрещает использовать для обмена ключей шифрование с открытым ключом. Таким образом, протокол S-HTTP окажется очень полезным там, где нужно обязательно проводить идентификацию клиента (например, при управлении доступом).
СОСТОЯНИЕ ТРАНЗАКЦИЙ
В S-HTTP предусмотрен простой механизм проверки состояния передачи (transmission freshness). С его помощью сервер может проверить, кем прислано
сообщение. Таким образом, можно отслеживать ситуации, когда вместо сообщения пользователя серверу приходит скопированное хакером сообщение. Подобное явление происходит в том случае, если хакер скопировал пакет, взломал зашифрованное сообщение и послал его от имени клиента. Кроме того, в новом стандарте HTTP-заголовок сообщения Date может использоваться в качестве индикатора состояния (однако при этом требуется, чтобы установка S-HTTP
предусматривала возможность работы с различными часовыми поясами, компьютерами с неправильно установленным системным временем и т. д.).
ИНКАПСУЛЯЦИЯ
Сообщение состоит из строки запроса или состояния, за которой следует набор заголовков RFC-822, а за ним - зашифрованное тело сообщения. Телом сообщения может быть другое сообщение S-HTTP, сообщение HTTP или просто какие-нибудь данные. Для совместимости с HTTP запросы и ответы в
S-HTTP отделяются друг от друга при помощи указателя протокола. Другими словами, вместо стандартной строки «НТТР I. I»заголовок MIME содержит строку «Secure-HTTP/l.I». Однако остается вероятность того, что будущие реализации протокола HTTP будут обладать всеми необходимыми средствами обеспечения
безопасности данных и использование S-HTTP станет ненужным. Для этого заголовок S-HTTP инкапсулируется по всем правилам HTTP — если какое-либо из приложений не распознает его, то он попросту будет проигнорирован.
ЗАПРОСА S-HTTP
Запросы S-HTTP построены по той же схеме, что и запросы HTTP (6). Специально для запросов HTTP разработчики нового протокола ввели метод Secure. Все безопасные запросы (использующие протокол S-HTTP версии 1.1) должны содержать в заголовке MIME следующую строку:
Secure * Secure-HTTP/1.1
Безопасный сервер должен быть независимым от регистра. В этой строке «звездочка» служит в качестве заменителя символов. Вместо нее клиенты, работающие с сервером-посредником, должны вставить URL запроса; как минимум, они должны обеспечить расположенную в URL секцию хоста и ссылку на порт -все эти действия строго регламентированы в HTTP. Например, полная версия
безопасного запроса для сервера-посредника (для доступа к безопасному Web-
серверу) должна выглядеть следующим образом:
Secure http://www.secure-server.com:80/ Secure-HTTP/1.1
Обратите внимание на то, что, в отличие от SSL, в S-HTTP в качестве стандартного порта используется порт с номером 80. Как уже упоминалось (6), этот же порт является стандартным и для HTTP.
СТРОКА ОТВЕТА
Как уже упоминалось, броузер должен тщательно просматривать ответы сервера. В главе 6 говорилось о том, что при успешной обработке запроса сервер посылает ответ 200 ОК. В S-HTTP первая строка ответа сервера должна выглядеть следующим образом:
Secure-HTTP/l. 1 200 OK
В этом протоколе первая строка ответа также является индикатором того, успешно ли прошел запрос. Однако если в качестве ответа сервер будет всегда посылать эту строку, то броузеру не придется анализировать причины ошибки. Тем самым сервер лишает хакера возможности получить информацию о причине запрета доступа к безопасному серверу. Таким образом, безопасный сервер должен всегда посылать код об успешной обработке запроса.
СТРОКИ ЗАГОЛОВКА
В S-HTTP определено несколько новых строк заголовка сообщения. Все они являются необязательными, за исключением строк Content-Type и Content-Privacy-
Domain. Тело сообщения отделяется от строк заголовка при помощи двух пар символов cr1 -г. Все данные и строки заголовка являются нечувствительными к регистру (если не указано обратное). Визуальные разделители служат для разделения заголовка и тела сообщения. Однако это правило может быть нарушено в том случае, если некоторое поле потребует использования свободных строк (нескольких символов CR). Как и в HTTP, для более удобного представления текста можно разбивать длинные строки заголовка на несколько строк.
ДОПУСТИМЫЕ типы СОДЕРЖАНИЯ СООБЩЕНИЯ
Итак, представим, что сервер (или броузер) расшифровал тело сообщения и получил содержание исходного (незашифрованного) сообщения. В обычных условиях содержание сообщения рассматривается как сообщение HTTP 1.0. Если сообщение и в самом деле является сообщением HTTP 1.0, то в нем будет присутствовать следующая строка:
Content-Туре: application/http
Пара application/http зарегистрирована IANA как один из типов MIME. Для обеспечения обратной совместимости в S-HTTP используется пара application/ x-http. Однако полученное содержание может использовать другой тип, который должен быть четко- определен строкой заголовка Content-Type. Итак, если тип содержания отличается от или x-http, то броузер (или сервер) должен использовать поля заголовка для последнего (наиболее глубоко инкапсулированного) сообщения HTTP. Обратите внимание: так как HTTP-сообщение (из которого сервер или броузер извлекают заголовки) зашифровано, то в нем можно
спокойно размещать конфиденциальную информацию.
Таким образом, механизм Content-Type полезен для передачи расширенных данных (в особенности заранее подписанных) и не требует при этом изменения
заголовков HTTP.
ЗАГ0Л0В0К ' PREARRANGED Key-Info
В этой строке заголовка содержится информация о ключе, заранее установленном без использования средств шифрования (например, при помощи флоппи-диска). Строка PrearrangedKey-Info обеспечивает возможность обмена ключа во время передачи. Однако с ее помощью можно выбрать и другой механизм, такой как список одноразовых (one-time) ключей.
При использовании заранее установленного внешнего ключа не забывайте о том, что в определено три метода обмена ключами: во время передачи,
и вне передачи.
Элементы <inband> и <Ы> указывают, что общающиеся стороны обменялись ключом заранее (при помощи заголовка соответствующего метода).
Обмен ключами вне передачи (указываемый элементом подразумевает, что агенты обладают внешним доступом к материалам ключа (например, при помощи базы данных или непосредственного ввода с клавиатуры). Синтаксис этой строки заголовка приведен ниже:
Prearranged-Key-Info: <Hdr-Cipher>','<CoveredDEK>1,
'<CoverKey-ID> <CoverKey-ID> := <метод>','<имя-ключа> <CoveredDEK> : = <шестнадцатиричное-значение> <метод> := 'inband' | ^^'<kv> | 'outband' <kv> := '4' I '5'
В таблице 7.1 приведены все остальные параметры этой строки.
Имя элемента_Описание_
<Hdr-Cipher> Содержит имя блока шифра, при помощи которого
отправитель зашифровывает одноразовый ключ.
< Covered DEK^ Этот элемент представляет имя защищенного ключа
Data Exchange Key (его также называют ключом транзакции), с помощью которого передающий хост зашифровывает инкапсулированное сообщение. Для каждой транзакции отправитель должен сгенерировать отдельный ключ DEK, Передающий хост должен зашифровать каждую транзакцию при помощи одноразового ключа, а затем преобразовать результат в шестнадцатиричный формат. Во избежание использования одинаковых имен хост и порт должны ._поддерживать различные пространства имен ключей.
Нестандартные параметры строки заголовка Prearranged-Key-Info.
ЗАГОЛОВОК MA С-Info
Как уже отмечалось, модель транзакций s-HTTP поддерживает создание цифровых подписей передаваемых данных. Для идентификации сообщений, проверки их целостности используется новое средство — MAC. Оно вычисляется на основе текста сообщения, текущего времени (этот параметр не обязателен, однако с его помощью можно обезопасить себя от повторов атак) и совместно используемого клиентом и сервером пароля или набора кодов (codeset). Использующий S-HTTP броузер (или сервер) должен вычислить MAC при помощи инкапсулированного содержания сообщения S-HTTP.
Имея алгоритм смешивания Н, использующий S-HTTPхост должен вычислить MAC при помощи описанной ниже формулы. Пункты сообщения разделены при помощи символа «||»; таким образом, при вычислении MAC каждый последующий пункт добавляется к предыдущему:
МАС = hex (Н(Message| |<время>| |<совместно используемый ключ>>)
Время должно представляться в виде 32-битного беззнакового значения. Значение 00:00:00 GMT соответствует 1 января 1970 года (эпоха Unix). Формат совместно используемого ключа зависит от самого ключа (которым стороны обмениваются заранее).
Формат строки ма с-In] выглядит следующим образом:
Идентификатор (ID) ключа ссылается на определенные в строке Key-Assigi ключи, либо на ключи, указанные в том же порядке, что и метод Outband. Использование в строке Спецификация ключа> значения "null" подразумевает, что отправитель использует ключ нулевой длины. В этом случае MAC просто представляет собой смешанное значение текста сообщения и (необязательно) время. Специальное значение "dek"-это ссылка на использование спецификации Data Exchange Key. В этом случае тело сообщения будет зашифровано при помощи стандарта
Примечание. Использование спецификации ПЕК совместно с незашифрованным телом сообщения вызовет ошибку.
Обратите внимание: при помощи строки MAC-Info можно воспользоваться усовершенствованной версией стандартного режима HTTP-идентификации. Для этого пользователь должен указать свое имя и пароль. Однако пароль остается личным, а целостность сообщения проверяется — т. е. установка S-HTTP проверяет целостность сообщения и вход в систему (log-in) без использования шифрования. Кроме того, механизм MAC-Info позволяет проводить быструю проверку сообщений (при этом вы уже не сможете использовать полученное сообщение в качестве улики против его отправителя). В этом случае подразумевается, что обе стороны совместно используют некоторый ключ (которым они могли обменяться при помощи Key-Assign).