 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Создаваемые элементы сессии
| Идентификатор сессии | Произвольная последовательность байтов, выбираемая сервером для идентификации активного или возобновляемого состояния сессии |
| Сертификат участника | Х.509 v3 сертификат участника. Этот элемент может быть нулевым |
| Метод сжатия | Алгоритм, используемый для сжатия данных перед шифрованием |
| Набор алгоритмов | Алгоритм симметричного шифрования данных (такой как null, DES и т.д.), МАС-алгоритм (такой как MD5 или SHA) и различные криптографические атрибуты, такие как hash_size |
| Мастер-секрет | 48-байтный секрет, разделямый клиентом и сервером |
| Возобновляемо | Флаг, определяющий, может ли данная сессия использоваться для создания нового соединения |
Сообщение об изменении шифрования может посылаться как клиентом, так и сервером для уведомления получающей стороны о том, что следующие записи будут защищены алгоритмами и ключами, о которых стороны только что договорились. При поступлении данного сообщения получатель должен информировать протокол Записи о немедленном копировании ожидаемого состояния чтения в текущее состояние чтения. Сразу после посылки данного сообщения отправитель должен информировать протокол Записи на своем конце соединения о немедленном копировании ожидаемого состояния записи в текущее состояние записи. Сообщение об изменении шифрования посылается при Рукопожатии после того, как параметры безопасности согласованы, но перед тем как посылается заключительное верифицирующее сообщение.
Alert протокол
Одним из протоколов, лежащих выше протокола Записи, является протокол Аlert. Содержимым протокола является либо фатальное, либо предупреждающее сообщение. Фатальное сообщение должно приводить к немедленному разрыву данного соединения. В этом случае другие другие соединения, соответствующие данной сессии, могут быть продолжены, но идентификатор сессии должен быть сделан недействительным для предотвращения использования данной сессии для установления новых соединений. Подобно другим сообщениям, сообщения Alert зашифрованы и сжаты, как определено в текущем состоянии соединения.
Сообщения закрытия
Клиент и сервер должны оба узнать о том, что соединение завершается. Каждый участник может инициировать обмен сообщениями закрытия.
Сообщение close_notify уведомляет получателя о том, что отправитель не будет больше посылать никаких сообщений по данному соединению. Сессия становится невозобновляемой, если хотя бы одно соединение завершено без соответствующего предупреждающего сообщения close_notify[41].
Каждый участник может инициировать закрытие посылкой сообщения Alert типа close_notify. Любые данные, отправленные после Alert-закрытия, игнорируются.
Требуется, чтобы каждый участник посылал close_notify Alert перед закрытием стороны записи соединения. Это означает, что при получении ответа другого участника с Alert типа close_notify соединение немедленно закрывается и все ожидаемые состояния сбрасываются. Инициатору закрытия не обязательно ждать ответного close_notify Alert перед закрытием стороны чтения соединения.
Если прикладной протокол, использующий TLS, предполагает, что какие-либо данные могут передаваться нижележащим транспортом после того как соединение TLS закрыто, реализация TLS должна получать ответный Alert типа close_notify перед тем как сообщать прикладному уровню, что соединение TLS завершено. Если прикладной протокол не будет передавать никаких дополнительных данных, а будет только закрывать нижележащее транспортное соединение, реализация может закрыть соединение без ожидания ответного close_notify. В стандарте TLS не определен способ, которым управляются данные транспорта, включая открытие и закрытие соединений.
3.3 Защита на уровне IP
IP Security - это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.
Спецификация IP Security (известная сегодня как IPsec) разрабатывается Рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов «Архитектура безопасности IP», «Аутентифицирующий заголовок (AH)», «Инкапсуляция зашифрованных данных (ESP)» (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 - RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES[42].
Рис.3.2. Архитектура IPSec
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol[43].
Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. «контекста безопасности» – применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности[44].
По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.
Таблица 3.4
Поиск по сайту: