為什麼 2015 年底各大網站都紛紛用起了 HTTPS？

12-28

百度、京東甚至知乎。
本來雖然不合理，然而已經習慣了只有支付寶、谷歌之類是 https.
突然廣泛地如此，總該是有些原因的。

（點贊的人還不少，那我再多寫寫吧，更多戲說互聯網的回答，請到我的主頁何明科）

使用https的潮流應該是Google開創的，最初是為了安全性，同時會優先收錄和展示https的頁面，於是就推動整個行業都在往https轉換。畢竟Google是最大的流量入口，而且大家也好歹有點技術追求。

不過，上面說的只是國外的情況。國內的互聯網公司可不是靠Google吃飯的，而是靠百度。而百度也是從2015年初才開始全面使用https協議。但百度及各大互聯網公司為啥要選擇https這種成本更高且技術更複雜的方案呢？

一、多麼痛的領悟
答案很簡單：防止自家的App及網頁被運營上劫持，被運營商「強行插入」（此處有馬賽克）廣告甚至是競爭對手的廣告。屍檢現場如下。

在58同城開心得看著二手物品準備省錢：銀行的廣告彈出來了，還要送酒店！嚇死寶寶了，幸好老婆不在身邊，不然還以為我去哪裡開過房，被運營商精準推薦呢。

在微信裡面看公眾號的文章：移動的廣告彈出來了，親，續話費還是玩遊戲？

在大眾點評裡面流著口水找餐館：優酷的廣告彈出來了。好險好險，幸好彈得不是迅雷雲播，這點小愛好全被你發現了。

在58同城開始給新年找一份好工作：移動跑出來要給我送健康大禮包，難道演算法判斷我腎虛，這可讓我怎麼找到工作？

有些網友說上面都是移動端的，沒有PC頁面的，那補充一個

二、該怎麼去領悟
面對這樣赤裸裸的挑釁，自己底盤被搶、收入被劫，還有王法嗎？

互聯網公司一般會有如下的處理方式。要麼祭出自家產品直接開始撕逼，參考3Q大戰，你家上外掛黑我，我就直接全球彈窗「一個艱難的決定」然後封殺。搖人兒弄你，參考樂視和騰訊的一貫做法。但是這次的對手是神一樣的運營商。它只需要輕描淡寫得說一句：還有誰，敢怎麼樣？

說到這裡，就要跳出來說一下，什麼是運營商劫持。一般來說，運營商劫持有兩種：

第一類是域名劫持或者污染DNS，目標域名會被惡意地錯誤解析到其他IP地址，顯示劫持者自己制定的廣告內容或者直接造成用戶無法正常使用服務
第二類是數據劫持，對於返回的內容會在其中強行插入彈窗或嵌入式廣告等其他內容，達到做廣告的目的。更噁心的是，訪問京東給用戶呈現淘寶的廣告等等

一般來說，各家互聯網公司遭遇到的運營商劫持都是第二種。技術原理大致如下：

通過劫持HTTP來實現，在用戶與其目標網路服務所建立的專用數據通道中，監視數據信息，根據各種大數據技術和用戶畫像的匹配（不好意思，我實在編不下去了，實際上就是想插入你的時候而已），就會在目標伺服器返回的數據流中插入廣告的網路數據報文。最後的結果是，用戶端程序（無論PC端還是移動端的網頁或者客戶端，只要是使用HTTP傳遞的數據）解釋「被xx過的數據」，並以彈出廣告的新窗口，然後徹底污染了原有頁面。

為了防止這種劫持，各大互聯網公司只好選擇HTTPS，進行數據加密而防止數據被篡改加入廣告。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

感覺自己沒有說人話，用形象的比喻再說一次吧。

互聯網公司好比淘寶商家，運營商好比快遞公司，用戶好比需要剁手的買家。而且快遞公司還是壟斷的，全國沒幾家可以選擇。

以前用http協議的時候，等於互聯網公司給用戶寄貨，但隨便選個包裝然後讓運營商配送給用戶。運營商公司為了自己的利益，把包裝拆開，在裡面塞滿了各種廣告。甚至有可能，用戶就買本書，結果包裝里被運營商塞了整整一箱傳單或者小卡片送了過去。甚至可能是下面的這種卡片。

現在開始使用https協議了，互聯網公司給用戶寄貨，不過這次選了一個保險箱給與用戶寄貨，開箱密碼通過另外的渠道告訴用戶，然後讓運營商給用戶配送過去。雖然這樣成本高了很多，但是終於安全了。

三、為什麼到現在才領悟
運營商劫持由來已久，在2011年就回答過類似的問題（使用 Chrome 時為什麼右下角會出現廣告彈窗，怎麼來的？ - 何明科的回答）。可是為什麼這麼多實力雄厚的互聯網到2015年12月底才開始領悟呢？這主要是之前運營商做這些事情都是偷偷摸摸，各大互聯網公司被偶爾揩油一把也就算了，還不急叫別人就停手了。可是到了2015年下半年，各大運營商聯合發力且摘下了最後的遮羞布，從揩油升級到肆無忌憚的「強行插入」，各大互聯網公司同時中招，於是同時呼喊「非禮」。

下圖的百度新聞搜索顯示，從2015年12月開始，運營上劫持進入了密集期，新聞不斷。

下圖的百度指數的需求圖譜也顯示，從2015年12月28日-2016年1月3日這一周開始，「運營商」這個關鍵詞開始與「劫持」這個關鍵詞呈現較強的相關性，而且搜索趨勢一致在增加，這在之前是沒有發生過的現象。

根據上述兩個百度的數據產品可以看到，運營商劫持恰恰密集發生在2015年12月底，於是各大互聯網公司不能忍受了，紛紛轉投https。—————————————————————————————————————
更多文章及分享請關注我的專欄，數據冰山：http://zhuanlan.zhihu.com/hemingke

其實最近我也在某網站的開發組內討論應用全站https事宜。
其原因非常簡單。

因為不斷接到用戶投訴說網站上出現影響瀏覽體驗的大面積廣告。
可是網站平常只針對未登錄用戶在頂欄和底欄打兩小條廣告。而且這種露骨的廣告。。。。。。

一看就是當地運營商乾的。
強行劫持用戶瀏覽，往裡面插入自己的廣告。
運營商都是大爺，我們不敢惹，以往都是默默忍著，安撫用戶說這不是我們投放的廣告。引導用戶清緩存刷新之類的。

應該說積累了這麼多年，運營商也不斷變本加厲，從原來的右下角小廣告到了覆蓋頁面的全屏廣告。大家終於在2015年開始爆發了。我上次在群里聊起這個問題，大家一看換https的價格（證書、加密時的多餘計算能力）居然已經低到完全可以接受了，而且還能獲得一些多餘的好處，比如增強穿牆性能什麼的。

於是大家一合計，開干吧。然後就默默的開始做整站遷移至https的工作。

應該說，使用https成本的下降，尤其是計算成本的下降是2015年https爆發的主要原因，當然這和幾個CA紛紛推出超低價證書甚至是免費證書也是分不開的。
不過最終導致大家下定決心更換https的導火索就是運營商劫持流量投放廣告了。

而且隨著計算價格的不斷下降，https因為加密產生的性能消耗正在被人們逐漸忽略。相反https帶來的安全性正在被人們逐漸重視。
在未來的幾年內，會有越來越多的網站啟用https。

阿里雲厲不厲害？

有個屌用
微軟厲不厲害？

有個屌用
中移動厲不厲害？

有個屌用
CNNIC厲不厲害？

有個屌用
國家電網厲不厲害？

有個屌用
「微軟辣雞，上個網都會中毒」

哪義務！
-----------------------
杭州電信用戶，現在已經分不清哪些廣告是網站自帶的，哪些廣告是電信插的了……

今日頭條、小米、騰訊等六公司聯合抵制流量劫持已有多項證據直接指向某些機構

Https背後的法律邏輯

一、HTTPS 現象

2015-2016年，互聯網領域的HTTPS現象簡直可以以風起雲湧來形容，大到GOOGEL這類互聯網巨頭，小到小米科技此類後起之秀都談論著HTTPS現象，而在這種談論中，有的直接掛鉤HTTPS而有的僅是掛靠上HTTPS。

這種HTTPS現象的大事件包括：Google正在推動整個互聯網由HTTP協議往HTTPS協議過渡並打算給那些沒有起用HTTPS的網站標識「不安全」標籤，百度在2015年3月份開始全站強制啟用https連接，同年10月14日的杭州雲棲大會上，阿里巴巴宣布旗下電商平台已實現全站https。而在這類事件中，最為著名的事件是在2015年的聖誕節，國內六家互聯網公司（今日頭條、美團大眾點評網、360、騰訊、微博、小米科技）發布了聯合聲明，控訴「有關機構」的流量劫持問題，聲淚俱下。

二、HTTPS的通俗理解

筆者是律師，不是IT技術員，不敢班門弄斧解釋物理現象，所以，關於什麼是HTTPS，只好通俗演義。講到HTTPS，就必需先講HTTP,其中文名稱是超文本傳輸協議，用白話講就是將伺服器信息傳輸到客戶終端（電腦、手機、IPAD）必須遵守的互聯網界協議，而HTTPS實際上是由HTTP+SSL（Secure Socket Layer）而構成。以往我們上網時，在伺服器和客戶終端上的信息都是明文傳輸而沒有加密的，所以黑客想要獲取你的信息，通過截取網路傳輸內容且不用破譯就可以獲得，而在加入SSL之後，文本傳輸的內容都進行了加密，信息的來源都進行了身份的認證。

再通俗一點，可以這麼設想，爸爸讓熊娃娃給媽媽送一封信，熊娃娃太好奇了，送到半路就把信拆開了，原來裡面有100塊錢和一封信，熊娃偷了錢讀了信。爸爸有段時間也覺得讓熊娃娃送信不甚安全，所以買了一個小小的帶鎖小鐵盒，把信和錢放在小鐵盒裡，熊娃娃看不到信也偷不到錢了。這裡的小鐵盒就是SSL。

HTTPS的應用場景有哪些？個人理解無外乎兩種場景，一種是確保數據安全，而另一種就是防止流量劫持。在上一通俗例子中，如果沒有那個小鐵盒，熊娃娃有可能還可以往信封里塞進去一個遊戲機廣告，從而調動媽媽買遊戲機的想法。數據安全的想像空間比較大，而對於流量劫持，大家可能其實每天都在經歷，只不是不知道那是流量劫持而已。

我們在使用手機時，有時候，手機下方會跳出一個綠色或紅色的流量點擊標識（加油槍等圖形顯示），一旦點擊後就直接跳轉到運營商（本人是移動）購買流量包的界面，這就是一種典型的流量劫持。還有在電腦端打開一個網頁，在網頁的左下角會莫名其妙地打開一個廣告框更加恐怖的事情是，就連我們在看電視不用流量的情況下，也會出現下面這種情況，電信運營商直接把自家的狗皮膏藥廣告貼到了央視的臉面上，有時還可能出現其它公司的廣告畫面，久久不願離去。

所以，六大互聯網公司聲淚控訴的有關機構，實際上就是運營商，這些運營商會進行數據劫持，對於從互聯網公司伺服器返回給用戶的內容，他們會在其中強行插入彈窗或嵌入式廣告等其他內容，干擾用戶的正常使用。但互聯網公司往往對運營商也是敢怒不敢言啊，為了防止流量劫持行為，這也進一步促成了各大互聯網公司紛紛啟動HTTPS項目，從而防止自家的網站被運營商強行切入廣告，對於講求用戶體驗的互聯網公司而言，運營商的行為就好比他們去一家五星級酒店，拚命通過門縫往房間里塞小卡片一樣令人不快。

當然，在互聯網領域，除了運營商敢明目張胆進行流量劫持外，各大互聯網公司之間其實也是宮斗厲害的非常。互聯網公司的用戶數一直是他們引以為豪的產物，很多公司也都是把它的用戶數量作為和投資人談判的籌碼，失去用戶是他們最不願意看到的結果，所以大家都拚命地去競爭對手或其他大流量公司去挖（引流）用戶。比如說2014年的百度VS360插標不正當競爭案中，百度稱「360安全衛士在百度搜索結果頁面上有選擇地插入警告標識，警示用戶搜索到的網站有風險，還逐步引導用戶點擊安裝360安全瀏覽器」，這種流量劫持行為最終被法院判決為不正當競爭行為並賠償。所以，如果當時的百度就全站啟動HTTPS項目，估計就不會發生該類狀況了。

三、HTTPS背後的法律應對之策

1.不正當競爭行為

在互聯網競爭性公司之間而言，流量劫持行為實際上就是一種「損害其他經營者的合法權益，擾亂社會經濟秩序的」不正當競爭行為，根據反不正當競爭法規定，這也是一種混淆商品或服務的行為。

除了上文中提到的2014年的百度VS360插標不正當競爭案外，在2015年「雙11」前，上海浦東新區法院於26日發出兩份民事裁定書，責令「幫5買」網站立即停止以「幫5淘」插件嵌入淘寶、天貓頁面，扒取後者流量的行為。該案是由於用戶電腦裝上「幫5淘」後，在使用IE、百度、搜狗等瀏覽器登陸時，「幫5淘」插件會自動嵌入天貓頁面，並在天貓頁面中出現「幫5買」廣告欄和搜索欄。當用戶選定商品準備買入時，商品標價附近會出現「現金立減」或「幫5買掃一掃立減1元」等鏈接和二維碼。一旦點擊，網頁就跳轉到「幫5買」界面。

2.刑事犯罪行為

流量劫持行為可能不僅僅只是一場民事訴訟，在特定情況下，甚至都可能將劫持犯明正典刑。2015年，上海浦東法院判決了全國首例流量劫持案，這起案件的被告並不是某一家互聯網公司或運營商，而是個人。從2013年年底到2014年10月，陝西人付某和廣東人黃某租賃多台伺服器，使用惡意代碼修改互聯網用戶路由器的DNS設置，進而使用戶登「2345.com」等導航網站時，跳轉至其設置的「5w.com」導航網站。最終，法院以破壞計算機信息系統罪判處兩名被告人有期徒刑三年，緩刑三年。

3.違約行為

流量劫持行為的背後，最大的受害者其實是消費者，他們可能不僅要消耗更多的流量，也得不到更好的服務體驗，你能想像付費後還得免費看運營商的廣告這般糟糕的體驗？所以，運營商實際上違反了消費者開通流量時的用戶協議，侵害了消費者的選擇權、知情權，違反了合同約定。當然，消費者也可以保留證據後先行向工信部投訴，這也不吝為一種行之有效的維權方式。

===============
手抖的快，錯別字漏網，無視頻！

微信公眾號：mclawman：互聯網法律領域深度觀察。

地方運營商耍流氓，HTTP劫持我問你怕不怕？！

事實上https也不能阻擋運營商投放廣告的熱情。
在各位答主說的2015年底2016年初的時間點之後，移動寬頻於1月21日至22日、電信寬頻於1月25日左右曾發生大面積網路中斷、http請求超時的情況。而在網路錯誤被逐漸排除之後，我所使用的移動寬頻（江蘇）開始出現運營商廣告，廣告形式為網頁正中，數秒後消失，內容全部指向http://10086.cn。

如知乎網，廣告劫持如下
跳轉頁被劫持，跳轉被中斷

廣告消失，變為空白頁面

刷新進入https頁面

包括必應搜索、百度貼吧、微博、A島、Steam都出現過被劫持的情況，其中

微博被劫持廣告消失以後，頁面上所有元素都無法點擊

Steam被完全劫持

A島的引用功能會直接被跳轉已跳過運營商直接向工信部投訴，運營商已解zan決ting對本戶的廣告投放，同樣的問題仍發生在我弟弟家中。

你國運營商劫持已經到了駭人聽聞的地步

中國某最大電商網站劫持率達到全量的幾個百分比你敢信？

為了防止http劫持啊

著作權歸作者所有。
商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
作者：weishuo1999
鏈接：你碰到過的最難調試的 Bug 是什麼樣的？ - weishuo1999 的回答
來源：知乎

也談談自己遇到的一個bug吧，我之前是做電商的，某較大的電商平台，突然有一天，C2C的店主反饋，看到的訂單不是自己的，看到後台的商品列表也不是自己的

當時在睡午覺，看到這個問題，立馬嚇醒了，平時5個投訴就是一個故障單，那還都是一點體驗上的小問題，這種訂單混亂，商品混亂的錯誤，真是要緊急死了

於是，主管，總監都來看這個問題，一群大佬在後面看著，趕緊找最近幾天的發布，測試情況，一個個回退，一個個檢查，最後都無法解決問題，要知道時間一分一秒過去，半個小時還解決不了就要出大事了

後續又有用戶來投訴，直接電話聯繫，遠程控制電腦，發現操作起來巨慢，於是順口問了一下用戶的網路是什麼網路。

結果他說是：「某城寬頻」，一瞬間，有點感覺了，繼續問其他幾個投訴的客戶都是「某城寬頻」，然後我們打電話到那個寬頻的運營商，得到的回復是「年底了，為了省流量，他們做了一部分緩存」

他們做了緩存
做了緩存
緩存
存

可是為毛TM的動態請求還做緩存啊，修改商品和訂單的時候，隨機返回成功或者失敗。。。。

＝＝＝＝＝＝＝＝＝回答下面的一些質疑＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
1.這個和時間戳也沒關，我們都加了token的，他們也忽略了
2.你沒猜錯，他們把POST和GET動態請求也緩存了，就是說你提交了一個POST修改商品的請求，他從環緩存裡面隨便丟個回復給用戶，用戶感覺修改成功了，其實請求根本沒到我們這邊
是的，就是這麼喪心病狂。

就是被這麼喪心病狂的運營商逼的

運營商劫持有一段時間了,但各個大網站2015換https最終的決心應該是iOS9的推出.
iOS9中默認是只能聯https網站.雖然可以重編譯程序取消這個限制,但是萬一以後強制只信用https呢,所以我看好幾個網站全線https是因為考慮iOS的訪問.

這題必須匿名黑一記。

這麼說吧，某年雙十一，某些地區會場商品和圖片全給調包了，我廠只能試探性給那邊運營商打電話隱晦地說這事，還不敢明說，都是逼的。

說到運營商劫持的問題，有點擔心以後運營商搞https劫持怎麼辦。運營商就是隨便拿個證書甚至自簽證書來劫持你的https連接，即使瀏覽器提醒不安全又怎樣，大不了用戶不訪問這些網站唄，如果點繼續訪問，那就老老實實被劫持並強制解密https。

運營商劫持流量讓服務商仍無可忍了，所以開啟全站https。但是新問題出來了，為了兼容老的http，伺服器做了跳轉，這時候運營上依然可以搞https代理劫持用戶流量。我相信運營商的路由器正在升級。

話說之前在知乎上泄露左耳朵耗子在阿里內部BBS帖子的哥們，估計就是掛在當時知乎還沒用https吧

1. HTTP2弄了Sever Push和多路復用。極大的加快了訪問的速度。
2. HTTP1.1上的劫持越來越暴力。影響了網頁的正常瀏覽。
3. 相比廣告費損失（意即類似淘寶客啊，百度首頁的劫持啊之類的損失）相比CPU性能上的額外損耗變得可以忽略不計。
4. HTTP2上的頭部壓縮技術和二進位幀，降低了流量。
5. HSTS使得降級到HTTP變得越來越不可能
6. 谷歌加大HTTPS鏈接的權重。谷歌的決定權也是很重要的！
7. 另外一個就是歷史的潮流，各大開發社區紛紛表示不支持不帶SSL的HTTP/2
8. 如果非要說有的話，還有一個時代的進程：ssl證書越來越便宜了，lets encrypt的出現則給了他們最後一擊，當然，這隻能說是次要的。
9. 最重要的還是nginx的mainline版本已經有HTTP/2支持了。眾所周知，一大堆網站都是用nginx的。（我記得V2EX和淘寶現在還是SPDY3.1，京東和百度還不是http/2）

待續。

劫持的這麼兇殘，你說你切不切https

流量挾持是一方面。

Https 可以額外帶來的收益還包括網站性能的優化。

新的網路協議，不管是 SPDY 還是HTTP/2推薦的默認實現都是建立在SSL 鏈接之上。

這兩者都具備復用 TCP 鏈路的能力，提高頁面載入速度。

不過可怕的是，百度上線全站 Https 之後，並沒有添加 Spdy 的支持。

有點跑題了，回答完畢。

從http到https的遷移，已是潮流，主要針對電商、P2P、APP下載等。啟用https不僅僅是針對運營商的劫持，更多的還是https本身是對數據進行加密傳輸的，保障數據傳輸過程中不被非法分子給竊取走或者篡改掉。另外，百度搜索會對https的頁面進行優先收錄，對SEO也是有很大幫助的。在APP應用商店也有限制必須是https的才被允許發布下載。

運營商劫持是一個原因。網站難以發現、感知。過去由於證書成本和伺服器資源的消耗，一般也就是網銀等交易平台會使用。現在成本低了，也沒有哪家網站會買不起證書或者伺服器，所以普及是一個趨勢。

首先要搞明白什麼是HTTPS，什麼是HTTP，然後才能解釋為什麼採用HTTPS。

HTTPS(Secure Hypertext Transfer Protocol)安全超文本傳輸協議
它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的
安全版,是使用 TLS/SSL 加密的 HTTP 協議。

HTTP 協議採用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議 TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能，可以避免此類問題。

TLS/SSL 全稱安全傳輸層協議 Transport Layer Security, 是介於 TCP 和 HTTP 之間的一層安全協議，不影響原有的 TCP 協議和 HTTP 協議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造。

TLS/SSL 的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

散列函數 Hash，常見的有
MD5、SHA1、SHA256，該類函數特點是函數單向不可逆、對輸入非常敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用於防止信
息篡改並驗證數據的完整性；對稱加密，常見的有
AES-CBC、DES、3DES、AES-GCM等，相同的密鑰可以用於信息的加密和解密，掌握密鑰才能獲取信息，能夠防止信息竊聽，通信方式是1對
1；非對稱加密，即常見的 RSA 演算法，還包括 ECC、DH
等演算法，演算法特點是，密鑰成對出現，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。因此掌握公鑰的不同
客戶端之間不能互相解密信息，只能和掌握私鑰的伺服器進行加密通信，伺服器可以實現1對多的通信，客戶端也可以用來驗證掌握私鑰的伺服器身份。

在
信息傳輸過程中，散列函數不能單獨實現信息防篡改，因為明文傳輸，中間人可以修改信息之後重新計算信息摘要，因此需要對傳輸的信息以及信息摘要進行加密；
對稱加密的優勢是信息傳輸1對1，需要共享相同的密碼，密碼的安全是保證信息安全的基礎，伺服器和 N 個客戶端通信，需要維持 N
個密碼記錄，且缺少修改密碼的機制；非對稱加密的特點是信息傳輸1對多，伺服器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但伺服器發出的信息能
夠被所有的客戶端解密，且該演算法的計算複雜，加密速度慢。

結合三類演算法的特點，TLS 的基本工作方式是，客戶端使用非對稱加密與伺服器進行通信，實現身份驗證並協商對稱加密使用的密鑰，然後對稱加密演算法採用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間採用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

身份驗證和密鑰協商是 TLS 的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但 RSA 演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的信息，存在安全隱患:

客戶端 C 和伺服器 S 進行通信，中間節點 M 截獲了二者的通信；

節點 M 自己計算產生一對公鑰 pub_M 和私鑰 pri_M;

C 向 S 請求公鑰時，M 把自己的公鑰 pub_M 發給了 C;

C 使用公鑰 pub_M 加密的數據能夠被 M 解密，因為 M 掌握對應的私鑰 pri_M，而 C 無法根據公鑰信息判斷伺服器的身份，從而 C 和 M 之間建立了」可信」加密連接;

中間節點 M 和伺服器S之間再建立合法的連接，因此 C 和 S 之間通信被M完全掌握，M 可以進行信息的竊聽、篡改等操作。

另外，伺服器也可以對自己的發出的信息進行否認，不承認相關信息是自己發出。

因此該方案下至少存在兩類問題：中間人攻擊和信息抵賴。

解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的，能夠驗證伺服器的身份信息，為此需要引入權威的第三方機構 CA。CA 負責核實公鑰的擁有者的信息，並頒發認證」證書」，同時能夠為使用者提供證書驗證服務，即 PKI 體系。

基本的原理為，CA 負責審核信息，然後對關鍵信息利用私鑰進行」簽名」，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA 也可以吊銷已經簽發的證書，基本的方式包括兩類 CRL 文件和 OCSP。CA 使用具體的流程如下：

a.服務方 S 向第三方機構CA提交公鑰、組織信息、個人信息(域名)等信息並申請認證；

http://b.CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等；

c.如信息審核通過，CA 會向申請者簽發認證文件-證書。

證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；

簽名的產生演算法：首先，使用散列函數計算公開的明文信息的信息摘要，然後，採用 CA 的私鑰對信息摘要進行加密，密文即簽名；

d.客戶端 C 向伺服器 S 發出請求時，S 返回證書文件；

e.客戶端 C 讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法；

f.客戶端然後驗證證書相關的域名信息、有效時間等信息；

g.客戶端會內置信任 CA 的證書信息(包含公鑰)，如果CA不被信任，則找不到對應 CA 的證書，證書也會被判定非法。

在這個過程注意幾點：

a.申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握；

b.證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器信息以及簽名；

c.內置 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書；

d.證書=公鑰+申請者與頒發者信息+簽名；