日前寫的文章里了討論了數據傳輸的安全性的問題，最后一部分提到了通過HTTPS解決數據傳輸安全性的方案。那么一個新問題又來了，實施全站HTTPS的過程中，我們可能會遇到哪些技術問題?所以我今天和大家一起來算一下這個賬，將技術成本理清楚。

[[205578]]

準備工作

1. 購買證書 ，網站使用HTTPS需要申請安全證書，目前來說還是比較繁瑣的，而且對小公司來說是有一些成本在。另外，一定要選正規的機構，否則你的網站以后使用主流瀏覽器，如chrome訪問，會被提示大大的警告，告訴用戶該證書有問題。
2. 頁面里所有資源都要改成走https ,包括：圖片、js、form表單等等，否則瀏覽器就會報警。
3. 確保用到的CDN節點都支持HTTPS ，如果是自建IDC, 必須要保證全國甚至世界范圍的 idc 和 cdn 節點，都得覆蓋到。

CDN 使用 https 常見的方案有：

1. 網站主提供私鑰給 cdn，回源使用 http。
2. cdn 使用公共域名，公共的證書，這樣資源的域名就不能自定義了。回源使用 http。
3. 僅提供動態加速，cdn 進行 tcp 代理，不緩存內容。
4. 所有的開發、測試環境都要做https的升級 ，確保各級環境保持同一套網絡協議。

性能方面的挑戰

做好以上的技術準備后，我們還必須意識到實施HTTPS后帶來的性能問題：

1.網絡耗時增加，簡單來說需要多幾次握手，網絡耗時變長，用戶從http跳轉到https還要一點時間。

對于這一塊的優化，有Session ticket或者Session Cache等優化方案，不過也是各有優缺點。

2.計算耗時增加，需要更好機器性能，https要多做一次RSA校驗。

對于這一塊的優化，主要的方式是采用最新的openssl協議，使用硬件加速，優先使用ECC密鑰等等。

安全方面的挑戰

關于這一塊，常見的安全隱患包含：降級攻擊和重新協商攻擊。

對于前者，攻擊者偽造或者修改"client hello "消息，使得客戶端和服務器之間使用比較弱的加密套件或者協議完成通信。對于重新協商攻擊，是攻擊者利用協商后安全算法偏弱，試圖竊取傳輸內容，并且可以 不斷發起完全握手請求，觸發服務端進行高強度計算并引發服務拒絕。

當然，這一塊，在基礎廠商或者云產商的努力下，對于我們一般的業務用戶，幾乎不用關心協議層上面安全的問題。我在這里提出的目的，還是想說明一點，安全問題一直都不能放松。

最后一點總結

切換成HTTPS是必然趨勢，相信會有越來越多的站點加入進來，而且完成后，它能給我們帶來的收益是巨大的。對于我們技術團隊而言，在實行之前，一定要考慮清楚它背后的技術成本，并做好對應的技術儲備，做好HTTP切換為HTTPS的上線流程，確保萬無一失。