HTTP HSTS協議和 nginx
HTTP HSTS協議和 nginx
Netcraft 公司最近公佈了他們檢測SSL/TLS網站的研究,並指出只有僅僅5%的使用者正確執行了HTTP嚴格傳輸安全HSTS。本文介紹nginx如何配置HSTS。
什麼是HSTS
HTTPS(SSL和TLS)確保使用者和網站通訊過程中安全,使攻擊者難於攔截、修改和假冒。當使用者手動輸入域名或http://連結,該網站的第一個請求是未加密的,使用普通的http。最安全的網站立即傳送回一個重定向使使用者引向到https連線,然而,中間人攻擊者可能會攻擊攔截初始的http請求,從而控制使用者後續的回話。
自然而然HSTS應運而生為了解決這一潛在的安全問題。即時使用者輸入域名或http連線,瀏覽器將嚴格的升級到https連線。
HSTS如何工作的
HSTS策略是從安全的HTTPS站點傳送的HTTP響應頭部發布的。
1 | Strict – Transport – Security : max – age = 31536000 |
當瀏覽器從HTTPS站點看到這個頭部,就知道該域名只能透過HTTPS(SSL 或者 TLS)訪問了。並將此資訊快取到31536000,也就是1年。
可選的引數includeSubDomains告訴瀏覽器該策略適用於當前域下的所有子域。
1 | Strict – Transport – Security : max – age = 31536000 ; includeSubDomains |
nginx配置HSTS
在nginx配置檔案上設定HSTS響應頭部。
1 | add_header Strict – Transport – Security “max-age=31536000; includeSubDomains” always ; |
always 引數確保所有的響應設定該頭部,包括內部產生的錯誤響應。nginx版本早於1.7.5不支援該always引數和內部產生的錯誤響應不設定該頭部資訊。
add_header指令繼承規則:
nginx配置塊繼承add_header指令所在的封裝塊,因此只需將add_header指令放在頂級的server塊。此外還有個重要的例外,如果一個塊包含了add_header指令本身,它不會從封裝塊繼承該頭部,你需要重新定義所有的add_header指令。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | server { listen 443 ssl ; add_header Strict – Transport – Security “max-age=31536000; includeSubDomains” always ; # This ‘location’ block inherits the STS header location / { root / usr / share / nginx / html ; } # Because this ‘location’ block contains another ‘add_header’ directive, # we must redeclare the STS header location / servlet { add _header X – Served – By “My Servlet Handler” ; add_header Strict – Transport – Security “max-age=31536000; includeSubDomains” always ; proxy_pass http : //localhost:8080; } } |
測試HTTP嚴格傳輸安全:
一旦使用者提出HSTS策略,它的快取資訊期由max-age指定。在此期間,瀏覽器將會拒絕透過未加密的HTTP訪問web服務,並拒絕給予例外證照錯誤(如果該網站以前提交了一個有效可信的證照)。如果指定了一個includeSubDomanis引數,這些限制也同樣適用於當前域下的所有子域。
當你測試HSTS時,max-age時間設定短點。
是否每個HTTPS響應需要有一個STS頭部:
我們的目標是當使用者開始HTTPS回話時,儘可能快的呈現HSTS策略。如果他們在回話期間接收到HSTS策略,他們仍然容易受到HTTP劫持攻擊的。瀏覽器只需檢視一次STS頭部,因此它不是嚴格必要將它新增到每個位置塊和每個響應。然而,只在主頁或者登陸頁面新增它可能是不夠的,如果你只新增到快取的響應,客戶端可能無法看到它。確保儘可能多的合理的覆蓋到你的URL,特別注意動態的內容。
HTTP和HTTPS並行
有時網站需要同時執行在HTTP和HTTPS下
1 2 3 4 5 | server { listen 80 ; listen 443 ssl ; . . . } |
有時,需要將http請求重定向到https
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | server { listen 80 default_server ; listen [ :: ] : 80 default_server ; server _name _ ; # Discourage deep links by using a permanent redirect to home page of HTTPS site return 301 https : //$host; # Alternatively, redirect all HTTP links to the matching HTTPS page # return 301 } server { listen 443 ssl ; server_name www . ttlsa . com ; add_header Strict – Transport – Security “max-age=31536000; includeSubDomains” always ; } |
加強HSTS
保護客戶端從HTTP攔截,從它看到STS頭部到宣告的max-age的期間內。然而,HSTS並不是HTTP回話劫持的完美解決方案。使用者仍然容易受到攻擊,如果他們透過HTTP訪問HSTS保護的網站時:
- 以前從未訪問過該網站
- 最近重新安裝了其作業系統
- 最近重新安裝了其瀏覽器
- 切換到新的瀏覽器
- 切換到一個新的裝置如行動電話
- 刪除瀏覽器的快取
- 最近沒訪問過該站並且max-age過期了
為了解決這個問題,google堅持維護了一個“HSTS preload list”的站點域名和子域名,並透過提交其域名。該域名列表被分發和硬編碼到主流的web瀏覽器。客戶端訪問此列表中的域名將主動的使用HTTPS,並拒絕使用HTTP訪問該站點。
一旦設定了STS頭部或者提交了你的域名到HSTS預載入列表,這是不可能將其刪除的。這是一個單向的決定使你的域名透過HTTPS可用的。
全球可信CA機構
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31483669/viewspace-2672781/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 隨記(四):簡述HSTS協議協議
- HTTP和HTTPS協議HTTP協議
- RPC和 HTTP協議RPCHTTP協議
- HTTP協議之:HTTP/1.1和HTTP/2HTTP協議
- HTTP協議和MQTT協議對比誰更好HTTP協議MQQT
- HTTP協議和HTTPS協議的異同點?HTTP協議
- http協議HTTP協議
- HTTP 協議HTTP協議
- 關於nginx HTTP Strict Transport Security (HSTS) Policy Not Enabled 的處理NginxHTTP
- IPIDEA帶你瞭解HTTP協議和SOCKS5協議IdeaHTTP協議
- 02 前端HTTP協議(圖解HTTP) 之 簡單的HTTP協議前端HTTP協議圖解
- 理解http協議HTTP協議
- http協議分析HTTP協議
- HTTP協議(2)HTTP協議
- HTTP 協議類HTTP協議
- 小解http協議HTTP協議
- HTTP協議概述HTTP協議
- Python_17 OSI模型和HTTP協議Python模型HTTP協議
- HTTP協議中URI和URL區別HTTP協議
- HTTP協議簡述HTTP協議
- HTTP 協議簡介HTTP協議
- HTTP協議那些事HTTP協議
- http協議內容HTTP協議
- Http與Https協議HTTP協議
- Http協議入門HTTP協議
- 瞭解HTTP協議HTTP協議
- HTTP通訊協議HTTP協議
- HTTP 協議圖解HTTP協議圖解
- HTTP2 協議HTTP協議
- 簡述HTTP協議HTTP協議
- Http協議簡介HTTP協議
- HTTP 協議完全解析HTTP協議
- HTTP協議詳解HTTP協議
- HTTP協議基礎HTTP協議
- 淺談HTTP協議HTTP協議
- HTTP協議類POST 和GET的區別HTTP協議
- HTTP協議中PUT和POST使用區別HTTP協議
- HTTP協議 GET和POST的左右互博HTTP協議