但是還有一種情況,在請求公鑰的過程中,有壞人在中間假扮真正的伺服器,發給你自己的公鑰,之後再一直跟你通訊,那你傳送的內容都被壞人看到了。這就引出瞭如何驗證伺服器的身份問題。為了解決這個問題,人們整了一個可信的第三方,叫做 CA,由它來協助驗證伺服器。伺服器向 CA 提供伺服器的資訊,CA 會生成一個金鑰對(公鑰和私鑰)以及一個證書,其中公鑰是證書的一部分。CA 還會對證書進行數字簽名,這個數字簽名是將證書經過一次雜湊函式後用 CA 的私鑰加密後的加密文字。客戶端每次跟伺服器通訊時,伺服器先把帶有數字簽名的證書發給客戶端,客戶端用 CA 公開的公鑰對數字簽名進行解密,得到的雜湊值與證書的雜湊值進行比較,兩個值相同,說明身份是真實的,這樣客戶端就拿到了真實的伺服器公鑰。
HTTP 是應用層上的純文字協議,就是說,從傳輸層 socket 拿到位元組再將它們轉換成字串之後看到的內容就是另一端發給你的內容,毫無秘密可言。如果有人在傳輸過程中的某個節點劫持傳輸的資料,就能完完全全地讀取到 Client 與 Server 之間傳輸的內容,你傳的是使用者名稱和密碼,那就悲劇了。
為了避免這種悲劇發生,就有了 HTTPS,S 代表 SSL,也可以是 TLS,可以將 TLS 理解為 SSL 3.1 版本。
HTTPS 主要解決了兩個問題,
加密:如何防止通訊內容被直接讀取信任:如何確認正在通訊的伺服器就是想要通訊的伺服器先說加密,為了不讓別人看到傳送的文字,就需要先對文字進行加密,加密一般有兩種方式,對稱加密和非對稱加密。對稱加密只需要一個金鑰,通訊雙方都用同一個金鑰進行加密和解密;非對稱加密需要一個金鑰對,公鑰和私鑰對,由通訊的一方(伺服器)建立,保留私鑰,將公鑰發給另一方(客戶端)。凡是用公鑰加密過的資訊,只能由私鑰進行解密。你自然會想到,只要在發起 HTTP 請求前,先從伺服器拿到公鑰,然後將 HTTP 內容用公鑰加密後傳送給伺服器就可以保證不會被別人讀到。加密過的內容確實只能由伺服器的私鑰解密過後才能讀取到。
但是還有一種情況,在請求公鑰的過程中,有壞人在中間假扮真正的伺服器,發給你自己的公鑰,之後再一直跟你通訊,那你傳送的內容都被壞人看到了。這就引出瞭如何驗證伺服器的身份問題。為了解決這個問題,人們整了一個可信的第三方,叫做 CA,由它來協助驗證伺服器。伺服器向 CA 提供伺服器的資訊,CA 會生成一個金鑰對(公鑰和私鑰)以及一個證書,其中公鑰是證書的一部分。CA 還會對證書進行數字簽名,這個數字簽名是將證書經過一次雜湊函式後用 CA 的私鑰加密後的加密文字。客戶端每次跟伺服器通訊時,伺服器先把帶有數字簽名的證書發給客戶端,客戶端用 CA 公開的公鑰對數字簽名進行解密,得到的雜湊值與證書的雜湊值進行比較,兩個值相同,說明身份是真實的,這樣客戶端就拿到了真實的伺服器公鑰。
但事實上,HTTP 文字是用對稱加密演算法加密,原因是
非對稱加密比較慢非對稱加密對文字長度有限制那之前費很大勁兒拿到的公鑰有什麼用呢?它是用來加密傳輸對稱加密使用的金鑰。