在上一篇文章中我們已經(jīng)實(shí)現(xiàn)了本地node服務(wù)使用https訪問了，看上一篇文章效果可以看如下：
但是如果我們現(xiàn)在使用http來訪問的話，訪問不了。如下圖所示：
因此我現(xiàn)在首先要做的是使用nginx配置下，當(dāng)用戶在瀏覽器下輸入http請求的時(shí)候使用nginx重定向到https下即可。因此我們現(xiàn)在需要做一個(gè)簡單的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/ 了，我們再來看下 我們網(wǎng)絡(luò)上的請求有2個(gè)請求，如下所示：
如上請求可以看到，瀏覽器首先會向網(wǎng)站發(fā)起一次http請求(http://xxx.abc.com), 在得到一個(gè)重定向響應(yīng)后，再會發(fā)起一次https請求并得到最終的響應(yīng)內(nèi)容。對用戶來講，它的操作是透明的，用戶體驗(yàn)也是不錯(cuò)的，但是在https鏈接之前會存在一次明文的http請求和重定向。那么攻擊者可以以中間人的方式劫持http請求。來進(jìn)行后續(xù)的攻擊。比如竊聽數(shù)據(jù)。篡改請求或響應(yīng)、跳轉(zhuǎn)到釣魚網(wǎng)站等操作。因此http請求是不夠安全的，所以最近幾年所有的網(wǎng)站都要以https來訪問的。
那么以劫持http請求并跳轉(zhuǎn)到釣魚網(wǎng)站類為列子，來看看大致的劫持流程是如下這個(gè)樣子的。
操作步驟如下：
1. 瀏覽器會發(fā)起一次http請求(比如http://xxx.abc.com). 發(fā)出請求后，攻擊者會以中間人的身份來劫持該http請求。
2. 攻擊者劫持該http請求后，會把當(dāng)前請求轉(zhuǎn)發(fā)給釣魚網(wǎng)站(比如 http://xxx.yyy.com)。
3. 釣魚網(wǎng)站會返回假冒的網(wǎng)頁內(nèi)容。
4. 最后攻擊者把假冒的網(wǎng)頁內(nèi)容返回給瀏覽器。
如上http請求根本就沒有重定向到https網(wǎng)站到，而是攻擊者直接劫持了http請求，最終把釣魚網(wǎng)站返回給瀏覽器了。因此如果直接http重定向的話，會存在一次http請求明文的問題，因此直接使用http重定向是不安全的，因此就出現(xiàn)了HSTS來解決這個(gè)問題。下面我們來認(rèn)識下HSTS吧。
2. 認(rèn)識下HSTS
如上使用重定向的方式，把http重定向到https存在安全性問題，因?yàn)樵谥囟ㄏ騢ttps之前會存在一次http明文的請求，那么攻擊者很容易劫持http請求，因此現(xiàn)在我們想當(dāng)用戶瀏覽器發(fā)起http請求的時(shí)候，瀏覽器直接轉(zhuǎn)換成https請求。然后通過https請求頁面，這樣的話，攻擊者就一般很難進(jìn)行攻擊了。我們可以請看如下示意圖，如下所示：
步驟可以理解為如下：
1. 用戶在瀏覽器輸入 http://xxx.abc.com 的時(shí)候，瀏覽器知道該域名需要使用https來進(jìn)行通信。
2. 因此瀏覽器直接向網(wǎng)站發(fā)起https請求(比如https://xxx.abc.com) 這樣的。
3. 網(wǎng)站返回響應(yīng)的內(nèi)容。
那么現(xiàn)在的問題就是說，瀏覽器怎么知道該域名需要使用https呢？因此這個(gè)時(shí)候我們出現(xiàn)了HSTS了。
HSTS是啥？
HSTS的全稱是 HTTP Strict-Transport-Security. 它是國際互聯(lián)網(wǎng)工程組織IETF發(fā)布的一種互聯(lián)網(wǎng)安全策略機(jī)制。采用HSTS策略的網(wǎng)站將保證瀏覽器始終鏈接到該網(wǎng)站的https加密版本。不需要用戶手動在URI地址欄中輸入加密地址，來減少會話被劫持的風(fēng)險(xiǎn)。
HSTS的基本語法如下：
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]
max-age 是必須的參數(shù)，它是一個(gè)以秒為單位的數(shù)值，它代表著HSTS Header的過期時(shí)間，一般設(shè)置為1年，即 31536000秒。
includeSubDomains 是可選參數(shù)，如果設(shè)置該參數(shù)的話，那么意味著當(dāng)前域名及其子域名均開啟HSTS的保護(hù)。
preload是可選參數(shù)，只有當(dāng)你申請將自己的域名加入到瀏覽器內(nèi)置列表的時(shí)候才需要使用到它。
下面我們先來看下百度的也是這樣處理的，我們先在瀏覽器URI輸入 http://www.baidu.com/ 后回車，瀏覽器會自動轉(zhuǎn)化成 https://www.baidu.com/ 這樣的請求了，但是我們使用chrome瀏覽器看網(wǎng)絡(luò)下的請求可以看到如下會發(fā)送2次請求，如下所示：
第二次是https請求，如下所示：
我們可以看到如上，第一次請求狀態(tài)碼是307，并且請求頭有這樣的標(biāo)識 "Provisional headers are shown", 具體的含義可以理解為瀏覽器攔截了該請求，并且該請求并沒有發(fā)送出去。因此瀏覽器發(fā)現(xiàn)該域名需要使用https來請求，所以就發(fā)了第二次https請求了。
nginx下配置HSTS
在nginx配置文件上設(shè)置HSTS響應(yīng)頭部，代碼如下：
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配置保存，然后重啟。
當(dāng)我重啟后，第一次使用https方式訪問我的網(wǎng)站，nginx會告訴客戶端瀏覽器，以后如果用戶輸入的是http，也要讓瀏覽器以https來訪問我的nginx服務(wù)器，如下所示：
但是如果nginx重啟后，第一次使用http訪問的話，雖然跳轉(zhuǎn)了，但是并沒有使用HSTS了，因?yàn)橐D(zhuǎn)到https，才會使用HSTS。但是當(dāng)我再輸入http了就會有307狀態(tài)碼，并且有 "Provisional headers are shown" 這樣的提示。
理解HSTS Preload List
HSTS雖然可以解決HTTPS的降級攻擊，但是對于HSTS生效前首次的http請求，依然是無法避免http請求被劫持的問題，比如我們第一次瀏覽器清除緩存，然后第一次使用http請求的話，第一次http也是明文傳輸?shù)模?dāng)跳轉(zhuǎn)到https后會使用HSTS的，以后只要瀏覽器緩存不清除的話，nginx不重啟的話，都會使用HSTS保護(hù)的。因此為了解決第一次http請求的問題，瀏覽器廠商們?yōu)榱私鉀Q這個(gè)問題，提出了 HSTS Preload List 的方案，內(nèi)置一份可以定期更新的表，對于列表中的域名，即使用戶之前沒有訪問過，也會使用https協(xié)議請求的。
目前這個(gè)Preload List由Google Chrome維護(hù)，Chrome、Firefox、Safari、IE 11和Microsoft Edge都在使用。如果要想把自己的域名加進(jìn)這個(gè)列表，首先需要滿足以下條件：
1. 擁有合法的證書(如果使用SHA-1證書，過期時(shí)間必須早于2016年)；
2. 將所有HTTP流量重定向到HTTPS；
3. 確保所有子域名都啟用了HTTPS；
4. 輸出HSTS響應(yīng)頭：
5. max-age不能低于18周(10886400秒)；
6. 必須指定includeSubdomains參數(shù)；
7. 必須指定preload參數(shù)；
即便滿足了上述所有條件，也不一定能進(jìn)入HSTS Preload List，更多信息可以查看：https://hstspreload.org/。
通過Chrome的chrome://net-internals/#hsts工具，可以查詢某個(gè)網(wǎng)站是否在PreloadList之中，還可以手動把某個(gè)域名加到本機(jī)Preload List。
HSTS缺點(diǎn)
HSTS并不是HTTP會話劫持的完美解決方案。用戶首次訪問某網(wǎng)站是不受HSTS保護(hù)的。這是因?yàn)槭状卧L問時(shí)，瀏覽器還未收到HSTS，所以仍有可能通過明文HTTP來訪問。
如果用戶通過HTTP訪問HSTS保護(hù)的網(wǎng)站時(shí)，以下幾種情況存在降級劫持可能：
1. 以前從未訪問過該網(wǎng)站。
2. 最近重新安裝了其操作系統(tǒng)。
3. 最近重新安裝了其瀏覽器。
4. 切換到新的瀏覽器。
5. 刪除瀏覽器的緩存。
6. 最近沒訪問過該站并且max-age過期了。
那么解決該問題的方法，可以使用上面介紹的 HSTS Preload List 方法。
支持HSTS瀏覽器
目前主流瀏覽器都已經(jīng)支持HSTS特性，具體可參考下面列表：
Google Chrome 4及以上版本
Firefox 4及以上版本
Opera 12及以上版本
Safari從OS X Mavericks起
Internet Explorer及以上版本
以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。
