The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSEC, opennews (??), 31-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


168. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 31-Янв-24, 16:35 
ессественно новенький админ, которого не курсанули, что при смене ключей необходимо заранее сообщить тов. майору :)
Ответить | Правка | Наверх | Cообщить модератору

251. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sem (??), 01-Фев-24, 19:04 
Если бы новенький админ, то не выпускали бы отчет со смыслом "это не мы такие, это DNSSEC такой. И вообще, переходите все на НСДИ.".
Ответить | Правка | Наверх | Cообщить модератору

252. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sem (??), 01-Фев-24, 19:06 
https://cctld.ru/media/news/kc/35566/
Ответить | Правка | Наверх | Cообщить модератору

261. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sw00p aka Jerom (?), 01-Фев-24, 22:13 
> https://cctld.ru/media/news/kc/35566/

"""
Возникшая коллизия ключей, в причинах которой в настоящее время продолжают разбираться специалисты Технического центра интернет (ТЦИ) и MSK-IX, привела к временной недоступности зоны .RU для части интернет-пользователей.

После обнаружения сбоя обновленные ключи были отозваны, и работоспособность зоны .RU в полном объеме восстановилась, что заняло, включая распространение данных по системе DNS, около двух часов.
""""

Какая нахрен коллизия? коллизия с чем? с каким другим ключем? если ключи независимые. Там можно записи подписывать одновременно обоими ключами (ZSK).

Раздел 4.1.1.2.  Double-Signature Zone Signing Key Rollover
https://www.rfc-editor.org/rfc/rfc6781


Да это все работало даже в том случае если добавили бы один и тот же ключ с другим key_id и подписали бы записи. Какой нафиг отзыв? Это термин из PKI. А что за бред про "в полном объеме восстановилась, что заняло, включая распространение данных по системе DNS,". Никто не кеширует богусную зону. Восстановилась именно сразу после того как "правильно все было переподписано". Хотя по моей версии все там правильно было переподписано, ибо этот процесс происходит каждый квартал. Нового админа не курсанули, чтобы ключи вовремя отослал тов. майору, вот и все.

Ответить | Правка | Наверх | Cообщить модератору

273. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от n00by (ok), 02-Фев-24, 07:56 
Коллизия - это, например, когда хеши от разных данных совпали. Тут требуется квалифицированный конспиролог, способный объяснить, почему поля Галуа весьма далеки от Эйфелевой башни.
Ответить | Правка | Наверх | Cообщить модератору

274. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sw00p aka Jerom (?), 02-Фев-24, 09:23 
- Почему у тебя нос сломан?
- Потому-что он столкнулся (коллизия) с чужим кулаком

Счастливое число Слэвина (ц)

Ответить | Правка | Наверх | Cообщить модератору

275. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sw00p aka Jerom (?), 02-Фев-24, 09:48 
Допускаем, сгенерировали 1024 битный ZSK ключ rsa, его хеш sha256 (ибо algo_id=8) как вы говорите столкнулся c хешем какого ключа? Со старым ключем ZSK? Ну и что?
Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

277. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от n00by (ok), 02-Фев-24, 13:00 
Тут задача из разряда "кто даст правильный ответ - тот получит 10 лет".
Ответить | Правка | Наверх | Cообщить модератору

278. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sw00p aka Jerom (?), 02-Фев-24, 16:00 
> Тут задача из разряда "кто даст правильный ответ - тот получит 10 лет".

ага, "кто купит билетов пачку" ... XD

Обратим внимание на данное утверждение:

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

Вопрос, какого ПО? Сделаю предположение - самописного, своего рода "панель управления", в которой можно сгенерить ключ для зоны и подписать записи. Отсюда:

"""
Как и любое другое технологическое решение, DNSSEC требует усовершенствования с течением времени, чтобы исправить обнаруживаемые ошибки работы.
"""

Вопрос, так DNSSEC требует усовершенствование или ваше "самопальное" ПО?

"""
Возникшая коллизия ключей
"""

Предполагаем возникновение коллизии созданного ключа. Как вы заметили, коллизия с хешем может быть от ключа, но с каким другим ключом? При генерации нового ключа (ZSK) существует ОДИН текущий актуальный активный ключ. Вероятно их ПО при запросе на переподписывании выбирало ключ из (где они там хранят ключи - не знаю) "базы" по хешу ключа, и напоролась на актуальный активный текущий ключ, взяла его и переподписала зону. Если коллизия произошла именно с этим ключем, то в чем проблема? Разве подпись ресурсных записей должна была быть невалидной? Ключ ведь актуальный активный никто ведь не удалял. Может key_tag неверный был у ресурсных записей? - НЕТ. Судя по dnsviz второй ключ был добавлен еще числа 26-го.

256 3 8 AwEAAbjj3GP0TUwaNI7BIIw/fvwKTmdR +oZsEPk64pl8VYn4dfdbGHWpYIooxcgEbuBEYrnC/oqnKhad38nTxrZ9SAK3qV5qShntFdgozS5IKs5m1ebNmg2sotlhXRhJ4vqgH+BQh/lw6T4vdB8FE5tHGE1vwPs9Vhj0vLTBhX8TwB6/ ; key tag = 52263

256 3 8 AwEAAcBtr/w2hP6OQjiCacPFzK6xh0pR 7QsHV9lxprIXG9WBoBB5XWPVc5q17F3yt3wpJ7xmedt80gxVMaicPYNYAa8YUFyMxTGVBDVQlz5gCmXQKlr0yImI78sdwzWNmgKHap0BLypTBVxAKxpcvuwTmqXQUSONkjq9werHvogrvkUb ; key tag = 44301

key tag - по сути должен храниться вместе с ключевой парой, и ситуация с коллизией описанной выше, по идее должна была выставить в качестве key tag в RRSIG не новый key tag = 52263, а "старый" текущий актуальный key tag = 44301.

НО - судя по dnsviz

NS 8 1 345600 20240305102631 20240130141847 52263 ru. kw9oqgvi/l0MZp/6FY0Ha+VZDWRR3+iDUCYqAY5W7D2wCfIXXdOOvdd58nNY7z/3b4fRK6tlTF3wQpCDSpeKrmkWmric4kcUptaj1rp71lC0GHXHmGwDsx8Zi/lvo6sJEk0guBbJYBJkzKqeseD4u1Pw29jkRHhQEJKk2seP+Zk=

у битой сигнатуры был выставлен key tag = 52263 - нового ключа, так почему же она оказалась битой?

Представим примитивное хранение ключевых пар

key_tag, pub_key, priv_key, hash

  44301, pub_cur, priv_cur, hash_cur
  52263, pub_new, priv_new, hash_new

Ну вот тут если hash_cur==hash_new и сделать выборку по hash, то какая разница какой из ключей выбрался бы, результат был бы - валидная сигнатура, ибо ситуация возьми priv_cur (текущий приватный ключ) и выстави key tag от ключа priv_new - ИСКЛЮЧАЕТСЯ!!!.

Так в чем же причина битой сигнатуры? А теперь допустим куда реалистичную ситуацию. Опять представим примитивное хранение ключевых пар:


key_tag, pub_key, priv_key, hash

  44301, pub_cur, priv_cur, hash_cur
  52263, pub_new, priv_new, hash_new
  12345, pub_old, priv_old, hash_old
  22222, pub_001, priv_001, hash_001
  33333, pub_002, priv_002, hash_002
  52263, pub_123, priv_123, hash_123

Допускаем, что они не удаляли старые ключевые пары, и среди ключей коллизия должна была быть не только по hash, но и одновременно по key_tag, так как key_tag в битых сигнатурах был от якобы нового опубликованного ключа. Но коллизия по hash двух 1024 битовых rsa ключевых пар мне кажется мало вероятной, склоняюсь к тому, что коллизия могла произойти по key_tag.

Вывод: Читаем внимательно https://datatracker.ietf.org/doc/html/rfc4034#appendix-B
  
key_tag не обязан быть уникальным, отсюда вся беда с коллизией в том, что НАКОЙ ХРАНИТЬ СТАРЫЕ КЛЮЧИ?

Ответить | Правка | Наверх | Cообщить модератору

281. "Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSE..."  +/
Сообщение от Sw00p aka Jerom (?), 08-Фев-24, 14:43 
для истории

"""
Из письма ТЦИ следует, что сбой длился 30 января с 18:28 до 21:00 мск и затронул сайты в доменных зонах *.RU, .tatar и .дети. Сбой произошёл при замене старого ключа для проверки подлинности записей в файле зоны на новый. Подобные замены — плановые, для домена *.RU они производятся четыре раза в год, очередная началась 24 января. «В результате сбоя конфигурации в системе [30 января при активации нового ключа] оказались две пары ключей с одинаковым keytag (16-битный тег, который вычисляется по алгоритму от данных ключа», — отмечается в разъяснении ТЦИ. Коллизия с одинаковыми keytag в системе в нем объясняется «сбоем программного обеспечения».
"""

https://habr.com/ru/news/792176/

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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