Сертификат ненадёжен

Hello,

Откройте сам сертификат ЭЦП и на вкладке Путь сертификации будут отображены корневые и промежуточные сертификаты издателя, их надо обновить. Инструкция: ссылка на инструкцию

Я не сотрудник компании.

Все эти манипуляции проделаны несколько раз. Переустановлены все сертификаты и корневые и промежуточные и тд. К нам подключалась техподдержка Калуги, проверяли сертификаты.

Программа Криптопро CSP

Здравствуйте, vladislavhf, уточните пожалуйста какой версии программы Криптопро CSP установлена на компьютере?

Область применения электронной подписи (ЭП или ЭЦП) довольно широка. Например, многие специальные сервисы требуют верификации пользователя с её помощью — личный кабинет налоговой, Госуслуги, онлайн-сервисы для управления средствами в банке, электронные площадки и другие. Поэтому любые технические неполадки, возникающие при использовании ЭЦП, могут вызвать различные серьёзные проблемы: от упущенной выгоды до материальных убытков.

Ошибки при использовании ЭП

Проблемы при использовании ЭП, с которыми пользователи встречаются чаще всего, можно условно разделить на различные группы:

• Компьютеру не удаётся проверить цепочку доверия или списки отозванных сертификатов
• Сертификат не найден

Не удаётся проверить цепочку доверия или списки отозванных сертификатов

Причина, по которой компьютеру не удаётся проверить цепочку доверия или списки отозванных сертификатов может быть и в ошибке Не удаётся проверить подпись сертификата, и в ошибке Не удаётся построить цепочку сертификатов для доверенного корневого центра. Бывает, что сертификат в хранилище Windows бьётся где-то по пути его передачи, то есть его хэш сумма меняется и СКЗИ не может проверить его подпись. Также ошибка появляется в случаях, когда нужный корневой сертификат установлен в хранилище, но цепочка доверия ошибочно строится через другой сертификат.

Сертификат не найден

Описание ошибки и дополнительные инструкции.

Заключение

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

Ошибки и проблемы с ЭП: как их решить

Иногда при попытке подписать электронный документ с помощью ЭП пользователь может столкнуться с ошибкой Не удалось найти ни одного сертификата, пригодного для создания подписи.

Причины ошибок:

Для установки списка отозванных сертификатов:

Проблема с промежуточным сертификатом цепочки доверия:

Не виден сертификат на носителе

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

Распространённые причины:

ЭЦП не подписывается на документе

Причин множество, каждый случай требует отдельной проверки. Среди наиболее распространённых неполадок:

Ошибка Невозможно создание объекта сервером программирования объектов:

Установка и регистрация библиотеки Capicom помогает в этой ситуации:

Выбранная подпись не авторизована

Такая ошибка возникает при попытке авторизации на электронных торговых площадках. Решение — регистрация нового сертификата.

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

Часто задаваемые вопросы

Почему компьютер не видит ЭЦП? Проблема может быть в несовместимости программного обеспечения и носителя ЭП. Проверьте версию операционной системы и, если нужно, переустановите её. Если токен повреждён, обратитесь в удостоверяющий центр для перевыпуска ЭП.

Что делать, если компьютер не видит ЭЦП

О том, что делать, если компьютер не видит ЭЦП, и о способах проверки настроек, мы подробно писали в нашей статье.

Порядок устранения неполадок

Порядок устранения неполадок зависит от:

• Изменений в законодательстве, связанных с ЭЦП
• Типа ошибки при проверке ЭП

Также необходимо учитывать изменения в законодательстве, связанные с ЭЦП. Например, квалифицированные сертификаты подписи работников организаций не будут действительны с 1 сентября 2024 года при условии, если они выпущены до 1 сентября 2023 года. Если контрагенту отправлен документ, подписанный такой подписью, то при получении появится ошибка о том, что ЭЦП не прошла проверку. В этом случае подписанный файл не будет иметь юридической силы.

Почему не получилось проверить ЭЦП? Речь о ЭП, которые передаются без участия оператора электронного документооборота. Например, документ об устройстве на работу подписан физлицом и отправлен в отдел кадров по электронной почте. У получателя при проверке появляется ошибка, что системе не удалось проверить электронную подпись. Значит, отправитель изменил данные в документе после подписания или его сертификат недействителен, или отозван.

Почему КриптоПро не отображает ЭЦП

Почему КриптоПро не отображает ЭЦП? Если КриптоПро CSP не отображает ключи ЭЦП, следует проверить настройки браузера. Также исправляет ошибку добавление плагина для работы с ЭП в веб-обозреватель и загрузка недостающих сертификатов электронной подписи.

Подробнее ознакомиться, как устранить данную неисправность, можно в нашей статье.

Где на компьютере искать сертификаты ЭЦП

Где на компьютере искать сертификаты ЭЦП? Сертификат ЭЦП позволяет проверить подлинность подписи, содержит в себе срок её действия и информацию о владельце. Он автоматически загружается в папку с системными файлами. В операционной системе Windows от 7 версии и выше ЭЦП хранится по адресу:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

Что такое сертификат ЭЦП и зачем он нужен, мы рассказали в нашей статье.

Другие значения термина

У этого термина существуют и другие значения, см. SSL (значения).

Протокол SSL

SSL (Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который подразумевает более безопасную связь. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко использовался для обмена мгновенными сообщениями и передачи голоса через IP (Voice over IP — VoIP) в таких приложениях, как электронная почта, интернет-факс и др.

Протокол SSL обеспечивает защищённый обмен данными за счёт двух следующих элементов:

• Асимметричной криптографии для аутентификации ключей обмена
• Симметричного шифрования для сохранения конфиденциальности
• Кодов аутентификации сообщений для целостности сообщений

Протокол SSL предоставляет безопасный канал, который имеет три основных свойства.

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

История и развитие

TLS 1.0 впервые был определен в RFC 2246 в январе 1999 года в качестве обновления версии SSL 3.0. Как указано в RFC, различия между этим протоколом и SSL 3.0 не критичны, но они значительны для появления несовместимости при взаимодействии TLS 1.0 и SSL 3.0. TLS 1.0 действительно включает средства, с помощью которых реализация подключения TLS к SSL 3.0 ослабит безопасность.

TLS 1.2 был анонсирован в RFC 5246 в августе 2008 года. Он основан на ранее предложенной версии TLS 1.1.

TLS 1.3 был признан стандартом в RFC 8446 в августе 2018 года.

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

Уровни протокола

Работу протокола можно разделить на два уровня:

Первый слой

Первый слой состоит из трех подпротоколов:

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

SSL также использует сертификаты для проверки принадлежности открытого ключа его реальному владельцу.

Способы получения SSL-сертификата

1. Самоподписанный сертификат.
2. Пустой сертификат.

Типы сертификатов SSL

1. Сертификаты, подтверждающие домен.
2. Сертификаты расширенной проверки.

Все сертификаты выпускаются в Центрах сертификации. Существует несколько разновидностей SSL-удостоверений. Обычно выделяют три типа — в соответствии с уровнем проверки, которая проводится перед выдачей:

Механизмы образования ключа для текущей сессии в SSL/TLS

Существует 4 основных алгоритма для образования ключей: RSA, Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman

Основная статья: RSA

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

Механизм Fixed Diffie-Hellman использует постоянный публичный ключ, который прописан в сертификате сервера. Это также означает, что при каждом новом соединении клиент предоставляет свою часть ключа. После обмена ключами образуется новый симметричный ключ для обмена информацией для текущей сессии. При раскрытии приватного ключа сервера криптоаналитик может расшифровать ранее записанные сообщения, а также все будущие сообщения. Это становится возможным из-за самого механизма. Так как криптоаналитик знает приватный ключ сервера, он сможет узнать симметричный ключ каждой сессии, и даже тот факт, что механизм образования ключа является двусторонним, не поможет. Механизм Anonymous Diffie-Hellman не предоставляет гарантий секретности, ибо данные передаются незашифрованными. Единственный вариант, при котором гарантируется безопасность прошлых и будущих сообщений — Ephemeral Diffie-Hellman. Разница по сравнению с ранее рассмотренными методами заключается в том, что при каждом новом соединении сервером и клиентом создается одноразовый ключ. Таким образом, даже если криптоаналитику достанется текущий приватный ключ, он сможет расшифровать только текущую сессию, но не предыдущие или будущие сессии.

Существует два основных способа шифрования данных: симметричное шифрование (общий секретный ключ) и асимметричное шифрование (пара открытый/приватный ключ).

SSL использует как асимметричную, так и симметричную криптографию.

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

RSA — один из самых распространённых алгоритмов асимметричного шифрования.

При использовании симметричного шифрования один и тот же ключ используется как для шифрования, так и для расшифровывания данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных (так как симметричное шифрование является более быстрым). Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.

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

Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создаёт 128-битное хеш-значение, SHA-1 (Secure Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.

Возможно, этот раздел содержит оригинальное исследование.

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

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

Протокол SSL позволяет использовать шифрование симметричным ключом, используя либо блочные, либо потоковые шифры. Обычно на практике применяются блочные шифры. Принцип работы блочного шифра заключается в отображении блока открытого текста в такой же блок шифрованного текста. Этот шифр можно представить в виде таблицы, содержащей 2128 строк, каждая строка содержит блок открытого текста M и соответствующий ему блок шифрованного текста C. Подобная таблица существует для каждого ключа.

Шифрование можно обозначить в виде функции

C = E(Key, M), где M — исходные данные, Key — ключ шифрования, С — зашифрованные данные.

Частое использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL (или уже TLS), тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется во Всемирной паутине для приложений, в которых важна безопасность соединения, например в платёжных системах. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

TLS 1.0 Может быть 94.7 %

Информация в этой статье или некоторых её разделах устарела.

Вы можете помочь проекту, обновив её и убрав после этого данный шаблон.

По состоянию на начало 2017 г. все основные веб-браузеры, поддерживающие SSL/TLS:

Браузер Платформы TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3

Chrome 1-21 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да Нет Нет Нет

Chrome 58+ Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) Да Да Да Да

Firefox 27-53 Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да Да Да Нет

Firefox 54+ Linux, Mac OS X, Windows (XP, Vista, 7, 8) Да Да Да Да

IE 6 Windows (XP) Да Нет Нет Нет

IE 7-8 Windows (XP, Vista) Да Нет Нет Нет

IE 8-9 Windows 7 Да Да Да Нет

IE 9 Windows Vista Да Нет Нет Нет

IE 10+ Windows (7, 8) Да Да Да Нет

Edge 12-15 Windows 10 Да Да Да Нет

Opera 10+ Linux, Mac OS X, Windows Да Да Да Нет

Opera 44+ Linux, Mac OS X, Windows Да Да Да Да

Safari 4 Mac OS X, Windows (XP, Vista, 7), iOS 4.0 Да Нет Нет Нет

Safari 5 Mac OS X, Windows (XP, Vista, 7) Да Нет Нет Нет

Safari 7-10 iOS 5.0- Да Да Да Нет

Использование и реализация

Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна, сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.

Наиболее распространённая реализация SSL — криптографический пакет с открытым исходным кодом OpenSSL, основанный на SSLeay, написанной Эриком Янгом. Последняя версия OpenSSL поддерживает SSLv3. Пакет предназначен для создания и управления различного рода сертификатами. Также в его состав входит библиотека для поддержки SSL различными программами. Библиотека используется, например, модулем SSL в распространенном HTTP-сервере Apache.

Спецификация протокола записей SSL

Все данные в SSL пересылаются в виде записей (рекордов) — объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит 2 или 3 байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель, и полная длина заголовка равна 3 байтам. В случае длинного (3 байта) заголовка второй по старшинству бит первого байта имеет специальное значение. Если он равен 0 — рекорд является информационным, если он равен 1 — рекорд является security escape. Код длины рекорда не включает в себя число байт заголовка. Для 2-байтового заголовка его длина вычисляется так:

Значение PADDING специфицирует число байтов, добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра. Отправитель добавляет PADDING после имеющихся данных, а затем шифрует всё это, так как длина этого массива кратна размеру блока используемого шифра. Поскольку известен объём передаваемых данных, заголовок сообщения может быть сформирован с учётом объёма PADDING. Получатель сообщения дешифрует всё поле данных и получает исходную информацию, затем вычисляет истинное значение RECORD-LENGTH, при этом PADDING из поля «данные» удаляется.

Формат информационных записей SSL

Часть данных рекорда SSL состоит из 3 компонентов:

MAC-DATA — код аутентификации сообщенияMAC-SIZE — функция используемого алгоритма вычисления хеш-суммыACTUAL-DATA — реально переданные данные или поле данных сообщенияPADDING-DATA — данные PADDING (при блочном шифровании)

Здесь SECRET передается хеш-функции первым, затем следует ACTUAL-DATA и PADDING-DATA, за которыми передается SEQUENCE-NUMBER — порядковый номер. Значение SECRET зависит от того, кто именно посылает сообщение. Если это делает клиент, то SECRET равен CLIENT-WRITE-KEY. Если же клиент получает сообщение, SECRET равен CLIENT-READ-KEY. Порядковый номер представляет собой 32-битовый код, который передается хеш-функции в виде 4 байт, используя сетевой порядок передачи «от старшего к младшему». Порядковый номер — счетчик для сервера или клиента. Для каждого направления передачи используется пара счетчиков — для отправителя и для получателя; каждый раз, когда отправляется сообщение, счетчик увеличивает своё значение на 1. Получатель сообщения использует ожидаемое значение порядкового номера для передачи MAC (тип хеш-функции определяется параметром CIPHER-CHOICE). Вычисленное значение MAC-DATA должно совпадать с переданным значением. Если сравнение не прошло, сообщение считается поврежденным, что приводит к возникновению ошибки, которая вызывает закрытие соединения. Окончательная проверка соответствия выполняется, когда используется блочный шифр. Объём данных в сообщении (RECORD-LENGTH) должен быть кратен размеру блока шифра. Если данное условие не выполнено, сообщение считается поврежденным, что приводит к разрыву соединения.

Для 2-байтового заголовка максимальная длина сообщения равно 32767 байтов, для 3-байтового 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL, а сообщения прикладного протокола могут занимать несколько рекордов SSL.

Протокол диалога SSL

Протокол диалога SSL содержит 2 основные фазы.

Первая фаза используется для установления конфиденциального канала коммуникаций. Эта фаза инициализирует соединение, когда оба партнёра обмениваются сообщениями «hello». Клиент посылает сообщение CLIENT-HELLO. Сервер получает это сообщение, обрабатывает его и посылает в ответ сообщение SERVER-HELLO. В этот момент и сервер и клиент имеют достаточно информации, чтобы знать, нужен ли новый master key. Если ключ не нужен, сервер и клиент переходят в фазу 2. Когда возникает необходимость создания нового master key, сообщение сервера SERVER-HELLO уже содержит достаточно данных для того, чтобы клиент мог сгенерировать master key. В эти данные входят подписанный сертификат сервера, список базовых шифров и идентификатор соединения (случайное число, сгенерированное сервером, которое используется на протяжении всей сессии). После генерации клиентом master key он посылает серверу сообщение CLIENT-MASTER-KEY или же сообщение об ошибке, когда клиент и сервер не могут согласовать базовый шифр. После определения master key сервер посылает клиенту сообщение SERVER-VERIFY, которое аутентифицирует сервер.

Фаза 2 называется фазой аутентификации. Так как сервер уже аутентифицирован на первой фазе, то на второй фазе осуществляется аутентификация клиента. Сервер отправляет запрос клиенту, и если у клиента есть необходимая информация — он присылает позитивный отклик, если же нет — сообщение об ошибке. Когда один партнёр выполнил аутентификацию другого партнёра — он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация была неудачной, сервер посылает сообщение ERROR. Когда один из партнёров послал сообщение finished — он должен принимать сообщения до тех пор, пока не получит сообщение finished от другого партнёра, и только когда оба партнёра послали и получили сообщения finished, протокол диалога SSL закончит свою работу. С этого момента начинает работу прикладной протокол.

Типовой протокол обмена сообщениями

Client-hello C ® S: challenge, cipher_specs

Server-hello S ® C: connection-id,server_certificate,cipher_specs

Идентификатор сессии найден клиентом и сервером

Client-hello C ® S: challenge, session_id, cipher_specs

Server-hello S ® C: connection-id, session_id_hit

Использован идентификатор сессии и аутентификация клиента

SSL поддерживает 3 типа аутентификации:

Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отозван. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима для такой атаки. Анонимный сервер не может аутентифицировать клиента. Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).

Анонимный обмен ключами

Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнаёт из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).

Аутентификация и обмен ключами при использовании RSA

В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS (???). Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает приватный ключ, соответствующий сертификату сервера.

Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывает значение, вычисленное из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия (???).

Аутентификация и обмен ключами при использовании Diffie-Hellman

В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу.

Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

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

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

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

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

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

Сообщение изменения шифра посылается клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение «finished».

Один из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения.

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