Компания OpenDNS анонсировала (http://blog.opendns.com/2011/12/06/dnscrypt-%E2%80.../) проект DNSCrypt (http://www.opendns.com/technology/dnscrypt/), в рамках которого продвигается новый способ защиты от атак, связанных с модификацией и манипулированием транзитным трафиком DNS. Основная задача DNSCrypt - полное шифрование всего канала связи между клиентом и сервером DNS, примерно как SSL используется для шифрования HTTP-трафика. Шифрование DNS-трафика позволит защитить клиента от атак "человек посередине", при которых злоумышленник вклинивается в канал связи и претворяется DNS-сервером. Кроме того, шифрование предотвращает наблюдение за трафиком и блокирует активность злоумышленников, связанную с подбором идентификаторов пакетов или отправкой фиктивных DNS-ответов.
DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение аутентификации, верификации и гарантирования получения исходных данных, но не предоставля...URL: http://blog.opendns.com/2011/12/06/dnscrypt-%E2%80.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32503
объясните на пальцах, чем велосипед лучше/дополняет dnssec ?
3. What about DNSSEC? Does this eliminate the need for DNSSEC?No. DNSCrypt and DNSSEC are complementary. DNSSEC does a number of things. First, it provides authentication. (Is the DNS record I'm getting a response for coming from the owner of the domain name I'm asking about or has it been tampered with?) Second, DNSSEC provides a chain of trust to help establish confidence that the answers you're getting are verifiable. But unfortunately, DNSSEC doesn't actually provide encryption for DNS records, even those signed by DNSSEC. Even if everyone in the word used DNSSEC, the need to encrypt all DNS traffic would not go away. Moreover, DNSSEC today represents a near-zero percentage of overall domain names and an increasingly smaller percentage of DNS records each day as the Internet grows.
That said, DNSSEC and DNSCrypt can work perfectly together. They aren't conflicting in any way. Think of DNSCrypt as a wrapper around all DNS traffic and DNSSEC as a way of signing and providing validation for a subset of those records. There are benefits to DNSSEC that DNSCrypt isn't trying to address, in fact, we hope DNSSEC adoption grows so that people can have more confidence in the entire DNS infrastructure, not just the link between our customers and OpenDNS.
стоило сначало на сайт заглянуть
зачем нужно шифрование, если достаточно цифровой подписи?
DNS информация секретна? Разве цифровой подписи не достаточно чтобы проверить отправителя и целостность?
> DNS информация секретна?Хаха, вот сходил ты на superpupermegazooporn.com и запалился :). Хотя нынче актуальнее пожалуй что-нибудь про выборы и их результаты.
Ваш ссылка не открывается!
Веб-страница недоступна
:)
И тем не менее теперь все, кому было интересно, знают, что вы пытались зайти на сайт с таким названием, хоть его и нет :)
> И тем не менее теперь все, кому было интересно, знают, что вы
> пытались зайти на сайт с таким названием, хоть его и нет
> :)Пусть знают.
У меня паранойя не сильно развита.
если чего отмажусь скажу, что гента за обновлениями лазила
в случае с цифровой подписью - нужны дополнительные расходы - сервера проверки
а с шифрованием канала тебе никаких серверов не нужноцифровая подпись вещь хорошая она защитит от поддельных днс серверов
Вау ! Шифрование у нас теперь менее ресурсоемкая операция чем проверка ЭЦП ? Мужики то не знают... И давно ?
В новости об этом русским языком написано:DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение аутентификации, верификации и гарантирования получения исходных данных, но не предоставляет средств для шифрования передаваемых данных.
> В новости об этом русским языком написано:
> DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение
> аутентификации, верификации и гарантирования получения исходных данных, но не предоставляет
> средств для шифрования передаваемых данных.вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда еще и существует механизм афентикации/афторизации ?
> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
> еще и существует механизм афентикации/афторизации ?Нахрена? Чтобы у желающих поглядеть, чего же вот этот товарищ ресолвил, руки отсохли. Вкупе с HTTPS вполне нормальная мера.
>> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
>> еще и существует механизм афентикации/афторизации ?
> Нахрена? Чтобы у желающих поглядеть, чего же вот этот товарищ ресолвил, руки
> отсохли. Вкупе с HTTPS вполне нормальная мера.Да, HTTPS показывает себя во всей красе последний год. И его системообразующие концепции - в особенности.
>>> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
>>> еще и существует механизм афентикации/афторизации ?
> Да, HTTPS показывает себя во всей красе последний год. И его системообразующие
> концепции - в особенности.+1
>> Нахрена? Чтобы у желающих поглядеть, чего же вот этот товарищ ресолвил, руки
>> отсохли. Вкупе с HTTPS вполне нормальная мера.эти желающие, как правило, ограничены лишь сетью вашего провайдера - благо вы вероятнее их ДНС используете, что собственно сильно ограничивает возможности снифа извне, а провайдер ваш - дак он вас и так сдаст ))
> эти желающие, как правило, ограничены лишь сетью вашего провайдера - благо вы
> вероятнее их ДНС используете, что собственно сильно ограничивает возможности снифа извне,
> а провайдер ваш - дак он вас и так сдаст ))Увы и ах - у меня свой ресолвер. Хомячкам может и не надо, а вот тем, кто имеет развёрнутые домашние сети - пригодится.
>> эти желающие, как правило, ограничены лишь сетью вашего провайдера - благо вы
>> вероятнее их ДНС используете, что собственно сильно ограничивает возможности снифа извне,
>> а провайдер ваш - дак он вас и так сдаст ))
> Увы и ах - у меня свой ресолвер. Хомячкам может и не
> надо, а вот тем, кто имеет развёрнутые домашние сети - пригодится.хомячкам естно не надо, а вот людям, имеющим свой резолвер, можно например научиться использовать форвард ...
> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
> еще и существует механизм афентикации/афторизации ?От атак man-in-middle DNSSEC не спасает.
это ещё почему ?
записи в зоне подписаны - этого достаточно для защиты от mitm.а шифровать днс траффик... смысл ?
> а шифровать днс траффик... смысл ?надо же куда девать простаивающие петафлопсы .... :)
Спасет. Там же дерево, а ключи от корня распространяются отдельно.Смысл DNSCrypt в другом.
> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
> еще и существует механизм афентикации/афторизации ?А, собственно, далеко не факт что я хочу информировать все транзитные узлы до днс-сервера о том чего это я там резольвил. Случаи бывают разные. Бывают любители цензуры. Бывают любители репрессий. Бывают ушибленные на голову правительства и что там еще.
>> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
>> еще и существует механизм афентикации/афторизации ?
> А, собственно, далеко не факт что я хочу информировать все транзитные узлы
> до днс-сервера о том чего это я там резольвил. Случаи бывают
> разные. Бывают любители цензуры. Бывают любители репрессий. Бывают ушибленные на голову
> правительства и что там еще.большинство таких транзитных узлов как правило принадлежат вам
>>> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
>>> еще и существует механизм афентикации/афторизации ?
>> А, собственно, далеко не факт что я хочу информировать все транзитные узлы
>> до днс-сервера о том чего это я там резольвил. Случаи бывают
>> разные. Бывают любители цензуры. Бывают любители репрессий. Бывают ушибленные на голову
>> правительства и что там еще.
> большинство таких транзитных узлов как правило принадлежат вамк тому же факт резолва еще ничего не доказывает - да банер там подгружался и ниипет
в dnssec стоит очень серьезный вопрос как защитить трафик от резолвера до клиента. если, благодаря dnssec, отравить кэш резолверу сложно, то отравить кэш стаб-резолверу на стороне клиента все вполне по силам.
> в dnssec стоит очень серьезный вопрос как защитить трафик от резолвера до
> клиента. если, благодаря dnssec, отравить кэш резолверу сложно, то отравить кэш
> стаб-резолверу на стороне клиента все вполне по силам.очевидно научить резолвер клиента использовать dnssec ?
>> в dnssec стоит очень серьезный вопрос как защитить трафик от резолвера до
>> клиента. если, благодаря dnssec, отравить кэш резолверу сложно, то отравить кэш
>> стаб-резолверу на стороне клиента все вполне по силам.
> очевидно научить резолвер клиента использовать dnssec ?в этом случае очевидно, что серьезно повысится нагрузка на авторитетные серверы, что не очень нравится людям, пишущим стандарты (все они таки или иначе являются игроками на рынке DNS услуг). кроме того, в этом случае проще полностью перенести резолвер на сторону клиента, что конечно не может понравиться opendns, потому как они становятся не нужны.
Если я правильно понял, то нужна поддержка на стороне клиента, что займет много лет.
Ну, на OS X уже есть. Работает более-менее, но при установке VPN соединения возможность подключения к прокси пропадает.
> Ну, на OS X уже есть.Угу, осталось сущая фигня - MS убедить что им нужно (всякие там линуксоиды и сами убедятся, пожалуй).
>[оверквотинг удален]
> трафиком DNS. Основная задача DNSCrypt - полное шифрование всего канала связи
> между клиентом и сервером DNS, примерно как SSL используется для шифрования
> HTTP-трафика. Шифрование DNS-трафика позволит защитить клиента от атак "человек посередине",
> при которых злоумышленник вклинивается в канал связи и претворяется DNS-сервером. Кроме
> того, шифрование предотвращает наблюдение за трафиком и блокирует активность злоумышленников,
> связанную с подбором идентификаторов пакетов или отправкой фиктивных DNS-ответов.
> DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение
> аутентификации, верификации и гарантирования получения исходных данных, но не предоставля...
> URL: http://blog.opendns.com/2011/12/06/dnscrypt-%E2%80.../
> Новость: http://www.opennet.me/opennews/art.shtml?num=32503С приходом v6 необходимость шифровать днс трафик отпадет?
>С приходом v6 необходимость шифровать днс трафик отпадет?С чего это вдруг?
>>С приходом v6 необходимость шифровать днс трафик отпадет?
> С чего это вдруг?Дык вроде же в него хотели ипсек впилить?
> Дык вроде же в него хотели ипсек впилить?Настраивать ипсек в общем случае является каким-то батхертом.
>> Дык вроде же в него хотели ипсек впилить?
> Настраивать ипсек в общем случае является каким-то батхертом.Дык вроде же по дефолту там будет? Или ошибаюсь?
>Шифрование DNS-трафика позволит защитить клиента от атак "человек посередине", при которых злоумышленник вклинивается в канал связи и притворяется DNS-серверомНе совсем понятно каким образом
Скорее всего на базе DNSSEC генерится определенный ключ, который знают только сервер и клиент. В принципе, нормальная практика.
Осталось только понять, на кой это надо.Помнится, Брюс говорил, что аутентификация важнее шифрования. ИМХО это как раз тот самый случай. А шифрование тут уже как у зайца стоп-сигнал - костыль костылей. Причем годится разве что для самоуспокоения. В свете наличия Теслы и появления все более и более мощных числогрызок.
> Теслы и появления все более и более мощных числогрызок.Хорошему шифрованию числогрызки не по чем. Не, ну des с ключом 56 битов вы даже за пару дней раздолбаете. А с шифрование с ключом 256 битов будете долбить до конца времен...
> Хорошему шифрованию числогрызки не по чем. Не, ну des с ключом 56
> битов вы даже за пару дней раздолбаете. А с шифрование с
> ключом 256 битов будете долбить до конца времен...шифрование то, дорогой, тоже весчЬ не бесплатная, об этом кагбы забывать не надо.
Тоже не вижу смысла шифровать DNS-трафик. Подписать DNS запрос - да, имеет смысл. А вот шифровать - нет. Потому что:- DNS не содержит объекта защиты, ведь он публичный;
- после DNS-запроса происходит запрос к отрезолвленному ip-адресу, т.е. человек посередине сможет с высокой вероятностью определить результат резолва независимо от того зашифрован DNS-ответ или нет.
> - DNS не содержит объекта защиты, ведь он публичный;То, что есть сайты про события на площади Тяньаймень — не секрет даже для компартии КНР. Но то, что простой китайский гражданин Ляо идет их читать — уже не скажешь, что публичная информация.
Чуете разницу?
> - после DNS-запроса происходит запрос к отрезолвленному ip-адресу, т.е. человек посередине
> сможет с высокой вероятностью определить результат резолва независимо от того зашифрован
> DNS-ответ или нет.Ну-ка, определите мне результат ресолва на мастерхосте...
Подскажите, пожалуйста, зачем "человеку посередине" обманывать DNS? Он ведь может взять себе любой IP и стать нужным сервером. На чём, собственно, в любом случае попадётся при наличии HTTPS (или подобного протокола). Кстати, тот же HTTPS требует отдельного IP так как занимает весь 443 порт (в отличии от HTTP, где много хостов). А это значит, что "человек посередине" поймёт с каким хостом была установлена связь.
HTTPS не требует отдельного IP и не "занимает весь порт". Не тешьте себя иллюзиями. То, что апач исторически это не поддерживает не означает, что это не делается - просто в первых версиях SSL не было расширения, позволяющего такую штуку, а в апаче на это завязались и спроектировали все так, что оказалось "невозможно" с mod_ssl. Уже много лет это возможно, с mod_gnutls или как его там, или с другими веб-серверами.http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
http://en.wikipedia.org/wiki/Server_Name_Indication
>HTTPS не требует отдельного IPЕщё лучше. Теперь он шлёт имя хоста открытым текстом, да?
Вы читали с чего начался вопрос?
Насколько тяжело это будет для сервера? И не возникнет ли тоже что и с SSL? когда вычислительные нагрузки в протоколе распределены не в пользу сервера?
Собрал для роутера, проверил под типовой нагрузкой, проблем нет.
http://www.wl500g.info/showpost.php?p=246603&postcount=347