一篇漫畫故事帶你理解透HTTPS(下)


上下集知識點總結:程序員

前情提要:算法

蝙蝠紀元,疫情之下。二丫欲訪問京東購物,不料彈出安全提示,遂找二毛一探究竟。二毛一頓排查後,開始用通俗易懂的語言深刻淺出的向二丫解釋 HTTP做用及優缺點、HTTPS的功能做用......瀏覽器

未看過上集的,可進入傳送門:安全

【故事】跟零計算機基礎的房東女兒講了一下午的中間人劫持京東事件後,她感激不盡,決定給我免除房租(上)網絡


二丫掛掉電話後,對二毛邪魅一笑...函數

開始以前,咱們先了解一些前置技術。網站

前置技術

1 對稱加密

定義:一種加密算法,只有一個密鑰,這個密鑰既能夠用來加密數據,又能夠用來解密數據。加密

優勢:加解密速度快。spa

缺點:因爲只有一個密鑰,應用場景不普遍。3d

2 非對稱加密

定義:也是一種加密算法,有兩個密鑰,一個稱爲公鑰,另外一個稱爲私鑰。其中公鑰能夠廣而告之,私鑰須要本身妥善保存。公鑰能夠加密數據,而後用私鑰解密;反過來,私鑰也能夠加密數據,用公鑰來解密。

優勢:因爲公鑰和私鑰能夠互相加解密,應用場景普遍。

缺點:加解密速度較慢。

3 消息摘要:

定義:經過哈希函數,將任意長度的消息變成固定長度的短消息,且一個固定的內容不管通過多少次哈希獲得的結果仍然是固定不變的,稱爲消息摘要。

應用場景:可將長消息縮短,加密處理起來更快。

4 數字證書:

定義:由CA(一個權威的認證機構)頒發的一種證書,裏面含有能夠標識你身份的信息,相似於咱們的身份證。

注:證書是必須由服務端主動向CA申請的。服務端(假設爲網站)提供本身的域名等信息,接着CA會使用它們的私鑰對內容進行加密,而後做爲數字證書返回給服務端。

應用場景:

身份證實。因爲CA是權威的,他們的私鑰會嚴格保存,公鑰會廣爲公開,因此一旦服務端網站出示了數字證書後,咱們就能夠依據頒發證書的CA,找到對應的公鑰,而後解密數字證書獲得裏面的域名信息,並比對當前訪問的域名是否跟獲得的域名一致,以此判斷真假。

5 數字簽名:

定義:只有信息的發送者才能生成的、別人沒法僞造的一段字符串。

主要有兩個步驟生成:

  1. 首先對要發送的內容進行消息摘要獲得短字符串。
  2. 發送者再使用本身的私鑰對該短字符串進行加密,就獲得了數字簽名。(固然也能夠對整個信息作數字簽名,可是通過消息摘要處理的信息會更少,加密更快。)

應用場景:

  • 完整性保護:只要咱們使用發送者的公鑰解密數字簽名,獲得原摘要內容,再跟咱們本身進行消息摘要的內容進行對比,就能判斷,若一致,則說明信息內容沒篡改破壞過。
  • 不可抵賴性:因爲發送者的私鑰只有發送者本身知道,因此只要信息比對一致,就能證實這信息是該發送方寫的。

看到這裏,讀者可能有點懵,那數字簽名跟數字證書有什麼不一樣?

  • 數字簽名通常是用戶用本身的私鑰加密摘要生成的,目的是爲了數據完整性保護和不可抵賴性。
  • 數字證書是使用CA的私鑰加密你的信息造成的,目的是證實你的身份。

HTTPS的技術實現

上集的例子中,小明給小紅傳紙條,可是小明的明文通訊可能會被第四排同窗竊聽、篡改、破壞、假裝,而對應的解決方法就是使得通訊規則能有這三個功能:加密數據、數據完整性保護、身份驗證

那該如何使得通訊規則有這三個功能?小明在研究了前置技術的內容後,受到啓發,決定這樣幹:

(這裏假設學校有個大隊長(即CA)可以爲學生信息作公證,即頒發數字證書,小明小紅都已經申請了本身的數字證書。數字證書中包含本身的姓名、本身的公鑰等信息)

1 在開始傳對話內容前,小明就先傳紙條請求小紅的數字證書,請求時也把本身的數字證書傳過去。

2 小紅收到信息後,就用大隊長的公鑰解密獲得信息,得知是小明請求與她傳紙條,因而她含羞的把本身的數字證書回傳了過去。

3 小明獲得返回的數字證書後,也用大隊長的公鑰解密獲得信息(信息含有小紅姓名和小紅公鑰),比對姓名信息看是否爲小紅。若是不是小紅,則不通訊,若是是,進入下一步。

4 小明隨機生成一串字符a,而後拿出小紅的公鑰,並用該公鑰加密這串字符a,返回給小紅。

5 小紅收到信息就用本身的私鑰進行解密,而後取出字符a,隨後小紅將內容 「贊成傳紙條」 用字符a做爲密鑰進行對稱加密,獲得密文後寫入紙條中。另外,小紅也對內容 「贊成傳紙條」進行消息摘要,隨後用本身的私鑰對摘要的內容進行加密獲得數字簽名,寫入紙條署名處。

6 小明收到信息,用字符a做爲密鑰進行對稱解密,獲得內容「贊成傳紙條」。爲了鑑別內容是否被破壞或篡改過,小明使用小紅的公鑰對署名的字符進行解密,獲得消息摘要內容a,另外再將內容「贊成傳紙條」進行消息摘要獲得消息摘要b,最後將摘要內容a和摘要內容b進行比對,若是一致,則說明沒有破壞或篡改過。

7 通訊繼續。。

至此上面幾個步驟,就完成了安全的鏈接和通訊:雙方都使用字符a做爲密鑰對內容進行對稱加密,另外生成數字簽名寫在一旁用於校驗內容。

身份驗證的實現:

此前小明不是怕第四排同窗假裝成小紅回紙條信息嗎?

如今有了數字證書的功能,在一開始準備傳對話內容前就能夠經過CA公鑰解密數字證書,得出信息來辨別對方身份。

萬惡的第四排同窗(中間人)再也沒法假裝女神小紅了!

注:HTTPS機制很是重要的一點就是假定CA的私鑰是安全的,若是泄露了,HTTPS的安全性機制將土崩瓦解。因此CA通常是大公司或組織,由於它們更有能力保護本身的私鑰,所以瀏覽器信任的CA列表每每是一些知名CA。

數據加密的實現:

此前小明不是怕第四排同窗竊聽紙條信息嗎?

如今由於有了前面的身份驗證,也就確保獲得了真實對方的公鑰,並能利用該公鑰加密傳輸即將用於對稱加密對話內容的密鑰(例子中的字符a)。只要這個對稱密鑰被安全傳輸了,後面進行紙條內容的加密也就被高效的實現了。

萬惡的第四排同窗(中間人)不再沒法偷看個人紙條小祕密了!

注:這裏可能會有同窗問,既然雙方都知道彼此的公鑰後,那爲什麼不直接拿對方的公鑰來加密本身要發出的信息?這個確實能夠,可是卻忽略了高效性,前面已經提到過,非對稱加密算法比對稱加密算法效率要低,考慮到後續通訊的頻繁性,因此最好使用對稱加密來對通訊內容進行加密。

數據完整性保護的實現:

此前小明不是怕第四排同窗篡改或破壞紙條信息嗎?

如今有了數字簽名,可與原有信息進行對比,就能夠判斷紙條內容有無被更改或破壞了。

萬惡的第四排同窗(中間人)再也沒法更改或破壞我對女神表達的情感了!

HTTPS的創建過程:

弄懂了上面小明傳紙條的例子,再來理解訪問使用 HTTPS 協議網站的創建過程,簡直就是易如反掌!

創建安全的HTTPS通信,可防止中間人攻擊,這須要如下步驟:  

一、服務端配置正確了對應的安全證書   

二、客戶端發送請求到服務端   

三、服務端返回公鑰和證書到客戶端   

四、客戶端接收後會驗證證書的安全性,若是經過則會隨機生成一個隨機數,用公鑰對其加密,發送到服務端   

五、服務端接受到這個加密後的隨機數後會用私鑰對其解密獲得真正的隨機數,隨後用這個隨機數當作密鑰對須要發送的數據進行對稱加密   

六、客戶端在接收到加密後的數據使用密鑰(即生成的隨機值)對數據進行解密而且解析數據呈現結果給客戶   

七、SSL加密創建。後續數據傳輸還將用到數字簽名技術。。

注:小明傳紙條的例子和用戶訪問網站有點不一樣:小明小紅互相傳紙條須要雙方互相進行身份驗證;而用戶訪問網站,只是用戶驗證網站,網站不驗證用戶。但不管哪一種狀況,使用的底層技術都是上面幾種,只是應用狀況不一樣。

事件後續吃瓜

點擊域名左邊的感嘆號標誌,就能查看到該網站提供的證書信息。

能夠看到這個數字證書的簽發人信息,從電子郵箱能夠知道 QQ。後續網傳這QQ主人仍是個初學計算機的高中生......

不過,「初學者」的猜想顯然不符合常理,「憑一己之力搞壞網絡」所須要的智商,和「拿本身QQ郵箱簽名證書」所對應的智商,顯然不在同一個位面上。這不符合常理,事出反常必有妖。

最近,這位號主也發話澄清了。。

晚上,二毛坐在電腦桌前,看着萬家燈火,想象着二丫又搞懂了一些計算機知識點後,欣喜若狂、歡呼雀躍的樣子,不由感到欣慰。

他隨後在電腦上敲下一行標題:跟零計算機基礎的房東女兒講了一下午的中間人劫持京東事件後,她感激不盡,決定給我免除房租。

哎,程序員的快樂,每每就是那麼樸實無華、枯燥且乏味。

往期精彩:

【故事】跟零計算機基礎的房東女兒講了一下午的中間人劫持京東事件後,她感激不盡,決定給我免除房租(上)


    歡迎來到程序員二毛的世界,在這裏你將看到特色鮮明的人物、跌宕起伏且有趣的故事情節、通俗易懂的技術。

    關注公衆號《程序員二毛》,後臺回覆 1024 領取變強祕籍。

相關文章
相關標籤/搜索