id: Гость   вход   регистрация
текущее время 00:54 15/10/2019
создать
просмотр
редакции
ссылки

2. Удостоверяющие центры и поставщики браузеров


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

2.1 Удостоверяющие центры сертификатов


УЦ играют важную роль в инфраструктуре открытых ключей — Public Key Infrastructure (PKI) для SSL. Главная обязанность каждого УЦ — проверка идентичности субъекта, которому выдаётся сертификат.


Уровень проверки, осуществляемой УЦ зависит от типа выдаваемого сертификата. Регистрация сертификата на домен можен быть получена менее чем за 15$ и обычно требует, только чтобы запрашивающий был способен ответить на имэйл к административному адресу, находящемуся в списке базы данных WHOIS. Расширенная проверка (Extended Validation — EV) требует более сложных методов.


То есть, когда пользователь посещает https://www.bankofamerica.com, браузер будет информировать его о том, что банковский сертификат действителен, выдан компанией VeriSign и этот сайт запущен компанией Bank of America. Таким образом аутентичность и конфиденциальность гарантирована SSL для того чтобы пользователь мог продолжать свою транзакцию без необходимости беспокоиться о фишинг-атаках киберпреступников.


УЦ в общем случае попадают в одну из трёх категорий:
те, которым доверяют браузеры (корневые УЦ — "root CAs"), те, которым доверяют корневые УЦ (промежуточные УЦ — "intermediate CAs" ) и те, которым не доверяют ни браузеры, ни какие-либо промежуточные УЦ (недоверяемые УЦ — "untrusted CAs"). Кроме того, промежуточные УЦ необязательно должны быть напрямую заверены корневым УЦ: они могут быть заверены другими промежуточными УЦ до тех пор, пока цепочка доверия оканчивается корневым УЦ.


С точки зрения конечного пользователя, корневые и промежуточные УЦ функционально эквивалентны. Вэбсайт, представляющий сертификат, подписанный любой из этих двух форм УЦ, приведёт к появлению в браузере пользователя иконки замка и изменение цвета строки статуса. Сертификаты, проверенные недоверяемым УЦ и потому являющиеся самоподписанными владельцем сайта, приведут к появлению предупреждений безопасности, что может испугать некоторых технически неподготовленных пользователей [3], привести их в замешательство и создать трудности, которые прийдётся преодолевать для продолжения навигации по сайту [4].


В том виде как система УЦ была задумана в оригинале и исполнена в данный момент, все корневые УЦ одинаково доверяемы для браузеров. Так, каждый из 264 УЦ, доверяемых для Microsoft, 166 доверяемых Apple и 144 корневых УЦ, доверяемых Firefox, способны выпустить сертификат для любого вэбсайта в любой стране или домене верхнего уровня [5]. Например, даже если Bank of America получит свой текущий сертификат от VeriSign, нет никакой технической причины, почему бы другой УЦ, скажем GoDaddy, не мог бы выпустить сертификат для него или кого-нибудь ещё. Злонамеренной третьей стороне нужно каким-то образом получить сертификат для сайта Bank of America и затем обманом направить пользователя на подставной вэбсервер (например, путём DNS или ARP спуфинга), при этом нет никакого практичного лёгкого пути для пользователя определить, что произошло что-то неправильно, поскольку интерфейс браузера будет сигнализировать об установлении корректной SSL-сессии.


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



Статусные панели узлов в браузерах (43 Кб)


Рис 1: Панели со строками статусов браузеров Internet Explorer (вверху), Firefox (посредине) и Chrome (внизу), в процессе посещения HTTPS-сайта с расширенной проверкой (Bank of America) и сайта со стандартным HTTPS-сертификатом (Chase). Обратите внимание, что информация о стране ("US"), представленная в браузерах, относится к корпорациям, которые получили сертификат, а не к местоположению центра сертификации (удостоверяющего центра).



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


Поставщики браузеров обладают значительной теоретической властью над каждым УЦ. Каждый УЦ, который не может более быть доверяемым ведущими поставщиками браузеров не сможет больше привлекать и удерживать клиентов, так как посетители вэбсайтов его клиентов будут каждый раз встречать запугивающие предупреждения при попытке установления защищённого соединения. Тем не менее, поставщики браузеров проявляют крайнюю неохоту в том, чтобы своевременно исключать УЦ из списков, что способствует их неподобающему поведению — мы всегда можем наблюдать большой список примеров плохих практик УЦ [6].


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


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

2.2 Вэб-браузеры


Не существует технического стандарта, который должен определять, как вэб-браузеры должны выбирать свои списки доверяемых УЦ. В результате, каждый поставщик браузера создаёт свой собственный набор политик для оценки и утверждения УЦ [7,8,9]. Поскольку нет никакого свидетельства, указывающего, что какой-либо браузер по умыслу или некомпетентности принимал нечестного УЦ, мы не обсуждаем тонкости проверки политик каждого отдельно взятого поставщика.


Далее больше внимания будет уделено методу, которым поставщики браузеров производят доставку и обновление своих списков корневых УЦ и как интерфейс браузера предоставляет конечным пользователям просмотр и управление ими.


Ведущие браузеры (Internet Explorer, Firefox, Chrome и Safari) используют несколько отличающиеся политики управления и отображения списков доверяемых УЦ: Firefox — единственный лидирующий браузер, ведущий собственную базу данных доверяемых УЦ, тогда как остальные три браузера вместо этого полагаются на список УЦ, предоставляемый операционной системой. Однако, поскольку два из этих трёх поставщиков браузеров также являются и крупными игроками в бизнесе компьютерных операционных систем, граница между браузером и операционной системой имеет тенденцию размываться.


Несколько лет назад Microsoft, как и другие поставщики, включила сотни УЦ в корневое хранилище (Trusted Root Store) своей операционной системы Windows. Пользователи, изучавшие соотвествующий интерфейс могли просматривать и управлять полным списком УЦ. Однако в ответ на критику от крупных корпоративных пользователей, Microsoft уменьшила число сертификатов в доверенном хранилище в последующих версиях ОС до считанных единиц.


Бывший менеджер по выпуску Internet Explorer заявлял, что "крайне малое число энтерпрайз-компаний, которые выбирали контроль над своим уровнем доверия, испытывали беспокойство по поводу того, что хранилище из 70-100 корневых УЦ может быть источником потенциальных злоупотреблений. По этим и другим причинам Microsoft впоследствии уменьшило число корневых сертификатов в доверенном хранилище [10]."


Для наивного пользователя (или исследователя по вопросам безопасности) на основе сравнения через пользовательский интерфейс различных баз данных УЦ, предоставляемых Microsoft, Apple и Mozilla легко придти к выводу о том, что Microsoft подходит более тщательно к вопросу доверия УЦ, чем конкуренты, поскольку пользовательский интерфейс свежеустановленной Windows Vista или Windows 7 будет содержать менее 15 УЦ в доверенном корневом хранилище ОС. К сожалению, этот интерфейс чрезвычайным образом вводит в заблуждение, поскольку он не показывает факты того, что Microsoft выбрало доверие к 264 различным УЦ. Собственная документация компании гласит, что:


Корневые сертификаты обновляются в Windows Vista [и Windows 7] автоматически. Как только пользователь посещает защищённый вэбсайт (при использовании HTTPS SSL [...] и сталкивается с новым корневым сертификатом, программное обеспечения Windows для проверки цепочек сертификатов проверяет подходящие обновления Microsoft для корневого сертификата. Если он находится, то он загружается в систему. Для пользователя это проходит как непрерывная операция. Пользователь не видит никаких диалоговых окон или предупреждений безопасности. Загрузка происходит автоматически, вне поля зрения [7] )

Таким образом, любой вэб-браузер, который зависит от доверенного хранилища сертификатов Microsoft (такой как Internet Explorer, Chrome или Safari под Windows) беспрекословно доверяет 264 различным УЦ, выдающим сертификаты, без предупреждения, хотя лишь малая часть из них показана в списке пользовательского интерфейса операционной системы. Несмотря на то, что Microsoft ясно описывает это в своей сетевой документации для разработчиков [7], никакого упоминания об этом важном выборе в проектировании браузера или в пользовательском интерфейсе управления сертификатами операционной системы не встречается, там где интересующиеся пользователи имели бы больше всего шансов это заметить.

2.3 Человек посредине



"Любой вэбсайт, защищённый TLS может быть подменён при использовании подложного сертификата, выданного недобросовестным УЦ. Это безотносительно того, какой УЦ выдавал подлинный сертификат вэбсайту и любого свойства этого сертификата"
— Марк Стивенс и др.[11]

В то время как подробное рассмотрение атак человека посредине против SSL выходит за рамки данной статьи, мы по крайней мере дадим краткое введение в тему. За последние годы протокол SSL был предметом серии успешных атак исследователей в области безопасности, некоторых, за счёт преимущественно фундаментальных изъянов протокола и других, фокусировавшихся на социальной инженерии и других техниках введения в заблуждение [12, 13].


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


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


Исследователь по вопросам безопасности Мокси Мэрлинспайк регулярно атаковал SSL, основываясь на цепочках доверия, обнаруживая эксплойты, влияющие как на уязвимости в дизайне браузеров, так и атаки социальной инженерии против конечных пользователей. Его утилиты sslsniff [14] и sslstrip [15] автоматизируют задачи выполнения атак человека-посредине, и при возможности оснащения действительным сертификатом (например полученным от недобросовестного УЦ), могут быть использованы для перехвата пользовательских коммуникаций без того, чтобы вызвать какие-либо предупреждения со стороны браузера.


Назад | Оглавление | Дальше


 
Комментариев нет [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3