Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Если принять во внимание число корневых сертификатов, вшитых... 13.04.06 20:45 Число просмотров: 2932
Автор: sattva Статус: Незарегистрированный пользователь
|
> > популярной почтовой службы. С кем поделиться? ;) Для
> атаки
> > на Firefox/Mozilla не подойдёт (CACert в хранилище
> браузера
> > отсутствует), но против Эксплорера -- вполне.
>
> Если учесть сегмент рынка, занимаемый эксплорером, то даже
> если CACert - единственный, кто не синхронизируется (что
> вряд ли), то все равно весьма серьезная уязвимость
Если принять во внимание число корневых сертификатов, вшитых в эксплорер, я вообще слабо себе представляю, как бы удостоверяющие центры сверяли друг с другом списки заверенных сертификатов. Видимо, логика PKI и действующих УЦ исходит из допущения, что раз уж установить SSL-сертификат на сервер может только администратор, то не стоит и беспокоиться.
В порядке лирического отступления хочу вспомнить случай, обсуждавшийся пару лет назад в списке рассылки шифрпанков, когда корневой сертификат доверенного для эксплорера какого-то малоизвестного УЦ был продан с молотка вместе с остальной собственностью этого УЦ после его банкротства. Название УЦ забыл, но это и не важно.
Конечно, я не оригинален. В последние годы не плевал в PKI только ленивый. :)
|
|
<theory>
|
Спуфинг SSL-защищённых серверов 12.04.06 13:40
Автор: sattva Статус: Незарегистрированный пользователь
|
Господа, верно ли я себе представляю возможный сценарий атаки на SSL-защищённый веб-сервис для некоторого пользователя (это может быть фишинг-атака или нечто подобное)?
1. Противник взламывает DNS-сервер интернет-провайдера целевого пользователя или иной DNS, близко расположенный к пользователю и кэширующий его запросы.
2. Для данного доменного имени он заменяет IP-адрес легитимного сервера IP-адресом подконтрольного ему сервера.
3. Поскольку легитимный сервер использует SSL-сертификат известного удостоверяющего центра, оппонент заказывает у другого УЦ (чей корневой сертификат имеется в хранилище браузера пользователя) сертификат для того же доменного имени (допустим, этими УЦ являются VeriSign и Thawte).
4. Оппонент устанавливает "поддельный" сертификат на свой сервер.
5. При обращении к легитимному серверу пользователь будет перенаправлен (благодаря подмене в DNS-таблице) на подставной сервер, подконтрольный противнику. Поскольку сертификат этого сервера также заверен ключом доверенного УЦ, пользователь не заметит атаки и будет считать, что соединение надёжно.
Единственная проблема, которую я вижу (не считая взлома DNS ;)), это если УЦ поддерживает базу своих пользователей и принадлежащих им доменов и для логина в систему и отправки CSR требует логин/пароль, то такой сценарий усложняется.
Чего ещё на ваш взгляд в супе не хватает?
|
|
А вот тут облом :). Root CA не выдаст два сертификата на... 12.04.06 16:37
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> Господа, верно ли я себе представляю возможный сценарий
> атаки на SSL-защищённый веб-сервис для некоторого
> пользователя (это может быть фишинг-атака или нечто
> подобное)?
>
> 1. Противник взламывает DNS-сервер интернет-провайдера
> целевого пользователя или иной DNS, близко расположенный к
> пользователю и кэширующий его запросы.
> 2. Для данного доменного имени он заменяет IP-адрес
> легитимного сервера IP-адресом подконтрольного ему сервера.
> 3. Поскольку легитимный сервер использует SSL-сертификат
> известного удостоверяющего центра, оппонент заказывает у
> другого УЦ (чей корневой сертификат имеется в хранилище
> браузера пользователя) сертификат для того же доменного
> имени (допустим, этими УЦ являются VeriSign и Thawte).
А вот тут облом :). Root CA не выдаст два сертификата на одно имя разным людям.
> 4. Оппонент устанавливает "поддельный" сертификат на свой
> сервер.
> 5. При обращении к легитимному серверу пользователь будет
> перенаправлен (благодаря подмене в DNS-таблице) на
> подставной сервер, подконтрольный противнику. Поскольку
> сертификат этого сервера также заверен ключом доверенного
> УЦ, пользователь не заметит атаки и будет считать, что
> соединение надёжно.
>
> Единственная проблема, которую я вижу (не считая взлома DNS
> ;)), это если УЦ поддерживает базу своих пользователей и
> принадлежащих им доменов и для логина в систему и отправки
> CSR требует логин/пароль, то такой сценарий усложняется.
именно так и есть. только там нету по-моему никакого логина/пароля.
> Чего ещё на ваш взгляд в супе не хватает?
|
| |
А два разных рута? 12.04.06 20:03
Автор: amirul <Serge> Статус: The Elderman
|
> А вот тут облом :). Root CA не выдаст два сертификата на
> одно имя разным людям.
Если они действуют сообща, то конечно. Вопрос: ты уверен, что они обмениваются базами подписей?
|
| | |
В своём первом мессе я как раз о двух разных УЦ говорил,... 13.04.06 16:07
Автор: sattva Статус: Незарегистрированный пользователь
|
> > А вот тут облом :). Root CA не выдаст два сертификата
> на
> > одно имя разным людям.
>
> Если они действуют сообща, то конечно. Вопрос: ты уверен,
> что они обмениваются базами подписей?
В своём первом мессе я как раз о двух разных УЦ говорил, что, видимо, не заметил первый отвечающий.
Любопытства ради сформировал CSR для gmail.com и передал его в CACert. Теперь имею SSL-сертификат X.509 для популярной почтовой службы. С кем поделиться? ;) Для атаки на Firefox/Mozilla не подойдёт (CACert в хранилище браузера отсутствует), но против Эксплорера -- вполне.
|
| | | |
Да, теперь понял идею. Это ужас. Единственное что я не нашел... 14.04.06 18:09
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> В своём первом мессе я как раз о двух разных УЦ говорил,
> что, видимо, не заметил первый отвечающий.
>
Да, теперь понял идею. Это ужас. Единственное что я не нашел CACert в списке trusted publishers IE. Ты уверен что он там есть?
> Любопытства ради сформировал CSR для gmail.com и передал
> его в CACert. Теперь имею SSL-сертификат X.509 для
> популярной почтовой службы. С кем поделиться? ;) Для атаки
> на Firefox/Mozilla не подойдёт (CACert в хранилище браузера
> отсутствует), но против Эксплорера -- вполне.
|
| | | | |
Действительно, облом. Но на итог вряд ли повлияет 14.04.06 22:11
Автор: sattva Статус: Незарегистрированный пользователь
|
> Да, теперь понял идею. Это ужас. Единственное что я не
> нашел CACert в списке trusted publishers IE. Ты уверен что
> он там есть?
Проверил хранилище. Ты прав, нету CACert. Но всё же я уверен, что при желании найти из всего множества доверенных для эксплорера УЦ такой, который выдаёт "экспресс-сертификаты" (заверяет CSR без веттинга) можно. Нам не обязательно знать, какие доказательства владения требует большинство УЦ; нам нужно найти только одну точку сбоя.
|
| | | |
Я понял, потому и возразил NKritsky 13.04.06 16:58
Автор: amirul <Serge> Статус: The Elderman
|
> В своём первом мессе я как раз о двух разных УЦ говорил,
> что, видимо, не заметил первый отвечающий.
> Любопытства ради сформировал CSR для gmail.com и передал
> его в CACert. Теперь имею SSL-сертификат X.509 для
А вот это интересно. Все таки никакой синхронизации друг с другом они не производят и таким образом теряется вся идея сертификации.
> популярной почтовой службы. С кем поделиться? ;) Для атаки
> на Firefox/Mozilla не подойдёт (CACert в хранилище браузера
> отсутствует), но против Эксплорера -- вполне.
Если учесть сегмент рынка, занимаемый эксплорером, то даже если CACert - единственный, кто не синхронизируется (что вряд ли), то все равно весьма серьезная уязвимость
|
| | | | |
Если принять во внимание число корневых сертификатов, вшитых... 13.04.06 20:45
Автор: sattva Статус: Незарегистрированный пользователь
|
> > популярной почтовой службы. С кем поделиться? ;) Для
> атаки
> > на Firefox/Mozilla не подойдёт (CACert в хранилище
> браузера
> > отсутствует), но против Эксплорера -- вполне.
>
> Если учесть сегмент рынка, занимаемый эксплорером, то даже
> если CACert - единственный, кто не синхронизируется (что
> вряд ли), то все равно весьма серьезная уязвимость
Если принять во внимание число корневых сертификатов, вшитых в эксплорер, я вообще слабо себе представляю, как бы удостоверяющие центры сверяли друг с другом списки заверенных сертификатов. Видимо, логика PKI и действующих УЦ исходит из допущения, что раз уж установить SSL-сертификат на сервер может только администратор, то не стоит и беспокоиться.
В порядке лирического отступления хочу вспомнить случай, обсуждавшийся пару лет назад в списке рассылки шифрпанков, когда корневой сертификат доверенного для эксплорера какого-то малоизвестного УЦ был продан с молотка вместе с остальной собственностью этого УЦ после его банкротства. Название УЦ забыл, но это и не важно.
Конечно, я не оригинален. В последние годы не плевал в PKI только ленивый. :)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
