Технический обзор Schannel SSP

Статья
09/02/2016

Опубликовано: Август 2016

Применимо к: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

В этом справочном разделе для ИТ-специалистов объясняется, что такое поставщик поддержки безопасности (SSP) безопасного канала (Schannel) и какие службы проверки подлинности он предоставляет с помощью протоколов TLS и SSL.

Эта статья содержит следующие разделы.

Что такое TLS, SSL и Schannel
Общие сценарии TLS и SSL
Schannel SSP Technical Overview
Зависимости TLS и SSL

Примечание

Протокол TLS описывается в разделе Протокол безопасности уровня транспорта.

Протокол DTLS, включенный в Schannel SSP, описывается в разделе Протокол безопасности транспортного уровня датаграмм.

Что такое TLS, SSL и Schannel

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

Протоколы TLS, SSL, DTLS и PCT) основаны на шифровании с открытым ключом. Эти протоколы входят в набор протоколов проверки подлинности Schannel. Все протоколы Schannel используют модель клиента и сервера. Список поддерживаемых протоколов см. в разделе Поддерживаемые комплекты шифров и протоколы в поставщике поддержки безопасности Schannel.

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

Для проверки подлинности серверов на клиентах TLS/SSL не требует, чтобы ключи сервера хранились в контроллерах домена или в базе данных, например в доменных службах Active Directory. Клиенты подтверждают правильность учетных данных сервера с помощью сертификатов доверенного корневого центра сертификации (ЦС), которые загружаются при установке операционной системы Windows Server. Таким образом, если сервер не требует проверки подлинности пользователя, пользователи могут не создавать учетные записи перед созданием безопасного соединения с сервером.

Журнал и стандарты для TLS и SSL

Протокол SSL был разработан корпорацией Netscape Communications в 1994 году для защиты транзакций через Интернет. Вскоре после этого рабочая группа IETF приступила к разработке стандартного протокола, предоставляющего те же функциональные возможности. Они использовали SSL 3.0 как основу для этой работы, которая в итоге вылилась в протокол TLS. Реализация протокола TLS начиная с Windows Server 2003 точно соответствует спецификации, определенной в следующих спецификациях из базы данных RFC IETF:

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

Различия между протоколами TLS и SSL

Хотя существуют некоторые различия между SSL 3.0 и версиями TLS, в этом справочном руководстве рассматривается обобщенный протокол TLS/SSL.

Примечание

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

Поскольку протокол SSL был уязвим для возросшего числа атак на систему безопасности, группа IETF разработала интернет-стандарты для более безопасного протокола TLS. В следующем списке приведены усовершенствования TLS, выходящие за рамки возможностей протокола SSL по защите взаимодействия по ненадежным сетям.

Алгоритм кода проверки подлинности сообщения с использованием хэширования с ключом (HMAC) заменяет алгоритм кода проверки подлинности сообщения (MAC) в SSL.
Протокол TLS стандартизован и является стандартом Интернета, а протокол SSL имеет множество вариантов.
TLS содержит дополнительные сообщения оповещений.
SSL требует сертификаты, выданные корневым ЦС (или привязанные к корневому ЦС). При использовании TLS не всегда требуется включать сертификаты, привязанные к корневому ЦС. Можно использовать промежуточный ЦС.
Алгоритмы Fortezza не включены в RFC TLS, поскольку они не открыты для общего просмотра.

Преимущества TLS и SSL

Протокол TLS/SSL предоставляет множество преимуществ по сравнению с использованием других методов проверки подлинности для клиентов и серверов. Некоторые из этих преимуществ описаны в следующей таблице.

Преимущество	Описание
Надежная проверка подлинности, конфиденциальность сообщений, целостность данных.	Протокол TLS/SSL помогает безопасно передавать данные с использованием шифрования. TLS/SSL проверяет подлинность серверов и при необходимости проверяет подлинность клиентов, чтобы подтвердить удостоверения систем, участвующих в безопасном взаимодействии. Он также обеспечивает целостность данных с помощью значения проверки целостности. Помимо защиты от раскрытия данных протокол безопасности TLS/SSL используется для защиты от атак маскировки, атак типа "злоумышленник в середине", атак с откатом и атак с повтором.
Взаимодействие	Протокол TLS/SSL работает с большинством веб-браузеров и в большинстве операционных систем и веб-серверов. Он часто интегрирован в средства чтения новостей, в серверы LDAP и во множество других приложений, имеющихся на рынке.
Гибкость алгоритма	Протокол TLS/SSL предоставляет параметры для механизмов проверки подлинности, алгоритмов шифрования и алгоритмов хэширования, которые используются во время безопасного сеанса.
Простота развертывания	Многие приложения прозрачно используют протокол TLS/SSL в операционных системах Windows Server. С помощью TLS вы можете более безопасно просматривать веб-страницы при использовании Internet Explorer и Internet Information Services (IIS). Если сервер уже имеет установленный сертификат сервера, то вам достаточно установить флажок в Internet Explorer.
Простота использования	Поскольку протокол TLS/SSL реализуется на уровне приложения, большая часть его операций полностью невидима для клиентского компьютера. Это позволяет клиенту защищаться от злоумышленников, почти ничего не зная о безопасности обмена данными.

Ограничения TLS и SSL

Существуют некоторые ограничения использования протокола. Они показаны в следующей таблице.

Ограничение	Описание
Увеличение нагрузки процессора	Это самое существенное ограничение для реализации TLS/SSL. Шифрование (в частности операции с открытым ключом) сильно нагружает процессор. В результате при использовании протокола SSL меняется производительность. К сожалению, нет способа узнать, насколько снизится производительность. Производительность меняется в зависимости от частоты подключений и их длительности. Больше всего ресурсов TLS использует при установке соединений.
Административные издержки	Среда TLS/SSL сложна и требует обслуживания. Системный администратор должен настроить систему и управлять сертификатами.

Увеличение нагрузки процессора

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

Административные издержки

Среда TLS/SSL сложна и требует обслуживания. Системный администратор должен настроить систему и управлять сертификатами.

Общие сценарии TLS и SSL

Многие считают, что протоколы TLS и SSL используются для более безопасной работы в Интернете через веб-браузеры. Однако они также являются протоколами общего назначения, которые можно использовать всегда, когда требуется проверка подлинности и защита данных. Фактически возможность доступа к этим протоколам через интерфейс поставщика служб безопасности (SSPI) означает, что их можно использовать практически для любого приложения. Многие приложения изменяются, чтобы использовать преимущества функций протокола TLS/SSL. В следующей таблице приведены примеры использования TLS/SSL.

Сценарий	Описание
Транзакции SSL c веб-сайтом электронной коммерции	Это сценарий типичного использования SSL между браузером и веб-сервером. Например, имеется торговый сайт электронной коммерции, где покупатели должны предоставлять номера своих кредитных карт. Протокол сначала подтверждает, что сертификат веб-сайта правильный, а затем отправляет сведения о кредитной карте в виде зашифрованного текста. Для этого типа транзакций, когда сертификат сервера поступает из надежного источника, проверка подлинности выполняется только для сервера. Необходимо включить TLS/SSL для веб-страницы, где происходят транзакции данных, например для страницы с формой заказа.
Доступ клиента, прошедшего проверку подлинности, к веб-сайту, защищенному протоколом SSL	Клиент и сервер должны иметь сертификаты из взаимно доверенного центра сертификации (ЦС). С помощью Schannel SSP можно сопоставить клиентские сертификаты с учетными записями пользователей или компьютеров в операционной системе Windows Server по принципу "один к одному" или "многие к одному". Затем ими можно управлять с помощью оснастки "Active Directory — пользователи и компьютеры", и пользователи могут проходить проверку подлинности на веб-сайте без пароля. Сопоставление "многие к одному" имеет несколько назначений. Например, если вы хотите предоставить нескольким пользователям доступ к конфиденциальным данным, можно создать группу, сопоставить сертификаты пользователей с этой группой, а затем предоставить этой группе необходимые разрешения для данных. При сопоставлении "один к одному" сервер имеет копию сертификата клиента, и когда пользователь входит с клиентского компьютера, сервер проверяет их идентичность. Это сопоставление "один к одному" обычно используется для частных данных: например, на веб-сайте банковских операций, где только один пользователь имеет право просматривать личный счет.
Удаленный доступ.	При удаленной работе часто используется Schannel SSP. С помощью этой технологии можно обеспечить проверку подлинности и защиту данных при удаленном входе пользователей в операционные системы Windows или сети. Пользователи получают более безопасный доступ к своей электронной почте или к корпоративным приложениям из дома или в пути, что снижает риск раскрытия информации посторонним лицам в Интернете.
Доступ к SQL Server	Вы можете требовать проверку подлинности клиентского компьютера, когда он подключается к серверу SQL Server. На клиенте или на сервере можно настроить требование шифрования данных, передаваемых между ними. Очень конфиденциальные сведения, такие как финансовые или медицинские базы данных, можно защитить для предотвращения несанкционированного доступа и раскрытия информации по сети.
Электронная почта	При использовании Exchange Server с помощью Schannel SSP можно защищать данные при их перемещении с сервера на сервер в интрасети или в Интернете. Для полной сквозной безопасности может потребоваться использование S/MIME. Однако помощь в защите данных при их передаче между серверами позволяет компаниям использовать Интернет для безопасной передачи почты между подразделениями компании, дочерними компаниями и партнерами. Это можно делать независимо от того, используется ли S/MIME.

Архитектура Schannel SSP

В операционных системах Windows Server набор протоколов проверки подлинности Schannel содержит TLS. На следующей схеме показано место Schannel SSP среди этих и других технологий. Клиентские или серверные приложения используют Secur32.dll посредством вызовов SSPI для взаимодействия со службой LSASS.

Архитектура Schannel SSP

Schannel Architecture

В следующей таблице приводятся описания элементов, участвующих в TLS/SSL.

Элементы подсистемы безопасности, используемые в проверке подлинности TLS и SSL

Элемент	Описание
Schannel.dll	Протокол проверки подлинности TLS/SSL. Этот протокол обеспечивает проверку подлинности через зашифрованный канал вместо менее безопасного открытого канала.
Lsasrv.dll	LSASS обеспечивает применение политик безопасности и действует как диспетчер пакетов безопасности для локальной системы безопасности.
Netlogon.dll	В отношении службы TLS служба Netlogon передает сведения о сертификате пользователя через канал SSL в контроллер домена для сопоставления сертификата пользователя с учетной записью пользователя.
Secur32.dll	Поставщик нескольких методов проверки подлинности, который реализует SSPI.

Набор протоколов проверки подлинности обеспечивается Schannel SSP, который поддерживается программным интерфейсом (API) SSPI, предоставляющим службы безопасности для операционных систем Windows Server.

Интерфейс поставщика поддержки безопасности Майкрософт (SSPI) является основой для проверки подлинности в операционной системе Windows. Таким образом, приложения и службы инфраструктуры, требующие проверку подлинности, используют SSPI для ее предоставления. Когда клиент и сервер должны пройти проверку подлинности для более безопасного взаимодействия, запросы проверки подлинности направляются в SSPI, который выполняет процесс проверки подлинности независимо от используемого сетевого протокола. SSPI — это реализация API универсальной службы безопасности (GSSAPI). Дополнительные сведения о GSSAPI см. в следующих документах RFC в базе данных RFC IETF.

Сведения об архитектуре SSPI для всех SSP и о месте поставщика Kerberos в этой архитектуре см. в разделе Security Support Provider Interface Architecture.

Schannel SSP можно использовать для доступа к веб-службам, таким как электронная почта или персональные данные, которые предоставляются на веб-страницах. Schannel SSP использует сертификаты открытого ключа для проверки подлинности сторон. Он включает четыре протокола проверки подлинности. При проверке подлинности сторон он выбирает один из четырех протоколов в следующем порядке:

TLS версии 1.2;
TLS версии 1.1;
TLS версии 1.0;
SSL версии 3.0.

Затем Schannel SSP выбирает наиболее подходящий протокол проверки подлинности, который может поддерживать и клиент, и сервер. Например, если сервер поддерживает все четыре протокола Schannel, а клиентский компьютер поддерживает только SSL 3.0, поставщик Schannel использует для проверки подлинности протокол SSL 3.0.

Работа с доверенными издателями для проверки подлинности клиента

До выхода Windows Server 2012 и Windows 8 приложения или процессы, которые использовали Schannel SSP (включая HTTP.sys и IIS), могли предоставлять список доверенных издателей, поддерживаемых для проверки подлинности клиента. Эта информация предоставлялась в виде списка доверия сертификатов (CTL).

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

В Windows Server 2012 и Windows 8 были внесены следующие изменения в базовый процесс проверки подлинности.

Управление списком доверенных издателей на основе списка доверия сертификатов больше не поддерживается.
Действие отправки списка доверенных издателей по умолчанию отключено. Раздел реестра SendTrustedIssuerList теперь по умолчанию имеет значение 0 (отключено по умолчанию) вместо 1.
Совместимость с предыдущими версиями операционных систем Windows сохранена.

Это обеспечивает знакомую управляемость с помощью существующих командлетов управления сертификатами в поставщике PowerShell, а также с помощью программ командной строки, таких как certutil.exe. Хотя максимальный размер списка доверенных центров сертификации (16 КБ), поддерживаемых Schannel SSP, остается таким же, как и в Windows Server 2008 R2, в Windows Server 2012 существует новое выделенное хранилище сертификатов для издателей проверки подлинности клиентов, поэтому несвязанные сертификаты не включаются в сообщение клиента или сервера.

Принцип работы

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

Если существует конкретное хранилище учетных данных, настроенное для сайта, оно будет использоваться в качестве источника.
Если в хранилище, определяемом приложением, отсутствуют сертификаты, Schannel проверяет хранилище издателей проверки подлинности клиента на локальном компьютере. Если сертификаты присутствуют, Schannel использует это хранилище в качестве источника.
Если сертификатов нет ни в локальном, ни в глобальном хранилище, Schannel SSP будет использовать хранилище Доверенные корневые центры сертификациив качестве источника списка доверенных издателей. (Это поведение также присутствует в Windows Server 2008 R2.)

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

Если хранилище Доверенные корневые центры сертификации содержит сочетание корневых (самозаверяющих) сертификатов и сертификатов издателя центра сертификации (ЦС), на сервер по умолчанию будут отправляться только сертификаты издателя ЦС.

Настройка Schannel для использования хранилища сертификатов доверенных издателей

Архитектура Schannel SSP будет по умолчанию использовать хранилища, как описано выше, для управления списком доверенных издателей. Для управления сертификатами вы по-прежнему можете использовать существующие командлеты управления сертификатами в поставщике PowerShell, а также программы командной строки, например certutil.exe.

Сведения об управлении сертификатами с помощью поставщика Windows PowerShell см. в разделе Командлеты управления службой сертификации Active Directory в Windows.

Сведения об управлении сертификатами с помощью программы сертификатов см. в разделе certutil.exe.

Сведения о том, какие данные (включая заданное приложением хранилище) определяются в качестве учетных данных Schannel, см. в разделе Структура SCHANNEL_CRED (Windows).

Настройка приложения или компонента для использования хранилища издателей проверки подлинности клиента

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

Например, веб-сервер HTTP.sys, реализующий стек HTTP-сервера Windows, по умолчанию не настроен для использования хранилища издателей проверки подлинности клиента.

Чтобы настроить HTTP. SYS для использования хранилища издателей проверки подлинности клиента, можно использовать следующую команду:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Чтобы найти значения для certhash и appid на сервере, можно использовать следующую команду:

netsh http show sslcert

Значения по умолчанию для режимов доверия

Существует три режима доверия проверки подлинности клиента, поддерживаемых Schannel SSP. Режим доверия управляет тем, как выполняется проверка цепочки сертификатов клиента. Он является параметром системы, который управляется переменной REG_DWORD "ClientAuthTrustMode" в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Значение	Режим доверия	Описание
0	Доверие компьютера (по умолчанию)	Требует, чтобы сертификат клиента выдавался сертификатом из списка доверенного издателя.
1	Монопольное корневое доверие	Требует, чтобы клиентский сертификат был связан с корневым сертификатом, который находится в указанном вызывающей стороной хранилище доверенных издателей. Сертификат также должен быть выдан издателем из списка доверенных издателей.
2	Монопольное доверие ЦС	Требует, чтобы клиентский сертификат был связан либо с сертификатом промежуточного ЦС, либо с корневым сертификатом, содержащимся в указанном вызывающей стороной хранилище доверенного издателя.

Сведения о сбоях проверки подлинности из-за проблем конфигурации в списке доверенных издателей см. в статье 280256 базы знаний Майкрософт.

Зависимости TLS и SSL

Правильное функционирование протоколов TLS и SSL зависит от нескольких связанных технологий и ресурсов. В следующей таблице описаны эти технологии и ресурсы, а также указано, как они связаны с проверкой подлинности TLS/SSL.

Зависимость	Описание
Операционная система	Проверка подлинности TLS и SSL использует функциональные возможности клиента, встроенные в операционные системы Windows Server и клиентские операционные системы Windows. Если клиент или сервер работает под управлением операционной системы, которая не поддерживает TLS/SSL, он не может использовать проверку подлинности TLS/SSL.
Сетевое подключение TCP/IP	Чтобы проверка подлинности TLS и SSL могла выполняться, должно существовать сетевое подключение TCP/IP между клиентом и целевым сервером. Дополнительные сведения см. в разделе TCP/IP.
Домен Active Directory	Если серверное приложение требует проверки подлинности клиента, Schannel SSP автоматически пытается сопоставить сертификат, предоставленный клиентом, с учетной записью пользователя. Вы можете проверять подлинность пользователей, выполняющих вход с сертификатом клиента, вручную создавая сопоставления, связывающие данные сведения с учетной записью пользователя Windows. После создания и включения сопоставления сертификатов каждый раз, когда клиент предоставляет сертификат, серверное приложение автоматически связывает этого пользователя с соответствующей учетной записью пользователя в операционной системе Windows. Если вы хотите использовать сопоставление сертификатов, то должны использовать учетные записи пользователей в доменных службах Active Directory. Дополнительные сведения см. в разделе Обзор доменных служб Active Directory.
Доверенные центры сертификации	Поскольку проверка подлинности основывается на цифровых сертификатах, центры сертификации (ЦС), такие как Verisign или службы сертификации Active Directory, являются важной частью TLS/SSL. ЦС — это сторонняя компания (не Майкрософт) со взаимным доверием, которая подтверждает удостоверение стороны, запросившей сертификат (обычно это пользователь или компьютер), а затем выдает сертификат запросившей стороне. Сертификат привязывает удостоверение запросившей стороны к открытому ключу. Центры сертификации также обновляют и отзывают сертификаты при необходимости. Например, если клиенту предоставляется сертификат сервера, клиентский компьютер может попытаться сравнить ЦС сервера со списком доверенных ЦС клиента. Если выдавший сертификат ЦС входит в этот список, клиент проверит подлинность и целостность сертификата. Дополнительные сведения о центрах сертификации см. в разделе Обзор служб сертификатов Active Directory.

См. также:

Справочные поставщика поддержки безопасности Schannel