關於HTTPS認證,這里解決你所有疑惑


摘要:從簽發證書到數據加密交互,按流程的進展講解HTTPS認證過程內容和原理。

本文分享自華為雲社區《故事+圖文,一次性解決你對HTTPS認證過程的所有疑惑》,作者:breakDraw。

講解HTTPS認證原理的文章非常多,也算是做web開發的基礎知識了。但是這類文章看過去都有一個特點——知識點超級多,很亂。

證書、簽名、公鑰、私鑰、哈希、CA證書、網站證書、對稱非對稱加解密……一堆概念夾雜在一起,導致很多人對這塊只能說個所以然,卻無法做到完全理解。

這里我就用 從簽發證書到數據加密交互,按流程完整解釋, 並在其中穿插圖片和問題,來完整解釋這個原理。

一、創業前的資質申請——證書簽發

某天,我做了一個網站, 如果直接開放給所有人訪問,那么就屬於無證經營, 每個訪問我網站的人,都會收到瀏覽器如下的警告。

為了解決這個問題, 我需要去工商局也就是證書頒發機構CA( Certificate Authority),去獲取一個證書,來證明我這個網站是安全的。

CA機構要求我提供身份證 、 店鋪信息等一系列申請信息,整合成一個server.req的文件, 提交給他。

CA機構會有專門的人進行審查,確認我的資質、合法性。審查通過后,他們就開始了證書簽發工作。

1、首先, 他們覺得我的網站信息太長了,不好用來做檢查或者對比,於是用一個 哈希算法(可以是sha256),將其變成一個固定長度的字符串, 這個字符串被他們叫做 摘要(Digest)

2、接着,他們請出了CA機構中的最高領導,將這個摘要加上領導名字 重新在紙上寫了一遍,然而寫出來時卻是一串看不懂的線條。 這是領導獨有的寫法,除了他自己,任何人都無法模仿。而且普通人也根本看不懂。

這個領導的名字叫做 CA私鑰。而這個看似瞎寫的過程, 叫做私鑰簽名,即對摘要重寫並暗含了自己的名字,只是一般人根本看不懂罷了。

3、接着他們把我的網站信息、CA簽名 打包成了一個證書,頒發給我,叫我好好保管, 如果有顧客問我,我就可以把這個證書拿出來給他們看。

我疑惑地問道: “你這個簽名寫得亂七八糟,誰也看不懂啊,顧客咋確認我這個是合法的證書?”
CA證書的機構笑了笑,說:“你只管提供就好了,顧客們自有辦法”。

最終整個頒發的過程如下所示:

二、究極謹慎的顧客——證書驗證

那天,我游盪在街頭,無意發現一個我很感興趣的店,我進入了店內,卻發現這家店是新開的。

如果我不確認這家店的合法性,那么很有可能進入一家黑店,被宰或者被犯罪都有可能。

此刻我必須確認這個店家的證書是CA機構簽發的,還是他自己造假的證書。

而我正好認識一位和CA私鑰一起出生長大的兄弟 CA公鑰(公私鑰都是同時生成的), 雖然無法模仿領導的筆跡,但是能夠勉強看懂。

CA公鑰確認了簽名是CA私鑰所寫,而且能夠正確解讀出簽名中的摘要信息。他還將其與經營證書上所有文字生成的新摘要進行比對, 發現確實一致,因此他認定這是合法的證書。

上面這個過程,就叫做驗簽, 如下所示


可是,一般能解讀出簽名是CA私鑰所寫就夠了, 為什么還要比對一下摘要信息呢?

因為簽名公鑰只能識別出這個字是私鑰所寫,但是私鑰曾經為別人寫過很多的簽名。萬一造假者把簽名換成了其他正規店鋪里抄來的簽名,那怎么辦? 所以肯定得確認下這個簽名的內容是不是和證書上所寫的店鋪是同一家。

上面的過程是單向認證,即客戶端驗證服務端。

如果商家擔心碰到居心不良的顧客, 那么同樣可以讓顧客提供 類似簽發過程的證書,以證明自己也是可信的顧客, 這就是雙向認證

三、超級而隱秘的交易

上面的店家和顧客,通過證書驗證,確認了各自的身份。接着便決定互相進行快遞交易。
但因為路上不安全,經常有強盜或者小偷出沒,如何保證快遞不被盜取很重要。

顧客打算把錢(通信數據)放在一個密碼箱里, 然后設置好密碼,再快遞過去。
這個密碼叫做會話密鑰,任何人拿到密碼都能打開密碼箱,所以也叫對稱密鑰

但是店家該怎么知道這個密碼呢?

如果顧客直接把密碼箱的密碼快遞過去, 密碼在路上被小偷看到了, 那后面發出去的錢豈不是就能被小偷解開並拿到了?

這時候顧客想起來,當時拿到的商家經營證書里, 攜帶了一個叫 公鑰的東西, 通過這個東西, 可以把 密碼箱密碼 變成另一串看不懂的數字, 只有商家自己能夠解讀這個數字。

於是顧客用公鑰生成了一個 加密后的密碼, 並成功送到了店家手中。

店家拿到后, 使用自己的私鑰成功解讀出了這個密碼。接着店家和顧客就 都把密碼箱設置成密碼,進行快遞, 除了店家和顧客, 其他人都無法知道這個密碼是多少, 劫匪們也就無從下手了。

四、關鍵問題

上面過程中,還有幾個關鍵問題,這里提出,可以先自己思考,再看答案:

Q: 為什么不使用非對稱密鑰加密 傳輸數據, 而要用對稱密鑰這樣繞一大圈?

A:對稱算法的加解密性能比非對稱算法快很多, 所以非對稱只用於會話密鑰的傳輸即可, 只需要一次。

Q: 為什么數據開始傳輸之后不需要再做驗簽, 難道者中間的數據就不會再被人篡改或者替換嗎?

A:不會,有3個原因保證:

  1. 會話密鑰是會話級別, 動態生成的,只有這一次連接才會用到。因此以前廢棄的會話密鑰不用擔心被人拿去利用。
  2. 建立連接並傳遞會話密鑰之前,已經通過驗簽確認過對方身份是可信的。
  3. 沒有任何第三方知道會話密鑰是什么。因此第三方攻擊人無法用正確的會話密鑰加密數據,即無法做到偽造會話密鑰來欺騙接收者的目的。

Q: CA根證書可能被造假嗎?
例如黑客修改了用戶機器中的CA證書,導致CA的公鑰被替換了, 后面訪問了黑客所在的網址時,就會驗簽成功。

A:如果真的能修改的話,那么是可行的。
但是操作系統基本會內置著名CA的公鑰,除非黑客已經能直接觸碰你的操作系統底層了,否則基本辦不到。

五、總結和完整大圖

上文的顧客就是客戶端(也可以是瀏覽器), 店家就是服務端(網站), 工商局就是可信CA機構(或者某域內自己設置的頒發機構也行)。

而一些要點總結如下:

  • CA私鑰用於簽名, CA公鑰用於驗簽
  • 要先生成摘要,再簽名。目的是為了驗簽后確認來源是所簽的服務端。
  • 服務端公鑰用於加密, 服務端私鑰用於解密。
  • 傳輸數據使用對稱密鑰進行加密和解密。

 

點擊關注,第一時間了解華為雲新鮮技術~


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM