mutual tls что это
СОДЕРЖАНИЕ
Этапы процесса и проверка
Чтобы убедиться, что взаимная аутентификация прошла успешно, логика Барроуза-Абади-Нидхема ( логика BAN) является хорошо зарекомендовавшим и широко распространенным методом, поскольку она проверяет, что сообщение пришло от надежного объекта. Логика BAN сначала предполагает, что объекту нельзя доверять, а затем проверяет его законность.
Защиты
Взаимная проверка подлинности поддерживает сети с нулевым доверием, поскольку она может защитить коммуникации от враждебных атак, в частности:
Взаимная аутентификация также обеспечивает целостность информации, поскольку, если стороны подтверждают, что они являются правильным источником, полученная информация также является надежной.
Облегченные схемы против защищенных схем
Хотя упрощенные схемы и схемы безопасности не исключают друг друга, добавление этапа взаимной аутентификации к протоколам передачи данных часто может увеличить время выполнения и вычислительные затраты. Это может стать проблемой для сетевых систем, которые не могут обрабатывать большие объемы данных или тех, которые постоянно должны обновляться для получения новых данных в реальном времени (например, отслеживание местоположения, данные о состоянии здоровья в реальном времени).
Приложения, которые полагаются исключительно на связь между устройствами (D2D), когда несколько устройств могут взаимодействовать локально в непосредственной близости, удаляют стороннюю сеть. Это, в свою очередь, может ускорить время общения. Однако аутентификация по-прежнему происходит по незащищенным каналам, поэтому исследователи считают, что по-прежнему важно обеспечить взаимную аутентификацию, чтобы сохранить безопасную схему.
Схемы могут принести в жертву лучшее время выполнения или стоимость хранения при обеспечении взаимной аутентификации, чтобы сделать приоритетом защиту конфиденциальных данных.
Схемы на основе паролей
В схемах взаимной аутентификации, которые требуют ввода пароля пользователя как части процесса проверки, существует более высокая уязвимость для хакеров, поскольку пароль создается человеком, а не сертификатом, созданным компьютером. Хотя приложения могут просто требовать от пользователей использования пароля, сгенерированного компьютером, людям неудобно его запоминать. Создаваемые пользователем пароли и возможность изменить свой пароль важны для того, чтобы сделать приложение удобным для пользователя, поэтому многие схемы работают, чтобы учесть характеристики. Исследователи отмечают, что протокол на основе паролей с взаимной аутентификацией важен, потому что идентификационные данные пользователей и пароли по-прежнему защищены, поскольку сообщения доступны для чтения только двум вовлеченным сторонам.
Многофакторная аутентификация
В последнее время все больше схем имеют более высокий уровень аутентификации, чем схемы на основе пароля. В то время как аутентификация на основе пароля рассматривается как «однофакторная аутентификация», в схемах начинают реализовываться схемы аутентификации на основе смарт-карт ( двухфакторная ) или биометрическая (трехфакторная). Смарт-карты проще реализовать и легко аутентифицировать, но все же есть риск взлома. Биометрия стала более популярной по сравнению со схемами на основе паролей, потому что при использовании биометрии сложнее копировать или угадывать ключи сеанса, но может быть сложно зашифровать зашумленные данные. Из-за этих рисков и ограничений безопасности схемы могут по-прежнему использовать взаимную аутентификацию независимо от того, сколько факторов аутентификации добавлено.
Схемы на основе сертификатов и системные приложения
Взаимная аутентификация часто встречается в схемах, используемых в Интернете вещей (IoT), где физические объекты включены в Интернет и могут связываться через IP-адрес. Схемы аутентификации могут применяться ко многим типам систем, которые включают передачу данных. Поскольку присутствие Интернета в механических системах увеличивается, написание эффективных схем безопасности для большого числа пользователей, объектов и серверов может стать сложной задачей, особенно когда требуется, чтобы схемы были легкими и имели низкие вычислительные затраты. Вместо аутентификации на основе пароля устройства будут использовать сертификаты для проверки личности друг друга.
Радиосети
Взаимная аутентификация может быть удовлетворена в схемах радиосети, где передача данных через радиочастоты является безопасной после проверки отправителя и получателя.
Метки радиочастотной идентификации (RFID) обычно используются для обнаружения объектов, которые многие производители внедряют в свои складские системы для автоматизации. Это позволяет быстрее вести инвентаризацию и отслеживать объекты. Однако отслеживание элементов в системе с помощью RFID-меток, которые передают данные на облачный сервер, увеличивает шансы на угрозу безопасности, поскольку теперь существует больше цифровых элементов, которые необходимо отслеживать. Между RFID-метками, считывателями меток и облачной сетью, в которой хранятся эти данные, может происходить трехсторонняя взаимная аутентификация, чтобы обеспечить безопасность данных RFID-меток и их невозможность манипулировать.
Аналогичным образом, альтернативная система RFID-меток и считывателей, которая назначает назначенные считыватели меткам, была предложена для дополнительной безопасности и низкой стоимости памяти. Вместо того, чтобы рассматривать все считыватели тегов как одно целое, только определенные считыватели могут читать определенные теги. При использовании этого метода, если читатель взломан, это не повлияет на всю систему. Отдельные считыватели будут взаимодействовать с определенными тегами во время взаимной проверки подлинности, которая выполняется в постоянное время, поскольку считыватели используют один и тот же закрытый ключ для процесса проверки подлинности.
Многие системы электронного здравоохранения, которые удаленно контролируют данные о здоровье пациентов, используют беспроводные сети тела (WBAN), которые передают данные через радиочастоты. Это полезно для пациентов, которых не следует беспокоить во время наблюдения, и может снизить нагрузку на медицинских работников и позволить им сосредоточиться на более практических задачах. Однако большую озабоченность поставщиков медицинских услуг и пациентов по поводу использования удаленного отслеживания медицинских данных вызывает то, что конфиденциальные данные пациента передаются по незащищенным каналам, поэтому аутентификация происходит между пользователем локальной сети медицинского органа (пациентом) и поставщиком медицинских услуг (HSP). и доверенная третья сторона.
Облачные вычисления
Машинная проверка
Многие системы, не требующие участия человека в системе, также имеют протоколы, которые взаимно аутентифицируют стороны. В системах беспилотных летательных аппаратов (БПЛА) происходит аутентификация платформы, а не аутентификация пользователя. Взаимная аутентификация во время связи с транспортным средством предотвращает взлом системы одного транспортного средства, что может негативно повлиять на всю систему. Например, система дронов может использоваться для сельскохозяйственных работ и доставки грузов, но если один дрон будет взломан, вся система может рухнуть.
Что такое TLS
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.
Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, который предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.
TLS и MTLS для Skype для бизнеса Server
Протоколы безопасности транспортного слоя (TLS) и Mutual Transport Layer Security (MTLS) обеспечивают зашифрованную связь и проверку подлинности конечных точек в Интернете. Skype для бизнеса Server эти два протокола используются для создания сети доверенных серверов и обеспечения шифрования всех сообщений по этой сети. Все SIP-связи между серверами происходят через MTLS. SIP-сообщения от клиента к серверу происходят через TLS.
TLS позволяет пользователям с помощью клиентского программного обеспечения проверить подлинность Skype для бизнеса Server серверов, к которым они подключаются. В подключении TLS клиент запрашивает действительный сертификат с сервера. Чтобы быть действительным, сертификат должен быть выдан ЦС, которому также доверяет клиент, а имя DNS сервера должно соответствовать имени DNS в сертификате. Если сертификат действителен, клиент использует общедоступный ключ в сертификате для шифрования симметричных ключей шифрования, которые будут использоваться для связи, поэтому только первоначальный владелец сертификата может использовать закрытый ключ для расшифровки содержимого сообщения. В результате подключение доверяется и с этого момента не оспаривается другими доверенными серверами или клиентами. В этом контексте безопасный слой sockets (SSL), используемый с веб-службами, может быть связан как TLS-основе.
Подключение сервера к серверу зависит от MTLS для взаимной проверки подлинности. В подключении MTLS сервер, зародив сообщение, и сервер, получающ его сертификаты обмена из взаимно доверенного ЦС. Сертификаты доказывают удостоверение каждого сервера другому. В Skype для бизнеса Server развертывания сертификаты, выдавлимые корпоративным ЦС в период их действия и не отозванные ЦС, автоматически считаются действительными всеми внутренними клиентами и серверами, так как все члены домена Active Directory доверяют Enterprise ca в этом домене. В федерадных сценариях выдаче ЦС должны доверять оба федерадных партнера. При желании каждый партнер может использовать другой ЦС, если этот ЦС также доверяет другому партнеру. Это доверие наиболее легко достигается с помощью edge Servers, имеющих корневой сертификат ЦС партнера в доверенных корневых ЦС, или с помощью стороненного ЦС, которому доверяют обе стороны.
TLS и MTLS помогают предотвратить как перехват, так и атаки человека в центре. В атаке «человек в центре» злоумышленник перенабивается через компьютер злоумышленника, не зная ни одной из сторон, связь между двумя сетевыми сущностями. TLS и Skype для бизнеса Server доверенных серверов (только те, которые указаны в Topology Builder) частично смягчают риск атаки «человек в середине» на уровне приложения с помощью шифрования, согласованного с использованием криптографии Public Key между двумя конечными точками, и злоумышленник должен иметь действительный и надежный сертификат с соответствующим закрытым ключом и выдан на имя службы. e, с которым клиент общается для расшифровки сообщения. Однако в конечном счете необходимо следовать лучшим практикам безопасности в сетевой инфраструктуре (в данном случае корпоративной DNS). Skype для бизнеса Server предполагает, что DNS-серверу доверяют так же, как доверенным контроллерам домена и глобальным каталогам, но DNS обеспечивает уровень защиты от атак захвата DNS, не допуская успешного ответа сервера злоумышленника на запрос подмененного имени.
Протокол безопасности транспортного уровня (TLS), версия 1.2 (RFC 5246) (Часть 3.1)
T. Dierks, E. Rescorla
Протокол безопасности транспортного уровня (TLS)
Версия 1.2
Запрос на комментарии 5246 (RFC 5246)
Август 2008
Часть 3.1
Предыдущие части перевода: Часть 1, Часть 2.
СОДЕРЖАНИЕ
7. Протоколы процесса рукопожатия TLS
[1] В TLS имеется три подпротокола, используемые для:
согласования двумя соединяющимися узлами параметров безопасности протокола записи;
аутентификации сторонами друг друга;
применения согласованных параметров безопасности;
сообщений друг другу об ошибках.
Протокол рукопожатия (The Handshake Protocol) необходим для согласования параметров сессии, которые состоят из следующих элементов:
session identifier
Идентификатор сессии – произвольная последовательность байт, выбранная сервером для обозначения активного состояния сессии [2], либо состояния ее возобновления (англ. resumable state).
peer certificate
Сертификат узла – сертификат стандарта X509v3 [PKIX] [3]. Данный элемент состояния может быть нулевым.
compression method
Алгоритм используемый для сжатия данных перед началом шифрования.
cipher spec
Параметры (спецификация) шифрования:
псевдослучайная функция (PRF) используемая для генерации ключевого материала;
алгоритм канального шифрования данных (англ. bulk cipher algorithm) (нулевой, AES, и т. д.);
алгоритм создания кода аутентификации сообщения (далее – MAC) (напр., HMAC-SHA1).
master secret
Общий для клиента и сервера секрет размером 48-байт.
is resumable
Флаг, показывающий возможно ли инициировать новое соединение в рамках текущей сессии [5].
Данные параметры используются для создания параметров безопасности, отправляемых уровню записи протокола TLS (см. Разд. 6), который, в свою очередь, использует параметры безопасности для защиты данных приложения. Используя возможность возобновления сессии, предоставляемую протоколом рукопожатия TLS, можно создавать несколько соединений в рамках одной и той же сессии.
7.1. Протокол изменения параметров шифрования (Change Cipher Spec)
Протокол изменения параметров шифрования нужен для сигнализации о смене стратегии шифрования. Протокол состоит из единственного сообщения, которое шифруется и сжимается в рабочем состоянии соединения (но не в состоянии ожидания (англ. pending state)). Все сообщение состоит из одного байта, значение которого равно 1:
7.2. Протокол оповещений
Одним из типов содержимого, поддерживаемый уровнем записи TLS, является тип содержимого alert (оповещение). Сообщения оповещения (далее – alert-сообщения) содержат информацию о степени серьезности события (предупреждение или критическое) (англ. warning or fatal), а также описание оповещения. Alert-сообщения с уровнем значимости «критическое» ведут к немедленному прекращению соединения. В этом случае другие соединения, относящиеся к сессии, могут оставаться активными, но идентификатор сессии должен быть признан недействительным (англ. invalidated) в целях предотвращения создания новых соединений для этой сессии. Как и другие сообщения, alert-сообщения шифруются и сжимаются так, как это определено рабочим состоянием соединения.
7.2.1. Оповещения о закрытии соединения
Во избежание атаки отсечения (англ. truncation attack ) [6] клиент и сервер должны знать о том, что соединение закрывается. Любая из двух сторон может инициировать обмен сообщениями о закрытии. К данному типу сообщений относятся:
close_notify
Сообщение уведомляет реципиента о том, что в этом соединении отправитель не будет больше посылать каких-либо сообщений. Обратите внимание, что начиная с TLS 1.1 невозможность правильно закрыть соединение не влечет за собой требования о запрете на возобновление сессии. Это является изменением по сравнению с TLS 1.0 и было сделано с целью соответствия широко распространенной практике в реализации приложений.
Каждая из сторон может инициировать закрытие соединения путем отправки сообщения « close_notify ». При этом любые данные, полученные после сообщения о закрытии, будут проигнорированы.
Если не было передано каких-либо других критических оповещений, сторона, закрывающая соединение, должна отправить оповещение « close_notify » перед тем, как закроет сторону записи соединения (исходящий трафик). Другая сторона должна ответить своим оповещением « close_notify » и немедленно закрыть соединение, сбросив все ожидающие состояния записи (англ. pending writes). От инициатора закрытия соединения не требуется ожидать ответного сообщения « close_notify » для того, чтобы закрыть сторону чтения (входящий трафик) в соединении.
Если протокол приложения, использующий TLS, обеспечивает то, что после закрытия TLS-соединения, любые данные могут быть перенесены базовым (нижележащим) транспортным сервисом (англ. underlying transport), то в этом случае TLS-реализация должна получить ответное оповещение « close_notify » до того, как она просигнализирует прикладному уровню о том, что TLS-соединение было завершено [7]. Если протокол приложения не будет передавать какие-либо дополнительные данные, и только лишь начнет закрытие соединения с базовым транспортным сервисом (тж. транспортом), то в этом случае реализация может закрыть транспорт не ожидая ответного сообщения « close_notify ». Ни одна из частей данного стандарта не может быть использована для того, чтобы диктовать алгоритм действий при управлении протоколом TLS его транспортами данных, включая момент, когда будет открыто или закрыто соединение.
Примечание: подразумевается, что при закрытии соединения все данные, ожидающие своей обработки (англ. pending data), могут быть надежно пересланы до того как будет уничтожен транспорт.
7.2.2. Сообщения об ошибках
Механизм реагирования на ошибки в протоколе TLS-рукопожатия весьма прост. При обнаружении ошибки, сторона, обнаружившая ошибку, посылает сообщение об этом другой стороне. После приема или передачи сообщения о критической ошибке, обе стороны немедленно закрывают соединение. При этом и сервер и клиент должны удалить из памяти любые идентификаторы сессии, ключи и секреты, связанные с неудачным соединением. Таким образом, любое соединение, завершившееся сообщением о критической ошибке, не должно быть возобновлено.
Как только реализация встречается с условием, которое определено как критическая ошибка, она должна послать соответствующее сообщение перед закрытием соединения. Для всех сообщений, у которых протокол явно не указывает уровень опасности, сторона, пославшая сообщение, может определить по своему усмотрению должна ли ошибка оцениваться как критическая или нет. Если реализация посылает сообщение об ошибке, но при этом намеревается немедленно закрыть соединение, она должна послать сообщение о критическом уровне ошибки.
В общем случае, при приеме и отправке сообщения уровня предупреждения, соединение может нормально продолжать свою работу. Если принимающая сторона решает не продолжать работу соединения (напр., после получения оповещения « no_renegotiation », которое принимающая сторона не желает получать), она должна послать сообщение критического уровня для закрытия соединения. Учитывая это, посылающая сторона не может, в общем случае, знать как поведет себя принимающая сторона. Таким образом, оповещения уровня предупреждения (англ. warning alerts) иногда могут совсем не посылаться в том случае, если посылающая сторона желает продолжить соединение, соответственно – их нельзя воспринимать в качестве чрезвычайно полезных. Например, если узел решает принять сертификат с истекшим сроком действия (возможно, после подтверждения этого пользователем) и желает продолжить соединение, в общем случае при этом не следует посылать сообщение « certificate_expired ».
Определены следующие сообщения об ошибках:
unexpected_message
Непредвиденное сообщение. Посылается при приеме несоответствующего сообщения. Данное сообщение всегда критично и не должно присутствовать при связи двух правильно реализованных приложений.
bad_record_mac
Данное оповещение высылается, если сторона записи получила неправильный MAC. Также, данное сообщение должно посылаться в том случае, если была неверно расшифрована структура « TLSCiphertext » [8]: либо длина самой структуры не является четным кратным длине блока, либо значения набивок (англ. padding values) этой структуры являются некорректными. Данное сообщение всегда критично и не должно присутствовать при связи двух правильно реализованных приложений (за исключением случая искажения сообщения в сети).
decryption_failed_RESERVED
Данное оповещение использовалось в более ранних версиях TLS и могло быть использовано для осуществления атак при работе протокола в режиме шифрования CBC [9]. Совместимые с TLS 1.2 реализации никогда не должны высылать данное сообщение.
decompression_failure
Функция распаковки (англ. decompression function) получила некорректные входные данные (например, размер данных превышают установленный лимит). Данное сообщение всегда критично и не должно присутствовать при связи двух правильно реализованных приложений.
handshake_failure
Получение сообщения « handshake_failure » говорит о том, что отправитель не смог выработать приемлемый набор параметров безопасности с учетом доступных опций. Данная ошибка является критической.
no_certificate_RESERVED
Данное сообщение использовалось в стандарте SSLv3, но ни в одной из версий TLS. Совместимые с TLS 1.2 реализации никогда не должны высылать данное сообщение.
bad_certificate
Сертификат был поврежден, либо содержит подписи, которые не могут быть правильно проверены и т. д.
unsupported_certificate
Сертификат имеет неподдерживаемый тип.
certificate_revoked
Сертификат был отозван подписавшим его лицом.
certificate_expired
Срок действия сертификата истек, либо сам сертификат не является действительным на момент проверки.
certificate_unknown
При обработке сертификата возникли некоторые другие (неуказанные) проблемы, что не позволяет его принять.
illegal_parameter
Значение одного из полей сообщения рукопожатия выходит за установленные пределы, либо несовместимо с другими полями. Данная ошибка всегда является критической.
unknown_ca
Была получена действительная цепочка сертификатов или частичная цепочка, но сертификат не был принят, так как не было найдено местоположение сертификата удостоверяющего центра (УЦ), или же он не был сопоставлен с известным доверенным УЦ. Данная ошибка всегда является критической.
access_denied
Был получен действительный сертификат, но при контроле доступа отправитель не стал продолжать рукопожатие. Данная ошибка всегда является критической.
decode_error
Сообщение не могло быть декодировано, так как значение некоторого поля выходит за установленный диапазон либо длина сообщения является некорректной. Данное сообщение всегда критично и не должно присутствовать при связи двух правильно реализованных приложений (за исключением случая искажения сообщения в сети).
decrypt_error
Криптографическая операция во время рукопожатия неудачно завершена, включая случай невозможности корректно проверить подпись или действительность (тж. валидность) сообщения « Finished » [10]. Данная ошибка всегда является критической.
export_restriction_RESERVED
Данное сообщение использовалось в некоторых более ранних версиях TLS. Совместимые с TLS 1.2 реализации никогда не должны высылать данное сообщение.
protocol_version
Версия протокола, указанная клиентом при попытке рукопожатия распознана, но не поддерживается. (Например, в целях безопасности не должны приниматься старые версии протоколов). Данная ошибка всегда является критической.
insufficient_security
Сообщение высылается вместо сообщения « handshake_failure » в том случае, если выработка секретных параметров (англ. negotiation ) была неудачно завершена по причине того, что сервер запросил более защищенные шифры чем те, которые использует клиент. Данная ошибка всегда является критической.
internal_error
Внутренняя ошибка, не относящаяся к узлу или правильности протокола (такая как сбой распределения памяти (англ. memory allocation failure)), не позволяет продолжить выполнение приложения. Данная ошибка всегда является критической.
user_canceled
Рукопожатие сбрасывается по причине, не относящейся к сбою в протоколе. В том случае, если пользователь отменил операцию после завершенного рукопожатия, более приемлемым вариантом будет закрыть соединение, выслав сообщение « close_notify ». Данная ошибка, в общем случае, будет иметь уровень предупреждения.
no_renegotiation
Сообщение посылается клиентом в ответ на hello-запрос [11] или сервером в ответ на клиентское « hello » (англ. client hello) [12] после начального процесса рукопожатия. При получении двух указанных типов сообщений, обычно, происходит процесс пересогласования параметров (англ. renegotiation); но если пересогласование неприемлемо, реципиент вышеуказанных сообщений должен ответить данным оповещением. В этот момент сторона, отправившая запрос и получившая в ответ данное сообщение, должна решить будет ли она продолжать соединение. Один из случаев, когда соединение может быть продолжено – сервер создал и запустил дочерний процесс (англ. to spawn a process) для выполнения некоторого запроса (англ. to satisfy a request); в этом случае запущенный процесс мог уже получить параметры безопасности (длина ключа, параметры аутентификации и т. п.) на старте соединения и передать изменения в этих параметрах после этого момента было бы довольно сложно. Данное сообщение всегда будет иметь уровень предупреждения.
unsupported_extension
Неподдерживаемое расширение. Сообщение посылается клиентом, который получил расширенное серверное сообщение « hello », содержащее расширение, которое не может быть помещено в клиентское сообщение « hello ». Данная ошибка всегда является критической.
Новые значения кодов оповещений, назначаемые IANA, описываются в Разделе 12 данного стандарта [13].
7.3. Обзор протокола рукопожатия
Криптографические параметры состояния сессии [14] создаются протоколом рукопожатия TLS, который работает поверх уровня записи TLS (англ. TLS record layer) [15]. Когда клиент и сервер начинают впервые коммуницировать через протокол TLS, они согласовывают версию протокола, выбирают криптографические алгоритмы, а также могут дополнительно аутентифицировать друг друга, и задействовать методы шифрования с открытым ключом (англ. public key) для генерации общих секретов.
Протокол рукопожатия TLS включает в себя следующие шаги:
Обмен hello-сообщениями для согласования алгоритмов, обмена случайными значениями, и контроля за тем, возобновляется сессия или параметры соединения согласовываются заново;
Обмен необходимыми криптографическими параметрами для того, чтобы позволить клиенту и серверу выработать предварительный секрет (англ. premaster secret);
Обмен сертификатами и криптографической информацией для того, чтобы клиент и сервер могли аутентифицировать друг друга;
Генерация основного секрета (англ. master seсret) из предварительного секрета и случайных чисел, которыми обменялись клиент и сервер;
Обеспечение уровня записи параметрами безопасности;
Обеспечение возможности того, чтобы клиент и сервер могли проверить, что противоположная сторона рассчитала те же самые секретные параметры и то, что рукопожатие прошло без какого-либо внешнего вмешательства.
Нужно иметь ввиду, что верхние уровни не должны чрезмерно полагаться на то, что TLS всегда будет вырабатывать максимально возможные параметры безопасности при соединении двух узлов. Существует большое количество способов, при которых злоумышленник во время MITM-атаки [16] может попытаться заставить два узла перейти на минимально поддерживаемый ими метод безопасности. Протокол был разработан для минимизации этого риска, но возможность для атаки все еще сохраняется: например, злоумышленник может блокировать доступ к порту, через который служба безопасности отправляет данные или может попытаться заставить узлы соединяться через неаутентифицированный канал связи. Фундаментальное правило при этом – верхние уровни должны знать о своих требованиях безопасности и никогда не передавать информацию через канал, имеющий требования безопасности ниже, чем у них самих. Протокол TLS обеспечивает безопасность в той степени, в какой определенный криптонабор (англ. cipher suite) может обеспечить этот уровень безопасности: если при обмене данными с хостом, чей сертификат безопасности был проверен, при выработке секретных параметров используется блочный шифр 3DES с обменом RSA-ключами размером 1024-бит, ожидается, что верхний уровень должен обеспечивать такой же уровень безопасности.
Заявленные цели достигаются при работе протокола рукопожатия, работа которого может быть кратко представлена как:
Сообщения ClientHello и ServerHello используются для установления усиленных параметров безопасности при соединении между клиентом и сервером.
Сообщения ClientHello и ServerHello устанавливают следующие атрибуты: версия протокола, идентификатор сессии ( Session ID ), используемый криптонабор, метод сжатия.
Действующие правила обмена ключами используют до 4 видов сообщений: серверный сертификат ( server Certificate ), ServerKeyExchange [17], клиентский сертификат ( client Certificate ) и ClientKeyExchange [18]. Новые методы обмена ключами могут быть созданы путем определения формата указанных сообщений и задания правил использования сообщений для согласования клиентом и сервером общего секрета. Этот секрет должен быть достаточно большой длины – текущие методы обмена ключами определяют минимальный размер ключа в 46 байт (368 бит).
Схема 1. Порядок сообщений (поток сообщений) при полном рукопожатии
* Дополнительные или зависящие от ситуации сообщения, которые высылаются не всегда.
Замечание: во избежание потери скорости в канале передачи данных сообщение ChangeCipherSpec является независимым типом содержимого протокола TLS и, строго говоря, не является сообщением TLS-рукопожатия [27] [28].
В тот момент, когда клиент и сервер решают возобновить сессию, в которой некоторое время не было передачи данных, либо продублировать рабочую сессию (вместо того, чтобы вырабатывать новые параметры безопасности), порядок обмена сообщения (англ. message flow) будет следующий:
Клиент отправляет серверу сообщение ClientHello с использованием идентификатора сессии ( Session ID ), которая должна быть возобновлена.
В этом случае сервер проверяет свой сессионный кеш для сопоставления идентифкатора.
Как только сессия была повторно установлена клиент и сервер могут начать обмениваться данными приложения. (См. схему ниже). Если идентификатор сессии не найден в кеше сервера, то сервер генерирует новый код сессии, а TLS-клиент и TLS-сервер осуществляют полное рукопожатие.
Схема 2. Порядок сообщений (поток сообщений) при сокращенном рукопожатии.
Содержимое и значение каждого сообщения будут подробно изложены в следующих разделах стандарта.
7.4. Протокол рукопожатия
Значения для новых типов рукопожатия присваиваются IANA и описываются в разделе 12 [30].
7.4.1. Hello-сообщения
Сообщения hello-стадии используются для обмена усиленными параметрами безопасности между клиентом и сервером. При старте новой сессии шифрование состояния соединения уровня записи, хеш, а также алгоритмы сжатия инициализируются со значением null. Для повторной выработки секретных параметров используется рабочее состояние соединения.
7.4.1.1. Hello-запрос (Hello Request)
Сообщение HelloRequest может быть отправлено сервером в любой момент времени.
Значение сообщения:
Данное сообщение не несет в себе задачи установить какая из сторон является клиентом, а какая – сервером. Оно нужно только лишь для перезапуска процесса рукопожатия.
Данное сообщения не должно включаться в хеш сообщений, создаваемый во время рукопожатия, и используемый в сообщениях Finished и сообщениях проверки сертификатов ( CertificateVerify ).
7.4.1.2. Клиентское hello-сообщение
Данное сообщение посылается:
При первом соединении клиента и сервера требуется посылать сообщение ClientHello в качестве первого сообщения;
также, клиент может послать сообщение ClientHello в ответ на сообщение HelloRequest
или по своей собственной инициативе для повторной выработки (англ. renegotiation) параметров безопасности при существующем соединении.
Структура сообщения:
Сообщение ClientHello включает в себя структуру со случайными значениями ( Random ), которая впоследствии будет использоваться при работе протокола:
gmt_unix_time
Текущее время и дата в стандартном 32-битном UNIX-формате (количество секунд, прошедших с 00:00 (UTC[31]) 1 января 1970 года за вычетом дополнительных секунд (англ. leap seconds [32]) согласно внутреннему времени отправителя сообщения. Для базовой работы протокола TLS не требуется того, чтобы часы были правильно установлены; протоколы высшего уровня, либо протоколы приложений могут вводить дополнительные требования. Имя поля по историческим причинам имеет приставку GMT (среднее время по Гринвичу) – которое было предшественником текущего мирового стандарта UTC.
random_bytes
Значение размером 28 байт, сгенерированное защищенным генератором случайных чисел.
Сообщение ClientHello включает в себя идентификатор сессии ( SessionID ) изменяемой длины. Данное значение идентифицирует (если не является пустым) сессию между одними и теми же клиентом и сервером, чьи параметры безопасности клиент желает повторно использовать. Идентификатор сессии может быть взят из более раннего соединения, текущего соединения, или же из другого активного на данный момент соединения. Второй вариант может быть использован, если клиент желает только обновить структуры со случайными величинами и производные от них значения во время какого-либо соединения. Третий вариант дает возможность установить несколько независимых безопасных соединений без повторения полного протокола рукопожатия. Эти независимые соединения могут происходить либо одновременно, либо последовательно во времени; SessionID становится действительным (англ. valid) в тот момент, когда сгенерировавший его процесс рукопожатия завершается обменом сообщениями Finished и продолжает действовать до тех пор, пока не будет удален в связи с истечением времени сессии, или по причине возникновения критической ошибки во время соединения, принадлежащему данной сессии. Содержимое идентификатора SessionID определяется стороной сервера.
Внимание: так как значение SessionID передается без шифрования и непосредственной защиты кодом аутентификации сообщения (MAC), сторона сервера не должна помещать внутри этого значения конфиденциальную информацию или же допускать бреши в системе безопасности при получении поддельных идентификаторов сессии. (При этом данные рукопожатия целиком, включая и значение SessionID [33], защищены путем обмена сообщениями Finished в конце процесса рукопожатия).
uint8 CipherSuite[2]; /* Селектор криптонабора */
Сообщение ClientHello содержит также список поддерживаемых клиентом алгоритмов сжатия, расположенных в порядке клиентских предпочтений.
Таким образом, вся структура сообщения ClientHello выглядит следующим образом:
client_version
Версия протокола TLS, которую клиент желает использовать при соединении во время сессии. Рекомендуется, чтобы это была последняя (с наибольшим значением) версия, поддерживаемая клиентом. Для TLS версии 1.2 данное значение будет равно 3.3 [35] (см. Прил. E для подробной информации об обратной совместимости).
random
Сгенерированная клиентом структура со случайными величинами.
session_id
Идентификатор сессии, который клиент желает использовать для данного соединения. Данное поле остается пустым в случае, если значение session_id недоступно, или же клиент желает создать новые параметры безопасности.
7.4.1.3. Серверное hello-сообщение
Данное сообщение отправляется сервером в ответ на сообщение ClientHello только в том случае, если он способен найти приемлемый набор алгоритмов. Если ему не удается найти подобный набор, сервер отвечает сообщением о критической ошибке рукопожатия.
server_version
В общем случае данное поле содержит значение меньшее либо равное версии, указанной клиентом в его hello-сообщении, но в любом случае не больше самой высокой поддерживаемой сервером версии протокола. Для версии TLS 1.2 значение поля будет равно 3.3 (см. Прил. E для подробной информации об обратной совместимости).
extensions
Список расширений. Обратите внимание, что в списке сервера не содержится никаких других расширений, кроме тех, которые были указаны в списке клиента.
7.4.1.4. Расширения hello-сообщений
Формат расширения следующий:
» extension_type » указывает на определенный тип расширения;
» extension_data » содержит информацию, касающуюся определенного типа расширения.
Начальный набор расширений определен в отдельном документе [TLSEXT] [36]. Список поддерживаемых типов расширений регулируется IANA по принципам, указанным в разделе 12 [37].
Тем не менее, в рамках развития протокола в будущем могут быть созданы «серверно-ориентированные» расширения. Такое расширение (предположим, типа x) будет требовать, чтобы сначала клиент отправил расширение типа x с пустым полем extension_data в своем сообщении ClientHello для того, чтобы показать, что он поддерживает расширение данного типа. В этом случае клиент сообщает о способности понимать конкретный тип расширения, а сервер принимает подобное предложение.
Если в сообщениях ClientHello или ServerHello присутствует более одного типа расширений, они могут следовать в произвольном порядке. В сообщении не должно присутствовать два или более расширения одного типа.
Обратите внимание, что список расширений может быть послан либо при создании новой сессии, либо при запросе на возобновление уже созданной. Более того, клиент, запрашивая возобновление сессии, в общем случае не знает примет ли сервер его запрос, таким образом, рекомендуется, чтобы он высылал в своем сообщении указанные им ранее расширения как если бы, он делал запрос на создание новой сессии.
При работе данного протокола могут возникнуть довольно узкие (и не особо) места при взаимодействии между расширениями с новой функциональностью и уже существующими расширениями, что может вылиться в существенное снижение общей безопасности. При разработке новых расширений следует учитывать некоторые моменты:
Некоторые случаи, при которых сервер не согласен использовать то или иное расширение, являются условиями для возникновения ошибки. Но в некоторых случаях сервер выдает отказ в поддержке конкретного расширения. В общем случае, в первом варианте рекомендуется выдавать сообщение об ошибке, а во втором – отправлять ответ сервера с поддерживаемыми расширениями.
Расширения, насколько это возможно, должны быть построены таким образом, чтобы предотвратить любую атаку, которая вынуждает использовать (либо не использовать) особенности (англ. feature ) его работы при манипуляции сообщениями рукопожатия. Данный принцип должен соблюдаться несмотря на то, имеются или нет опасения того, что указанная особенность способствует возникновению проблем в безопасности.
Вполне вероятно, что появится техническая возможность заменять при помощи расширений главные аспекты работы протокола TLS; например, принцип согласования используемого криптонабора. Делать это не рекомендуется; наиболее приемлемым вариантом будет создание новой версии TLS – в особенности из-за того, что алгоритмы рукопожатия TLS имеют специфическую защиту против атак отката версии (англ. version rollback attacks ), которая основывается на понижении версии протокола. Возможность отката версии должна стать одним из главных соображений при создании каких-либо значительных изменений в конструкцию протокола.
7.4.1.4.1. Расширение «алгоритмы подписи»
Расширение » signature_algorithms » используется клиентом для указания серверу какие пары алгоритмов подписи/хеш-функции могут быть задействованы для цифровой подписи. Поле » extension_data » данного расширения содержит значение » supported_signature_algorithms «:
Каждое значение SignatureAndHashAlgorithm содержит единственную пару хеш/подпись, которую клиент желает подтвердить. Значения расположены в порядке снижения приоритета пар.
Обратите внимание: из-за того, что не все алгоритмы подписи и алгоритмы хэширования могут быть приняты реализациями протокола (напр., возможно использование DSA с SHA-1, но не с SHA-256) все алгоритмы в данном разделе приводятся в парах.
hash
Данное поле указывает на возможный к использованию алгоритм хеширования. Значения указывают на отсутствие функции хеширования, алгоритмы MD5 [MD5] [39], SHA-1,SHA-224, SHA-256, SHA-384, и SHA-512 соответственно[SHS] [40]. Значение » none » добавлено для будущей расширяемости в случае работы с алгоритмом подписи, не требующим хеширования перед подписанием данных.
signature
Данное поле указывает на возможные алгоритмы подписи. Значения указывают на анонимную подпись, алгоритмы RSASSA-PKCS1-v1_5 [PKCS1][41], DSA [DSS] [42] [ECDSA][43], соответственно. Значение » anonymous » (анонимная) в данном контексте не несет никакой смысловой нагрузки, но используется в разделе 7.4.3 (серверное сообщение об обмене ключами). Оно не должно присутствовать в данном расширении.
Семантика данного расширения в некоторой степени сложна, поскольку криптонаборы указывают на допустимый алгоритм подписи, но не на алгоритмы хеширования. В разделах 7.4.2 и 7.4.3 определены соответствующие правила для криптонаборов.
Если согласованный алгоритм обмена ключами является одним из следующих – DHE_DSS , DH_DSS – сервер должен вести себя так как если бы клиент отправил значение < sha1, dsa >.
Если согласованный алгоритм обмена ключами является одним из следующих – ECDH_ECDSA , ECDHE_ECDSA – сервер должен вести себя так как если бы клиент отправил значение < sha1, ecdsa >.
Обратите внимание: данное правило является изменением по сравнению с протоколом TLS 1.1, в котором нет четких указаний, касающихся подобных ситуаций, но в качестве практической меры следует сделать допущение, что каждый из узлов поддерживает протоколы MD5 и SHA-1.
Сервер не должен отправлять сообщение с данным расширением. TLS-сервер должен иметь возможность получить сообщение с данным расширением.
[1] Не следует смешивать термины «процесс рукопожатия» (англ. handshaking) и «рукопожатие» (англ. handshake). Процесс рукопожатия является более широким термином, который включает в себя три подпротокола: протокол рукопожатия (тж. согласования параметров) (англ. handshake protocol), оповещений (alert protocol), изменения параметров шифрования (англ. change cipher spec protocol). Таким образом, термин «процесс рукопожатия» включает в себя термин «рукопожатие» (Прим. перев.).
[2] Приложение B данного стандарта определяет TLS-сессию как: связь (англ. association) между клиентом и сервером, которая создается протоколом рукопожатия. Сессии определяют набор криптографических параметров безопасности, которые могут не меняться в течение многих соединений (англ. connection). Основная цель создания сессии: избежать лишних согласований новых параметров безопасности при каждом соединении (Прим. перев.).
[4] Как видно, эти три параметра входят в число параметров безопасности, описанных в Разд. 6.1 и в Прил. A.6 данного Cтандарта. Криптографические атрибуты входят в состав структуры SecurityParameters (тж. см. Разд. 6.1 и Прил. A.6) (Прим. перев.).
[5] По-другому – возобновляемая сессия или нет. То есть, существует ли возможность начать новое соединение в рамках текущей сессии с уже согласованными параметрами безопасности или же при новом соединении необходимо будет создавать и новую сессию с согласованием новых параметров безопасности (Прим. перев.).
[6] При атаке отсечения злоумышленник внедряет в сообщение TCP-код, сигнализирующий об окончании сообщения, не позволяя, таким образом, принять остаток сообщения. Для предотвращения этого начиная с SSL 3.0 было введено закрывающее рукопожатие для того, чтобы реципиент точно знал, в какой момент будет заканчиваться сообщение. См. тж. здесь (Прим. перев.).
[7] Стандарт TLS разрабатывается организацией IETF (Internet Engineering Task Force), которая придерживается сетевой модели со стеком протоколов TCP/IP, в которой после транспортного уровня идет сразу прикладной уровень (уровень приложения). В сетевой модели OSI (Open Systems Interconnection) между транспортным и прикладным уровнем существуют еще два уровня – сеансовый уровень и уровень представления (Прим. перев.).
[8] См. подробнее п. 6.2.3. данного стандарта.
[9] Moeller, B., «Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures«, http://www.openssl.org/
bodo/tls-cbc.txt. О режиме CBC-шифрования см. тж. п. 6.2.3.2 данного стандарта.
[10] Сообщение « Finished » является финальным сообщением, посылаемым сервером клиенту во время выполнения протокола рукопожатия TLS. Данное сообщение говорит о том, что обмен ключами и операция аутентификация были выполнены успешно. (см. тж. п. 7.4.9 данного стандарта) (Прим. перев.).
[11] Hello-запрос (англ. hello request) является уведомлением о том, что клиент должен начать заново процесс выработки секретных параметров (англ. negotiation). (см. тж. п. 7.4.1.1 данного стандарта) (Прим. перев.).
[12] Клиентские «hello» рассматриваются в п. 7.4.1.2 данного стандарта.
[13] Коды сообщений об ошибках добавляются в регистр «TLS Alerts» (Оповещения TLS) раздела регистров «Transport Layer Security (TLS) Parameters», доступный по адресу: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6 (Прим. перев.).
[14] См. Раздел 6.1. данного стандарта.
[15] См. Раздел 6.2. данного стандарта.
[17] См. пункт 7.4.3. данного стандарта.
[18] См. пункт 7.4.7. данного стандарта.
[20] См. пункт 7.4.2. данного стандарта.
[21] См. пункт 7.4.5. данного стандарта.
[22] См. пункт 7.4.4. данного стандарта.
[23] См. пункт 7.4.6. данного стандарта.
[25] См. пункт 7.4.8. данного стандарта.
[26] См. пункт 7.4.9. данного стандарта.
[27] Описание протокола изменения параметров шифрования (Change Cipher Spec) содержится в Разд. 7.1. данного стандарта.
[28] В разделе Errata (Ошибки) (https://www.rfc-editor.org/errata/eid4007) данного стандарта содержится предложение о перефразировке данного абзаца:
Для того, чтобы сообщение ChangeCipherSpec не передавалось вместе с другими фрагментами рукопожатия в одной записи, ChangeCipherSpec является независимым типом содержимого протокола TLS и, по сути, не является сообщением TLS-рукопожатия. Во избежание потери скорости в канале передачи данных сообщение ChangeCipherSpec отправляется как от клиента, так и от сервера.
Обоснование: оригинальный текст можно трактовать так, будто мы можем отправлять ChangeCipherSpec асинхронно. Это небезопасно, так как может стать причиной уязвимости CCS Injection (ChangeCipherSpec Ingection).
Об уязвимости CCS Injection см. здесь, здесь и здесь. (Прим. перев.).
[29] Описание протокола записи TLS (TLS record protocol) содержится в Разд. 6. данного стандарта.
[30] Кодовые значения для существующих типов рукопожатия добавляются в регистр «TLS HandshakeType» (Типы рукопожатия TLS) раздела регистров «Transport Layer Security (TLS) Parameters», доступный по адресу: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-7 (Прим. перев.).
[31] UTC – всемирное координированное время, (англ. Coordinated Universal Time, фр. Temps Universel Coordonné). Всемирный стандарт времени. Для повсеместного использования, когда не требуется высокая точность, может использоваться как аналог среднего времени по Гринвичу (GMT) или всемирного времени UT1 (Прим. перев.).
[32] Дополнительные секунды (тж. високосные секунды, англ. leap seconds) – дополнительные секунды, прибавляемые к UTC для координации его со всемирным временем UT1. Начиная с 1972 года к UTC было добавлено 27 дополнительных секунд. В связи с ускорением вращения Земли в будущем возможно не прибавление, а вычитание секунд из UTC (Прим. перев.).
Обоснование: при пропуске TLS-трафика через программу-анализатор WireShark в сетевых пакетах всегда присутствует поле «Session ID Length» с записанным в него значением либо 0, либо 32. (Прим. перев.).
[34] В данном стандарте описано только одно расширение – алгоритмы подписи (signature_algorithms, см. пп. 7.4.1.4. и 7.4.1.4.1 Стандарта). Основной документ, определяющий расширения TLS версии 1.2 – стандарт RFC6066 «Transport Layer Security (TLS) Extensions: Extension Definitions». Также, все поддерживаемые протоколом TLS расширения указаны в разделе «TLS ExtensionType Values» раздела регистров IANA «Transport Layer Security (TLS) Extensions» (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1) (Прим. перев.).
[35] Поскольку протокол TLS 1.0 выпущен на основе протокола SSL 3.0, то в целях исторической преемственности версия TLS 1.0 кодируется значением <3, 1>. Соответственно, версия протокола TLS 1.2 кодируется значением <3, 3>(Прим. перев.).
[38] На момент опубликования стандарта в августе 2008 года (Прим. перев.).
[39] Rivest, R., «The MD5 Message-Digest Algorithm«, RFC 1321, Апрель 1992. Стандарт обновлен стандартом: S. Turner, L. Chen, «Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms«, RFC 6151, Март 2011.
[40] NIST FIPS PUB 180-2, «Secure Hash Standard«, National Institute of Standards and Technology, U.S. Department of Commerce, August 2002. На данный момент стандарт устарел и актуален следующий стандарт: NIST FIPS PUB 180-4, «Secure Hash Standard (SHS)», National Institute of Standards and Technology, U.S. Department of Commerce, August 2015 (Прим. перев.).
[41] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1«, RFC 3447, February 2003.
[43] American National Standards Institute, «Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)«( Алгоритм цифровой подписи на основе эллиптических кривых), ANSI X9.62-2005, November 2005.
[44] То есть использовать алгоритм хеширования SHA-1 и алгоритм цифровой подписи – DSA. И т. д. (Прим. перев.).
[45] В рамках протокола TLS термины «клиент» и «сервер» не несут смысловой нагрузки по аналогии с этими же терминами в рамках реализации приложений клиент-серверной архитектуры. В Приложении B Стандарта клиент определен как: приложение, инициировавшее TLS-соединение. При этом особо подчеркивается, что клиент не обязательно должен инициировать соединение и на нижележащем уровне. Основное операционное отличие клиента TLS от сервера TLS в том, что сервер, в общем случае, должен быть обязательно аутентифицирован (выслать свой сертификат клиенту), в то время как для клиента нет такого обязательства (хотя он и может быть аутентифицирован, если этого требуют настройки сервера) (Прим. перев.).