На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

ОСОБЕННОСТИ ПОВТОРНЫХ ЗАПРОСОВ в S-HTTP

Ошибки Unauthorized 401 и Payment Required 402 представляют типичные схемы HTTP-сообщений об ошибке, используемых для идентификации и оплаты. (В S-НТТР существуют другие сообщения об ошибке — они используются для ука­зания ошибок идентификации.) В S-НТТР нет четкой поддержки механизмов ошибок 401 и 402. Однако их легко можно заменить при помощи средств обеспе­чения безопасности. Например, в S-НТТР введено новое сообщение о состоя­нии сервера — Security Retry420. С его помощью сервер может попросить клиента послать повторный запрос с другими параметрами шифрования.
Сообщение SecurityRetry 420 говорит о том, что (по некоторым причинам) сервер считает, что примененные клиентом шифрования запроса являются не-
удовлетворительными, и поэтому клиент должен повторить запрос с параметрами, перечисленными в заголовке ответа. Обратите внимание: ответ SecurityRetry 420 очень удобен для инициирования повторного согласования открытых ключей. Он используется в том случае, если закончился срок действия одноразового ключа или если нужно передать уникальное значение Nonce (чтобы проверить связь). Код ошибки BogusHeader 421 указывает, что в запросе что-то не так. Обычно в
этом случае следует такой код ошибки:
BogusHeader 421 Content-Privacy-Domain must be specified
Ограничены на автоматические повторные запросы
Использование повторных запросов позволяет хакеру провести некоторые виды атак. Рассмотрим, например, случай, когда пользователь просматривает доку­мент, в котором нужно указать номер кредитной карточки. Пользователь может удостовериться в том, что DN получателя допустим что можно зашифровать запрос. После этого пользователь повторно ссылается на анкер. Атакующий перехватывает ответ сервера и посылает клиенту сообщение, зашифрованное при помощи открытого ключа клиента. В этом сообщении содержится заголо­вок Moved 301. Если клиент автоматически выполнит перенаправление, то оно поможет раскрыть хакеру номер кредитной карточки.
автоматический повторный запрос шифрования
Клиенты должны избегать автоматического повторного шифрования данных до тех пор, пока сервер (запросивший повторный запрос) не сообщит о том, что у
него уже есть эти данные. Далее описаны ситуации, когда можно использовать повторное шифрование:
• Сервер зашифровал и вернул ответ на повторный запрос, воспользовав­шись ключом, определяемым во время передачи. Используемый ключ был сгенерирован сервером для первоначального запроса.
• Получатель первоначального запроса создал цифровую подпись повторно­го ответа.
• В первоначальном запросе использовался внешний ключ, и сервер за­шифровал ответ при помощи этого ключа.
Этот список далеко не полон. Несмотря на это автор броузера должен хоро­шенько подумать, прежде чем реализовать автоматическое повторное шифрова­ние. Короче говоря, если, вы не уверены, является ли пользователь тем самым человеком, за которого себя выдает, стоит осведомиться у него, хочет ли он воспользоваться повторным шифрованием.
В руководстве по S-HTTP запрещается использование броузеров, поддержива­ющих протокол, в котором используется автоматический повторный запрос под­писи. Однако если предположить, что подобный броузер соблюдает все остальные спецификации, его разработчики могут автоматически повторно использовать идентификацию MAC.
ЭЛЕМЕНТЫ S-HTTP HTML
Несмотря на то что S-HTTP прежде всего является набором расширений прото­кола HTTP, он отличается от SSL. Дело в том, что новый протокол включает в себя некоторые расширения языка HTML и стандарта URL. Далее приводится подробное описание всех этих нововведений. Однако вы должны уяснить, что реализовать S-НТТР на сервере можно при помощи вставки дополнительной программы в программу сервера, либо изменив элементы документов HTML. Последний метод имеет значительные преимущества по сравнению с использо­ванием SSL.
S-HTTP HTML и РАСШИРЕНИЯ ФОРМАТА URL
Как уже обсуждалось, S-HTTP определил некоторые новые элементы HTML и формата URL. В частности, в S-НТТР определен новый указатель протокола URL — s-http, который используется в качестве анкера URL. Он указывает, что сервер назначения использует протокол S-HTTP, и поэтому вы должны зашиф­ровать повторную ссылку на этот URL. При помощи безопасных URL можно использовать дополнительные атрибуты анкера (они описаны далее). Обратите внимание: нельзя позволять игнорирующим S-НТТР агентам повторно ссылать­ся на URL с указателем неизвестного протокола, чтобы их клиенты не могли случайно послать секретные данные.
Анкер_Описание_
DN Имя (Distinguished Name) администратора доступа,
у которого сервер запрашивает шифрование при повтор­ной ссылке на URL анкера. Не нужно указывать DN, но если вы его укажете, то возможна ситуация, когда клиент будет не в состоянии определить это DN и поэтому не сможет зашифровать передаваемое сообщение. NONCE Строка, включаемая в заголовок S-HTTP-Nonce:. Это
делается в том случае, если сервер повторно ссылается на анкер. CERTS Этот элемент определяет местоположение используемых сервером сертификатов.
CRYPTOPTS        Информация о параметрах шифрования. Если эти сведения занимают несколько строк, то необходимо _заключить их в кавычки._
ЭЛЕМЕНТ CERTS
В S-HTTP дополнительно определен CERTS. В нем содержится информация о группе сертификатов (не обязательно связанных друг с другом),
предоставляемых в виде дополнительных данных. Не нужно показывать пользо­вателю содержание этого элемента. Тег CERTS может содержать группы серти­фикатов, соответствующих реализациям РЕМ или PKCS-7. Такие сертификаты используются в документах HTML для удобства получателя. Без них последний не смог бы получить сертификат, соответствующий DN, указанному в некотором анкере.
Формат элемента CERTS должен быть таким же, как и у описанной ранее строки заголовка «Certificate-Info», за исключением того, что создатель Web-страниц должен использовать в качестве FMT-атрибута указатель <Cert-Fmt>. В S-HTTP разрешено использование нескольких элементов CERTS в документе HTML. На самом деле в спецификациях нового протокола предполагается, что эти элемен­ты будут включены в элемент HEAD. В этом случае броузеры, не использую­щие S-НТТР, не будут отображать эти данные.
ЭЛЕМЕНТ
Программисты и создатели Web-страниц могут разбить CRYPTOPTS на элемент и ссылку на него. Атрибут NAME определяет имя, с помощью которого можно будет ссылаться на этот элемент (внутри расположенного в анкере атрибута CRYPTOPTS). В начале имени должен стоять символ «#». Например, элемент CRYPTOPTSможет быть реализован следующим образом:
CRYPTOPTS=''S-HTTP-Privacy-Enhancements: recv-refused=encrypt; S-HTTP-Signature-Algorithms: recv-required=NIST-DSS"
РЕЗЮМЕ
Напомню, что протокол HTTP был разработан для передачи Но­вый протокол S-HTTP расширяет возможности HTTP и обеспечивает безопас­ность сообщений в Web. В следующей главе я расскажу еще об одном из наиболее широко используемых протоколов безопасности Internet. Но прежде, чем перейти к его изучению, убедитесь, что усвоили следующие основные понятия:
дополняет набор инструкций HTTP. Новые инструкции обеспе­чивают поддержку шифрования информации и других средств безопаснос­ти транзакций.
✓ Для обеспечения безопасности транзакций в S-НТТР используется метод цифровых подписей, шифрование и идентификация отправителя сообще­ния.
В новом протоколе используются схемы шифрования с симметричным и асимметричным ключом.
В S-HTTP реализована поддержка сертификатов и создания подписей ключей.

В новом протоколе есть средства поддержки зашифрованных сквозных передач данных, включая запрос HTTP CONNECT.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика