Поделиться через


Интегрированная проверка подлинности Windows с расширенной защитой

Были добавлены улучшения, которые влияют на обработку встроенной проверки подлинности Windows в HttpWebRequest, HttpListener, SmtpClient, SslStream, NegotiateStream и связанных классах в System.Net и соответствующих пространствах имен. Была добавлена поддержка расширенной защиты для повышения безопасности.

Эти изменения могут влиять на приложения, которые используют эти классы для создания веб-запросов и получения ответов, в которых используется встроенная проверка подлинности Windows. Это изменение также может повлиять на веб-серверы и клиентские приложения, в которых используется встроенная проверка подлинности Windows.

Эти изменения могут также влиять на приложения, которые используют эти классы для создания других типов запросов и получения ответов, в которых используется встроенная проверка подлинности Windows.

Изменения для поддержки расширенной защиты будут доступны только для приложений в Windows 7 и Windows Server 2008 R2. Функции расширенной защиты недоступны в более ранних версиях Windows.

Обзор

Структура встроенной проверки подлинности Windows позволяет формировать универсальные ответы на некоторые запросы учетных данных. Это означает, что эти ответы можно повторно использовать или перенаправлять. Ответы на запросы должны обязательно содержать сведения о целевом объекте, а также могут содержать некоторые сведения о канале. Кроме того, службы могут предоставлять расширенную защиту, чтобы в ответах на запросы учетных данных также содержались сведения о службе, например имя субъекта-службы. С включением этих сведений в ответы на запросы учетных данных службы могут обеспечить лучшую защиту при изменении ответов на запросы учетных данных злоумышленниками.

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

Общие цели улучшения таковы.

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

  2. Обновленные серверы, которые правильно настроены, могут проверять сведения о привязке для канала и службы, если эти сведения содержатся в маркере проверки подлинности клиента, и отклонять попытки проверки подлинности, если привязки каналов не совпадают. В зависимости от сценария развертывания серверы могут проверять привязку канала, привязку службы или обе привязки.

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

Сведения, используемые для расширенной защиты, включают в себя один или оба следующих компонента:

  1. Маркер привязки канала.

  2. Сведения о привязке службы в виде имени субъекта-службы.

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

  • Значение имени субъекта-службы должно быть доступно на сервере, выполняющем проверку подлинности клиента, в виде открытого текста.

  • Значение имени субъекта-службы является открытым.

  • Имя субъекта-службы должно быть криптографически защищено во время передачи, чтобы его было невозможно вставить, удалить или изменить с помощью атаки "человек посередине".

Маркер привязки канала — это свойство внешнего безопасного канала (например, TLS), которое используется для привязки этого канала к обмену данными во внутреннем канале, проверку подлинности которого выполнил клиент. Маркер привязки канала должен иметь следующие свойства (эти свойства также определяются в стандарте RFC 5056, принятом IETF):

  • При наличии внешнего канала значение маркера привязки канала должно определять внешний канал или конечную точку сервера. Маркер привязки канала должен быть получен обеими сторонами обмена (клиентской и серверной) независимо друг от друга.

  • Злоумышленник не должен иметь возможность повлиять на значение маркера привязки канала.

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

  • Целостность маркера привязки канала должна быть криптографически защищена во время передачи, чтобы его значение было невозможно вставить, удалить или изменить с помощью атаки "человек посередине".

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

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

Несколько компонентов в пространствах имен System.Net и System.Net.Security выполняют встроенную проверку подлинности Windows от имени вызывающего приложения. В этом разделе описаны изменения в компонентах System.Net для добавления расширенной защиты при использовании встроенной проверки подлинности Windows в этих компонентах.

Расширенная защита поддерживается в Windows 7. Предоставляется механизм, с помощью которого приложение может определить, поддерживает ли операционная система расширенную защиту.

Изменения для поддержки расширенной защиты

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

Пространство имен System.Security.Authentication.ExtendedProtection обеспечивает поддержку проверки подлинности для приложений с использованием расширенной защиты. Класс ChannelBinding в этом пространстве имен представляет привязку каналов. Класс ExtendedProtectionPolicy в этом пространстве имен представляет политику расширенной защиты, используемую сервером для проверки входящих клиентских подключений. Другие члены класса используются с расширенной защитой.

Для серверных приложений к таким классам относятся следующие:

Класс ExtendedProtectionPolicy, содержащий следующие элементы:

  • Свойство OSSupportsExtendedProtection, которое указывает, поддерживает ли операционная система встроенную проверку подлинности Windows с расширенной защитой.

  • Значение PolicyEnforcement, указывающее, когда следует применять расширенную политику защиты.

  • Значение ProtectionScenario, которое указывает сценарий развертывания. Это влияет на проверку расширенной защиты.

  • Необязательный объект ServiceNameCollection, содержащий пользовательский список имен субъектов-служб, который используется для проверки имени субъекта-службы, предоставленного клиентом в виде целевого объекта проверки подлинности.

  • Необязательный объект ChannelBinding, содержащий пользовательскую привязку канала, используемую при проверке. Этот сценарий не является наиболее распространенным.

Пространство имен System.Security.Authentication.ExtendedProtection.Configuration обеспечивает поддержку настройки проверки подлинности для приложений с использованием расширенной защиты.

В существующем пространстве имен System.Net были изменены некоторые функции для поддержки расширенной защиты. В число этих изменений входят следующие.

  • В пространство имен System.Net добавлен новый класс TransportContext, который представляет контекст транспорта.

  • В класс HttpWebRequest добавлены новые перегрузки методов EndGetRequestStream и GetRequestStream, которые позволяют получить TransportContext для поддержки расширенной защиты клиентских приложений.

  • Дополнения к классам HttpListener и HttpListenerRequest для поддержки серверных приложений.

Была изменена функция для поддержки расширенной защиты для клиентских приложений SMTP в существующем пространстве имен System.Net.Mail:

  • Свойство TargetName в классе SmtpClient, которое представляет имя участника-службы, используемое для проверки подлинности при использовании расширенной защиты для клиентских приложений SMTP.

В существующем пространстве имен System.Net.Security были изменены некоторые функции для поддержки расширенной защиты. В число этих изменений входят следующие.

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

  • В класс NegotiateStream добавлены новые перегрузки методов BeginAuthenticateAsServer и AuthenticateAsServer, которые позволяют передавать ExtendedProtectionPolicy для поддержки расширенной защиты серверных приложений.

  • Новое свойство TransportContext в классе SslStream для поддержки расширенной защиты клиентских и серверных приложений.

В пространство имен System.Net.Security добавлено свойство SmtpNetworkElement для поддержки настройки расширенной защиты для клиентов SMTP.

Расширенная защита для клиентских приложений

Для большинства приложений расширенная защита поддерживается автоматически. Классы HttpWebRequest и SmtpClient поддерживают расширенную защиту, если базовая версия Windows поддерживает расширенную защиту. Экземпляр HttpWebRequest отправляет имя участника-службы, сформированное из Uri. По умолчанию экземпляр SmtpClient отправляет имя участника-службы, сформированное из имени узла на почтовом сервере SMTP.

Для пользовательской проверки подлинности клиентские приложения могут использовать методы HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) или HttpWebRequest.GetRequestStream(TransportContext) в классе HttpWebRequest, которые позволяют получить TransportContext и маркер привязки канала с помощью метода GetChannelBinding.

Имя субъекта-службы для встроенной проверки подлинности Windows, которое отправляется экземпляром HttpWebRequest в заданную службу, можно переопределить, задав свойство CustomTargetNameDictionary.

Свойство TargetName можно использовать для установки пользовательского имени субъекта-службы, которое будет использоваться во встроенной проверке подлинности Windows для соединения SMTP.

Расширенная защита для серверных приложений

HttpListener автоматически предоставляет механизмы для проверки привязок службы при проверке подлинности HTTP.

Наиболее безопасный сценарий — включение расширенной защиты для префиксов HTTPS://. В этом случае задайте HttpListener.ExtendedProtectionPolicyExtendedProtectionPolicy значение с PolicyEnforcement заданным значением WhenSupported или Alwaysзначением ProtectionScenarioTransportSelected A WhenSupported , которое помещает HttpListener в частично затверденный режим, в то время как Always соответствует полностью защищенному режиму.

В этой конфигурации при выполнении запроса к серверу с помощью внешнего безопасного канала у внешнего канала запрашивается привязка канала. Эта привязка канала передается вызовам проверки подлинности SSPI, которые проверяют соответствие переданной привязки и привязки канала в BLOB-объекте проверки подлинности. Существует три возможных результата:

  1. Базовая операционная система сервера не поддерживает расширенную защиту. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя.

  2. Если вызов SSPI завершается неудачно, это означает, что либо клиент предоставил привязку канала, которая не соответствует ожидаемому значению привязки, полученному из внешнего канала, либо клиенту не удалось предоставить привязку канала при настройке политики расширенной защиты на сервере для Always. В обоих случаях запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя.

  3. Клиент указывает правильную привязку канала или получает возможность подключиться без указания привязки канала, так как политика расширенной защиты на сервере настроена со свойством WhenSupported. Запрос возвращается приложению для обработки. Имена служб не проверяются автоматически. Приложение может выполнить собственную проверку имени службы с помощью свойства ServiceName, но в таких обстоятельствах это действие является избыточным.

Если приложение выполняет собственные вызовы SSPI для проверки подлинности на основе BLOB-объектов, передаваемых в тексте HTTP-запроса, и хочет поддерживать привязки каналов, приложение должно получить ожидаемую привязку канала из внешнего безопасного канала с помощью HttpListener и передать ее собственной функции Win32 AcceptSecurityContext. Для этого используйте свойство TransportContext и вызовите метод GetChannelBinding для получения маркера привязки канала. Поддерживаются только привязки конечной точки. Если указано что-то иное, кроме Endpoint, будет выдано исключение NotSupportedException. Если базовая операционная система поддерживает привязки каналов, метод GetChannelBinding будет возвращать объект ChannelBindingSafeHandle, в котором содержится указатель на привязку канала, который можно передать функции AcceptSecurityContext в качестве элемента pvBuffer структуры SecBuffer, передаваемой в параметре pInput. Свойство Size содержит длину привязки канала в байтах. Если базовая операционная система не поддерживает привязки каналов, функция возвращает null.

Другой возможный сценарий — включение расширенной защиты для префиксов HTTP://, когда прокси не используются. В этом случае задайте HttpListener.ExtendedProtectionPolicyExtendedProtectionPolicy значение с PolicyEnforcement заданным значением WhenSupported или Alwaysзначением ProtectionScenarioTransportSelected A WhenSupported , которое помещает HttpListener в частично затверденный режим, в то время как Always соответствует полностью защищенному режиму.

По умолчанию список допустимых имен служб создается на основе префиксов, которые были зарегистрированы с HttpListener. Для просмотра списка по умолчанию можно использовать свойство DefaultServiceNames. Если этот список не является исчерпывающим, приложение может указать пользовательскую коллекцию имен служб в конструкторе класса ExtendedProtectionPolicy, и эта коллекция будет использоваться вместо списка имен служб по умолчанию.

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

  1. Базовая операционная система сервера не поддерживает расширенную защиту. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя.

  2. Базовая операционная система клиента не поддерживает расширенную защиту. В конфигурации WhenSupported попытка проверки подлинности завершится успешно, и запрос будет возвращен в приложение. В конфигурации Always попытка проверки подлинности завершится неудачно. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя.

  3. Базовая операционная система клиента поддерживает расширенную защиту, но в приложении не указана привязка службы. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя.

  4. В клиенте указана привязка службы. Привязка службы сравнивается со списком допустимых привязок службы. Если привязка соответствует списку, запрос возвращается приложению. В противном случае запрос не будет передан в приложение, и клиенту будет автоматически возвращен ответ 401 (Не авторизовано). В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя.

Если этого простого подхода со списком допустимых имен служб недостаточно, приложение может выполнять собственную проверку имени службы, обращаясь к свойству ServiceName. В случаях 1 и 2 выше свойство возвратит null. В случае 3 будет возвращена пустая строка. В случае 4 будет возвращено имя службы, указанное клиентом.

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

См. также