зачем нужен 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 тоже подписываются, есть там особый метод.
Так что враг не пройдет, если конечно пользовательскую машину не контролирует :-)