Как интернет становится безопаснее: отслеживание постквантовой защиты, шифрования и маршрутизации

Cloudflare Radar уже предлагает широкий спектр информации о безопасности — от атак на прикладном и сетевом уровне до вредоносных электронных писем, цифровых сертификатов и маршрутизации в Интернете.

И сегодня мы представляем ещё больше. Мы запускаем несколько новых наборов данных и инструментов, связанных с безопасностью, в Radar:

• Мы расширяем наше постквантовое (PQ) наблюдение, выходя за рамки клиентской стороны, чтобы теперь включить подключения к исходным серверам (origin). Мы также выпустили новый инструмент, который поможет вам проверить совместимость любого веб-сайта с постквантовым шифрованием.

• Новый раздел «Прозрачность ключей» (Key Transparency) в Radar предоставляет публичную панель мониторинга, показывающую статус проверки в реальном времени для журналов прозрачности ключей (Key Transparency Logs) таких сервисов сквозного шифрования, как WhatsApp, отображая, когда каждый журнал был последний раз подписан и проверен Аудитором Cloudflare. Страница служит прозрачным интерфейсом, где любой может отслеживать целостность распределения открытых ключей и получать доступ к API для независимой проверки доказательств нашего Аудитора.

• Аналитика безопасности маршрутизации продолжает расширяться с добавлением глобальной, страновой и сетевой информации о внедрении ASPA — нового стандарта, который может помочь обнаруживать и предотвращать утечки BGP-маршрутов.

С апреля 2024 года мы отслеживали совокупный рост поддержки постквантового шифрования со стороны клиентов в Cloudflare Radar, фиксируя его глобальный рост с менее 3% в начале 2024 до более 60% в феврале 2026. А в октябре 2025 года мы добавили возможность для пользователей проверять, поддерживает ли их браузер X25519MLKEM768 — гибридный алгоритм обмена ключами, сочетающий классический X25519 с ML-KEM, основанной на решётках постквантовой схемой, стандартизированной NIST. Это обеспечивает безопасность как от классических, так и от квантовых атак.

Однако поддержка постквантового шифрования в подключениях между пользователем и Cloudflare — это только часть истории.

Для контента, отсутствующего в нашем кеше CDN, или для некэшируемого контента, серверы на границе Cloudflare устанавливают отдельное соединение с исходными серверами клиента, чтобы получить его. Чтобы ускорить переход к квантово-устойчивой безопасности для таких обращений к origin-серверам, мы ранее представили API, позволяющий клиентам выбирать предпочтение постквантовых соединений. Сегодня мы делаем совместимость исходных серверов с постквантовыми технологиями видимой в Radar.

Новый график поддержки постквантовых технологий на стороне origin в Radar показывает долю исходных серверов клиентов, поддерживающих X25519MLKEM768. Эти данные получены от нашего автоматического TLS-сканера, который проверяет origin-серверы, совместимые с TLS 1.3, и ежедневно агрегирует результаты. Важно отметить, что наш сканер проверяет именно поддержку, а не конкретные предпочтения origin-сервера. Хотя сервер может поддерживать алгоритм постквантового обмена ключами, именно его локальные предпочтения обмена ключами TLS могут в конечном итоге определить результат шифрования.

Хотя основной график фокусируется на готовности к постквантовой эре, сканер также оценивает поддержку классических алгоритмов обмена ключами. В представлении Data Explorer в Radar вы также можете увидеть полное распределение поддерживаемых методов обмена ключами TLS.

Как показано на графиках выше, примерно 10% исходных серверов уже сегодня могли бы получить выгоду от предпочтительного постквантового согласования ключей. Это представляет собой значительный скачок с менее чем 1% в начале 2025 года — десятикратный рост чуть более чем за год. Мы ожидаем, что это число будет неуклонно расти по мере продолжения миграции в отрасли. Эта восходящая тенденция, вероятно, ускорилась в 2025 году, поскольку многие серверные TLS-библиотеки, такие как OpenSSL 3.5.0+, GnuTLS 3.8.9+ и Go 1.24+, по умолчанию включили гибридный постквантовый обмен ключами, позволяя платформам и сервисам поддерживать постквантовые соединения просто путем обновления зависимостей криптографических библиотек.

В дополнение к графикам в Radar и Data Explorer, данные о готовности origin-серверов также доступны через Radar API.

В рамках наших усилий по помощи Интернету в переходе к постквантовой криптографии мы также запускаем инструмент для проверки поддержки постквантового шифрования конкретным доменным именем. Эти тесты можно запускать для любого публично доступного веб-сайта, при условии, что он разрешает подключения с диапазонов исходящих IP-адресов Cloudflare.

_{Скриншот инструмента в Radar для проверки поддержки постквантового шифрования доменным именем.}

Инструмент представляет собой простую форму, где пользователи могут ввести имя хоста (например, cloudflare.com или www.wikipedia.org) и, опционально, указать пользовательский порт (по умолчанию 443, стандартный порт HTTPS). После нажатия кнопки «Проверить» результат отображает метку, указывающую статус поддержки PQ, а также согласованный алгоритм обмена ключами TLS. Если сервер предпочитает PQ-безопасные соединения, появляется зелёная метка «PQ» с сообщением, подтверждающим, что соединение «защищено постквантовой криптографией». В противном случае красная метка указывает, что соединение «не защищено постквантовой криптографией», показывая классический алгоритм, который был согласован.

Внутри этот инструмент использует Cloudflare Containers — новую возможность, позволяющую запускать контейнерные рабочие нагрузки вместе с Workers. Поскольку среда выполнения Workers не имеет доступа к деталям базового TLS-рукопожатия, Workers не могут инициировать TLS-сканирование. Поэтому мы создали Go-контейнер, который использует поддержку проверки совместимости с постквантовыми технологиями в пакете crypto/tls. Контейнер запускается по запросу и выполняет фактическое рукопожатие, чтобы определить согласованный алгоритм обмена ключами TLS, возвращая результаты через Radar API.

С добавлением этой аналитики для стороны origin, дополняющей существующую аналитику для клиентской стороны, мы переместили весь постквантовый контент в его собственный раздел в Radar.

Мессенджеры со сквозным шифрованием (E2EE), такие как WhatsApp и Signal, стали важнейшими инструментами для приватного общения, которыми пользуются миллиарды людей по всему миру. Эти приложения используют криптографию с открытым ключом, чтобы гарантировать, что только отправитель и получатель могут читать содержимое их сообщений — даже сам сервис обмена сообщениями не может. Однако в этой модели есть уязвимость, которую часто упускают из виду: пользователи должны доверять, что мессенджер распространяет правильные открытые ключи для каждого контакта.

Если бы злоумышленник смог подменить неправильный открытый ключ в базе данных мессенджера, он мог бы перехватывать сообщения, предназначенные кому-то другому — и всё это без ведома отправителя.

Key Transparency addresses this challenge by creating an auditable, append-only log of public keys — similar in concept to Certificate Transparency for TLS certificates. Messaging apps publish their users' public keys to a transparency log, and independent third parties can verify and vouch that the log has been constructed correctly and consistently over time. In September 2024, Cloudflare announced such a Key Transparency auditor for WhatsApp, providing an independent verification layer that helps ensure the integrity of public key distribution for the messaging app's billions of users.

Today, we're publishing Key Transparency audit data in a new Key Transparency section on Cloudflare Radar. This section showcases the Key Transparency logs that Cloudflare audits, giving researchers, security professionals, and curious users a window into the health and activity of these critical systems.

The new page launches with two monitored logs: WhatsApp and Facebook Messenger Transport. Each monitored log is displayed as a card containing the following information:

• Status: Indicates whether the log is online, in initialization, or disabled. An "online" status means the log is actively publishing key updates into epochs that Cloudflare audits. (An epoch represents a set of updates applied to the key directory at a specific time.)

• Last signed epoch: The most recent epoch that has been published by the messaging service's log and acknowledged by Cloudflare. By clicking on the eye icon, users can view the full epoch data in JSON format, including the epoch number, timestamp, cryptographic digest, and signature.

• Last verified epoch: The most recent epoch that Cloudflare has verified. Verification involves checking that the transition of the transparency log data structure from the previous epoch to the current one represents a valid tree transformation — ensuring the log has been constructed correctly. The verification timestamp indicates when Cloudflare completed its audit.

• Root: The current root hash of the Auditable Key Directory (AKD) tree. This hash cryptographically represents the entire state of the key directory at the current epoch. Like the epoch fields, users can click to view the complete JSON response from the auditor.

The data shown on the page is also available via the Key Transparency Auditor API, with endpoints for auditor information and namespaces.

If you would like to perform audit proof verification yourself, you can follow the instructions in our Auditing Key Transparency blog post. We hope that these use cases are the first of many that we publish in this Key Transparency section in Radar — if your company or organization is interested in auditing for your public key or related infrastructure, you can reach out to us here.

While the Border Gateway Protocol (BGP) is the backbone of Internet routing, it was designed without built-in mechanisms to verify the validity of the paths it propagates. This inherent trust has long left the global network vulnerable to route leaks and hijacks, where traffic is accidentally or maliciously detoured through unauthorized networks.

Although RPKI and Route Origin Authorizations (ROAs) have successfully hardened the origin of routes, they cannot verify the path traffic takes between networks. This is where ASPA (Autonomous System Provider Authorization) comes in. ASPA extends RPKI protection by allowing an Autonomous System (AS) to cryptographically sign a record listing the networks authorized to propagate its routes upstream. By validating these Customer-to-Provider relationships, ASPA allows systems to detect invalid path announcements with confidence and react accordingly.

While the specific IETF standard remains in draft, the operational community is moving fast. Support for creating ASPA objects has already landed in the portals of Regional Internet Registries (RIRs) like ARIN and RIPE NCC, and validation logic is available in major software routing stacks like OpenBGPD and BIRD.

To provide better visibility into the adoption of this emerging standard, we have added comprehensive RPKI ASPA support to the Routing section of Cloudflare Radar. Tracking these records globally allows us to understand how quickly the industry is moving toward better path validation.

Our new ASPA deployment view allows users to examine the growth of ASPA adoption over time, with the ability to visualize trends across the five Regional Internet Registries (RIRs) based on AS registration. You can view the entire history of ASPA entries, dating back to October 1, 2023, or zoom into specific date ranges to correlate spikes in adoption with industry events, such as the introduction of ASPA features on ARIN and RIPE NCC online dashboards.

Beyond aggregate trends, we have also introduced a granular, searchable explorer for real-time ASPA content. This table view allows you to inspect the current state of ASPA records, searchable by AS number, AS name, or by filtering for only providers or customer ASNs. This allows network operators to verify that their records are published correctly and to view other networks’ configurations.

We have also integrated ASPA data directly into the country/region routing pages. Users can now track how different locations are progressing in securing their infrastructure, based on the associated ASPA records from the customer ASNs registered locally.

On individual AS pages, we have updated the Connectivity section. Now, when viewing the connections of a network, you may see a visual indicator for "ASPA Verified Provider." This annotation confirms that an ASPA record exists authorizing that specific upstream connection, providing an immediate signal of routing hygiene and trust.

For ASes that have deployed ASPA, we now display a complete list of authorized provider ASNs along with their details. Beyond the current state, Radar also provides a detailed timeline of ASPA activity involving the AS. This history distinguishes between changes initiated by the AS itself ("As customer") and records created by others designating it as a provider ("As provider"), allowing users to immediately identify when specific routing authorizations were established or modified.

Visibility is an essential first step toward broader adoption of emerging routing security protocols like ASPA. By surfacing this data, we aim to help operators deploy protections and assist researchers in tracking the Internet's progress toward a more secure routing path. For those who need to integrate this data into their own workflows or perform deeper analysis, we are also exposing these metrics programmatically. Users can now access ASPA content snapshots, historical timeseries, and detailed changes data using the newly introduced endpoints in the Cloudflare Radar API.

Internet security continues to evolve, with new approaches, protocols, and standards being developed to ensure that information, applications, and networks remain secure. The security data and insights available on Cloudflare Radar will continue to evolve as well. The new sections highlighted above serve to expand existing routing security, transparency, and post-quantum insights already available on Cloudflare Radar. 

Если вы поделитесь любыми из этих новых графиков и диаграмм в социальных сетях, обязательно отметьте нас: @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon) и radar.cloudflare.com (Bluesky). Если у вас есть вопросы, комментарии или предложения по данным, которые вы хотели бы видеть добавленными в Radar, вы можете связаться с нами через социальные сети или написать нам по электронной почте.