HTTPS可以防止中間人篡改內容嗎？

12-28

我搜到Wireshark可以通過導入CA，進而解密HTTPS內容。那麼如果是客戶端程序來訪問HTTPS的話，用戶就有辦法查看請求返回內容了。
另一方面，我們知道，私鑰是存在服務端的，那就是說中間人無法偽造一個服務端用私鑰加密，客戶端用公鑰解密的內容了。
以上有個假設前提是，客戶端無法被破解，服務端私鑰不會被泄露。
不知道我理解的對不對？
===================================================
謝謝各位解釋，這裡補充下，現在重點是防禦用戶主動做的破解，因為是商業軟體，有基於用戶的功能授權，所以，底線是不允許用戶篡改授權內容，如果能讓用戶無法看到則更好。

用戶通過以下方式進行的破解不在本主題討論範圍：
1. 修改客戶端可執行程序
2. 進程內存讀取、修改
3. 偷取伺服器證書

網路安全是一個數學題、又是一個邏輯推理題，其特徵是：一步錯，步步錯。

換句話說，網路安全環環相扣，一個環掉鏈子，整個鏈子就斷了，沒有安全性可言。

讓我來一步步來邏輯推理。

CA的自簽名數字證書是CA的RSA公鑰，這個公鑰預裝在PC的操作系統里，由於是預裝，我們絕對相信這個公鑰是可靠的！（我們如果連微軟都不相信了，下面的內容就不用看了）

既然CA的公鑰是可信的，這是我們接下來一切推理的前提，如果用這個公鑰可以解密對方出示的任何證明材料，那麼對方就是用CA私鑰加密的！既然CA私鑰只有CA唯一知道，所以對方是CA的親筆簽名無疑！

RSA公鑰是明文，所以任何人都可以得到CA的公鑰，那誰唯一擁有CA的RSA私鑰呢？廢話！肯定是CA本人了！

為什麼叫RSA公鑰、私鑰呢？
因為是運行RSA公鑰演算法，才可以得到一一對應的公鑰、私鑰。

公鑰、私鑰有何特點？
公鑰加密的，私鑰可以解密；
私鑰加密的，公鑰可以解密。

但公鑰加密的，公鑰無法解密；
私鑰加密的，私鑰也無法解密！

此乃非對稱加密！

數字證書認證
當伺服器S向客戶端C出示數字證書，其實是一個證書鏈

1） CA自簽名證書（含有CA私鑰簽名的指紋）
2） CA給S簽名的證書（也含有CA私鑰簽名的指紋）

由於C擁有CA的公鑰，1）驗證成功
2）用CA的公鑰，成功驗證是CA私鑰的簽名，於是信任伺服器S的公鑰，因為證書2）里包含伺服器的公鑰

Okay，獲得了伺服器S的公鑰，也認證通過了，這時需要S與C協商用於加密數據的session key 了。

有兩個演算法：

1）DH演算法
S 篩選出自己的素數對 S1、S2
C篩選出自己的素數對 C1、C2

S與C交換各自的S2、C2

S擁有了S1、C2，DH可以算出一個master key
C擁有了C1、S2，DH可以算出一個master key

兩個master key 完全一樣！

這就是神奇的DH演算法！

任何第三方都無法根據截獲的S2、C2算出master key。

S、C用共同的公式，再推導出session key ，這個session key 只有S、C知曉，所以用此key 加密的數據是安全的、第三方是無法破解的。

但如果瀏覽器把C1、S2導出到wireshark，Wireshark是可以計算出master key，再推導出session key 的，因為DH演算法公開。

那麼就可以解密S、C之間的加密流量。

2）RSA演算法
C隨機選取一個master key ，用S 的公鑰加密，S解密，得到明文的master key，剩下過程和DH演算法類似，不在重複！

如果瀏覽器把master key 導出到wireshark 里，同樣也可以解密用戶流量。

看，整個過程就是一個邏輯推理題，但不容許任何一步是邏輯錯誤的！

其實，嚴格意義上來說，Wireshark破解流量不算中間人攻擊，是客戶端主動泄密的結果，用於debug 、trouble shooting 而已。

如果題主的客戶端不主動泄密(like wireshark)，試問誰可以破解https流量呢？

題主問題里的一些描述有不準確的地方，就不一一指出了，可以參照以上過程來糾正。

但並不是說https就無懈可擊，如果認證環節（中間人攻擊）出問題了，流量就被破解了，關於這點等有空的時候再更新！

結論是對的，https可以防禦中間人劫持的。不過你的分析是錯的，加密的內容並非是用客戶端存儲的公鑰解密的。公鑰是服務端通過證書明文傳輸給客戶端的，如果客戶端可以用它來解密，何來保密性可言？https就廢了。

https加密解密數據用的對稱加密演算法，密鑰是雙方基於非對稱協商出來的，是採用橢圓曲線之類的東西做密鑰交換。

基於非對稱演算法在不安全的網路上讓會話雙方生成對稱加密的密鑰，兼顧安全和性能，這個就是我一直膜拜https的原因。

補充一小點內容給你，ssltrip2可以通過arp欺騙篡改響應頁面內容，將https降級為http做劫持，曲線救國。這種攻擊利用的是很多網站並沒有關掉http訪問，而是在服務端將首頁從http跳到https，給了攻擊者一個http響應做突破口。不過這種攻擊也可以防禦，啟用hsts和pre load就行了，讓攻擊者找不到任何http的機會。

題主的目的是防止用戶抓包破解協議，主要是兩方面下手

一是提高抓包門檻，一般使用SSL Pinning技術，用戶抓包難度大了很多，開發成本也不高，如OkHttp等網路庫已經集成了這個功能。

二是提高破解難度，一般是二次加密。

至於完全杜絕用戶破解……這不太可能，唯一能做的就是提高破解難度。

我沒有看明白問題問的「導入CA」是個什麼操作。不過我了解一種通過「信任證書」的方式來做https的解析。

客戶端信任伺服器端，是在客戶端配置了一個「信任列表」，只有這個信任列表中存在的證書籤發者簽發的證書，才會被客戶端信任。

這個是所有基於證書信任的基礎，這是一個管理行為，不是業務行為，也不是控制行為，所以一般沒有在協議中寫出來。

所有的瀏覽器軟體，會內置一個「信任列表」，這個信任列表列出了常見的政府、組織、商業的證書頒發者的根證書（包括公鑰和頒發者的信息，以及有效期）。

當客戶端瀏覽器收到伺服器發過來的證書驗證時，會用頒發者證書列表去檢查：1）此證書的subject（持有人）是不是用戶正在訪問的URL，例如訪問谷歌必須拿到對方發送的谷歌URL的證書，而不是百度的證書； 2）伺服器提供的證書是不是這個列表裡的頒發者頒發的 3）伺服器的證書是不是有效（有效期，是否私鑰持有人，一般通過一個挑戰去驗證）。4）簽名是否有效（用本地保存的信任證書里的公鑰去檢驗伺服器證書里的簽名）；如果檢查不通過，則會提示用戶不安全。

導入CA，就是在可信CA列表上，增加一個用戶自己配置的「可信」。比如，wireshark自己作為一個正式頒發者，被瀏覽器信任。當你鏈接谷歌時，wireshark自己驗證谷歌，然後拿谷歌的URL和谷歌證書里的其他信息，自己簽名給自己發一個「谷歌證書」。因為瀏覽器信任了wireshark的證書（其實是信任了wireshark簽名的證書有效），因此瀏覽器也相信了自己在和谷歌連。

這時，wireshark自己，就是一個應用層中間人。他在瀏覽器和自己間建立一個https（瀏覽器信任了wireshark）；在自己和伺服器間建立一個https（他把客戶所有的用戶數據都截下來重發）。

很多proxy就是這樣的實現，尤其是企業的proxy。

曾經，中國的GFW，也作為中間人對谷歌和其他網站做過攻擊，他利用的是所有瀏覽器信任中國互聯網管理中心。中國互聯網管理中心頒發給GFW一個以谷歌信息為信息的證書。

信任列表，伺服器信息，只要能讓客戶端信任了這兩條，https是可以被中間人攻擊的。

所以，千萬要保護好自己的信任列表，千萬千萬。那些在不明來源下載的瀏覽器軟體或者其他客戶端軟體，很可能是被內置了惡意的信任列表的，他可以讓你訪問銀行的時候訪問到他的網站去。

就目前中國的網路環境，隨隨便便一個證書也下載不誤的，中間人攻擊很容易就實現了。
具體參考，鐵道部網站的自簽發證書，有幾個人下證書的時候會看？

不過話說話來，這不是協議的問題，這是使用的問題

題主沒搞清楚中間人和用戶的區別

HTTPS是保護用戶和伺服器之間的通訊不被第三方竊取或者篡改。這個第三方攻擊者才是中間人。對於用戶對客戶端邏輯的逆向和篡改，HTTPS是不能起到防護作用的

題目的補充說明就更滑稽了。人家告訴你，你的基本思路就錯了，你還在說：請忽略我的所有錯誤理解，只管回答我的問題就行了

你的問題本身就問錯了，別人只能指出你的錯誤，沒法直接回答你的無效問題啊。

不過問題本身是錯誤的，但是你問題的初衷是合理的：防止用戶破解授權。答案很簡單，授權信息都在伺服器端記錄並驗證。

但是如果你的主要業務功能都在客戶端實現，那麼伺服器上的許可權驗證邏輯可以直接在客戶端被跳過。這時候你的問題又退化成從上個世紀80年代就廣泛存在的問題：單機軟體防止盜版

HTTPS可以防止中間人的篡改。

加密演算法的安全性主要分為兩種，一種是保護信息不被泄露的能力（CPA安全），一種是保護信息不被篡改的能力（CCA安全）。

單純的加密演算法是不具備防止篡改的能力的。

比如AES-CBC加密的某一個消息「早上10點20分發起進攻」，我不需要知道這條消息的具體內容是什麼，卻可以通過某種手段隨意把它改成我指定的時間，比如「早上11點10分發起進攻」。

只有結合消息驗證機制的加密演算法才能防止篡改。比如AES-CBC with HMAC-SHA256、AES-GCM、ChaCha20-Poly1305等等。

HTTPS中對消息驗證作了明確要求，所以本身是具有防篡改能力的。

（看一下知乎HTTPS使用的加密演算法，是AES-GCM，這也是目前各大網站的主流選擇。）

回到題主的具體場景上，需要保證客戶端中授權內容不被篡改，嚴格來說HTTPS只是用來保證客戶端到服務端之間通信的安全，而授權內容已經赤裸裸地躺在用戶電腦的內存中，所以理論上是怎麼也防不住用戶做手腳的。

但是如果只是為了防止抓包，那麼只要客戶端不信任系統中的CA，轉而使用內置的CA證書即可。事實上很多安全軟體就是這麼乾的，防止系統中的CA證書被黑客篡改進而導致安全軟體形同虛設。當然這裡又會涉及到如何防止通過逆向修改CA證書的問題，這就是另一個領域的對抗了。

聽說過CNNIC嗎？

這個挺簡單.你已經假設客戶端不能破解.那麼只要把你伺服器證書的指紋寫死在客戶端里.連接的時候檢查指紋就可以了.客戶如果對自己發起中間人攻擊.可以通過添加根證書的方式偽造證書,但是指紋肯定會不一樣.

理論上並不可以，我工作的地方已經大量應用https中間人了，雖然不是以掃描數據為目的，但是其實想掃的話是可以做的。問題在於證書密鑰泄不泄露，用戶訪問dns是否被修改的問題。

公鑰是全網皆知的，怎麼能用來解密呢。一般是公鑰加密，私鑰解密。私鑰做簽名，公鑰驗證簽名。
https就是http加上安全套階層協議，非對稱密鑰通過可信賴PKI（CA）保證服務端公鑰正確性。握手的時候，利用非對稱密鑰交換對稱密鑰，之後都是用對稱密鑰加解密。

因為是https是http的進化版本。
http＋1s=https
這世界，任何事情都是有代價的，想要獲得更好的安全性，就要付出這麼1s。
攻擊者的攻擊也是有代價的。
我們通過向xx祭獻了1s，獲得了更好的安全性，比如說ca證書驗證了server的身份，加密了流量等等。。
攻擊者想要像攻擊http那樣去攻擊https，就需要進行－1s，這樣的代價顯然是巨大的。
但也不是沒有辦法，比如說某證書和某證書。可以想像，現在已經到了xxxx的地步了。

HTTPS=HTTP+認證+加密傳輸+完整性保護，防止篡改當然沒問題啦

抓包軟體可解析HTTPS報文的原因是，用戶主動給該抓包軟體安裝了證書，並手動選擇信任該證書，而且要設置代理為這個軟體，比如題主說的wireshark，或者輕量化的Charles，都是通過用戶手動選擇信任它的證書從而搭建一個中間人的角色，所有的請求都通過這個軟體去發送和解析。

詳細一點就是，客戶端跟Charles通信，Charles再跟伺服器去通信，兩個過程都是完整的HTTPS通信。

需要注意的是，你可以通過給Charles安裝證書從而抓取你手機上的淘寶客戶端的HTTPS數據包，但是你抓不到別人的HTTPS數據包，因為別的人並沒有信任你的軟體呀，也沒有設置代理。所以wireshark和Charles這種抓包HTTPS就是用來調試用的而已啦

給你一個方向，github的mitmproxy開源，關於https代理那一個部分，透傳或者偽造證書欺騙客戶端兩種模式都看看，就明白了

你是客戶端程序嗎？用戶可以做中間劫持的，修改dns,中間人冒充伺服器和客戶端通訊，再冒充客戶端和伺服器通訊。當劫持客戶端的報文後，直接可以做修改，發送給伺服器，伺服器就被欺騙了。

如果是要絕對保證中間傳輸的數據安全的安全性的話，除了用上HTTPS之外，還可以加上JWT.IO 作為數據的載體。對方每次合法登錄之後你才簽發一套公私鑰來通訊，這樣你控制每個的公私鑰都是你簽發的，可以很大程度上避免到被中間人劫持的風險。即使劫持破解了HTTPS的內容，還有JWT這一層的加密。

不過，怎麼保證登錄安全性就又成了問題。這時候可以考慮用USB key這一類的私鑰了。。。

結論：不可能防止防禦用戶主動做中間人攻擊的破解 HTTPS。

具體做法：

如何使用mitmproxy來讀取和修改HTTPS內容

內置證書 + HTTP Pinning 應該可以增強破解難度了。但是太麻煩了吧。

安全網站迴避HTTP公鑰固定？！-SSL中國

HPKP：炙手可熱還是瀕臨死亡？-SSL中國

Is HTTP Public Key Pinning Dead?

HPKP: HTTP Public Key Pinning

只要禁止伺服器證書錯誤，就可以

中間人攻擊：用戶使用中間人的證書，中間人使用用戶想要訪問網站的用戶，這樣形成兩段https 通信