nginx開(kāi)啟HSTS讓瀏覽器強(qiáng)制跳轉(zhuǎn)HTTPS訪(fǎng)問(wèn)詳解
在上一篇文章中我們已經(jīng)實(shí)現(xiàn)了本地node服務(wù)使用https訪(fǎng)問(wèn)了,看上一篇文章效果可以看如下:

但是如果我們現(xiàn)在使用http來(lái)訪(fǎng)問(wèn)的話(huà),訪(fǎng)問(wèn)不了。如下圖所示:

因此我現(xiàn)在首先要做的是使用nginx配置下,當(dāng)用戶(hù)在瀏覽器下輸入http請(qǐng)求的時(shí)候使用nginx重定向到https下即可。因此我們現(xiàn)在需要做一個(gè)簡(jiǎn)單的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;
}
}
如上配置后,我們需要重新啟動(dòng)下nginx即可生效,我們?cè)跒g覽器下輸入域名 http://xxx.abc.com 后 會(huì)自動(dòng)重定向到 https://xxx.abc.com/ 了,我們?cè)賮?lái)看下 我們網(wǎng)絡(luò)上的請(qǐng)求有2個(gè)請(qǐng)求,如下所示:


如上請(qǐng)求可以看到,瀏覽器首先會(huì)向網(wǎng)站發(fā)起一次http請(qǐng)求(http://xxx.abc.com), 在得到一個(gè)重定向響應(yīng)后,再會(huì)發(fā)起一次https請(qǐng)求并得到最終的響應(yīng)內(nèi)容。對(duì)用戶(hù)來(lái)講,它的操作是透明的,用戶(hù)體驗(yàn)也是不錯(cuò)的,但是在https鏈接之前會(huì)存在一次明文的http請(qǐng)求和重定向。那么攻擊者可以以中間人的方式劫持http請(qǐng)求。來(lái)進(jìn)行后續(xù)的攻擊。比如竊聽(tīng)數(shù)據(jù)。篡改請(qǐng)求或響應(yīng)、跳轉(zhuǎn)到釣魚(yú)網(wǎng)站等操作。因此http請(qǐng)求是不夠安全的,所以最近幾年所有的網(wǎng)站都要以https來(lái)訪(fǎng)問(wèn)的。
那么以劫持http請(qǐng)求并跳轉(zhuǎn)到釣魚(yú)網(wǎng)站類(lèi)為列子,來(lái)看看大致的劫持流程是如下這個(gè)樣子的。

操作步驟如下:
1. 瀏覽器會(huì)發(fā)起一次http請(qǐng)求(比如http://xxx.abc.com). 發(fā)出請(qǐng)求后,攻擊者會(huì)以中間人的身份來(lái)劫持該http請(qǐng)求。
2. 攻擊者劫持該http請(qǐng)求后,會(huì)把當(dāng)前請(qǐng)求轉(zhuǎn)發(fā)給釣魚(yú)網(wǎng)站(比如 http://xxx.yyy.com)。
3. 釣魚(yú)網(wǎng)站會(huì)返回假冒的網(wǎng)頁(yè)內(nèi)容。
4. 最后攻擊者把假冒的網(wǎng)頁(yè)內(nèi)容返回給瀏覽器。
如上http請(qǐng)求根本就沒(méi)有重定向到https網(wǎng)站到,而是攻擊者直接劫持了http請(qǐng)求,最終把釣魚(yú)網(wǎng)站返回給瀏覽器了。因此如果直接http重定向的話(huà),會(huì)存在一次http請(qǐng)求明文的問(wèn)題,因此直接使用http重定向是不安全的,因此就出現(xiàn)了HSTS來(lái)解決這個(gè)問(wèn)題。下面我們來(lái)認(rèn)識(shí)下HSTS吧。
2. 認(rèn)識(shí)下HSTS
如上使用重定向的方式,把http重定向到https存在安全性問(wèn)題,因?yàn)樵谥囟ㄏ騢ttps之前會(huì)存在一次http明文的請(qǐng)求,那么攻擊者很容易劫持http請(qǐng)求,因此現(xiàn)在我們想當(dāng)用戶(hù)瀏覽器發(fā)起http請(qǐng)求的時(shí)候,瀏覽器直接轉(zhuǎn)換成https請(qǐng)求。然后通過(guò)https請(qǐng)求頁(yè)面,這樣的話(huà),攻擊者就一般很難進(jìn)行攻擊了。我們可以請(qǐng)看如下示意圖,如下所示:

步驟可以理解為如下:
1. 用戶(hù)在瀏覽器輸入 http://xxx.abc.com 的時(shí)候,瀏覽器知道該域名需要使用https來(lái)進(jìn)行通信。
2. 因此瀏覽器直接向網(wǎng)站發(fā)起https請(qǐng)求(比如https://xxx.abc.com) 這樣的。
3. 網(wǎng)站返回響應(yīng)的內(nèi)容。
那么現(xiàn)在的問(wèn)題就是說(shuō),瀏覽器怎么知道該域名需要使用https呢?因此這個(gè)時(shí)候我們出現(xiàn)了HSTS了。
HSTS是啥?
HSTS的全稱(chēng)是 HTTP Strict-Transport-Security. 它是國(guó)際互聯(lián)網(wǎng)工程組織IETF發(fā)布的一種互聯(lián)網(wǎng)安全策略機(jī)制。采用HSTS策略的網(wǎng)站將保證瀏覽器始終鏈接到該網(wǎng)站的https加密版本。不需要用戶(hù)手動(dòng)在URI地址欄中輸入加密地址,來(lái)減少會(huì)話(huà)被劫持的風(fēng)險(xiǎn)。
HSTS的基本語(yǔ)法如下:
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]
max-age 是必須的參數(shù),它是一個(gè)以秒為單位的數(shù)值,它代表著HSTS Header的過(guò)期時(shí)間,一般設(shè)置為1年,即 31536000秒。
includeSubDomains 是可選參數(shù),如果設(shè)置該參數(shù)的話(huà),那么意味著當(dāng)前域名及其子域名均開(kāi)啟HSTS的保護(hù)。
preload是可選參數(shù),只有當(dāng)你申請(qǐng)將自己的域名加入到瀏覽器內(nèi)置列表的時(shí)候才需要使用到它。
下面我們先來(lái)看下百度的也是這樣處理的,我們先在瀏覽器URI輸入 http://www.baidu.com/ 后回車(chē),瀏覽器會(huì)自動(dòng)轉(zhuǎn)化成 https://www.baidu.com/ 這樣的請(qǐng)求了,但是我們使用chrome瀏覽器看網(wǎng)絡(luò)下的請(qǐng)求可以看到如下會(huì)發(fā)送2次請(qǐng)求,如下所示:

第二次是https請(qǐng)求,如下所示:

我們可以看到如上,第一次請(qǐng)求狀態(tài)碼是307,并且請(qǐng)求頭有這樣的標(biāo)識(shí) "Provisional headers are shown", 具體的含義可以理解為瀏覽器攔截了該請(qǐng)求,并且該請(qǐng)求并沒(méi)有發(fā)送出去。因此瀏覽器發(fā)現(xiàn)該域名需要使用https來(lái)請(qǐng)求,所以就發(fā)了第二次https請(qǐng)求了。
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方式訪(fǎng)問(wèn)我的網(wǎng)站,nginx會(huì)告訴客戶(hù)端瀏覽器,以后如果用戶(hù)輸入的是http,也要讓瀏覽器以https來(lái)訪(fǎng)問(wèn)我的nginx服務(wù)器,如下所示:


但是如果nginx重啟后,第一次使用http訪(fǎng)問(wèn)的話(huà),雖然跳轉(zhuǎn)了,但是并沒(méi)有使用HSTS了,因?yàn)橐D(zhuǎn)到https,才會(huì)使用HSTS。但是當(dāng)我再輸入http了就會(huì)有307狀態(tài)碼,并且有 "Provisional headers are shown" 這樣的提示。
理解HSTS Preload List
HSTS雖然可以解決HTTPS的降級(jí)攻擊,但是對(duì)于HSTS生效前首次的http請(qǐng)求,依然是無(wú)法避免http請(qǐng)求被劫持的問(wèn)題,比如我們第一次瀏覽器清除緩存,然后第一次使用http請(qǐng)求的話(huà),第一次http也是明文傳輸?shù)?,?dāng)跳轉(zhuǎn)到https后會(huì)使用HSTS的,以后只要瀏覽器緩存不清除的話(huà),nginx不重啟的話(huà),都會(huì)使用HSTS保護(hù)的。因此為了解決第一次http請(qǐng)求的問(wèn)題,瀏覽器廠(chǎng)商們?yōu)榱私鉀Q這個(gè)問(wèn)題,提出了 HSTS Preload List 的方案,內(nèi)置一份可以定期更新的表,對(duì)于列表中的域名,即使用戶(hù)之前沒(méi)有訪(fǎng)問(wèn)過(guò),也會(huì)使用https協(xié)議請(qǐng)求的。
目前這個(gè)Preload List由Google Chrome維護(hù),Chrome、Firefox、Safari、IE 11和Microsoft Edge都在使用。如果要想把自己的域名加進(jìn)這個(gè)列表,首先需要滿(mǎn)足以下條件:
1. 擁有合法的證書(shū)(如果使用SHA-1證書(shū),過(guò)期時(shí)間必須早于2016年);
2. 將所有HTTP流量重定向到HTTPS;
3. 確保所有子域名都啟用了HTTPS;
4. 輸出HSTS響應(yīng)頭:
5. max-age不能低于18周(10886400秒);
6. 必須指定includeSubdomains參數(shù);
7. 必須指定preload參數(shù);
即便滿(mǎn)足了上述所有條件,也不一定能進(jìn)入HSTS Preload List,更多信息可以查看:https://hstspreload.org/。
通過(guò)Chrome的chrome://net-internals/#hsts工具,可以查詢(xún)某個(gè)網(wǎng)站是否在PreloadList之中,還可以手動(dòng)把某個(gè)域名加到本機(jī)Preload List。
HSTS缺點(diǎn)
HSTS并不是HTTP會(huì)話(huà)劫持的完美解決方案。用戶(hù)首次訪(fǎng)問(wèn)某網(wǎng)站是不受HSTS保護(hù)的。這是因?yàn)槭状卧L(fǎng)問(wèn)時(shí),瀏覽器還未收到HSTS,所以仍有可能通過(guò)明文HTTP來(lái)訪(fǎng)問(wèn)。
如果用戶(hù)通過(guò)HTTP訪(fǎng)問(wèn)HSTS保護(hù)的網(wǎng)站時(shí),以下幾種情況存在降級(jí)劫持可能:
1. 以前從未訪(fǎng)問(wèn)過(guò)該網(wǎng)站。
2. 最近重新安裝了其操作系統(tǒng)。
3. 最近重新安裝了其瀏覽器。
4. 切換到新的瀏覽器。
5. 刪除瀏覽器的緩存。
6. 最近沒(méi)訪(fǎng)問(wèn)過(guò)該站并且max-age過(guò)期了。
那么解決該問(wèn)題的方法,可以使用上面介紹的 HSTS Preload List 方法。
支持HSTS瀏覽器
目前主流瀏覽器都已經(jīng)支持HSTS特性,具體可參考下面列表:
Google Chrome 4及以上版本
Firefox 4及以上版本
Opera 12及以上版本
Safari從OS X Mavericks起
Internet Explorer及以上版本
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
- nginx強(qiáng)制使用https訪(fǎng)問(wèn)的方法(http跳轉(zhuǎn)到https)
- 詳解NGINX訪(fǎng)問(wèn)https跳轉(zhuǎn)到http的解決方法
- 如何通過(guò)nginx負(fù)載均衡跳轉(zhuǎn)https
- Nginx實(shí)現(xiàn)http自動(dòng)跳轉(zhuǎn)到https
- Nginx配置HTTP強(qiáng)制跳轉(zhuǎn)到HTTPS的解決辦法
- Nginx強(qiáng)制跳轉(zhuǎn)Https(Http訪(fǎng)問(wèn)跳轉(zhuǎn)Https)
- Nginx中實(shí)現(xiàn)訪(fǎng)問(wèn)HTTP請(qǐng)求時(shí)自動(dòng)跳轉(zhuǎn)到HTTPS請(qǐng)求
相關(guān)文章
阿里云部署Ubuntu 1.4 Flask + WSGI + Nginx 詳解
本文解決的是 Flask 最后一公里的問(wèn)題:Linux 部署,需要的朋友可以參考下2017-12-12
Windows下使用?Nginx?搭建?HTTP文件服務(wù)器?實(shí)現(xiàn)文件下載功能
Nginx?是一款輕量級(jí)的?HTTP?服務(wù)器,采用事件驅(qū)動(dòng)的異步非阻塞處理方式框架,這讓其具有極好的?IO?性能,時(shí)常用于服務(wù)端的反向代理和負(fù)載均衡,這篇文章主要介紹了Windows下使用?Nginx?搭建?HTTP文件服務(wù)器實(shí)現(xiàn)文件下載功能,需要的朋友可以參考下2023-03-03
Nginx中配置過(guò)濾爬蟲(chóng)的User-Agent的簡(jiǎn)單方法
這篇文章主要介紹了Nginx中配置過(guò)濾爬蟲(chóng)的User-Agent的簡(jiǎn)單方法,文中羅列了一些常用搜索引擎的爬蟲(chóng)名稱(chēng)以免造成不必要的過(guò)濾,需要的朋友可以參考下2016-01-01
Nginx之正向代理與反向代理進(jìn)階方式(支持https)
文章介紹了如何在Nginx中實(shí)現(xiàn)正向代理和反向代理對(duì)HTTP和HTTPS協(xié)議的支持,通過(guò)使用第三方模塊`ngx_http_proxy_connect_module`和Nginx內(nèi)置的`ngx_http_ssl_module`,可以實(shí)現(xiàn)Nginx對(duì)HTTPS的正向和反向代理2025-03-03
Nginx實(shí)現(xiàn)if多重判斷配置方法示例
這篇文章主要介紹了Nginx實(shí)現(xiàn)if多重判斷配置方法示例,本文直接給出實(shí)現(xiàn)代碼,需要的朋友可以參考下2015-05-05
高并發(fā)nginx服務(wù)器的linux內(nèi)核優(yōu)化配置講解
今天小編就為大家分享一篇關(guān)于高并發(fā)nginx服務(wù)器的linux內(nèi)核優(yōu)化配置講解,小編覺(jué)得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來(lái)看看吧2019-03-03
基于Nginx實(shí)現(xiàn)限制某IP短時(shí)間訪(fǎng)問(wèn)次數(shù)
這篇文章主要介紹了基于Nginx實(shí)現(xiàn)限制某IP短時(shí)間訪(fǎng)問(wèn)次數(shù),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-12-12

