Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
DNSSEC: полезные центры и провайдеры
Кстати, без “внешних” относительно DNS центров доверия – в DNSSEC смысла нет. Дело вот в чём. DNSSEC подразумевает подписывание адресной информации. Подпись должна гарантировать достоверность данных. Однако, скажем, на компьютер конечного пользователя данные из DNS поступают с сервера интернет-провайдера. Ну вот, предположим, подписал провайдер эти данные какой-то подписью – и что? Это ведь не снимает вопрос доверия провайдеру: понятно, что он мог подписать какие угодно данные какой-нибудь только что сгенерированной подписью, выдав её за подпись администратора соответствующей доменной зоны (при этом и открытые ключи провайдер может подменить).
То есть, для полезной системы нужен удостоверяющий центр, который позволит проверить достоверность самой подписи, подтвердить, что её владелец действительно является администратором той доменной зоны, информация из которой подписана.
Вообще у провайдеров будут хитрые проблемы с DNSSEC. Скажем, DNSSEC позволяет давать “авторитативные” ответы о том, что запрошенный адрес не существует. Это перекрывает кислород тем интернет-провайдерам, которые подменяют через DNS несуществующие адреса на свои (рекламные, информационные) страницы.
Адрес записки: https://dxdt.ru/2008/10/11/1757/
Похожие записки:
- IP-адреса и октеты
- Теги ключей DNSSEC: продолжение
- CVE-2024-3661 (TunnelVision) и "уязвимость" всех VPN
- "Пасхалки" в трафике
- Перебор записей компьютерных доказательств и открытые проблемы
- Алгоритм Шора в фантастической машине превращения вероятностей
- Продолжение сегментации: Docker Hub
- Логи Certificate Transparency и "таймшардинг"
- "Случайные пакеты" как транспорт
- Автомобили-роботы из "обязательной" сети такси
- Ретроспектива заметок: программный код из "реальности" в "виртуальности"