Основное направление
Инфраструктура
В фасете «Основное направление» значение «Инфраструктура» группирует публикации по основной предметной области. В одном месте собраны статьи, открытые источники, институты, компании, люди, региональные риски, операционные зависимости и рыночный контекст. Страница объясняет границы области, основных участников и источники, на которые стоит опираться при сравнении сигналов. Она помогает увидеть, как одна тема проявляется в событиях, профилях, изменениях рынка и долгосрочных инфраструктурных решениях.
ICANN
Поддельное письмо, которое передало Sex.com: дело Kremen против Cohen и Network Solutions
Контроль изменился не из-за перемещения вещи, а после редактирования авторитетной регистрационной записи. Поэтому в деле особенно важна граница между предъявленным полномочием, решением регистратора и фактическим состоянием домена.
Истории
Список NET в ARIN не охватывает дочерние сети
Пустая коллекция кажется окончательным ответом, пока не видна граница запроса. В API реестра маршрутизации ARIN обычный список заканчивается на прямой регистрации NET; нижестоящие перераспределения требуют другого запроса.
Облачные сервисы: тенденции Северной Америки
Откат не завершён, пока каждая edge-площадка не докажет исчезновение старого решения
Панель управления может за секунды подтвердить активацию прежней версии сервиса Fastly. Но бизнес ещё не восстановлен, если хотя бы часть запросов на edge продолжает исполнять отозванное правило, использовать прежний артефакт или принимать старое кэш-решение. Завершённость…
ICANN
Домен под контролем судебного управляющего: Office Depot против Zuccarini
Регистраторы находились в США, Германии и Израиле, а реестр `.com` — в Северной Калифорнии. Для исполнения денежного решения суду пришлось превратить эту техническую географию в юридическое местонахождение нематериального актива.
ICANN
ICANN прекращает аккредитацию регистратора: кому переходят домены?
Сотрудничающий регистратор может предложить преемника. Если ICANN отклоняет кандидатуру или сотрудничества нет, организация выбирает получателя сама. Разница показывает, где заканчивается предложение уходящей компании и начинается самостоятельное решение ICANN.
Досье
Номер тот же, смысл другой: что доказывает область наблюдения IPFIX
Экспортёр восстановил соединение, и коллектор снова увидел номер 256. Старая расстановка полей ещё лежит в памяти. Если применить её к новым байтам, могут получиться вполне убедительные числа — только подписи к ним будут неверными. Для такой ошибки не нужен оборванный график.…
Досье
TXT-запись была верной. Поставщик всё равно не был доменом: ACME DNS-01 и полномочия делегированной проверки
Поставщика удалили из приложения, CI, учётных записей сотрудников и хранилища сертификатов. Но одно полномочие пережило отключение: `_acme-challenge` по-прежнему был делегирован в его зону проверки. Когда ACME-аккаунт поставщика запросил новый wildcard-сертификат, появился…
Досье
Лишний маршрут, потерянная сессия: как управлять BGP maximum-prefix
Ограничение maximum-prefix защищает конечные ресурсы маршрутизатора от неожиданного объёма маршрутов. Но при жёстком действии оно не просто отклоняет излишек: оно закрывает BGP-сессию и лишает источника все ранее полученные через неё маршруты. Поэтому число должно быть связано с…
Досье
Ответ DNS был защищён. Но выбор узла остался вопросом политики: SSHFP и пределы полномочий отпечатка
Оператор ввёл `ssh db`, а полученный из сети поисковый суффикс развернул короткое имя в другой FQDN. Запись SSHFP для этого имени имела статус DNSSEC Secure и совпала с ключом сервера. Все криптографические проверки были корректны — для узла, выбранного клиентом, но не для базы…
Досье
Подпись прошла проверку. Но отправитель всё ещё не был подписантом: DKIM и границы полномочий доменной подписи
В поле From был показан домен `bank.example`, письмо требовало срочно оплатить счёт, а DKIM показывал успешную проверку. Подпись действительно была верной — только для `receipt-alert.example`, домена злоумышленника. Криптографический результат незаметно наделили полномочиями…
Досье
Дайджест совпал, но отправитель остался неизвестен: `Content-Digest` и полномочия контрольной суммы HTTP
Файл политики пришёл без единого повреждённого бита. Он также с самого начала был вредоносным и содержал безупречно рассчитанный `Content-Digest`. Сервис показал «проверено» и применил изменения. Атакующий не взламывал хеш-функцию — он сам выбрал и тело, и дайджест.
Досье
Заголовок назвал клиента, но сетевой сосед этого не подтвердил: HTTP `Forwarded` и полномочия цепочки прокси
По схеме origin был доступен только через два обратных прокси. На деле сохранился прямой маршрут. Запрос пришёл по нему с разрешённым административным адресом в начале `X-Forwarded-For` и прошёл IP-проверку. Парсер верно прочёл корректный адрес. Ошибка состояла в том, что…
Досье
Имя выбрало контекст TLS, но не дало полномочий: граница SNI как подсказки маршрута
Шлюз увидел `tenant-a.example`, выбрал сертификат арендатора A и завершил TLS 1.3. Затем интеграция записала метку выбранного контекста в поле прикладного субъекта. Клиент не предъявлял никаких полномочий: его собственное указание пункта назначения стало его удостоверением.
Досье
Подпись сертификата прошла, а рукопожатие — нет: TLS 1.3 `Finished` и полномочие transcript
Панель уже засчитала защищённую сессию после успешного CertificateVerify. Следующее сообщение, `Finished`, оказалось неверным, и клиент завершил соединение с `decrypt_error`. Ключ сертификата доказал владение. Ошиблась система, превратив этот факт в ещё не наступившее завершение.
История
Токен, доказавший обратный путь: DNS Cookies без удостоверения личности
Небольшая опция EDNS позволила DNS-серверу сделать узкий вывод об исходном UDP-адресе: не установить отправителя, а понять, что кто-то по этому видимому адресу получил прежний ответ и вернул созданный сервером токен.
Досье
На внешнем участке был HTTP/2, на исходном — HTTP/1.1: полномочия TLS ALPN ограничены соединением
Браузер предложил `h2` и `http/1.1`. Пограничный узел выбрал `h2`, завершил TLS и принял корректные кадры HTTP/2. После этого каталог назвал исходный сервер «нативным HTTP/2». Между фактами потерялось завершение TLS: к исходному серверу прокси открыл другое соединение и отправлял…
Досье
УЦ был в списке, но личность не получила права: граница полномочий TLS `certificate_authorities`
Клиент выбрал сертификат, поскольку имя его издателя присутствовало в запросе сервера. Сервер успешно построил и проверил цепочку. Затем приложение отклонило операцию: субъект не был допущен в нужный контур арендатора. Криптография сработала. Ошибка возникла там, где подсказке…
Досье
Подпись верна, а статус уже отстал: границы доверия к OCSP stapling
Сертификат отозвали в 10:07. В 10:11 сервер всё ещё прикладывал корректно подписанный ответ OCSP со статусом `good` и `nextUpdate` через несколько часов. Подделки не было: подлинное утверждение оставалось в заявленном интервале, но ещё не знало о новом событии. Ошибка появилась…
Досье
Сокет закрылся. Транзакция — нет: `close_notify` и полномочия завершения
Клиент получил успешный ответ и увидел штатное завершение TLS. Но запись на сервере так и не стала долговечной: база отклонила commit через несколько миллисекунд. Криптография не ошиблась. `close_notify` достоверно сообщал лишь о том, что сервер больше не будет отправлять…
Досье
Билет сохранился. Сессия — нет: возобновление TLS 1.3 и полномочия перенесённого состояния
После переключения на резервный регион новый узел принял билет TLS 1.3, выпущенный до отзыва административной роли. Протокол сработал корректно: клиент доказал владение PSK возобновления, а binder связал новый ClientHello с прежним рукопожатием. Но приложение приняло эту…