VPN提供商能截獲HTTPS的信息嗎？

12-28

謝邀，先說結論：在基礎設施沒有漏洞和合理操作的前提下不能。

（國內用戶另說，見文末）

長文預警！
========

要說能否截取HTTPS的明文信息，就要從HTTPS的原理說起了。

所謂HTTPS協議，其實是指HTTP和TLS兩種協議的結合。嚴格來說，HTTPS並不能算是一種協議，而應該被看做是HTTP協議在TLS協議之上，使用TLS加密的結果，即：信息仍然採用HTTP協議編碼，但在傳遞時會由TLS協議來加密，從而達到避免竊聽和中間人攻擊的目的。

那麼題主實際上想要問的問題是：假設掌握了TLS加密後的密文，是否存在沒有密匙而獲取明文的方法？

針對這個問題，我們從密碼學的歷史看起。首先要說的一點是，密碼學(cryptography)和密碼(password)是兩個完全不同的概念。密碼學指的是隱秘的傳送信息的方法，而常說的「密碼」則指的是用來認證身份的密匙。

據說，在公元前480年希臘人對波斯人的戰爭時，斯巴達的司令曾派人給前線送去這樣一條腰帶：

KGDEINPKLRIJLFGOKLMNISOJNTVWG

指揮官拿到後，將其纏在一條木棍上，得到了明文"Kill King"，如下：

KGDEINPKLRIJLFGOKLMNISOJNTVWG

斯巴達人雖然在這次戰爭中失敗了，但這次戰爭中卻出現了人類歷史上第一次的加密。從此以後，在不斷增多的秘密通訊需求的推動下，加密裝置不斷地增強，發展到第二次世界大戰中的「迷」，成為了機械式加密裝置的巔峰。

在這之後，由於計算機技術的不斷發展，更加複雜的加密方式變得可能，而更加強大的破解能力也在不斷被實現。同時，由於網路鏈路的複雜性，任何一個環節被監聽都可能導致信息的泄露，而雙方也不可能預先約定一個密匙。這使得加密演算法必須做到在演算法被公開的情況下依然不能被破譯。RSA演算法，TLS協議中使用的一個演算法，就做到了這一點。

RSA演算法是公開密匙加密演算法中的一種。在這樣的演算法中，每個用戶擁有兩個密匙：公匙和私匙。公匙是公開的，而私匙則不公開。這兩個密匙數學上相互關聯，但由公匙計算出私匙則幾乎不可能。用公匙加密的信息可以由對應的私匙解密。這樣，在用戶使用網站時，網站與用戶只需相互交換公匙，並用對方的公匙加密信息，就可以保證信息只有對方可以解密。破解RSA演算法依賴於高效率的大數質因數分解，而目前尚沒有有效的演算法可以做到這一點。因此，在密匙長度足夠的情況下，可以認為由RSA演算法加密的信息是絕對安全的。

但是仍然存在一個問題：我們雖然確認了這個信息是由某一公匙加密的，但卻不能確定這一公匙對應者的身份。如果有人在信息傳遞的中途攔截了這些信息，並用他自己的公匙來替換了雙方的公匙，他就完成了一次中間人攻擊(man-in-the-middle attack)。1586年，被伊麗莎白女王監禁的瑪麗女王收穫了安東尼·貝平頓的秘密信件，得知了他們秘密營救瑪麗並刺殺伊麗莎白的計劃。他們的信件中使用了密碼，但卻被當時的英格蘭大臣華興翰所截獲，複製，由菲力普·馬尼斯破解。在破解後，他們由模仿瑪麗的筆記引誘安東尼行動，一舉抓獲叛逆者。由此可見中間人攻擊的危害，不僅會導致信息的泄露，更會導致內容被替換，從而造成更大的損失。

為了解決這個問題，我們引入了信任鏈這一概念。簡單地說，數字證書認證機構（CA），負責審核身份，並且對公匙做數字簽名，再生成一個證書。數字簽名技術同樣採用RSA演算法，我們只需擁有CA的公匙，就能夠確認這條信息是由CA的私匙加密，從而保證了CA所生成的證書是由CA擔保的。也就是說，CA替用戶完成了審核身份的工作。用戶只需要信任CA的公匙，就能夠信任由這個CA所頒發的所有證書的身份，從而避免了上述信息交換過程中，有第三方替換了證書來進行中間人攻擊的可能性。

可以看到，這一套系統中，我們做到了從兩者初次交換信息開始，所有的交換（公匙，密文）都公開可見，然而攻擊者仍然不能破譯出明文。這一點為現代的互聯網提供了極大的方便，使得用戶可以方便的建立可信任的連接。

回到VPN的問題上來，雖然VPN提供者有瀏覽所有信息的瀏覽的能力，也有替換其中信息的能力，由於我們使用了信任鏈和公匙加密系統，他既不能查看信息的明文，也不能對明文進行替換。

那麼可能的問題有哪些呢？

1. 基礎設施的漏洞
假如說，用戶在收到信息時，並沒有進行有效的身份認證，而是選擇了直接信任這一信息，就能使攻擊者可以採取任意的密匙來偽造身份。這一點的例子就是前段時間著名的"Goto fail"。假如VPN的所有者掌握了這樣的漏洞，就可以偽造自己的身份，從而監聽甚至偽造信息。

2.不合理的操作
由信任鏈的結構可以看出，信任一個證書，就是選擇了信任這個證書所代表的機構認證的任何證書。如果VPN的所有者誘導用戶在自己的設備上信任了自己的CA，那麼他只需要由這個CA頒發給自己一個證書，就可以做到偽造身份了。

下面是私貨夾帶時間
===============

很不幸，在國內，基本上所有的用戶都很危險。

為什麼，因為在你安裝支付寶安全插件的時候，它已經自動幫你信任了一個它自己的CA證書了。或許支付寶認為沒有什麼別的機構有資格認證它的身份，那支付寶又有什麼資格認證其他機構的身份，認證Windows更新，認證驅動程序，認證文件加密？而這個CA證書，能做的遠遠不止這些。

或許你覺得我們應該信任支付寶，但是：

任何一個多餘的證書都是潛在的安全威脅。如果這個證書的私匙被泄露了怎麼辦？如果支付寶的這個證書被用於認證除了支付寶以外的其他網站怎麼辦？這一點直接否定了CA存在的意義：幫助用戶完成身份的審核。
對不起，我不信任一個會轉發我所有流量的互聯網公司。（詳見為什麼 Alipay 的安全插件要從 Windows 底層轉發幾乎所有 TCP 流量？ - 網路安全）

以上。

v1.2更新

使用VPN，使用無密碼WI-FI等均是截獲傳輸層數據，此問題等價於截獲所有傳輸層數據能否破解應用層加密。

HTTPS設計目的在於應用層的端對端加密，從設計目的上來講，HTTPS不受VPN、無密碼WIFI等不安全鏈路的影響，鏈路層只能截斷數據交互而不能破譯。

理論歸理論，實際歸實際。討論一下實際上有可能的攻擊方法。

將HTTPS強行降為HTTP，並利用SSLTRIP等進行中間人攻擊。目前可行的防範方法是使用HTTP Strict Transport Security，新版瀏覽器中均有https://hstspreload.appspot.com/，一定程度上可以防止這類攻擊。同時，HTTPS Everywhere也不失為一個好的方法。對於SSLTRIP只要細心一點很容易可以發現。
將加密協議降為舊版，如使用不安全的SSLv3協議等。此類攻擊一般在最新的客戶端中無效，各大瀏覽器都會禁用公開的不安全協議，但是不排除政府等有能力破解商業上未能完全破解的協議。
軟體實現的漏洞，包括軟體實現本身的漏洞，如心臟出血漏洞，和軟體實現密碼協議中不安全的漏洞，如隨機數可以被預測，RSA中使用相差不大的兩個素數，使用一個太小的素數，多組RSA密鑰公用n等，都可能導致通訊被完全破解。這種漏洞對個人而言沒有太好的防範方法，主要取決的服務商是否良好的配置了加密和軟體是否有良好的實現。
CDN與後端伺服器的不安全通訊。FBI曾經利用此方法攻擊Google的SSL加密通訊。這是一個值得重視的問題，由於很多CDN需要解密HTTPS通訊，導致此類攻擊具有現實意義。此類方法也只是取決於服務商的安全規範，與是否使用VPN無關。
證書信任鏈問題，BLUECOAT等專門用於監聽的證書可能會成功進行中間人攻擊。包括CNNIC和支付寶，各大銀行根證書都有嚴重的信任鏈問題。使用任何會添加根證書的軟體請使用虛擬機。測試Burp對所有現有HSTS包括Google、Wikipedia、Facebook都可以完美截獲，沒有任何異常提示，除非手動點開證書鏈，這個一般人都不會這麼做。針對信任根問題，新的解決方法是使用https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning，但是目前並沒有部署，Google主頁並沒有，Facebook主頁僅有Public-Key-Pins-Report-Only但是並沒有Pinning，需要等待大規模部署。

至於量子計算機，個人認為目前還不太可能實現。相反，尋找協議的不安全實現容易得多。

VPN更多是只是能截獲通訊，但是想要破解，如果你不是什麼重要人物的話，估計沒有人會這麼做。你只要保證破解的成本高於獲益，你就處於相對安全的地位了。

2016.06.02 00:45 v1.1
2016.06.02 13:36 v1.2

可以截獲。然而一堆密文，有個卵用

取決於HTTPS本身的證書是否安全。

之前做過中間人產品的過來答一波。

先回答題主所說的問題：VPN 供應商完全可以截獲任何通過該鏈路的數據流量（也可以說信息），但是是不是明文的這個就沒法下定論了。也就意味著，這時候拿到的 http 協議的數據是明文的，https 數據則全都是加密的，沒有對應 site 的私鑰是沒有辦法解密的（自行破解的暫不考慮）

那麼應當如何在沒有私鑰又不想破解證書的前提下拿到明文傳輸的數據呢？提供兩種方案：

第一，降級攻擊
這裡就用到了sslstrip，當然你也可以自己寫一個，python 用一些現成的庫就可以了，sslstrip 的作用主要是將可以降級的 https 站點降級為 http 協議，這樣流經的流量也就不再是加密了，截獲過程也就變成了 http 數據包的解析處理過程，做什麼也就隨意了（比如中間人掛馬、投毒，放個 js 放個馬等）。當然這時候就有人跳出來說 hsts 了，聽說 sslstrip 有個增強版產品，名字叫做 sslstrip+ ：）

第二，中間人證書偽造
我發現一直以來中間人證書的偽造一直不被重視，是因為某組織擅長用這種方式所以不能公開傳播怕出安全產品然後竊聽被阻止嗎？不懂。在 15 年左右，曾對市面上幾乎所有的主流瀏覽器做過一個調查，結果顯示，除了 IE、chrome、firefox 之外的瀏覽器會給出明確的虛假證書提示且主動阻止訪問外，其他瀏覽器均只是在不起眼的地方告訴用戶可能不安全，這對於不懂技術甚至不懂安全的人來說並沒什麼用。感興趣的同學可以自己生成一份證書插一下試試，可以寫個 python 自己抓一下流量，這裡推薦一個現成的工具：sslsplit，c 寫的，效率很高。

就寫到這。

雲舒說的，就是一個老掉牙的最經典最原始的中間人攻擊的場景。用http替換https。這個替換一點也不難，都有現成的工具，簡單的令人髮指，可能就是2條命令而已。先arpspoof 再sslsplit就可以，直接用ettercap也可以。所以雲舒那篇文章在安全人士看來一點意義都沒有，只是截了幾張簡單的不能再簡單的ettercap攻擊命令。

你的地址欄https都被換成http了，能安全么？雲舒偷換了概念吧。https本身是有能力應對這種攻擊的，看的是用戶的安全意識。
簡單的來幾點
1 網站啟用https，沒有啟用hsts，那麼可以直接將https改為http劫持
2 網站啟用hsts，則還需要更改url才行，這就是為什麼雲舒在後面的文章里將https://www.tencentpay.com改為了http://wwww.tencentpay.com，因為http://www.tencentpay.com瀏覽器會強制訪問https。

如果你的地址欄至始至終都是https，你電腦沒有信任不明的證書，在啟用了hsts的情況下(如果沒有啟用你可能會遭受一個叫cookie覆蓋的攻擊)，你是安全的。

順便提一點，https包是可以看到訪問去向的，只是內容看不到，所以用https並不能掩蓋你企圖訪問類似1024網站的事實。

談談個人看法：

任何安全的隧道，有一個前提，就是認證對方，通俗的說，就是A和B通信，A和B要認證彼此，保證真實身份，如果這一最重要的前提有問題，那接下來的隧道通信也就有問題，認證完成協商加密密鑰的DH演算法就會收到一個中間人C（刺客）的攻擊:

C欺騙A，自己是B，A信任C，於是DH演算法得到AC 之間的對稱加密的密鑰：AC

C欺騙B，說自己是A，B信任C，於是DH演算法得到BC之間的對稱加密的密鑰：BC

於是A發給B的數據，用AC密鑰加密，C用AC解密，得到明文，然後再用BC加密發送給B，B用BC解密，也得到明文。

返程的流量也是類似的操作，可以看出明文都被C看到了！所以問題的關鍵還是解決第一步認證問題，目前也只是用戶單方面認證伺服器的數字證書，但是如果強制伺服器也認證用戶電腦，那用戶電腦如果沒有數字證書則無法通信。這個安全難題只有等數字證書普及了才會解決。

使用標準協議和標準的客戶端的話，做不到
然而如果他們提供專用客戶端的話……

ssltrip我見的太多了，如果不上HSTS還是很恐怖的，上了HSTS之後基本消停了，除了一些老的瀏覽器，這也是為什麼我們還花了很多時間將sslv3和ie6、7和rc4幹掉了。。。反正你訪問http://www.taobao.com的時候，用VPN是沒問題的～～～要安裝VPN客戶端就算了，還是不要亂用了，給你搞個內置CA所有https（或者說所有TLS）都廢物了，即便你做了釘扎（HPKP）。

當然很遺憾的是在我走之前瀏覽器的preload list沒搞完，因為那個要求所有域名都做HSTS，這個太難了，外部太多的依賴，需要比較長的時間，搞SSLv3和IE6、7我們就花了快半年時間。
因為沒有進入preload list，所以在第一次訪問taobao的時候還是可以被ssltrip，不過只要有一次成功訪問https://www.taobao.com，HSTS寫入到瀏覽器裡面並且瀏覽器不清空的話就沒啥問題了。

…… 你問VPN提供商能不能截獲你的通信，就好像把錢放在問保險柜製造商製造的保險柜里，派來管理保險柜的也是保險柜製造商，你說他能不能自己配個鑰匙把你的錢摸走……

ssltrip…… 何必這樣大動干戈呢…… 完全是偏題了啊喂……

記住，面對一個黑箱你是沒有任何安全可言的/w

可以的，用量子計算機

看你用proxy還是用IPsec了。

如果是proxy，那麼proxy是代替你和伺服器交互的，你和伺服器間的所有https有可能被proxy隔成兩段：你和proxy間的https，proxy和伺服器間的https。proxy會假冒伺服器和你通信，假冒你和伺服器通信，你所有通信內容都在proxy看到明文。

怎麼實現的呢？很簡單，vpn要求你安裝軟體的時候，要求修改你的可信證書列表，然後伺服器就自己給自己簽名，冒充谷歌冒充微軟亞馬遜。

如果你和VPN間用的是IPsec，那麼就沒問題。相當於你和伺服器間先加密過，然後再和VPN伺服器間加密第二次。加解密第二次看到的也是密文，看不到明文。

所以，VPN的實現決定了能不能看到。

但是，但是，但是，非常需要提醒的，由於NAT的存在，大部分VPN提供的服務都是proxy的，不是IPsec的。雖然IPsec有穿透NAT的能力，但是一般不會這樣去做的。所以一般VPN都提供的是Proxy形式。

有沒有可能在NAT情況下去實現IPsec的VPN？可以。需要在家用路由器上去做軟體（固件）和配置。一般路由器不行（沒有許可權改軟體），一般小白不行（沒有能力去折騰路由器）。

所以還是小心點吧，尤其是使用了VPN去訪問網銀、支付之類的

答案: 不能，可以放心的上你的網站。
用VPN的人可以放心的用VPN,Https的請求只能看到IP地址，而不能看到網址和訪問的內容。這個是Https決定的。中間人攻擊是可以的，但是也是有成本和難度的，除非有人針對你。

如果特別需要安全保障可以用tor。但是世界上沒有絕對的安全只是看你的價值大不大。

我覺得可以，只不過截獲的是加密過後的密文，但是無法知道密鑰

完全可以，只是看到請求頭的話非常簡單，但是不清楚題主想要的結果是什麼。——

我現在玩的某手游用的https協議，不想用力肝，自己簽發個證書中間人隨便搞。

偉大防火牆旁路那一套聽說也能看到內容。

確切來說，可以截獲，但不能解密。如果哪天你打開12306，沒有看到熟悉的小紅叉，也沒有綠色的小鎖，你就應該考慮是不是以後不要再用這家的VPN了

數據從他那過，至於想要解密，只是成本問題。

可以截獲一堆密文，然而沒辦法解密。

SSL的安全性是基於兩點：
1 密鑰交換演算法，保證的是「A告訴B通信用的密鑰」這個行為的安全性，即使任何第三方截取到完整的報文，也沒法推算出所傳輸密鑰。
2 對稱加密演算法。保證的是「A和B進行通信」這個行為的安全性，這個安全性的前提是只有A和B知道通信用的密鑰。顯然，如果這個對稱加密演算法是安全的，第二點的安全性完全是由1來保證。

所以答案是：能截獲HTTPS信息，但是拿不到信息的明文。
至於VPN要攻擊你，那就是另一回事了。

若想了解的是Https中間人攻擊漏洞問題，可以一起交流下https://zhuanlan.zhihu.com/p/22426761