一篇文章帶你看懂Cloudflare信息泄露事件

版權聲明：本文由賀嘉   原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/753847001488039974

來源：騰雲閣 https://www.qcloud.com/community

 

1.問題描述

近期根據Hacker News的報道，以及國際CDN廠商cloudflare的公告，咱們注意到了一塊兒敏感信息、API 密鑰被Cloudflare泄露給了隨機的 requesters請求，同時相關敏感數據也被搜索引擎給收錄的問題。

這一問題持續了 2016-09-22至 2017-02-18近半年時間，最爲嚴重的階段是2-13至2-18 每 3,300,000 HTTP 請求就有可能泄露一分內存數據(近總請求量的0.00003%),預計是100k-200k 頁面涉嫌數據泄露。包括uber在內的一系列知名互聯網企業可能受到影響。

如下是可能受到這一問題影響的網站清單：
https://github.com/pirate/sites-using-cloudflare/blob/master/README.md

2.信息泄露問題緣由

Cloudflare CDN服務 會對 HTML 標籤進行從新解析，好比將 Google Analytics的標籤插入到HTML中, 安全地重寫 http:// 連接成爲 https://， 模糊email郵箱地址等等。可是因爲 NGINX 模塊中的HTML 解析功能存在指針問題，致使在用戶之間共享的反向代理存在信息泄露問題，最先是由 Google’s Project Zero 的研究員 Tavis Ormandy發現。

以前Cloudflare的HTML解析一直使用標準的 Ragel 有限狀態機編譯器（ www.colm.net/open-source/ragel/），可是前段時間Cloudflare爲了提高代碼效率對解析器進行了升級，將其升級爲 cf-html並測試了其對HTML5的解析是沒有問題的。可是問題出在了開發團隊錯誤的使用了 Ragel的編碼規範，Ragel的代碼會被自動編譯爲C語言的代碼，而C語言容許更加靈活的使用指針。
/ generated code /
if ( ++p == pe )
goto _test_eof;
以上Ragel自動生成的代碼會致使指針越界，也就是常見的內存泄露問題。可是以前Ragel實現的HTML 解析模塊單獨使用並不會觸發信息泄露問題，而是僅當基於Ragel 解析器與Cloudflare 升級 後的cf-html解析器一塊兒工做的時候纔會觸發這一問題。

3.解決方案

3.1遷移至騰訊雲CDN

騰訊雲CDN（領取免費體驗）
提供基於角色的CDN權限控制，而且支持以API接口方式調用。同時新用戶開通CDN即連續6個月，每個月贈送50G流量包。

* 財務管理員
* 超級管理員
* 雲資源管理員

超級管理員擁有建立者的全部權限，能夠進行其餘子用戶的分配；而云資源管理員擁有對全部雲資源的管理權限，但不能夠建立其餘子用戶。部分功能僅可以供預設管理員使用，具體以下：

* 使用雲API DescribeCdnHosts 獲取帳戶下全部域名詳細信息；
* 使用雲API UpdateCdnProject 或在 CDN控制檯 進行域名所屬項目的切換；

項目管理員除了預設管理員外，還能夠按照項目維度劃分權限，即項目管理員。項目管理員能夠管理指定項目中全部的雲資源。
項目管理員能夠經過自定義策略 中服務類型爲項目管理的策略進行指派，該策略擁有兩個功能：

* 管理 CDN 業務項目內雲資源
* 管理其餘業務項目內雲資源

3.2考慮在你的應用中實現Keyless（無密鑰加載）架構

對證書稍微熟悉的朋友都知道，SSL 密鑰和證書都是成對使用的，一個證書必定惟一對應一個私鑰。整個 HTTPS 最重要的一個數據就是 SSL 的私鑰了，若是私鑰泄露，整個握手過程就能夠被劫持，簽名能夠被僞造，對稱密鑰也能夠被破解。整個 HTTPS 就毫無安全可言。
傳統的私鑰使用方案和風險傳統的私鑰方案就是將私鑰和應用程序綁定在一塊兒。好比你們熟知的 nginx, apache，若是想使用 HTTPS，必須在部署 nginx 的接入機器上部署相關的證書和私鑰。

這種方案會有以下安全上的問題：私鑰部署在雲端或者 CDN，若是泄露了怎麼辦？
無祕鑰方式雖然騰訊雲的內網很是安全，可是出於對客戶的安全負責，完全打消用戶對私鑰泄露的顧 慮，確保用戶對私鑰的絕對控制，騰訊雲提供一種無私鑰的加載方案。這個方案核心是「不須要把私鑰存儲在騰訊雲，容許用戶使用本身的服務器保管私鑰，完成 HTTPS 的接入」。 騰訊雲徹底接觸不到私鑰，客戶甚至能夠把私鑰保存在本身家裏的服務器上。
它的接入過程以下：

1. 用戶發起 HTTPS 握手請求。
2. 在涉及到私鑰計算的時候，騰訊雲 CLB 會將這個私鑰計算請求經過加密的自定義協議，轉發給用戶本身的 keyless 服務器上。
3. keyless 服務調用用戶的私鑰完成計算。
4. keyless 服務將計算結果返回給騰訊雲 CLB。
5. CLB 繼續進行 HTTPS 請求的處理。

整個過程，騰訊雲接觸不到 HTTPS 私鑰，須要注意一點的，keyless server 是騰訊雲提供一個服務端程序，代碼開源，用戶自主部署，服務端行爲用戶掌握得一清二楚。

總結來講Keyless（無密鑰加載）架構能夠更好的實現用戶的私鑰安全性，可是會對於開發者而言增長一次網絡交互，通常來講100-200ms的網絡延時，除非是對於安全性有很是高要求的應用，纔會考慮這一方式，是用騰訊雲的這一架構須要和咱們的技術人員單獨溝通以明確需求。

4.參考資料list

https://www.qcloud.com/document/product/228/6689

https://www.qcloud.com/community/article/207618001486449512

List of Sites possibly affected by Cloudflare's
https://github.com/pirate/sites-using-cloudflare/blob/master/README.md

report of bugs
https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

Incident report on memory leak caused by Cloudflare parser bug
https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/