前言
HSTS 的出現，對 HTTPS 劫持帶來莫大的挑戰。
不過，HSTS 也不是萬能的，它只能解決 SSLStrip 這類劫持方式。但仔細想想，SSLStrip 這種算劫持嗎？
劫持 vs 釣魚
從本質上講，SSLStrip 這類工具的技術含量是很低的。它既沒破解什麼算法，也沒找到協議漏洞，只是修改和代理了明文的封包而已。
如果說劫持，要保持源站點不變纔算的話，那 SSLStrip 並沒做到。根據同源的定義，<協議, 主機名, 端口> 三者必須相同。顯然它修改了協議，因此並非在源站點上劫持，而是進入了另個不同的站點。
既然站點都不同，那就屬於釣魚網站了。
但這種釣魚之所以會如此隱蔽，和大家的常理有關：對大部分用戶來說，只要主機名正確那就對了，至於協議和端口，很少有人去關心。
而 SSLStrip 正好利用了人們的認知弱點，確實沒有修改網站主機名，從而欺騙了大部分用戶。
因此更確切的說，這就是一種高級釣魚。
進一步釣魚
由於 HSTS 這種反釣魚的機制出現，即使蒙的了用戶，但也騙不過瀏覽器。
HSTS 正是以主機名爲單位的。在新的版本里，甚至還支持所有子域名（includeSubDomains）。
如果還抱有僥倖心理，期望能過濾首次的 HSTS 頭，那麼 Preloading HSTS 能讓瀏覽器天生就記住某些網站。徹底打消 SSLStrip 的念頭。。。
不過，剛剛也說了，SSLStrip 本質就是網站釣魚。既然都釣魚了，何必這樣鬼鬼祟祟的反倒被發現，爲何不正大光明的釣？
反正釣魚考的就是用戶眼力，不如再進一步，乾脆把主機名也改了吧！眼力不好的人，可能還是看不出破綻。
例如，將原本 https://www.alipay.com 的鏈接，跳轉到 http://www.alipay.cn 這個釣魚網站，仍會有不少用戶覺察不到。
而 www.alipay.cn 這個虛假的主機名，顯然不會在 HSTS 白名單中，因此又可以無限劫持了！
在流量劫持的環境裏，任何明文數據都是可控的。即使訪問 www.alipay.cn 這種不存在的域名，中間人也可模擬 DNS 應答，從而可僞造出各種看起來相似的釣魚站點。
在之前那篇 《SSLStrip 的未來 —— HTTPS 前端劫持》 中，我們是在 URL 的 Query 中進行僞裝的：
雖然修改了 URL，但主機名沒變，因此仍躲不過 HSTS。
所以，我們需要將 symbol 標記轉移到域名裏：
將頁面中出現的 HTTPS 域名稍作修改，就是完全不同的一個站點了，因此即可徹底擺脫 HSTS 的白名單。
例如把域名都替換成 .cn 的，原本 www.alipay.com 就變成 www.alipay.cn 了，這樣即使用戶瀏覽器裏存在 HSTS 記憶，那也是之前的，這個臨時僞造出來的釣魚站點，自然不會有的。
儘管站點完全不同，但表面上看起來仍是相似，因此用戶仍然不易察覺。
同時，中間人能夠識別出域名中的這個被修改過的特徵，在轉發時還原回先前的域名，進行正常代理。
保留綠色證書
對於大部分用戶來說，地址欄裏醒目的 HTTPS 綠色證書，是一隻強心劑。而 SSLStrip 剝離了協議，顯然是不可能出現了。
但如今通過修改主機名，能否要回這個圖標？
如果想有，顯然得申請一個合法的證書。但要將所有的 .cn 域名都配上數字證書，肯定是不現實的。
不過既然是釣魚網站，主機名也可以隨意改，何必困死在頂級域名上？
我們可以申請一個泛域名證書，例如 *.xx.com。這樣，將目標站點都套在該二級域名下，即可以 HTTPS 協議進行釣魚了。
（這裏以自簽署的證書演示）
雖然域名相比之前差別較大，但有醒目的綠色證書，反而更容易被矇蔽了。
HSTS 的意義
由於釣魚的方式可以千變萬化，因此 HSTS 也很難從根本上進行防禦。
當然，這並不意味 HSTS 沒有實際作用。事實上 HSTS 還是能夠避免很大部分的風險。其中最典型的，就是用戶在地址欄裏敲入網址的情況。
在過去，未提供的協議的網址，都是以默認的 HTTP 方式請求，因此在這個入口就有極大的風險。而 HSTS 的出現，很大程度的解決了這個隱患。
如今，像百度這樣的大型導流網站，都在逐步支持 HTTPS 升級，從而在入口源頭上堵住這個安全隱患。
防禦方案
儘管是釣魚，但也不是完全沒有防禦方案。
從攻擊者的角度來看，如果要爲各種站點製作一個釣魚網站，成本是極大的。而且更新起來也不容易，數據也難以保持實時。
因此，通常是直接代理線上的站點內容。既然這樣，不妨在網頁中悄悄加入些監控腳本，統計當前頁面究竟在哪些域名裏出現過，就能快速找出一些釣魚網站了。
當然，攻擊者也可以過濾掉這段監控腳本，這就是後期對抗的事了。