wireshark能否嗅探https鏈接中的用戶名和口令？

12-30

如果不能，有沒有其他方法可以實現

如果你是要抓取本機上的流量的話，是可以嗅探的

Starting with Wireshark 2.0, the RSA key file is automatically matched against the public key as found in the Certificate handshake message. Before Wireshark 2.0, it relied on the user to enter a valid Address and Port value. Note that only RSA key exchanges can be decrypted using this RSA private key, Diffie-Hellman key exchanges cannot be decrypted using a RSA key file! (See "SSLKEYLOGFILE" if you have such a capture.)

具體方法在這裡：https://wiki.wireshark.org/SSL#SSL_dissection_in_Wireshark，本人能力有限就不翻譯了。題主可以自己研究一下或者是看 @屈光宇菊苣總結的文章：三種解密 HTTPS 流量的方法介紹
但是，MITM 是不可以做到的（當然，你有網站的私鑰另說）

(以下內容有部分刪減，語句可能不通)

如果實在要說，所有 HTTPS 網站的證書公鑰都是公開的，這要從 HTTPS 的原理說起，這裡就不細說了。但是僅擁有公鑰是絕對不可能解密 HTTPS 流量的。

該答主舉的例子 openssl 官網使用的確實是免費證書 Let"s Encrypt, 但是免費證書並不代表就可以解密，這個邏輯是完全錯誤的！至於為什麼，這同樣涉及 HTTPS 的原理，我承認我知識水平還是不夠，還到不了能夠自建語言複述一遍原理不出錯的級別，所以想深究的建議自行查詢 Wikipedia。

爆破更加是不可能的

現在的密鑰交換 + 簽名有三種主流選擇：

RSA 密鑰交換（無需數字簽名）；
ECDHE 密鑰交換、RSA 數字簽名；
ECDHE 密鑰交換、ECDSA 數字簽名；

無論是哪一種演算法都是基於數學理論證明以現在的運算能力基本無法破解的（比較短的 RSA 現在已經可以解密了，但是主流的 2048 bit 在短期仍然無法爆破），這是超算都爆破不出來的東西……我實在無法想像一台個人計算機要怎麼爆破出來。要是這個程序真能做到那密碼學和互聯網界可能要炸鍋了

就做了一點微小的工作，很慚愧。

理論上來說不能，理由是 SSL 協議的原理。這裡先給 @車小胖點個贊同。

SSL 協議的用途，或者說根本目的是為了加密流量，使之不被第三方竊取或者是偽造。為了達成這一目的，就需要對數據流進行加密（廢話）。在對稱加密演算法中，保證數據安全性的唯一方法是，保證密鑰的安全性和保密性。因此，SSL 協議中，要涉及到這個密鑰的生成的有關內容，並保證起可靠性。

SSL 協議是通過非對稱密碼體系來安全地生成這把密鑰的。以 RSA 握手為例，我們來看 SSL 握手的過程（圖片摘自 Keyless SSL: The Nitty Gritty Technical Details）：

這個圖片很清晰地介紹了 SSL 握手的過程，我就不贅述了。看這個圖片的時候要記住這一點：用公鑰加密的數據只能用私鑰解密。

假設現在，伺服器和客戶端之間的所有通信，被 wireshark 截獲了。我們手頭收集到了這些信息：

Client Random
Server Random
Server 的 Public Key
用 Server 的 Public Key 加密的 Premaster secret

於是，要想得出 Session Key，需要知道 Premaster secret, Client Random 和 Server Random。後兩者我們是知道的，問題就出在第一個上：我們手頭只有加密過的 Premaster secret，要想獲取 Premaster secret，必須要使用伺服器的私鑰來解密，而伺服器的私鑰是嚴密地存儲在伺服器上的，因此無法恢復 Session Key，也就無法解密流量了。

～～～～～～～～～～～分割線～～～～～～～～～～

通過上面的分析，我們知道了，理論上，SSL 鏈接是不能被第三方解密的。但是，有的時候，我們可以從別的地方下手，從而達到解密流量的目的。

方法一：在 Wireshark 中直接導入 Session Key。

這個方法是最直接的。這個 Session Key 是哪裡來的呢？部分瀏覽器為了方便開發者調試，在開啟特定的選項的時候，可以導出 Session Key。這個時候，就可以利用它解密流量了。

然而然而然而（重說三），導出 Session Key 的動作顯然是瀏覽器的使用者主動的操作，因此，該方法不會影響 SSL 的安全性。這種方法顯然不適用於在鏈路中間做竊聽。

方法二：SSL Strip 攻擊·。

這種攻擊方法的思路是：SSL 雖然很強大，不易攻擊，但是我可以用特殊的辦法，使得流量不走 SSL 加密，這樣一來流量就是明文的了，竊取就易如反掌了。

這種攻擊方法，要求攻擊者能夠篡改你和伺服器之間的通信數據。假設沒有攻擊者時，你訪問 http://example.com/ 時，這個網站發現你沒有使用 https 加密，於是自動返回一個 302 跳轉，跳到 https://example.com/。這本來是比較安全的一種做法。然而，當有攻擊者劫持通信數據的時候，它可以不讓你跳轉到 https 的頁面上（注意，http 協議沒有加密，可以任意監聽和篡改），卻把 https://example.com/ 的內容一模一樣的通過 http 協議返回給你，而你通過 http 發送的請求，攻擊者加密後再發給伺服器。這個時候，你的瀏覽器里看起來就是一個正常的網站；此時，攻擊者監聽明文數據就易如反掌了。

這種攻擊方法的對策還是非常簡單的，就是：直接訪問 https://example.com/ 即可。為了避免這種攻擊，還有 hsts 等技術隨之而來。

方法三：SSL 降級攻擊

這種攻擊方法是，攻擊者通過篡改伺服器和客戶端開始的「Hello」數據，使得雙方誤以為對方不支持強壯的加密演算法或較高的協議版本。這樣一來，雙方以低版本的協議或者較弱的加密演算法建立 SSL 鏈接。而此時，攻擊者就可以趁虛而入。

防範方法也非常簡單，目前多數瀏覽器和伺服器軟體都已經強制關閉了對較弱的加密演算法和低版本協議的支持。因此，這種方法得逞的概率還是不高。

方法四：中間人攻擊

這種攻擊方法，主要攻擊的對象是，剛才的圖中的「Public key Certificate」。攻擊者自己生成一對公私鑰，冒充伺服器與客戶端建立連接。這樣一來，客戶端發送的加密過的 Premaster secret 也就可以用攻擊者的私鑰解密，從而得出 Session Key。此時，攻擊者需要做的就是再與真實的伺服器建立另一個 SSL 鏈接，把客戶端發過來的加密的數據，用 Session Key 解密後，再重新加密後發給服務端，服務端發過來的加密數據解密後，也用這個 Session Key 加密，發給客戶端。這樣看上去，客戶端是在與伺服器進行正常的通信，殊不知，流量已經全部都被攻擊者截獲。

這種方法之所以能成功，是因為客戶端錯誤地相信了攻擊者的公鑰，誤以為攻擊者的公鑰是伺服器的公鑰。然而實際上，通常的伺服器的公鑰是被一個權威的第三方（CA）進行驗證的。經過 CA 簽名驗證的伺服器的公鑰，連帶著一些附加信息，稱作「證書」。證書上包括的信息，有這麼幾樣是非常重要的：伺服器的公鑰、伺服器的名稱（通常是域名）、有效期起止時間。而 CA 驗證這些信息的真實性後，會使用CA自己的私鑰將上述信息的散列值加密，附在上述信息的後面（稱作數字簽名）。

而瀏覽器收到證書以後，會首先使用 CA 的公鑰將簽名數據解密，然後重新計算證書信息的散列值，並將二者比較。如果一致，則證明證書是完好的。然後再對證書上的各個信息進行核驗（比如域名對不對，是不是在有效期內等），核驗通過後才會相信證書上的公鑰。

因此，攻擊者由於不掌握 CA 的私鑰，不能對篡改的證書的散列值進行加密，也就不可能偽造數字簽名，自然也就逃不過瀏覽器的「火眼金睛」。此時，客戶端瀏覽器上會彈出一個警告框，提示這個證書不可信。這個時候，注意注意注意（重說三）：不要點擊信任按鈕，如果你點擊了信任按鈕，瀏覽器就會信任攻擊者的公鑰，攻擊者的竊聽就得逞了。這個時候，直接關掉瀏覽器即可保證你信息的安全性。

有的軟體，例如之前有人提到過的 burpsuit，就可以實施這種攻擊。當然，自己調試瀏覽器通信的時候，可以「自己騙自己」一下，選擇相信 burpsuit 偽造的證書，從而在 burpsuit 中獲得解密後的流量數據，以便分析。如果拿來騙別人，你就得讓受害者選擇相信你偽造的證書，這個就超出技術的範圍了。

～～～～～～～～～～～～～

有人可能會疑惑，瀏覽器是怎麼知道 CA 的公鑰的呢？事實上，CA 的公鑰是預先通過可靠的途徑（如安裝操作系統）內置在瀏覽器內部的。瀏覽器對 CA 的信任是無條件的，因此，CA 的責任重大，在核發證書的時候要對申請者的信息進行核實。至於 CA 會不會給攻擊者簽發證書，一般來說，靠譜的 CA 是不會的。如果有 CA 膽敢這麼做，一旦被發現，瀏覽器廠商會通過系統更新等形式，去掉對該 CA 的信任。而 CA 一旦不被信任，就不會有人找他簽證書，CA 也就會因此而破產。

說到根本上，網路的安全不僅僅是要靠密碼學手段來保證（在此向密碼學前輩致敬），還需要依靠社會學方法。而後者，往往才是最容易出現問題的。

誰在這裡做大頭夢？醒醒啦，蘇州站到了，下車的旅客請下車…

鄭重宣布：Wireshark 沒有session key ，不能解密SSL數據流！

在SSL會話中，客戶端通過數字證書認證伺服器的合法性（真正要訪問的伺服器），網路安全里的術語：認證！

認證完成，雙方會運行 Diffie Hellman 演算法，簡稱 DH演算法。通俗地說：雙方會協商一個master-key，這個master-key 不會在網路上傳輸、交換，它們獨立計算出來的，其值是相同的，只有它們自己雙方知道，任何第三方不會知道，俗稱的天不知，地不知，你知，我知。

然後以master-key推導出 session-key，用於雙方SSL數據流的加密/解密，採用對稱加密，保證數據不被偷窺，加密演算法一般用AES。

以master-key推導出 hash-key，用於數據完整性檢查（Integrity Check Verification）的加密密鑰，HASH演算法一般有：MD5、SHA，通俗滴說，保證數據不被篡改。

然後雙方就依靠上文session-key , hash-key 進行數據交換，沒有這些key，想解密數據，做夢！

瀉藥

它會抓取流量數據，但不會明文顯示。

因為https跟http不同 https採用了ssl加密

但並不是任何手段都是絕對安全的，你可以破壞掉客戶端與server端的ssl通訊實行gank...

比如

用sslstrip就是個很好的選擇，原理相當於arp欺騙，你做了個代理。

好吧開了個坑專門研究懟HTTPS,還希望 @車小胖大大多提意見啊

知乎專欄

=====================再次分割線=====================

實名反對 @車小胖

將有可能涉及人身攻擊的段落刪除

抓包的是WinPCAP，準確的說是內核上的NDFS過濾驅動

而Wireshark作為前端是一個協議的分析工具

在設置SSLKEYLOGFILE之後，瀏覽器會保存每次SSL的加密key，而ws作為分析工具為何不能解開呢？

請看火狐的官方文檔

Key logs can be written by NSS so that external programs can decrypt TLS connections. Wireshark 1.6.0 and above can use these log files to decrypt packets.

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

此處分割線

先給答案:

本機流量可以，遠程流量理論上不可以，注意是理論上

因為聽說某些實驗室已經在搞黑科技了，不過應該也是變形的中間人攻擊…

本機的話簡直太簡單了，說個通用的

設置一下SSLKEYLOGFILE環境變數，然後打開大鯊魚，是不是所有的流量都能看到了？

區域網環境的話也可以通過某些漏洞，在遠程機器上安裝虛假證書，然後進行中間人攻擊，照樣可以解密流量

公網上也不是不可以，我們偉大的防火牆不就是這麼搞得么(手動滑稽

來說說防範吧…最簡單的就是啟用兩個安全協議:HTTP嚴格傳輸安全和公鑰打孔，並且加入pre-load列表，再加上一些防護header就行…有時間我把我們伺服器的配置傳上來

Diffie和Hellman今年剛拿了圖靈獎，手還沒捂熱呢，題主就想破了人家的成果(的衍生成果)…

有人提到sslstrip，那隻能算繞過https，而且基本上稍微有點計算機網路常識的人都不會上當，當然騙騙沒裝360之類軟體的小白也是可以的

還有人提到拿到證書，公鑰就能破解，更是滑天下之大稽，這些人估計連公鑰密碼學是啥都不懂…

如果能和https硬杠的話，明年圖靈獎非你莫屬了

瀉藥

Wireshark是可以嗅探一些情況下的https的

但Fd和burpsuite是可以的解密一些情況下的https的

其他嗅探ssl的方法可以百度搜索下https 嗅探

11-9號更新

首先我承認我語文不好沒表述清楚引起了很多誤會

這個@5on1r朋友的回答表達了一些我想說的話.

也就是burpsuite監測https的方法請移步他的答案wireshark能否嗅探https鏈接中的用戶名和口令？ — 5on1r 的回答 - 知乎

http://www.zhihu.com/question/52261727/answer/130335672

相關的還有一些強制降級的手段也可以在mitm的時候嗅探到https明文這個不是我提出的 freebuf上有很多詳細文章

其次我想評論下一樓這個

我仔細讀了一遍你的回復又簡單看了一下你的資料發現，你沒資格評論我對網路安全有沒有基礎，可能你沒見過我的id，也沒看過我以前寫過的任何工具和技術文章，這些我不怪你我本來就是個小人物，但一次表述錯誤不代表就可以評論一個人的技術水平高低，本來想和你交個朋友，一起私底下交流下，甚至可以讓你來我公司，一個月10k都是小數目。

我不想反覆證明我的技術水平怎麼樣，也不想裝太多b，只是曾經給中國銀行做過ATM出廠安全測試，目前公司也在給吉林省gov機構做大量的安全服務，如果gov都能承認我的水平而你不能，你也太強了.

另外還有很多人仗著自己有點影響力，就在這裡回復一些抖機靈的話，不切入重點不回復技術只是在扯淡，我只能說你太年輕.

11-11日更新

本來我以為這個問題已經結束了，沒想到今天還有這麼多人更新.

但看到這麼多人都在自以為是，我真為知乎感到捉急.

首先我想問問你們，既然你們說「如果https可以被解密，還要https幹嘛？」

我就想問問你們了，安全軟體可以被繞過，還要安全軟體幹嘛？

軟體加殼可以被破解，還要加殼幹嘛？

車鎖可以被撬開，乾脆汽車廠商都不設計鎖得了唄？

你們根本不知道什麼叫攻防！

小人物總以為自己站在地球頂端看世界.

我也公開反對@車小胖你居然敢說，Wireshark絕對不能破解https？

這種話你也敢說？我一看你就不是做安全的，不懂裝懂，沒有絕對的安全.

我就不拿樓上這幾個朋友說的本機嗅探方法來說你了，

你自己看下百度，光公開資料就有這麼多，你居然敢說絕對不行？

不知道你有沒有去過谷歌安全部門，甚至加拿大皇家騎警網路部門參觀過.他們的網路嗅探工具，只要電腦接入某個網路，不管你是ssl還是什麼鬼東西，一個按鈕就可以嗅探.

破解https的用途無非兩種，一種是本機分析數據包一種是網路中間人分析數據包.

這兩種在很多公司都是半公開的簡單黑科技，我可以告訴那些說https如果能被破解還要https幹嘛的人們，你們太年輕！

第一種本機嗅探前面幾位朋友已經說得很透徹了，對於中間人嗅探

https六年前就可以被中間人嗅探了，國內四年前也有了 http://www.freebuf.com/articles/web/5929.html

你們還想怎麼說？除了sslstrip強制降級的文章freebuf也有.

如果你們還不信現在隨便打開一個ssl網站打開最新版burpsuite看看.

無知不是你不被噴的理由.

本來不想理你現在看看你在這吐臟拉黑人就可想而知你的身份和素質了.一個人如果只能承受讚許承受不了批評，這人也做不了什麼大事.

你回復我「撒野也有資本」雖然我沒看懂你這六個字到底什麼意思，可能你沒上過大學語文吧，我不怪你.

不過我肯定比你有資本.@車小胖

虧你還有不少粉絲.@hunter niu我想問問這個車小狗還有你的粉絲敢不敢不刪我的評論？敢不敢不拉黑我？連和人辯論的勇氣都沒有？？

我在你評論地下有理有據的反駁你，你直接給我刪掉然後跟你的粉絲說我狗急跳牆？到底是誰不能自圓其說？

在客戶端抓wireshark的包是可以解ssl的。用firefox和chrome，添加環境變數SSLKEYLOGFILE並將其指定到某個文本文件後，firefox和chrome就會往這個文件里寫入https連接使用的私鑰，wireshark可以配置該文件為pre-master-secret-log之後就可以解ssl的包了。

但是，如果使用dhe、ecdhe加密的話，這就不管用了。但既然在客戶端，我們可以把dhe、ecdhe禁用，這樣就fallback到可以解密的加密演算法了。具體步驟可以看：http://joji.me/zh-cn/blog/walkthrough-decrypt-ssl-tls-traffic-https-and-http2-in-wireshark

另外fiddler解https是通過了fiddler自己的證書，fiddler其實只是一個代理而已。

=================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
HTTP/Requests:
Topic / Item Count Average Min val Max val Rate (ms) Percent Burst rate Burst start
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
HTTP Requests by HTTP Host 91 0.0013 100% 0.1000 14.265
192.168.2.66 38 0.0005 41.76% 0.0300 27.023
/?code=2asyn=1id=qCa%3EI201~*%5EZGf0b 23 0.0003 60.53% 0.0100 27.055
/?code=2asyn=1id=hlr%2BLW%082OyG78wO3 14 0.0002 36.84% 0.0100 1.024
/?code=7asyn=0id=qCa%3EI201~*%5EZGf0b 1 0.0000 2.63% 0.0100 27.043
239.255.255.250:1900 35 0.0005 38.46% 0.1000 14.265
* 35 0.0005 100.00% 0.1000 14.265
http://www.baidu.com 8 0.0001 8.79% 0.0100 8.835
/ 8 0.0001 100.00% 0.0100 8.835
http://ct02.mg.lightonus.com:32013 4 0.0001 4.40% 0.0100 11.470
/tracker?id=8a455614d13b8e4c7e7a8b1f66fe2719ed28bb7d8489e52924c8840bffff478at=1497265697635an=10ch=r201504230000-mango-MangoCDN-HNDSMPP360.flv-std%7Cct00.mg.lightonus.com%3A2054msg=htbtav=0isLive=truemac=1328336305rv=1 1 0.0000 25.00% 0.0100 51.447
/tracker?id=8a455614d13b8e4c7e7a8b1f66fe2719ed28bb7d8489e52924c8840bffff478at=1497265677635an=10ch=r201504230000-mango-MangoCDN-HNDSMPP360.flv-std%7Cct00.mg.lightonus.com%3A2054msg=htbtav=0isLive=truemac=824473689rv=1 1 0.0000 25.00% 0.0100 31.448
/tracker?id=8a455614d13b8e4c7e7a8b1f66fe2719ed28bb7d8489e52924c8840bffff478at=1497265671745an=10ch=r201504230000-mango-MangoCDN-HNDSMPP360.flv-std%7Cct00.mg.lightonus.com%3A2054msg=rqstpeerav=0isLive=truemac=1030862429rv=1 1 0.0000 25.00% 0.0100 25.565
/tracker?id=8a455614d13b8e4c7e7a8b1f66fe2719ed28bb7d8489e52924c8840bffff478at=1497265657635an=10ch=r201504230000-mango-MangoCDN-HNDSMPP360.flv-std%7Cct00.mg.lightonus.com%3A2054msg=htbtav=0isLive=truemac=62701985rv=1 1 0.0000 25.00% 0.0100 11.470
http://ct02.mg.lightonus.com:80 3 0.0000 3.30% 0.0100 5.100
/log.html?c=mangov=1195938831 3 0.0000 100.00% 0.0100 5.100
http://zhushou.huihui.cn 1 0.0000 1.10% 0.0100 0.000
/api/hui/share.json?channel=baicai~share 1 0.0000 100.00% 0.0100 0.000
http://log.event.hunantv.com 1 0.0000 1.10% 0.0100 15.838
/dispatcher.do?uuid=suuid=71812BF5-B868-C228-2FCE-2A83FBFA906Dguid=bid=1.1.1.1cookie=ct=et=td=idx=3pt=1ln=%E6%B9%96%E5%8D%97%E9%83%BD%E5%B8%82pay=0ap=1lid=1806def=1pver=WIN%2021,0,0,213cver=Mgtv_Live_V5.0.10liveid=346activeid=platform=0pstatus=playact=heartbeatch=sessionid=fid=A8705805-CE9A-697C-96F1-8485344DC17Eistry=0time=20170612191307preliveid=prelid=uvip=0ref=url=http%3A%2F%2Fplayer.hunantv.com%2Fmgtv_v5_live%2Flive.swf%3Fchannel_id%3D346 1 0.0000 100.00% 0.0100 15.838
192.168.2.66:1900 1 0.0000 1.10% 0.0100 16.203
/igd.xml 1 0.0000 100.00% 0.0100 16.203

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

居然有說拿到證書可以解密https流量的，也是醉了。

如果我沒記錯fiddler,burpsuite都可以

按我的理解：假如通信雙方靠譜的話，你就只有一個辦法：拿到伺服器的加密私鑰；假如雙方特別靠譜的話，你就得同時拿到伺服器和客戶端兩邊的私鑰。只要拿到私鑰，兩邊的協商過程對你來說都是透明的，沒有任何秘密可言，你只要不錯過開頭協商部分就好了。

假如雙方不是那麼的靠譜，就像在現實世界中偶爾發生的那樣，你可以先使用各種手段誘導HTTPS的加密級別降級到可以攻破的地步，然後開始各種手段。

以上需要耐心。

ssl這玩意現在來說是不可能解密出來的，你要問我如何看到經過ssl加密過的http數據？

也不是沒有辦法，因為ssl這個安全套接層就像是一個安全套套在http協議上的。

你可以使用sslstrip把這個安全套剝離下來，這樣就可以看到http的明文數據了。

但注意，並不是把ssl解密了...

------------------------------------------------------

修改一波，還有一種方式，可能是ziwen所說的。

bp導入自生成的證書，並且導入根域且信任，這樣你在訪問https的網站時，抓包就可以看到https協議並且修改內容。

其實bp導入自生成的證書的行為其實是「自己劫持自己」。

雙向認證 SSL 協議的具體過程
① 瀏覽器發送一個連接請求給安全伺服器。
② 伺服器將自己的證書，以及同證書相關的信息發送給客戶瀏覽器。
③ 客戶瀏覽器檢查伺服器送過來的證書是否是由自己信賴的 CA 中心所簽發的。如果是，就繼續執行協議；如果不是，客戶瀏覽器就給客戶一個警告消息：警告客戶這個證書不是可以信賴的，詢問客戶是否需要繼續。
④ 接著客戶瀏覽器比較證書里的消息，例如域名和公鑰，與伺服器剛剛發送的相關消息是否一致，如果是一致的，客戶瀏覽器認可這個伺服器的合法身份。
⑤ 伺服器要求客戶發送客戶自己的證書。收到後，伺服器驗證客戶的證書，如果沒有通過驗證，拒絕連接；如果通過驗證，伺服器獲得用戶的公鑰。
⑥ 客戶瀏覽器告訴伺服器自己所能夠支持的通訊對稱密碼方案。
⑦ 伺服器從客戶發送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密後通知瀏覽器。
⑧ 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接著用伺服器的公鑰加過密後發送給伺服器。
⑨ 伺服器接收到瀏覽器送過來的消息，用自己的私鑰解密，獲得通話密鑰。
⑩ 伺服器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱密鑰是加過密的。
單向認證 SSL 協議不需要客戶擁有 CA
證書，具體的過程相對於上面的步驟，只需將伺服器端驗證客戶證書的過程去掉，以及在協商對稱密碼方案，對稱通話密鑰時，伺服器發送給客戶的是沒有加過密的（這並不影響
SSL 過程的安全性）密碼方案。
這樣，雙方具體的通訊內容，就是加過密的數據，如果有第三方攻擊，獲得的只是加密的數據，第三方要獲得有用的信息，就需要對加密的數據進行解密，這時候的安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強調要求使用
128 位加密通訊的原因。

如果可以，為什麼還要叫http"s"

喜聞樂見，這個問題把不少裝逼犯都炸回原形了！貴乎網路方面真是……我覺得連985（除東南大學外）的研究生都比你們不知道高到哪裡去了！說話狂的，好像自己多牛逼似的

說完全不可能的你們真敢說。

我就問你一個：為什麼大家倡導不要把sslv3協議作為https的版本協議？不就是因為不安全么！不就是因為會被解密么！設計結構沒問題不代表實現方式沒漏洞。

關於我的依據，

大家可以移步看我這篇文章，http://zhuanlan.zhihu.com/p/22917510

如果你實在不相信可以參考我文章裡面最後的延伸鏈接。

https攻擊相關的，關鍵：不使用key解密你們覺得不可能解密的數據包。

如果還不相信，隨意。

能嗅探裡面的數據，就是不能解密，除非證書被偷了，當然還有其他方法獲取其中的數據

使用 HTTPS 的網站也能被黑客監聽到數據嗎？ - 網路安全

相對來說，去用戶機的進程里抓數據是一個很好的方案，中間人抓ssl通道傳輸的數據？那是不可能的

https，更確切的說是ssl，你要知道它的原理就不會問這個問題。

所以答案就是簡單粗暴的兩個字: 不能

另外反對對某些提到搞到證書就可以解密的回答，請問你知道什麼是非對稱加密嗎？證書那玩意兒是公開的，誰都可以下載，如果把解密門檻設在這裡，那設計和使用這種加密技術的工程師可真是low到爆了

同樓上說的只能抓到流量數據。如果能嗅探到要ssl證書有何用。如果可以搞到證書的話倒是可以

你可以問下NSA，聽說他們可以破解1024位密玥了