Secure Socket Layer (SSL) в настоящее время является, пожалуй, одним из самых популярных протоколов безопасности транспортного уровня, используемых в Интернете. Работая на транспортном уровне стека TCP/IP, он решает следующие задачи:
1. Обеспечивает конфиденциальность данных, т. е. уверенность, что они не были раскрыты в ходе транспортировки между клиентом и сервером, путем шифрования данных всех вышестоящих уровней (представления и прикладного), т. е. оставляет открытой только служебную информацию уровня TCP и ниже.
2. Обеспечивает аутентификацию сервера, т. е. уверенность пользователя (клиента), что он получает доступ именно к тому серверу, к которому необходимо.
3. Опционально может обеспечивать аутентификацию клиента, т. е. обеспечивать уверенность сервера, что он работает с авторизованным клиентом.
4. Обеспечивает целостность передаваемой информации, т. е. уверенность, что информация не была изменена в ходе транспортировки между клиентом и сервером.
5. Опционально может сжимать данные для обеспечения скорости передачи.
Протокол включает в себя два подпротокола – протокол записи (SSL record protocol), определяющий формат передачи данных, и протокол установки связи (SSL handshake protocol), определяющий механизм установки соединения.
Подпротокол SSL-записи
Основная функция протокола записи – работа с данными, поступающими от уровня приложения. На первом этапе производится фрагментирование данных в блоки для дальнейшей обработки (блок 16 384 байта для версии SSL 3.0). Затем производится упаковка (при отправлении) или распаковка (при получении) данных, если эта опция была задана. Далее производится шифрование данных тем алгоритмом, который был определен для клиента и сервера, а также устанавливается аутентификационный код сообщения (англ. message authentication code – MAC) для обеспечения контроля целостности сообщения.
Кроме того, этот подпротокол берет на себя функции генерирования сообщений об ошибках и закрытии сессии. Рассмотрим возможные варианты служебных сообщений, которые представлены в табл. 22.1.
Таблица 22.1. Системные сообщения подпротокола SSL-записи
Сообщение
Значение сообщения
Close_notify
Это нормальное, не связанное с ошибкой, сообщение о закрытии сессии
Unexpected_message
Получено несоответствующее сообщение, которое приводит к закрытию сессии
Bad_record_mac
Получен неверный аутентификационный код сообщения, приводящий к закрытию сессии
Decompressbnjailure
Функция распаковки получила неверное значение, приводит к закрытию сессии
Handshake_failure
Получатель не способен поддержать требуемый отправителем набор параметров безопасности, приводит к закрытию сессии
No_certificate
Нет доступа к сертификату
Bad_certificate
Сертификат поврежден
Unsup-ported_certificate
Данный тип сертификата не поддерживается
Certificate_revoked
Сертификат отозван выпустившим его субъектом
Cert'rficate_expired
Дата действия сертификата истекла или неверна
Certificate_unknown
При обработке данных сертификата возникли прочие неразрешимые проблемы
Illegal_parameter
Поле данных имеет неверное значение, которое приводит к закрытию сессии
Подпротокол установки связи
Протокол установки связи обеспечивает настройку множества криптографических параметров. В момент, когда клиент пытается установить соединение с сервером, обе стороны должны:
1. согласовать версию протокола;
2. согласовать алгоритм шифрования (выбирается наиболее сильный из списка поддерживаемых обеими сторонами);
3. произвести аутентификацию (с обеих сторон или выборочную);
4. с помощью согласованного алгоритма асимметричного шифрования обменяться общим секретом, на основе которого будет производиться симметричное шифрование.
Клиент посылает сообщение Client_hello, в котором указывает версию протокола, случайное число, номер сессии, список поддерживаемых алгоритмов шифрования и список методов компрессии. Сервер отвечает сообщением Server_hello, в котором содержатся те же поля и в них указан выбор сервера из представленных клиентом возможностей. Если сервер должен аутентифицировать себя, он высылает клиенту свой сертификат. В случае если у него нет соответствующего сертификата, он высылает сообщение Server_key_exchange, в котором в зависимости от выбранного алгоритма асимметричного шифрования устанавливается способ передачи открытого ключа сервера.
Если требуется аутентификация клиента, сервер может послать сообщение Certificate_request, запрашивая сертификат клиента. После этого сервер отправляет сообщение Server_hello_done, показывая, что он завершил свою работу и ожидает сообщений от клиента.
Клиент высылает сообщение Client_certificate со своим сертификатом, либо сообщение No_certificate, если у него нет сертификата. Затем клиент высылает сообщение Client_key_exchange, в котором он формирует основу для генерации распределенного секрета для симметричного шифрования. Этот предварительный секрет он шифрует открытым ключом сервера из его сертификата.
Если клиент использовал сертификат для своей аутентификации, то он генерирует сообщение Certificate_verify для подтверждения своего сертификата. После этого клиент формирует сообщение Change_cipher_spec, которое означает, что клиент произвел выбор из списка рассматриваемых параметров шифрования и перенес их в статус текущих. Затем клиент отправляет сообщение Finished, означающее, что этап согласования закончен, при этом это сообщение уже зашифровано в рамках новых параметров шифрования.
Сервер также производит установку текущих параметров шифрования и отвечает сообщениями Change_cipher_spec и Finished (рис. 22.22).
Алгоритмы шифрования и аутентификации, используемые в реализации SSL, представлены в следующем списке:
DES – Data Encryption Standard и Triple-DES;
RC2 и RC4 – Rivest Cipher 2 и Rivest Cipher 4 соответственно;
Кроме того, при отдельных реализациях используются алгоритмы Skipjack и КЕА – Key Exchange Algorithm.
Рис. 22.22. Работа протокола установки связи, опциональные параметры
Различные варианты реализации протокола по убывающей от наиболее к наименее стойкой в криптографическом смысле конфигурации показаны в табл. 22.2. Данные представлены по состоянию до снятия ограничения на вывоз криптографии с длиной ключа более 40 бит из США.
Таблица 22.2. Параметры шифрования протокола SSL
В заключение рассмотрим процессы проверки цифрового сертификата сервера клиентом и аутентификации клиента сервером.
Когда клиент получает цифровой сертификат сервера, он проверяет следующие параметры:
1. Срок действия сертификата: попадает ли текущая дата в этот период, если нет – процесс обработки прекращается, если да – переходит дальше.
2. Находится ли субъект, выпустивший сертификат (СА – Certification Authority), в списке доверенных СА клиента. Каждый клиент поддерживает список доверенных СА. Если субъект отсутствует в списке – сервер не аутентифицируется.
3. Используя открытый ключ СА из списка доверенных СА, клиент проверяет корректность электронно-цифровой подписи на сертификате сервера. Если подпись некорректна, то предполагается, что сертификат был изменен и не принимается.
4. Проверяется соответствие имени сервера (англ. domain name), указанного в сертификате, реальному имени сервера. Если они совпадают – сервер аутентифицирован.
Если сервер сконфигурирован таким образом, что он требует аутентификации клиента, процесс происходит следующим образом:
1. Сервер и клиент совместно генерируют некое случайное значение, затем клиент устанавливает свою электронно-цифровую подпись на это значение.
2. Сервер проверяет, соответствует ли открытый ключ клиента из сертификата клиента этой электронно-цифровой подписи.
3. Сервер проверяет срок действия сертификата, попадает ли текущая дата в этот период.
4. Сервер проверяет, находится ли СА, выпустивший сертификат, в списке доверенных СА сервера. Каждый сервер поддерживает список доверенных СА.
5. Используя открытый ключ СА из списка доверенных СА, сервер проверяет корректность электронно-цифровой подписи на сертификате клиента.
6. Сервер проверяет, находится ли сертификат клиента в списке сертификатов клиентов, которые могут быть аутентифицированы данным сервером.
Если аутентификация прошла успешно, сервер производит авторизацию – т. е. проверяет, имеет ли клиент доступ к запрашиваемым ресурсам и в зависимости от правил доступа разрешает или запрещает доступ клиента к ресурсам.
Говоря о SSL, необходимо упомянуть и протокол TLS (Transport Layer Security – Безопасность Транспортного Уровня), который является в отличие от SSL официально опубликованным интернет-стандартом [RFC-2246], и популярность которого, по-видимому, будет расти. В указанном RFC говорится, что между протоколами нет кардинальных различий, и при этом TSL обеспечивает обратную совместимость с SSL. Одним из основных преимуществ TSL следует назвать возможность его встраивания в работу приложений независимыми разработчиками и расширения криптографических возможностей.
