Critical Vulnerabilities in WS_FTP Server

On September 27, 2023, Progress Software published a security advisory on multiple vulnerabilities affecting WS_FTP Server, a secure file transfer solution. There are a number of vulnerabilities in the advisory, two of which are critical (CVE-2023-40044 and CVE-2023-42657).

Rapid7 is not aware of any exploitation in the wild as of September 29, 2023. Our research team has identified what appears to be the .NET deserialization vulnerability (CVE-2023-40044) and confirmed that it is exploitable with a single HTTPS POST request and a pre-existing ysoserial.net gadget.

The vulnerabilities in the advisory span a range of affected versions, and several affect only WS_FTP servers that have the Ad Hoc Transfer module enabled. Nevertheless, Progress Software’s advisory urges all customers to update to WS_FTP Server 8.8.2, which is the latest version of the software. Rapid7 echoes this recommendation.The vendor advisory has guidance on upgrading, along with info on disabling or removing the Ad Hoc Transfer module.

The critical vulnerabilities are below — notably, NVD scores CVE-2023-40044 as only being of “high” severity, not critical:

CVE-2023-40044: In WS_FTP Server versions prior to 8.7.4 and 8.8.2, the Ad Hoc Transfer module is vulnerable to a .NET deserialization vulnerability that allows an unauthenticated attacker to execute remote commands on the underlying WS_FTP Server operating system. The vulnerability affects all versions of the WS_FTP Server Ad Hoc module. Progress Software’s advisory indicates that WS_FTP Server installations without the Ad Hoc Transfer module installed are not vulnerable to CVE-2023-40044.
CVE-2023-42657: WS_FTP Server versions prior to 8.7.4 and 8.8.2 are vulnerable to a directory traversal vulnerability that allows an attacker to perform file operations (delete, rename, rmdir, mkdir) on files and folders outside of their authorized WS_FTP folder path. Attackers could also escape the context of the WS_FTP Server file structure and perform the same level of operations (delete, rename, rmdir, mkdir) on file and folder locations on the underlying operating system.

Additional (non-critical) vulnerabilities are listed below. See Progress Software’s advisory for full details:

CVE-2023-40045: In WS_FTP Server versions prior to 8.7.4 and 8.8.2, the Ad Hoc Transfer module is vulnerable to reflected cross-site scripting (XSS). Delivery of a specialized payload could allow an attacker to execute malicious JavaScript within the context of the victim’s browser.
CVE-2023-40046: The WS_FTP Server manager interface in versions prior to 8.7.4 and 8.8.2 is vulnerable to SQL injection, which could allow an attacker to infer information about the structure and contents of the database and execute SQL statements that alter or delete database elements.
CVE-2023-40047: The WS_FTP Server Management module in versions prior to 8.8.2 is vulnerable to stored cross-site scripting (XSS), which could allow an attacker with administrative privileges to import an SSL certificate with malicious attributes containing cross-site scripting payloads. Once the cross-site scripting payload is successfully stored, an attacker could leverage this vulnerability to target WS_FTP Server admins with a specialized payload which results in the execution of malicious JavaScript within the context of the victim’s browser.
CVE-2023-40048: The Manager interface in WS_FTP Server version prior to 8.8.2 was missing cross-site request forgery (CSRF) protection on a POST transaction corresponding to a WS_FTP Server administrative function.
CVE-2023-40049: In WS_FTP Server version prior to 8.8.2, an unauthenticated user could enumerate files under the ‘WebServiceHost’ directory listing.
CVE-2022-27665: WS_FTP Server 8.6.0 is vulnerable to reflected XSS (via AngularJS sandbox escape expressions), which allows an attacker to execute client-side commands by inputting malicious payloads in the subdirectory search bar or Add folder filename boxes. For example, there is Client-Side Template Injection via subFolderPath to the ThinClient/WtmApiService.asmx/GetFileSubTree URI.

Mitigation guidance

Progress Software security advisories have borne increased scrutiny and garnered broader attention from media, users, and the security community since the Cl0p ransomware group’s May 2023 attack on MOVEit Transfer. Secure file transfer technologies more generally continue to be popular targets for researchers and attackers.

While these vulnerabilities are not known to be exploited by adversaries at this time, we would advise updating to a fixed version as soon as possible, without waiting for a typical patch cycle to occur. As noted in the advisory, “upgrading to a patched release using the full installer is the only way to remediate this issue. There will be an outage to the system while the upgrade is running.”

The optimal course of action is to update to 8.8.2 as the vendor has advised. If you are using the Ad Hoc Transfer module in WS_FTP Server and are not able to update to a fixed version, consider disabling or removing the module.

See Progress Software’s advisory for the latest information.

Rapid7 customers

InsightVM and Nexpose customers running WS_FTP will be able to assess their exposure to all eight of the CVEs in this blog with authenticated vulnerability checks expected to be available in today’s (September 29) content release.

La cryptographie post-quantique passe en disponibilité générale

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/fr-fr/post-quantum-cryptography-ga-fr-fr/

Au cours des douze derniers mois, nous avons parlé de la nouvelle référence en matière de chiffrement sur Internet : la cryptographie post-quantique. Durant la Semaine anniversaire, l’année dernière, nous avons annoncé que notre version bêta de Kyber était disponible à des fins de test, et que Cloudflare Tunnel pouvait être mis en œuvre avec la cryptographie post-quantique. Au début de l’année, nous avons clairement indiqué que nous estimons que cette technologie fondamentale devait être accessible à tous, gratuitement et pour toujours.

Aujourd’hui, nous avons franchi une étape importante, après six ans et 31 articles de blog : nous lançons le déploiement de la prise en charge de la cryptographie post-quantique en disponibilité générale¹ pour nos clients, nos services et nos systèmes internes ; nous le décrivons plus en détail ci-dessous. Ce déploiement inclut des produits tels que Pingora pour la connectivité aux serveurs d’origine, 1.1.1.1, R2, le routage intelligent Argo, Snippets et bien d’autres.

Il s’agit d’une étape importante pour Internet. Nous ne savons pas encore quand les ordinateurs quantiques deviendront suffisamment puissants pour briser la cryptographie actuelle, mais les avantages qu’offre l’adoption de la cryptographie post-quantique sont aujourd’hui manifestes. Des connexions rapides et une sécurité pérenne sont désormais possibles, grâce aux progrès accomplis par Cloudflare, Google, Mozilla, NIST (National Institute of Standards and Technology) des États-Unis, Internet Engineering Task Force et de nombreuses institutions universitaires.

Connections involved when a user visits an uncached page on a website served through Cloudflare: 1. browser to edge; 2. internal connection(s); and 3. edge to customer origin server.

Qu’entend-on par « disponibilité générale » ? En octobre 2022, nous avons déployé X25519+Kyber sous forme de version bêta pour l’ensemble des sites web et API servis par l’intermédiaire de Cloudflare. Cependant, un tango se danse à deux, et une connexion n’est donc sécurisée que si le navigateur prend également en charge la cryptographie post-quantique. À partir d’août 2023, Chrome activera progressivement X25519+Kyber, par défaut.

La requête de l’utilisateur est acheminée sur le réseau de Cloudflare (2). Nous avons amélioré un grand nombre de nos connexions internes afin d’utiliser la cryptographie post-quantique, et nous prévoyons de finaliser l’amélioration de toutes nos connexions internes d’ici fin 2024. La dernière liaison demeure donc la connexion (3) entre Cloudflare et le serveur d’origine.

Nous sommes heureux d’annoncer que nous déployons la prise en charge de X25519+Kyber en disponibilité générale pour la plupart des connexions entrantes et sortantes dans le cadre d’une utilisation comprenant les serveurs d’origine et les commandes fetch() de Cloudflare Workers.

Plan	Prise en charge des connexions sortantes post-quantiques
Gratuit	Début du déploiement. Objectif : 100 % d’ici fin octobre.
Pro et Business	Objectif : 100 % d’ici la fin de l’année.
Enterprise	Le déploiement commencera en février 2024. 100 % d’ici mars 2024.

Nous transmettrons régulièrement à nos clients Enterprise des informations supplémentaires au cours des six prochains mois, afin de les aider à se préparer au déploiement. Les clients des offres Pro, Business et Enterprise peuvent ignorer le déploiement et s’inscrire dès aujourd’hui dans leur zone, ou se désinscrire à l’avance via une API, décrite dans l’article de blog associé. Avant le déploiement pour les clients de l’offre Enterprise en février 2024, nous ajouterons une option de désinscription au tableau de bord.

Si vous êtes impatient(e) de vous lancer maintenant, consultez notre article de blog contenant les informations techniques détaillées et activez la prise en charge de la cryptographie post-quantique via l’API.

Qu’est-ce qui est inclus et qu’est-ce qui va suivre ?

Avec une amélioration de cette ampleur, nous voulions d’abord prioriser les produits les plus utilisés, puis étendre le déploiement pour prendre en charge les scénarios d’utilisation particuliers. Cette approche nous a conduits à inclure les produits et systèmes suivants dans ce déploiement :

1.1.1.1
AMP (Accelerated Mobile Pages)
Passerelle API Gateway
Routage intelligent Argo
Auto Minify
Optimisation automatique de plateforme
Échanges signés automatiques
Trafic sortant de Cloudflare
Cloudflare Images
Ensemble de règles de Cloudflare
Cloudflare Snippets
Cloudflare Tunnel
Pages d’erreur personnalisée
Surveillance fondée sur les flux
Contrôles d’intégrité
Hermes
Host Head Checker
Magic Firewall
Magic Network Monitoring
Journalisation des erreurs réseau
Project Flame
Quicksilver
R2 Storage
Request Tracer
Rocket Loader
Speed sur le tableau de bord de Cloudflare
SSL/TLS
Traffic Manager
Pare-feu WAF, règles gérées
Waiting Room
Web Analytics

Si un produit ou un service que vous utilisez ne figure pas dans cette liste, c’est que le déploiement de la cryptographie post-quantique n’a pas encore débuté pour ce produit. Nous travaillons activement au déploiement de la cryptographie post-quantique pour tous nos produits et services, notamment nos produits Zero Trust. Jusqu’à ce que tous nos systèmes prennent en charge la cryptographie post-quantique, nous publierons un article de blog proposant des informations mises à jour à l’occasion de chaque Innovation Week. Cet article présentera les produits pour lesquels nous avons déployé la cryptographie post-quantique, ceux qui en bénéficieront prochainement et ceux pour lesquels la prise en charge est encore à l’horizon.

Voici les produits pour lesquels nous développons la prise en charge de la cryptographie post-quantique :

Cloudflare Gateway
DNS Cloudflare
Service d’équilibrage de charge de Cloudflare
Cloudflare Access
Always Online
Zaraz
Journalisation
D1
Cloudflare Workers
Cloudflare WARP
Gestion des bots

Pourquoi maintenant ?

Comme nous l’avons annoncé plus tôt cette année, la cryptographie post-quantique sera incluse gratuitement dans tous les produits et services Cloudflare compatibles. La meilleure technologie de chiffrement devrait être accessible à tous, gratuitement, afin de contribuer à la protection de la confidentialité et des droits de l’homme dans le monde entier.

Comme nous l’avons indiqué en mars dernier :

«Ce qui était autrefois une frontière expérimentale est devenu le substrat sous-jacent de la société moderne. Il est présent dans nos infrastructures les plus critiques, à l’image des réseaux électriques, des hôpitaux, des aéroports et des banques. Nous lui confions nos souvenirs les plus précieux. Nous lui confions nos secrets. C’est pourquoi l’Internet doit être privé par défaut, et doit également être sécurisé par défaut.»

Nos travaux sur la cryptographie post-quantique sont motivés par la théorie selon laquelle les ordinateurs quantiques, capables de briser la cryptographie conventionnelle, sont à l’origine d’un problème comparable à celui du bug de l’an 2000. Nous savons qu’il y aura, à l’avenir, un problème qui pourrait avoir des répercussions catastrophiques sur les utilisateurs, les entreprises et même les États-nations. La différence, cette fois, c’est que nous ne connaissons pas la date et l’heure auxquelles se produira cette véritable rupture du paradigme informatique. Pire encore, tout trafic capturé aujourd’hui pourrait être déchiffré à l’avenir. Nous devons donc nous préparer dès aujourd’hui à cette menace.

Nous sommes impatients de voir tous les utilisateurs adopter la cryptographie post-quantique sur leurs systèmes. Pour suivre les derniers développements du déploiement de la cryptographie post-quantique et de la prise en charge de clients/serveurs tiers, consultez pq.cloudflareresearch.com et suivez ce blog.

***

¹Nous utilisons une version préliminaire de Kyber, le choix de l’institut NIST pour les accords de clé post-quantique. Kyber n’a pas été finalisé ; nous nous attendons à la publication d’une norme définitive en 2024, sous le nom « ML-KEM ». Nous l’adopterons alors rapidement, tout en mettant fin à la prise en charge de X25519Kyber768Draft00.

ポスト量子暗号が一般利用可能に

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/ja-jp/post-quantum-cryptography-ga-ja-jp/

過去12か月間、当社はインターネット上の暗号化の新しいベースラインであるポスト量子暗号について議論してきました。昨年のバースデーウィークの間、Kyberのベータ版がテスト用に利用可能であること、そしてCloudflare Tunnelがポスト量子暗号を使用して、有効にできることを発表しました。今年初め、当社は、この基礎的なテクノロジーを誰もが永久に無料で利用できるべきだというスタンスを明確にしました。

今日、当社は6年を経てマイルストーンを達成し、31件のブログ記事を作成中です。以下に、より詳細に説明されているように、お客様、サービス、および内部システムへのポスト量子暗号サポートの一般提供のロールアウトを開始しています。これには、オリジン接続用のPingora、1.1.1.1、R2、Argo Smart Routing、Snippetsなどの製品が含まれます。

これはインターネットのマイルストーンです。量子コンピュータが今日の暗号を破るのに十分な規模を持つかは、まだ分かりませんが、今すぐポスト量子暗号にアップグレードするメリットは明らかです。Cloudflare、Google、Mozilla、米国国立標準技術研究所、インターネットエンジニアリングタスクフォース、および多数の学術機関による進歩により、高速接続と、将来も保証されるセキュリティはすべて今日可能になっています

一般提供とはどういう意味ですか？2022年10月当社はX25519+KyberをCloudflareを介して提供されるすべてのWebサイトとAPIに対し、ベータ版として有効にしました。しかし、タンゴを踊るには二人必要です。ブラウザがポスト量子暗号もサポートしている場合にのみ、接続が保護されます。2023年8月から、ChromeはデフォルトでX25519+Kyberを徐々に有効にします。

ユーザーのリクエストは、Cloudflareのネットワークを介してルーティングされます（2）。当社はこれらの内部接続の多くをポスト量子暗号を使用するようにアップグレードしており、2024年末までにすべての内部接続のアップグレードが完了する予定です。これにより、最終リンクとして、当社と配信元サーバー間の接続（3）が残ります。

配信元サーバーやCloudflare Workersのフェッチを含む利用に対し、ほとんどのインバウンドおよびアウトバウンド接続向けX25519+Kyberのサポートを使用の一般提供としてロールアウトしていることをお知らせできて嬉しく思います。

プラン	ポスト量子アウトバウンド接続のサポート
Free	ロールアウトを開始。 10月末までに100％を目指す。
ProプランおよびBusinessプラン	年末までに100％を目指す。
Enterprise	ロールアウト開始は2024年2月。 2024年3月までに100%。

Enterpriseのお客様には、今後6ヶ月にわたり、ロールアウトの準備に役立つ追加情報を定期的にお送りする予定です。Pro、Business、Enterpriseをご利用のお客様は、ロールアウトをスキップして、現在ご利用のゾーン内でオプトインすることも、コンパニオンブログ記事で説明されているAPIを使用して事前にオプトアウトすることもできます。2024年2月にEnterprise向けにロールアウトする前に、ダッシュボードにオプトアウト用のトグルを追加する予定です。

今すぐ始めたいという方は、技術的な詳細を記載したブログをチェックし、APIを介したポスト量子暗号サポートを有効にしてください！

何が含まれ、次に何があるのでしょうか？

この規模のアップグレードでは、まず最もよく使用される製品に焦点を当て、次に外側に拡張しエッジケースを把握したいと考えました。このプロセスにより、このロールアウトには以下の製品とシステムを含めることになりました。

1.1.1.1
AMP
API Gateway
Argo Smart Routing
Auto Minify
プラットフォームの自動最適化
Automatic Signed Exchanges
Cloudflareエグレス
Cloudflare Images
Cloudflareルールセット
Cloudflare Snippets
Cloudflare Tunnel
カスタムエラーページ
フローベースのモニタリング
ヘルスチェック
ヘルメス
ホストヘッドチェッカー
Magic Firewall
Magic Network Monitoring
ネットワークエラーログ
プロジェクトフレーム
クイックシルバー
R2ストレージ
リクエストトレーサー
Rocket Loader
Cloudflare Dashの速度
SSL/TLS
Traffic Manager（トラフィックマネージャー）
WAF、管理ルール
Waiting Room
Web Analytics

ご利用の製品またはサービスがここに記載されていない場合は、まだポスト量子暗号の展開を開始していません。当社は、Zero Trust製品を含むすべての製品とサービスにポスト量子暗号を展開することに積極的に取り組んでいます。すべてのシステムでポスト量子暗号のサポートが完了するまで、どの製品にポスト量子暗号をロールアウトしたか、次にロールアウトする製品、まだ、近々予定の製品を網羅する更新ブログをイノベーションウィークごとに公開する予定です。

ポスト量子暗号サポートを導入しようと取り組んでいる製品はまもなくです。

Cloudflare Gateway
Cloudflare DNS
Cloudflareロードバランサー
Cloudflare Access
Always Online
Zaraz
ログ
D1
Cloudflare Workers
Cloudflare WARP
ボット管理

なぜ、今なのでしょうか？

今年初めにお知らせしたように、ポスト量子暗号は、それをサポートできるすべてのCloudflare製品とサービスの中に無料で含まれます。最高の暗号化技術は誰もがアクセスできる必要があり、プライバシーと人権を世界的にサポートするのに役立ちます。

3月に述べたように：

「かつては実験的なフロンティアだったものが、現代社会の根底にある構造へと変わりました。これは、電力システム、病院、空港、銀行などの最も重要なインフラストラクチャで実行されます。私たちは最も貴重なメモリをそれに託しています。私たちは機密をそれに託しています。インターネットが、デフォルトでプライベートである必要があるのはそのためです。デフォルトで安全である必要があります。」

ポスト量子暗号に関する私たちの研究は、従来の暗号を破ることができる量子コンピューターが西暦2000年のバグと同様の問題を引き起こすという論文によって推進されています。将来的には、ユーザー、企業、さらには国家に壊滅的な結果をもたらす可能性のある問題が発生することは、わかっています。今回の違いは、計算パラダイムのこの破壊がいつどのように発生するかがわからないことです。さらに悪いことに、今日捕捉されたトラフィックは将来解読される可能性があります。この脅威に備えるために、今日から準備をする必要があります。

当社は、ポスト量子暗号を皆さんのシステムに導入することを楽しみにしています。ポスト量子暗号の導入とサードパーティのクライアント/サーバーサポートの最新情報をフォローするには、pq.cloudflareresearch.comをチェックして、このブログに注目してください。

¹当社は、ポスト量子鍵合意に関して、NISの選択であるKyberの暫定版を使用しています。Kyberはまだ完成していません。最終基準は、2024年にML-KEMという名前で公開される予定であり、X25519Kyber768Draft00のサポートを廃止しつつ、速やかに採用する予定です。

后量子加密正式发布

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/zh-cn/post-quantum-cryptography-ga-zh-cn/

在过去的十二个月里，我们一直在讨论互联网上的新加密基准：后量子加密。去年生日周期间，我们宣布我们的 Kyber 测试版可供测试，且 Cloudflare Tunnel 可启用后量子加密。今年早些时候，我们明确表示这项基础技术应该永久免费提供给所有人使用。

经过六年的努力和 31 篇博客文章的酝酿，我们今天正式发布对我们客户、服务和内部系统的后量子加密支持，详情如下。支持的产品包括 Pingora （源连接）、1.1.1.1、R2、Argo Smart Routing、Snippets 等等。

这对互联网来说是一个里程碑。我们目前还不知道量子计算机何时会强大到足以破解现今的加密技术，但是现在升级到后量子加密的好处是显而易见的。由于 Cloudflare、Google、Mozilla、美国国家标准与技术研究院、互联网工程任务组以及众多学术机构取得的进展，快速连接和面向未来的安全性在今天才成为可能。

正式发布意味着什么？2022 年 10 月，我们为通过 Cloudflare 服务的所有网站和 API 启用 X25519+Kyber 测试版。然而，一个巴掌拍不响：只有浏览器也支持后量子加密，才能确保连接的安全。2023 年 8 月起，Chrome逐渐默认启用 X25519+Kyber。

用户的请求通过 Cloudflare 的网络进行路由（2）。我们已经升级了许多这些内部连接以使用后量子加密，并预计到 2024 年底将完成所有内部连接的升级。这使得连接（3）成为我们与源服务器之间的最后一环。

我们很高兴能正式推出对大部分入站和出站连接的 X25519+Kyber 支持，适用于源服务器和 Cloudflare Workers fetch()。

计划	后量子加密出站连接支持
免费	开始推出。目标是 10 月底前 100% 覆盖
Pro 和 Business	目标是年底前 100% 覆盖
Enterprise	2024 年 2 月开始推出2024 年 3 月 100% 覆盖

对于我们的 Enterprise 客户，我们将在接下来的六个月内定期发出更多信息，以帮助您准备迎接这一推出。Pro、Business 和 Enterprise 客户可以跳过这一推出，提前使用我们中相关博客文章描述的 API，在您的区域内选择加入或者退出。在 2024 年 2 月为 Enterprise 客户推出之前，我们将在仪表板上添加一个切换按钮，以选择退出。

如果您希望马上开始，请查看我们的博客文章以了解技术细节，并通过 API 启用后量子加密支持!

包括什么？下一步是什么？

对于如此大规模的升级，我们希望首先专注于我们最常用的产品，然后扩展以覆盖边缘用例。因此本次推出包括如下产品和系统：

1.1.1.1
AMP
API GATEWAY
Argo Smart Routing
Auto Minify
自动平台优化
Automatic Signed Exchanges
Cloudflare Egress
Cloudflare Images
Cloudflare Rulesets
Cloudflare Snippets
Cloudflare Tunnel
自定义错误页
基于流的监测
运行状况检查
Hermes
Host Head Checker
Magic Firewall
Magic Network Monitoring
Network Error Logging
Project Flame
Quicksilver
R2 储存
Request Tracer
Rocket Loader
Speed on Cloudflare Dash
SSL/TLS
流量管理器
WAF, Managed Rules
Waiting Room
Web Analytics

如果您使用的产品或服务未在此处列出，那么我们尚未开始为其推出后量子加密支持。我们正在积极推出对所有产品和服务的后量子加密支持，包括我们的 Zero Trust 产品。在我们实现所有系统的后量子加密支持之前，我们将在每个创新周发布更新博客文章，介绍我们已经为哪些产品推出了后量子加密，下一步将支持的产品以及未来的计划。

我们将在不久后为以下产品提供后量子加密支持：

Cloudflare Gateway
Cloudflare DNS
Cloudflare Load Balancer
Cloudflare Access
Always Online
Zaraz
日志记录
D1
Cloudflare Workers
Cloudflare WARP
Bot管理

为什么现在要推出这项服务？

正如我们今年早些时候宣布的那样，后量子加密将免费包含在所有能够支持的 Cloudflare 产品和服务中。最好的加密技术应该对每个人免费开放，以帮助支持全球的隐私和人权。

正如我们在 3 月所提到的：

“曾经的实验性前沿已经变成了现代社会的基础结构。它运行在我们最关键的基础设施中，例如电力系统、医院、机场和银行。我们将最珍贵的记忆托付给它。我们把秘密托付给它。这就是为什么互联网需要默认是私密的。它需要默认是安全的。”

我们对后量子加密技术的研究是基于这样一个论点，即量子计算机可以破解传统密码学，产生类似于“千年虫”的问题。我们知道未来会出现一个问题，可能会给用户、企业甚至国家带来灾难性的后果。这一次的区别在于，我们不知道这种计算范式的突破将会在何年何月发生。更糟糕的是，今天捕获的任何流量在未来可能会被解密。我们今天就需要为应对这种威胁做好准备。

我们很高兴每个人都能在他们的系统中采用后量子加密技术。要了解我们部署后量子加密和第三方客户端/服务器支持的最新进展，请访问 pq.cloudflareresearch.com 并关注本博客。

¹我们正在使用 Kyber （NIST 选择的后量子密钥协商算法）的一个初步版本。Kyber 尚未最终定稿。我们预计最终标准将在 2024 年以 ML-KEM 的名称发布，届时我们将迅速采用该标准，并停止支持 X25519Kyber768Draft00。

Disponibilidad general de la criptografía poscuántica

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/es-es/post-quantum-cryptography-ga-es-es/

Durante los últimos 12 meses, hemos estado hablando sobre la nueva línea base de la encriptación en Internet: la criptografía poscuántica. El año pasado, durante la Semana aniversario anunciamos la disponibilidad de nuestra versión beta de Kyber para fines de prueba, y que Cloudflare Tunnel se podría activar con la criptografía poscuántica. Este mismo año, dejamos clara nuestra postura de que creemos que esta tecnología fundamental debería estar disponible para todos de forma gratuita, siempre.

Hoy, tras seis años y 31 publicaciones del blog, hemos alcanzado un hito importante: estamos empezando a implementar la disponibilidad general del soporte de la criptografía poscuántica para nuestros clientes, servicios y sistemas internos, tal como se describe más detalladamente a continuación. Esto incluye productos como Pingora para la conectividad de origen, 1.1.1.1, R2, Argo Smart Routing, Snippets y muchos más.

Esto es un hito para Internet. No sabemos aún cuándo los ordenadores cuánticos alcanzarán la escala suficiente para descifrar la criptografía actual, pero las ventajas de actualizar ahora a la criptografía cuántica son evidentes. Las conexiones rápidas y una seguridad preparada para el futuro son posibles hoy gracias a los avances logrados por Cloudflare, Google, Mozilla, el Instituto Nacional de Estándares y Tecnología de EE. UU., Internet Engineering Task Force y muchas otras instituciones académicas.

¿Qué significa la disponibilidad general? En octubre de 2022 activamos X25519+Kyber como versión beta para todos los sitios web y las API proporcionados a través de Cloudflare. Pero una conexión es cosa de dos: solo está protegida si el navegador también admite la criptografía poscuántica. A partir de agosto de 2023, Chrome está activando poco a poco X25519+Kyber por defecto.

La solicitud del usuario se enruta a través de la red de Cloudflare (2). Hemos actualizado muchas de estas conexiones internas para utilizar la criptografía poscuántica, y esperamos dar por terminada la actualización de todas nuestras conexiones internas a finales de 2024. Esto deja como el enlace final la conexión (3) entre nosotros y el servidor de origen.

Nos complace anunciar que estamos implementado la compatibilidad con X25519+Kyber para la mayoría de las conexiones entrantes y salientes como disponibilidad general para su uso, incluidos los servidores de origen y Cloudflare Workers fetch()es.

Plan	Compatibilidad con las conexiones salientes poscuánticas
Gratuito	Implementación iniciada. Nuestro objetivo es la compatibilidad total para finales de octubre.
Pro y Business	Nuestro objetivo es la compatibilidad total para finales de año.
Enterprise	La implementación se iniciará en febrero de 2024. Compatibilidad total para marzo de 2024.

Para nuestros clientes Enterprise, a lo largo de los próximos seis meses proporcionaremos periódicamente información adicional para ayudarte a preparar para la implementación. Los clientes de los planes Pro, Business y Enterprise pueden omitir la implementación y la activación en su zona hoy, o bien desactivarla con antelación mediante una API tal como se describe en nuestra publicación complementaria del blog. Antes de la implementación para Enterprise en febrero de 2024, añadiremos un selector en el panel de control para la desactivación.

Si te interesa empezar ya, echa un vistazo a nuestro blog, donde encontrarás todos los detalles técnicos, y activa la compatibilidad con la criptografía poscuántica mediante la API.

¿Qué se incluye y qué será lo siguiente?

Con una actualización de este calibre, queríamos centrarnos primero en nuestros productos más utilizados y a continuación ampliar progresivamente para cubrir nuestros casos extremos. Este proceso nos ha llevado a incluir los siguientes productos y sistemas en esta implementación:

1.1.1.1
AMP
API Gateway
Argo Smart Routing
Auto Minify
Optimización automática de la plataforma
Intercambios firmados automáticos
Salida de Cloudflare
Cloudflare Images
Conjuntos de reglas de Cloudflare
Cloudflare Snippets
Cloudflare Tunnel
Páginas de error personalizado
Supervisión basada en el flujo
Comprobaciones de estado
Hermes
Verificador de encabezado de servidor
Magic Firewall
Magic Network Monitoring
Registro de errores de red
Proyecto Flame
Quicksilver
Almacenamiento R2
Rastreador de solicitudes
Rocket Loader
Speed en el panel de control de Cloudflare
SSL/TLS
Traffic Manager
WAF, Reglas administradas
Waiting Room
Web analytics

Si un producto o servicio que utilizas no aparece en esta lista, aún no hemos empezado a implementar la criptografía poscuántica en él. Estamos trabajando activamente para implementar la criptografía poscuántica en todos nuestros productos y servicios, incluidos nuestros productos Zero Trust. Hasta que hayamos logrado la compatibilidad con la criptografía poscuántica en todos nuestros sistemas, en cada Innovation Week ofreceremos una nueva publicación del blog con las últimas noticias acerca de en qué productos ya hemos implementado la criptografía poscuántica, en cuáles lo haremos a continuación y las perspectivas para el futuro.

Productos en los que estamos trabajando para que en breve admitan la criptografía poscuántica:

Cloudflare Gateway
DNS de Cloudflare
Cloudflare Load Balancer
Cloudflare Access
Always Online
Zaraz
Registro
D1
Cloudflare Workers
WARP de Cloudflare
Gestión de bots

¿Por qué ahora?

Como ya anunciamos este mismo año, la criptografía poscuántica se incluirá de forma gratuita en todos los productos y los servicios de Cloudflare que puedan admitirla. La mejor tecnología de encriptación debe ser accesible para todos, de forma gratuita, a fin de ayudar a proteger la privacidad y los derechos humanos en todo el mundo.

Como mencionamos en marzo:

“Lo que antes era una tecnología fronteriza experimental se ha convertido en el sustrato subyacente de la sociedad moderna. Se ejecuta en nuestras infraestructuras más críticas, como los sistemas eléctricos, los hospitales, los aeropuertos y los bancos. Le confiamos nuestros recuerdos más preciados, también nuestros secretos. Por ello, Internet debe ser privada por defecto. Debe estar protegida por defecto”.

Nuestro trabajo con la criptografía poscuántica se basa en la tesis de que los ordenadores cuánticos que pueden descifrar la criptografía convencional crean un problema similar al del error del año 2000. Sabemos que habrá un problema en el futuro que podría tener catastróficas consecuencias para los usuarios, las empresas e incluso para los estados-nación. La diferencia esta vez es que no sabemos la fecha y hora en que tendrá lugar este cambio radical en el paradigma informático. Lo que es peor, cualquier tráfico capturado hoy podría ser desencriptado en el futuro. Necesitamos prepararnos hoy para estar listos para esta amenaza.

Estamos entusiasmados de que todo el mundo adopte la criptografía poscuántica en sus sistemas. Para seguir los últimos desarrollos de nuestra implementación de la criptografía poscuántica y de la compatibilidad con clientes/servidores externos, consulta pq.cloudflareresearch.com y no pierdas de vista este blog.

¹Estamos utilizando una versión preliminar de Kyber, la opción de NIST para un acuerdo de claves poscuánticas. Kyber aún no se ha completado. Esperamos la publicación de un estándar final en 2024, denominado ML-KEM. Entonces adoptaremos de inmediato dicho estándar al tiempo que eliminaremos la compatibilidad con X25519Kyber768Draft00.

Post-Quanten-Kryptographie allgemein verfügbar

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/de-de/post-quantum-cryptography-ga-de-de/

In den letzten zwölf Monaten haben wir über die neue Grundlage der Verschlüsselung im Internet gesprochen: Post-Quanten-Kryptographie. Während der Birthday Week im letzten Jahr haben wir angekündigt, dass unsere Beta-Version von Kyber zu Testzwecken verfügbar ist und dass Post-Quanten-Kryptografie für Cloudflare Tunnel aktiviert werden kann. Anfang dieses Jahres haben wir uns klar dafür ausgesprochen, dass diese grundlegende Technologie für alle kostenlos und dauerhaft verfügbar sein sollte.

Heute haben wir nach sechs Jahren und 31 Blog-Beiträgen einen Meilenstein erreicht: Wir führen die allgemeine Verfügbarkeit der Unterstützung für Post-Quanten-Kryptographie für unsere Kunden, Dienste und internen Systeme ein, wie im Folgenden genauer beschrieben. Dazu gehören Produkte wie Pingora für Konnektivität von Ursprungsservern, 1.1.1.1, R2, Argo Smart Routing, Snippets und viele mehr.

Dies ist ein Meilenstein für das Internet. Wir wissen noch nicht, wann Quantencomputer leistungsstark genug sein werden, um die heutige Kryptographie zu knacken, aber die Vorteile, jetzt auf Post-Quanten-Kryptographie umzusteigen, liegen auf der Hand. Schnelle Verbindungen und vorausschauende Sicherheit sind dank der Fortschritte von Cloudflare, Google, Mozilla, den National Institutes of Standards and Technology (NIST) in den USA, der Internet Engineering Task Force und zahlreichen akademischen Einrichtungen heute möglich.

Was bedeutet Allgemeine Verfügbarkeit (GA)? Im Oktober 2022 aktivierten wir X25519+Kyber als Beta-Version für alle Websites und APIs, die über Cloudflare bereitgestellt werden. Für ein perfektes Zusammenspiel muss jedoch jeder seinen Beitrag leisten: Die Verbindung ist nur dann sicher, wenn der Browser auch Post-Quanten-Kryptographie unterstützt. Ab August 2023 wird Chrome langsam X25519+Kyber standardmäßig aktivieren.

Die Anfrage des Nutzers wird über das Netzwerk von Cloudflare geleitet (2). Wir haben viele dieser internen Verbindungen auf Post-Quanten-Kryptographie umgestellt und erwarten, dass wir bis Ende 2024 alle unsere internen Verbindungen umgestellt haben werden. Damit bleibt als letztes Glied die Verbindung (3) zwischen uns und dem Ursprungsserver.

Wir freuen uns, ankündigen zu können, dass wir die Unterstützung für X25519+Kyber für die meisten ein- und ausgehenden Verbindungen allgemein verfügbar machen auch für Ursprungsserver und Cloudflare Workers-Abrufe via fetch()-Befehl.

Tarif	Unterstützung für ausgehende Post-Quantum-Verbindungen
Free	Einführung lanciert. Ziel ist es, bis Ende Oktober 100 % zu erreichen.
Pro und Business	Ziel ist es, bis Ende des Jahres 100 % zu erreichen.
Enterprise	Die Einführung beginnt im Februar 2024. 100 % bis März 2024.

Enterprise-Kunden werden im Laufe der nächsten sechs Monate regelmäßig zusätzliche Informationen erhalten, um sie auf die Einführung vorzubereiten. Pro-, Business- und Enterprise-Kunden können die Einführung überspringen und sich bereits heute in ihrer Zone anmelden oder sich vorzeitig über eine API abmelden, die in unserem begleitenden Blogbeitrag beschrieben wird. Vor der Markteinführung für Enterprise-Kunden im Februar 2024 werden wir im Dashboard einen Schalter für die Abmeldung (Opt-out) einrichten.

Wenn Sie sofort loslegen möchten, lesen Sie unseren Blog mit den technischen Details und der Unterstützung von Post-Quanten-Kryptographie über die API!

Was ist inbegriffen und wie geht es weiter?

Bei einem Upgrade dieser Größenordnung wollten wir uns zunächst auf unsere am häufigsten genutzten Produkte konzentrieren und dann auf speziellere Anwendungsfälle ausweiten. Dieser Prozess hat dazu geführt, dass wir die folgenden Produkte und Systeme in diese Markteinführung einbezogen haben:

1.1.1.1
AMP
API-Gateway
Argo Smart Routing
Auto Minify
Automatic Platform Optimization
Automatische Signed Exchanges
Cloudflare Egress
Cloudflare Images
Cloudflare Rulesets
Cloudflare Snippets
Cloudflare Tunnel
Eigene Fehlerseiten
Flow-basierte Überwachung
Integritätsprüfungen
Hermes
Host Head Checker
Magic Firewall
Magic Network Monitoring
Protokollierung von Netzwerkfehlern
Projekt „Flame“
Quicksilver
R2 Storage
Nachverfolgung von Anfragen (Request Tracer)
Rocket Loader
Speed auf Cloudflare Dash
SSL/TLS
Traffic Manager
WAF, Managed Rules (Verwaltete Regel)
Waiting Room
Web Analytics

Wenn ein von Ihnen genutztes Produkt oder ein Dienst hier nicht aufgeführt ist, haben wir noch nicht mit der Einführung der Post-Quanten-Kryptographie für dieses Produkt begonnen. Wir arbeiten aktiv daran, die Post-Quanten-Kryptographie für alle Produkte und Dienstleistungen, einschließlich unserer Zero Trust-Produkte, einzuführen. Bis wir die Post-Quanten-Kryptographie in allen unseren Systemen unterstützt haben, werden wir in jeder Innovation Week einen Info-Blogbeitrag veröffentlichen, in dem wir darüber berichten, für welche Produkte wir die Post-Quanten-Kryptographie bereits eingeführt haben, welche Produkte als nächstes dran sind und was noch geplant ist.

Wir arbeiten daran, die Post-Quanten-Kryptographie bald in unsere folgenden Produkte zu integrieren:

Cloudflare Gateway
Cloudflare DNS
Cloudflare Load Balancer
Cloudflare Access
Always Online
Zaraz
Protokollierung
D1
Cloudflare Workers
Cloudflare WARP
Bot-Management

Warum gerade jetzt?

Wie wir bereits Anfang des Jahres angekündigt haben, wird die Post-Quanten-Kryptographie kostenlos in alle Cloudflare-Produkte und -Dienste integriert, die sie unterstützen können. Die beste Verschlüsselungstechnologie sollte für jedermann zugänglich sein – und zwar kostenlos –, um die Privatsphäre und die Menschenrechte weltweit zu schützen und zu fördern.

Wie wir bereits im März erwähnt haben:

„Einst ein experimentelles Neuland, hat es sich zum Fundament der modernen Gesellschaft entwickelt. Unsere kritischsten Infrastrukturen wie Stromnetze, Krankenhäuser, Flughäfen und Banken setzen es ein. Wir vertrauen ihm unsere wertvollsten Erinnerungen an. Wir vertrauen ihm unsere Geheimnisse an. Deshalb muss das Internet standardmäßig privat sein. Es muss standardmäßig sicher sein.“

Unsere Arbeit an der Post-Quanten-Kryptographie beruht auf der These, dass Quantencomputer, die konventionelle Kryptographie knacken können, ein ähnliches Problem darstellen wie der Jahr-2000-Bug. Wir wissen, dass es in der Zukunft ein Problem geben wird, das katastrophale Folgen für Benutzer, Unternehmen und sogar Nationalstaaten haben könnte. Der Unterschied ist, dass wir dieses Mal nicht wissen, wann und wie dieser Paradigmenwechsel hinsichtlich der Funktionsweise von Computern stattfinden wird. Schlimmer noch, jeder heute erfasste Traffic könnte in Zukunft entschlüsselt werden. Wir müssen uns heute vorbereiten, um für diese Bedrohung gerüstet zu sein.

Wir freuen uns über jeden, der die Post-Quanten-Kryptographie in seine Systeme integrieren möchte. Um über die neuesten Entwicklungen unserer Post-Quanten-Kryptographie und der Client/Server-Unterstützung von Drittanbietern auf dem Laufenden zu bleiben, besuchen Sie pq.cloudflareresearch.com und behalten Sie diesen Blog im Auge.

¹ Wir verwenden eine vorläufige Version von Kyber, das vom NIST für die Post-Quantum-Schlüsselvereinbarung ausgewählt wurde. Kyber ist noch nicht fertiggestellt. Wir gehen davon aus, dass im Jahr 2024 ein endgültiger Standard unter dem Namen ML-KEM veröffentlicht wird, den wir dann umgehend übernehmen werden, während wir die Unterstützung für X25519Kyber768Draft00 einstellen.

Encrypted Client Hello – the last puzzle piece to privacy

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/announcing-encrypted-client-hello/

Encrypted Client Hello - the last puzzle piece to privacy

Today we are excited to announce a contribution to improving privacy for everyone on the Internet. Encrypted Client Hello, a new proposed standard that prevents networks from snooping on which websites a user is visiting, is now available on all Cloudflare plans.

Encrypted Client Hello (ECH) is a successor to ESNI and masks the Server Name Indication (SNI) that is used to negotiate a TLS handshake. This means that whenever a user visits a website on Cloudflare that has ECH enabled, no one except for the user and the website will be able to determine which website was visited. Cloudflare is a big proponent of privacy for everyone and is excited about the prospects of bringing this technology to life.

Browsing the Internet and your privacy

Whenever you visit a website, your browser sends a request to a web server. The web server responds with content and the website starts loading in your browser. Way back in the early days of the Internet this happened in 'plain text', meaning that your browser would just send bits across the network that everyone could read: the corporate network you may be browsing from, the Internet Service Provider that offers you Internet connectivity and any network that the request traverses before it reaches the web server that hosts the website. Privacy advocates have long been concerned about how much information could be seen in "plain text": If any network between you and the web server can see your traffic, that means they can also see exactly what you are doing. If you are initiating a bank transfer any intermediary can see the destination and the amount of the transfer.

So how to start making this data more private? To prevent eavesdropping, encryption was introduced in the form of SSL and later TLS. These are amazing protocols that safeguard not only your privacy but also ensure that no intermediary can tamper with any of the content you view or upload. But encryption only goes so far.

While the actual content (which particular page on a website you're visiting and any information you upload) is encrypted and shielded from intermediaries, there are still ways to determine what a user is doing. For example, the DNS request to determine the address (IP) of the website you're visiting and the SNI are both common ways for intermediaries to track usage.

Let's start with DNS. Whenever you visit a website, your operating system needs to know which IP address to connect to. This is done through a DNS request. DNS by default is unencrypted, meaning anyone can see which website you're asking about. To help users shield these requests from intermediaries, Cloudflare introduced DNS over HTTPS (DoH) in 2019. In 2020, we went one step further and introduced Oblivious DNS over HTTPS which prevents even Cloudflare from seeing which websites a user is asking about.

That leaves SNI as the last unencrypted bit that intermediaries can use to determine which website you're visiting. After performing a DNS query, one of the first things a browser will do is perform a TLS handshake. The handshake constitutes several steps, including which cipher to use, which TLS version and which certificate will be used to verify the web server's identity. As part of this handshake, the browser will indicate the name of the server (website) that it intends to visit: the Server Name Indication.

Due to the fact that the session is not encrypted yet, and the server doesn't know which certificate to use, the browser must transmit this information in plain text. Sending the SNI in plaintext means that any intermediary that can view which website you’re visiting simply by checking the first packet for a connection:

This means that despite the amazing efforts of TLS and DoH, which websites you’re visiting on the Internet still isn't truly private. Today, we are adding the final missing piece of the puzzle with ECH. With ECH, the browser performs a TLS handshake with Cloudflare, but not a customer-specific hostname. This means that although intermediaries will be able to see that you are visiting a website on Cloudflare, they will never be able to determine which one.

How does ECH work?

In order to explain how ECH works, it helps to first understand how TLS handshakes are performed. A TLS handshake starts with a ClientHello part, which allows a client to say which ciphers to use, which TLS version and most importantly, which server it's trying to visit (the SNI).

With ECH, the ClientHello message part is split into two separate messages: an inner part and an outer part. The outer part contains the non-sensitive information such as which ciphers to use and the TLS version. It also includes an "outer SNI". The inner part is encrypted and contains an "inner SNI".

The outer SNI is a common name that, in our case, represents that a user is trying to visit an encrypted website on Cloudflare. We chose cloudflare-ech.com as the SNI that all websites will share on Cloudflare. Because Cloudflare controls that domain we have the appropriate certificates to be able to negotiate a TLS handshake for that server name.

The inner SNI contains the actual server name that the user is trying to visit. This is encrypted using a public key and can only be read by Cloudflare. Once the handshake completes the web page is loaded as normal, just like any other website loaded over TLS.

In practice, this means that any intermediary that is trying to establish which website you’re visiting will simply see normal TLS handshakes with one caveat: any time you visit an ECH enabled website on Cloudflare the server name will look the same. Every TLS handshake will appear identical in that it looks like it's trying to load a website for cloudflare-ech.com, as opposed to the actual website. We've solved the last puzzle-piece in preserving privacy for users that don't like intermediaries seeing which websites they are visiting.

For full details on the nitty-gritty of ECH technology, visit our introductory blog.

The future of privacy

We're excited about what this means for privacy on the Internet. Browsers like Google Chrome and Firefox are starting to ramp up support for ECH already. If you're a website, and you care about users visiting your website in a fashion that doesn't allow any intermediary to see what users are doing, enable ECH today on Cloudflare. We've enabled ECH for all free zones already. If you're an existing paying customer, just head on over to the Cloudflare dashboard and apply for the feature. We’ll be enabling this for everyone that signs up over the coming few weeks.

Over time, we hope others will follow our footsteps, leading to a more private Internet for everyone. The more providers that offer ECH, the harder it becomes for anyone to listen in on what users are doing on the Internet. Heck, we might even solve privacy for good.

If you're looking for more information on ECH, how it works and how to enable it head on over to our developer documentation on ECH.

Privacy-preserving measurement and machine learning

2023-09-29 Christopher Patton

Post Syndicated from Christopher Patton original http://blog.cloudflare.com/deep-dive-privacy-preserving-measurement/

Privacy-preserving measurement and machine learning

In 2023, data-driven approaches to making decisions are the norm. We use data for everything from analyzing x-rays to translating thousands of languages to directing autonomous cars. However, when it comes to building these systems, the conventional approach has been to collect as much data as possible, and worry about privacy as an afterthought.

The problem is, data can be sensitive and used to identify individuals – even when explicit identifiers are removed or noise is added.

Cloudflare Research has been interested in exploring different approaches to this question: is there a truly private way to perform data collection, especially for some of the most sensitive (but incredibly useful!) technology?

Some of the use cases we’re thinking about include: training federated machine learning models for predictive keyboards without collecting every user’s keystrokes; performing a census without storing data about individuals’ responses; providing healthcare authorities with data about COVID-19 exposures without tracking peoples’ locations en masse; figuring out the most common errors browsers are experiencing without reporting which websites are visiting.

It’s with those use cases in mind that we’ve been participating in the Privacy Preserving Measurement working group at the IETF whose goal is to develop systems for collecting and using this data while minimizing the amount of per-user information exposed to the data collector.

So far, the most promising standard in this space is DAP – Distributed Aggregation Protocol – a clever way to use multi-party computation to aggregate data without exposing individual measurements. Early versions of the algorithms used by DAP have been implemented by Google and Apple for exposure notifications.

In this blog post, we’ll do a deep dive into the fundamental concepts behind the DAP protocol and give an example of how we’ve implemented it into Daphne, our open source aggregator server. We hope this will inspire others to collaborate with us and get involved in this space!

The principles behind DAP, an open standard for privacy preserving measurement

At a high level, using the DAP protocol forces us to think in terms of data minimization: collect only the data that we use and nothing more. Abstractly, our goal is to devise a system with which a data collector can compute some function $ f(m_{1},…,m_{N}) $ of measurements $ m_{1},…,m_{N} $ uploaded by users without observing the measurements in the clear.

This may at first seem like an impossible task: to compute on data without knowing the data we're computing on. Nevertheless, —and, as is often the case in cryptography— once we've properly constrained the problem, solutions begin to emerge.

In an ideal world (see above), there would be some server somewhere on the Internet that we could trust to consume measurements, aggregate them, and send the result to the data collector without ever disclosing anything else. However, in reality there's no reason for users to trust such a server more than the data collector; Indeed, both are subject to the usual assortment of attacks that can lead to a data breach.

Instead, what we do in DAP is distribute the computation across the servers such that no single server has a complete measurement. The key idea that makes this possible is secret sharing.

Computing on secret shared data

To set things up, let's make the problem a little more concrete. Suppose each measurement $ m_{i} $ is a number and our goal is to compute the sum of the measurements. That is, $ f(m_{1},…,m_{N}) = m_{1} + \cdots + m_{N} $. Our goal is to use secret sharing to allow two servers, which we'll call aggregators, to jointly compute this sum.

To understand secret sharing, we're going to need a tiny bit of math—modular arithmetic. The expression $ X + 1 (\textrm{mod}) \textit{q} $ means "add $ X $ and $ Y $, then divide the sum by $ q $ and return the remainder". For now the modulus $ q $ can be any large number, as long as it's larger than any sum we'd ever want to compute ($ 2 ^{64} $, say). In the remainder of this section, we'll omit $ q $ and simply write $ X + Y $ for addition modulo $ q $.

The goal of secret sharing is to shard a measurement (i.e., a "secret") into two "shares" such that (i) the measurement can be recovered by combining the shares together and (ii) neither share leaks any information about the measurement. To secret share each $ m_{i} $, we choose a random number $ R_{i} \in \lbrace 0,…,q – 1\rbrace $, set the first share to be $X_{i} = m_{i} – R_{i} $ and set the other share to be $ Y_{i} = R_{i} $. To recover the measurement, we simply add the shares together. This works because $ X_{i} + Y_{i} = (m_{i} – R_{i}) + R_{i} = m_{i} $. Moreover, each share is indistinguishable from a random number: For example, $ 1337 $ might be secret-shared into $ 11419752798245067454 $ and $ 7026991275464485499 $ (modulo $ q = 2^{64} $).

With this scheme we can devise a simple protocol for securely computing the sum:

Each client shards its measurement $ m_{i} $ into $ X_{i} $ and $ Y_{i} $ and sends one share to each server.
The first aggregator computes $ X = X_{1} + \cdots + X_{N} $ and reveals $ X $ to the data collector. The second aggregator computes $ Y = Y_{1} + \cdots + Y_{N} $ and reveals $ Y $ to the data collector.
The data collector unshards the result as $ r = X + Y $.

This works because the secret shares are additive, and the order in which we add things up is irrelevant to the function we're computing:

$ r = m_{1} + \cdots + m_{N} $ // by definition
$ r = (m_{1} – R_{1}) + R_{1} + \cdots (m_{N} – R_{N}) + R_{N} $ // apply sharding
$ r = (m_{1} – R_{1}) + \cdots + (m_{N} – R_{N}) + R_{1} + \cdots R_{N} $ // rearrange the sum
$ r = X + Y $ // apply aggregation

Rich data types

This basic template for secure aggregation was described in a paper from Henry Corrigan-Gibbs and Dan Boneh called "Prio: Private, Robust, and Scalable Computation of Aggregate Statistics" (NSDI 2017). This paper is a critical milestone in DAP's history, as it showed that a wide variety of aggregation tasks (not just sums) can be solved within one, simple protocol framework, Prio. With DAP, our goal in large part is to bring this framework to life.

All Prio tasks are instances of the same template. Measurements are encoded in a form that allows the aggregation function to be expressed as the sum of (shares of) the encoded measurements. For example:

To get arithmetic mean, we just divide the sum by the number of measurements.
Variance and standard deviation can be expressed as a linear function of the sum and the sum of squares (i.e., $ m_{i}, m_{i}^{2} $ for each $ i $).
Quantiles (e.g., median) can be estimated reasonably well by mapping the measurements into buckets and aggregating the histogram.
Linear regression (i.e., finding a line of best fit through a set of data points) is a bit more complicated, but can also be expressed in the Prio framework.

This degree of flexibility is essential for wide-spread adoption because it allows us to get the most value we can out of a relatively small amount of software. However, there are a couple problems we still need to overcome, both of which entail the need for some form of interaction.

Input validation

The first problem is input validation. Software engineers, especially those of us who operate web services, know in our bones that validating inputs we get from clients is of paramount importance. (Never, ever stick a raw input you got from a client into an SQL query!) But if the inputs are secret shared, then there is no way for an aggregator to discern even a single bit of the measurement, let alone check that it has an expected value. (A secret share of a valid measurement and a number sampled randomly from $ \lbrace 0,…,q – 1 \rbrace $ look identical.) At least, not on its own.

The solution adopted by Prio (and the standard, with some improvements), is a special kind of zero-knowledge proof (ZKP) system designed to operate on secret shared data. The goal is for a prover to convince a verifier that a statement about some data it has committed to is true (e.g., the user has a valid hardware key), without revealing the data itself (e.g. which hardware key is in-use).

Our setting is exactly the same, except that we're working on secret-shared data rather than committed data. Along with the measurement shares, the client sends shares of a validity proof; then during aggregation, the aggregators interact with one another in order to check and verify the proof. (One round-trip over the network is required.)

A happy consequence of working with secret shared data is that proof generation and verification are much faster than for committed (or encrypted) data. This is mainly because we avoid the use of public-key cryptography (i.e., elliptic curves) and are less constrained in how we choose cryptographic parameters. (We require the modulus $ q $ to be a prime number with a particular structure, but such primes are not hard to find.)

Non-linear aggregation

There are a variety of aggregation tasks for which Prio is not well-suited, in particular those that are non-linear. One such task is to find the "heavy hitters" among the set of measurements. The heavy hitters are the subset of the measurements that occur most frequently, say at least $ t $ times for some threshold $ t $. For example, the measurements might be the URLs visited on a given day by users of a web browser; the heavy hitters would be the set of URLs that were visited by at least $ t $ users.

This computation can be expressed as a simple program:

def heavy_hitters(measurements: list[bytes], t: int) -> set[bytes]:
    hh = defaultdict(lambda: 0)
    for measurement in measurements:
        hh[measurement] += 1
    return set(map(lambda x: x[0], filter(lambda x: x[1] >= t, hh.items())))

However, it cannot be expressed as a linear function, at least not efficiently (with sub-exponential space). This would be required to perform this computation on secret-shared measurements.

In order to enable non-linear computation on secret shared data, it is necessary to introduce some form of interaction. There are a few possibilities. For the heavy hitters problem in particular, Henry Corrigan-Gibbs and others devised a protocol called Poplar (IEEE Security & Privacy 2021) in which several rounds of aggregation and unsharding are performed, where in each round, information provided by the collector is used to "query" the measurements to obtain a refined aggregate result.

Helping to build a world of multi-party computation

Protocols like Prio or Poplar that enable computation over secret shared data fit into a rich tradition in cryptography known as multi-party computation (MPC). MPC is at once an active research area in theoretical computer science and a class of protocols that are beginning to see real-world use—in our case, to minimize the amount of privacy-sensitive information we collect in order to keep the Internet moving.

The PPM working group at IETF represents a significant effort, by Cloudflare and others, to standardize MPC techniques for privacy preserving measurement. This work has three main prongs:

To identify the types of problems that need to be solved.
To provide cryptography researchers from academia, industry, and the public sector with "templates" for solutions that we know how to deploy. One such template is called a "Verifiable Distributed Aggregation Function (VDAF)", which specifies a kind of "API boundary" between protocols like Prio and Poplar and the systems that are built around them. Cloudflare Research is leading development of the standard, contributing to implementations, and providing security analysis.
To provide a deployment roadmap for emerging protocols. DAP is one such roadmap: it specifies execution of a generic VDAF over HTTPS and attends to the various operational considerations that arise as deployments progress. As well as contributing to the standard itself, Cloudflare has developed its own implementation designed for our own infrastructure (see below).

The IETF is working on its first set of drafts (DAP/VDAF). These drafts are mature enough to deploy, and a number of deployments are scaling up as we speak. Our hope is that we have initiated positive feedback between theorists and practitioners: as new cryptographic techniques emerge, more practitioners will begin to work with them, which will lead to identifying new problems to solve, leading to new techniques, and so on.

Daphne: Cloudflare’s implementation of a DAP Aggregation Server

Our emerging technology group has been working on Daphne, our Rust-based implementation of a DAP aggregator server. This is only half of a deployment – DAP architecture requires two aggregator servers to interoperate, both operated by different parties. Our current version only implements the DAP Helper role; the other role is the DAP Leader. Plans are in the works to implement the Leader as well, which will open us up to deploy Daphne for more use cases.

We made two big decisions in our implementation here: using Rust and using Workers. Rust has been skyrocketing in popularity in the past few years due to its performance and memory management – a favorite of cryptographers for similar reasons. Workers is Cloudflare’s serverless execution environment that allows developers to easily deploy applications globally across our network – making it a favorite tool to prototype with at Cloudflare. This allows for easy integration with our Workers-based storage solutions like: Durable Objects, which we’re using for storing various data artifacts as required by the DAP protocol; and KV, which we’re using for managing aggregation task configuration. We’ve learned a lot from our interop tests and deployment, which has helped improve our own Workers products and which we have also fed back into the PPM working group to help improve the DAP standard.

If you’re interested in learning more about Daphne or collaborating with us in this space, you can fill out this form. If you’d like to get involved in the DAP standard, you can check out the working group.

Cloudflare now uses post-quantum cryptography to talk to your origin server

2023-09-29 Suleman Ahmad

Post Syndicated from Suleman Ahmad original http://blog.cloudflare.com/post-quantum-to-origins/

Cloudflare now uses post-quantum cryptography to talk to your origin server

Quantum computers pose a serious threat to security and privacy of the Internet: encrypted communication intercepted today can be decrypted in the future by a sufficiently advanced quantum computer. To counter this store-now/decrypt-later threat, cryptographers have been hard at work over the last decades proposing and vetting post-quantum cryptography (PQC), cryptography that’s designed to withstand attacks of quantum computers. After a six-year public competition, in July 2022, the US National Institute of Standards and Technology (NIST), known for standardizing AES and SHA, announced Kyber as their pick for post-quantum key agreement. Now the baton has been handed to Industry to deploy post-quantum key agreement to protect today’s communications from the threat of future decryption by a quantum computer.

Cloudflare operates as a reverse proxy between clients (“visitors”) and customers’ web servers (“origins”), so that we can protect origin sites from attacks and improve site performance. In this post we explain how we secure the connection from Cloudflare to origin servers. To put that in context, let’s have a look at the connection involved when visiting an uncached page on a website served through Cloudflare.

The first connection is from the visitor’s browser to Cloudflare. In October 2022, we enabled X25519+Kyber as a beta for all websites and APIs served through Cloudflare. However, it takes two to tango: the connection is only secured if the browser also supports post-quantum cryptography. As of August 2023, Chrome is slowly enabling X25519+Kyber by default.

The visitor’s request is routed through Cloudflare’s network (2). We have upgraded many of these internal connections to use post-quantum cryptography, and expect to be done upgrading all of our internal connections by the end of 2024. That leaves as the final link the connection (3) between us and the origin server.

We are happy to announce that we are rolling out support for X25519+Kyber for most outbound connections, including origin servers and Cloudflare Workers fetch() calls.

Plan	Support for post-quantum outbound connections
Free	Started roll-out. Aiming for 100% by the end of the October.
Pro and Business	Started roll-out. Aiming for 100% by the end of year.
Enterprise	Start roll-out February 2024. 100% by March 2024.

You can skip the roll-out and opt-in your zone today, or opt-out ahead of time, using an API described below. Before rolling out this support for enterprise customers in February 2024, we will add a toggle on the dashboard to opt out.

In this post we will dive into the nitty-gritty of what we enabled; how we have to be a bit subtle to prevent breaking connections to origins that are not ready yet, and how you can add support to your (origin) server.

But before we dive in, for the impatient:

Quick start

To enable a post-quantum connection between Cloudflare and your origin server today, opt-in your zone to skip the gradual roll-out:

curl --request PUT \
  --url https://api.cloudflare.com/client/v4/zones/(zone_id)/cache/origin_post_quantum_encryption \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer (API token)' \
  --data '{"value": "preferred"}'

Then, make sure your server supports TLS 1.3; enable and prefer the key agreement X25519Kyber768Draft00; and ensure it’s configured with server cipher preference. For example, to configure nginx (compiled with a recent BoringSSL) like this, use

ssl_ecdh_curve X25519Kyber768Draft00:X25519;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.3;

Replace (zone_id) and (API token) appropriately. Then, make sure your server supports TLS 1.3; enable and prefer the key agreement X25519Kyber768Draft00; and ensure it’s configured with server cipher preference. For example, to configure nginx (compiled with a recent BoringSSL) like this, use

	ssl_ecdh_curve X25519Kyber768Draft00:X25519;
	ssl_prefer_server_ciphers on;
	ssl_protocols TLSv1.3;

To check your server is properly configured, you can use the bssl tool of BoringSSL:

	$ bssl client -connect (your server):443 -curves X25519:X25519Kyber768Draft00
[...]
	  ECDHE curve: X25519Kyber768Draft00
[...]

We’re looking for X25519Kyber768Draft00 for a post-quantum connection as shown above instead of merely X25519.
For more client and server support, check out pq.cloudflareresearch.com. Now, let’s dive in.

Overview of a TLS 1.3 handshake

To understand how a smooth upgrade is possible, and where it might go wrong, we need to understand a few basics of the TLS 1.3 protocol, which is used to protect traffic on the Internet. A TLS connection starts with a handshake which is used to authenticate the server and derive a shared key. The browser (client) starts by sending a ClientHello message that contains among other things, the hostname (SNI) and the list of key agreement methods it supports.

To remove a round trip, the client is allowed to make a guess of what the server supports and start the key agreement by sending one or more client keyshares. That guess might be correct (on the left in the diagram below) or the client has to retry (on the right). By the way, this guessing of keyshares is a new feature of TLS 1.3, and it is the main reason why it’s faster than TLS 1.2.

In both cases the client sends a client keyshare to the server. From this client keyshare the server generates the shared key. The server then returns a server keyshare with which the client can also compute the shared key. This shared key is used to protect the rest of the connection using symmetric cryptography, such as AES.

Today X25519 is used as the key agreement in the vast majority of connections. To secure the connection against store-now/decrypt-later in the post-quantum world, a client can simply send a X25519+Kyber keyshare.

Hello! Retry Request? (HRR)

What we just described is the happy flow, where the client guessed correctly which key agreement the server supports. If the server does not support the keyshare that the client sent, then the server picks one of the supported key agreements that the client advertised, and asks for it in a HelloRetryRequest message.

This is not the only case where a server can use a HelloRetryRequest: even if the client sent keyshares that the server supports, the server is allowed to prefer a different key agreement the client advertised, and ask for it with a HelloRetryRequest. This will turn out to be very useful.

HelloRetryRequests are mostly undesirable: they add an extra round trip, and bring us back to the performance of TLS 1.2. We already had a transition of key agreement methods: back in the day P-256 was the de facto standard. When browsers couldn’t assume support for the newer X25519, some would send two keyshares, both X25519 and P-256 to prevent a HelloRetryRequest.

Also today, when enabling Kyber in Chrome, Chrome will send two keyshares: X25519 and X25519+Kyber to prevent a HelloRetryRequest. Sending two keyshares is not ideal: it requires the client to compute more, and it takes more space on the wire. This becomes more problematic when we want to send two post-quantum keyshares, as post-quantum keyshares are much larger. Talking about post-quantum keyshares, let’s have a look at X25519+Kyber.

The nitty-gritty of X25519+Kyber

The full name of the post-quantum key agreement we have enabled is X25519Kyber768Draft00, which has become the industry standard for early deployment. It is the combination (a so-called hybrid, more about that later) of two key agreements: X25519 and a preliminary version of NIST’s pick Kyber. Preliminary, because standardization of Kyber is not complete: NIST has released a draft standard for which it has requested public input. The final standard might change a little, but we do not expect any radical changes in security or performance. One notable change is the name: the NIST standard is set to be called ML-KEM. Once ML-KEM is released in 2024, we will promptly adopt support for the corresponding hybrid, and deprecate support for X25519Kyber768Draft00. We will announce deprecation on this blog and pq.cloudflareresearch.com.

Picking security level: 512 vs 768

Back in 2022, for incoming connections, we enabled hybrids with both Kyber512 and Kyber768. The difference is target security level: Kyber512 aims for the same security as AES-128, whereas Kyber768 matches up with AES-192. Contrary to popular belief, AES-128 is not broken in practice by quantum computers.

So why go with Kyber768? After years of analysis, there is no indication that Kyber512 fails to live up to its target security level. The designers of Kyber feel more comfortable, though, with the wider security margin of Kyber768, and we follow their advice.

Hybrid

It is not inconceivable though, that an unexpected improvement in cryptanalysis will completely break Kyber768. Notably Rainbow, GeMMS and SIDH survived several rounds of public review before being broken. We do have to add nuance here. For a big break you need some mathematical trick, and compared to other schemes, SIDH had a lot of mathematical attack surface. Secondly, even though a scheme participated in many rounds of review doesn’t mean it saw a lot of attention. Because of their performance characteristics, these three schemes have more niche applications, and therefore received much less scrutiny from cryptanalysts. In contrast, Kyber is the big prize: breaking it will ensure fame.

Notwithstanding, for the moment, we feel it’s wiser to stick with hybrid key agreement. We combine Kyber together with X25519, which is currently the de facto standard key agreement, so that if Kyber turns out to be broken, we retain the non-post quantum security of X25519.

Performance

Kyber is fast. Very fast. It easily beats X25519, which is already known for its speed:

		Size keyshares(in bytes)		Ops/sec (higher is better)
Algorithm	PQ	Client	Server	Client	Server
X25519	❌	32	32	17,000	17,000
Kyber768	✅	1,184	1,088	31,000	70,000
X25519Kyber768Draft00	✅	1,216	1,120	11,000	14,000

Combined X25519Kyber768Draft00 is slower than X25519, but not by much. The big difference is its size: when connecting the client has to send 1,184 extra bytes for Kyber in the first message. That brings us to the next topic.

When things break, and how to move forward

Split ClientHello

As we saw, the ClientHello is the first message that is sent by the client when setting up a TLS connection. With X25519, the ClientHello almost always fits within one network packet. With Kyber, the ClientHello doesn’t fit anymore with typical packet sizes and needs to be split over two network packets.

The TLS standard allows for the ClientHello to be split in this way. However, it used to be so exceedingly rare to see a split ClientHello that there is plenty of software and hardware out there that falsely assumes it never happens.

This so-called protocol ossification is the major challenge rolling out post-quantum key agreement. Back in 2019, during earlier post-quantum experiments, middleboxes of a particular vendor dropped connections with a split ClientHello. Chrome is currently slowly ramping up the number of post-quantum connections to catch these issues early. Several reports are listed here, and luckily most vendors seem to fix issues promptly.

Over time, with the slow ramp up of browsers, many of these implementation bugs will be found and corrected. However, we cannot completely rely on this for our outbound connections since in many cases Cloudflare is the sole client to connect directly to the origin server. Thus, we must exercise caution when deploying post-quantum cryptography to ensure that we are still able to reach origin servers even in the presence of buggy implementations.

HelloRetryRequest to the rescue

To enable support for post-quantum key agreement on all outbound connections, without risking issues with split ClientHello for those servers that are not ready yet, we make clever use of HelloRetryRequest. Instead of sending a X25519+Kyber keyshare, we will only advertise support for it, and send a non-post quantum secure X25519 keyshare in the first ClientHello.

If the origin does not support X25519+Kyber, then nothing changes. One might wonder: could merely advertising support for it trip up any origins? This used to be a real concern in the past, but luckily browsers have adopted a clever mechanism called GREASE: they will send codepoints selected from unpredictable regions to make it hard to implement any software that could trip up on unknown codepoints.

If the origin does support X25519+Kyber, then it can use the HelloRetryRequest to request a post-quantum key agreement from us.

Things might still break then: for instance a malfunctioning middlebox, load-balancer, or the server software itself might still trip over the large ClientHello with X25519+Kyber sent in response to the HelloRetryRequest.

If we’re frank, the HRR trick kicks the can down the road: we as an industry will need to fix broken hardware and software before we can enable post-quantum on every last connection. The important thing though is that those past mistakes will not hold us back from securing the majority of connections. Luckily, from our experience, breakage will not be common.

So, when you have flipped the switch on your origin server, and things do break against expectation, what could be the root cause?

Debugging and examples

It’s impossible to exhaustively list all bugs that could interfere with the post-quantum connection, but we like to share a few we’ve seen.

The first step is to figure out what pieces of hardware and software are involved in the connection. Rarely it’s just the server: there could be a load-balancer, and even a humble router could be at fault.

One straightforward mistake is to conveniently assume the ClientHello is small by reserving only a small, say 1000 byte, buffer.

A variation of this is where a server uses a single call to recv() to read the ClientHello from the TCP connection. This works perfectly fine if it fits within one packet, but when split over multiple, it might require more calls.

Not all issues that we encountered relate directly to split ClientHello. For instance, servers using the Rust TLS library rustls did not implement HelloRetryRequest correctly before 0.21.7.

If you turned on post-quantum support for your origin, and hit issues, please do reach out: email [email protected].

Opting in and opting out

Now that you know what might lie in wait for you, let’s cover how to configure the outbound connections of your zone. There are three settings. The setting affects all outbound connections for your zone: to the origin server, but also for fetch() requests made by Workers on your zone.

Setting	Meaning
supported	Advertise support for post-quantum key agreement, but send a classical keyshare in the first ClientHello.When the origin supports and prefers X25519+Kyber, a post-quantum connection will be established, but it incurs an extra roundtrip.This is the most compatible way to enable post-quantum.
preferred	Send a post-quantum keyshare in the first ClientHello.When the origin supports X25519+Kyber, a post-quantum connection will be established without an extra roundtrip.This is the most performant way to enable post-quantum.
off	Do not send or advertise support for post-quantum key agreement to the origin.
(default)	Allow us to determine the best behavior for your zone. (More about that later.)

The setting can be adjusted using the following API call:

curl --request PUT \
  --url https://api.cloudflare.com/client/v4/zones/(zone_id)/cache/origin_post_quantum_encryption \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer (API token)' \
  --data '{"value": "(setting)"}'

Here, the parameters are as follows.

Parameter	Value
setting	supported, preferred, or off, with meaning as described above
zone_id	Identifier of the zone to control. You can look up the zone_id in the dashboard.
API token	Token used to authenticate you. You can create one in the dashboard. Use create custom token and under permissions select zone → zone settings → edit.

Testing whether your origin server is configured correctly

If you set your zone to preferred mode, you only need to check support for the proper post-quantum key agreement with your origin server. This can be done with the bssl tool of BoringSSL:

	$ bssl client -connect (your server):443 -curves X25519:X25519Kyber768Draft00
[...]
	  ECDHE curve: X25519Kyber768Draft00
[...]

If you set your zone to supported mode, or if you wait for the gradual roll-out, you will need to make sure that your origin server prefers post-quantum key agreement even if we sent a classical keyshare in the initial ClientHello. This can be done with our fork of BoringSSL:

	$ git clone https://github.com/cloudflare/boringssl-pq
	[...]
	$ cd boringssl-pq && cmake -B build && make -C build
$ build/bssl client -connect (your server):443 -curves X25519:X25519Kyber768Draft00 -disable-second-keyshare
[...]
	  ECDHE curve: X25519Kyber768Draft00
[...]

Scanning ahead to remove the extra roundtrip

With the HelloRetryRequest trick today, we can safely advertise support for post-quantum key agreement to all origins. The downside is that for those origins that do support post-quantum key agreement, we’re incurring an extra roundtrip for the HelloRetryRequest, which hurts performance.

You can remove the roundtrip by configuring your zone as preferred, but we can do better: the best setting is the one you shouldn’t have to touch.

We have started scanning all active origins for support of post-quantum key agreement. Roughly every 24 hours, we will attempt a series of about ten TLS connections to your origin, to test support and preferences for the various key agreements.

Our preliminary results show that 0.5% of origins support a post-quantum connection. As expected, we found that a small fraction (<0.34%) of all origins do not properly establish a connection, when we send a post-quantum keyshare in the first ClientHello, which corresponds to the preferred setting. Unexpectedly the vast majority of these origins do return a HelloRetryRequest, but fail after receiving the second ClientHello with a classical keyshare. We are investigating the exact causes of these failures, and will reach out to vendors to help resolve them.

Later this year, we will start using these scan results to determine the best setting for zones that haven’t been configured yet. That means that for those zones whose origins support it reliably, we will send a post-quantum keyshare directly without extra roundtrip.

Also speeding up non post-quantum origins

The scanner pipeline we built will not just benefit post-quantum origins. By default we send X25519, but not every origin supports or prefers X25519. We find that 4% of origin servers will send us a HelloRetryRequest for other key agreements such as P-384.

Key agreement	Fraction supported	Fraction preferred
X25519	96%	96%
P-256	97%	0.6%
P-384	89%	2.3%
P-521	82%	0.1%
X25519Kyber768Draft00	0.5%	0.5%

Also, later this year, we will use these scan results to directly send the most preferred keyshare to your origin removing the need for an extra roundtrip caused by HRR.

Wrapping up

To mitigate the store-now/decrypt-later threat, and ensure the Internet stays encrypted, the IT industry needs to work together to roll out post-quantum cryptography. We’re excited that today we’re rolling out support for post-quantum secure outbound connections: connections between Cloudflare and the origins.

We would love it if you would try and enable post-quantum key agreement on your origin. Please, do share your experiences, or reach out for any questions: [email protected].

To follow the latest developments of our deployment of post-quantum cryptography, and client/server support, check out pq.cloudflareresearch.com and keep an eye on this blog.

Network performance update: Birthday Week 2023

2023-09-29 David Tuber

Post Syndicated from David Tuber original http://blog.cloudflare.com/network-performance-update-birthday-week-2023/

Network performance update: Birthday Week 2023

We constantly measure our own network’s performance against other networks, look for ways to improve our performance compared to them, and share the results of our efforts. Since June 2021, we’ve been sharing benchmarking results we’ve run against other networks to see how we compare.

In this post we are going to share the most recent updates since our last post in June, and tell you about our tools and processes that we use to monitor and improve our network performance.

How we stack up

Since June 2021, we’ve been taking a close look at every single network and taking actions for the specific networks where we have some room for improvement. Cloudflare was already the fastest provider for most of the networks around the world (we define a network as country and AS number pair). Taking a closer look at the numbers; in July 2022, Cloudflare was ranked #1 in 33% of the networks and was within 2 ms (95th percentile TCP Connection Time) or 5% of the #1 provider for 8% of the networks that we measured. For reference, our closest competitor on that front was the fastest for 20% of networks.

As of August 30, 2023, Cloudflare is the fastest provider for 44% of networks—and was within 2 ms (95th percentile TCP Connection Time) or 5% of the fastest provider for 10% of the networks that we measured—whereas our closest competitor is now the fastest for 19% of networks.

Below is the change in percentage of networks in which each provider is the fastest plotted over time.

Cloudflare is maintaining our steady growth in the percentage of networks where we’re the fastest. Despite the slight tick down the past couple of months, the trendline is still positive and with a higher rate of increase than other networks.

Now that we’ve reviewed how we stack up compared to other networks, let’s dig a little more into the other metrics we use to make us the fastest.

Our tooling

To provide insight into network performance, we use Real User Measurements (RUM) and fetch a small file from Cloudflare, Akamai, Amazon CloudFront, Fastly and Google Cloud CDN. Browsers around the world report the performance of those providers from the perspective of the end-user network they are on. The goal is to provide an accurate picture of where different providers are faster, and more importantly, where Cloudflare can improve. You can read more about the methodology in the original Speed Week blog post here.

Using the RUM data, we are able to measure various performance metrics, such as TCP Connection Time, Time to First Byte (TTFB), Time to Last Byte (TTLB), for ourselves and other networks.

Let’s take a look at some of the metrics we monitor and what’s changed since our last blog in June.

The first metric we closely monitor is the percent of networks that we are ranked #1 in terms of TCP Connection Time. That's a key performance indicator that we evaluate ourselves against. This first line of the table shows that Cloudflare was ranked #1 in 45% of networks in June 2023 and 44% in August 2023. Here’s the full picture of how we looked in June versus how we look today.

Cloudflare’s rank by TCP connection time	% of networks in June 2023	% of networks in August 2023
1	45	44
2	26	24
3	16	16
4	9	10
5	4	6

Overall, these metrics align with what we saw above: Cloudflare is still the fastest provider in the most last mile networks, and while there has been slight changes in the month-to-month fluctuations, the overall trend shows us as being the fastest.

The second metric we monitor is our overall performance in each country. This gives us visibility into the countries or regions that we need to pay closer attention to and take action towards improving our performance. Those actions will be listed later. Orange indicates the countries that Cloudflare is the fastest provider based on the TCP Connection Time. Here’s how we look as of September 2023:

For comparison, this is what that map looks like from June 2023:

We’ve become faster in Iran and Paraguay, and in the few cases where we are no longer number 1, we are within 2ms of the fastest provider. In Brazil and Norway for example, we trail Fastly by only 1ms. In various countries in Africa, Amazon CloudFront pulled ahead but only by 2ms. We aim to fix that in the coming weeks and months and return to the #1 spot there also.

The third set of metrics we use are TCP Connection Time and TTLB. The number of networks where we are #1 in terms of 95th percentile TCP Connection Time is one of our key performance indicators. We actively monitor and work on improving that metric so that we are #1 in the most metrics for 95th percentile TCP Connection Time. For September 2023, we are still #1 in the most networks for TCP Connection Time, more than double the next best provider.

Provider	# of networks where the provider is fastest for 95th percentile TCP connection time
Cloudflare	826
Google	392
Fastly	348
Cloudfront	337
Akamai	52

The way we achieve these great results is by having our engineering teams constantly investigate the underlying reasons for degraded performance if there are any, and we track open work items until they are resolved.

What’s next

We’re sharing our updates on our journey to become #1 everywhere so that you can see what goes into running the fastest network in the world. From here, our plan is the same as always: identify where we’re slower, fix it, and then tell you how we’ve gotten faster.

See what threats are lurking in your Office 365 with Cloudflare Email Retro Scan

2023-09-29 Ayush Kumar

Post Syndicated from Ayush Kumar original http://blog.cloudflare.com/threats-lurking-office-365-cloudflare-email-retro-scan/

See what threats are lurking in your Office 365 with Cloudflare Email Retro Scan

We are now announcing the ability for Cloudflare customers to scan old messages within their Office 365 Inboxes for threats. This Retro Scan will let you look back seven days and see what threats your current email security tool has missed.

Why run a Retro Scan

Speaking with customers, we often hear that they do not know the condition of their organization’s mailboxes. Organizations have an email security tool or use Microsoft’s built-in protection but do not understand how effective their current solution is. We find that these tools often let malicious emails through their filters increasing the risk of compromise within the company.

In our pursuit to help build a better Internet, we are enabling Cloudflare customers to use Retro Scan to scan messages within their inboxes using our advanced machine learning models for free. Our Retro Scan will detect and highlight any threats we find so that customers can clean up their inboxes by addressing them within their email accounts. With this information, customers can also implement additional controls, such as using Cloudflare or their preferred solution, to prevent similar threats from reaching their mailbox in the future.

Running a Retro Scan

Customers can navigate to the Cloudflare dashboard where they will see under the Area 1 tab the Retro Scan option:

To be able to access the messages to scan, Cloudflare needs authorization to be able to scan messages. You start this process by providing Cloudflare with the appropriate permissions to scan messages. The second authorization will allow the Cloudflare application to access Active Directory. This is needed to understand which users are within the organization along with which groups they belong to which helps our algorithms better assess if a messa ge is malicious.

Once all the authorizations are given, you have one final step which is to pick which domains we want to scan as well as providing us information about the other email security vendors who are protecting your inboxes.

Finally, customers can click “Generate Retro Scan” which will prompt Cloudflare Area 1 Email Security to start scanning older messages. Since this process takes time, we provide customers with an email alert when the scan is done.

Analyzing The Results

What you will be presented with is a quick breakdown of what threats we found within your organization’s email inboxes. The top section breaks down all of our detections by type. Here you can find the count of Malicious, Suspicious, Spoof, Spam, and Bulk messages. We also highlight the most important ones to look at under phish emails. At any point you can click the Search button to get more information about the emails with those labels.

The report also showcases the top targeted employees as well as the most common places where threats originate from. All these statistics are meant to provide a better understanding of what is going on within your company inbox.

The retro scan is currently in a closed beta. If you are interested in running a retro scan on your Office 365 email domains please reach out to your Cloudflare contact and we will get it added to your account.

After running a Retro Scan and seeing the results you can either choose to purchase Cloudflare Area 1 to prevent future threats from making it into your inbox or choose to set up a phishing risk assessment which is a 30 day free trial of the Area 1 product. Whereas the Retro Scan is a great tool to see what latent threats exist, a phishing risk assessment can help you gain better visibility on all the tools we have to keep mailboxes clean.

To get started you can click the “Request Trial” button at the bottom of the Retro Scan Report, fill out the corresponding form and someone from Cloudflare will reach out or you can reach out directly to your Cloudflare contact.

Detecting zero-days before zero-day

2023-09-29 Michael Tremante

Post Syndicated from Michael Tremante original http://blog.cloudflare.com/detecting-zero-days-before-zero-day/

Detecting zero-days before zero-day

We are constantly researching ways to improve our products. For the Web Application Firewall (WAF), the goal is simple: keep customer web applications safe by building the best solution available on the market.

In this blog post we talk about our approach and ongoing research into detecting novel web attack vectors in our WAF before they are seen by a security researcher. If you are interested in learning about our secret sauce, read on.

This post is the written form of a presentation first delivered at Black Hat USA 2023.

The value of a WAF

Many companies offer web application firewalls and application security products with a total addressable market forecasted to increase for the foreseeable future.

In this space, vendors, including ourselves, often like to boast the importance of their solution by presenting ever-growing statistics around threats to web applications. Bigger numbers and scarier stats are great ways to justify expensive investments in web security. Taking a few examples from our very own application security report research (see our latest report here):

The numbers above all translate to real value: yes, a large portion of Internet HTTP traffic is malicious, therefore you could mitigate a non-negligible amount of traffic reaching your applications if you deployed a WAF. It is also true that we are seeing a drastic increase in global API traffic, therefore, you should look into the security of your APIs as you are likely serving API traffic you are not aware of. You need a WAF with API protection capabilities. And so on.

There is, however, one statistic often presented that hides a concept more directly tied to the value of a web application firewall:

This brings us to zero-days. The definition of a zero-day may vary depending on who you ask, but is generally understood to be an exploit that is not yet, or has very recently become, widely known with no patch available. High impact zero-days will get assigned a CVE number. These happen relatively frequently and the value can be implied by how often we see exploit attempts in the wild. Yes, you need a WAF to make sure you are protected from zero-day exploits.

But herein hides the real value: how quickly can a WAF mitigate a new zero-day/CVE?

By definition a zero-day is not well known, and a single malicious payload could be the one that compromises your application. From a purist standpoint, if your WAF is not fast at detecting new attack vectors, it is not providing sufficient value.

The faster the mitigation, the better. We refer to this as “time to mitigate”. Any WAF evaluation should focus on this metric.

How fast is fast enough?

24 hours? 6 hours? 30 minutes? Luckily we run one of the world's largest networks, and we can look at some real examples to understand how quickly a WAF really needs to be to protect most environments. I specifically mention “most” here as not everyone is the target of a highly sophisticated attack, and therefore, most companies should seek to be protected at least by the time a zero-day is widely known. Anything better is a plus.

Our first example is Log4Shell (CVE-2021-44228). A high and wide impacting vulnerability that affected Log4J, a popular logging software maintained by the Apache Software Foundation. The vulnerability was disclosed back in December 2021. If you are a security practitioner, you have certainly heard of this exploit.

The proof of concept of this attack was published on GitHub on December 9, 2021, at 15:27 UTC. A tweet followed shortly after. We started observing a substantial amount of attack payloads matching the signatures from about December 10 at 10:00 UTC. That is about ~19 hours after the PoC was published.

We blogged extensively about this event if you wish to read further.

Our second example is a little more recent: Atlassian Confluence CVE-2022-26134 from June 2, 2022. In this instance Atlassian published a security advisory pertaining to the vulnerability at 20:00 UTC. We were very fast at deploying mitigations and had rules globally deployed protecting customers at 23:38 UTC, before the four-hour mark.

Although potentially matching payloads were observed before the rules were deployed, these were not confirmed. Exact matches were only observed on 2022-06-03 at 10:30 UTC, over 10 hours after rule deployment. Even in this instance, we provided our observations on our blog.

The list of examples could go on, but the data tells the same story: for most, as long as you have mitigations in place within a few hours, you are likely to be fine.

That, however, is a dangerous statement to make. Cloudflare protects applications that have some of the most stringent security requirements due to the data they hold and the importance of the service they provide. They could be the one application that is first targeted with the zero-day well before it is widely known. Also, we are a WAF vendor and I would not be writing this post if I thought “a few hours” was fast enough.

Zero (time) is the only acceptable time to mitigate!

Signatures are not enough, but are here to stay

All WAFs on the market today will have a signature based component. Signatures are great as they can be built to minimize false positives (FPs), their behavior is predictable and can be improved overtime.

We build and maintain our own signatures provided in the WAF as the Cloudflare Managed Ruleset. This is a set of over 320 signatures (at time of writing) that have been fine-tuned and optimized over the 13 years of Cloudflare’s existence.

Signatures tend to be written in ModSecurity, regex-like syntax or other proprietary language. At Cloudflare, we use wirefilter, a language understood by our global proxy. To use the same example as above, here is what one of our Log4Shell signatures looks like:

Our network, which runs our WAF, also gives us an additional superpower: the ability to test new signatures (or updates to existing ones) on over 64M HTTP/S requests per second at peak. We can tell pretty quickly if a signature is well written or not.

But one of their qualities (low false positive rates), along with the fact that humans have to write them, are the source of our inability to solely rely on signatures to reach zero time to mitigate. Ultimately a signature is limited by the speed at which we can write it, and combined with our goal to keep FPs low, they only match things we know and are 100% sure about. Our WAF security analyst team is, after all, limited by human speed while balancing the effectiveness of the rules.

The good news: signatures are a vital component to reach zero time to mitigate, and will always be needed, so the investment remains vital.

Getting to zero time to mitigation

To reach zero time to mitigate we need to rely on some machine learning algorithms. It turns out that WAFs are a great application for this type of technology especially combined with existing signature based systems. In this post I won’t describe the algorithms themselves (subject for another post) but will provide the high level concepts of the system and the steps of how we built it.

Step 1: create the training set

It is a well known fact in data science that the quality of any classification system, including the latest generative AI systems, is highly dependent on the quality of the training set. The old saying “garbage in, garbage out” resonates well.

And this is where our signatures come into play. As these were always written with a low false positive rate in mind, combined with our horizontal WAF deployment on our network, we essentially have access to millions of true positive examples per second to create what is likely one of the best WAF training sets available today.

We also, due to customer configurations and other tools such as Bot Management, have a pretty clear idea of what true negatives look like. In summary, we have a constant flow of training data. Additionally due to our self-service plans and the globally distributed nature of Cloudflare’s service and customer base, our data tends to be very diverse, removing a number of biases that may otherwise be present.

It is important to note at this point that we paid a lot of effort to ensure we anonymised data, removed PII, and that data boundary settings provided by our data localization suite were implemented correctly. We’ve published previously blog posts describing some of our strategies for data collection in the context of WAF use cases.

Step 2: enhance the training set

Simply relying on real traffic data is good, but with a few artificial enhancements the training set can become a lot better, leading to much higher detection efficacy.

In a nutshell we went through the process of generating artificial (but realistic) data to increase the diversity of our data even further by studying statistical distribution of existing real-world data. For example, mutating benign content with random character noise, language specific keywords, generating new benign content and so on.

Some of the methods adopted to improve accuracy are discussed in detail in a prior blog post if you wish to read further.

Step 3: build a very fast classifier

One restriction that often applies to machine learning based classifiers running to inline traffic, like the Cloudflare proxy, is latency performance. To be useful, we need to be able to compute classification “inline” without affecting the user experience for legitimate end users. We don’t want security to be associated with “slowness”.

This required us to fine tune not only the feature set used by the classification system, but also the underlying tooling, so it was both fast and lightweight. The classifier is built using TensorFlow Lite.

At time of writing, our classification model is able to provide a classification output under 1ms at 50th percentile. We believe we can reach 1ms at 90th percentile with ongoing efforts.

Step 4: deploy on the network

Once the classifier is ready, there is still a large amount of additional work needed to deploy on live production HTTP traffic, especially at our scale. Quite a few additional steps need to be implemented starting from a fully formed live HTTP request and ending with a classification output.

The diagram below is a good summary of each step. First and foremost, starting from the raw HTTP request, we normalize it, so it can easily be parsed and processed, without unintended consequences, by the following steps in the pipeline. Second we extract the relevant features found after experimentation and research, that would be more beneficial for our use case. To date we extract over 6k features. We then run inference on the resulting features (the actual classification) and generate outputs for the various attack types we have trained the model for. To date we classify cross site scripting payloads (XSS), SQL injection payloads (SQLi) and remote code execution payloads (RCE). The final step is to consolidate the output in a single WAF Attack Score.

Step 5: expose output as a simple interface

To make the system usable we decided the output should be in the same format as our Bot Management system output. A single score that ranges from 1 to 99. Lower scores indicate higher probability that the request is malicious, higher scores indicate the request is clean.

There are two main benefits of representing the output within a fixed range. First, using the output to BLOCK traffic becomes very easy. It is sufficient to deploy a WAF rule that blocks all HTTP requests with a score lower than $x, for example a rule that blocks all traffic with a score lower than 10 would look like this:

cf.waf.score < 10 then BLOCK

Secondly, deciding what the threshold should be can be done easily by representing the score distributions on your live traffic in colored “buckets”, and then allowing you to zoom in where relevant to validate the correct classification. For example, the graph below shows an attack that we observed against blog.cloudflare.com when we initially started testing the system. This graph is available to all business and enterprise users.

All that remains, is to actually use the score!

Success in the wild

The classifier has been deployed for just over a year on Cloudflare’s network. The main question stated at the start of this post remains: does it work? Have we been able to detect attacks before we’ve seen them? Have we achieved zero time to mitigate?

To answer this we track classification output for new CVEs that fail to be detected by existing Cloudflare Managed Rules. Of course our rule improvement work is always ongoing, but this gives us an idea on how well the system is performing.

And the answer: YES. For all CVEs or bypasses that rely on syntax similar to existing vulnerabilities, the classifier performs very well, and we have observed several instances of it blocking valid malicious payloads that were not detected by our signatures. All of this, while keeping false positives very low at a threshold of 15 or below. XSS variations, SQLi CVEs, are in most cases, a problem fully solved if the classifier is deployed.

One recent example is a set of Sitecore vulnerabilities that were disclosed in June 2023 listed below:

CVE	Date	Score	Signature match	Classification match (score less than 10)
CVE-2023-35813	06/17/2023	9.8 CRITICAL	Not at time of announcement	Yes
CVE-2023-33653	06/06/2023	8.8 HIGH	Not at time of announcement	Yes
CVE-2023-33652	06/06/2023	8.8 HIGH	Not at time of announcement	Yes
CVE-2023-33651	06/06/2023	7.5 HIGH	Not at time of announcement	Yes

The CVEs listed above were not detected by Cloudflare Managed Rules, but were correctly detected and classified by our model. Customers that had the score deployed in a rule in June 2023, would have been protected in zero time.

This does not mean there isn’t space for further improvement.

The classification works very well for attack types that are aligned, or somewhat similar to existing attack types. If the payload implements a brand new never seen before syntax, then we still have some work to do. Log4Shell is actually a very good example of this. If another zero-day vulnerability was discovered that leveraged the JNDI Java syntax, we are confident that our customers who have deployed WAF rules using the WAF Attack Score would be safe against it.

We are already working on adding more detection capabilities including web shell detection and open redirects/path traversal.

The perfect feedback loop

I mentioned earlier that our security analyst driven improvements to our Cloudflare Managed Rulesets are not going to stop. Our public changelog is full of activity and there is no sign of slowing down.

There is a good reason for this: the signature based system will remain, and likely eventually be converted to our training set generation tool. But not only that, it also provides an opportunity to speed up improvements by focusing on reviewing malicious traffic that is classified by our machine learning system but not detected by our signatures. The delta between the two systems is now one of the main focuses of attention for our security analyst team. The diagram below visualizes this concept.

It is this delta that is helping our team to further fine tune and optimize the signatures themselves. Both to match malicious traffic that is bypassing the signatures, and to reduce false positives. You can now probably see where this is going as we are starting to build the perfect feedback loop.

Better signatures provide a better training set (data). In turn, we can create a better model. The model will provide us with a more interesting delta, which, once reviewed by humans, will allow us to create better signatures. And start over.

We are now working to automate this entire process with the goal of having humans simply review and click to deploy. This is the leading edge for WAF zero-day mitigation in the industry.

Summary

One of the main value propositions of any web application security product is the ability to detect novel attack vectors before they can cause an issue, allowing internal teams time to patch and remediate the underlying codebase. We call this time to mitigate. The ideal value is zero.

We’ve put a lot of effort and research into a machine learning system that augments our existing signature based system to yield very good classification results of new attack vectors the first time they are seen. The system outputs a score that we call the WAF Attack Score. We have validated that for many CVEs, we are indeed able to correctly classify malicious payloads on the first attempt and provide Sitecore CVEs as an example.

Moving forward, we are now automating a feedback loop that will allow us to both improve our signatures faster, to then subsequently iterate on the model and provide even better detection.

The system is live and available to all our customers in the business or enterprise plan. Log in to the Cloudflare dashboard today to receive instant zero-day mitigation.

Post-quantum cryptography goes GA

2023-09-29 Wesley Evans

Post Syndicated from Wesley Evans original http://blog.cloudflare.com/post-quantum-cryptography-ga/

Post-quantum cryptography goes GA

Over the last twelve months, we have been talking about the new baseline of encryption on the Internet: post-quantum cryptography. During Birthday Week last year we announced that our beta of Kyber was available for testing, and that Cloudflare Tunnel could be enabled with post-quantum cryptography. Earlier this year, we made our stance clear that this foundational technology should be available to everyone for free, forever.

Today, we have hit a milestone after six years and 31 blog posts in the making: we’re starting to roll out General Availability¹ of post-quantum cryptography support to our customers, services, and internal systems as described more fully below. This includes products like Pingora for origin connectivity, 1.1.1.1, R2, Argo Smart Routing, Snippets, and so many more.

This is a milestone for the Internet. We don't yet know when quantum computers will have enough scale to break today's cryptography, but the benefits of upgrading to post-quantum cryptography now are clear. Fast connections and future-proofed security are all possible today because of the advances made by Cloudflare, Google, Mozilla, the National Institutes of Standards and Technology in the United States, the Internet Engineering Task Force, and numerous academic institutions

What does General Availability mean? In October 2022 we enabled X25519+Kyber as a beta for all websites and APIs served through Cloudflare. However, it takes two to tango: the connection is only secured if the browser also supports post-quantum cryptography. Starting August 2023, Chrome is slowly enabling X25519+Kyber by default.

The user’s request is routed through Cloudflare’s network (2). We have upgraded many of these internal connections to use post-quantum cryptography, and expect to be done upgrading all of our internal connections by the end of 2024. That leaves as the final link the connection (3) between us and the origin server.

We are happy to announce that we are rolling out support for X25519+Kyber for most inbound and outbound connections as Generally Available for use including origin servers and Cloudflare Workers fetch()es.

Plan	Support for post-quantum outbound connections
Free	Started roll-out. Aiming for 100% by the end of the October.
Pro and business	Aiming for 100% by the end of year.
Enterprise	Roll-out begins February 2024. 100% by March 2024.

For our Enterprise customers, we will be sending out additional information regularly over the course of the next six months to help prepare you for the roll-out. Pro, Business, and Enterprise customers can skip the roll-out and opt-in within your zone today, or opt-out ahead of time using an API described in our companion blog post. Before rolling out for Enterprise in February 2024, we will add a toggle on the dashboard to opt out.

If you're excited to get started now, check out our blog with the technical details and flip on post-quantum cryptography support via the API!

What’s included and what is next?

With an upgrade of this magnitude, we wanted to focus on our most used products first and then expand outward to cover our edge cases. This process has led us to include the following products and systems in this roll out:

1.1.1.1
AMP
API Gateway
Argo Smart Routing
Auto Minify
Automatic Platform Optimization
Automatic Signed Exchange
Cloudflare Egress
Cloudflare Images
Cloudflare Rulesets
Cloudflare Snippets
Cloudflare Tunnel
Custom Error Pages
Flow Based Monitoring
Health checks
Hermes
Host Head Checker
Magic Firewall
Magic Network Monitoring
Network Error Logging
Project Flame
Quicksilver
R2 Storage
Request Tracer
Rocket Loader
Speed on Cloudflare Dash
SSL/TLS
Traffic Manager
WAF, Managed Rules
Waiting Room
Web Analytics

If a product or service you use is not listed here, we have not started rolling out post-quantum cryptography to it yet. We are actively working on rolling out post-quantum cryptography to all products and services including our Zero Trust products. Until we have achieved post-quantum cryptography support in all of our systems, we will publish an update blog in every Innovation Week that covers which products we have rolled out post-quantum cryptography to, the products that will be getting it next, and what is still on the horizon.

Products we are working on bringing post-quantum cryptography support to soon:

Cloudflare Gateway
Cloudflare DNS
Cloudflare Load Balancer
Cloudflare Access
Always Online
Zaraz
Logging
D1
Cloudflare Workers
Cloudflare WARP
Bot Management

Why now?

As we announced earlier this year, post-quantum cryptography will be included for free in all Cloudflare products and services that can support it. The best encryption technology should be accessible to everyone – free of charge – to help support privacy and human rights globally.

As we mentioned in March:

“What was once an experimental frontier has turned into the underlying fabric of modern society. It runs in our most critical infrastructure like power systems, hospitals, airports, and banks. We trust it with our most precious memories. We trust it with our secrets. That’s why the Internet needs to be private by default. It needs to be secure by default.”

Our work on post-quantum cryptography is driven by the thesis that quantum computers that can break conventional cryptography create a similar problem to the Year 2000 bug. We know there is going to be a problem in the future that could have catastrophic consequences for users, businesses, and even nation states. The difference this time is we don’t know how the date and time that this break in the computational paradigm will occur. Worse, any traffic captured today could be decrypted in the future. We need to prepare today to be ready for this threat.

We are excited for everyone to adopt post-quantum cryptography into their systems. To follow the latest developments of our deployment of post-quantum cryptography and third-party client/server support, check out pq.cloudflareresearch.com and keep an eye on this blog.

***

¹We are using a preliminary version of Kyber, NIST’s pick for post-quantum key agreement. Kyber has not been finalized. We expect a final standard to be published in 2024 under the name ML-KEM, which we will then adopt promptly while deprecating support for X25519Kyber768Draft00.

Découvrez les menaces qui se dissimulent dans votre boîte aux lettres Office 365 avec Cloudflare Email Retro Scan

2023-09-29 Ayush Kumar

Post Syndicated from Ayush Kumar original http://blog.cloudflare.com/fr-fr/threats-lurking-office-365-cloudflare-email-retro-scan-fr-fr/

Nous annonçons maintenant la possibilité pour les clients de Cloudflare d’analyser les anciens messages dans leurs boîtes de réception Office 365 afin de détecter les menaces. Le service Retro Scan vous permet de revenir sept jours en arrière, afin d’identifier les menaces qui n’ont pas été détectées par votre outil de sécurité actuel.

Pourquoi exécuter le service Retro Scan

Lorsque nous échangeons avec nos clients, ces derniers nous apprennent souvent qu’ils n’ont pas connaissance de l’état des boîtes aux lettres de leur entreprise. Les entreprises disposent d’un outil de sécurité des e-mails, ou elles utilisent la protection intégrée de Microsoft, mais elles ne sont pas en mesure de comprendre l’efficacité de leur solution actuelle. Nous constatons que les filtres de ces outils laissent souvent passer des e-mails malveillants, augmentant le risque de compromission de données au sein des entreprises.

Conformément à notre engagement de contribuer à bâtir un Internet meilleur, nous permettons désormais aux clients de Cloudflare d’utiliser Retro Scan pour analyser les messages dans leurs boîtes de réception à l’aide de nos modèles d’apprentissage automatique avancés – et ce, gratuitement. Notre service Retro Scan détectera et mettra en évidence toutes les menaces que nous identifions, afin de permettre aux clients d’éliminer les menaces contenues dans leurs boîtes de réception en remédiant directement à celles-ci depuis leurs comptes de messagerie. Avec ces informations, les clients peuvent également mettre en œuvre des contrôles supplémentaires, tels que l’utilisation de Cloudflare ou de la solution de leur choix, afin d’éviter que des menaces similaires ne parviennent leurs boîtes aux lettres à l’avenir.

Exécuter le service Retro Scan

Les clients peuvent accéder au tableau de bord de Cloudflare ; l’option Retro Scan se trouve sous l’onglet Area 1 :

Pour permettre à Cloudflare d’accéder aux messages à analyser, vous devez autoriser l’analyse des messages par l’application. Pour démarrer ce processus, accordez à Cloudflare les autorisations nécessaires pour exécuter l’analyse des messages. Une deuxième autorisation est nécessaire pour permettre à l’application Cloudflare d’accéder à Active Directory, afin de déterminer quels utilisateurs font partie de l’entreprise, ainsi que les groupes auxquels ils appartiennent ; ceci permet à nos algorithmes de mieux évaluer le caractère malveillant d’un message.

Une fois toutes les autorisations accordées, il reste une dernière étape : sélectionnez les domaines que vous souhaitez analyser, puis fournissez les informations requises concernant les autres fournisseurs de solutions de sécurité des e-mails utilisées pour protéger vos boîtes de réception.

Enfin, les clients peuvent cliquer sur « Generate Retro Scan » ; la solution de sécurité des e-mails Cloudflare Area 1 commencera alors à analyser les anciens messages. Puisque ce processus demande du temps, nous vous informerons par e-mail lorsque l’analyse sera terminée.

Analyse des résultats

Le service vous fournira une analyse rapide des menaces que nous avons détectées dans les boîtes de réception de votre entreprise. La section supérieure présente toutes les détections par type, indiquant le nombre de messages correspondant à chacune de ces catégories : Malicious (malveillants), Suspicious (suspects), Spoof (imitation), Spam (indésirables) et Bulk (envoi en masse). Nous mettons également en évidence les détections les plus importantes, qui requièrent votre attention, sous la catégorie Phish (phishing). Vous pouvez à tout moment cliquer sur le bouton Search (Rechercher) pour obtenir plus d’informations sur les e-mails portant ces intitulés.

Le rapport présente également les employés les plus fréquemment ciblés, ainsi que les endroits d’où proviennent le plus souvent les menaces. Toutes ces statistiques sont destinées à vous permettre de mieux comprendre ce qui se passe dans la boîte de réception de votre entreprise.

Comment s’inscrire ?

Le service Retro Scan est actuellement proposé en version bêta fermée. Si vous souhaitez exécuter le service Retro Scan sur vos domaines de messagerie Office 365, veuillez contacter votre interlocuteur chez Cloudflare, et nous ajouterons le service à votre compte.

Après avoir exécuté le service Retro Scan et examiné les résultats, vous pouvez choisir d’acheter la solution Cloudflare Area 1 afin d’empêcher les menaces futures d’atteindre votre boîte de réception ou choisir de mettre en place une évaluation du risque lié au phishing, qui propose un essai gratuit pendant 30 jours du produit Area 1. Si le service Retro Scan est un excellent outil pour détecter les menaces latentes, l’évaluation des risques liés au phishing peut vous aider à acquérir une meilleure visibilité de l’ensemble des outils que nous proposons pour protéger les boîtes aux lettres.

Pour commencer, vous pouvez cliquer sur le bouton Request Trial (Demander un essai) en bas du rapport Retro Scan, puis renseigner le formulaire correspondant ; un collaborateur de Cloudflare vous contactera alors, ou vous pouvez contacter directement votre interlocuteur Cloudflare.

Sehen Sie, welche Bedrohungen in Ihrem Office 365 lauern – mit dem Retro Scan von Cloudflare für E-Mails

2023-09-29 Ayush Kumar

Post Syndicated from Ayush Kumar original http://blog.cloudflare.com/de-de/threats-lurking-office-365-cloudflare-email-retro-scan-de-de/

Ab sofort können Cloudflare-Kunden alte Nachrichten in ihren Office 365-Postfächern auf Bedrohungen hin scannen. Mit dem Retro Scan können Sie jeweils die vergangenen sieben Tage überprüfen, um zu sehen, welche Bedrohungen Ihrem aktuellen E-Mail-Sicherheitstool entgangen sind.

Gründe für den Einsatz eines Retro Scan

Kunden berichten uns oft, dass sie nicht wissen, in welchem Zustand die E-Mail-Postfächer ihrer Unternehmen sind. Firmen nutzen ein E-Mail-Sicherheitstool oder den bei Microsoft integrierten Schutz. Oft ist wissen sie aber nicht, wie effektiv ihre aktuelle Lösung tatsächlich arbeitet. Wir haben festgestellt, dass schädliche E-Mails von diesen Werkzeugen oft nicht herausgefiltert werden, wodurch sich das Risiko einer Kompromittierung innerhalb des Unternehmens erhöht.

Im Rahmen unserer Bemühungen, ein besseres Internet zu schaffen, stellen wir Cloudflare-Kunden nun einen Retro Scan zur Verfügung. Mit diesem können sie Nachrichten in ihren Postfächern unter Einsatz fortschrittlicher Machine Learning-Modelle kostenlos scannen. Unser Retro Scan erkennt Bedrohungen und weist auf diese hin, sodass Kunden ihre Postfächer durch eine Behebung innerhalb ihrer E-Mail-Konten bereinigen können. Mit diesen Informationen sind sie außerdem in der Lage, herkömmliche Kontrollen zu implementieren. Sie können also Cloudflare oder ihre bevorzugte Lösung einsetzen, um vergleichbare Bedrohungen in Zukunft daran zu hindern, ihre Postfach überhaupt erst zu erreichen.

Einsatz des Retro Scan

Kunden finden im Cloudflare-Dashboard unter der Registerkarte Area 1 die Option „Retro Scan“:

Um zum Scannen auf die Nachrichten zugreifen zu können, benötigt Cloudflare eine entsprechende Berechtigung. Diese müssen Sie zunächst erteilen.Eine zweite Autorisierung erlaubt der Cloudflare-Anwendung den Zugriff auf Active Directory. Das ist notwendig, um in Erfahrung zu bringen, welche Nutzer zu dem Unternehmen gehören und welchen Gruppen sie angehören. Dies erleichtert es unseren Algorithmen, eine Einschätzung dazu zu treffen, ob eine Nachricht schädlich ist.

Nachdem alle Genehmigungen erteilt wurden, bleibt noch ein letzter Schritt: Sie müssen auswählen, welche Domains gescannt werden und uns Informationen zu den anderen E-Mail-Sicherheitsdiensten zukommen lassen, die Ihre Postfächer schützen.

Zu guter Letzt können Kunden per Klick auf „Generate Retro Scan“ die E-Mail-Sicherheitslösung Cloudflare Area 1 dazu veranlassen, mit dem Scan älterer Nachrichten zu beginnen. Da dieser Vorgang eine gewisse Zeit in Anspruch nimmt, werden die Kunden per E-Mail vom Abschluss des Scans informiert.

Analyse der Ergebnisse

Ihnen wird ein kurzer Überblick über die in den Postfächern Ihres Unternehmens aufgespürten Bedrohungen angezeigt. Im obersten Abschnitt werden alle ermittelten Bedrohungen nach Typ in Kategorien unterteilt. Hier sehen sie, wie viele schädliche, verdächtige und gefälschte Nachrichten sowie Spam- und Massennachrichten Sie jeweils erhalten haben. Unter „Phish emails“ heben wir die Nachrichten hervor, die die größte Aufmerksamkeit verdienen. Sie können sich jederzeit mit einem Klick auf das Suchfeld weitere Informationen über die entsprechend gekennzeichneten E-Mails anzeigen lassen.

In dem Bericht werden auch die Mitarbeitenden herausgehoben, die am stärksten zur Zielscheibe geworden sind, sowie die häufigsten Ursprünge von Bedrohungen. Diese Statistiken sollen Ihnen eine klarere Vorstellung davon vermitteln, was in den Postfächern Ihres Unternehmens vor sich geht.

Sie möchten sich registrieren? So funktioniert’s

Der Retro Scan ist zurzeit als Closed Beta-Version verfügbar. Falls Sie daran interessiert sind, ihn bei Ihren Office 365-E-Mail-Domains einzusetzen, wenden Sie sich gern an Ihre Ansprechpartnerin oder Ihren Ansprechpartner bei Cloudflare. Wir schalten diese Funktion dann für Ihr Konto frei.

Nachdem Sie einen Retro Scan durchgeführt und die Ergebnisse in Augenschein genommen haben, können Sie entweder zur Abschirmung Ihres Postfachs vor künftigen Bedrohungen Cloudflare Area 1 erwerben oder eine Phishing-Risikowertung vornehmen lassen, wobei es sich um eine 30-tägige kostenlose Probeversion des Area 1-Produkts handelt. Der Retro Scan ist ein großartiges Werkzeug zur Ermittlung latenter Bedrohungen. Eine Phishing-Risikobewertung hilft Ihnen dabei, sich einen besseren Überblick über alle Tools zu verschaffen, mit denen wir dafür sorgen, dass Postfächer nicht infiziert werden.

Zum Einstieg können Sie auf die Schaltfläche „Request Trial“ am Ende des Retro Scan-Berichts klicken und das daraufhin angezeigte Formular ausfüllen. Einer bzw. eine unserer Mitarbeitenden wird sich dann mit Ihnen in Verbindung setzen. Sie können sich aber auch direkt an Ihren Ansprechpartner bzw. Ihre Ansprechpartnerin bei Cloudflare wenden.

Veja quais ameaças estão escondidas no seu Office 365 com o Cloudflare Email Retro Scan

2023-09-29 Ayush Kumar

Post Syndicated from Ayush Kumar original http://blog.cloudflare.com/pt-br/threats-lurking-office-365-cloudflare-email-retro-scan-pt-br/

Agora anunciamos a possibilidade de os clientes da Cloudflare verificarem mensagens antigas em suas caixas de entrada do Office 365 em busca de ameaças. Este Retro Scan permitirá que você analise sete dias atrás e veja quais ameaças sua ferramenta de segurança de e-mail atual deixou passar.

Por que executar um Retro Scan

Conversando com os clientes, ouvimos frequentemente que eles não sabem o estado das caixas de entrada de suas organizações. As organizações possuem uma ferramenta de segurança de e-mail ou usam a proteção integrada da Microsoft, mas não entendem a eficácia de sua solução atual. Descobrimos que essas ferramentas muitas vezes permitem que e-mails maliciosos passem por seus filtros, aumentando o risco de comprometimento dentro da empresa.

Em nossa busca para ajudar a construir uma internet melhor, disponibilizamos para os clientes da Cloudflare o uso do Retro Scan para verificar mensagens em suas caixas de entrada usando nossos modelos avançados de aprendizado de máquina gratuitamente. Nosso Retro Scan detecta e destaca quaisquer ameaças que encontrarmos, assim os clientes podem limpar suas caixas de entrada tratando-as em suas contas de e-mail. Com essas informações, os clientes também podem implementar controles adicionais, como usar a Cloudflare ou sua solução preferida, para evitar que ameaças semelhantes cheguem às suas caixas de entrada no futuro.

Executar um Retro Scan

Os clientes podem navegar até o painel da Cloudflare, onde verão na guia Area 1 a opção Retro Scan:

Para poder acessar as mensagens, a Cloudflare precisa de autorização para poder verificar as mensagens. Você inicia esse processo fornecendo à Cloudflare as permissões apropriadas para verificar as mensagens. A segunda autorização permite que o aplicativo da Cloudflare acesse o Active Directory. Isso é necessário para entender quais usuários estão dentro da organização e a quais grupos eles pertencem, o que ajuda nossos algoritmos a avaliar melhor se uma mensagem é maliciosa.

Depois que todas as autorizações forem concedidas, você terá uma etapa final que é escolher quais domínios vamos verificar e nos fornecer informações sobre outros fornecedores de segurança de e-mail que estão protegendo suas caixas de entrada.

Por fim, os clientes podem clicar em “Gerar Retro Scan”, o que fará com que o Cloudflare Area 1 Email Security comece a verificar as mensagens mais antigas. Como esse processo é demorado, fornecemos aos clientes um alerta por e-mail quando a verificação estiver concluída.

Analise dos resultados

O que vai ser apresentado a você é uma rápida análise das ameaças que encontramos nas caixas de entrada de e-mail de sua organização. A seção superior divide todas as nossas detecções por tipo. Aqui você pode encontrar a contagem de mensagens maliciosas, suspeitas, falsas, spam e em massa. Também destacamos aquelas mais importantes a serem observadas nos e-mails de phishing. A qualquer momento você pode clicar no botão Pesquisar para obter mais informações sobre os e-mails com esses marcadores.

O relatório também mostra os principais funcionários visados, bem como os locais mais comuns de origem das ameaças. Todas essas estatísticas têm como objetivo fornecer uma melhor compreensão do que está acontecendo na caixa de entrada da sua empresa.

Como faço para me cadastrar

O Retro Scan está atualmente em beta fechado. Se você tiver interesse em executar uma verificação retroativa em seus domínios de e-mail do Office 365, fale com seu contato da Cloudflare e nós o adicionaremos à sua conta.

Depois de executar o Retro Scan e ver os resultados, você pode optar por adquirir o Cloudflare Area 1 para evitar que ameaças futuras cheguem à sua caixa de entrada ou optar por configurar uma avaliação de risco de phishing, que é uma avaliação gratuita de 30 dias do produto Area 1. Embora o Retro Scan seja uma ótima ferramenta para ver quais ameaças latentes existem, uma avaliação de risco de phishing pode ajudá-lo a obter melhor visibilidade sobre todas as ferramentas que temos para manter as caixas de entrada limpas.

Para começar, você pode clicar no botão “Solicitar avaliação” na parte inferior do relatório Retro Scan, preencher o formulário correspondente e alguém da Cloudflare entrará em contato ou você pode falar diretamente com seu contato da Cloudflare.

Descubre qué amenazas acechan tu buzón de correo de Office 365 con Cloudflare Email Retro Scan

2023-09-29 Ayush Kumar

Post Syndicated from Ayush Kumar original http://blog.cloudflare.com/es-es/threats-lurking-office-365-cloudflare-email-retro-scan-es-es/

Ahora los clientes de Cloudflare pueden analizar viejos mensajes de sus bandejas de entrada de Office 365 en busca de amenazas. Retro Scan te permitirá observar qué amenazas ha pasado por alto tu actual herramienta de seguridad del correo electrónico en los últimos siete días.

Por qué ejecutar Retro Scan

Al hablar con los clientes, solemos escuchar que no conocen el estado de los buzones de correo de sus organizaciones. Las organizaciones tienen una herramienta de seguridad para correo electrónico o usan la protección integrada de Microsoft, pero no entienden qué nivel de efectividad tiene la actual solución. A menudo, descubrimos que estas herramientas permiten el paso de correos electrónicos maliciosos a través de sus filtros, lo que aumenta el riesgo en la empresa.

En nuestra búsqueda de ayudar a crear un mejor servicio de Internet, permitimos a los clientes de Cloudflare el uso de Retro Scan para analizar mensajes en sus buzones de entrada con nuestros modelos de aprendizaje automático avanzados, ¡gratis! Nuestro Retro Scan detecta y resalta las amenazas que encontramos para que los clientes puedan limpiar sus buzones de entrada y gestionarlas dentro de sus cuentas de correo electrónico. Con esta información, los clientes también pueden implementar controles adicionales, como el uso de Cloudflare o las soluciones que prefieran, para evitar que amenazas similares lleguen a sus casillas de correo en el futuro.

Cómo ejecutar Retro Scan

Los clientes pueden ir al panel de Cloudflare y allí verán debajo de la pestaña Área 1 la opción de Retro Scan:

Para poder tener acceso a los mensajes, Cloudflare necesita tener autorización para analizarlos. Para comenzar este proceso, debes brindar a Cloudflare los permisos correspondientes para analizar los mensajes. La segunda autorización permitirá que la aplicación de Cloudflare acceda al directorio activo. Eso es necesario para comprender qué usuarios están en la organización y a qué grupos pertenecen, lo que ayuda a que nuestros algoritmos evalúen mejor si un mensaje es malicioso.

Una vez que se conceden todas las autorizaciones, queda un último paso que consiste en elegir qué dominios queremos analizar y se nos facilita información sobre los demás proveedores de seguridad de correo electrónico que protegen tus bandejas de entrada.

Por último, los clientes pueden hacer clic en “Generar Retro Scan” que hará que Cloudflare Area 1 Email Security comience a analizar los mensajes más antiguos.Como este proceso lleva tiempo, avisamos a los clientes por correo electrónico cuando finaliza el análisis.

Cómo analizar los resultados

Se te brindará un detalle de las amenazas que encontramos en las bandejas de entrada de correo electrónico de tu organización.La sección superior muestra todas las detecciones por tipo. Aquí puedes encontrar el recuento de mensajes maliciosos, sospechosos, con suplantación de identidad, spam y mensajes masivos. También destacamos los más importantes a tener en cuenta en los correos electrónicos de phishing. En cualquier momento, puedes hacer clic en el botón Buscar para obtener más información sobre los correos electrónicos con esas etiquetas.

El informe también muestra los empleados que han recibido la mayor cantidad de ataques y los lugares más comunes de donde provienen las amenazas. Todas estas estadísticas sirven para comprender mejor lo que ocurre en la bandeja de entrada de tu empresa.

Cómo registrarse

El Retro Scan se encuentra actualmente en fase beta cerrada.Si te interesa ejecutar Retro Scan en tus dominios de correo electrónico de Office 365, comunícate con tu contacto de Cloudflare y lo incorporaremos a tu cuenta.

Después de ejecutar Retro Scan y ver los resultados, puedes optar por comprar Cloudflare Area 1 para evitar que futuras amenazas lleguen a tu bandeja de entrada o configurar una evaluación de riesgos de phishing, que es una prueba gratuita de 30 días del producto Área 1. Si bien Retro Scan es una excelente herramienta para ver qué amenazas latentes existen, una evaluación del riesgo de phishing puede ayudarte a obtener una mejor visibilidad de todas las herramientas que tenemos para mantener limpios los buzones de correo.

Para empezar, puedes hacer clic en el botón “Solicitar prueba” de la parte inferior del informe de Retro Scan, completar el formulario correspondiente y una persona de Cloudflare se pondrá en contacto contigo, o puedes comunicarte directamente con tu contacto de Cloudflare.

클라우드, 네트워크, 애플리케이션 및 사용자를 연결하고 보호하는 현대적인 방법인 클라우드 연결성으로 여러분을 모십니다

2023-09-29 Jen Taylor

Post Syndicated from Jen Taylor original http://blog.cloudflare.com/ko-kr/welcome-to-connectivity-cloud-ko-kr/

Welcome to connectivity cloud: the modern way to connect and protect your clouds, networks, applications and users

우리가 근무하면서 가장 좋아하는 부분은 Cloudflare 고객과 대화하는 시간입니다. 고객의 IT 및 보안 문제에 대하여 항상 새롭고 흥미로운 사실을 알게 됩니다.

최근 이러한 대화에 변화가 있었습니다. 고객이 언급하는 가장 큰 문제를 쉽게 정의할 수 없는 경우가 점점 더 많아집니다. 그리고 이러한 문제는 개별 제품이나 주요 기능으로 대처할 수 없는 것입니다.

더 정확히 말하면 IT 및 보안 팀에서는 디지털 환경에 대한 제어 능력을 잃고 있다고 이야기합니다.

제어 능력 상실은 다양한 형태를 띱니다. 고객은 호환성이 걱정되므로 필요성은 알지만 새로운 기능을 채택하는 것을 꺼리는 모습을 보일 수 있습니다. 아니면 비교적 단순한 변경 사항을 적용하는 데 시간과 노력이 많이 들며, 이러한 변경 사항 때문에 더 큰 영향력이 있을 작업에 투입할 시간을 빼앗기고 있다고 언급할 수도 있습니다. 고객이 느끼는 감정을 요약하자면 “팀이나 예산의 규모가 아무리 크더라도 비즈니스를 완벽하게 연결하고 보호하는 데는 절대 충분하지 않다”는 것입니다.

익숙하게 느껴지는 부분이 있으신가요? 그런 부분이 있다 해도 여러분 혼자 그렇게 느끼는 건 아닙니다.

제어 능력을 상실하는 이유

IT 및 보안이 바뀌는 속도는 빨라지고 있으며 무섭도록 복잡해지고 있습니다. IT 및 보안 팀에서는 과거에 비해 더 다양한 기술 도메인을 책임지고 있습니다. 최근 Forrester 연구에서 확인된 변화에 따르면 사내, 원격, 하이브리드 근무자를 보호할 책임이 있는 팀의 52%만이 지난 5년 동안 이러한 책임을 맡았습니다. 한편 46%는 해당 기간 동안 퍼블릭 클라우드 애플리케이션을 관리하고 보호할 책임이 생겼습니다. 그리고 53%는 규제 준수로 인한 어려운 문제를 떠맡았습니다.

IT 및 보안 팀에는 엄청난 과제가 생겼습니다. 원격 팀, 온프레미스 팀 및 인프라, 다양한 클라우드 환경, SaaS 앱 등을 연결하여 이들 모두가 안전한 단일 환경처럼 작동하게 만들어야 했습니다. 하지만 이 작업은 다양한 이유로 쉽지 않습니다.

대부분의 기업에서는 전용 인프라, 고유한 규제 준수 요구, 준호환성 프로세스 및 구성으로 인해 클라우드, SaaS 앱, 웹 앱, 온프레미스 인프라를 연결하는 것이 어렵습니다. 간단히 말하자면 이들 도메인은 쉽고 안전하게 함께 작동하도록 구축되지 않았습니다.
콘웨이의 법칙에 따르면 시스템은 조직의 커뮤니케이션 구조와 일치하는 경향이 있습니다. 팀 자체의 잘못은 아니지만, 수많은 IT 및 보안 팀이 상당히 단절되어 있습니다.

IT 및 보안은 언제 차선책과 복잡하게 얽힌 상호 의존성에 발목을 잡혀도 이상하지 않습니다.

다행히 Cloudflare에서는 전향적인 방법을 찾아냈습니다.

클라우드 연결성에 오신 것을 환영합니다

흔히 고객과의 대화에서 중요한 것은 행간을 읽는 능력입니다. 고객은 제어 능력 상실을 언급할 때, 명시하지는 않지만, 존재하지 않는다고 생각하는 무언가를 원하는 것처럼 보입니다. 고객은 IT 및 보안에서 담당하는 모든 것을 위한 연결 조직을 원합니다. 즉, 환경의 모든 것을 다루고, 모든 곳에서 제공되며, 필요한 모든 보안, 네트워킹, 개발 기능을 수행하여 복잡성을 줄이는 무언가를 필요로 합니다.

추가 연구 결과 우리의 짐작이 확신으로 바뀌었습니다. IT 및 보안 리더를 대상으로 진행한 설문조사에서는 이들 중 72%가 안전한 “모든 용도에 사용 가능한” 클라우드 플랫폼을 높이 평가하는 것으로 확인되었습니다. 그리고 이들은 전체 IT 및 보안 예산에서 평균 16%를 이러한 플랫폼에 투자할 의향이 있음을 밝혔습니다.

따라서 Cloudflare에서는 이런 클라우드 플랫폼이 정확히 어떤 모습일지 생각하기 시작했습니다. 그 플랫폼에서 필요한 모든 작업을 어떻게 수행할 수 있을까요?

우리가 찾은 해답을 공유합니다. 바로 클라우드 연결성입니다.

클라우드 연결성은 디지털 환경을 보호하고 연결하기 위해 기업에서 필요로 하는 다양한 서비스를 제공하는 새로운 접근법입니다. 클라우드 연결성은 프로그래밍 가능한 클라우드 네이티브 서비스의 통합 인텔리전스 플랫폼으로, 모든 네트워크(엔터프라이즈 및 인터넷), 클라우드 환경, 애플리케이션, 사용자 사이에 모든 용도에 사용 가능한 연결을 가능하게 해줍니다. 클라우드 연결성에는 수많은 보안, 성능, 개발자 서비스가 포함됩니다. 그 주안점은 모든 것을 모든 장소에서 대체하는 기능이 아니라, 필요한 장소에 탑재하고 중요한 여러 서비스를 단일 플랫폼으로 통합하는 능력입니다.

클라우드 연결성은 4가지 기본 원칙에 따라 구축되었습니다.

심층 통합 — 조직에서는 인터넷에 의존하여 디지털 환경의 다양한 요소를 근무자, 파트너, 고객과 연결합니다. 클라우드 연결성은 인터넷 및 엔터프라이즈 네트워크와 기본적으로 통합되므로 모든 사용자, 애플리케이션, 인프라 간에 안전하고 대기 시간이 짧으며 무한히 확장 가능한 연결이 가능합니다. 클라우드 연결성은 인터넷만큼 빠르고 직관적이면서도 위험이나 불확실성은 없습니다.
프로그래밍 가능성 — 모든 엔터프라이즈 디지털 환경에는 독점 인프라, 다양한 클라우드, 고유 규제 준수 요구, 그리고 기타 전용 툴링, 프로세스, 구성이 존재합니다. 클라우드 연결성의 아키텍처는 한계가 없는 상호 운용성과 사용자 지정 가능한 네트워킹을 제공하므로 일관된 사용자 경험 및 효율적인 관리가 가능하며 고유한 요구에 적응할 수 있습니다.
플랫폼 인텔리전스 — 조직에서는 디지털 환경에서 모든 것을 연결하고 보호하기 위해 다양한 서비스를 필요로 합니다. 하지만 모든 것을 통합하는 것은 부담스러운 일이며 모두 관리하려고 하면 비효율적이고 보안에 구멍이 생깁니다. 잘 설계된 클라우드 연결성에는 기본적으로 다양한 서비스가 구축되어 있으며 자동으로 인텔리전스 모델을 업데이트하기 위해 매우 높은 볼륨의 다양한 트래픽을 분석합니다.
단순성 — IT 및 보안 서비스가 너무 많으면 대시보드도 너무 많아집니다. 이로 인해 비효율적이 되고, 가시성이 낮아지며, 알림으로 인해 피곤해집니다. 단일 플랫폼으로 100% 통합하는 것이 해답은 아니지만, 클라우드 연결성은 단일 제어판에서 IT 환경의 훨씬 더 많은 부분을 관리하므로 무분별하게 확장되는 도구와 대시보드 과부하가 크게 줄어듭니다.

이러한 특징을 지닌 클라우드 연결성으로 더 많은 제어 능력을 잃지 않는 채로 디지털 환경에 새로운 서비스를 추가할 수 있습니다. 이미 보유하고 있는 서비스에 대한 제어 능력을 다시 확보하는 데도 도움이 됩니다.

Cloudflare의 클라우드 연결성

우리가 이러한 4가지 특성을 특히 중시하는 성향이 있음을 인정합니다. Cloudflare에서는 처음부터 통합, 프로그래밍 가능성, 플랫폼 인텔리전스, 단순성이라는 원칙을 기반으로 서비스를 구축했습니다. 현재 Cloudflare의 전체 포트폴리오는 충분히 포괄적이어서 고객이 수많은 보안 및 IT 요구를 해결할 때 이러한 이점을 누릴 수 있습니다.

이러한 접근법 덕분에 Cloudflare가 세계 최초 클라우드 연결성임이 되었음을 자랑스레 말씀드릴 수 있습니다.

우리가 주장하는 것을 직접 확인해 보세요. 다음은 Cloudflare의 지원으로 제어 능력 문제를 해결한 고객 사례입니다.

Conrad Electric: 전 세계에 걸쳐 분산된 인력의 액세스 보호

클라우드 연결성에서는 프로그래밍 가능성, 심층 네트워크 통합, 기본 제공 인텔리전스를 제공하므로 기업 리소스에 안전한 액세스를 보장하는 데 이상적입니다.

전자제품 소매업체인 Conrad Electronic에서는 “직원을 온라인 상태로 유지하는 것만으로도 다양한 관리 병목 현상이 발생했습니다”라고 이야기합니다. 이 회사에 근무하는 2,300명의 직원 중 절반 가까이가 원격으로 기업 애플리케이션에 액세스해야 하며 이러한 액세스를 활성화는 것은 쉽지 않았습니다. 이를 위해 각 사용자를 대상으로 VPN 클라이언트를 배포하고 구성해야 했으니까요.

Conrad Electronic에서는 이제 Cloudflare의 클라우드 연결성을 이용하여 수백 개의 기업 애플리케이션에 안전한 원격 액세스를 제공합니다. 관리 부담이 크게 줄어들었으며 웹 운영을 개선하는 데 이제 매달 훨씬 더 많은 시간을 투자할 수 있다고 담당자는 이야기합니다. 또한 보안 상태도 개선되었습니다. “한 번의 클릭으로 특정 개인을 제한하거나 중요한 영역을 보호할 수 있습니다. 1,000개의 VPN 프로필을 유지할 필요가 없으므로 보안이 개선되고 시간과 비용이 절약됩니다.”

Carrefour: 고객이 직접 사용하며 신뢰할 수 있는 애플리케이션 제공 및 관리

클라우드 연결성을 이용하면 위협 인텔리전스, 네트워크 통합, 통합 인터페이스로 보안 간극을 훌륭하게 메꿀 수 있으며 전 세계에 걸쳐 애플리케이션을 안전하게 제공할 수 있습니다.

다국적 소매 및 도매 기업인 Carrefour는 호황을 누리며 빠른 성장세를 구가하고 있는 전자 상거래 업체입니다. 그러나 사이버 공격이 늘어났을 때 단순히 보안 스택을 늘리는 것은 도움이 되지 않았습니다. Carrefour 보안 팀 관계자는 “다양한 도구를 바꿔가며 사용하다 보니 아키텍처 조정과 제어가 어려웠습니다… 또한, 여러 도구를 아우르는 통합 기능이 없어 보안 및 성능 문제를 조사하고 해결하는 것이 복잡했고 시간이 오래 걸렸습니다”라고 이야기합니다.

폭넓은 보안 기능 변경의 일환으로 Carrefour에서는 Cloudflare의 클라우드 연결성을 채택하여 웹 악용, zero-day 위협, 악의적 봇 공격을 차단했습니다. 이를 통해 각기 다른 벤더에서 제공하는 5개의 보안 도구를 대체할 수 있었습니다. 그 이후로 Carrefour에서는 사고 해결 시간이 75% 단축되었습니다.

Canva: 혁신적인 애플리케이션 구축

마지막으로 클라우드 연결성의 프로그래밍 가능성과 네트워크 통합은 거의 모든 상황에서 혁신적인 개발을 지원하는 데 도움이 됩니다.

글로벌 설계 대기업인 Canva가 그 좋은 예입니다. 전에 이 회사에서는 다양한 개발자 플랫폼을 이용하여 네트워크 에지에서 사용자 지정 코드를 실행했습니다. 하지만 이러한 서비스를 사용하려면 시간이 너무 오래 걸렸고, 혁신에 방해가 되는 한계에 부딪혀야 했습니다.

Cloudflare의 클라우드 연결성은 “우리 소프트웨어의 중요한 부분”이 되었습니다. Canva에서는 클라우드 연결성의 개발자 서비스를 사용하여 사용자 지정 코드를 작성하고 실행하며 SEO 및 시간 제한 콘텐츠 액세스를 위해 페이지 제공을 최적화합니다. 최근 Canva의 관계자는 우리에게 “당사는 Cloudflare 덕분에 플랫폼이 신속하고 안정적이며 안전하다는 확신을 갖고 제품의 성장과 신규 시장으로의 확장에 집중할 수 있습니다”라고 이야기했습니다.

또한 Canva의 경험은 안전한 액세스 및 애플리케이션 제공을 위해 Cloudflare 제품을 채택하는 것으로 이어졌습니다. 이는 클라우드 연결성을 100% 활용하여 운영하는 경우의 예시를 아주 잘 보여줍니다.

클라우드 연결성에 대해 자세히 알아보세요

고객 덕분에 우리는 혁신을 이룰 수 있으며 클라우드 연결성의 비전도 예외가 아닙니다. 모든 것을 더 쉽고, 빠르며, 안전하고, 연결된 상태로 만들기 위해 노력하고 있습니다. 클라우드 연결성 덕분에 복잡성이 줄어들고 보안이 개선되는 모습을 보게 되어 정말 기쁩니다.

여기에서 클라우드 연결성에 대해 자세히 알아볼 수 있습니다. 하지만 이는 시작일 뿐이라고 생각해 주시면 좋겠습니다. 질문이 있거나 제안할 것이 있으면 Cloudflare로 연락해 주시기 바랍니다. 안전하고 연결된 여정에서 고객을 계속해서 도울 방법을 찾기 위한 대화를 계속할 수 있을 것으로 기대합니다.

Mitigation guidance

Rapid7 customers

Qu’est-ce qui est inclus et qu’est-ce qui va suivre ?

Pourquoi maintenant ?

何が含まれ、次に何があるのでしょうか？

なぜ、今なのでしょうか？

包括什么？下一步是什么？

为什么现在要推出这项服务？

¿Qué se incluye y qué será lo siguiente?

¿Por qué ahora?

Was ist inbegriffen und wie geht es weiter?

Warum gerade jetzt?

Browsing the Internet and your privacy

How does ECH work?

The future of privacy

The principles behind DAP, an open standard for privacy preserving measurement

Computing on secret shared data

Rich data types

Input validation

Non-linear aggregation

Helping to build a world of multi-party computation

Daphne: Cloudflare’s implementation of a DAP Aggregation Server

Quick start

Overview of a TLS 1.3 handshake

Hello! Retry Request? (HRR)

The nitty-gritty of X25519+Kyber

Picking security level: 512 vs 768

Hybrid

Performance

When things break, and how to move forward

Split ClientHello

HelloRetryRequest to the rescue

Debugging and examples

Opting in and opting out

Testing whether your origin server is configured correctly

Scanning ahead to remove the extra roundtrip

Also speeding up non post-quantum origins

Wrapping up

How we stack up

Our tooling

What’s next

Why run a Retro Scan

Running a Retro Scan

Analyzing The Results

How to sign up

The value of a WAF

How fast is fast enough?

Signatures are not enough, but are here to stay

Getting to zero time to mitigation

Step 1: create the training set

Step 2: enhance the training set

Step 3: build a very fast classifier

Step 4: deploy on the network

Step 5: expose output as a simple interface

Success in the wild

The perfect feedback loop

Summary

What’s included and what is next?

Why now?

Pourquoi exécuter le service Retro Scan

Exécuter le service Retro Scan

Analyse des résultats

Comment s’inscrire ?

Gründe für den Einsatz eines Retro Scan

Einsatz des Retro Scan

Analyse der Ergebnisse

Sie möchten sich registrieren? So funktioniert’s

Por que executar um Retro Scan

Executar um Retro Scan

Analise dos resultados

Como faço para me cadastrar

Por qué ejecutar Retro Scan

Cómo ejecutar Retro Scan

Cómo analizar los resultados

Cómo registrarse

제어 능력을 상실하는 이유

클라우드 연결성에 오신 것을 환영합니다

Cloudflare의 클라우드 연결성

Conrad Electric: 전 세계에 걸쳐 분산된 인력의 액세스 보호

Carrefour: 고객이 직접 사용하며 신뢰할 수 있는 애플리케이션 제공 및 관리