Программирование серверных приложений

Мы обсудили SSPI и аутентификацию с учетными записями доверенных объектов Windows с применением протоколов NTLM и Kerberos. Аутентификацию можно также проводить с использованием SSPI посредством цифровых сертификатов. Это делается через SSPI и компонент защиты SChannel, реализующий SSL. Если вы планируете работать с SSL, не забудьте включить в исходные тексты заголовочные файлы Security.h и SChannel.h, а также скомпоновать свой проект с библиотечным файлом Secur32.1ib.
В отличие от рассмотренных нами протоколов SSL ориентируется не столько на аутентификацию клиента сервером, сколько на аутентификацию сервера клиентом. При этом сервер также может аутентифицировать клиента, что позволяет ему заимствовать права. Для начала рассмотрим наиболее распространенный сценарий.
Клиент хочет подключиться к некоторому сайту, вероятней всего в Интернете. Прежде чем передать на сайт важную информацию, он хочет убедиться, что взаимодействует с нужным субъектом. Сервер посылает клиенту свой сертификат, который подписан и содержит открытый ключ из пары открытого/ закрытого ключа.
Клиент может узнать из сертификата, кто его издал, и решить, доверять ли ему. Если он доверяет соответствующему центру сертификации, он считает, что информация в сертификате имеет силу. После проверки сертификата клиент может прочитать содержащуюся в нем информацию, такую как URL сервера, и сравнить с той, что предоставил взаимодействующий с ним сервер. При успешном сравнении клиент может быть спокоен: он связался с нужным ему сервером.
В модели сертификатов остается много не проработанных вопросов. Как на самом деле клиентское ПО доверяет информации в сертификате? Правильно ли переносить принятие решения о доверии с клиентского ПО на пользователя (человека)? Как передается информация? Какие корневые центры являются доверенными? Может ли пользователь выбирать эти центры сертификации? Можно ли доверять всем центрам в отношении всех типов сертификатов? Нужно ли, чтобы центры сертификации были привязаны к конкретным областям деятельности, например, медицине или розничной торговле? Ответы на эти вопросы будут проясняться по мере роста технологии. Сейчас же я сосредоточусь на технике применения сертификатов.
В зависимости от среды, спроектированной вами для защищенного обмена данными, вы можете решить стать собственным центром сертификации. Microsoft Certificate Services позволит вам выпускать собственные сертификаты, и, поскольку ваши клиенты доверяют вашему центру, вы сможете создавать сертификаты, соответствующие вашим конкретным стандартам.
С собственным центром сертификации вы даже сможете пойти на то, чтобы «прошивать» сертификаты вашего центра в коде клиентских программ. Когда клиент соединится с сервером, вы сможете использовать эти явные доверительные отношения для инициации сеанса, а затем для генерации клиентского сертификата (клиент сгенерирует закрытый ключ и передаст открытый ключ серверу). Сервер с помощью этого открытого ключа сгенерирует сертификат в собственном центре и сохранит нужную информацию. После этого при каждом соединении клиента с сервером они могут использовать открытые ключи друг друга (в виде сертификатов) для быстрой взаимной аутентификации и согласования сеансового ключа, что позволит им сразу перейти к обмену данными.
Признав сертификат сервера, клиент может извлечь из сертификата открытый ключ, зашифровать им симметричный сеансовый ключ и послать его серверу. Сервер — единственная сущность, у которой есть соответствующий закрытый ключ, так что он сможет расшифровать сеансовый ключ. Теперь клиент и сервер могут обмениваться данными, будучи уверенными, что они взаимодействуют с кем нужно.
В стандартных сценариях, требующих защищенного обмена данными, браузер или другой клиент посылает через сеть клиенту информацию о кредитной карте или другие конфиденциальные данные. Для подобного рода транзакций можете использовать SSPI, чтобы работать по протоколу SSL.