Stack Overflow上部署HTTPS：長路盡頭（五）

Python部落(python.freelycode.com)組織翻譯，禁止轉載，歡迎轉發。

HSTS預載入

HSTS代表「HTTP嚴格的傳輸安全」。 OWASP在這裡有一個很好的點可寫。這是一個相當簡單的概念：

• 當您訪問https：//頁面時，我們向您發送如下標題：Strict-Transport-Security：max-age = 31536000

• 在這段時間內（以秒為單位），您的瀏覽器只能通過https：//訪問該域

即使您點擊http：//的鏈接，您的瀏覽器也會直接轉到https：//。它永遠不會通過設置的http：//重定向，它適用於SSL/TLS。這樣可以阻止人們攔截http：//（insecure）請求並劫持它。例如，它可能會將您重定向到https：// stack <LooksLikeAnobutIsReallyCrazyUnicode> verflow.com，他們甚至可能擁有適當的SSL/TLS證書。永遠不要去那裡，你更安全。

但是，這需要一次點擊網站首先獲得標題，對吧？是的，沒錯。所以有HSTS預載入，這是所有主要瀏覽器附帶的域名列表，以及如何預載入。實際上，他們得到的指令僅在第一次訪問之前訪問https：//。一旦這是到位的，就不會有任何http：//通訊。

好的很酷！那麼在這個列表上需要怎麼辦？以下是要求：

1. 提供有效的證書。

2. 如果您正在偵聽埠80，則從同一主機上的HTTP重定向到HTTPS。

3. 通過HTTPS服務所有子域。

1. 特別地，如果該子域的DNS記錄存在，則必須支持www子域的HTTPS。

4. 在基本域上為HTTPS請求提供HSTS標頭：

1. max-age必須至少為18周（10886400秒）。

2. 必須指定includeSubDomains指令。

3. 必須指定預載入指令。

4. 如果您從HTTPS網站提供其他重定向，則該重定向仍必須具有HSTS標頭（而不是重定向到的頁面）。

聽起來不錯，對吧？我們現在將所有的活動域都部署在HTTPS，並且具有有效的證書。不，我們有個問題。還記得我們如何保持meta.gaming.stackexchange.com多年？當它重定向到gaming.meta.stackexchange.com時，重定向沒有有效的證書。

以metas為例，如果我們在我們的HSTS頭上推送了includeSubDomains，我們將把互聯網上的每一個指向舊域名的鏈接，從正常工作的重定向改變為地雷。而不是登陸https：//網站（如今），他們會得到一個無效的證書錯誤。根據我們昨天的流量記錄，我們每天仍有80,000次點擊會訪問到301s的子域名。很多來自網路抓取工具（需要相當長的一段時間），但很多也是來自博客，書籤等的人流量，而且一些抓取工具只是真的很愚蠢，從不會根據301更新他們的信息。是誰誰明白。為什麼還在讀這個？我寫這個該死的東西讓我睡著了3次。

那麼我們該怎麼辦？我們是否設置了幾個SAN證書，其上包含數百個域，並承諾嚴格通過我們的基礎架構管理301？不付出更高的成本（更多的知識產權，更多的證據等），通過Fastly是不能合理地實現。Let』s Encrypt在這裡實際上是有幫助的。如果您忽略設置和維護證書所需的工程工作（這也是我們因為上述原因不使用它的理由），那麼獲得證書將是低成本的。

這裡還有一個關鍵的歷史問題：我們的內部域名是ds.stackexchange.com。為什麼選擇我不確定。我的假設是我們不知道如何拼寫數據中心。這意味著includeSubDomains自動包含每個內部端點。現在，我們的大部分內容都是https：//已經存在，但是從內部的第一時間開始，一切都需要HTTPS來進行開發，這將導致一些問題和延遲。這不是我們不希望在內部的任何地方使用https：//，但這是一個整個項目（主要是關於證書分發和維護，以及多級證書），你真的不想要耦合。為什麼不改變內部域名？因為我們沒有幾個閑置的月份進行橫向移動。需要大量的時間和協調才能做到這一點。

目前，我將把所有Q＆A網站的HSTS最大持續時間緩慢提高到2年，而不需要包括子域名。如果必須，我實際上要從代碼中刪除這個設置，因為它是如此危險。一旦我們獲得了所有問答網站標題的持續時間，我認為我們可以與Google合作，將其添加到HSTS列表中，而不需要使用includeSubDomains，至少是個開端。您可以在當前的列表中看到，這種情況在罕見的情況下會發生。我希望他們同意保護Stack Overflow。

聊天

為了儘可能快地啟用Secure cookies（僅通過HTTPS發送），我們將把聊天（chat.stackoverflow.com，chat.stackexchange.com和chat.meta.stackexchange.com）重定向到https：/。 如同所有其他通用登錄應用程序一樣，聊天依賴於二級域名上的Cookie，因此如果Cookie僅通過https：//發送，則只能通過https：//登錄。

在這方面還有更多的想法，但是在我們解決這些問題的同時，使用混合內容進行聊天本身仍然是一個凈勝。 它允許我們快速保護網路，然後在實時聊天中處理混合內容。 在接下來的一兩周內找到這個。 這是我的下一個任務。

今天

無論如何，這就是我們目前做到的，以及過去4年的發展。 很多事情出現了更高的優先順序，把HTTPS推回來 - 這遠不是我們唯一一直在努力的事情。 這就是生命。 處理這些工作的人仍然是那些希望你永遠看不到錯誤的那幫人。 這裡還有更多的人參與。 我正在把這個帖子縮小到僅覆蓋複雜的話題（否則很長一段時間都無法結束），每個人都需要大量的工作，而在Stack Overflow和外部的許多其他人都提供了幫助。

我知道很多你會對我們如何更好地做好事情提出許多問題，疑慮，抱怨和建議。 我們更歡迎所有這些事情。 我們將在本周查看所有的評論，包括我們的metas，Reddit，Hacker News和Twitter，儘可能地回答/幫助。 感謝您百忙之中抽出時間，估計您讀完這篇文字已經近乎抓狂了吧。<3

英文原文：https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/
譯者：jianli

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！