(мрачно) Любой протокол должен максимум через 20 лет редизайниться с нуля

[netch80]

Любой протокол должен максимум через 20 лет редизайниться с нуля.
Сегодняшний пример - DNS. Ну что стоило подумать про 64- или 128-битный ID ещё во время первых атак с подменой ID?

Не хочется кассандрить, но это напоминает начало системного кризиса Internet.

Comments

[sha90w.livejournal.com]

ты на доклад Пилософа намекаешь ? ;)

[dbg.livejournal.com]

Ха! Можно подумать, что интернет хоть когда-то за свою историю был не в кризисе. Всё, как всегда, плохо, но мы опять выкрутимся.

Кстати, ты презентацию Камински читал? Он там очень качественно нагнал жути.

[ospf-ripe.livejournal.com]

В аттаке, про которую рассказал Дэн Каминский ключевой момент не подбор ID (про это писали и раньше с оговоркой что атакующему вряд ли повезет), а то что отравленная запись из секции Additional перезаписывает валидную запись из кэша. Что IMHO проблема не протокола, а реализации популярных ДНС серверов.

Если бы этого не происходило, то аттака была бы малореально - записи которые интересно подменять обычно часто спрашиваются и всегда есть в кэше. Нужно было бы дождаться пока кэш протухнет и за несколько секунд пока туда запись не попадет снова его отравить.

[dbg.livejournal.com]

Это проблема протокола.

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

[furry.livejournal.com]

Ну что это за security through obscurity? Протокол должен дизайниться с возможностью масштабирования систем защиты.
Кстати, telnet, например, я не знаю зачем редизайнить..Просто думать надо было сразу, а не во время первых атак..

[t-mike.livejournal.com]

а чем телнет плох? есть к нему и шифрация пароле и ssl

[furry.livejournal.com]

telnet как раз всем хорош, я про это и говорю. В отличие от "более других" протоколов..

[netch80.livejournal.com]

Это, насколько я понимаю, более глобальная проблема. Ты не заставишь ставить фильтры тех, кто этого не хочет.

[netch80.livejournal.com]

> Протокол должен дизайниться с возможностью масштабирования систем защиты.

Тогда накопятся какие-то другие новые требования.

> Кстати, telnet, например, я не знаю зачем редизайнить..Просто думать надо было сразу, а не во время первых атак..

У telnet'а изначальная ошибка проектирования, но не в открытости. То, что он открыт (в стандартном варианте) - не проблема.

[netch80.livejournal.com]

Telnet плох тем, что на его управляющие последовательности нет общего стандарта, который бы позволял по крайней мере опознавать и игнорировать те из них, которые неизвестны реализации на приёмной стороне. Приёмная сторона должна знать длины всех опций, которые могут быть посланы передающей стороной. Кроме того, нет никаких штатных средств выяснить особенности реализации другой стороны. В результате, любое нововведение должно быть одновременно реализовано по всему миру во всех версиях.

На практике есть эмпирические методы обхода этой проблемы (определением свойств групп последовательностей, текстовые посылки требующие ответа), но они ненадёжны.

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

Описанные "фичи" неисправимы без полного редизайна. Поэтому, никакие позднейшие протоколы не базируются на telnet.