在API.Cloudflare.com上关闭HTTP端口以执行仅HTTPS的连接

通过ClearText HTTP端口建立的连接可能会暴露敏感信息，因为数据未加密，可以被网络中介机构拦截

Connections made over cleartext HTTP ports risk exposing sensitive information because the data is transmitted unencrypted and can be intercepted by network intermediaries, such as ISPs, Wi-Fi hotspot providers, or malicious actors on the same network. It’s common for servers to either redirect or return a 403 (Forbidden) response to close the HTTP connection and enforce the use of HTTPS by clients. However, by the time this occurs, it may be too late, because sensitive information, such as an API token, may have already been transmitted in cleartext in the initial client request. This data is exposed before the server has a chance to redirect the client or reject the connection.

通过ClearText HTTP端口建立的连接可能会暴露敏感信息，因为数据是未加密的，并且可以被网络中介机构（例如ISP，Wi-Fi Hotspot提供商或恶意参与者）拦截。服务器通常会重定向或返回403（禁止）响应以关闭HTTP连接并强制客户使用HTTPS。但是，到发生这种情况时，可能为时已晚，因为敏感信息（例如API令牌）可能已经在初始客户端请求中已在clearText中传输。在服务器有机会重定向客户端或拒绝连接之前，该数据已公开。

A better approach is to refuse the underlying cleartext connection by closing the network ports used for plaintext HTTP, and that’s exactly what we’re going to do for our customers.

一种更好的方法是通过关闭针对明文HTTP的网络端口来拒绝基础的ClearText连接，这正是我们要为客户做的。

Today we’re announcing that we’re closing all of the HTTP ports on api.cloudflare.com. We’re also making changes so that api.cloudflare.com can change IP addresses dynamically, in line with on-going efforts to decouple names from IP addresses, and reliably managing addresses in our authoritative DNS. This will enhance the agility and flexibility of our API endpoint management. Customers relying on static IP addresses for our API endpoints will be notified in advance to prevent any potential availability issues.

今天，我们宣布我们正在关闭API.Cloudflare.com上的所有HTTP端口。我们还会进行更改，以便api.cloudflare.com可以与持续的努力从IP地址解除名称以及可靠地管理我们权威DNS中的地址的努力，并可以动态地更改IP地址。这将增强我们API端点管理的敏捷性和灵活性。依靠我们API端点的静态IP地址的客户将得到事先通知，以防止任何潜在的可用性问题。

In addition to taking this first step to secure Cloudflare API traffic, we’ll release the ability for customers to opt-in to safely disabling all HTTP port traffic for their websites on Cloudflare. We expect to make this free security feature available in the last quarter of 2025.

除了采取第一步以保护CloudFlare API流量外，我们还将释放客户选择加入以安全地禁用Cloudflare网站的所有HTTP端口流量的能力。我们希望这项免费的安全功能在2025年的最后一个季度提供。

We have consistently advocated for strong encryption standards to safeguard users’ data and privacy online. As part of our ongoing commitment to enhancing Internet security, this blog post details our efforts to enforce HTTPS-only connections across our global network.

我们一直在倡导强大的加密标准，以在线保护用户的数据和隐私。作为我们对增强互联网安全性的持续承诺的一部分，此博客详细介绍了我们在全球网络中执行仅HTTPS连接的努力。

Understanding the problem

了解问题

We already provide an “Always Use HTTPS” setting that can be used to redirect all visitor traffic on our customers’ domains (and subdomains) from HTTP (plaintext) to HTTPS (encrypted). For instance, when a user clicks on an HTTP version of the URL on the site (http://www.example.com), we issue an HTTP 3XX redirection status code to immediately redirect the request to the corresponding HTTPS version (https://www.example.com) of the page. While this works well for most scenarios, there’s a subtle but important risk factor: What happens if the initial plaintext HTTP request (before the redirection) contains sensitive user information?

我们已经提供了一个“始终使用HTTPS”设置，可用于将客户域（和子域）上的所有访问者流量重定向从HTTP（Plaintext）到HTTPS（加密）。例如，当用户单击网站上的http版本（http://www.example.com）时，我们会发出http 3xx重定向状态代码，以立即将请求重定向到相应的https版本（https://www.example.com）。尽管这在大多数情况下都可以很好地工作，但仍有一个微妙但重要的风险因素：如果初始明文HTTP请求（重定向之前）包含敏感用户信息会发生什么？

Initial plaintext HTTP request is exposed to the network before the server can redirect to the secure HTTPS connection.

在服务器可以重定向到安全HTTPS连接之前，初始明文HTTP请求已暴露于网络。

Third parties or intermediaries on shared networks could intercept sensitive data from the first plaintext HTTP request, or even carry out a Monster-in-the-Middle (MITM) attack by impersonating the web server.

共享网络上的第三方或中介可以从第一个明文HTTP请求中拦截敏感数据，甚至可以通过模仿Web服务器来攻击中间的怪物（MITM）攻击。

One may ask if HTTP Strict Transport Security (HSTS) would partially alleviate this concern by ensuring that, after the first request, visitors can only access the website over HTTPS without needing a redirect. While this does reduce the window of opportunity for an adversary, the first request still remains exposed. Additionally, HSTS is not applicable by default for most non-user-facing use cases, such as API traffic from stateless clients. Many API clients don’t retain browser-like state or remember HSTS headers they've encountered. It is quite common practice for API calls to be redirected from HTTP to HTTPS, and hence have their initial request exposed to the network.

可以询问HTTP严格的运输安全性（HSTS）是否会通过确保第一个请求之后，访问者只能通过HTTP访问网站而无需重定向，从而部分缓解这种担忧。尽管这确实减少了对手的机会之窗，但第一个请求仍然暴露。此外，默认情况下，HST不适用于大多数非用户用例，例如来自无状态客户端的API流量。许多API客户不保留浏览器状状态，也不记得他们遇到的HSTS标题。 API调用从HTTP重定向到HTTP是很普遍的做法，因此将其初始请求暴露于网络。

Therefore, in line with our culture of dogfooding, we evaluated the accessibility of the Cloudflare API (api.cloudflare.com) over HTTP ports (80, and others). In that regard, imagine a client making an initial request to our API endpoint that includes their secret API key. While we outright reject all plaintext connections with a 403 Forbidden response instead of redirecting for API traffic — clearly indicating that “Cloudflare API is only accessible over TLS” — this rejection still happens at the application layer. By that point, the API key may have already been exposed over the network before we can even reject the request. We do have a notification mechanism in place to alert customers and rotate their API keys accordingly, but a stronger approach would be to eliminate the exposure entirely. We have an opportunity to improve!

因此，根据我们的狗食文化，我们评估了HTTP端口（80等）上Cloudflare API（API.Cloudflare.com）的可访问性。在这方面，请想象一个客户向我们的API端点提出初步请求，其中包括其秘密API密钥。虽然我们完全拒绝使用403禁止响应而不是重定向API流量的所有明文连接 - 显然表明“ Cloudflare API仅在TLS上可以访问”，但此拒绝仍然发生在应用程序层。到那时，在我们甚至可以拒绝请求之前，API密钥可能已经通过网络公开。我们确实有一个通知机制来提醒客户并相应地旋转其API键，但是更强大的方法是完全消除暴露量。我们有机会改进！

A better approach to API security

更好的API安全方法

Any API key or token exposed in plaintext on the public Internet should be considered compromised. We can either address exposure after it occurs or prevent it entirely. The reactive approach involves continuously tracking and revoking compromised credentials, requiring active management to rotate each one. For example, when a plaintext HTTP request is made to our API endpoints, we detect exposed tokens by scanning for 'Authorization' header values.

在公共互联网上以明文暴露的任何API密钥或令牌都应被视为妥协。我们可以在发生后解决暴露或完全防止暴露。反应性方法涉及不断跟踪和撤销受损的凭据，要求主动管理旋转每个凭据。例如，当向我们的API端点提出明文HTTP请求时，我们通过扫描“授权”标头值来检测暴露的令牌。

In contrast, a preventive approach is stronger and more effective, stopping exposure before it happens. Instead of relying on the API service application to react after receiving potentially sensitive cleartext data, we can preemptively refuse the underlying connection at the transport layer

相反，预防方法更强大，更有效，在发生之前停止暴露。我们可以先拒绝运输层的基础连接，而不是依靠API服务应用程序来进行反应