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

在上一篇文章中咱們已經實現了本地node服務使用https訪問了,看上一篇文章 效果能夠看以下:html

可是若是咱們如今使用http來訪問的話,訪問不了。以下圖所示:node

所以我如今首先要作的是使用nginx配置下,當用戶在瀏覽器下輸入http請求的時候使用nginx重定向到https下便可。所以咱們如今須要作一個簡單的nginx重定向功能。想要深刻了解nginx重定向功能,能夠看這篇文章nginx

所以在咱們的nginx中須要加以下重定向配置:chrome

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吧。session

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及以上版本

相關文章
相關標籤/搜索