HTTPS 可能被這樣劫持嗎？

12-26

在瀏覽器輸入如下域名
https:// www.zhihu.com
那瀏覽器要打開這個網站，首先要解析域名www.zhihu.com,結果這個域名被黑客劫持到他的私人伺服器1.2.3.4,結果我的瀏覽器和他的私人伺服器1.2.3.4建立SSL連接，他的伺服器1.2.3.4也和www.zhihu.com建立SSL的連接，我收發的數據都通過他的伺服器1.2.3.4中轉，也就是黑客的伺服器1.2.3.4相當於一個https代理伺服器，結果我收發的所有數據，他都能看到。可能這樣被劫持嗎？

是完全有可能的，只要你導入了一個不知名根證書。我舉個例子：

ADsafe（凈網大師）更新了 5.2 版本後，有很多用戶發現使用火狐訪問 HTTPS 網站均出現「連接不安全」的提示，錯誤代碼 SEC_ERROR_UNKNOWN_ISSUER：

而這時你會發現其他瀏覽器訪問正常，通過研究 ADsafe 的設置發現，凈網大師 5.2 版本加入了 HTTPS 攔截功能，這種所謂的去廣告功能本質上是對所有網路通信進行劫持，劫持並解包網路通信，會破壞 HTTPS 安全連接。凈網大師是通過導入偽造證書的方式解決 HTTPS 錯誤，由於火狐不允許自動導入證書，就會出現這種情況。

我們看一下開啟這個選項後，知乎的 SSL 證書。回到第一張圖，點擊錯誤代碼，會顯示當前證書的證書鏈：

我們可以通過把證書鏈解碼的方式查看證書信息，點擊複製到剪貼板，然後訪問 SSL Certificate Decoder 將證書鏈複製到 Decode 窗口，並點擊 Decode：

完成後，我們可以在下方查看當前「知乎」網站的證書信息，適用域名，這裡是正常的：

查看到簽發機構時就可以發現問題了：

我們看一下正常的證書籤發機構是什麼：

同樣的，如果你測試其他 HTTPS 網站，例如「百度」，「淘寶」，也會發現他們的證書籤發機構統統被改為了 ADSafe。

那麼為什麼其他瀏覽器即使顯示的是 ADSafe 的證書，打開網站卻不會出現錯誤提示呢？
Chrome：

網站證書是否被信任，取決於證書機構是否是被認證，Chrome 等其他瀏覽器使用的是系統根證書，當系統被導入了一個未知的根證書，即使頒發機構不被認可，訪問這個證書名下的網站都是能正常訪問的。

由於火狐擁有自主的證書存儲機制，這是同 Windows 系統證書存儲互相獨立的一套證書存儲機制，未知的根證書通常不會導入到火狐的證書文件，就會出現這個錯誤。

ADsafe 的問題相對好解決，只需在軟體選項中關閉 HTTPS 掃描即可，國內有些用戶使用的是盜版系統，盜版系統往往會直接對根證書進行修改，也會出現類似的情況。

Firefox 49 版本開始添加了一個參數，如果遇到未知的 CA 證書，瀏覽器可以直接對正在使用的 Windows 系統證書存儲機制進行檢查對比。當然這個參數的本意是某些企業環境中由於 IT 管理員需要安裝根證書至 Windows PC 以訪問企業私有網路或應用，火狐瀏覽器採用的另一套證書存儲機制導致無法通過火狐瀏覽器訪問這些私有網路。如果無法找到劫持的根證書，也可以參考這個方法修改火狐鍵值：訪問所有HTTPS網站顯示連接不安全 - Firefox 火狐瀏覽器 - 火狐社區

這種方法只是讓火狐讀取 Windows 系統根證書存儲中的對應 CA 證書，實際上根證書的問題依然存在。

.如果你安裝了某個不知名的根證書後，你就可以被劫持。
所以在閑的沒事兒的時候，不要亂裝證書，這是一個非常危險的行為。我見過某團隊，在自己的伺服器上自己簽發了證書，然後讓大家安裝他的根證書，然後這個企業的同學們在上網時所有的https就都被劫持並竊聽了。

.如果有某人在一個證書機構仿冒你申請成功了你的域名的證書後，你可以被劫持。
這個可能性很小，也是售賣證書的機構們標榜自己的牛逼的行為特性之一。原則上來講，這樣的事情不可能發生。其實現在很多證書頒發機構連google的類似域名的證書都不敢售賣了。

.如果你申請了多域名證書後，你的證書被盜取，你可以被支持。
這個就是自己內部管理問題了，建議縮短證書的有效期，同時保證好證書在伺服器上的安全性。

.如果你申請的是一個子證書籤發機構，有人私下籤發了你的域名的證書後，你可以被劫持。
如果自己內部出了問題，頒發出去了一張證書，這時只能把子級證書籤發的證書快速去證書籤發機構作廢。

通過所謂的截取會話進行劫持，現在看除非伺服器上有漏洞，否則還不可能這麼快的劫持。原則上來講，現在的加密長度實在太長，如果你有足夠多的計算機，同時計算能力超強，算出伺服器上的隨機串，也可以劫持滴

首先明確一個概念：非對稱加密演算法

非對稱加密演算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。

HTTPS協議中，前面的握手過程，伺服器會將公鑰發給客戶端，客戶端驗證後生成一個密鑰用公鑰加密後發送給伺服器，成功後建立通信。
通信過程客戶端將請求數據用得到的公鑰加密後，發給伺服器，伺服器用私鑰解密。伺服器用客戶端給的密鑰加密響應報文，發回給客戶端，客戶端用自己存的密鑰解密。

忽略掉其他例如確定協議和版本號之類的環節，提煉出來的重要環節如下：

公私玥A用於非對稱式加密，密鑰B只用於普通的對稱式加密。

簡而言之就是這樣，那麼問題來了：你作為一個中間人，你沒有伺服器私鑰A，是不能解密客戶端發送的內容的，如果你沒有客戶端自己生成的密鑰B，所以你也不能解密客戶端發過去的內容的。
請注意：這兩個私鑰都是兩端各自保存，而私鑰A是只保存在伺服器上，從不對外發送的。

結果就是，你收發的數據，他都能看到——————但是他不能解密，看不懂。

這只是最普通的劫持HTTP的方式，HTTPS就是為了解決題主所說的這個中間人攻擊而產生的，然而題主並沒有去理解HTTPS的工作原理，而用HTTP的原始思路繼續去思考HTTPS，所以題主這個方法是完全不可行的。

繼續往下想，或許有人會覺得：

如果你自己簽發一對非對稱式公私鑰C，還有密鑰D，然後作為一個中間人。在一開始的通信環節，用公私鑰C替代公私鑰A，用密鑰D替代密鑰B。這樣分發給對應的伺服器和客戶端，這樣他們發給自己的信息，自己都能解密。然後自己再用真正的公鑰A把解密後的信息重新加密發給伺服器騙取響應報文，把響應報文用密鑰B（前面客戶端用公鑰C加密後，被中間人用私鑰C解密的刀）重新加密發回給客戶端騙取新的請求報文。
這樣豈不是可以瞞天過海？

那麼在圖中所示的驗證環節，因為你的證書是自己簽發的，所以證書跟指紋拿去去系統里可信頒發機構的證書那一對，肯定對不上。

例如我用Fiddler給自己簽發了個證書，因為頒發者不在系統受信任證書頒發機構里，會直接報警：

如果你要假冒其他機構頒發證書，因為你沒有頒發機構的密鑰，那麼你頒發的證書，結果指紋肯定沒辦法對上，還是一樣會報警。

系統信任的頒發機構一般都是權威的大機構，當然你也可以自己導入自己信任的機構的證書，用來驗證簽名。

如果要實現HTTPS下的中間人攻擊，你應該讓自己的根證書進入系統里，讓自己成為裁判。
這是HTTPS中間人攻擊中最難也是最簡單的一點——畢竟用戶很好騙。

你可以這麼做，或者跟上一張圖證書中的第三第四行所示的那麼做。

還有人就說了，我可以讓用戶回落到HTTP協議啊，中間人用HTTPS跟伺服器通信，然後用HTTP跟客戶端通信——要知道大部分用戶在地址欄輸入URL時，並沒有指定協議的習慣，都是打www開頭而不是打https://開頭，能用HTTPS全是Web Server上80埠301 Location到HTTPS的功勞。

看起來似乎中間人充當了一個替換頁面里HTTPS資源到HTTP的反向代理，好像可行性還是很高。
但是只要利用HSTS（HTTP Strict Transport Security，RFC6797）就可以解決這個問題。通過在HTTP Header中加入Strict-Transport-Security的聲明，告訴瀏覽器在一定時間內必須通過HTTPS協議訪問本域名下的資源。
這種情況下，只要用戶曾經在安全網路環境下訪問過一次某站，中間人在指定時間內也無法讓其回落到HTTP。

樓主已經說了輸入https://www.zhihu.com了，所以ssltrip就沒有作用了。
但是sslsniff可以劫持，原理就是mitm偽造知乎證書並獲取瀏覽器信任（誘騙用戶安裝），瀏覽器和mitm使用假證書通信，mitm再將用戶請求轉發給知乎伺服器通信，完整劫獲用戶信息。
不過這種劫持成本較高，需要用戶安裝證書，也需要mitm加解密，所以大規模劫持不會這麼干。

對於大部分https網站，都是有被 MITM 的風險的
首先無論PC還是手機內部都是有一個受信的CA列表的，所以無論是夠是真的受信，只要在這個列表裡面
1.如果某些受信CA 亂簽發證書，可以被利用劫持https回話
2.如果裝了某些apps 或者軟體，同時導入了一些自簽發的CA，同樣可能會被劫持

可以用 certificates spinning 來避免這個問題。

中間人攻擊沒法防，你們都是從網上下的瀏覽器對吧

理論上有可能。但是你可以識別出來的。

因為 https 的特性，攻擊者需要向你偽裝成伺服器，向伺服器偽裝成你。你和 http://zhihu.com 伺服器之間原本密封的信件，被攻擊者打開閱讀後，重新換了個信封封好，再發給你。（攻擊者的私人伺服器向你提供了一個偽造的證書，用來維持給你提供的 https 訪問。）

因為攻擊者沒有原始蠟封的印章（證書的私鑰），所以他從黑市弄了一塊（驗證不嚴格的CA給他頒發了一張證書）。如果你發現印章細節（證書內容）可疑，那就有可能受到了 https 中間人攻擊。

如果是偽造的印章，是可以一眼看穿的（瀏覽器提示），但是，如果專業的印章刻制機構（CA根證書持有者）被賄賂、被欺騙或出於其他目的，參與了偽造，就看不出來了（瀏覽器沒有提示）。

所以，要保管好域名的管理許可權和敏感用戶名郵箱，防止被拿去私刻印章（申請合法證書）；同時，對那些信譽不好的刻制機構（CA），我們要把他從信任列表中移除，避免被欺騙。

擴展閱讀：
CNNIC CA：最最最嚴重安全警告！

即為 HTTPS中間人攻擊(Man-in-the-Middle Attack)。
原理：基於SSLStrip的HTTPS會話劫持
示例：https劫持 - hack8的專欄

可以，提供兩種思路
一，你偽造證書（基本不可能，你把頒發證書的機構全拿下？）
二，用在一個網段內做mitm，SSLtrip
可以參考我之前的一個思路：MITM之截獲用戶敏感信息（有點像釣魚）

HTTPS協議不支持代理，也就是說，HTTPS協議保護的是你和目的端的通信，這中間不允許出現代理。

目的端的伺服器是通過證書來驗證身份的，所以這樣劫持的後果就是：

順便說一下排名第一的答案，你們的某控制項自動給用戶種根證書用戶造么？

是為了連騙證書這一步都免了么？

看到一些答案提到的方法基本都是客戶端瀏覽器用戶操作不當導致的。比如SSLStrip是因為用戶在瀏覽器輸入的不是HTTPS URL，這種情況下用戶能夠發現自己用的不是HTTPS。而根證書的問題，也是用戶自己選擇了安裝未知來源的證書。

正常情況下，用戶能確定：

瀏覽器客戶端使用的是HTTPS（很容易做到）
自己沒有安裝未知來源的根證書（很容易做到）
所用的瀏覽器不是未知來源的（對比官方公布的下載文件散列值）

那麼這裡的HTTPS就不可能被劫持。考慮下過程：

用戶在瀏覽器輸入域名https://www.zhihu.com，瀏覽器發起請求
網路上某個未知的伺服器回復請求，它首先返回了一個公鑰證書
客戶端收到公鑰證書，可以驗證公鑰證書是有效的：

根據客戶端系統中的可信根證書列表，確定證書的CA可信。但是可信CA簽發的證書那麼多，隨便哪一個都行嗎？

確定證書屬於域名*.zhihu.com。但是如果別人把可信CA簽發的某個證書修改了，域名改成*.zhihu.com怎麼辦？

驗證證書上的私鑰簽名，確定證書內容在網路傳輸過程中沒被修改。

從上面的過程可以看出，當你在瀏覽器輸入https://www.zhihu.com的時候，伺服器（無論是誰的）給你返回的證書只能是知乎的真實證書，不會被替換或者修改，否則會被瀏覽器檢測到。

既然拿到了真實的知乎證書，那麼剩下的加密通信過程就非常安全了。因為客戶端只要用證書中的公鑰加密數據，那就只有對應的證書私鑰才能解密查看，而證書私鑰只有真正的知乎伺服器才知道。

簡述一下SSL/TLS驗證伺服器合法的過程：
（大幅度簡化）
首先瀏覽器通過DNS解析到伺服器地址，向伺服器發出https請求
伺服器向瀏覽器扔出自己的公鑰（證書）（由CA私鑰簽名，清楚地含有域名信息）
瀏覽器檢索相應CA在本地保存的公鑰（證書），驗證伺服器的公鑰（證書）的確由該CA簽名，並且的確發行給你所訪問的域名。
此時伺服器已經被確認合法。

其中的幾個關鍵信任點：
1.伺服器的私鑰保持私有
伺服器的私鑰被公開的可能性應該存在，但本人不是安全運維方面的人員不清楚現在業內情況
http://2.CA的私鑰保持私有
CA的私鑰公開且被利用非法簽發證書的事情發生過，當時系統與瀏覽器迅速進行更新，拒絕了所有該CA簽發的伺服器證書。只要用戶及時更新，CA問題對用戶的影響是很有限的（但在5月份SMB事件的時候我才發現讓用戶更新實在是。。）
4.本地的CA根證書可信
本地的根證書本應由系統及瀏覽器所欲裝，因此需信任系統（廠商）以及瀏覽器。然而這年頭在Windows上想讓軟體安裝證書完全不是難事，完全有可能有軟體在本地安插了一個自己的根證書，並用他來驗證所有的假伺服器證書。這就要靠用戶的安全警覺性了（哈）
這事發生過，之前聯想曾經為了廣告而在本地直接生成根證書，並且在本地直接用根證書籤名你所有訪問網站的伺服器證書，以劫持HTTPS流量，完成了一次SSL中間人攻擊。
5.瀏覽器可信
在根證書之外，瀏覽器還可以直接在劉本地重定向你的流量（地址欄寫的是http://zhihu.com，訪問的卻是http://zh1hu.com此類）
6.用戶在看到那個大大的紅色鎖的該連接不可信時不會直接無腦點繼續瀏覽
呵。

恭喜題主發現了一個幾十年前就在討論的並已經使用CA證書解決的攻擊：中間人攻擊

思而不學則殆

不會，因為用戶無法和1.2.3.4建立https連接，因為他的伺服器沒有ca簽發的證書！沒有證書，怎麼建立https連接呢？除非你搞到一張合法的受信任的假的證書，或者你自己簽發一個證書，然後用戶點擊信任你的證書。這樣才能建立你們之間的https.

思而不學則殆

讓我想到某牆進行的中間人攻擊

標準的中間人劫持，但是需要一個被正規CA認證的證書。要麼正規CA足夠邪惡敢簽這種證書，要麼你足夠傻導入了劫持用的CA。

這就體現了證書籤名的重要性

首先

從這個簡化版的SSL協議可以看出，單從SSL協議下手的話，中間人攻擊是不可能的，還有replay攻擊也是不行的。所以SSL如果遭到中間人攻擊只有兩種情況。
1.伺服器被黑導致伺服器的私鑰被攻擊者知道，這樣攻擊者可以假裝自己是zhihu跟客戶端連接，然而客戶端卻渾然不知。
2.用戶自己信任了惡意CA。這樣的話在建立SSL連接的過程中，惡意CA可以阻斷連接，並生成key和用CA自己的key加密的偽造證書，然後發給用戶。然而在用戶的信任列表中有這個惡意CA，所以客戶端默認接受了這個偽造的證書並建立連接，這樣惡意CA就可以獲取到所有的數據了。

題主說的是存在的，這個叫做中間人攻擊，在https的領域也是存在的，基於此，引入了CA和簽章，絕對的安全是不存在的，比如：如果這裡負責ca和簽章的伺服器都被攻陷了，那也不要說什麼安全不安全了～
所以只是看一個投入產出比的問題。