Безопасное сетевое взаимодействие (часть 2)

Протокол Рукопожатия TLS

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

В результате выполнения протокола Рукопожатия будут созданы элементы сессии показанные в таблице 21.3.

Протокол изменения шифрования

Протокол состоит из единственного сообщения, которое зашифровано и сжато, как определено в текущем (не ожидаемом) состоянии соединения.

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

Alert протокол

Одним из протоколов, лежащих выше протокола Записи, является протокол Аlert. Содержимым протокола является либо фатальное, либо предупреждающее сообщение. Фатальное сообщение должно приводить к немедленному разрыву данного соединения. В этом случае другие соединения, соответствующие данной сессии, могут быть продолжены, но идентификатор сессии должен быть сделан недействительным для предотвращения использования данной сессии для установления новых соединений. Подобно другим сообщениям, сообщения Alert зашифрованы и сжаты, как определено в текущем состоянии соединения.

Сообщения закрытия

Клиент и сервер должны оба узнать о том, что соединение завершается. Каждый участник может инициировать обмен сообщениями закрытия.

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

Каждый участник может инициировать закрытие посылкой сообщения Alert типа close_notify. Любые данные, отправленные после Alert-закрытия, игнорируются.

Требуется, чтобы каждый участник посылал close_notify Alert перед закрытием стороны записи соединения. Это означает, что при получении ответа другого участника с Alert типа close_notify соединение немедленно закрывается и все ожидаемые состояния сбрасываются. Инициатору закрытия не обязательно ждать ответного close_notify Alert перед закрытием стороны чтения соединения.

Если прикладной протокол, использующий TLS, предполагает, что какие-либо данные могут передаваться нижележащим транспортом после того как соединение TLS закрыто, реализация TLS должна получать ответный Alert типа close_notify перед тем как сообщать прикладному уровню, что соединение TLS завершено. Если прикладной протокол не будет передавать никаких дополнительных данных, а будет только закрывать нижележащее транспортное соединение, реализация может закрыть соединение без ожидания ответного close_notify. В стандарте TLS не определен способ, которым управляются данные транспорта, включая открытие и закрытие соединений.

Замечание: предполагается, что при закрытии соединения ожидающие доставки данные надежно доставляются перед разрушением транспорта.

Alerts ошибок

Ошибки обрабатываются в протоколе Рукопожатия следующим образом. Когда один из участников соединения обнаруживает ошибку, он посылает соответствующее сообщение другому участнику. При передаче или получении сообщения фатального Alert оба участника немедленно закрывают соединение. Сервер и клиент должны сбросить все идентификаторы сессии, ключи и секреты, связанные с этим соединением.

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