HTTPS 部署簡要指南

許多Web開發者都知道SSL，但常見的狀況是SSL沒有完整地部署或者沒有部署在它應該部署的地方。這篇關於什麼時候及如何部署SSL的簡要指南，將幫助你避免大多數常見錯誤。

要點

• 若是你有任何機密信息，或者你要進行用戶登錄，哪怕只是讓管理員登錄，你就應該部署HTTPS。風險並不是只存在於理論上。
• 決不要部分部署HTTPS：請將它用於全部內容，不然你將面臨許多風險，好比session ID被攔截，其危害不亞於密碼被攔截。
• 若是你部署了HTTPS，請將任何普通的HTTP請求都重定向至HTTPS的URL，以強制全部的請求都經過HTTPS來處理。
• 啓用HTTP嚴格傳輸安全協議（HSTS）來進一步減小遭受攻擊的可能。
• 在你的cookies，好比session cookie上設置安全標記，確保它們不會經由普通的HTTP請求而泄露。

什麼是HTTPS？

HTTPS是將HTTP置於SSL/TLS之上，其效果是加密HTTP流量(traffic)，包括請求的URL、結果頁面、cookies、媒體資源和其餘經過HTTP傳輸的內容。企圖干擾HTTPS鏈接的人既沒法監聽流量，也沒法更改其內容。除了加密，遠程服務器的身份也要進行驗證：畢竟，若是你都不知道另外一端是誰，加密鏈接也就沒什麼用處了。這些措施將使攔截流量變得極其困難。雖然攻擊者仍有可能知道用戶正在訪問哪一個網站，但他所能知道的也就僅限於此了。

什麼時候及爲何要部署HTTPS

只要你的網站有任何非公開信息，你就應當部署HTTPS，包括那些須要登錄的網站——畢竟，若是信息是公開的，根本就無須要求登錄。那些只有管理員才能登錄的網站，好比典型的Wordpress站點，也須要HTTPS。

部署HTTPS是必須的，由於若是沒有它，即便有人在被動監聽，也就是監聽而不操控網絡流量，他也能順着HTTP傳輸讀取到密碼或認證令牌等機密信息。

這種攻擊並不是只存在於理論上。我本身（通過許可）就幹過幾回——在公共熱點(public hotspots)上這太容易作到了。公共熱點一般沒有使用任何WiFi加密，所以監聽全部流量只不過是小菜一碟。這種狀況在酒吧、賓館、火車和其餘公共場所很是廣泛。換句話說，若是你的用戶某些時候從公共熱點訪問你的網站，而你又沒有使用HTTPS，那麼任何在公共熱點附近的人均可以監聽用戶全部的流量。這並非監聽可能發生的惟一狀況，但它確實很容易作到。

若是我只是在登錄頁面使用HTTPS呢？

別這麼幹。只在登錄頁面使用HTTPS當然能夠防止用戶的密碼被竊取，但這只是問題的一部分。

首先，你的網站上使用HTTPS的部分越少，進行主動攔截就越容易：你的登錄連接可能指向一個HTTPS URL，但若是我在用戶點擊以前就改變了連接，HTTPS就無法幫到你了。部分使用HTTPS也將面臨被動攔截的風險。

驗證用戶名和密碼只是web上用戶身份驗證的一部分：咱們還須要記住某個特定用戶已通過驗證和用於驗證的帳戶。最多見的辦法是使用session cookies，這一般意味着瀏覽器會將一個長的隨機字符串，也就是session ID，存儲在一個cookie中，例如在PHP中可使用PHPSESSID來實現。服務器端的數據庫知道那個隨機字符串對應某個特定的session，而那個session又對應着某個特定的已驗證用戶。若是我用某種方式獲得了你的session ID，那麼當你登錄以後，我就得到了你全部的權限，這和我知道你的密碼沒什麼兩樣。

考慮到這一風險，session ID都很是長且隨機，而且它的生命期是有限的，這就意味着我無法靠猜想來獲知它，所以session ID是足夠安全的。可是，因爲cookie的運做方式，瀏覽器每次向網站發請求時都會包含cookie信息。因此，即便已經登錄好久了，我請求的每一個網頁，哪怕一般狀況下是公開的網頁，也會致使個人session cookie被瀏覽器發送出去。若是這時有人在監聽，他們依然能夠篡改個人帳戶。

若是你僅僅把網站中涉及管理員的部分置於SSL的保護之下，一樣的狀況也可能發生：當你登錄並隨後訪問非SSL的公開內容時，瀏覽器也會發送session cookie。

簡而言之：因爲容許訪問用戶帳戶的session cookie在每一次請求中都會被髮送，僅僅保障登錄頁面的安全是絕對不夠的。

我該如何正確地啓用HTTPS？

強制使用HTTPS

一些網站購買了SSL證書並將其配置到Web服務器上，覺得這就算完事兒了。但這只是代表你啓用了HTTPS選項，而用戶極可能不會注意到。爲確保每一個用戶都從HTTPS中受益，你應該將全部傳入的HTTP請求重定向至HTTPS。這意味着任何一個訪問你的網站的用戶都將自動切換到HTTPS，從那之後他們的信息傳輸就安全了。

但上述作法仍是留下了一個空子：當用戶第一次向你的網站發送請求時，他們使用的是普通HTTP，而那時他們可能就已經在傳輸機密信息了。上述作法還留下了一個「中間人攻擊」漏洞(man-in-the-middle hole)。

嚴格傳輸安全協議

爲進一步增強控制，請啓用HTTP嚴格傳輸安全協議。這是一種可由服務器發送的特殊的頭信息(header)，它的含義是：在設定的時限內，你不能經過普通HTTP訪問網站，也不能在證書不可靠時經過HTTPS訪問網站。二級域名也能夠選擇包含HSTS。

HSTS是一種簡單的服務器頭信息，且容易配置。可是要注意在時限結束以前沒法撤銷設定，所以不要把時限設置得太長。你應該同時使用HSTS和HTTPS重定向，而不是用前者取代後者。

安全的cookies

Cookies，包括session cookie，有一個可選的安全標記。它大體的含義是：「不要用普通HTTP鏈接發送這個cookie」 啓用這個安全標記，你的cookie就不會被瀏覽器的初始HTTP請求發送出去，直到鏈接切換爲HTTPS且再也不會被監聽爲止。

我能夠只爲已驗證用戶部署SSL嗎？

不能夠。一旦你遵循了上述指南，當用戶發起普通HTTP鏈接時，你無法知道他們是否通過了驗證。關鍵在於：除非用戶已經連上了SSL，不然他們不該該傳輸任何機密信息，好比session cookie。

雖然我還能想出其餘的辦法來解決這些安全問題，但它們可能會在某個環節上失效。現在SSL的成本已至關低，採用其餘方案並不划算。

進一步閱讀

讀過這篇博客，你可能還想看看這幾篇文章:

• An appeal for security for the ordinary developer
• But where is the decryption key?
• Proof of concept: arbitrary remote code execution through pickle-backed cookie-based sessions

想進一步瞭解怎樣正確設置加密和其餘SSL選項，你能夠看看Qualys Labs的:

• SSL服務器測試
• 最佳實踐文檔
• GitHub改進其SSL配置時的考量
• Mozilla的TLS文檔

Mozilla的TLS文檔可能會嚇到新手。尚處於草案階段的Applied Crypto Hardening也不錯，它提供了直接可用的配置模板並詳細解釋了模板中所用選項的合理性。

---

原文：A basic guide to when and how to deploy HTTPS
轉載自：伯樂在線 - LieGroup