Безопасность транспорта HTTP

Статья
03/30/2023

Если в качестве транспорта используется протокол HTTP, безопасность обеспечивается реализацией протокола SSL (Secure Sockets Layer). Протокол SSL широко используется в Интернете для проверки подлинности службы при подключении клиента, а затем и для обеспечения конфиденциальности (шифрования) канала. В этой статье объясняется, как работает SSL и как она реализована в Windows Communication Foundation (WCF).

Базовый SSL

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

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

Чтобы инициировать безопасный сеанс, клиент отправляет серверу эквивалент приветствия, а также список алгоритмов шифрования, которые могут быть использованы клиентом для подписания, шифрования и расшифровки данных и создания хэшей. В ответ сайт отправляет подтверждение и указывает, какой набор алгоритмов был выбран. В ходе такого первоначального подтверждения оба участника посылают и отправляют специальные слова. Nonce — это случайно созданный фрагмент данных, который используется в сочетании с открытым ключом сайта для создания хэша. Хэш — это новое число, производное от двух чисел с помощью стандартного алгоритма, например SHA1. (Клиент и сайт также обмениваются сообщениями, чтобы согласиться с используемым хэш-алгоритмом.) Хэш является уникальным и используется только для сеанса между клиентом и сайтом для шифрования и расшифровки сообщений. Как клиент, так и служба имеют исходное специальное слово и открытый ключ сертификата, поэтому обе стороны могут создать один и тот же хэш. Следовательно, клиент проверяет хэш, отправленный службой, (а) используя согласованный алгоритм для вычисления хэша из данных и (б) сравнивая его с хэшем, отправленным службой; если хэши соответствуют друг другу, клиент может быть уверен, что хэш не был подделан. После этого клиент может использовать этот хэш в качестве ключа для шифрования сообщения, которое содержит другой, новый хэш. Служба может расшифровать сообщение с помощью хэша и восстановить предпоследний хэш. Теперь накопленная информация (специальные слова, открытый ключ и другие данные) известна обеим сторонам, и они могут создать окончательный хэш (или главный ключ). Окончательный ключ отправляется зашифрованным с использованием предпоследнего хэша. Затем главный ключ используется для шифрования и расшифровки сообщений для остальной части сеанса. Так как клиент и служба используют один и тот же ключ, это также называется ключом сеанса.

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

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

Сертификаты и инфраструктура открытого ключа

Во время подтверждения служба также отправляет свой SSL-сертификат клиенту. В сертификате содержится различная информация, такая как дата истечения срока действия, центр выдачи и универсальный код ресурса (URI) сайта. Клиент сравнивает этот URI с универсальным кодом ресурса, с которым он взаимодействовал изначально, чтобы убедиться, что они соответствуют друг другу, затем клиент проверяет дату и центр выдачи сертификата.

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

Реализация SSL с WCF

Безопасность транспорта HTTP (или SSL) предоставляется внешним образом в WCF. SSL можно реализовать одним из двух способов; при этом выбор способа определяется размещением приложения.

Если вы используете службы IIS (IIS) в качестве узла WCF, используйте инфраструктуру IIS для настройки службы SSL.
При создании локального приложения WCF можно привязать SSL-сертификат к адресу с помощью средства HttpCfg.exe.

Использование служб IIS для безопасности транспорта

IIS 7.0

Сведения о настройке IIS 7.0 в качестве безопасного узла (с помощью SSL) см. в статье Настройка уровня безопасных сокетов в IIS 7.0.

Сведения о настройке сертификатов для использования с IIS 7.0 см. в разделе "Настройка сертификатов сервера" в IIS 7.0.

IIS 6,0

Сведения о настройке IIS 6.0 в качестве безопасного узла (с помощью SSL) см. в разделе "Настройка уровня безопасных сокетов".

Сведения о настройке сертификатов для использования с IIS 6.0 см. в Certificates_IIS_SP1_Ops.

Использование средства HttpCfg для SSL

Если вы создаете локальное приложение WCF, используйте средство HttpCfg.exe .

Дополнительные сведения об использовании средства HttpCfg.exe для настройки порта с сертификатом X.509 см. в статье "Практическое руководство. Настройка порта с помощью SSL-сертификата".