版權聲明：本文由賀嘉 原創文章，轉載請注明出處:
文章原文鏈接：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/