Error code tls alert record received

Протокол безопасности транспортного уровня (TLS), версия 1.2 (RFC 5246) (Часть 3.1)

T. Dierks, E. Rescorla

Протокол безопасности транспортного уровня (TLS)

Версия 1.2

Запрос на комментарии 5246 (RFC 5246)

Август 2008

Часть 3.1

В статье приводится продолжение перевода на русский язык стандарта IETF — RFC 5246, описывающего работу протокола безопасности транспортного уровня TLS версии 1.2. Данная часть перевода охватывает первую половину описания работы рукопожатия TLS 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).

Также, этот параметр определяет криптографические атрибуты, такие как mac_length . (Формальное определение находится в Прил. А.6). [4]

master secret
Общий для клиента и сервера секрет размером 48-байт.

is resumable
Флаг, показывающий возможно ли инициировать новое соединение в рамках текущей сессии [5].

Данные параметры используются для создания параметров безопасности, отправляемых уровню записи протокола TLS (см. Разд. 6), который, в свою очередь, использует параметры безопасности для защиты данных приложения. Используя возможность возобновления сессии, предоставляемую протоколом рукопожатия TLS, можно создавать несколько соединений в рамках одной и той же сессии.

7.1. Протокол изменения параметров шифрования (Change Cipher Spec)

Протокол изменения параметров шифрования нужен для сигнализации о смене стратегии шифрования. Протокол состоит из единственного сообщения, которое шифруется и сжимается в рабочем состоянии соединения (но не в состоянии ожидания (англ. pending state)). Все сообщение состоит из одного байта, значение которого равно 1:

Сообщение ChangeCipherSpec посылается как клиентом, так и сервером [45] для сообщения реципиенту о том, что последующие записи будут защищаться заново согласованными параметрами шифрования и ключами. При приеме данного сообщения его реципиент дает инструкцию уровню (слою) записи немедленно скопировать состояние ожидания чтения (англ. read pending state) в рабочее состояние чтения (англ. read current state). Непосредственно после отправки данного сообщения, его отправитель должен дать инструкцию уровню записи сделать состояние ожидания записи (англ. write pending state) рабочим состоянием записи (англ. write current state). (См. Разд. 6. 1.). Сообщение ChangeCipherSpec посылается во время рукопожатия после того, как были согласованы параметры безопасности, но до того как было послано подтвержденное сообщение Finished .

Примечание: если повторное рукопожатие происходит во время передачи данных, стороны, устанавливающие связь, могут продолжить пересылать данные, используя старые параметры шифрования ( CipherSpec ). Однако, если было послано сообщение ChangeCipherSpec , новые значения CipherSpec должны быть созданы в любом случае. Сторона, посылающая сообщение ChangeCipherSpec не знает того, закончила ли другая сторона расчет ключевого материала (например, если для этого ей следует выполнить требующие определенного времени операции с открытым ключом). Таким образом, при этом может существовать небольшое временное окно, во время которого реципиент сообщения должен положить данные в буфер. На практике, при использовании современных машин такой интервал будет, вероятнее всего, весьма коротким.

7.2. Протокол оповещений

Одним из типов содержимого, поддерживаемый уровнем записи TLS, является тип содержимого alert (оповещение). Сообщения оповещения (далее – alert-сообщения) содержат информацию о степени серьезности события (предупреждение или критическое) (англ. warning or fatal), а также описание оповещения. Alert-сообщения с уровнем значимости «критическое» ведут к немедленному прекращению соединения. В этом случае другие соединения, относящиеся к сессии, могут оставаться активными, но идентификатор сессии должен быть признан недействительным (англ. invalidated) в целях предотвращения создания новых соединений для этой сессии. Как и другие сообщения, alert-сообщения шифруются и сжимаются так, как это определено рабочим состоянием соединения.

Ниже даются два перечисления протокола оповещений — AlertLevel и AlertDescription . Первое из них содержит уровни опасности оповещений, второе — список самих оповещений. Структура 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 реализации никогда не должны высылать данное сообщение.

record_overflow
Была получена запись типа TLSCiphertext , имеющая длину более 2^14+2048 байт, или же запись была расшифрована в запись типа TLSCompressed , имеющую длину более 2^14+1024 байт. Данное сообщение всегда критично и не должно присутствовать при связи двух правильно реализованных приложений (за исключением случая искажения сообщения в сети).

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 используются для установления усиленных параметров безопасности при соединении между клиентом и сервером.

Сообщения ClientHello и ServerHello устанавливают следующие атрибуты: версия протокола, идентификатор сессии ( Session ID ), используемый криптонабор, метод сжатия.

Дополнительно генерируются и обмениваются два случайных значения: ClientHello.random и ServerHello.random .

Действующие правила обмена ключами используют до 4 видов сообщений: серверный сертификат ( server Certificate ), ServerKeyExchange [17], клиентский сертификат ( client Certificate ) и ClientKeyExchange [18]. Новые методы обмена ключами могут быть созданы путем определения формата указанных сообщений и задания правил использования сообщений для согласования клиентом и сервером общего секрета. Этот секрет должен быть достаточно большой длины – текущие методы обмена ключами определяют минимальный размер ключа в 46 байт (368 бит).

В том случае, если сервер должен быть аутентифицирован, после своего hello-сообщения ( ServerHello ) [19] сервер высылает свой сертификат в сообщении Certificate [20]. Дополнительно, если требуется (например, если у сервера нет сертификата или у него есть сертификат только для подписи), сервером может быть выслано сообщение ServerKeyExchange . Если сервер аутентифицирован, он может потребовать от клиента выслать его сертификат, если это приемлемо для выбранного криптонабора. После этого сервер высылает сообщение ServerHelloDone [21], показывая, что hello-стадия (англ. hello-message phase) рукопожатия завершена. В этот момент сервер будет ждать ответа от клиента. Если сервер выслал сообщение CertificateRequest [22], то клиент обязан отправить сообщение Certificate [23]. После этого клиентом высылается сообщение ClientKeyExchange , содержимое которого будет зависеть от алгоритмов создания открытого ключа, выбранных в сообщениях ClientHello [24] и ServerHello . Если клиент отправил сертификат с возможностью подписи, то им же высылается подписанное цифровой подписью сообщение CertificateVerify [25] для того, чтобы явным образом удостоверить владение закрытым ключом сертификата.

В этот момент клиентом отправляется сообщение ChangeCipherSpec и клиент копирует ожидающую спецификацию параметров шифрования в рабочую спецификацию параметров шифрования. После чего клиент немедленно отправляет сообщение Finished [26] уже с использованием новых алгоритмов, ключей и секретов. В ответ сервер высылает свое собственное сообщение ChangeCipherSpec , перемещает ожидающую спецификацию параметров шифрования (Cipher Spec) в рабочую спецификацию параметров шифрования, и посылает свое сообщение Finished уже с использованием новых параметров шифрования. В этот момент рукопожатие завершается и клиент с сервером могут начать обмениваться данными уровня приложения (см. схему ниже). Данные приложения (англ. application data) не должны высылаться до завершения первого рукопожатия (до того как будет установлен криптонабор отличный от TLS_NULL_WITH_NULL_NULL ).

Клиент Сервер
ClientHello ———>
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*

[ChangeCipherSpec]
Данные приложения

Схема 1. Порядок сообщений (поток сообщений) при полном рукопожатии

* Дополнительные или зависящие от ситуации сообщения, которые высылаются не всегда.

Замечание: во избежание потери скорости в канале передачи данных сообщение ChangeCipherSpec является независимым типом содержимого протокола TLS и, строго говоря, не является сообщением TLS-рукопожатия [27] [28].

В тот момент, когда клиент и сервер решают возобновить сессию, в которой некоторое время не было передачи данных, либо продублировать рабочую сессию (вместо того, чтобы вырабатывать новые параметры безопасности), порядок обмена сообщения (англ. message flow) будет следующий:

Клиент отправляет серверу сообщение ClientHello с использованием идентификатора сессии ( Session ID ), которая должна быть возобновлена.

В этом случае сервер проверяет свой сессионный кеш для сопоставления идентифкатора.

Если сопоставление прошло успешно и сервер желает заново установить сессию с заданным состоянием сессии, то сервер отправляет сообщение ServerHello с тем же самым значением Session ID .

В этот момент и клиент и сервер должны послать сообщения ChangeCipherSpec и продолжить обмен сообщениями до сообщений Finished .

Как только сессия была повторно установлена клиент и сервер могут начать обмениваться данными приложения. (См. схему ниже). Если идентификатор сессии не найден в кеше сервера, то сервер генерирует новый код сессии, а TLS-клиент и TLS-сервер осуществляют полное рукопожатие.

Клиент Сервер
ClientHello ———>
ServerHello
[ChangeCipherSpec]

Finished ———>
Данные приложения Данные приложения

Схема 2. Порядок сообщений (поток сообщений) при сокращенном рукопожатии.

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

7.4. Протокол рукопожатия

Протокол рукопожатия TLS является одним из определенных данным стандартом высокоуровневых клиентов протокола записи TLS (TLS Record Protocol [29]). Протокол используется для выработки секретных параметров сессии. Сообщения рукопожатия предоставляются протоколу записи TLS, где они инкапсулируются внутри одной или нескольких структур TLSPlaintext , которые затем обрабатываются и пересылаются так, как это было указано текущим рабочим состоянием сессии.

Ниже приводится формат структуры Handshake , а также перечисление, задающее поле типа HandshakeType (тип рукопожатия):

Сообщения протокола рукопожатия представлены ниже в том порядке, в котором они должны посылаться; отправка сообщений рукопожатия в неправильном порядке приводит к критической ошибке. Однако, ненужные сообщения рукопожатия могут быть пропущены. Существует одно исключение из этого правила: сообщение Certificate отправляется в рукопожатии дважды, (от сервера к клиенту, а затем – от клиента к серверу), но описывается только для первого случая. Единственное сообщение, которое никак не привязано к этому порядку – сообщение HelloRequest , которое может быть выслано в любой момент, но клиенту рекомендуется игнорировать его в том случае, если оно приходит в процессе уже начатого рукопожатия.

Значения для новых типов рукопожатия присваиваются IANA и описываются в разделе 12 [30].

7.4.1. Hello-сообщения

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

7.4.1.1. Hello-запрос (Hello Request)

Сообщение HelloRequest может быть отправлено сервером в любой момент времени.

Значение сообщения:

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

Данное сообщение не несет в себе задачи установить какая из сторон является клиентом, а какая – сервером. Оно нужно только лишь для перезапуска процесса рукопожатия.

Серверу не рекомендуется высылать сообщение HelloRequest сразу же после начального соединения с клиентом, поскольку в этот момент именно клиент обязан выслать сообщение ClientHello .

Данное сообщение будет проигнорировано клиентом, если он уже находится в процессе согласования параметров сессии. Если клиент не желает заново согласовывать параметры сессии, он может проигнорировать данное сообщение, или же ответить оповещением no_renegotiation . Поскольку протоколом оговаривается, что сообщения рукопожатия предшествуют передаче данных приложения, ожидается, что новое рукопожатие начнется не раньше, чем от клиента будет получено какое-либо количество записей. Если сервер отправляет сообщение HelloRequest , но не получает в ответ сообщение ClientHello , он может закрыть соединение с сообщением о критической ошибке.

После отправки сообщения 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 в конце процесса рукопожатия).

Список криптонаборов, передаваемых от клиента серверу в сообщении ClientHello , содержат комбинации криптографических алгоритмов, поддерживаемых клиентом исходя из его предпочтений (наиболее предпочтительный криптонабор идет первым). Каждый криптонабор определяет алгоритм обмена ключами, алгоритм канального шифрования данных (включая длину секретного ключа), алгоритм создания MAC и псевдослучайную функцию (англ. PRF). Сервер выбирает какой-либо криптонабор или же, если доступного для него криптонабора не имеется, возвращает сообщение о невозможности провести рукопожатие ( handshake_failure ) и закрывает соединение. Если список содержит криптонаборы, которые сервер не распознает, не поддерживает, или не желает использовать, сервер игнорирует данные криптонаборы и работает только с оставшимися криптонаборами.

uint8 CipherSuite[2]; /* Селектор криптонабора */

Сообщение ClientHello содержит также список поддерживаемых клиентом алгоритмов сжатия, расположенных в порядке клиентских предпочтений.

Таким образом, вся структура сообщения ClientHello выглядит следующим образом:

TLS позволяет, чтобы за полем compression_methods (методы сжатия) следовал блок расширений. Наличие расширений может быть обнаружено при наличии дополнительных байт данных идущих после поля compression_methods в сообщении ClientHello . Обратите внимание, что подобный способ обнаружения дополнительных данных отличается от нормального способа, используемого в протоколе TLS для обнаружения поля переменной длины, но он используется для совместимости с теми реализациями TLS, когда расширения еще не были определены [34].

client_version
Версия протокола TLS, которую клиент желает использовать при соединении во время сессии. Рекомендуется, чтобы это была последняя (с наибольшим значением) версия, поддерживаемая клиентом. Для TLS версии 1.2 данное значение будет равно 3.3 [35] (см. Прил. E для подробной информации об обратной совместимости).

random
Сгенерированная клиентом структура со случайными величинами.

session_id
Идентификатор сессии, который клиент желает использовать для данного соединения. Данное поле остается пустым в случае, если значение session_id недоступно, или же клиент желает создать новые параметры безопасности.

cipher_suites
Список криптографических опций, поддерживаемых клиентом, в котором первым пунктом идет предпочтительный для клиента криптонабор. Если поле session_id не является пустым (что подразумевает запрос на возобновление сессии), то данный вектор должен содержать, как минимум, список cipher_suite , уже существующий в возобновляемой сессии. Значения данного поля определены в Прил. А.5.

compression_methods
Список поддерживаемых клиентом методов сжатия, расположенных в порядке предпочтения клиента. Если поле session_id не является пустым (что подразумевает запрос на возобновление сессии), то данное поле должно включать список compression_method возобновляемой сессии. Данный вектор должен содержать, и все реализации должны поддерживать значение CompressionMethod.null . Таким образом, клиент и сервер всегда могут установить общий для них обоих метод сжатия.

extensions
Клиент может сделать запрос серверу на включение расширенной функциональности (расширений) в работу сессии, путем отправки данных в поле extensions . Действующий формат расширений TLS описан в п.7.4.1.4.

В том случае, если клиент запрашивает о включении дополнительной функциональности, задействуя то или иное расширение, и данная функциональность не поддерживается сервером, клиент может окончить обмен сообщениями с сервером. Сервер должен принимать сообщения ClientHello как с полем, так и без поля extensions , и (как и для всех других сообщений) должен проверять, что общее количество данных в сообщении соответствует его формату; если этого не происходит сервер должен выслать сообщение о критической ошибке decode_error .

После отправки сообщения ClientHello клиент ждет ответного сообщения ServerHello . Любые другие сообщения рукопожатия, возвращаемые сервером, за исключением сообщения HelloRequest, рассматриваются сервером в качестве критической ошибки.

7.4.1.3. Серверное hello-сообщение

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

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

server_version
В общем случае данное поле содержит значение меньшее либо равное версии, указанной клиентом в его hello-сообщении, но в любом случае не больше самой высокой поддерживаемой сервером версии протокола. Для версии TLS 1.2 значение поля будет равно 3.3 (см. Прил. E для подробной информации об обратной совместимости).

random
Данная структура со случайными величинами должна генерироваться сервером независимо от структуры ClientHello.random .

session_id
Идентификатор сессии, соответствующей текущему соединению. Если значение ClientHello.session_id не является пустым, сервер обязан просмотреть свой сессионный кеш для поиска соответствия. Если соответствие найдено и сервер желает установить новое соединение с определенным состоянием сессии, сервер отвечает тем же сам значением, которое было передано клиентом. Это является признаком того, что сессия возобновлена и стороны должны перейти к обмену сообщениями Finished . В противном случае значение поля будет отличаться от значения поля, полученного от клиента, что будет сигнализировать о начале новой сессии. Сервер может ответить пустым значением поля session_id , что означает то, что сессия не будет кешироваться и, таким образом, не сможет быть восстановлена. При возобновлении сессии она должна работать с тем же криптонабором, который был согласован с клиентом при самом первом рукопожатии сессии. Обратите внимание, что для сервера не существует обязательного требования возобновлять сессию, если ему было предоставлено значение session_id . Клиент должен быть готов к полному согласованию параметров во время любого рукопожатия, включая и согласование новых криптонаборов.

cipher_suite
Единственный криптонабор, выбранный сервером из списка, задаваемого полем ClientHello.cipher_suites . При возобновлении сессии данное значение берется из состояния возобновляемой сессии.

compression_method
Единственный алгоритм сжатия, выбранный сервером из списка, задаваемого полем ClientHello.compression_methods . При возобновлении сессии данное значение берется из состояния возобновляемой сессии.

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

7.4.1.4. Расширения hello-сообщений

Формат расширения следующий:

» extension_type » указывает на определенный тип расширения;

» extension_data » содержит информацию, касающуюся определенного типа расширения.

Начальный набор расширений определен в отдельном документе [TLSEXT] [36]. Список поддерживаемых типов расширений регулируется IANA по принципам, указанным в разделе 12 [37].

В сообщении ServerHello не должен появляться тип расширения, не указанный в соответствующем сообщении ClientHello . Если в полученном клиенте сообщении ServerHello указывается тип расширения, на использование которого клиент не подавал запроса в соответствующем сообщении ClientHello , то клиент должен прервать рукопожатие с сообщением о критической ошибке unsupported_extension .

Тем не менее, в рамках развития протокола в будущем могут быть созданы «серверно-ориентированные» расширения. Такое расширение (предположим, типа x) будет требовать, чтобы сначала клиент отправил расширение типа x с пустым полем extension_data в своем сообщении ClientHello для того, чтобы показать, что он поддерживает расширение данного типа. В этом случае клиент сообщает о способности понимать конкретный тип расширения, а сервер принимает подобное предложение.

Если в сообщениях ClientHello или ServerHello присутствует более одного типа расширений, они могут следовать в произвольном порядке. В сообщении не должно присутствовать два или более расширения одного типа.

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

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

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

Расширения, насколько это возможно, должны быть построены таким образом, чтобы предотвратить любую атаку, которая вынуждает использовать (либо не использовать) особенности (англ. feature ) его работы при манипуляции сообщениями рукопожатия. Данный принцип должен соблюдаться несмотря на то, имеются или нет опасения того, что указанная особенность способствует возникновению проблем в безопасности.

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

Вполне вероятно, что появится техническая возможность заменять при помощи расширений главные аспекты работы протокола 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 определены соответствующие правила для криптонаборов.

Если клиент поддерживает только установленные по умолчанию алгоритмы подписи и хеширования (приведенные в этом пункте), он может опустить расширение signature_algorithms . Если клиент не поддерживает установленные по умолчанию алгоритмы, либо поддерживает другие алгоритмы подписи и хеширования (и желает использовать их для проверки отправленных сервером сообщений, например серверных сообщений Certificate и ServerKeyExchange ), он должен выслать в своем hello-сообщении также и расширение signature_algorithms с перечислением алгоритмов, которые он желает использовать.

В том случае, если клиент не высылает в своем hello-сообщении расширение signature_algorithms , сервер обязан предпринять следующие шаги:

Если согласованный алгоритм обмена ключами является одним из следующих – RSA , DHE_RSA , DH_RSA , RSA_PSK , ECDH_RSA , ECDHE_RSA – сервер должен вести себя так как если бы клиент отправил значение < sha1, rsa >[44].

Если согласованный алгоритм обмена ключами является одним из следующих – DHE_DSS , DH_DSS – сервер должен вести себя так как если бы клиент отправил значение < sha1, dsa >.

Если согласованный алгоритм обмена ключами является одним из следующих – ECDH_ECDSA , ECDHE_ECDSA – сервер должен вести себя так как если бы клиент отправил значение < sha1, ecdsa >.

Обратите внимание: данное правило является изменением по сравнению с протоколом TLS 1.1, в котором нет четких указаний, касающихся подобных ситуаций, но в качестве практической меры следует сделать допущение, что каждый из узлов поддерживает протоколы MD5 и SHA-1.

Обратите внимание: данное расширение не распространяется на версии TLS, предшествующие версии 1.2. Клиент не должен включать его в свое сообщение ClientHello , если он собирается работать с предыдущими версиями TLS. Однако, даже если клиент и включит его в свое сообщение, правила, определенные в [TLSEXT], обязывают сервер игнорировать неподдерживаемые ими расширения.

Сервер не должен отправлять сообщение с данным расширением. TLS-сервер должен иметь возможность получить сообщение с данным расширением.

При возобновлении сессии данное расширение не включается в сообщение ServerHello , а при наличии данного расширения в сообщении ClientHello сервер его игнорирует.

[1] Не следует смешивать термины «процесс рукопожатия» (англ. handshaking) и «рукопожатие» (англ. handshake). Процесс рукопожатия является более широким термином, который включает в себя три подпротокола: протокол рукопожатия (тж. согласования параметров) (англ. handshake protocol), оповещений (alert protocol), изменения параметров шифрования (англ. change cipher spec protocol). Таким образом, термин «процесс рукопожатия» включает в себя термин «рукопожатие» (Прим. перев.).

[2] Приложение B данного стандарта определяет TLS-сессию как: связь (англ. association) между клиентом и сервером, которая создается протоколом рукопожатия. Сессии определяют набор криптографических параметров безопасности, которые могут не меняться в течение многих соединений (англ. connection). Основная цель создания сессии: избежать лишних согласований новых параметров безопасности при каждом соединении (Прим. перев.).

[3] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile«, RFC 3280, April 2002. – На данный момент стандарт устарел, актуальная версия: D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008. В основе этого стандарта лежит более фундаментальный стандарт ITU-T Recommendation X.509 | ISO/IEC 9594-8, «Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks«. (Прим. перев.).

[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. данного стандарта.

[16] MITM-атака, тж. «атака man-in-the-middle», атака «человек посередине» — тип атаки, при которой злоумышленник внедряется в канал связи между двумя соединяющимися сторонами и тайно пропускает весь трафик через себя (Прим. перев.).

[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 (Прим. перев.).

[33] В разделе Errata (Ошибки) (https://www.rfc-editor.org/errata/eid5036) данного стандарта содержится предложение о введении дополнительного поля » Session ID Length » длиной 1 байт в сообщениях ClientHello и ServerHello .

Обоснование: при пропуске 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>(Прим. перев.).

[36] D. Eastlake 3 rd , «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC6066, January 2011.

[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.

[42] NIST FIPS PUB 186-2, «Digital Signature Standard«, National Institute of Standards and Technology, U.S. Department of Commerce, 2000. На данный момент устарел, актуален стандарт: На август 2021 года указанный стандарт является недействующим. Действующий стандарт — NIST FIPS 186-4, «Digital Signature Standard», National Institute of Standards and Technology, U.S. Department of Commerce, 2013 (Прим. перев.).

[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 в том, что сервер, в общем случае, должен быть обязательно аутентифицирован (выслать свой сертификат клиенту), в то время как для клиента нет такого обязательства (хотя он и может быть аутентифицирован, если этого требуют настройки сервера) (Прим. перев.).

Источник

Permalink

Cannot retrieve contributors at this time

description	ms.assetid	title	ms.topic	ms.date
Schannel returns the following error messages when the corresponding alert is received from the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols.	0a6ac61d-a00c-4fc8-a995-d25d17e405df	Schannel Error Codes for TLS and SSL Alerts	article	05/31/2018

Schannel returns the following error messages when the corresponding alert is received from the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols. The error messages are defined in Winerror.h.

TLS or SSL alert	Schannel error code
SSL3_ALERT_UNEXPECTED_MESSAGE 10	SEC_E_ILLEGAL_MESSAGE 0x80090326
TLS1_ALERT_BAD_RECORD_MAC 20	SEC_E_MESSAGE_ALTERED 0x8009030F
TLS1_ALERT_DECRYPTION_FAILED 21	SEC_E_DECRYPT_FAILURE 0x80090330
TLS1_ALERT_RECORD_OVERFLOW 22	SEC_E_ILLEGAL_MESSAGE 0x80090326
SSL3_ALERT_DECOMPRESSION_FAIL 30	SEC_E_MESSAGE_ALTERED 0x8009030F
SSL3_ALERT_HANDSHAKE_FAILURE 40	SEC_E_ILLEGAL_MESSAGE 0x80090326
TLS1_ALERT_BAD_CERTIFICATE 42	SEC_E_CERT_UNKNOWN 0x80090327
TLS1_ALERT_UNSUPPORTED_CERT 43	SEC_E_CERT_UNKNOWN 0x80090327
TLS1_ALERT_CERTIFICATE_REVOKED 44	CRYPT_E_REVOKED 0x80092010
TLS1_ALERT_CERTIFICATE_EXPIRED 45	SEC_E_CERT_EXPIRED 0x80090328
TLS1_ALERT_CERTIFICATE_UNKNOWN 46	SEC_E_CERT_UNKNOWN 0x80090327
SSL3_ALERT_ILLEGAL_PARAMETER	SEC_E_ILLEGAL_MESSAGE 0x80090326
TLS1_ALERT_UNKNOWN_CA 48	SEC_E_UNTRUSTED_ROOT 0x80090325
TLS1_ALERT_ACCESS_DENIED 49	SEC_E_LOGON_DENIED 0x8009030C
TLS1_ALERT_DECODE_ERROR 50	SEC_E_ILLEGAL_MESSAGE 0x80090326
TLS1_ALERT_DECRYPT_ERROR 51	SEC_E_DECRYPT_FAILURE 0x80090330
TLS1_ALERT_EXPORT_RESTRICTION 60	SEC_E_ILLEGAL_MESSAGE 0x80090326
TLS1_ALERT_PROTOCOL_VERSION 70	SEC_E_UNSUPPORTED_FUNCTION 0x80090302
TLS1_ALERT_INSUFFIENT_SECURITY 71	SEC_E_ALGORITHM_MISMATCH 0x80090331
TLS1_ALERT_INTERNAL_ERROR 80	SEC_E_INTERNAL_ERROR 0x80090304
TLS1_ALERT_USER_CANCELED 90	SEC_E_UNFINISHED_CONTEXT_DELETED 0x80090333
TLS1_ALERT_NO_RENEGOTIATION 100	SEC_E_ILLEGAL_MESSAGE 0x80090326
TLS1_ALERT_UNSUPPORTED_EXT 110	SEC_E_ILLEGAL_MESSAGE 0x80090326
Default	SEC_E_ILLEGAL_MESSAGE 0x80090326

У меня есть новый веб-сервер с proftpd борту. Проблема в том, что я не могу подключиться к нему через FTP-клиент filezilla потому что он выдает ошибку

Status: Connection established, waiting for welcome message...
Response:   220 FTP Server ready.
Command:    AUTH TLS
Response:   234 AUTH TLS successful
Status: Initializing TLS...
Error:  Received TLS alert from the server: Handshake failed (40)
Error:  Could not connect to server

Я обнаружил, что ошибка соответствует журналу proftpd /var/log/proftpd/tls.log/var/log/proftpd/tls.log записи:

Jul 24 13:50:47 mod_tls/2.4.2[1572]: unable to accept TLS connection: protocol error: 
  (1) error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

Это означает, что клиент ftp не поддерживает ни один из алгоритмов шифрования, предложенных сервером. В результате соединение не устанавливается.

Я также нашел директиву TLSCipherSuite в /etc/proftpd.conf которая отключает шифры ADH , DES , SSLv2 и SSLv3 .

TLSCipherSuite                 ALL:!ADH:!DES:!SSLv2:!SSLv3

Когда я удаляю :!SSLv3 из директивы и перезагрузки сервера, filezilla подключается без проблем. Но включение SSLv3 кажется плохой идеей, потому что оно уязвимо и небезопасно, согласно http://disablessl3.com/

Вопрос

Итак, мой вопрос: что я могу сделать, чтобы proftpd предоставил хотя бы один безопасный шифр для успешного согласования с FTP-клиентом filezilla ?

Дополнительное примечание

Есть похожий вопрос Получено предупреждение TLS от сервера: сбой рукопожатия (40), который говорит

Использовать только обычный FTP (небезопасный)

но я хочу, чтобы соединение было безопасным, поэтому ответ для меня не подходит.

Дополнительное примечание № 2

Список доступных шифров:

[root@server ~]# openssl ciphers -v 'ALL:!ADH:!DES:!SSLv2:!SSLv3'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

There have been many occasions where a event corresponding to SChannel is logged in the System event logs which indicates a problem with the SSL/TLS handshake and many a times depicts a number. The logging mechanism is a part of the SSL/TLS Alert Protocol.
SChannel logging may have to be enabled on the windows machines to get detailed SChannel messages. Please refer the following article to do so: http://support.microsoft.com/kb/260729

These warnings sometimes are very helpful in troubleshooting SSL related issues and provide important clues. However, there is not much documentation available on the description of the alert codes.
These alert codes have been defined precisely in TLS/SSL RFC’s for all the existing protocol versions. For example lets consider the RFC 5246 (TLS 1.2). This RFC corresponds to the latest protocol version and it defines the alert messages.

Follow this link: http://tools.ietf.org/html/rfc5246#appendix-A.3

Below is a snippet from the above RFC describing the various alert messages:

A.3.  Alert Messages

   enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
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_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),           /* new */
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;

There is MSDN article which describes these messages more briefly. Here is the link: http://technet.microsoft.com/en-us/library/cc783349%28v=ws.10%29.aspx

However, the article never mentions the alert codes while explaining the messages. For simplicity, I have created a simpler table combining both the MSDN documentation and the RFC for usability. Below is the table:

Alert Code	Alert Message	Description
0	close_notify	Notifies the recipient that the sender will not send any more messages on this connection.
10	unexpected_message	Received an inappropriate message This alert should never be observed in communication between proper implementations. This message is always fatal.
20	bad_record_mac	Received a record with an incorrect MAC. This message is always fatal.
21	decryption_failed	Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.
22	record_overflow	Received a TLSCiphertext record which had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal.
30	decompression_failure	Received improper input, such as data that would expand to excessive length, from the decompression function. This message is always fatal.
40	handshake_failure	Indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error.
42	bad_certificate	There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified.
43	unsupported_certificate	Received an unsupported certificate type.
44	certificate_revoked	Received a certificate that was revoked by its signer.
45	certificate_expired	Received a certificate has expired or is not currently valid.
46	certificate_unknown	An unspecified issue took place while processing the certificate that made it unacceptable.
47	illegal_parameter	Violated security parameters, such as a field in the handshake was out of range or inconsistent with other fields. This is always fatal.
48	unknown_ca	Received a valid certificate chain or partial chain, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA. This message is always fatal.
49	access_denied	Received a valid certificate, but when access control was applied, the sender did not proceed with negotiation. This message is always fatal.
50	decode_error	A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal.
51	decrypt_error	Failed handshake cryptographic operation, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message.
60	export_restriction	Detected a negotiation that was not in compliance with export restrictions; for example, attempting to transfer a 1024 bit ephemeral RSA key for the RSA_EXPORT handshake method. This message is always fatal.
70	protocol_version	The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal.
71	insufficient_security	Failed negotiation specifically because the server requires ciphers more secure than those supported by the client. Returned instead of handshake_failure. This message is always fatal.
80	internal_error	An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue, such as a memory allocation failure. The error is not related to protocol. This message is always fatal.
90	user_cancelled	Cancelled handshake for a reason that is unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning.
100	no_renegotiation	Sent by the client in response to a hello request or sent by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, and so on) at start-up and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.
255	unsupported_extension

Hope this reference will be useful for someone in troubleshooting TLS/SSL errors!

Constant

Value

Description

SEC_ERROR_IO

-8192

An I/O error occurred during
authentication; or
an error occurred during
crypto operation (other than
signature verification).

SEC_ERROR_LIBRARY_FAILURE

-8191

Security library failure.

SEC_ERROR_BAD_DATA

-8190

Security library: received bad
data.

SEC_ERROR_OUTPUT_LEN

-8189

Security library: output
length error.

SEC_ERROR_INPUT_LEN

-8188

Security library: input length
error.

SEC_ERROR_INVALID_ARGS

-8187

Security library: invalid
arguments.

SEC_ERROR_INVALID_ALGORITHM

-8186

Security library: invalid
algorithm.

SEC_ERROR_INVALID_AVA

-8185

Security library: invalid AVA.

SEC_ERROR_INVALID_TIME

-8184

Security library: invalid
time.

SEC_ERROR_BAD_DER

-8183

Security library: improperly
formatted DER-encoded message.

SEC_ERROR_BAD_SIGNATURE

-8182

Peer’s certificate has an
invalid signature.

SEC_ERROR_EXPIRED_CERTIFICATE

-8181

Peer’s certificate has
expired.

SEC_ERROR_REVOKED_CERTIFICATE

-8180

Peer’s certificate has been
revoked.

SEC_ERROR_UNKNOWN_ISSUER

-8179

Peer’s certificate issuer is
not recognized.

SEC_ERROR_BAD_KEY

-8178

Peer’s public key is invalid

SEC_ERROR_BAD_PASSWORD

-8177

The password entered is
incorrect.

SEC_ERROR_RETRY_PASSWORD

-8176

New password entered
incorrectly.

SEC_ERROR_NO_NODELOCK

-8175

Security library: no nodelock.

SEC_ERROR_BAD_DATABASE

-8174

Security library: bad
database.

SEC_ERROR_NO_MEMORY

-8173

Security library: memory
allocation failure.

SEC_ERROR_UNTRUSTED_ISSUER

-8172

Peer’s certificate issuer has
been marked as not trusted by
the user.

SEC_ERROR_UNTRUSTED_CERT

-8171

Peer’s certificate has been
marked as not trusted by the
user.

SEC_ERROR_DUPLICATE_CERT

-8170

Certificate already exists in
your database.

SEC_ERROR_DUPLICATE_CERT_NAME

-8169

Downloaded certificate’s name
duplicates one already in your
database.

SEC_ERROR_ADDING_CERT

-8168

Error adding certificate to
database.

SEC_ERROR_FILING_KEY

-8167

Error refiling the key for
this certificate.

SEC_ERROR_NO_KEY

-8166

The private key for this
certificate cannot be found in
key database.

SEC_ERROR_CERT_VALID

-8165

This certificate is valid.

SEC_ERROR_CERT_NOT_VALID

-8164

This certificate is not valid.

SEC_ERROR_CERT_NO_RESPONSE

-8163

Certificate library: no
response.

SEC_ER
ROR_EXPIRED_ISSUER_CERTIFICATE

-8162

The certificate issuer’s
certificate has expired.

SEC_ERROR_CRL_EXPIRED

-8161

The CRL for the certificate’s
issuer has expired.

SEC_ERROR_CRL_BAD_SIGNATURE

-8160

The CRL for the certificate’s
issuer has an invalid
signature.

SEC_ERROR_CRL_INVALID

-8159

New CRL has an invalid format.

SEC
_ERROR_EXTENSION_VALUE_INVALID

-8158

Certificate extension value is
invalid.

SEC_ERROR_EXTENSION_NOT_FOUND

-8157

Certificate extension not
found.

SEC_ERROR_CA_CERT_INVALID

-8156

Issuer certificate is invalid.

SEC_ERR
OR_PATH_LEN_CONSTRAINT_INVALID

-8155

Certificate path length
constraint is invalid.

SEC_ERROR_CERT_USAGES_INVALID

-8154

Certificate usages field is
invalid.

SEC_INTERNAL_ONLY

-8153

Internal-only module.

SEC_ERROR_INVALID_KEY

-8152

The key does not support the
requested operation.

SEC_ER
ROR_UNKNOWN_CRITICAL_EXTENSION

-8151

Certificate contains unknown
critical extension.

SEC_ERROR_OLD_CRL

-8150

New CRL is not later than the
current one.

SEC_ERROR_NO_EMAIL_CERT

-8149

Not encrypted or signed: you
do not yet have an email
certificate.

SEC_
ERROR_NO_RECIPIENT_CERTS_QUERY

-8148

Not encrypted: you do not have
certificates for each of the
recipients.

SEC_ERROR_NOT_A_RECIPIENT

-8147

Cannot decrypt: you are not a
recipient, or matching
certificate and private key
not found.

S
EC_ERROR_PKCS7_KEYALG_MISMATCH

-8146

Cannot decrypt: key encryption
algorithm does not match your
certificate.

SEC_ERROR_PKCS7_BAD_SIGNATURE

-8145

Signature verification failed:
no signer found, too many
signers found,
or improper or corrupted data.

SEC_ERROR_UNSUPPORTED_KEYALG

-8144

Unsupported or unknown key
algorithm.

S
EC_ERROR_DECRYPTION_DISALLOWED

-8143

Cannot decrypt: encrypted
using a disallowed algorithm
or key size.

XP_SEC_FORTEZZA_BAD_CARD

-8142

FORTEZZA card has not been
properly initialized.

XP_SEC_FORTEZZA_NO_CARD

-8141

No FORTEZZA cards found.

XP_SEC_FORTEZZA_NONE_SELECTED

-8140

No FORTEZZA card selected.

XP_SEC_FORTEZZA_MORE_INFO

-8139

Please select a personality to
get more info on.

XP
_SEC_FORTEZZA_PERSON_NOT_FOUND

-8138

Personality not found

XP_SEC_FORTEZZA_NO_MORE_INFO

-8137

No more information on that
personality.

XP_SEC_FORTEZZA_BAD_PIN

-8136

Invalid PIN.

XP_SEC_FORTEZZA_PERSON_ERROR

-8135

Couldn’t initialize FORTEZZA
personalities.

SEC_ERROR_NO_KRL

-8134

No KRL for this site’s
certificate has been found.

SEC_ERROR_KRL_EXPIRED

-8133

The KRL for this site’s
certificate has expired.

SEC_ERROR_KRL_BAD_SIGNATURE

-8132

The KRL for this site’s
certificate has an invalid
signature.

SEC_ERROR_REVOKED_KEY

-8131

The key for this site’s
certificate has been revoked.

SEC_ERROR_KRL_INVALID

-8130

New KRL has an invalid format.

SEC_ERROR_NEED_RANDOM

-8129

Security library: need random
data.

SEC_ERROR_NO_MODULE

-8128

Security library: no security
module can perform the
requested operation.

SEC_ERROR_NO_TOKEN

-8127

The security card or token
does not exist, needs to be
initialized, or has been
removed.

SEC_ERROR_READ_ONLY

-8126

Security library: read-only
database.

SEC_ERROR_NO_SLOT_SELECTED

-8125

No slot or token was selected.

SEC
_ERROR_CERT_NICKNAME_COLLISION

-8124

A certificate with the same
nickname already exists.

SE
C_ERROR_KEY_NICKNAME_COLLISION

-8123

A key with the same nickname
already exists.

SEC_ERROR_SAFE_NOT_CREATED

-8122

Error while creating safe
object.

SEC_ERROR_BAGGAGE_NOT_CREATED

-8121

Error while creating baggage
object.

XP_JAVA_REMOVE_PRINCIPAL_ERROR

-8120

Couldn’t remove the principal.

XP_JAVA_DELETE_PRIVILEGE_ERROR

-8119

Couldn’t delete the privilege

XP_JAVA_CERT_NOT_EXISTS_ERROR

-8118

This principal doesn’t have a
certificate.

SEC_ERROR_BAD_EXPORT_ALGORITHM

-8117

Required algorithm is not
allowed.

SE
C_ERROR_EXPORTING_CERTIFICATES

-8116

Error attempting to export
certificates.

SE
C_ERROR_IMPORTING_CERTIFICATES

-8115

Error attempting to import
certificates.

SEC_ERROR_PKCS12_DECODING_PFX

-8114

Unable to import. Decoding
error. File not valid.

SEC_ERROR_PKCS12_INVALID_MAC

-8113

Unable to import. Invalid MAC.
Incorrect password or corrupt
file.

SEC_ERROR_PK
CS12_UNSUPPORTED_MAC_ALGORITHM

-8112

Unable to import. MAC
algorithm not supported.

SEC_ERROR_PKC
S12_UNSUPPORTED_TRANSPORT_MODE

-8111

Unable to import. Only
password integrity and privacy
modes supported.

SEC_ERROR
_PKCS12_CORRUPT_PFX_STRUCTURE

-8110

Unable to import. File
structure is corrupt.

SEC_ERROR_PK
CS12_UNSUPPORTED_PBE_ALGORITHM

-8109

Unable to import. Encryption
algorithm not supported.

SEC_ER
ROR_PKCS12_UNSUPPORTED_VERSION

-8108

Unable to import. File version
not supported.

SEC_ERROR_PKC
S12_PRIVACY_PASSWORD_INCORRECT

-8107

Unable to import. Incorrect
privacy password.

S
EC_ERROR_PKCS12_CERT_COLLISION

-8106

Unable to import. Same
nickname already exists in
database.

SEC_ERROR_USER_CANCELLED

-8105

The user clicked cancel.

S
EC_ERROR_PKCS12_DUPLICATE_DATA

-8104

Not imported, already in
database.

SEC_ERROR_MESSAGE_SEND_ABORTED

-8103

Message not sent.

SEC_ERROR_INADEQUATE_KEY_USAGE

-8102

Certificate key usage
inadequate for attempted
operation.

SEC_ERROR_INADEQUATE_CERT_TYPE

-8101

Certificate type not approved
for application.

SEC_ERROR_CERT_ADDR_MISMATCH

-8100

Address in signing certificate
does not match address in
message headers.

SEC_ERR
OR_PKCS12_UNABLE_TO_IMPORT_KEY

-8099

Unable to import. Error
attempting to import private
key.

SEC_ERR
OR_PKCS12_IMPORTING_CERT_CHAIN

-8098

Unable to import. Error
attempting to import
certificate chain.

SEC_ERROR_PKCS12_U
NABLE_TO_LOCATE_OBJECT_BY_NAME

-8097

Unable to export. Unable to
locate certificate or key by
nickname.

SEC_ERRO
R_PKCS12_UNABLE_TO_EXPORT_KEY

-8096

Unable to export. Private key
could not be located and
exported.

SE
C_ERROR_PKCS12_UNABLE_TO_WRITE

-8095

Unable to export. Unable to
write the export file.

S
EC_ERROR_PKCS12_UNABLE_TO_READ

-8094

Unable to import. Unable to
read the import file.

SEC_ERROR_PKCS1
2_KEY_DATABASE_NOT_INITIALIZED

-8093

Unable to export. Key database
corrupt or deleted.

SEC_ERROR_KEYGEN_FAIL

-8092

Unable to generate
public-private key pair.

SEC_ERROR_INVALID_PASSWORD

-8091

Password entered is invalid.

SEC_ERROR_RETRY_OLD_PASSWORD

-8090

Old password entered
incorrectly.

SEC_ERROR_BAD_NICKNAME

-8089

Certificate nickname already
in use.

SEC_ERROR_NOT_FORTEZZA_ISSUER

-8088

Peer FORTEZZA chain has a
non-FORTEZZA Certificate.

SEC_E
RROR_CANNOT_MOVE_SENSITIVE_KEY

-8087

“A sensitive key cannot be
moved to the slot where it is
needed.”

SE
C_ERROR_JS_INVALID_MODULE_NAME

-8086

Invalid module name.

SEC_ERROR_JS_INVALID_DLL

-8085

Invalid module path/filename.

SEC_ERROR_JS_ADD_MOD_FAILURE

-8084

Unable to add module.

SEC_ERROR_JS_DEL_MOD_FAILURE

-8083

Unable to delete module.

SEC_ERROR_OLD_KRL

-8082

New KRL is not later than the
current one.

SEC_ERROR_CKL_CONFLICT

-8081

New CKL has different issuer
than current CKL.

SE
C_ERROR_CERT_NOT_IN_NAME_SPACE

-8080

Certificate issuer is not
permitted to issue a
certificate with this name.

SEC_ERROR_KRL_NOT_YET_VALID

-8079

“The key revocation list for
this certificate is not yet
valid.”

SEC_ERROR_CRL_NOT_YET_VALID

-8078

“The certificate revocation
list for this certificate is
not yet valid.”

SEC_ERROR_UNKNOWN_CERT

-8077

“The requested certificate
could not be found.”

SEC_ERROR_UNKNOWN_SIGNER

-8076

“The signer’s certificate
could not be found.”

SEC_
ERROR_CERT_BAD_ACCESS_LOCATION

-8075

“The location for the
certificate status server has
invalid format.”

SEC_ER
ROR_OCSP_UNKNOWN_RESPONSE_TYPE

-8074

“The OCSP response cannot be
fully decoded; it is of an
unknown type.”

SE
C_ERROR_OCSP_BAD_HTTP_RESPONSE

-8073

“The OCSP server returned
unexpected/invalid HTTP data.”

SE
C_ERROR_OCSP_MALFORMED_REQUEST

-8072

“The OCSP server found the
request to be corrupted or
improperly formed.”

SEC_ERROR_OCSP_SERVER_ERROR

-8071

“The OCSP server experienced
an internal error.”

S
EC_ERROR_OCSP_TRY_SERVER_LATER

-8070

“The OCSP server suggests
trying again later.”

SE
C_ERROR_OCSP_REQUEST_NEEDS_SIG

-8069

“The OCSP server requires a
signature on this request.”

SEC_E
RROR_OCSP_UNAUTHORIZED_REQUEST

-8068

“The OCSP server has refused
this request as unauthorized.”

SEC_ERRO
R_OCSP_UNKNOWN_RESPONSE_STATUS

-8067

“The OCSP server returned an
unrecognizable status.”

SEC_ERROR_OCSP_UNKNOWN_CERT

-8066

“The OCSP server has no status
for the certificate.”

SEC_ERROR_OCSP_NOT_ENABLED

-8065

“You must enable OCSP before
performing this operation.”

SEC_E
RROR_OCSP_NO_DEFAULT_RESPONDER

-8064

“You must set the OCSP default
responder before performing
this operation.”

SEC
_ERROR_OCSP_MALFORMED_RESPONSE

-8063

“The response from the OCSP
server was corrupted or
improperly formed.”

SEC_ER
ROR_OCSP_UNAUTHORIZED_RESPONSE

-8062

“The signer of the OCSP
response is not authorized to
give status for this
certificate.”

SEC_ERROR_OCSP_FUTURE_RESPONSE

-8061

“The OCSP response is not yet
valid (contains a date in the
future).”

SEC_ERROR_OCSP_OLD_RESPONSE

-8060

“The OCSP response contains
out-of-date information.”

SEC_ERROR_DIGEST_NOT_FOUND

-8059

“The CMS or PKCS #7 Digest was
not found in signed message.”

SEC_
ERROR_UNSUPPORTED_MESSAGE_TYPE

-8058

“The CMS or PKCS #7 Message
type is unsupported.”

SEC_ERROR_MODULE_STUCK

-8057

“PKCS #11 module could not be
removed because it is still in
use.”

SEC_ERROR_BAD_TEMPLATE

-8056

“Could not decode ASN.1 data.
Specified template was
invalid.”

SEC_ERROR_CRL_NOT_FOUND

-8055

“No matching CRL was found.”

SEC_
ERROR_REUSED_ISSUER_AND_SERIAL

-8054

“You are attempting to import
a cert with the same
issuer/serial as an existing
cert, but that is not the same
cert.”

SEC_ERROR_BUSY

-8053

“NSS could not shutdown.
Objects are still in use.”

SEC_ERROR_EXTRA_INPUT

-8052

“DER-encoded message contained
extra unused data.”

SEC_ER
ROR_UNSUPPORTED_ELLIPTIC_CURVE

-8051

“Unsupported elliptic curve.”

SEC_E
RROR_UNSUPPORTED_EC_POINT_FORM

-8050

“Unsupported elliptic curve
point form.”

SEC_ERROR_UNRECOGNIZED_OID

-8049

“Unrecognized Object
IDentifier.”

SEC_E
RROR_OCSP_INVALID_SIGNING_CERT

-8048

“Invalid OCSP signing
certificate in OCSP response.”

SEC
_ERROR_REVOKED_CERTIFICATE_CRL

-8047

“Certificate is revoked in
issuer’s certificate
revocation list.”

SEC_
ERROR_REVOKED_CERTIFICATE_OCSP

-8046

“Issuer’s OCSP responder
reports certificate is
revoked.”

SEC_ERROR_CRL_INVALID_VERSION

-8045

“Issuer’s Certificate
Revocation List has an unknown
version number.”

SEC_E
RROR_CRL_V1_CRITICAL_EXTENSION

-8044

“Issuer’s V1 Certificate
Revocation List has a critical
extension.”

SEC_ERROR_
CRL_UNKNOWN_CRITICAL_EXTENSION

-8043

“Issuer’s V2 Certificate
Revocation List has an unknown
critical extension.”

SEC_ERROR_UNKNOWN_OBJECT_TYPE

-8042

“Unknown object type
specified.”

SEC_ERROR_INCOMPATIBLE_PKCS11

-8041

“PKCS #11 driver violates the
spec in an incompatible way.”

SEC_ERROR_NO_EVENT

-8040

“No new slot event is
available at this time.”

SEC_ERROR_CRL_ALREADY_EXISTS

-8039

“CRL already exists.”

SEC_ERROR_NOT_INITIALIZED

-8038

“NSS is not initialized.”

SEC_ERROR_TOKEN_NOT_LOGGED_IN

-8037

“The operation failed because
the PKCS#11 token is not
logged in.”

SEC_ERR
OR_OCSP_RESPONDER_CERT_INVALID

-8036

“The configured OCSP
responder’s certificate is
invalid.”

SEC_ERROR_OCSP_BAD_SIGNATURE

-8035

“OCSP response has an invalid
signature.”

SEC_ERROR_OUT_OF_SEARCH_LIMITS

-8034

“Certification validation
search is out of search
limits.”

SE
C_ERROR_INVALID_POLICY_MAPPING

-8033

“Policy mapping contains
any-policy.”

SEC_
ERROR_POLICY_VALIDATION_FAILED

-8032

“Certificate chain fails
policy validation.”

SEC_E
RROR_UNKNOWN_AIA_LOCATION_TYPE

-8031

“Unknown location type in
certificate AIA extension.”

SEC_ERROR_BAD_HTTP_RESPONSE

-8030

“Server returned a bad HTTP
response.”

SEC_ERROR_BAD_LDAP_RESPONSE

-8029

“Server returned a bad LDAP
response.”

S
EC_ERROR_FAILED_TO_ENCODE_DATA

-8028

“Failed to encode data with
ASN.1 encoder.”

SEC_
ERROR_BAD_INFO_ACCESS_LOCATION

-8027

“Bad information access
location in certificate
extension.”

SEC_ERROR_LIBPKIX_INTERNAL

-8026

“Libpkix internal error
occurred during cert
validation.”

SEC_ERROR_PKCS11_GENERAL_ERROR

-8025

“A PKCS #11 module returned
CKR_GENERAL_ERROR, indicating
that an unrecoverable error
has occurred.”

SE
C_ERROR_PKCS11_FUNCTION_FAILED

-8024

“A PKCS #11 module returned
CKR_FUNCTION_FAILED,
indicating that the requested
function could not be
performed. Trying the same
operation again might
succeed.”

SEC_ERROR_PKCS11_DEVICE_ERROR

-8023

“A PKCS #11 module returned
CKR_DEVICE_ERROR, indicating
that a problem has occurred
with the token or slot.”

SE
C_ERROR_BAD_INFO_ACCESS_METHOD

-8022

“Unknown information access
method in certificate
extension.”

SEC_ERROR_CRL_IMPORT_FAILED

-8021

“Error attempting to import a
CRL.”

SEC_ERROR_UNKNOWN_PKCS11_ERROR

-8018

“Unknown PKCS #11 error.”
(unknown error value mapping)

There have been many occasions where a event corresponding to SChannel is logged in the System event logs which indicates a problem with the SSL/TLS handshake and many a times depicts a number. The logging mechanism is a part of the SSL/TLS Alert Protocol. These alerts are used to notify peers of the normal and error conditions. The numbers especially, play a trivial role in understanding the problem/failure with the SSL/TLS handshake.

SChannel logging may have to be enabled on the windows machines to get detailed SChannel messages. Please refer the following article to do so: http://support.microsoft.com/kb/260729

Below is an example of one such event:

Log Name:      System
Source:        Schannel
Date:          x/xx/xxxx x:xx:xx
Event ID:      36887
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      xxxxxxx
Description:
The following fatal alert was received: 47.

These warnings sometimes are very helpful in troubleshooting SSL related issues and provide important clues. However, there is not much documentation available on the description of the alert codes.

These alert codes have been defined precisely in TLS/SSL RFC’s for all the existing protocol versions. For example lets consider the RFC 5246 (TLS 1.2). This RFC corresponds to the latest protocol version and it defines the alert messages.

Follow this link: http://tools.ietf.org/html/rfc5246#appendix-A.3

Below is a snippet from the above RFC describing the various alert messages:

A.3.  Alert Messages

   enum { warning(1), fatal(2), (255) } AlertLevel;
   enum {
       close_notify(0),
       unexpected_message(10),
       bad_record_mac(20),
       decryption_failed_RESERVED(21),
       record_overflow(22),
       decompression_failure(30),
       handshake_failure(40),
       no_certificate_RESERVED(41),
       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_RESERVED(60),
       protocol_version(70),
       insufficient_security(71),
       internal_error(80),
       user_canceled(90),
       no_renegotiation(100),
       unsupported_extension(110),           /* new */
       (255)
   } AlertDescription;
   struct {
       AlertLevel level;
       AlertDescription description;
   } Alert;

There is MSDN article which describes these messages more briefly. Here is the link: http://technet.microsoft.com/en-us/library/cc783349%28v=ws.10%29.aspx.

However, the article never mentions the alert codes while explaining the messages. For simplicity, I have created a simpler table combining both the MSDN documentation and the RFC for usability. Below is the table:

</tr> </tbody> </table>

There were few articles that I found while searching that contain additional alert codes. However, I don’t find these to be part of the RFC. Here is one: http://botan.randombit.net/doxygen/classBotan_1_1TLS_1_1Alert.html

It includes additional alerts like 110, 111, 112, 113, 114, 115. You can browse the above link for further reading.

Hope someone finds the above table useful. It may not help you in solving any issue but would provide useful pointers.

Until then, Ciao!

Alert Code	Alert Message	Description
</td>	</p> close_notify </td>	</p> Notifies the recipient that the sender will not send any more messages on this connection. </td> </tr>
</p> 10 </td>	</p> unexpected_message </td>	</p> Received an inappropriate message This alert should never be observed in communication between proper implementations. This message is always fatal. </td> </tr>
</p> 20 </td>	</p> bad_record_mac </td>	</p> Received a record with an incorrect MAC. This message is always fatal. </td> </tr>
</p> 21 </td>	</p> decryption_failed </td>	</p> Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal. </td> </tr>
</p> 22 </td>	</p> record_overflow </td>	</p> Received a TLSCiphertext record which had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal. </td> </tr>
</p> 30 </td>	</p> decompression_failure </td>	</p> Received improper input, such as data that would expand to excessive length, from the decompression function. This message is always fatal. </td> </tr>
</p> 40 </td>	</p> handshake_failure </td>	</p> Indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error. </td> </tr>
</p> 42 </td>	</p> bad_certificate </td>	</p> There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified. </td> </tr>
</p> 43 </td>	</p> unsupported_certificate </td>	</p> Received an unsupported certificate type. </td> </tr>
</p> 44 </td>	</p> certificate_revoked </td>	</p> Received a certificate that was revoked by its signer. </td> </tr>
</p> 45 </td>	</p> certificate_expired </td>	</p> Received a certificate has expired or is not currently valid. </td> </tr>
</p> 46 </td>	</p> certificate_unknown </td>	</p> An unspecified issue took place while processing the certificate that made it unacceptable. </td> </tr>
</p> 47 </td>	</p> illegal_parameter </td>	</p> Violated security parameters, such as a field in the handshake was out of range or inconsistent with other fields. This is always fatal. </td> </tr>
</p> 48 </td>	</p> unknown_ca </td>	</p> Received a valid certificate chain or partial chain, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA. This message is always fatal. </td> </tr>
</p> 49 </td>	</p> access_denied </td>	</p> Received a valid certificate, but when access control was applied, the sender did not proceed with negotiation. This message is always fatal. </td> </tr>
</p> 50 </td>	</p> decode_error </td>	</p> A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal. </td> </tr>
</p> 51 </td>	</p> decrypt_error </td>	</p> Failed handshake cryptographic operation, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message. </td> </tr>
</p> 60 </td>	</p> export_restriction </td>	</p> Detected a negotiation that was not in compliance with export restrictions; for example, attempting to transfer a 1024 bit ephemeral RSA key for the RSA_EXPORT handshake method. This message is always fatal. </td> </tr>
</p> 70 </td>	</p> protocol_version </td>	</p> The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal. </td> </tr>
</p> 71 </td>	</p> insufficient_security </td>	</p> Failed negotiation specifically because the server requires ciphers more secure than those supported by the client. Returned instead of handshake_failure. This message is always fatal. </td> </tr>
</p> 80 </td>	</p> internal_error </td>	</p> An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue, such as a memory allocation failure. The error is not related to protocol. This message is always fatal. </td> </tr>
</p> 90 </td>	</p> user_cancelled </td>	</p> Cancelled handshake for a reason that is unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning. </td> </tr>
</p> 100 </td>	</p> no_renegotiation </td>	</p> Sent by the client in response to a hello request or sent by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, and so on) at start-up and it might be difficult to communicate changes to these parameters after that point. This message is always a warning. </td> </tr>
</p> 255 </td>	</p> unsupported_extension </td>	</p>