id: Гость   вход   регистрация
текущее время 17:24 28/03/2024
создать
просмотр
редакции
ссылки

Это старая редакция страницы Библиотека / Статьи / Certified Lies / Certificate Authoritiesandthe Browser Vendors за 26/03/2010 14:26.


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 Вэб-браузеры


2.2 Web Browsers
There is no technical standard that specifies how
web browsers should select their list of trusted CAs.
As a result, each browser vendor has created their
own set of policies to evaluate and approve CAs [7,
8, 9]. Since there is no evidence to suggest that any
browser has knowingly or incompetently approved a
rogue CA, we do not discuss each particular vendors'
policies in depth.


What does merit further attention is the method

by which the browser vendors deliver and update
their list of root CAs and the in-browser user in-
terface provided to end-users to view and manage
them.

The ma jor browsers (Internet Explorer, Firefox,

Chrome and Safari) have all adopted slightly differ-
ent policies for managing and displaying the list of
trusted CAs: Firefox is the only ma jor browser to
maintain its own database of trusted CAs, while the
other three browsers instead rely upon a list of CAs
provided by the operating system. However, since
two of these three browser vendors are also ma jor
players in the computer operating system business,
the line between browser and operating system tends
to be rather blurry.

In years past, Microsoft, like the other vendors,

included hundreds of CAs in its Windows operat-
ing system Trusted Root Store. Users who discov-
ered the relevant user interface were able to view
and manage the full list of CAs. However, in re-
sponse to criticism from large enterprise customers,
Microsoft reduced the number of certificates in the
trusted store in subsequent OS versions down to just
a handful.4

4
The former product manager for Internet Explorer told

us that "a very few enterprises who chose to control their own
trust decisions raised concerns regarding a trusted store pre-
loaded with 70-100 root CAs as a potential for abuse. For

It would be easy for a naive user (or security

researcher) comparing the various CA databases
through the user interfaces provided by Microsoft,
Apple and Mozilla to conclude that Microsoft has
adopted a far more cautious approach in trusting
CAs than its competitors, since the user interface of
a fresh installation of Windows Vista or Windows 7
will list less than 15 CAs in the operating system's
Trusted Root Store. Unfortunately, this interface is
extremely misleading as it does not reveal the fact
that Microsoft has opted to trust 264 different CAs.
The company's own documentation reveals that:

"Root certificates are updated on Win-
dows Vista [and Windows 7] automatically.
When a user visits a secure Web site (by
using HTTPS SSL) [. . . ] and encounters a
new root certificate, the Windows certifi-
cate chain verification software checks the
appropriate Microsoft Up date lo ca-
tion for the ro ot certificate. If it finds
it, it downloads it to the system. To the
user, the experience is seamless. The user
do es not see any security dialog b oxes
or warnings. The download happ ens
automatically, b ehind the scenes [7]."
Thus, any web browser that depends upon Mi-

crosoft's Trusted Root Store (such as Internet Ex-
plorer, Chrome and Safari for Windows) ultimately
trusts 264 different CAs to issue certificates without
warning, although only a handful of them are listed
in the operating system's user interface. While Mi-
crosoft clearly describes this in its online developer
documentation [7], no mention of this rather impor-
tant design decision is made in the browser or the
operating system certificate management user inter-
face, where interested users are most likely to look.

2.3 Man in The Middle


"Any website secured using TLS can be im-
personated using a rogue certificate issued
by a rogue CA. This is irrespective of which
CA issued the website's true certificate and
of any property of that certificate."
  • - Marc Stevens et al [11].

this and several other reason Microsoft has since reduced the
number of root certificates in the trusted store [10]."

While an exhaustive explanation of man in th

middle attacks against SSL is beyond the scope o
this article, we at least provide a brief introductio
to the sub ject. Over the past few years, the SS
protocol has been sub ject to a series of successfu
attacks by security researchers, some taking advan
tage of fundamental flaws in the protocol, and other
focusing on social engineering and other deceptio
based techniques [12, 13].

It is because SSL protected web connections flo

over a number of other insecure protocols that it i
possible for attackers to intercept and hijack a con
nection to a SSL protected server (these are know
as man in the midd le attacks ). It is only once th
browser has received and verified a site's SSL certifi
cate that the user can be sure that her connectio
is safe.

However, this step alone is often not enough t

protect users. Sites that supply self-signed certifi
cates, or that exploit unpatched vulnerabilities i
the certificate handling code in the browsers can sti
trigger the display of the SSL lock icon, yet with
out providing the user with the associated securit
protections that they would normally expect.

Security researcher Moxie Marlinspike has repeat

edly attacked the SSL based chain of trust, revealin
exploits that leverage both browser design flaws, a
well as social engineering attacks against end-users
His sslsniff [14] and sslstrip [15] tools automate th
task of performing a man-in-the-middle attacks, an
when supplied with a valid SSL certificate (obtaine
via a rogue CA for example), can be used to inter
cept users' communications without triggering an
browser warnings.


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