В разных интернетах разные пользователи доставляют разные заблуждения на тему PKI. Это вполне нормальное поведение для тех, кто не является специалистом в этой области. Но ненормальное для пользователей претендующих на это звание. Сегодня на повестке дня 3 вопроса:

• Standalone CA и шаблоны сертификатов;
• тайна самоподписанных сертификатов EFS;
• сертификаты на кластере NLB.

Standalone CA и шаблоны сертификатов

Вчера в одном блоге вычитал утверждение, что Standalone CA может использовать шаблоны сертификатов. На самом деле это не так. Standalone CA выгодно отличается от Enterprise, что ему не нужны шаблоны. Совсем. Он собирает сертификат из той информации, которая хранится в запросе сертификата. Если в оснастке certsrv.msc у Enterprise CA есть секция Certificate Templates, то у Standalone CA её нет:

вот, есть Revoked, Issued certificates, Pending, Failed Requests, но никакого Certificate Templates, так что использовать их в такой ситуации нельзя.

Тайна самоподписанных сертификатов EFS

Я думаю, что многие шифровали файлы в системе простым, автоматически сгенерированным системой сертификатом. Находится он в оснастке certmgr.msc, контейнере Personal и выглядит примерно так:

Как мы видим, это самоподписанный сертификат, у которого Issuer и Subject одинаковые и соответствуют имени текущего пользователя. Срок действия — 100 лет. Всем известно, чтобы сертификат был доверенный, корневой сертификат из его цепочки (или он сам, если это самоподписанный сертификат) должен находиться в контейнере Trusted Root CA. Но в случае с этим сертификатом EFS такое не наблюдается. И вчера в том же самом блоге узнал, что этот самоподписанный сертификат какой-то волшебный и на него не распространяются правила доверия.

Но на самом деле всё гораздо интересней. PKI — технология очень железная с не менее железной логикой и всё в ней подчиняется простым принципам. Это делает PKI весьма надёжной и непробиваемой. Но давайте вернёмся к нашим баранамсампоподписанным сертификатам EFS. На самом деле его копия тоже установлена в контейнере, который делает сертификаты доверенными. И имя ему Trusted People:

Если удалить ваш сертификат из контейнера Trusted People, он станет недоверенным и мы будем горько плакать по этому поводу. Вот что говорят об этом технеты:

Trusted People (TrustedPeople) — This container keeps certificates issued to people or end entities that are explicitly trusted. Most often, these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook. To share an EFS–encrypted file with other parties, you must have their certificate in this store.

Иными словами, контейнер Trusted People своего рода аналог контейнера Trusted Root CAs, но только для пользовательских сертификатов.

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

Предположим, у вас кластер NLB, который несёт роль веб-сервера. Зачастую там будет какой-нибудь HTTPS, которому нужны сертификаты. Бытует весьма устойчивое мнение, будто бы сертификат SSL должен быть одинаковый на всех узлах кластера, иначе что-то не будет работать при отказе какого-то узла. В действительности это тоже весьма далеко от истины. Дело в том, что сессионные ключи не реплицируются между узлами кластера и каждый узел поддерживает свою сессию SSL c клиентом (это реально, когда клиент одновременно подключен к нескольким узлам кластера). И переключение с одного узла на второй (если один отказал) вызывает инициирование новой сессии SSL. Т.е. снова запрос сертификата сервера, проверка на доверие и отзыв, генерация сессии, сессионных ключей и всё остальное.

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

На сегодня это всё.

В этом посте я постарался собрать наиболее полезные или интересные ссылки на MS Knowledge Base (или просто KB) по теме Software Restriction Policies и AppLocker.

Список будет периодически обновляться по мере выхода новых KB.

Давненько я ничего не писал про SRP, хотя давно пора было бы заполнить некоторые пробелы. В этой статье мы разберём 3 вопроса (проблемы):

• особенности применения SRP в системах x64;
• особенности конфигурирования политики на терминальном сервере;
• особенности создания правил в Vista-based системах и применения в XP-based системах.

Проблемы SRP в системах x64

Использование SRP в 64-разрядной системе иногда чревато проблемами. Давайте разберёмся с дефолтными правилами. Их у нас всего 2:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Это очень хорошие и полезные правила. Они позволяют нам запускать любые приложения из папки Windows и Program Files. Но в x64 системах у нас есть 2 класса приложений, родные x64 и унаследованные приложения x86, которые работают в режиме эмуляции. Такие приложения как правило устанавливаются в папку Program Files (x86). И если мы попробуем запустить любое приложение из папки Program Files (x86), мы получим ошибку:

Это происходит по вполне очевидным причинам. Наши правила по умолчанию не распространяются на папку Program Files (x86). Для этого мы должны создать ещё одно правило:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%

После этого мы сможем запускать всё из папки Program Files (x86). Вроде бы всё хорошо и замечательно. Но природа работы SRP многогранна и необычна.

Представим ситуацию, у вас установлен 32-разрядный MS Outlook (ну или любая другая 32-разрядная почтовая программа) и вам пришло письмо с приаттаченным RAR архивом. А WinRAR у вас установлен x64. Вы пытаетесь открыть архив из письма, а не получается. На сколько я проверял, вообще ничего не происходит, но в журнале событий (напоминаю, что логи SRP пишутся в журнал Application) с EventID = 865 можно найти многозначащее:

Access to C:\Program Files\WinRAR\WinRAR.exe has been restricted by your Administrator by the default software restriction policy level.

Что хотите, то и делайте. Правила все есть, а не работают. Но я не зря говорил о многогранной и необычной природе SRP. При запуске одного приложения из второго (в нашем случае из аутлука запускаем WinRAR, чтобы открыть архив) контекст SRP наследуется из родительского приложения в дочернее (если так вообще можно сказать). Если говорить простым языком, если родительское приложение (в нашем случае MS Outlook) является 32-битным, то все запускаемые из него приложения проверяются так, будто они 32-битные. На практике это означает примерно следующее. Где фактически находится ветка реестра Software для x86 приложений? Кто-то скажет, что там же, где и всегда: HKLM\Software и будет не прав, потому что правильный ответ: HKLM\Software\Wow6432Node. И давайте посмотрим, что нам покажут вышеперечисленные пути (из правил SRP) в реестре:

А ведут оба этих пути в одну и ту же папку, т.е. Program Files (x86). Соответственно, в такой ситуации у нас нет ни одного правила для папки Program Files и вполне логично, что WinRAR запущен не был. В обратной ситуации (когда из 64-битного аутлука запустить 32-битный WinRAR) такой проблемы нет, потому что путь в значении ProgramFiles (x86) всегда ведёт в Program Files (x86). Для решения этой проблемы в Windows 7 было добавлено ещё одно значение: ProgramW6432Dir = C:\Program Files.

Этот ключ реестра во всех случаях ведёт в папку Program Files. Следовательно, нам нужно создать ещё одно правило, которое будет включать этот параметр реестра. В сухом остатке список правил по умолчанию для x64 систем у нас должен быть минимум такой:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%

Эти 4 правила обеспечивают полный эквивалент правил по умолчанию, которые используются в родных x86 системах. Однако, хочу отметить один факт. Параметр ProgramW6432Dir по указанному пути присутствует только в Windows 7 и Windows Server 2008 R2. В предыдущих системах (включая Windows Vista x64 и Windows Server 2008 x64) он отсутствует. Поэтому в них для решения этой проблемы придётся прописывать абсолютные пути (без использования переменных) к папкам C:\Program Files и C:\Program Files (x86).

Политики SRP на терминальных серверах

Достаточно часто (если исходить из общего количества внедрений SRP) администраторы наступают на одни и те же грабли. Поскольку природа терминальных серверов достаточно разнообразна, практически сложно создать какую-то одну политику SRP с правилами, которые удовлетворяли бы требованиям всех пользователей. Всегда будет так, что одному пользователю будет необходимо одно бизнес-приложение, а другому это приложение не нужно и должно быть запрещено. Адмнистраторы недолго думая пользуются тем фактом, что SRP можно настраивать и на уровне пользователя (секция User Configuration). Создают несколько политик SRP в этой секции, настраивают фильтрацию (чаще security filtering) так, чтобы каждой группе пользователей применялись нужные правила. Но сразу после применения политики могут начаться проблемы. Например, в пользовательской политике исключили расширение LNK, а на самом деле это расширение блокируется. Дело в том, что в определённых ситуациях (не скажу точно при каких условиях) SRP неявно создаёт копию политики по умолчанию в общекомпьютерной ветке реестра: HKLM\Software\Policies\Microsoft\Windows\Safer и получается конфликт, поскольку настройки компьютерной политики (кроме правил в Additional Rules) перекрывают соответствующие настройки в пользовательской политике.

Чтобы заранее избежать подобной ситуации следует придерживаться следующего правила: создать базовую (которая применима ко всем пользователям на машине) политику в секции Computer Configuration (в этой секции определить общие настройки и глобальные правила). Для расширения прав и/или назначения гранулированных прав запуска тех или иных приложений можно назначать правила в секции User Confgiration.

Создание политик в Vista-based системах и применения в XP-based системах

Ещё давным-давно (в декабре 2007) вышла в свет Windows Vista с некоторыми изменениями в SRP. В частности правила хешей теперь поддерживают алгоритм SHA256, который не поддерживается в Windows XP и Windows Server 2003 (включая R2). Но возникает вопрос interoperability с предыдущими системами. Например, что будет, если мы создадим правило в Windows Vista, а применим его на Windows XP (через GPMC.msc, который входит в состав RSAT)?

В интернетах ходят разные мифы на этот счёт, но в реальности всё гораздо проще. Когда Windows Vista (или выше) создаёт правило хеша, система генерирует 2 хеша — родной SHA256 и совместимый хеш MD5. Таким образом обеспечивается полная совместимость с системами XP/2003. Два хеша генерируются даже если это одиночная машина в рабочей группе и совместимость с предыдущими версиями систем не требуется. Вот как это выглядит в реестре:

Здесь мы видим стандартный хеш MD5 (AlgID = 8003 это MD5). ItemData содержит фактический хеш.

Под ключом правила (каждое правило здесь указано в виде GUID'а) добавляется ещё один ключ SHA256:

Вот здесь мы видим другой идентификатор алгоритма (800c это SHA256). ItemData так же содержит фактический хеш, но не MD5, а SHA256.

Примечание: полный список криптографических алгоритмов можнно найти по здесь: http://msdn.microsoft.com/en-us/library/aa375549(VS.85).aspx

Порядок проверки хешей для XP/2003 остался тот же — только MD5. В Windows Vista сначала проверяется хеш из ключа SHA256.

Update 20.03.2011: исправлен синтаксис для INF

В различных интернетах ходит достаточно много слухов о правильности использования флага EDITF_ATTRIBUTESUBJECTALTNAME2. В общем смысле, администраторы включают этот флаг для выпуска сертификатов с расширением Subject Alternative Name без разбора и ссылаются на этот документ: http://support.microsoft.com/kb/931351. Но, как оказывается, мало кто осилил документ полностью.

Как видно из названия (ATTRIBUTE), этот флаг разрешает сабмитить запрос сертификата с атрибутом, содержащим расширение SAN. Этот атрибут можно добавить следующими способами:

• при использовании Web Enrollment Pages (Windows 2000 и Windows Server 2003) вы можете указать дополнительный атрибут с использованием примерно такого формата: san:dns=dns.name[&dns=dns.name];
• при использовании certreq и INF файла, который содержит строку следующего формата: san:dns=dns.name[&dns=dns.name] (такой же, как и в Web Enrollment Pages);
• при использовании certreq и сабмита уже готового файла запроса: certreq –submit –attrib:"san:dns=dns.name[&dns=dns.name]"

С одной стороны, вроде, и удобно, но это сильно небезопасно. Дело в том, что если флаг EDITF_ATTRIBUTESUBJECTALTNAME2 включен, любой пользователь можешь добавить атрибут SAN к своему запросу и получить нужный сертификат, даже если шаблон не разрешает использовать расширение SAN. Данный флаг можно включать только если CA сконфгирурирован на ручное одобрение каждого запроса администратором CA, который будет следить, чтобы ни один пользователь не подсунул «левый» SAN. Но в условиях энтерпрайза это малореально. Следовательно вы НЕ ДОЛЖНЫ включать этот флаг на Enterprise CA, если он настроен на автоматическую выдачу сертификатов без премодерации!

Но мы ведь хотим SAN, но не хотим включать этот флаг. Как тогда быть? Для этого мы (и вы тоже) должны использовать один из следующих методов:

• Сжечь Web Enrollment Pages и научиться пользоваться оснасткой Certificates (в Windows Vista и выше) для получения сертификата: Web server certificate enrollment with SAN extension (ха-ха, у меня там раньше тоже была сноска на включение этого флага, потому что сам заблуждался).
• Использовать новые возможности INF файла. Начиная с Windows Vista вы можете в INF файле указать расширение SAN в Base64 кодировке с использованием примерно следующего формата:
  [Extensions] 
  2.5.29.17 = "{text}"
  _continue_ = "dns=www01.fabrikam.com&"
• настроить шаблон на премодерацию и использовать вот такой скриптик для добавления расширения SAN в запрос: How to add FQDN to HP iLO request

HTH

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	Google Chrome	Apple Safari
Legacy cryptography support
CNG Support
OCSP Support
Offline revocation detection
Native Windows/Integrated Authentication
Custom Windows/Integrated Authentication implementation	Not required			Not required
Client Certificate Authentication
Windows Certificate Store support
Custom Certificate Store support	Not required			Not required	Not required
Native smart card support
Custom smart card support	Not required			Not required	Not required

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

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

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