Книги: "Создание сайтов" - "Доменные войны". Защита информации: техническое описание TLS, тестовый сервер TLS 1.3. Ресурсы: LaTeX
Реплика: внешний публичный сервис DNS
Надо подчеркнуть, что использование сервисов вроде Google Public DNS – не слишком хорошо защищает от подмены и перехвата (блокировки) доступа. Как я уже писал, никто не мешает узлу, переправляющему ваш трафик в строну сервиса Google, ответить на DNS-запрос вместо сервиса Google (да ещё и быстрее). То есть, пока нет криптографических механизмов проверки подлинности ответа, подменить гугловский DNS не так трудно, адреса его известны.
Занятно, что подобная подмена распространяется и на все другие этапы разрешения имён DNS. Если вы контролируете подходящий маршрутизатор, то отвечать можно и за корневой сервер доменной системы имён (так блокируют доступ к сайтам на практике, например, в Китае). А из-за особенностей протоколов DNS, ответ, пришедший якобы от корневого сервера, может сразу содержать адрес узла, соответствующего запрошенному имени. Спросили www.yandex.ru? Ну вот и получите в ответ – 127.0.0.1.
()
Похожие записки:
- Про цепочки, RSA и ECDSA
- TLS-сертификаты dxdt.ru
- "Пасхалки" в трафике
- Экспериментальный сервер TLS 1.3: замена сертификатов
- Десятилетие DNSSEC в российских доменах
- Техническое: связь SCT-меток с логами Certificate Transparency
- Пресертификаты в Certificate Transparency
- Сорок лет Интернету
- HTTPS-запись в DNS для dxdt.ru
- Техническое описание TLS: обновление 2022
- DNS как транспорт для сигналов и данных
- Браузеры и перехват TLS без участия УЦ
- Обновление темы dxdt.ru
- Удостоверяющий центр TLS ТЦИ
- Ретроспектива заметок: деанонимизация по географии
- "Яндекс.Браузер" и российские сертификаты TLS в вебе
1 комментарий от читателей
1. 15th August 2012, 21:49 // Читатель jno написал:
Хех… А что помешает, скажем, отказать в использовании криптозащиты “от имени” того же гугля и ревертить клиента к использованию открытого протокола?