Реплика: история с сертификатом Jabber.ru и “управление доверием”

В свете нашумевшей атаки на Jabber.ru (с перехватом TLS) нередко пишут, будто эта атака показала, что “система хорошо известных (публичных) удостоверяющих центров TLS не вызывает доверия”. Атака, конечно, такое показала, но с уточнениями: “система хорошо известных УЦ” и раньше должна бы “вызывать доверие” равно в пределах разумной модели угроз, то есть – доверять ей можно только в сугубо определённых, узких случаях. И нельзя расширительно толковать возможности УЦ – это как раз большая ошибка, но весьма распространённая. В случае же инцидента с Jabber.ru, если говорить о сторонах, которые “вызывают доверие”, то тут такой стороной должен быть прежде всего хостер – предполагается высокая степень доверия хостеру (но не полное доверие, даже в этом случае), а только потом – немного доверия УЦ.

Адрес записки: https://dxdt.ru/2023/11/01/11377/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 4

  • 1. 1st November 2023, 13:37 // Читатель Nataraj написал:

    На мой взгляд тут сильно тонче…

    Хостер, да ему вынуждены доверять… Но там было MITM со стороне хостера. В работу самой виртуальной машины хостер не вмешивался, и по большому счету подшаманить с роутингом то можно было на любом участке между серверами Let’s encript и хетзнером…

    Так что я тут склонен винить автоматические DV (все что делается автоматически может начать автоматически работать не в твоих интересах) и да, таки систему well known CA.

    Будь другая, более нормальная система распространения доверия сертификату, например через DNSSec, такого бы не случилось…

    Злоумышленнику пришлось бы вмешиваться в работу виртуальной машины или системы DNS, что гораздо проще отловить чем временную анамалию в роутинге…

  • 2. 1st November 2023, 14:57 // Александр Венедюхин:

    > подшаманить с роутингом то можно было на любом участке между серверами Let’s encript и хетзнером

    Да, именно. И этот момент, кстати, тоже постоянно упускают: едва ли не всякий активный промежуточный узел мог бы подменить запрос и ответ.

    > Так что я тут склонен винить автоматические DV

    Дело в том, что DV как раз для другого задумывался – никто там не учитывал такие риски, как, предположим, перенаправление трафика на уровне авторитативных NS-ов. То есть, верно, DV тут не помогает, но это такая его особенность, ничего не поделать.

    > более нормальная система распространения доверия сертификату, например через DNSSec, такого бы не случилось…

    Но резко усложнилась бы штатная автоматизация, от которой все радуются. К тому же, DNSSEC не пользуется популярностью и сам по себе, а схемы типа DANE – в вебе не поддержали, ни браузеры, ни УЦ.

  • 3. 1st November 2023, 15:58 // Читатель Nataraj написал:

    > а схемы типа DANE – в вебе не поддержали, ни браузеры, ни УЦ.

    Нет ли в этом заговора… Я думаю что есть…

  • 4. 1st November 2023, 20:50 // Читатель beldmit написал:

    Я про это когда-то писал, и ща вспомнил

    https://beldmit.livejournal.com/509968.html

Написать комментарий

Ваш комментарий:

Введите ключевое слово "15D21" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.