nginx開啟HSTS讓瀏覽器強制跳轉HTTPS訪問

龍恩0707發表於2019-05-29
Nginx瀏覽器HTTP

在上一篇文章中我們已經實現了本地node服務使用https訪問了，看上一篇文章 效果可以看如下：

但是如果我們現在使用http來訪問的話，訪問不了。如下圖所示：

因此我現在首先要做的是使用nginx配置下，當使用者在瀏覽器下輸入http請求的時候使用nginx重定向到https下即可。因此我們現在需要做一個簡單的nginx重定向功能。想要深入瞭解nginx重定向功能，可以看這篇文章. 

因此在我們的nginx中需要加如下重定向配置：

server {
  listen xxx.abc.com;
  server_name xxx.abc.com;
  rewrite ^/(.*)$ https://$host$1 permanent;
}

因此nginx主要的配置程式碼如下：

server {
  listen xxx.abc.com;
  server_name xxx.abc.com;
  rewrite ^/(.*)$ https://$host$1 permanent;
}
server {
  listen       443 ssl;
  server_name  xxx.abc.com;

  ssl_certificate      cert/server.crt;
  ssl_certificate_key  cert/server.key;

  ssl_session_cache    shared:SSL:1m;
  ssl_session_timeout  5m;

  ssl_ciphers  HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers  on;

  location / {
    proxy_pass http://localhost:3001;
  }
}

如上配置後，我們需要重新啟動下nginx即可生效，我們在瀏覽器下輸入域名 http://xxx.abc.com 後 會自動重定向到 https://xxx.abc.com/ 了，我們再來看下 我們網路上的請求有2個請求，如下所示：

如上請求可以看到，瀏覽器首先會向網站發起一次http請求(http://xxx.abc.com), 在得到一個重定向響應後，再會發起一次https請求並得到最終的響應內容。對使用者來講，它的操作是透明的，使用者體驗也是不錯的，但是在https連結之前會存在一次明文的http請求和重定向。那麼攻擊者可以以中間人的方式劫持http請求。來進行後續的攻擊。比如竊聽資料。篡改請求或響應、跳轉到釣魚網站等操作。因此http請求是不夠安全的，所以最近幾年所有的網站都要以https來訪問的。

那麼以劫持http請求並跳轉到釣魚網站類為列子，來看看大致的劫持流程是如下這個樣子的。

操作步驟如下：
1. 瀏覽器會發起一次http請求(比如http://xxx.abc.com). 發出請求後，攻擊者會以中間人的身份來劫持該http請求。
2. 攻擊者劫持該http請求後，會把當前請求轉發給釣魚網站(比如 http://xxx.yyy.com)。
3. 釣魚網站會返回假冒的網頁內容。
4. 最後攻擊者把假冒的網頁內容返回給瀏覽器。

如上http請求根本就沒有重定向到https網站到，而是攻擊者直接劫持了http請求，最終把釣魚網站返回給瀏覽器了。因此如果直接http重定向的話，會存在一次http請求明文的問題，因此直接使用http重定向是不安全的，因此就出現了HSTS來解決這個問題。下面我們來認識下HSTS吧。

2. 認識下HSTS

如上使用重定向的方式，把http重定向到https存在安全性問題，因為在重定向https之前會存在一次http明文的請求，那麼攻擊者很容易劫持http請求，因此現在我們想當使用者瀏覽器發起http請求的時候，瀏覽器直接轉換成https請求。然後通過https請求頁面，這樣的話，攻擊者就一般很難進行攻擊了。我們可以請看如下示意圖，如下所示：

步驟可以理解為如下：

1. 使用者在瀏覽器輸入 http://xxx.abc.com 的時候，瀏覽器知道該域名需要使用https來進行通訊。
2. 因此瀏覽器直接向網站發起https請求(比如https://xxx.abc.com) 這樣的。
3. 網站返回響應的內容。

那麼現在的問題就是說，瀏覽器怎麼知道該域名需要使用https呢？因此這個時候我們出現了HSTS了。

HSTS是啥？

HSTS的全稱是 HTTP Strict-Transport-Security. 它是國際網際網路工程組織IETF釋出的一種網際網路安全策略機制。採用HSTS策略的網站將保證瀏覽器始終連結到該網站的https加密版本。不需要使用者手動在URI位址列中輸入加密地址，來減少會話被劫持的風險。

HSTS的基本語法如下：

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age 是必須的引數，它是一個以秒為單位的數值，它代表著HSTS Header的過期時間，一般設定為1年，即 31536000秒。
includeSubDomains 是可選引數，如果設定該引數的話，那麼意味著當前域名及其子域名均開啟HSTS的保護。
preload是可選引數，只有當你申請將自己的域名加入到瀏覽器內建列表的時候才需要使用到它。

下面我們先來看下百度的也是這樣處理的，我們先在瀏覽器URI輸入 http://www.baidu.com/ 後回車，瀏覽器會自動轉化成 https://www.baidu.com/ 這樣的請求了，但是我們使用chrome瀏覽器看網路下的請求可以看到如下會傳送2次請求，如下所示：

第二次是https請求，如下所示：

我們可以看到如上，第一次請求狀態碼是307，並且請求頭有這樣的標識 "Provisional headers are shown", 具體的含義可以理解為瀏覽器攔截了該請求，並且該請求並沒有傳送出去。因此瀏覽器發現該域名需要使用https來請求，所以就發了第二次https請求了。

nginx下配置HSTS

在nginx配置檔案上設定HSTS響應頭部，程式碼如下：

add_header Strict-Transport-Security "max-age=172800; includeSubDomains"

因此nginx的配置如下：

server {
  listen xxx.abc.com;
  server_name xxx.abc.com;
  rewrite ^/(.*)$ https://$host$1 permanent;
}
server {
  listen       443 ssl;
  server_name  xxx.abc.com;
  add_header Strict-Transport-Security "max-age=172800; includeSubDomains";
  ssl_certificate      cert/server.crt;
  ssl_certificate_key  cert/server.key;

  ssl_session_cache    shared:SSL:1m;
  ssl_session_timeout  5m;

  ssl_ciphers  HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers  on;

  location / {
    proxy_pass http://localhost:3001;
  }
}

然後nginx配置儲存，然後重啟。

當我重啟後，第一次使用https方式訪問我的網站，nginx會告訴客戶端瀏覽器，以後如果使用者輸入的是http，也要讓瀏覽器以https來訪問我的nginx伺服器，如下所示：

但是如果nginx重啟後，第一次使用http訪問的話，雖然跳轉了，但是並沒有使用HSTS了，因為要跳轉到https，才會使用HSTS。但是當我再輸入http了就會有307狀態碼，並且有 "Provisional headers are shown" 這樣的提示。

理解HSTS Preload List

HSTS雖然可以解決HTTPS的降級攻擊，但是對於HSTS生效前首次的http請求，依然是無法避免http請求被劫持的問題，比如我們第一次瀏覽器清除快取，然後第一次使用http請求的話，第一次http也是明文傳輸的，當跳轉到https後會使用HSTS的，以後只要瀏覽器快取不清除的話，nginx不重啟的話，都會使用HSTS保護的。因此為了解決第一次http請求的問題，瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 的方案，內建一份可以定期更新的表，對於列表中的域名，即使使用者之前沒有訪問過，也會使用https協議請求的。

目前這個Preload List由Google Chrome維護，Chrome、Firefox、Safari、IE 11和Microsoft Edge都在使用。如果要想把自己的域名加進這個列表，首先需要滿足以下條件：

1. 擁有合法的證書(如果使用SHA-1證書，過期時間必須早於2016年)；

2. 將所有HTTP流量重定向到HTTPS；
3. 確保所有子域名都啟用了HTTPS；
4. 輸出HSTS響應頭：
5. max-age不能低於18周(10886400秒)；
6. 必須指定includeSubdomains引數；
7. 必須指定preload引數；

即便滿足了上述所有條件，也不一定能進入HSTS Preload List，更多資訊可以檢視：https://hstspreload.org/。

通過Chrome的chrome://net-internals/#hsts工具，可以查詢某個網站是否在PreloadList之中，還可以手動把某個域名加到本機Preload List。

HSTS缺點

HSTS並不是HTTP會話劫持的完美解決方案。使用者首次訪問某網站是不受HSTS保護的。這是因為首次訪問時，瀏覽器還未收到HSTS，所以仍有可能通過明文HTTP來訪問。

如果使用者通過HTTP訪問HSTS保護的網站時，以下幾種情況存在降級劫持可能：

1. 以前從未訪問過該網站。
2. 最近重新安裝了其作業系統。
3. 最近重新安裝了其瀏覽器。
4. 切換到新的瀏覽器。
5. 刪除瀏覽器的快取。
6. 最近沒訪問過該站並且max-age過期了。
那麼解決該問題的方法，可以使用上面介紹的 HSTS Preload List 方法。

支援HSTS瀏覽器

目前主流瀏覽器都已經支援HSTS特性，具體可參考下面列表：

Google Chrome 4及以上版本
Firefox 4及以上版本
Opera 12及以上版本
Safari從OS X Mavericks起
Internet Explorer及以上版本

相關文章