隨着互聯網安全意識的廣泛提升,對安全要求稍高的應用中,HTTPS的使用是很常見的,甚至在1年前,蘋果公司就將使用HTTPS做爲APP上架蘋果應用市場的先決條件之一(詳見《蘋果即將強制實施 ATS,你的APP準備好切換到HTTPS了嗎?》一文)。html
因此,不管是即時通信IM仍是其它應用,在網絡安全意識加強的今天,不少場景下使用HTTPS是確定沒錯的。對於即時通信IM的開發人員來講,長鏈接用TLS這沒疑問,短鏈接用HTTPS也沒問題,但我想問你一個最基礎的面視問題:HTTPS到底用的是對稱加密仍是非對稱加密?算法
要回答這個問題,顯然須要再梳理一下HTTPS的技術原理了,本文將帶你瞭解HTTPS到底用的是對稱加密仍是非對稱加密,以及具體又是怎麼使用的。瀏覽器
隨着 HTTPS 建站的成本降低,如今大部分的網站都已經開始用上 HTTPS 協議。你們都知道 HTTPS 比 HTTP 安全,也據說過與 HTTPS 協議相關的概念有 SSL 、非對稱加密、 CA證書等。安全
但對於如下靈魂三拷問可能就答不上了:服務器
不用擔憂,本文將在解答「HTTPS到底用的是對稱加密仍是非對稱加密?」的同時層層深刻,從原理上把 HTTPS 的安全性講透,您也將同時理解上述問題。網絡
你們可能都據說過 HTTPS 協議之因此是安全的是由於 HTTPS 協議會對傳輸的數據進行加密,而加密過程是使用了非對稱加密實現。但其實:HTTPS 在內容傳輸的加密上使用的是對稱加密,非對稱加密只做用在證書驗證階段。工具
HTTPS的總體過程分爲證書驗證和數據傳輸階段,具體的交互過程以下: 學習
① 證書驗證階段:網站
1)瀏覽器發起 HTTPS 請求;加密
2)服務端返回 HTTPS 證書;
3)客戶端驗證證書是否合法,若是不合法則提示告警。
② 數據傳輸階段:
1)當證書驗證合法後,在本地生成隨機數;
2)經過公鑰加密隨機數,並把加密後的隨機數傳輸到服務端;
3)服務端經過私鑰對隨機數進行解密;
4)服務端經過客戶端傳入的隨機數構造對稱加密算法,對返回結果內容進行加密後傳輸。
首先:非對稱加密的加解密效率是很是低的,而 http 的應用場景中一般端與端之間存在大量的交互,非對稱加密的效率是沒法接受的。
另外:在 HTTPS 的場景中只有服務端保存了私鑰,一對公私鑰只能實現單向的加解密,因此 HTTPS 中內容傳輸加密採起的是對稱加密,而不是非對稱加密。
HTTP 協議被認爲不安全是由於傳輸過程容易被監聽者勾線監聽、僞造服務器,而 HTTPS 協議主要解決的即是網絡傳輸的安全性問題。
首先咱們假設不存在認證機構,任何人均可以製做證書,這帶來的安全風險即是經典的「中間人攻擊」問題。
「中間人攻擊」的具體過程以下:
如上圖因此,過程原理以下:
因爲缺乏對證書的驗證,因此客戶端雖然發起的是 HTTPS 請求,但客戶端徹底不知道本身的網絡已被攔截,傳輸內容被中間人所有竊取。
因此權威機構會對申請者的信息進行審覈,不一樣等級的權威機構對審覈的要求也不同,因而證書也分爲免費的、便宜的和貴的。
瀏覽器發起 HTTPS 請求時,服務器會返回網站的 SSL 證書,瀏覽器須要對證書作如下驗證:
1)驗證域名、有效期等信息是否正確:證書上都有包含這些信息,比較容易完成驗證;
2)判斷證書來源是否合法:每份簽發證書均可以根據驗證鏈查找到對應的根證書,操做系統、瀏覽器會在本地存儲權威機構的根證書,利用本地根證書能夠對對應機構簽發證書完成來源驗證(以下圖所示):
3)判斷證書是否被篡改:須要與 CA 服務器進行校驗;
4)判斷證書是否已吊銷:經過CRL(Certificate Revocation List 證書註銷列表)和 OCSP(Online Certificate Status Protocol 在線證書狀態協議)實現,其中 OCSP 可用於第3步中以減小與 CA 服務器的交互,提升驗證效率。
以上任意一步都知足的狀況下瀏覽器才認爲證書是合法的。
這裏插一個我想了好久的但其實答案很簡單的問題:
既然證書是公開的,若是要發起中間人攻擊,我在官網上下載一份證書做爲個人服務器證書,那客戶端確定會認同這個證書是合法的,如何避免這種證書冒用的狀況?
其實這就是非加密對稱中公私鑰的用處,雖然中間人能夠獲得證書,但私鑰是沒法獲取的,一份公鑰是不可能推算出其對應的私鑰,中間人即便拿到證書也沒法假裝成合法服務端,由於沒法對客戶端傳入的加密數據進行解密。
若是須要瀏覽器不提示安全風險,那隻能使用認證機構簽發的證書。但瀏覽器一般只是提示安全風險,並不限制網站不能訪問,因此從技術上誰均可以生成證書,只要有證書就能夠完成網站的 HTTPS 傳輸。
例如早期的 12306 採用的即是手動安裝私有證書的形式實現 HTTPS 訪問:
證書驗證是採用非對稱加密實現,可是傳輸過程是採用對稱加密,而其中對稱加密算法中重要的隨機數是由本地生成而且存儲於本地的,HTTPS 如何保證隨機數不會被竊取?
其實 HTTPS 並不包含對隨機數的安全保證,HTTPS 保證的只是傳輸過程安全,而隨機數存儲於本地,本地的安全屬於另外一安全範疇,應對的措施有安裝殺毒軟件、反木馬、瀏覽器升級修復漏洞等。
HTTPS 的數據是加密的,常規下抓包工具代理請求後抓到的包內容是加密狀態,沒法直接查看。
可是,正如前文所說,瀏覽器只會提示安全風險,若是用戶受權仍然能夠繼續訪問網站,完成請求。所以,只要客戶端是咱們本身的終端,咱們受權的狀況下,即可以組建中間人網絡,而抓包工具即是做爲中間人的代理。一般 HTTPS 抓包工具的使用方法是會生成一個證書,用戶須要手動把證書安裝到客戶端中,而後終端發起的全部請求經過該證書完成與抓包工具的交互,而後抓包工具再轉發請求到服務器,最後把服務器返回的結果在控制檯輸出後再返回給終端,從而完成整個請求的閉環。
既然 HTTPS 不能防抓包,那 HTTPS 有什麼意義?
HTTPS 能夠防止用戶在不知情的狀況下通訊鏈路被監聽,對於主動授信的抓包操做是不提供防禦的,由於這個場景用戶是已經對風險知情。要防止被抓包,須要採用應用級的安全防禦,例如採用私有的對稱加密,同時作好移動端的防反編譯加固,防止本地算法被破解。
如下用簡短的Q&A形式進行全文總結。
Q: HTTPS 爲何安全?
A: 由於 HTTPS 保證了傳輸安全,防止傳輸過程被監聽、防止數據被竊取,能夠確認網站的真實性。
Q: HTTPS 的傳輸過程是怎樣的?
A: 客戶端發起 HTTPS 請求,服務端返回證書,客戶端對證書進行驗證,驗證經過後本地生成用於改造對稱加密算法的隨機數,經過證書中的公鑰對隨機數進行加密傳輸到服務端,服務端接收後經過私鑰解密獲得隨機數,以後的數據交互經過對稱加密算法進行加解密。
Q: 爲何須要證書?
A: 防止」中間人「攻擊,同時能夠爲網站提供身份證實。
Q: 使用 HTTPS 會被抓包嗎?
A: 會被抓包,HTTPS 只防止用戶在不知情的狀況下通訊被監聽,若是用戶主動授信,是能夠構建「中間人」網絡,代理軟件能夠對傳輸內容進行解密。
好了,迴歸到本文標的問題,咱們來總結回顧一下。
Q: HTTPS用的是對稱加密仍是非對稱加密?
Q: HTTPS 在內容傳輸的加密上使用的是對稱加密,非對稱加密只做用在證書驗證階段。(本文同步發佈於:http://www.52im.net/thread-2866-1-1.html)
順手 po 一張學習的過程圖(點擊查看大圖):