訂閱以接收新文章的通知:

自動化(安全)傳輸:減輕原點連線安全性的負擔

2022-10-03

閱讀時間:7 分鐘
本貼文還提供以下語言版本:English简体中文

2014 年,Cloudflare 開始透過引入 Universal SSL 來加密網際網路。它使獲得 SSL/TLS 憑證變得既免費又容易,而在當時,這一操作既不免費也不容易。一夜之間,數百萬個網站在使用者的瀏覽器和 Cloudflare 之間建立了安全連線。

Automatic (and secure) transmission: taking the pain out of origin connection security

但是,從 Cloudflare 到客戶原始伺服器的連線加密更為複雜。由於 Cloudflare 和所有瀏覽器都支援 SSL/TLS,因此瀏覽器和 Cloudflare 之間的連線可以得到即時保護。但在 2014 年時,使用 SSL/TLS 憑證設定原始伺服器既複雜又昂貴,有時甚至無法實現。

因此,我們依靠使用者為其原始伺服器設定最佳安全性層級。後來我們新增了一項服務,該服務偵測並建議 Cloudflare 與原始伺服器之間連線的最高安全性層級。我們還為不想在其他地方獲取憑證的客戶推出了免費的原始伺服器憑證

今天,我們將做得更好。Cloudflare 將快速找到與客戶的原始伺服器最安全的連線,並自動使用它。在大規模的情況下正確執行此操作,同時又不破壞客戶的服務非常複雜。這篇部落格文章解釋了我們如何為那些不想花時間手動進行 SSL/TLS 設定的客戶自動實現最高層級的安全性。

為什麼自動設定源站 SSL 如此困難

當我們宣布推出 Universal SSL 時,我們知道 Cloudflare 和源站之間連線的後端安全性是一個與此不同且更難解決的問題。

為了設定最嚴格的安全性,客戶必須從第三方獲取憑證並將其上傳到其源站。然後他們必須向 Cloudflare 表明我們應該使用此憑證來驗證伺服器的身分,同時還要指示其源站的連線安全功能。這可能是一個昂貴而冗長的過程。為了幫助緩解這一高昂的設定成本,Cloudflare 在 2015 年推出了測試版 Origin CA 服務,該服務為客戶源站伺服器提供免費的有限功能憑證。我們還提供了有關如何正確設定和上傳憑證的指導,以便可以快速輕鬆地在 Cloudflare 和客戶源站之間建立安全連線。

然而我們發現,雖然這項服務對客戶很有用,但它仍然需要大量的設定。我們沒有看到我們對 Universal SSL 所做的變更,因為客戶仍然必須與他們的源站作鬥爭,以便上傳憑證並進行測試,以確保他們已正確設定所有內容。而且,當您將負載平衡器之類的東西混合在一起或將伺服器對應到不同的子網域時,處理伺服器端 SSL/TLS 會變得更加複雜。

大約在該公告發布的同時,Let's Encrypt 和其他服務開始作為公共 CA 免費提供憑證,使 TLS 更容易並為廣泛採用鋪平道路。Let's Encrypt 和 Cloudflare 得出了相同的結論:透過免費提供憑證、為使用者簡化伺服器設定並努力簡化憑證更新,他們可以對 Web 的整體安全性產生切實的影響。

隨著免費且易於設定的憑證的發布,人們越發關注面向源站的安全性。Cloudflare 客戶開始要求提供更多文件,以設定面向源站的憑證和高效能且直觀的 SSL/TLS 通訊。作為回應,我們在 2016 年推出了憑證授權單位的 GA,以提供便宜且簡單的原始憑證以及有關為任何網站最佳設定後端安全性的指南

客戶需求和關注度的增加有助於為 Cloudflare 上專注於後端安全性的其他功能鋪平道路。例如,經過驗證的源站拉取確保只有來自 Cloudflare 的 HTTPS 請求會收到來自您的源站的回應,同時從會阻止來自 Cloudflare 外部請求的源站回應。另一種選擇是,Cloudflare Tunnel 可以設定為在原始伺服器上執行,主動建立到最近的 Cloudflare 資料中心的安全和私有通道。這種設定讓客戶能夠完全鎖定他們的原始伺服器,只接收通過我們的網路路由的請求。對於無法使用此方法鎖定其源站的客戶,我們仍然鼓勵在設定 Cloudflare 應如何連線到原始伺服器時採用盡可能強的安全性。

Cloudflare 目前提供了五個 SSL/TLS 可設定性選項,以供與源站通訊時使用:

  • 關閉模式下,如您所料,從瀏覽器到 Cloudflare 以及從 Cloudflare 到源站的流量未加密,將使用純文字 HTTP。

  • 靈活模式下,從瀏覽器到 Cloudflare 的流量可以透過 HTTPS 加密,但從 Cloudflare 到網站原始伺服器的流量則不能。儘管我們建議盡可能升級此源站設定,但這是不支援 TLS 的源站的常見選擇。可以在此處找到升級指南。

  • 完整模式下,Cloudflare 會追蹤瀏覽器請求發生的任何事情,並使用相同的選項連線到源站。例如,如果瀏覽器使用 HTTP 連線到 Cloudflare,我們將透過 HTTP 與源站建立連線。如果瀏覽器使用 HTTPS,我們將使用 HTTPS 與源站通訊;但是我們不會驗證源站上的憑證來證明伺服器的身分和可信度。

  • 在**完整(嚴格)**模式下,Cloudflare 之間的流量遵循與「完整」模式相同的模式,但「完整(嚴格)」模式增加了對原始伺服器憑證的驗證。源站憑證可以由 Let's Encrypt 等公共 CA 或 Cloudflare Origin CA 頒發。

  • 嚴格模式下,從瀏覽器到 Cloudflare 的 HTTP 或 HTTPS 流量將始終透過 HTTPS 連線到源站,並驗證原始伺服器的憑證。

我們發現,在很多情況下,當客戶最初註冊 Cloudflare 時,他們使用的源站無法支援最進階的加密版本,導致使用未加密的 HTTP 進行面向源站的通訊。這些預設值會隨著時間的推移而持續存在,即使源站已變得更強大。我們認為是時候重新評估預設 SSL/TLS 層級的整個概念了。

因此,我們將透過代表我們的客戶自動管理面向源站的安全性來減少設定負擔。Cloudflare 將為我們如何與源站通訊提供零設定選項:我們將簡單地查看源站並使用可用的最安全選項與其通訊。

重新評估預設 SSL/TLS 模式僅僅是開始。我們不僅會自動將網站升級到最佳安全性設定,還會向所有方案層級開放所有 SSL/TLS 模式。過去,「嚴格」模式僅保留給 Enterprise 客戶。這是因為這一模式發佈於 2014 年,當時很少有人能透過 SSL/TLS 進行通訊,而且我們非常擔憂客戶破壞他們的設定。但現在是 2022 年,我們認為任何想要使用「嚴格」模式的人都應該可以使用它。因此,隨著自動升級的推出,我們將向所有人開放。

自動升級將如何運作**?**

要升級網站面向源站的安全性,我們首先需要確定源站可以使用的最高安全性層級。為了做出這個決定,我們將使用一年前發佈的 SSL/TLS Recommender 工具。

該推薦器執行從 Cloudflare 到客戶源站的一系列請求,以確定後端通訊是否可以升級為超出當前設定。該推薦器透過以下方式實現此目的:

  • 爬行網站以收集網站不同頁面上的連結。對於具有大量連結的網站,推薦器只會檢查一部分。同樣,對於爬行發現的連結數量不足的網站,我們會使用最近訪客對該區域的請求的連結樣本來擴充我們的結果。所有這些都是為了獲得一個具有代表性的樣本,瞭解請求的去向,以便瞭解源站是如何提供回應的。

  • 該網路爬蟲利用使用者代理程式 Cloudflare-SSLDetector,並已新增到 Cloudflare 的已知「善意機器人」清單中。

  • 接下來,推薦器透過 HTTP 和 HTTPS 下載每個連結的內容。推薦器在掃描原始伺服器時僅發出等冪 GET 請求,以避免修改伺服器資源狀態。

  • 在此之後,推薦器執行內容相似性演算法,以確定透過 HTTP 和 HTTPS 收集的內容是否匹配。

  • 如果透過 HTTP 下載的內容與透過 HTTPS 下載的內容匹配,那麼它就知道,我們可以升級網站的安全性而不會產生負面影響。

  • 如果網站已配置為「完整」模式,我們將執行憑證驗證(無需額外爬行網站),以確定是否可以將其更新為「完整(嚴格)」模式或更高版本。

如果可以確定客戶的源站能夠升級而不中斷,我們將自動升級面向源站的安全性。

但這並不是全部。我們不僅消除了 Cloudflare 上服務的設定負擔,而且還透過從每個區域的 SSL/TLS 設定移動到每個源站的 SSL/TLS 設定,來提供更精確的安全性設定

後端 SSL/TLS 服務的當前實施與整個網站相關,這對於具有單一來源的網站非常有效。但是,對於那些設定更為複雜的使用者,這可能意味著面向源站的安全性由為該服務的部分流量提供服務的最低能力源站定義。例如,如果一個網站使用 img.example.com 和 api.example.com,並且這些子網域由具有不同安全性功能的不同源站提供服務,我們不希望將這兩個子網域的 SSL/TLS 能力都限制在最不安全的源站。透過使用我們的新服務,我們將能夠更精確地設定每個源站的安全性,以便最大限度地提高每個源站的安全狀態。

這樣做的目標是最大限度地提高 Cloudflare 上所有內容面向源站的安全性。但是,如果我們嘗試掃描的任何源站封鎖了 SSL Recommender、具有非功能性源站或選擇退出此服務,我們將無法完成掃描,也無法升級安全性。有關如何選擇退出的詳細資訊將很快透過電子郵件公告提供。

選擇退出

人們可能出於各種原因而想要為其網站配置低於最佳的安全性設定。客戶提供的一個常見原因是擔心擁有更高的安全性設定會對其網站的效能產生負面影響。其他人則可能出於測試目的或想要對某些行為進行偵錯,而想要設定次優安全性設定。無論出於何種原因,我們都將提供繼續設定您想要的 SSL/TLS 模式所需的工具,即使這與我們認為的最佳模式不同。

這將在什麼時候進行?

我們將在今年年底之前開始推出此變更。如果您閱讀本文並希望確保您擁有最高層級的後端安全性,我們建議您使用完整(嚴格)嚴格模式。如果您更願意等待我們為您自動升級您的源站安全性,請密切關注您的收件匣,瞭解我們將於何時開始為您的群組推出此變更。

Cloudflare 認為網際網路必須是安全且私密的。如果您想幫助我們實現這一目標,我們的整個工程組織正在招聘。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
Birthday Week產品新聞ResearchCDNUniversal SSL安全性

在 X 上進行關注

Alex Krivit|@ackriv
Suleman Ahmad|@sulemanahmadd
Cloudflare|@cloudflare

相關貼文

2024年10月24日 下午1:00

Durable Objects aren't just durable, they're fast: a 10x speedup for Cloudflare Queues

Learn how we built Cloudflare Queues using our own Developer Platform and how it evolved to a geographically-distributed, horizontally-scalable architecture built on Durable Objects. Our new architecture supports over 10x more throughput and over 3x lower latency compared to the previous version....

2024年10月08日 下午1:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

2024年10月06日 下午11:00

Enhance your website's security with Cloudflare’s free security.txt generator

Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access. Strengthen your website's security today!...

2024年10月02日 下午1:00

How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack

Over the past couple of weeks, Cloudflare's DDoS protection systems have automatically and successfully mitigated multiple hyper-volumetric L3/4 DDoS attacks exceeding 3 billion packets per second (Bpps). Our systems also automatically mitigated multiple attacks exceeding 3 terabits per second (Tbps), with the largest ones exceeding 3.65 Tbps. The scale of these attacks is unprecedented....