Реплика: история с сертификатом Jabber.ru и “управление доверием”
В свете нашумевшей атаки на Jabber.ru (с перехватом TLS) нередко пишут, будто эта атака показала, что “система хорошо известных (публичных) удостоверяющих центров TLS не вызывает доверия”. Атака, конечно, такое показала, но с уточнениями: “система хорошо известных УЦ” и раньше должна бы “вызывать доверие” равно в пределах разумной модели угроз, то есть – доверять ей можно только в сугубо определённых, узких случаях. И нельзя расширительно толковать возможности УЦ – это как раз большая ошибка, но весьма распространённая. В случае же инцидента с Jabber.ru, если говорить о сторонах, которые “вызывают доверие”, то тут такой стороной должен быть прежде всего хостер – предполагается высокая степень доверия хостеру (но не полное доверие, даже в этом случае), а только потом – немного доверия УЦ.
Адрес записки: https://dxdt.ru/2023/11/01/11377/
Похожие записки:
- Неравенство треугольника в Интернете и anycast
- Кибератаки, самоуправляемые автомобили и бот в смартфоне
- Маскирование криптографических ключей в памяти
- Реплика: Интернет и веб
- Утечка DNS-запросов в ExpressVPN
- DNS-over-TLS на авторитативных серверах DNS
- Kyber768 и TLS-серверы Google
- Синтезирование изображений смартфонами и "реальность фотографий"
- Удаление аккаунтов GoDaddy
- Reuters о сети разведывательных спутников SpaceX
- Распознавание TLS-клиентов в трафике
Комментарии читателей блога: 4
1 <t> // 1st November 2023, 13:37 // Читатель Nataraj написал:
На мой взгляд тут сильно тонче…
Хостер, да ему вынуждены доверять… Но там было MITM со стороне хостера. В работу самой виртуальной машины хостер не вмешивался, и по большому счету подшаманить с роутингом то можно было на любом участке между серверами Let’s encript и хетзнером…
Так что я тут склонен винить автоматические DV (все что делается автоматически может начать автоматически работать не в твоих интересах) и да, таки систему well known CA.
Будь другая, более нормальная система распространения доверия сертификату, например через DNSSec, такого бы не случилось…
Злоумышленнику пришлось бы вмешиваться в работу виртуальной машины или системы DNS, что гораздо проще отловить чем временную анамалию в роутинге…
2 <t> // 1st November 2023, 14:57 // Александр Венедюхин:
> подшаманить с роутингом то можно было на любом участке между серверами Let’s encript и хетзнером
Да, именно. И этот момент, кстати, тоже постоянно упускают: едва ли не всякий активный промежуточный узел мог бы подменить запрос и ответ.
> Так что я тут склонен винить автоматические DV
Дело в том, что DV как раз для другого задумывался – никто там не учитывал такие риски, как, предположим, перенаправление трафика на уровне авторитативных NS-ов. То есть, верно, DV тут не помогает, но это такая его особенность, ничего не поделать.
> более нормальная система распространения доверия сертификату, например через DNSSec, такого бы не случилось…
Но резко усложнилась бы штатная автоматизация, от которой все радуются. К тому же, DNSSEC не пользуется популярностью и сам по себе, а схемы типа DANE – в вебе не поддержали, ни браузеры, ни УЦ.
3 <t> // 1st November 2023, 15:58 // Читатель Nataraj написал:
> а схемы типа DANE – в вебе не поддержали, ни браузеры, ни УЦ.
Нет ли в этом заговора… Я думаю что есть…
4 <t> // 1st November 2023, 20:50 // Читатель beldmit написал:
Я про это когда-то писал, и ща вспомнил
https://beldmit.livejournal.com/509968.html
Написать комментарий