Главная » Иные пенсионные выплаты » Сертификат клиентской аутентификации. Методы аутентификации

Сертификат клиентской аутентификации. Методы аутентификации

Криптографический протокол SSL (Secure Socket Layer) был разработан в 1996 году компанией Netscape и вскоре стал наиболее популярным методом обеспечения защищенного обмена данными через Интернет. Этот протокол интегрирован в большинство браузеров и веб серверов и использует ассиметричную криптосистему с открытым ключом, разработанную компанией RSA.

Для осуществления SSL соединения необходимо, чтобы сервер имел инсталлированный цифровой сертификат. Цифровой сертификат - это файл, который уникальным образом идентифицирует пользователей и серверы. Это своего рода электронный паспорт, который проводит аутентификацию сервера до того, как устанавливается сеанс SSL соединения. Обычно цифровой сертификат независимо подписывается и заверяется третьей стороной, что гарантирует его достоверность. В роли такой третьей стороны выступают центры сертификации, в частности, компания thawte. Компания thawte является наиболее известным в мире центром сертификации.

Протокол SSL обеспечивает защищенный обмен данными за счет сочетания двух следующих элементов:

 Аутентификация Цифровой сертификат привязан к конкретному домену сети Интернет, а центр сертификации проводит проверки, подтверждающие подлинность организации, а уже затем создает и подписывает цифровой сертификат для этой организации. Такой сертификат может быть установлен только на тот домен web-сервера, доля которого он прошел аутентификацию, что и дает пользователям сети Интернет необходимые гарантии.

 Шифрование Шифрование - это процесс преобразования информации в нечитаемый для всех вид, кроме конкретного получателя. Оно основывается на необходимых для электронной коммерции гарантиях конфиденциальности передачи информации и невозможности ее фальсификации.

Как выглядит SSL сертификат?

Чтобы увидеть детали SSL сертификата web-сайта, сделайте двойной щелчок мыши по закрытому замочку, который появляется внизу страницы в строке состояния.

Так выглядит цифровой сертификат для браузера IE 6.0:

SSL сертификат web-сервера позволяет посетителям Вашего сайта видеть следующую информацию (детальная информация о сертификате представлена на закладке «Состав»):

* Домен сети Интернет, для которого выпущен этот сертификат. Эта информация позволяет убедиться, что данный SSL сертификат web-сервера был выпущен именно для вашего хоста и домена (http://www.mydomain.com/ ). * Владелец сертификата. Эта информация является дополнительной гарантией, поскольку посетитель может увидеть имя того, с кем ведет бизнес. * Город, где зарегистрирована компания-владелец сертификата. Эта информация еще раз убеждает посетителя, что он имеет дело с реальной организацией. * Срок действия сертификата. Эта информация особенно важна, поскольку показывает пользователю, что ваш цифровой сертификат действующий.

Как установить SSL сессию защищенного обмена данными?

Когда вы устанавливаете сетевое соединение с защищенным web-сервером, таким как https://www.ssl.ua , сервер должен вначале сам аутентифицировать клиентский web-браузер, что осуществляется с помощью цифрового сертификата, после чего устанавливается защищенное соединение.

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

В ходе этой процедуры web-браузер проверяет, чтобы:

 доменное имя в сертификате соответствовало тому домену, от которого идет запрос на защищенное соединение

 сертификат не был просрочен

 сертификации, подписавший сертификат домена, входил в число доверенных вашего web-браузера

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

Когда желательно применять SSL сертификаты?

Решение о применении SSL сертификата исходит из важности обеспечения конфиденциальной передачи данных в сети Интернет. Например, при проведении через ваш web-сайт финансовых транзакций вопрос о применении SSL сертификата самоочевиден. Если вы обрабатываете значимую персональную информацию о клиентах, такую как номер социального страхования или другую подобную информацию, то применение SSL сертификата имеет серьезные основания. Особенно если вопросы конфиденциальности и информационной безопасности ваших клиентов имеют высокий приоритет.

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

Значимость аутентификации web-сервера

Информация - это основа жизнеобеспечения вашего бизнеса. Чтобы обеспечить цельность (защиту от фальсификации) и конфиденциальность, необходимо идентифицировать тех, с кем вы имеете дело, а также быть уверенными в надежности получаемых данных. Аутентификация поможет вам установить доверие между сторонами при проведении любых видов транзакций. К числу средств обеспечения надежности относится предотвращение следующих явлений:

 «Спуфинг» (имитация соединения):

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

 Несанкционированные действия:

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

 Неправомочное разглашение информации:

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

 Фальсификация данных:

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

Протокол SSL (Secure Socket Layers - протокол защищенных сокетов), совместно разработанный Netscape Communications и RSA Data Security, позволяет эффективно обеспечить такую безопасность. Протокол SSL обеспечивает безопасность, аутентификацию на базе сертификатов и согласование безопасности по установленному сетевому соединению, поэтому множество компаний и продуктов приняли SSL в качестве коммуникационного протокола.

В этой серии мы сконцентрируемся на двух главных аспектах:

подробная информация о схеме работы SSL;

детальная информация о поддержке SSL в версиях 5.1 и 6.0.1 среды ISC.

В данной статье исследуется SSL и объясняется, почему его рекомендуется реализовать в среде ISC. Во второй и третьей частях этой серии будет представлена подробная пошаговая инструкция по реализации и подключению SSL к ISC 5.1 и 6.0.1.

Во-первых, что такое SSL?

Знакомство с ssl

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

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

Цифровые сертификаты

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

установить личность владельца;

сделать доступным первичный ключ владельца.

Цифровой сертификат выпускается проверенной полномочной организацией - источником сертификатов (certificate authority - CA) и выдается только на ограниченное время. После истечения срока действия сертификата его необходимо заменить. Протокол SSL использует цифровые сертификаты для обмена ключами, аутентификации серверов и, при необходимости, аутентификации клиентов.

Цифровой сертификат содержит следующие фрагменты информации о личности владельца сертификата и источнике сертификатов:

полное (уникальное) имя владельца сертификата;

публичный ключ владельца;

дата выдачи цифрового сертификата;

дата окончания действия сертификата;

полное (уникальное) имя издателя (источника сертификата);

цифровая подпись издателя.

Подключение по SSL всегда инициируется клиентом вызовом URL-адреса, начинающегося с https:// вместо http:// .

Типы сертификатов

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

Есть три способа получить SSL-сертификат:

использовать сертификат от источника сертификатов;

использовать самоподписанный сертификат;

использовать "пустой" сертификат

Использование сертификата от источника сертификатов

Источники сертификатов (CA) - это организации, которым доверяет вся отрасль и которые занимаются выдачей Интернет-сертификатов. Например, такой сертификат можно получить от компании VeriSign. Чтобы получить сертификат, подписанный источником, необходимо предоставить достаточно информации источнику, чтобы он смог проверить вашу личность. Тогда источник создаст новый сертификат, подпишет его и доставит его вам. Популярные Web-браузеры заранее настроены доверять сертификатам, выданным определенными источниками, так что не нужно никакой дополнительной конфигурации для подключения клиента через SSL к серверу, для которого был выдан сертификат.

Использование самоподписанного сертификата

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

Использование "пустого" сертификата

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

Итак, что нужно делать после получения сертификата?

Остальные материалы цикла:

Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов — подведение итогов

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

Общая схема аутентификации по сертификатам

Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:

Пользователь запрашивает доступ к некоторой сетевой службе;
По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):

Клиент запрашивает установку безопасного канала;
Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
Клиент посылает на сервер свой список протоколов симметричного шифрования;
Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Логон смарт-картой или PKINIT

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT. PKINIT, в свою очередь, является лишь надстройкой над керберосом (или расширением протокола). Вот как он примерно работает:

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

Пользователь вводит PIN от смарт-карты и посылает запрос AS-REQ на контроллер домена (он же Key Distribution Center — KDC). Этот запрос содержит преаутентификационные данные PA_PK_AS_REQ, которые, в свою очередь, содержат логонный сертификат и подписанная временная метка и опциональные атрибуты. В качестве опциональных атрибутов, клиент посылает список поддерживаемых алгоритмов, корневых CA, параметры Diffie-Hellman и т.д. Более детально структуру запроса (а там есть достаточно занятных вещей) можно найти в RFC 4556 §3.2.1 (пункт 5 на странице 12). В связи с этим (например, передача списка доверенных корневых CA от клиента на сервер) время логона смарт-картой будет значительно медленней, чем при связке логин/пароль. Плюс расходы на криптографические операции.
Сервер KDC проверяет запрос и пробует ассоциировать полученный сертификат с учётной записью пользователя. Если сопоставление сертификата с учётной записью произошло успешно, KDC формирует ответ AS-REP, включая в него Ticket-Granting Ticket (TGT) и прочую необходимую информацию. Ответ подписывается сертификатом самого KDC (именно поэтому, при использовании смарт-карты для логона, сервер KDC должен иметь свой собственный сертификат (о нём мы поговорим в следующих статьях).
Клиент проверяет этот ответ и проверяет подпись (вместе с сертификатом KDC). Если с ответом и сертификатом всё хорошо, клиент, на основе имеющегося TGT, генерирует Ticket Granting Service запрос — TGS-REQ для доступа к конкретной службе и отправляет его на KDC.
KDC проверяет запрос TGS-REQ и в случае положительного вердикта формирует ответ Ticket-Granting Service (TGS-REP), включая в него всю необходимую информацию для интерактивного логона, включая все необходимые SID"ы и учётные данные для аутентификации при помощи NTLM.
Клиент генерирует специальный токен GSS-API (

Практически каждый пользователь сталкивался с множеством проблем в браузере. Одна из таких неполадок - SSL-подключения, которая не позволяет просматривать нужные страницы. Давайте же разберёмся со всеми способами устранения подобной проблемы.

Первый этап

Итак, для начала нужно определиться, что это за неполадка, откуда она берётся, а уже потом искать способы её устранения. Если на вашем компьютере при попытке подключения к какой-либо странице в интернете через браузер появляется ошибка SSL-подключения, то это свидетельствует о том, что неполадка вызвана несоответствием в системе. Следовательно, это нужно исправить, но, как показывает практика, сделать это не так просто, как может показаться на первый взгляд.

Зачастую работать отказываются все установленные браузеры. Единственный выход - это пользоваться стандартным IE, который в 90% случаев не выдаёт такой ошибки. Данный браузер можно использовать, пока не будет найдено решение проблемы. Простыми словами, SSL-ошибка свидетельствует о том, что невозможно установить соединение с сервером по некоторым причинам. Давайте же разберёмся, из-за чего появляется подобного рода проблема.

Причины возникновения SSL-ошибки

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

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

Ошибка подключения SSL origin

Если вы любите играть в хорошие игры на компьютере и покупаете их через интернет, то чаще всего такой продукт требует активации. Несмотря на то, что это минутный процесс, для вас он может стать настоящей головной болью из-за сбоя протокола SSL. При этом подробный текст ошибки может выглядеть по-разному. Например: «необходим сертификат клиентской аутентификации» или «SSL_ERROR_PROTOCOL». Всё исправить можно следующим образом.

Заходим в антивирус, если, конечно, он имеется. Далее идём в настройки, если быть точнее, нам нужна строка «фильтрация протокола https». Тут необходимо убрать галочку, то есть выключить. Перезагружаем компьютер и пробуем установить origin. Если всё прошло успешно, то Если нет, желательно установить игру с диска и попробовать просто ее обновить. Что еще может помочь, так это использование другого браузера, например, не Chrome, а Opera.

Ошибка SSL-подключения: устраняем проблему

Давайте разберёмся, что же делать, если появилась подобного рода проблема. Прежде всего, не нужно паниковать. Все не так и страшно и решается за несколько минут. Основная причина возникновения ошибки заключается в том, что, как было отмечено выше, Случается это по нескольким причинам. Одна из них - это севшая батарейка в BIOS. Её можно поменять, стоит она 40-50 рублей.

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

Включаем SSL и Cookie в браузере

В некоторых случаях наличие данного протокола не требуется. Но когда вы хотите воспользоваться Adsense-страницами, данный параметр должен быть включён. Это же касается и файлов Cookie. В принципе, для нормальной работы и отображения информации, в т.ч. и объявлений, нужен рабочий SSL. Итак, переходим к настройке браузера. Прежде всего, необходимо перейти в меню, а затем выбираем настройки.

Там вы должны увидеть вкладку «Дополнительные настройки», она-то нам и нужна. Следующий этап - это выбор пункта «Настройки контента», а после нужно зайти в «Личные данные». Перед нами будет меню под названием «Файлы Cookie». Заходим туда и устанавливаем флажок напротив пункта «Сохранение локальных данных». Закрываем вкладку и переходим в HTTPS/SSL. Тут нужно проделать аналогичную работу. Устанавливаем галочку напротив строчки «Проверять, не отозван ли сертификат с сервера». Если флажок не стоит, то работа SSL будет некорректной. Вот и всё, перезагружаем браузер и приступаем к работе.

Еще несколько простых способов решения проблемы

Если у вас нет времени для того, чтобы разбираться с настройками браузера или сканировать систему, то можно попробовать несколько раз подряд на которую вам нужно зайти. Вполне вероятно, что после этого информация будет частично отображена. Однако в дальнейшем вам нужно будет сделать всё по инструкции. Еще один выход - это сбросить настройки браузера на Default, то есть на стандартные. Это позволит включить/выключить все необходимые плагины и скрипты. Также рекомендуется почистить кэш, что иногда даёт положительный результат. Еще можно перейти в папку Windows, затем system 32, после чего - в drivers, чтобы найти там файл «etc». Последняя строчка должна выглядеть следующим образом: 127.0.0.1. Всё, что ниже данной надписи, нужно удалить. После этого в Google ошибка подключения SSL исчезнет.

Несколько важных моментов

Обратите внимание, что иногда сайты без надёжных или с просроченными сертификатами являются своего рода разносчика вирусов. В этом случае нормально увидеть окошко с надписью «ошибка подключения SSL».

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

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

Заключение

Вы должны понимать, что если у вас возникает подобного рода ошибка, то что-то с компьютером не так. Прежде всего, проверьте время. Если год, месяц или время суток не соответствует действительности, нужно все исправить. Для этого в трее рабочего стола вашей операционной системы кликаем несколько раз по часам и устанавливаем реальные значения. Как правило, это сразу же решает проблему. Если этого не случилось, идём в и смотрим, включена ли поддержка протокола SSL. Если всё так, как и должно быть, то, вероятнее всего, дело в антивирусной программе или вредоносном файле, который блокирует соединение. Удаление или перемещение в карантин должно помочь.

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

ISA сервер способен поддерживать четыре метода аутентификации:

Серверные и клиентские сертификаты.
Комплексная аутентификация.
Аутентификация по дайджесту.
Основная аутентификация.

Серверные и клиентские сертификаты

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

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

Клиентский сертификат

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

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

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

Сертификаты серверов

Если клиент у сервера запрашивает SSL объекты, сервер обязательно должен удостоверить свою подлинность. Если в период проведения аутентификации происходит обрыв соединения или аварийная ситуация, после устранения недоразумения весь процесс должен быть произведен снова.

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

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

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

Аутентификация по дайджесту

Этот метод аутентификации может быть использован лишь для доменов Windows 2000.
Если при основной аутентификации учетные данные пользователя направляются открытым текстом, то при аутентификации по дайджесту они хэшируются (кодируются.). Поэтому этот метод для пользователя считается более безопасным.

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

Комплексная аутентификация

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

При этом методе аутентификации применяется встроенный протокол (NTLM) или Kerbros, с помощью которых производится запрос и отзыв .

Сквозная аутентификация

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

Клиент направляет веб-серверу GET запрос.
Веб-сервер выдаёт ошибку 401. Он требует аутентификацию и сведения о том, какой метод аутентификации может быть поддержан.
ISA сервер сообщает клиенту о том, что следует произвести аутентификацию. Клиент направляет ISA серверу ту информацию, которую он затребовал, а ISA сервер отправляет эти сведения веб-серверу.
Далее общение клиента осуществляется с веб-сервером.

Используемый метод аутентификации иногда очень важен, если причина неполадок не лежит на поверхности. Надеемся,что эта статья поможет в работе.

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

Аутентификация клиента . Позволяет серверу Windows 2000 VPN или веб-серверу IIS идентифицировать пользователя с использованием стандартных методов шифрования на открытом ключе. Осуществляет проверку подлинности сертификата клиента и общего ID, а также проверку того, что эти данные сгенерированы бюро сертификатов, корневой сертификат которого установлен в перечне доверенных CA. Эта проверка очень важна, если сервером является банк, который передает конфиденциальную финансовую информацию клиенту и должен подтвердить личность получателя. На рисунке 8.1 отображен процесс аутентификации.
Аутентификация сервера . Позволяет клиенту VPN или браузеру клиента SSL/TLS подтверждать идентичность сервера, проверяя правильность сертификата сервера и идентификатора ID, а также то, что сертификаты выпущены бюро сертификатов (CA), корневой сертификат которого присутствует в перечне доверенных CA клиента. Это подтверждение имеет важное значение для пользователя веб-сайта, который отправляет номер кредитной карты через сеть и хочет удостовериться в том, что это именно тот сервер, который ему нужен.
Взаимная аутентификация . Позволяет клиенту и серверу авторизовать друг друга единовременно. Взаимная аутентификация требует, чтобы клиент и сервер имели цифровые сертификаты и соответствующие корневые сертификаты CA в перечнях доверенных CA.

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

На рисунке 8.1 показано, как работает аутентификация SSL/TLS. На практике в большей части веб-сайтов используется только серверная аутентификация с помощью цифрового сертификата, так как распространение клиентских сертификатов среди всех посетителей сайта представляет собой огромную работу (это сделать несколько легче, если клиенты объединены в сеть интранет).

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

Просмотров