Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Реплика: внешний публичный сервис DNS
Надо подчеркнуть, что использование сервисов вроде Google Public DNS – не слишком хорошо защищает от подмены и перехвата (блокировки) доступа. Как я уже писал, никто не мешает узлу, переправляющему ваш трафик в строну сервиса Google, ответить на DNS-запрос вместо сервиса Google (да ещё и быстрее). То есть, пока нет криптографических механизмов проверки подлинности ответа, подменить гугловский DNS не так трудно, адреса его известны.
Занятно, что подобная подмена распространяется и на все другие этапы разрешения имён DNS. Если вы контролируете подходящий маршрутизатор, то отвечать можно и за корневой сервер доменной системы имён (так блокируют доступ к сайтам на практике, например, в Китае). А из-за особенностей протоколов DNS, ответ, пришедший якобы от корневого сервера, может сразу содержать адрес узла, соответствующего запрошенному имени. Спросили www.yandex.ru? Ну вот и получите в ответ – 127.0.0.1.
Адрес записки: https://dxdt.blog/2012/08/15/5149/
Похожие записки:
- Обновления сервиса audit.statdom.ru
- Скорость из OBD и программы-навигаторы
- Различительная способность "обезличенных" данных
- Сертификаты с нестойкими ключами eMudhra и дампы трафика
- TLS-сертификаты и проверка "по IP-адресу"
- Статья о технологии Encrypted Client Hello
- Компиляторы в песочницах и сравнение программ
- Техническое: локальный корневой сертификат с кросс-подписью и nameConstraints
- Секретные ключи в трафике и симметричные шифры
- Реплика: история с сертификатом Jabber.ru и "управление доверием"
- Ссылки: NVIDIA об аппаратных бэкдорах в GPU
Новый
1 комментарий от читателей
1 <t> // 15th August 2012, 21:49 // Читатель jno написал:
Хех… А что помешает, скажем, отказать в использовании криптозащиты “от имени” того же гугля и ревертить клиента к использованию открытого протокола?