SSL
126ASP.NET --- Безопасность в ASP.NET --- SSL
Технология SSL (Secure Sockets Layer - уровень защищенных сокетов) позволяет шифровать коммуникации через HTTP. Протокол SSL поддерживается широким кругом браузеров и гарантирует, что передача информации между клиентом и веб-сервером не может быть расшифрована злоумышленниками.
SSL необходим для сокрытия важной информации, такой как номера кредитных карт и конфиденциальные сведения внутреннего характера, но также важен и для аутентификации пользователей. Например, если вы создаете страницу регистрации, на которой пользователь отправляет свое имя и пароль, то должны применять SSL для шифрования этой информации. В противном случае злоумышленник сможет перехватить удостоверение пользователя и воспользоваться им для проникновения в систему.
Веб-сервер IIS предоставляет SSL как встроенную, готовую к использованию службу. Поскольку SSL работает под HTTP, его применение не изменяет способа работы с HTTP-запросами. Все шифрование и дешифрацию берут на себя функциональные средства SSL программного обеспечения веб-сервера (в данном случае - IIS). Единственное отличие состоит в том, что адрес, защищенный SSL, начинается с https://, а не http://. Трафик SSL также проходит через другой порт (обычно веб-серверы используют порт 443 для SSL-запросов и порт 80 - для обычных запросов).
Чтобы сервер поддерживал SSL-соединения, он должен иметь установленный сертификат X.509 (название X.509 было выбрано для соответствия стандарту каталогов X.500). Чтобы реализовать SSL, понадобится приобрести сертификат, установить его и соответствующим образом сконфигурировать IIS. Все эти шаги подробно описаны в последующих разделах.
Понятие сертификатов
Прежде чем пересылать важные данные, клиент должен решить, можно ли доверять веб-сайту. Для достижения этой цели были спроектированы сертификаты, которые позволяют частично верифицировать идентичность пользователя. Сертификаты могут быть установлены на компьютере любого типа, но обычно они находятся на веб-серверах.
Организация приобретает сертификат у известного центра сертификации (Certificate Authority - CA) и устанавливает его на своем веб-сервере. Клиент доверяет CA и потому готов доверять информации сертификата, подписанного CA. Эта модель работает достаточно хорошо, т.к. маловероятно, чтобы злоумышленник решился на дополнительные расходы по приобретению и установке фальсифицированного сертификата. Центр сертификации также сохраняет информацию о каждом зарегистрированном пользователе. Однако наличие сертификата никоим образом не гарантирует надежность сервера, безопасность приложения или легитимность бизнеса. В этом смысле область действия сертификатов фундаментально ограничена.
Сам по себе сертификат содержит некоторую идентифицирующую информацию. Он подписывается защищенным ключом CA, что гарантирует его аутентичность и отсутствие модификаций. Промышленный стандартный сертификат, соответствующий X.509v3, включает следующую базовую информацию:
имя, название организации и адрес держателя;
открытый ключ держателя, который будет использоваться для реализации ключа SSL-сеансов для шифрования коммуникаций;
даты проверки сертификата;
серийный номер сертификата.
В дополнение сертификат также может включать специфичную для бизнеса информацию, такую как отрасль промышленности держателя, длительность присутствия его на рынке и т.п. Двумя крупнейшими центрами сертификации являются:
Если функция проверки идентичности CA не нужна (например, если сертификаты используются только в корпоративной сети), можете создать и пользоваться собственными сертификатами, настроив всех клиентов на доверие к ним. Для этого потребуется служба Active Directory и сервер Certificate Server (которые встроены в серверную операционную систему Windows). За более подробной информацией обращайтесь к специальным книгам по администрированию сетей Windows.
Что собой представляет SSL
Как было описано в предыдущем разделе, каждый сертификат включает открытый ключ. Открытый ключ - это часть асимметричной пары ключей. Основная идея в том, что открытый ключ свободно предоставляется всем, кто в нем заинтересован. Соответствующий секретный ключ хранится под замком, и доступен только серверу. Трюк заключается в том, что все, что зашифровано одним из этих ключей, поддается расшифровке с помощью другого. Это значит, что клиент может получить открытый ключ и использовать его для шифрования секретного сообщения, которое может быть расшифровано с помощью соответствующего секретного ключа. Другими словами, клиент может создавать сообщения, которые сможет прочесть только сервер.
Этот процесс называется асимметричным шифрованием, и он является базовым строительным блоком SSL. Важный принцип асимметричного шифрования состоит в том, что реконструировать секретный ключ, анализируя соответствующий ему открытый ключ, невозможно. Сделать это было бы чрезвычайно дорого в плане вычислительных ресурсов (даже сложнее, чем взломать одно из зашифрованных сообщений). Однако асимметричное шифрование также имеет свои ограничения, а именно - оно намного медленнее и генерирует большие по объему сообщения, чем симметричное шифрование.
Симметричное шифрование - это разновидность шифрования, с которым интуитивно знакомо большинство людей. В нем один и тот же секретный ключ используется для шифрования и расшифровки сообщения. Недостаток симметричного шифрования в том, что оба участника должны знать секретное значение для того, чтобы осуществлять обмен сообщениями. Однако передавать эту информацию через Интернет нельзя, поскольку злоумышленники могут перехватить ее и в результате получить возможность расшифровывать все последующие сообщения.
Главный трюк SSL заключается в том, что он комбинирует асимметричное и симметричное шифрование. Асимметричное шифрование используется только при начальной передаче ключа - другими словами, соглашения о секретном значении. Затем это секретное значение применяется для симметричного шифрования последующих сообщений, что гарантирует наилучшую производительность.
Весь процесс работает так, как описано ниже. При этом под клиентом понимается веб-браузер, выполняющийся на машине конечного пользователя, а под сервером - веб-сервер, обслуживающий веб-сайты, к которым пользователь желает получить доступ:
Клиент отправляет запрос на соединение с сервером.
Сервер подписывает свой сертификат и отправляет его клиенту. Это завершает фазу квитирования ("рукопожатия") при обмене.
Клиент проверяет, издан ли сертификат CA, которому он доверяет. Если это так, он переходит к следующему шагу. В сценарии с веб-браузером клиент может предупредить пользователя сообщением о том, что он не распознал CA, и предложить пользователю принять решение о продолжении. Клиент распознает CA, когда его сертификат помещается в хранилище доверенных корневых центров сертификации (Trusted Root Certification Authorities) операционной системы. Сертификаты, находящиеся в этом хранилище, можно просмотреть в Google Chrome щелкнув на кнопке Настройки --> Показать дополнительные настройки --> HTTPS/SSL --> Управление сертификатами --> Доверенные сертификаты:
Клиент сравнивает информацию в сертификате с информацией, присланной сайтом (включая доменное имя и его открытый ключ). Клиент также проверяет, допустим ли сертификат стороны сервера, не был ли он отменен и издан ли он заслуживающим доверия CA. Затем клиент принимает соединение.
Клиент сообщает серверу, какие ключи шифрования он поддерживает для коммуникаций.
Сервер выбирает наибольшую подходящую длину ключа и информирует клиента.
Используя указанную длину ключа, клиент случайным образом генерирует симметричный ключ шифрования. Он будет использован в период транзакции между сервером и клиентом. Это гарантирует оптимальную производительность, поскольку симметричное шифрование намного быстрее асимметричного.
Клиент шифрует ключ сеанса, используя открытый ключ сервера (из сертификата), и затем отправляет серверу зашифрованный ключ сеанса.
Сервер принимает зашифрованный ключ сеанса и расшифровывает его, используя свой защищенный ключ. После этого и клиент, и сервер имеют общий секретный ключ, и могут применять его для шифрования коммуникаций в период, пока длится сеанс.
Обратите внимание, что симметричный ключ генерируется случайным образом и используется только в период действия сеанса. Это ограничивает риск нарушения безопасности. Во-первых, сложнее взломать зашифрованные сообщения с применением криптоанализа, поскольку сообщения из других сеансов использоваться не могут. Во-вторых, даже если ключ будет вычислен злоумышленником, он останется действительным только на период существования одного сеанса.
Другой интересный момент связан с тем, что клиент должен генерировать симметричный ключ. Дело в том, что у клиента имеется открытый ключ сервера, который может быть использован для шифрования сообщений, доступных для чтения только серверу. У сервера нет соответствующей информации о клиенте, и потому он не может зашифровать сообщение. Это также означает, что если клиент предоставит ненадежный ключ, все взаимодействие окажется под угрозой. Например, в старых версиях браузера Netscape для создания симметричного ключа применялся слабый генератор случайных чисел. Это повышало вероятность угадывания ключей злоумышленниками.
При развертывании приложения, возможно, вы решите приобрести сертификаты от авторитетного CA, такого как VeriSign. Это, в частности, касается веб-сайтов и Интернет-браузеров, которые распознают ограниченное количество центров сертификации автоматически. Если, например, применяется тестовый сертификат для шифрования коммуникаций с защищенной частью веб-сайта, клиентский браузер отобразит предупреждение о том, что сертификат поставлен неизвестным CA:
Конфигурирование SSL на IIS 8
Прежде всего, понадобится издать сертификат для веб-сервера. Для этого раскройте корневой узел веб-сервера в навигационном дереве консоли управления и выберите средство Server Certificates (Сертификаты сервера), как показано на рисунке ниже:
После открытия детального представления консоль управления отобразит список сертификатов, установленных на сервере. Первый интересный момент в IIS 8 связан с возможностью установки множества серверных сертификатов на одном веб-сервере, которые могут использоваться для различных сконфигурированных на нем веб-сайтов . Это - замечательное усовершенствование по сравнению со старыми версиями IIS, которые позволяли устанавливать только один серверный сертификат на веб-сервер.
В детальном представлении средства Server Certificates панель задач в правой части консоли управления содержит необходимую задачу для установки серверных сертификатов. Она позволяет автоматически создать запрос сертификата, который можно применить для запроса нового сертификата у CA. Для создания нового запроса просто используется ссылка на задачу Create Certificate Request (Создать запрос сертификата) в панели задач, что позволит создать тот же закодированный в Base64 файл запроса для отправки его в запросе к CA.
После получения сертификата от CA можно завершить выполняющийся запрос, щелкнув на ссылке Complete Certificate Request (Завершить запрос сертификата) в панели задач внутри средства Server Certificates консоли управления. Подобным образом можно запросить и сконфигурировать сертификат SSL для автономного веб-сервера. Если необходимо запросить сертификат для вашего собственного CA, можно воспользоваться мастером онлайнового центра сертификации (Online Certification Authority), щелкнув на ссылке Create Domain Certificate (Создать сертификат домена). Затем этот сертификат конфигурируется на вашем собственном CA и применяется для подписания изданных им сертификатов.
Честно говоря, этот процесс довольно запутанный если вы - просто разработчик, которому нужно протестировать SSL на собственном веб-приложении. Поэтому IIS 8 включает дополнительную опцию, которая изначально не была доступна в версиях IIS 6 и ниже: создание самоподписанного сертификата для вашей собственной машины. Все, что понадобится указать для самоподписанного сертификата - это дружественное имя, которое будет отображено в списке. Впоследствии мастер создает сертификат, применяя криптографические функции вашей машины, и установит этот сертификат на веб-сервер.
Важно понимать, что такие сертификаты должны применяться только в целях тестирования, потому что ни один браузер кроме вашего, запущенного на вашей машине разработчика, не имеет понятия об этом сертификате, а потому выдаст предупреждения, что сертификат недействителен.
После конфигурирования и установки серверные сертификаты могут использоваться для SSL-коммуникаций внутри веб-сайтов, обслуживаемых вашим веб-сервером IIS. Для этой цели вам понадобится настроить привязки протокола для SSL, а также параметры SSL для веб-приложений внутри веб-сайтов.
Конфигурирование привязок для SSL
Привязки используются для открытия доступа к содержимому веб-сайтов через определенные протоколы, IP-адреса и порты. Хост-заголовки для доступа к нескольким веб-приложениям через один и тот же IP-адрес и порт также настраиваются в привязках.
Чтобы применять SSL для приложений, сконфигурированных внутри веб-сайта, понадобится настроить привязку протокола SSL для веб-сайта. Для этого просто выберите веб-сайт (такой как Default Web Site (Веб-сайт по умолчанию)) в навигационном дереве диспетчера служб IIS и щелкните на ссылке Bindings (Привязки) в панели задач справа. Откроется диалоговое окно Web Site Bindings (Привязки сайта), которое позволяет сконфигурировать необходимые привязки. Добавьте новые привязки, чтобы обеспечить доступ к приложению через разные IP-адреса, порты и протоколы. Диалоговое окно Web Site Bindings показано на рисунке ниже:
Щелкнув на кнопке Add (Добавить), можно добавить новую привязку веб-сайта. Щелкнув на кнопке Edit (Изменить), можно модифицировать существующую привязку в списке. На рисунке ниже показана конфигурация привязки для включения SSL на веб-сайте:
Легко заметить, что протокол сконфигурирован как https, запущенный на IP-адресе по умолчанию для сервера, с использованием порта 443 для SSL-доступа (который является портом по умолчанию для SSL). Далее в раскрывающемся списке в нижней части окна можно выбрать сертификат, используемый для трафика SSL на выбранном веб-сайте.
В этом списке доступен каждый установленный ранее сертификат, и для каждого веб-сайта на веб-сервере можно сконфигурировать свой сертификат. После конфигурирования привязки SSL для веб-сайта можно включить SSL для веб-приложений внутри веб-сайта.
Шифрование информации с помощью SSL
Включение SSL в OS конфигурируется на уровне веб-приложений. После настройки привязок на уровне веб-сайтов можно выбрать веб-приложение в навигационном дереве консоли управления IIS и активизировать конфигурацию средства SSL, как показано на рисунке ниже:
Здесь можно указать, требуется ли SSL-кодирование для выбранного веб-приложения и нужны ли клиентские сертификаты для аутентификации пользователей. При использовании аутентификации с применением клиентского сертификата потребуется сконфигурировать отображение сертификатов на пользователей, чтобы они были в конечном итоге аутентифицированы IIS при извлечении определенного сертификата.
Эти отображения должны быть настроены в разделе <iisClientCertificateMapping> внутри раздела <system.webServer> конфигурационного файла web.config. За дополнительной информацией об отображении клиентских сертификатов обращайтесь к документации Microsoft, доступной в MSDN.
После включения SSL для веб-сайта можно проверить его работоспособность, запустив в браузере:
Обратите внимание, что браузер Google Chrome отобразил перечеркнутую надпись https. Это связано с тем, что в этом примере я использовал самоподписанный сертификат, который не подтвержден CA. Это удобно когда вы разрабатываете сайт и вам нужно просто протестировать его при работе с SSL. Однако в развернутом веб-сайте нужно будет приобрести лицензированный сертификат в компаниях CA. Например, ниже показан сайт Сбербанка, который использует лицензированный сертификат, обратите внимание, что Google Chrome извлекает информацию о названии организации из сертификата:
