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

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

1. Microsoft Internet Explorer 8;
2. Mozilla Firefox 3.6.12;
3. Opera 10.63;
4. Google Chrome 7.0.517.44;
5. Apple Safari 5.33.19.4.

Все браузеры проверялись на Windows 7 Enterprise x64. Что проверялось? А проверялось следующее:

• Legacy cryptography support

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

• CNG Support

С выходом Windows Vista, Microsoft представил свою реализацию ассиметричных алгоритмов шифрования и генерации ключей под названием CNG (Cryptography Next Generation), в том числе с поддержкой ECC (Elliptic Curve Cryptography) и прочих стандартов. С момента выхода Windows Vista уже прошло ровно 3 года (конец 2007 года) и уже вышла следующая версия настольных Windows — Windows 7. Эти 2 системы всё шире и шире заполняют места в корпоративных сетях. Уже никого не удивишь сетью с системами под управлением только Windows Vista и выше. А, следовательно, уже приобретают актуальность SSL сертификаты с поддержкой CNG. Но все ли браузеры поддерживают их? Это тоже можно назвать баяном, но один браузер этот пункт провалил. Для меня было неожиданностью, что Opera ни в какую не хочет подключаться к сайтам с такими сертификатами.

• OCSP Support

Тоже стандарт де-факто 1999 года (RFC 2560). Ну за 11 лет браузеры как-то осилили 23-страничный RFC :-). Всё-таки, лучше потратить 2кб на запрос-ответ (а напомню, запрос весит примерно 70-100 байт, а ответ порядка 1,5кб), чем тратить мегабайты трафика (особенно на нешустрых мобильных каналах) на скачиваение CRL'ов. Вот один из таких пруфов:

• Offline revocation detection

Довольно важный момент, который многие пытаются игнорировать. Потому что это не всем по зубам настроить правильно и практической пользы от этого они (они — кто не смог настроить доступность проверки отзыва) не видят. А это очень неправильно, ведь может быть так, что сертификат давно отозван (например, украли ключи от сертификата), а мы об этом ничего не знаем, т.к. списки отзыва недоступны. Как правило браузеры игнорируют эту ошибку, когда CRL'ы и OCSP недоступны, но опционально можно включить предупреждение, что сервер отзыва недоступен. В IE это сделано очень готично — выводит жёлтую полоску в адрес-баре: IE7 & SSL. Про другие браузеры не знаю, но похожих опций в настройках не нашёл.

• Native Windows/Integrated Authentication

Весьма актуальный пункт для корпоративного сектора. Поскольку внутренние порталы (особенно на SharePoint) используют учётные записи Active Directory для разграничения прав доступа на элементы и страницы корпоративного веб-сайта с использованием Windows (или Integrated) Authentication. Без него пользователю пришлось бы каждый раз вводить свои логин и пароль для входа на сайт, что весьма уныло и очень раздражает. А если есть вот такая сквозная аутентификация, система сама пересылает учётные данные (как правило, билет кербероса, а не логин и пароль в чистом виде, как некоторые могли бы подумать) на сервер. Безусловно, раздавать свои учётные данные (хоть и шифрованные) всем подряд — не самая лучшая затея в этой жизни. Поэтому существует некоторый дополнительный механизм, который определяет, кому можно их пересылать или нет. IE использует зоны интернета для разделения сайтов. По умолчанию Internet Explorer'у разрешено пересылать учётные данные только тем сайтам, которые находятся в зоне Local Intranet. Как правило корпоративные порталы добавляются в эту зону администраторами через GPO. На одиночных станциях это настраивается в апплете Internet Options панели управления.

Бытует мнение, что только IE может использовать сквозную аутентификацию на вебе. Но это всё неправда, потому что Google Chrome тоже использует зоны интернета для определения, кому можно пересылать учётные данные.

• Custom Windows/Integrated Authentication implementation

Далеко не обязательно (хотя и рекомендуется) использовать стандартное (можно даже сказать системное) разделение сайтов по зонам для определения разрешения на пересылку учётных данных для аутентификации и браузеры могут использовать свою реализацию сквозной аутентификации на вебе. И Mozilla FireFox в данном случае является примером такой реализации. Вот ссылка на настройку Windows Authentication в FireFox: Firefox and Integrated Windows Authentication. Opera и Safari никаким образом не поддерживают сквозную аутентификацию и не имеют собственных реализаций.

• Client Certificate Authentication

Бывают в этой жизни такие ситуации, когда использование логина и пароля для доступа к веб-сайту очень небезопасно (особенно если на сайте хранится очень конфиденциальная информация). Для усиления аутентификации можно использовать пользовательские сертификаты. Пользователь просто предъявляет его и тем самым аутентифицируется на веб-сервере. Опять же, по умолчанию для поиска пользовательских сертификатов используется системное пользовательское хранилище сертификатов (certmgr.msc). Но это тоже не обязательно (хотя и рекомендуется) и можно сделать свою реализацию.

В принципе, эту функцию поддерживают (тем или иным образом) все браузеры. Однако, в Opera она не работает. Никак. Кнопки нужные есть, но они выдают ошибки и всё. Поэтому для Opera здесь ставим красный крестик.

• Windows Certificate Store support

Большинство приложений, использующих сертификаты, используют встроенное в Windows хранилище сертификатов для определения доверия и использования пользовательских сертификатов. Но в интернет-браузерах это не строгое условие, хотя очень полезное, т.к. ничего дополнительно настраивать не надо.

Internet Explorer (удивительно, да?), Google Chrome и Apple Safai используют стандартное хранилище сертификатов. Mozilla FireFox и Opera не поддерживают его никоим образом.

Примечание: однако, это вовсе не значит, что Chrome и Safari будут показывать зелёные полоски на вашем Extended Validation SSL сертификате. Т.е. если система доверяет вашему корневому сертификату (он установлен в контейнере Trusted Root CAs), Chrome и Safari будут ему доверять тоже. Но зелёнку (если она настроена для Internet Explorer) показывать не будут.

• Custom Certificate Store support

Т.к. использование стандартного хранилища сертификатов не обязательно для браузеров, Mozilla FireFox и Opera используют свои собственные хранилища для проверки доверия SSL сертификатам, а так же и для использования клиентских сертификатов для аутентификации на вебе. Поэтому если у вас используются внутренние сертификаты (выданые вашим собственным CA), скорее всего они не будут работать в этих браузерах и вам придётся их отдельно настраивать, чтобы эти браузеры доверяли вашим сертификатам. Что касается пользовательских сертификатов, то здесь придётся экспортировать сертификат из хранилища в PFX и импортировать в браузер. Это неудобно и вообще плохо.

Что касается Opera, этот браузер вообще как-то по-своему относится к сертификатам. Например, даже не показывает зелёнки (Extended Validation SSL) на тех сайтах, где остальные браузеры её показывают. Например, Opera до сих пор не показывает зелёнку на https://startssl.org.

• Native smart card support

Бывают в этой жизни и более тяжёлые случаи, когда пользователи не имеют логина и пароля для входа в систему и вообще для аутентификации в Active Directory. У них есть сертификат, но он не просто лежит в хранилище, а находится на защищённом криптоустройстве, называемом смарт-картой. Это уже из разряда многофакторной аутентификации, о которой я здесь рассказывать не буду, но этот вид аутентификации значительно надёжней комбинации логина и пароля, т.к. тут нужно знать не только PIN код от смарт-карты (а его можно и узнать при большом желании), но и иметь при себе саму смарт-карту. Для работы со смарт-картой в систему устанавливается её драйвер и криптопровайдер (Cryptographic Service Provider, CSP). Этот CSP так же встраивает себя в LSA (Local Security Authority), что позволяет приложениям легко обнаруживать смарт-карты для аутентификации, даже если приложение не обучено специально работать со смарт-картами. Для этого, разумеется, необходимо использовать системные API.

Вот эти самые системные API используют следующие браузеры: Internet Explorer (ну куда же без него :-)), Chrome и Safari. Как только вы установили драйвер для смарт-карты, эти браузеры уже готовы с ней работать. Просто, удобно и со вкусом.

• Custom smart card support

Mozilla FireFox и Opera не используют системные API для получения сведений о смарт-картах и в этих браузерах эту поддержку нужно включать вручную. Вот пример, как это делается в Mozilla FireFox на примере Aladdin eToken: eToken Settings for Mozilla-Firefox 3.5 (по ссылке документ PDF). Opera, к сожалению, смарт-карты не поддерживает ни в каком виде.

А теперь соберём это всё в аккуратненькую табличку:

Какие выводы следуют из этого?

• Internet Explorer показал вполне очевидные результаты по обсуждаемым моментам.
• Mozilla FireFox показал себя жутким независимым индивидуалистом. Абсолютно все указанные функции реализованы внутри браузера, иногда даже в виде костылей. С одной стороны это делает его платформонезависимым, но с другой стороны значительно усложняет администрирование, поскольку придётся настраивать систему и отдельно браузер. Вобщем, вариант не очень подходящий.
• Opera — достаточно популярный браузер среди домашних пользователей, но совершенно не пригоден как корпоративный браузер. Вобщем, в recycle bin.
• Google Chrome. Что удивильно (всё же, приятно), что Google Chrome показал точно такие же результаты, как и Internet Explorer. А это значит, что в Google хорошо подготовились к возможному внедрению своего детища в корпоративный сектор. Этот браузер предельно максимально использует системные возможности Windows, чтобы не доставлять дополнительного головняка администраторам, которым, возможно, придётся его настраивать. Правда, это делает браузер платформозависимым, но это в данном случае соверешенно некритично. Вобщем годная альтернативна для замена IE (в разрезе обсуждаемых моментов).
• Apple Safari, вроде, всё выглядит очень прилично, но отсутствие какой-либо реализации Windows Authentication, портит всё впечатление. А ведь сквозная аутентификация — немаловажная фича для корпоративного браузера. Вобщем, можно оставить на перспективу после Chrome.

Вот, собственно говоря, и всё :-)