Интегрированные сети ISDN
Протокол диалога TLS
7. Протокол диалога TLS
Протокол диалога TLS содержит набор из трех суб-протоколов, которые используются, чтобы партнеры могли согласовать используемые параметры безопасности для уровня записи, аутентифицировать себя, и уведомлять друг друга об ошибках.
Протокол диалога ответственен за согласования характеристик сессии, куда входят следующие объекты:
| идентификатор сессии | Произвольная последовательность байтов, выбранная сервером для идентификации состояния сессии (активная/ возобновляемая). |
| сертификат партнера | X509v3 [X509] сертификат партнера. Этот элемент состояния может быть равен нулю. |
| метод сжатия | Алгоритм, используемый для сжатия информации перед шифрованием. |
| спецификация шифра | Специфицирует алгоритм массового шифрования (такой как нуль, DES, и т.д.) и алгоритм MAC (такой как MD5 или SHA). Она определяет также криптографические атрибуты, такие как hash_size. (Смотри приложение A.6) |
| мастерный секретный код | 48-байтовый секретный код, общий для сервера и клиента. |
| 'is resumable' | Флаг, указывающий, может ли сессия использоваться для инициализации нового соединения. |
Эти объекты используются затем для определения параметров безопасности для уровня записей при защите прикладных данных. Многие соединения могут реализоваться в рамках той же сессии с помощью процедуры возобновления (resumption) протокола диалога.
7.1. Протокол изменения спецификации шифра
Протокол изменения спецификации шифра предназначен для оповещения об изменении стратегии шифрования. Протокол использует одно сообщение, которое зашифровано и архивировано в рамках текущего состояния соединения. Сообщение состоит из одного байта со значением 1.
struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;
Сообщение изменения спецификации шифра посылается как клиентом, так и сервером, для того чтобы уведомить партнера о том, что последующие записи будут защищены с помощью только что согласованных ключей и спецификации CipherSpec. Получение этого сообщения заставляет получателя на уровне записей немедленно скопировать состояние ожидания чтения в текущее состояние чтения.
Сразу после посылки сообщения отправитель должен дать команду уровню записей преобразовать состояние ожидания записи в активное состояние записи. (Смотри раздел 6.1.) Сообщение изменения спецификации шифра посылается во время диалога после согласования набора параметров безопасности, но до посылки проверочного завершающего сообщения (смотри раздел 7.4.9).
7.2. Протокол оповещения
Одним из типов содержимого, поддерживаемого слоем записей TLS, является оповещение. Сообщения оповещения передают описание возникшей ситуации. Оповещения с аварийным уровнем вызывают немедленное прерывание соединения. В этом случае, другие соединения сессии могут оставаться в рабочем состоянии, но идентификатор сессии должен быть объявлен не действительным, блокируя установление новых соединений. Подобно другим сообщениям, оповещения шифруются и сжимаются, как это специфицировано состоянием текущего соединения.
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { close_notify(0),
| unexpected_message(10), | |
| bad_record_mac(20), | |
| decryption_failed(21), | |
| record_overflow(22), | |
| decompression_failure(30), | |
| handshake_failure(40), | |
| bad_certificate(42), | |
| unsupported_certificate(43), | |
| certificate_revoked(44), | |
| certificate_expired(45), | |
| certificate_unknown(46), | |
| illegal_parameter(47), | |
| unknown_ca(48), | |
| access_denied(49), | |
| decode_error(50), | |
| decrypt_error(51), | |
| export_restriction(60), | |
| protocol_version(70), | |
| insufficient_security(71), | |
| internal_error(80), | |
| user_canceled(90), | |
| no_renegotiation(100), |
struct { AlertLevel level; AlertDescription description;} Alert;
7.2.1. Оповещения закрытия
Клиент и сервер должны оба знать, что соединение завершается, для того чтобы избежать атаки усечения (truncation). Оба партнера могут запустить обмен сообщениями закрытия.
| close_notify | Это сообщение обращает внимание получателя, что отправитель не будет посылать более каких-либо данных через это соединение. Сессия становится не возобновляемой (unresumable), если любое соединение разорвано без соответствующих сообщений close_notify с уровнем равным предупреждению. |
/p> Оба партнера могут инициализировать закрытие, послав уведомление close_notify. Любые данные, полученные после оповещения о закрытии, игнорируются.
Каждый из партнеров обязан послать уведомление close_notify, прежде чем разрывать соединение со стороны записи. Требуется, чтобы другой партнер реагировал своим уведомлением close_notify и закрывал соединение немедленно, аннулируя все не завершенные записи. Для инициатора закрытия не требуется ждать получения отклика close_notify, прежде чем закрыть соединение со стороны чтения. Если прикладной протокол, использующий TLS, гарантирует, что любые данные могут быть переданы через используемое TLS-соединение после его закрытия, реализация TLS должна получить уведомление-отклик close_notify до оповещения прикладного уровня о том, что соединение TLS завершает свою работу. Если прикладной протокол не передает никаких дополнительных данных, но лишь закрывает ниже лежащее транспортное соединение, тогда реализация может выбрать вариант закрытия транспорта, не дожидаясь отклика close_notify.
Предполагается, что закрытие соединения надежно доставляет все данные, ждущие передачи, прежде чем транспортная система будет блокирована.
7.2.2. Оповещения об ошибках
Обработка ошибок в протоколе диалога TLS очень проста. Когда обнаруживается ошибка, обнаруживший партнер посылает сообщение другому партнеру. При передаче или получении сообщения о фатальной ошибке, оба партнера немедленно закрывают соединение. Серверы и клиенты должны забыть любые идентификаторы сессии, ключи и секретные коды, связанные с неудачным соединением. Определены следующие оповещения об ошибках:
| unexpected_message | Получено не предусмотренное сообщение. Это оповещение является всегда фатальным и не должно встречаться при обменах между корректными реализациями. |
| bad_record_mac | Это оповещение присылается, если получена запись с неверным MAC. Это сообщение всегда вызывает фатальную ошибку. |
| decryption_failed | TLSCiphertext дешифрован не верно: либо текст не имел длину четную и кратную размеру блока или их значения (заполнители) при проверке оказались некорректными. Это сообщение всегда вызывает фатальную ошибку. |
| record_overflow | Получена запись TLSCiphertext, которая имеет длину больше 214+2048 байт, запись дешифрована TLSCompressed в запись с более чем 214+1024 байтов. Это сообщение всегда вызывает фатальную ошибку. |
| decompression_failure | Функция декомпрессии получила неприемлемые данные (напр., данные, которые после восстановления будут иметь слишком большой объем). Это сообщение вызывает фатальную ошибку. |
| handshake_failure | Получение сообщения оповещения handshake_failure указывает, что отправитель не мог согласовать приемлемый набор параметров безопасности из числа предлагаемых опций. Это фатальная ошибка. |
| bad_certificate | Сертификат был поврежден, содержал подписи, которые не прошли проверку и т.д.. |
| unsupported_certificate | Сертификат имел не поддерживаемый тип. |
| certificate_revoked | Сертификат был отозван его подписантом. |
| certificate_expired | Сертификат имеет исчерпанный срок годности или не пригоден по другой причине. |
| certificate_unknown | Некоторая другая, не специфицированная причина при обработке сертификата, делающая его неприемлемым. |
| illegal_parameter | Поле при диалоге оказалось вне диапазона допустимых значений или не согласуется с другими полями. Это фатальная ошибка.. |
| unknown_ca | Получена корректная сертификатная последовательность или ее часть, но сертификат не был воспринят из-за того, что CA-сертификат не может быть обнаружен или не согласуется с известным проверенным CA. Это сообщение всегда вызывает фатальную ошибку. |
| access_denied | Получен правильный сертификат, но при проверке доступа отправитель решил не продолжать согласование. Это сообщение всегда вызывает фатальную ошибку. |
| decode_error | Сообщение не может быть дешифровано из-за того, что некоторое поле выходит за пределы допустимого или сообщение имеет не верный размер. Это сообщение всегда вызывает фатальную ошибку. |
| decrypt_error | Диалог криптографической операции не прошел, это может включать неудачу проверки подписи, обмена ключами или контроль завершающего сообщения. |
| export_restriction | Согласование параметров вошло в противоречие с экспортными регламентациями. Например: попытка передать 1024 битов ephemeral RSA-ключа для метода диалога RSA_EXPORT. Это сообщение всегда вызывает фатальную ошибку. |
| protocol_version | Протокольная версия клиента распознана, но не поддерживается. (Например: старые версии протокола могут отвергаться по соображениям безопасности). Это сообщение всегда вызывает фатальную ошибку. |
| insufficient_security | Возвращается вместо handshake_failure, когда согласование не прошло в частности из-за того, что сервер требует более секретного шифра, чем может поддержать клиент. Это сообщение всегда вызывает фатальную ошибку. |
| internal_error | Внутренняя ошибка, не связанная с партнером, или требования протокола не допускают продолжения процедуры (например, ошибка при выделении памяти). Это сообщение всегда вызывает фатальную ошибку. |
| user_canceled | Этот диалог аннулирован по какой-то причине, не связанной с протокольной ошибкой. Если пользователь аннулирует операцию после завершения диалога, закрытие соединения путем посылки close_notify является более приемлемым. За этим оповещением должно следовать close_notify. Это сообщения является предупреждением. |
| no_renegotiation | Посылается клиентом в ответ на запрос hello или сервером - в ответ на hello клиента после стартового диалога. Любое из этих сообщений должно, в норме, вызывать повторное согласование параметров. Когда это не приемлемо, получатель должен реагировать посылкой этого уведомления (alert). В этой точке отправитель исходного запроса может решить, следует ли сохранять соединение. Случаем, когда это приемлемо, может оказаться ситуация, когда сервер запускает процесс, чтобы удовлетворить запросу. Процесс может получить параметры безопасности (длину ключа, аутентификацию и т.д.) при запуске, и может быть, трудно сообщить об изменении этих параметров в этой точке процесса. Это сообщение всегда является предупреждением. |
/p> Для всех ошибок, где уровень оповещения не специфицирован явно, отправитель может сам определить, является ли ошибка фатальной. Если получено оповещение с уровнем предупреждения, получатель может сам решить, воспринимать ли ее как фатальную. Однако все сообщения, которые переданы с фатальным уровнем, должны рассматриваться как фатальные.
7.3. Обзор протокола диалога
Криптографические параметры состояния сессии формируются протоколом диалога TLS, который работает поверх уровня записей TLS. Когда клиент и сервер TLS впервые начинают взаимодействие, они согласуют версию протокола, выбирают криптографические алгоритмы, опционно аутентифицируют друг друга и используют методику с общедоступным ключом для формирования общего секретного кода. Протокол диалога TLS включает в себя следующие шаги:
Заметим, что верхние слои не должны слишком полагаться на TLS, всегда согласуя самые безопасные из возможных соединений между партнерами: существует много способов, с помощью которых злоумышленник, включившийся в разрыв соединения, может попытаться заставить партнеров принять наименее безопасный метод связи из числа поддерживаемых ими. Протокол был устроен так, чтобы минимизировать этот риск, но, тем не менее, существуют некоторые возможности атак. Например, хакер может блокировать доступ к порту, через который обеспечивается безопасное обслуживание, или попытаться заставить партнеров установить не аутентифицированное соединение.
Фундаментальным правилом является то, что верхние уровни должны знать, каковы требования безопасности и никогда не передавать данные по каналам, которые менее безопасны, чем это предписано этими требованиями. Протокол TLS является безопасным, здесь любой шифровой набор предлагает свой уровень безопасности. Если вы согласуете использование 3DES с 1024-битовым RSA-ключом при связи с ЭВМ, чей сертификат вы проверили, вы можете быть уверены в безопасности. Однако вы никогда не должны посылать данные по каналу, где используется 40-битовая шифрование, если только вы не уверены, что данные не стоят того, чтобы кто-то тратил силы на их дешифрование.
Эти цели достигаются протоколом диалога, который может быть суммирован следующим образом. Клиент посылает сообщение hello, на которое сервер должен также откликнуться сообщением hello, в противном случае возникает ситуация фатальной ошибки и соединение разрывается. Сообщения client hello и server hello используются для установления более безопасного взаимодействия клиента и сервера. Сообщения client hello server hello устанавливают следующие атрибуты: версия протокола, ID-сессии, шифровой набор и метод сжатия. Кроме того, партнеры генерируют и пересылают друг другу два случайных числа: ClientHello.random и ServerHello.random.
Реальный обмен ключами использует до четырех сообщений: сертификат сервера, ключевой обмен сервера, сертификат клиента и ключевой обмен клиента. Новые методы ключевого обмена могут быть созданы с помощью спецификации формата для этих сообщений, чтобы позволить клиенту и серверу согласовать использование общего секретного кода. Этот секретный код должен быть достаточно длинным. Современные методы ключевого обмена пересылают коды длиной от 48 до 128 байт.
Вслед за сообщениями hello, сервер, если он должен быть аутентифицирован, посылает свой сертификат. Кроме того, если необходимо, может быть послано сообщение ключевого обмена (например, если сервер не имеет сертификата, или если его сертификат служит только для подписи).
Если сервер аутентифицирован, он может затребовать сертификат от клиента, если выбран соответствующий шифровой набор. После этого сервер пошлет сообщение hello done, указывающее, что фаза диалога hello завершена. Сервер ждет отклика клиента. Если сервер послал сообщение сертификатного запроса, клиент должен послать сообщение сертификата. Сообщение ключевого обмена клиента послано, и его содержимое зависит от алгоритма с общедоступным ключом, который выбрали клиент и сервер при обмене сообщениями hello.
В этой точке клиентом посылается сообщение об изменении спецификации шифра, и клиент копирует записанную шифровую спецификацию в текущую спецификацию. После этого клиент немедленно посылает сообщение finished для новых алгоритмов, ключей и секретных кодов. В качестве отклика сервер пошлет свое сообщение об изменении шифровой спецификации, перенесет записанную шифровую спецификацию в текущую, и пошлет свое сообщение finished с использованием новой шифровой спецификации. В этой точке диалог завершается, а клиент и сервер могут начать обмен прикладными данными (смотри блок-схему обмена ниже на Рисунок .1).
| Клиент | Сервер |
| ClientHello --------> | |
| ServerHello | |
| Certificate* | |
| ServerKeyExchange* | |
| CertificateRequest* | |
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
| Finished --------> | |
| [ChangeCipherSpec] | |
| Прикладные данные | Прикладные данные |
