秒懂HTTPS接口(原理篇)
秒懂HTTPS接口(原理篇)
2018年12月03日 10:08:33 zuozewei 閱讀數:441更多 所屬專欄:文章目錄
- 前言
- HTTPS簡介
- HTTPS實現原理
- 大致原理
- 技術細節
- 小故事
前言
講HTTPS之前,我們先來回顧一下HTTP協議。HTTP是一種超文本傳輸協議,它是無狀態的、簡單快速的、基於 TCP 的可靠傳輸協議。
既然 HTTP 協議這麽好,那為什麽又冒出來了一個 HTTPS 呢?HTTP本身不具備加密的功能,所以也就無法做到對通信整體內容進行加密,
也就是說HTTP是明文傳輸的,這就造成了很大的安全隱患。在網絡傳輸過程中,只要數據包被人劫持,那你就相當於赤身全裸的暴露在他人面前,毫無半點隱私可言。想象一下,如果你連了一個不可信的WIFI,正好有使用了某個支付軟件進行了支付操作,那麽你的密碼可能就到別人手裏去了,後果可想而知。
網絡環境的就是這樣,給你帶來便利的同時,也到處充滿了挑戰與風險。對於小白用戶,你不能期望他有多高的網絡安全意識,產品應該通過技術手段,讓自己變得更安全,從源頭來控制風險。這就誕生了HTTPS協議。
HTTPS簡介
因為HTTP是明文傳輸,所以造成了安全隱患。如何讓數據傳輸以加密的方式進行,就消除了該隱患。而SSL/TSL提供認證和加密處理及摘要功能。
為了統一解決上述的問題,需要在HTTP上加密處理和認證等機制。我們把添加了加密和認證機制的HTTP稱為HTTPS。
HTTPS並非是應用層的一種新協議,只是通信接口部分用SSL/TLS協議代替而已。
所謂的HTTPS,簡單理解就是身披SSL/TLS協議殼的HTTP。
從網絡的七層模型來看,原先的四層 TCP 到七層 HTTP 之間是明文傳輸,在這之間加一個負責數據加解密的傳輸層(SSL/TLS),保證在網絡傳輸的過程中數據是加密的,而HTTP接收到的依然是明文數據,不會有任何影響。
SSL是Netscape開發的專門用戶保護Web通訊的,目前版本為3.0。最新版本的TLS 1.0是IETF(工程任務組)制定的一種新的協議,它建立在SSL 3.0協議規範之上,是SSL 3.0的後續版本。兩者差別極小,可以理解為SSL 3.1,它是寫入了RFC的。
HTTPS實現原理
大致原理
通過上面的介紹,對HTTPS有了大致的了解。可本質問題還沒說,HTTPS是如何實現數據的加密傳輸?
首先,先來了解下加密算法的方式,常用的有兩種:對稱加密與非對稱加密。
- 對稱加密:即通信雙方通過相同的密鑰進行信息的加解密。加解密速度快,但是安全性較差,如果其中一方泄露了密鑰,那加密過程就會被人破解。
- 非對稱加密:相比對稱加密,它一般有公鑰和私鑰。公鑰負責信息加密,私鑰負責信息解密。兩把密鑰分別由發送雙發各自保管,加解密過程需兩把密鑰共同完成。安全性更高,但同時計算量也比對稱加密要大很多。
技術細節
對於網絡通信過程,在安全的前提下,還是需要保證響應速度。如何每次都進行非對稱計算,通信過程勢必會受影響。所以,人們希望的安全傳輸,最終肯定是以對稱加密的方式進行。如圖:
首先 Session Key是如何得到的,並且在 Session Key之前的傳輸都是明文的。Session Key通過網絡傳輸肯定不安全,所以它一定各自加密生成的。因此在這之前,雙方還要互通,確認加密的算法,並且各自添加隨機數,提高安全性。如圖:
這樣雙方確認了使用的 SSL/TLS 版本,以及生成 Session Key的加密算法。並且雙方擁有了2個隨機數(客戶端、服務端各自生成一個)。可是如果按照目前的隨機參數,加上加密算法生成Session Key呢,還是存在風險,加密算法是有限固定的,而且隨機數都是明文傳輸的,有被截獲的可能。
讓加密算法變得不可預測,可能性不大。那麽能否再傳輸一個加密的隨機數,這個隨機數就算被截獲,也無法破譯。這就用到了非對稱加密算法,我們在步驟二中,把公鑰傳輸給客戶端。這樣客戶端的第三個隨機數用公鑰加密,只有擁有私鑰的服務端才能破譯第三個參數,這樣生成的 Session 就是安全的了。如圖:
看似完成了,現在生成的 Session Key 是不可預測的(就算被截獲也無所謂),我們可以放心的進行私密通信了。真的是這樣嗎?我們似乎對服務端給的公鑰十分信任,如果你目前通信的本身就不可信,或者被中間人劫持,由它發送偽造的公鑰給你,那後果可想而知,這就是傳說中的“中間人攻擊”。
所以,我們得包裝一下公鑰,讓它變得安全。這就引出了數字證書的概念,數字證書由受信任的證書機構頒發,證書包含證書文件與證書私鑰文件。私鑰文件由服務端自己保存,證書文件發送給請求的客戶端,文件包含了域名信息、公鑰以及相應的校驗碼。客戶可以根據得到的證書文件,校驗證書是否可信。如圖:
通俗的表示整個流程如圖:
證書示例:
Extended Validation(EV):該級別的證書具有最高的安全性,也是最值得信任的。它除了給出更詳細的公司/組織信息外,還在瀏覽器的地址欄上直接給出了公司名稱。
示例:https://www.github.com
小故事
如果上面的技術細節沒怎麽看太懂?來,我們來講個故事。
我們在網絡的行為(例如看瀏覽、上傳圖片、聊天),簡單來說都是向服務器發送消息、接收服務器的消息,這個過程很像信鴿傳書。
為了更加形象,我們把通信過程中的主要角色服務器、客戶端、黑客的稱呼也替換一下,小服、小客、小黑。
如小客想給小服發送信息,那麽她就把信綁在信鴿腿上,放出信鴿,小服接到信鴿,拿到信紙讀消息,這個過程就完成了,很不錯,簡單方便。
但是,壞人小黑出現了,他把正在愉快飛翔的信鴿抓了下來,並把信給換了,這就麻煩了,小服得到了假消息。
這就是 HTTP 的溝通方式,方便但極不安全,不能傳遞重要信息。
但是小服和小客很聰明,想到了一個好辦法,他們設定了一套編碼規則:把字母偏移3個位置,例如,D → A、E → B、F → C,這樣,原本的消息“secret message” 就變成了 “pbzobq jbppxdb”。
小黑截獲到消息後就會一臉懵逼,看不懂改不了,但是小服知道解碼規則,可以輕松轉化成原文。
這個方式就是“對稱式加密”。
對稱式加密很安全,只要保護好key,別讓其他人知道即可,但也有個問題,如果小服和小客在通信之前不認識,他們就沒辦法設定加密規則。
為了解決這個問題,通信方式又一次升級了,比如小客向給小服發送信息,他們的通信流程如下:
- 小客讓信鴿飛到小服那兒,但啥也沒帶,沒有信息。
- 小服讓信鴿帶著一個箱子和一把開著的鎖飛回到小客,小服自己留著鎖的鑰匙。小服讓信鴿帶著一個箱子和一把開著的鎖飛回到小客,小服自己留著鎖的鑰匙。
- 小客把信放到箱子裏,並用鎖把箱子鎖上,讓信鴿把箱子帶給小服。小客把信放到箱子裏,並用鎖把箱子鎖上,讓信鴿把箱子帶給小服。
- 小服收到箱子,用鑰匙開鎖,拿到信
- 這樣小黑就沒招兒了,小服和小客可以愉快的通信了。這樣小黑就沒招兒了,小服和小客可以愉快的通信了。
這個方式就是“非對稱加密”,這個箱子就是公鑰,開鎖的鑰匙就是私鑰。
細想一下,有個問題,小客怎麽確認箱子來自小服而不是小黑呢?為此,小服決定給箱子簽個名,小客收到後先檢查一下簽名就可以確認了。
但這樣還不夠穩妥,小服決定讓最權威的小明來簽名,小明是幹啥的?他非常有名望,是個絕對值得信賴的家夥,他的簽名大家都認,小明就是大名鼎鼎的 CA(Certification Authority)。
小服與小明建立了合作,小明收到小服的請求就會為她簽名,而小黑是得不到小明給小客的簽名的,這樣小服就可以放心了。
這就是HTTPS的通信通俗原理了,是不是很好理解。
我們可以看到 HTTPS 比 HTTP的流程重了很多,有個箱子,還有簽名,還增加了往返過程,性能肯定有所影響,這一切都是為了安全,所以我們要根據自己的需求場景來選擇什麽時候使用 HTTPS,什麽時候使用 HTTP。
相關系列:
秒懂HTTPS接口(實現篇)
秒懂HTTPS接口(接口測試篇)
秒懂HTTPS接口(JMeter壓測篇)
參考文獻:
[1]上野宣,於均良譯.圖解HTTP.北京:人民郵電出版社,2014.
[2]https://github.com/jasonGeng88/blog/blob/master/201705/https.md
秒懂HTTPS接口(原理篇)