The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В рамках проекта DNSCrypt представлена технология шифрования DNS-трафика

08.12.2011 19:54

Компания OpenDNS анонсировала проект DNSCrypt, в рамках которого продвигается новый способ защиты от атак, связанных с модификацией и манипулированием транзитным трафиком DNS. Основная задача DNSCrypt - полное шифрование всего канала связи между клиентом и сервером DNS, примерно как SSL используется для шифрования HTTP-трафика. Шифрование DNS-трафика позволит защитить клиента от атак "человек посередине", при которых злоумышленник вклинивается в канал связи и притворяется DNS-сервером. Кроме того, шифрование предотвращает наблюдение за трафиком и блокирует активность злоумышленников, связанную с подбором идентификаторов пакетов или отправкой фиктивных DNS-ответов.

DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение аутентификации, верификации и гарантирования получения исходных данных, но не предоставляет средств для шифрования передаваемых данных. От проекта DNSCurve, осуществляющего полный цикл шифрования всех запросов DNS, DNSCrypt отличается значительным упрощением как реализации, так и конфигурации. DNSCrypt ориентирован только на шифрование канала связи между пользователем и резолвером DNS, не затрагивая при этом шифрование данных между DNS серверами. Вместо RSA DNSCrypt использует реализацию алгоритма Curve25519 (шифрование по эллиптическим кривым).

Серверная часть DNSCrypt выполнена в виде прокси, поддерживающего работу на большинстве серверных систем, включая OpenBSD, NetBSD, Dragonfly BSD, FreeBSD, Linux и Mac OS X. DNSCrypt не поддерживает кэширование, поэтому разработчики рекомендуют использовать его в сочетании с поддерживающими кэширование резолверами, такими как Unbound, PowerDNS и dnscache. Для обхода фильтров DNSCrypt может организовать канал связи с клиентом поверх TCP, используя порт 443, обычно используемый для HTTPS. Клиентская часть пока поддерживает только Mac OS X. Код всех компонентов открыт под ISC-подобной лицензией, используемой в таких продуктах как DNS-сервер BIND.

  1. Главная ссылка к новости (http://blog.opendns.com/2011/1...)
  2. OpenNews: В BIND 10, кроме DNS, будет интегрирован DHCP-сервер
  3. OpenNews: Консорциум ISC представил реализацию технологии пассивного DNS
  4. OpenNews: Основатель Pirate Bay намерен создать альтернативную службу DNS
  5. OpenNews: Пол Викси предлагает использовать концепцию DNSBL для борьбы с мошенниками
  6. OpenNews: Релиз OpenDNSSEC, пакета для автоматизации процесса создания DNSSEC записей
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/32503-dns
Ключевые слова: dns, security, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 21:19, 08/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    объясните на пальцах, чем велосипед лучше/дополняет dnssec ?
     
     
  • 2.3, Sw00p aka Jerom (?), 21:32, 08/12/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    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.

    стоило сначало на сайт заглянуть

     
     
  • 3.5, x0r (??), 23:48, 08/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    зачем нужно шифрование, если достаточно цифровой подписи?
    DNS информация секретна? Разве цифровой подписи не достаточно чтобы проверить отправителя и целостность?
     
     
  • 4.24, Аноним (-), 12:17, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > DNS информация секретна?

    Хаха, вот сходил ты на superpupermegazooporn.com и запалился :). Хотя нынче актуальнее пожалуй что-нибудь про выборы и их результаты.

     
     
  • 5.29, Sas (ok), 12:44, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ваш ссылка не открывается!
    Веб-страница недоступна
    :)
     
     
  • 6.39, Аноним (-), 16:44, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И тем не менее теперь все, кому было интересно, знают, что вы пытались зайти на сайт с таким названием, хоть его и нет :)
     
     
  • 7.40, Sas (ok), 16:57, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > И тем не менее теперь все, кому было интересно, знают, что вы
    > пытались зайти на сайт с таким названием, хоть его и нет
    > :)

    Пусть знают.
    У меня паранойя не сильно развита.
    если чего отмажусь скажу, что гента за обновлениями лазила

     
  • 4.44, Sw00p aka Jerom (?), 22:45, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    в случае с цифровой подписью - нужны дополнительные расходы - сервера проверки
    а с шифрованием канала тебе никаких серверов не нужно

    цифровая подпись вещь хорошая она защитит от поддельных днс серверов

     
     
  • 5.46, AdVv (ok), 10:21, 10/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вау ! Шифрование у нас теперь менее ресурсоемкая операция чем проверка ЭЦП ? Мужики то не знают... И давно ?
     
  • 2.4, Аноним (-), 22:10, 08/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В новости об этом русским языком написано:

    DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение аутентификации, верификации и гарантирования получения исходных данных, но не предоставляет средств для шифрования передаваемых данных.

     
     
  • 3.11, Pahanivo (ok), 07:37, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В новости об этом русским языком написано:
    > DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение
    > аутентификации, верификации и гарантирования получения исходных данных, но не предоставляет
    > средств для шифрования передаваемых данных
    .

    вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда еще и существует механизм афентикации/афторизации ?

     
     
  • 4.12, AlexAT (ok), 07:58, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    > еще и существует механизм афентикации/афторизации ?

    Нахрена? Чтобы у желающих поглядеть, чего же вот этот товарищ ресолвил, руки отсохли. Вкупе с HTTPS вполне нормальная мера.

     
     
  • 5.14, Аноним (-), 09:04, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    >> еще и существует механизм афентикации/афторизации ?
    > Нахрена? Чтобы у желающих поглядеть, чего же вот этот товарищ ресолвил, руки
    > отсохли. Вкупе с HTTPS вполне нормальная мера.

    Да, HTTPS показывает себя во всей красе последний год. И его системообразующие концепции - в особенности.

     
     
  • 6.35, Pahanivo (ok), 16:16, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    >>> еще и существует механизм афентикации/афторизации ?
    > Да, HTTPS показывает себя во всей красе последний год. И его системообразующие
    > концепции - в особенности.

    +1

    >> Нахрена? Чтобы у желающих поглядеть, чего же вот этот товарищ ресолвил, руки
    >> отсохли. Вкупе с HTTPS вполне нормальная мера.

    эти желающие, как правило, ограничены лишь сетью вашего провайдера - благо вы вероятнее их ДНС используете, что собственно сильно ограничивает возможности снифа извне, а провайдер ваш - дак он вас и так сдаст ))

     
     
  • 7.41, AlexAT (ok), 17:02, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > эти желающие, как правило, ограничены лишь сетью вашего провайдера - благо вы
    > вероятнее их ДНС используете, что собственно сильно ограничивает возможности снифа извне,
    > а провайдер ваш - дак он вас и так сдаст ))

    Увы и ах - у меня свой ресолвер. Хомячкам может и не надо, а вот тем, кто имеет развёрнутые домашние сети - пригодится.

     
     
  • 8.45, Pahanivo (ok), 22:48, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    хомячкам естно не надо, а вот людям, имеющим свой резолвер, можно например научи... текст свёрнут, показать
     
  • 4.15, Аноним (-), 10:52, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    > еще и существует механизм афентикации/афторизации ?

    От атак man-in-middle DNSSEC не спасает.

     
     
  • 5.19, Аноним (-), 11:32, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    это ещё почему ?
    записи в зоне подписаны - этого достаточно для защиты от mitm.

    а шифровать днс траффик... смысл ?

     
     
  • 6.36, Pahanivo (ok), 16:20, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > а шифровать днс траффик... смысл ?

    надо же куда девать простаивающие петафлопсы .... :)

     
  • 5.31, Аноним (-), 14:49, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Спасет. Там же дерево, а ключи от корня распространяются отдельно.

    Смысл DNSCrypt в другом.

     
  • 4.25, Аноним (-), 12:18, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    > еще и существует механизм афентикации/афторизации ?

    А, собственно, далеко не факт что я хочу информировать все транзитные узлы до днс-сервера о том чего это я там резольвил. Случаи бывают разные. Бывают любители цензуры. Бывают любители репрессий. Бывают ушибленные на голову правительства и что там еще.

     
     
  • 5.37, Pahanivo (ok), 16:21, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    >> еще и существует механизм афентикации/афторизации ?
    > А, собственно, далеко не факт что я хочу информировать все транзитные узлы
    > до днс-сервера о том чего это я там резольвил. Случаи бывают
    > разные. Бывают любители цензуры. Бывают любители репрессий. Бывают ушибленные на голову
    > правительства и что там еще.

    большинство таких транзитных узлов как правило принадлежат вам

     
     
  • 6.38, Pahanivo (ok), 16:23, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>> вот в том и вопрос - нахрена шифровать _НЕ_ секретные данные, когда
    >>> еще и существует механизм афентикации/афторизации ?
    >> А, собственно, далеко не факт что я хочу информировать все транзитные узлы
    >> до днс-сервера о том чего это я там резольвил. Случаи бывают
    >> разные. Бывают любители цензуры. Бывают любители репрессий. Бывают ушибленные на голову
    >> правительства и что там еще.
    > большинство таких транзитных узлов как правило принадлежат вам

    к тому же факт резолва еще ничего не доказывает - да банер там подгружался и ниипет

     
  • 2.18, Аноним (-), 11:30, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    в dnssec стоит очень серьезный вопрос как защитить трафик от резолвера до клиента. если, благодаря dnssec, отравить кэш резолверу сложно, то отравить кэш стаб-резолверу на стороне клиента все вполне по силам.
     
     
  • 3.20, Аноним (-), 11:32, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > в dnssec стоит очень серьезный вопрос как защитить трафик от резолвера до
    > клиента. если, благодаря dnssec, отравить кэш резолверу сложно, то отравить кэш
    > стаб-резолверу на стороне клиента все вполне по силам.

    очевидно научить резолвер клиента использовать dnssec ?

     
     
  • 4.23, Аноним (-), 12:04, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> в dnssec стоит очень серьезный вопрос как защитить трафик от резолвера до
    >> клиента. если, благодаря dnssec, отравить кэш резолверу сложно, то отравить кэш
    >> стаб-резолверу на стороне клиента все вполне по силам.
    > очевидно научить резолвер клиента использовать dnssec ?

    в этом случае очевидно, что серьезно повысится нагрузка на авторитетные серверы, что не очень нравится людям, пишущим стандарты (все они таки или иначе являются игроками на рынке DNS услуг). кроме того, в этом случае проще полностью перенести резолвер на сторону клиента, что конечно не может понравиться opendns, потому как они становятся не нужны.

     

  • 1.6, Аноним (-), 00:10, 09/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если я правильно понял, то нужна поддержка на стороне клиента, что займет много лет.
     
     
  • 2.7, Ищавин (?), 04:42, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, на OS X уже есть. Работает более-менее, но при установке VPN соединения возможность подключения к прокси пропадает.
     
     
  • 3.28, Аноним (-), 12:27, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, на OS X уже есть.

    Угу, осталось сущая фигня - MS убедить что им нужно (всякие там линуксоиды и сами убедятся, пожалуй).

     

  • 1.8, VolanD (ok), 05:34, 09/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >[оверквотинг удален]
    > трафиком DNS. Основная задача DNSCrypt - полное шифрование всего канала связи
    > между клиентом и сервером DNS, примерно как SSL используется для шифрования
    > HTTP-трафика. Шифрование DNS-трафика позволит защитить клиента от атак "человек посередине",
    > при которых злоумышленник вклинивается в канал связи и претворяется DNS-сервером. Кроме
    > того, шифрование предотвращает наблюдение за трафиком и блокирует активность злоумышленников,
    > связанную с подбором идентификаторов пакетов или отправкой фиктивных DNS-ответов.
    > DNSCrypt дополняет собой технологию DNSSEC, которая в первую очередь нацелена на обеспечение
    > аутентификации, верификации и гарантирования получения исходных данных, но не предоставля...
    > URL: http://blog.opendns.com/2011/12/06/dnscrypt-%E2%80%93-critical
    > Новость: http://www.opennet.me/opennews/art.shtml?num=32503

    С приходом v6 необходимость шифровать днс трафик отпадет?

     
     
  • 2.16, Аноним (-), 11:02, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >С приходом v6 необходимость шифровать днс трафик отпадет?

    С чего это вдруг?

     
     
  • 3.17, VolanD (ok), 11:11, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>С приходом v6 необходимость шифровать днс трафик отпадет?
    > С чего это вдруг?

    Дык вроде же в него хотели ипсек впилить?

     
     
  • 4.26, Аноним (-), 12:20, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Дык вроде же в него хотели ипсек впилить?

    Настраивать ипсек в общем случае является каким-то батхертом.

     
     
  • 5.47, VolanD (ok), 12:26, 10/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Дык вроде же в него хотели ипсек впилить?
    > Настраивать ипсек в общем случае является каким-то батхертом.

    Дык вроде же по дефолту там будет? Или ошибаюсь?

     

  • 1.9, Below (ok), 05:45, 09/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Шифрование DNS-трафика позволит защитить клиента от атак "человек посередине", при которых злоумышленник вклинивается в канал связи и притворяется DNS-сервером

    Не совсем понятно каким образом

     
     
  • 2.10, AlexAT (ok), 07:30, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее всего на базе DNSSEC генерится определенный ключ, который знают только сервер и клиент. В принципе, нормальная практика.
     
     
  • 3.13, Аноним (-), 09:02, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Осталось только понять, на кой это надо.

    Помнится, Брюс говорил, что аутентификация важнее шифрования. ИМХО это как раз тот самый случай. А шифрование тут уже как у зайца стоп-сигнал - костыль костылей. Причем годится разве что для самоуспокоения. В свете наличия Теслы и появления все более и более мощных числогрызок.

     
     
  • 4.27, Аноним (-), 12:21, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Теслы и появления все более и более мощных числогрызок.

    Хорошему шифрованию числогрызки не по чем. Не, ну des с ключом 56 битов вы даже за пару дней раздолбаете. А с шифрование с ключом 256 битов будете долбить до конца времен...

     
     
  • 5.48, Pahanivo (ok), 13:33, 10/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Хорошему шифрованию числогрызки не по чем. Не, ну des с ключом 56
    > битов вы даже за пару дней раздолбаете. А с шифрование с
    > ключом 256 битов будете долбить до конца времен...

    шифрование то, дорогой, тоже весчЬ не бесплатная, об этом кагбы забывать не надо.

     

  • 1.21, Аноним (-), 11:55, 09/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Тоже не вижу смысла шифровать DNS-трафик. Подписать DNS запрос - да, имеет смысл. А вот шифровать - нет. Потому что:

    - DNS не содержит объекта защиты, ведь он публичный;

    - после DNS-запроса происходит запрос к отрезолвленному ip-адресу, т.е. человек посередине сможет с высокой вероятностью определить результат резолва независимо от того зашифрован DNS-ответ или нет.

     
     
  • 2.32, Аноним (-), 14:56, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > - DNS не содержит объекта защиты, ведь он публичный;

    То, что есть сайты про события на площади Тяньаймень — не секрет даже для компартии КНР. Но то, что простой китайский гражданин Ляо идет их читать — уже не скажешь, что публичная информация.

    Чуете разницу?

     
  • 2.33, AlexAT (ok), 14:58, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > - после DNS-запроса происходит запрос к отрезолвленному ip-адресу, т.е. человек посередине
    > сможет с высокой вероятностью определить результат резолва независимо от того зашифрован
    > DNS-ответ или нет.

    Ну-ка, определите мне результат ресолва на мастерхосте...

     

  • 1.22, Аноним (-), 11:59, 09/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подскажите, пожалуйста, зачем "человеку посередине" обманывать DNS? Он ведь может взять себе любой IP и стать нужным сервером. На чём, собственно, в любом случае попадётся при наличии HTTPS (или подобного протокола). Кстати, тот же HTTPS требует отдельного IP так как занимает весь 443 порт (в отличии от HTTP, где много хостов). А это значит, что "человек посередине" поймёт с каким хостом была установлена связь.
     
     
  • 2.30, Stax (ok), 14:24, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    HTTPS не требует отдельного IP и не "занимает весь порт". Не тешьте себя иллюзиями. То, что апач исторически это не поддерживает не означает, что это не делается - просто в первых версиях SSL не было расширения, позволяющего такую штуку, а в апаче на это завязались и спроектировали все так, что оказалось "невозможно" с mod_ssl. Уже много лет это возможно, с mod_gnutls или как его там, или с другими веб-серверами.

    http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
    http://en.wikipedia.org/wiki/Server_Name_Indication

     
     
  • 3.42, Аноним (-), 17:33, 09/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >HTTPS не требует отдельного IP

    Ещё лучше. Теперь он шлёт имя хоста открытым текстом, да?
    Вы читали с чего начался вопрос?

     

  • 1.43, loglog (?), 19:38, 09/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Насколько тяжело это будет для сервера? И не возникнет ли тоже что и с SSL? когда вычислительные нагрузки в протоколе распределены не в пользу сервера?
     
     
  • 2.49, ryzhov_al (?), 22:45, 12/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Собрал для роутера, проверил под типовой нагрузкой, проблем нет.
    http://www.wl500g.info/showpost.php?p=246603&postcount=347
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру