Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Да, теперь понял идею. Это ужас. Единственное что я не нашел... 14.04.06 18:09 Число просмотров: 2866
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> В своём первом мессе я как раз о двух разных УЦ говорил, > что, видимо, не заметил первый отвечающий. >
Да, теперь понял идею. Это ужас. Единственное что я не нашел CACert в списке trusted publishers IE. Ты уверен что он там есть?
> Любопытства ради сформировал CSR для gmail.com и передал > его в CACert. Теперь имею SSL-сертификат X.509 для > популярной почтовой службы. С кем поделиться? ;) Для атаки > на Firefox/Mozilla не подойдёт (CACert в хранилище браузера > отсутствует), но против Эксплорера -- вполне.
|
<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 только ленивый. :)
|
|
|