зачем нужен DNSSEC
Apr. 4th, 2012 09:17 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
natarajНекоторое время назад некоторые товарищи рассказывали что DNSSEC не нужен ибо бесполезен.
Поскольку я изучил эту тему более или менее подробно, могу коротенько рассказать в каком месте он полезен:
DNSSEC нужен для увеличения защищенности шифрованных соединений, от атаки man in the middle
Все мы слышали о случаях когда злоумышленники завладевали сертификатом на * какого-то заштатного серцифицирующего центра (арабского или тому подобное). После этого на основе этого сертификата создавался ложный сертификат на google.com, и трафик жертвы перенаправлялся на сайт злоумышленника подписанный этим сертификатом.
Как от этого может спасти DNSSEC?
DNSSEC в отличии от бессистемных сертифицирующих цетров -- система иерархическая. Если удастся добыть закрытый ключ от арабской зоны, то подписать им получится только домены арабской зоны, com'овский домен им не подпишешь. Добыть же закрытый ключ от корневой зоны -- это вообще что-то из области фантастики, нет в мире столько денег. :-)
В результате в случае если и у клиента и на просматриваемом сайте включен DNSSEC, для злоумышленника становится недоступен механизм перенаправления на зараженный сайт путем DNS-спуфинга.
Если же злоумышленник контроллирует процесс маршрутизации и перенаправит пользователя на ложный сайт на этом уровне, то и тут у DNSSEC'а тоже есть потенциальный ответ: в одной из записей зоны можно хранить fingerprint от актуального SLL сертификата, и велеть браузеру возмущаться при несовпадении. Такой опции сейчас технически не реализовано, но с распространением DNSSEC'а это явно будет так или иначе стандартизировано.
И да, предвидя самый популярный вопрос: вместо подписанной зоны нельзя заспуфить не подписанную: факт подписанности зоны определяется по наличию DS записи у зоны родительской. Если DS есть а зона не подписана -- это ахтунг. Так же нельзя подавить отрицательный ответ на запрос DS записи: отрицательные ответы в DNSSEC тоже подписываются, есть там особый метод.
Так что враг не пройдет, если конечно пользовательскую машину не контролирует :-)
Поскольку я изучил эту тему более или менее подробно, могу коротенько рассказать в каком месте он полезен:
DNSSEC нужен для увеличения защищенности шифрованных соединений, от атаки man in the middle
Все мы слышали о случаях когда злоумышленники завладевали сертификатом на * какого-то заштатного серцифицирующего центра (арабского или тому подобное). После этого на основе этого сертификата создавался ложный сертификат на google.com, и трафик жертвы перенаправлялся на сайт злоумышленника подписанный этим сертификатом.
Как от этого может спасти DNSSEC?
DNSSEC в отличии от бессистемных сертифицирующих цетров -- система иерархическая. Если удастся добыть закрытый ключ от арабской зоны, то подписать им получится только домены арабской зоны, com'овский домен им не подпишешь. Добыть же закрытый ключ от корневой зоны -- это вообще что-то из области фантастики, нет в мире столько денег. :-)
В результате в случае если и у клиента и на просматриваемом сайте включен DNSSEC, для злоумышленника становится недоступен механизм перенаправления на зараженный сайт путем DNS-спуфинга.
Если же злоумышленник контроллирует процесс маршрутизации и перенаправит пользователя на ложный сайт на этом уровне, то и тут у DNSSEC'а тоже есть потенциальный ответ: в одной из записей зоны можно хранить fingerprint от актуального SLL сертификата, и велеть браузеру возмущаться при несовпадении. Такой опции сейчас технически не реализовано, но с распространением DNSSEC'а это явно будет так или иначе стандартизировано.
И да, предвидя самый популярный вопрос: вместо подписанной зоны нельзя заспуфить не подписанную: факт подписанности зоны определяется по наличию DS записи у зоны родительской. Если DS есть а зона не подписана -- это ахтунг. Так же нельзя подавить отрицательный ответ на запрос DS записи: отрицательные ответы в DNSSEC тоже подписываются, есть там особый метод.
Так что враг не пройдет, если конечно пользовательскую машину не контролирует :-)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-04-04 06:50 pm (UTC)"Ну нету подписей у .com, никаких нету, ни у кого".
no subject
Date: 2012-04-04 06:59 pm (UTC)no subject
Date: 2012-04-04 07:00 pm (UTC)Придется распространять открытые ключи всех зон, так?
no subject
Date: 2012-04-04 07:17 pm (UTC)в ней есть ключи от всех зон подписанной ключем корневой зоны.
открытый ключ корневой зоны, попадает на юзерскую станцию вместе с дистрибутивом.
dig @a.root-servers.net. com DS +dnssec
даст тебе подписанный дайджест от открытого ключа зоны .com
no subject
Date: 2012-04-04 07:22 pm (UTC)а система X.509 сертификатов уже фактически дискредитирована.
либо, опять же, эту информацию можно подменить.
no subject
Date: 2012-04-04 07:26 pm (UTC)no subject
Date: 2012-04-04 07:28 pm (UTC)Отличается. Круг организаций выпускающих сертификаты радикально уже. Арабы уже звездочку не подпишут.
либо, опять же, эту информацию можно подменить.
Речь идет только об атаке Man in the Middle. Если есть доступ к машине, то вся прочая безопасность идет лесом.
no subject
Date: 2012-04-05 04:05 am (UTC)Конечно, она нифига не спасет от компрометации ICANN. Но число организаций, которые могут себе такое позволить, сущетвенно меньше, чем число организаций, способных повлиять хотя бы на один из доверенных CA.