一、HTTP 與 HTTPS 有哪些區別？ 1. HTTP 是超文本傳輸協議，資訊是明文傳輸，存在安全風險，HTTPS ，是在 TCP 和網路層之間加入了 SSL/TLS 安全協議，也就是安全套接字層，使得報文能夠加密傳輸， 2. HTTP 連接建立相對簡單， TCP 三次握手建立之后便可進行 HTTP 的報文傳輸，而 HTTPS 在 TCP三次握手之后，還需進行 SSL/TLS 的四次握手程序，才可進入加密報文傳輸， 3. HTTP 的埠號是 80，HTTPS 的埠號是 443， 4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的，淘寶是真的淘寶，不是假冒的釣魚網站等， 二、HTTPS 解決了 HTTP 的具體哪些問題呢？
- 竊聽風險，“有心人”竊聽到具體的通信內容，資訊被不該知道的人，知道了，比如盜取QQ賬號，
- 篡改風險，“有心人”篡改了通信內容，不該知道的人，雖然沒有知道資訊的內容，但是他在資訊序列上加上、洗掉、或者編輯了原來的的內容，比如強制植入垃圾廣告
- 冒充風險，“有心人”冒充銀行、淘寶等網站，誘導用戶輸入一些敏感資訊，從而盜取用戶賬戶中的錢財等，俗稱釣魚網站，
所以https解決了三個問題，防竊聽、防篡改、防冒充，
四、基礎的加密演算法和基于這些加密演算法的加密機制
1、對稱加密演算法
加密密鑰和解密密鑰是一樣的，加密程序和解密程序是對稱的，所以叫做對稱加密演算法，
優點：加密速度快
缺點：需要雙方都有密鑰，怎么樣傳輸密鑰是最大的問題，
2、非對稱加密演算法（公開密鑰加密演算法）
幾點說明：
- 加密密鑰和解密密鑰是不一樣的，所以是非對稱加密，
- 加密密鑰和解密密鑰是成對的，可以互相加解密，也就是用其中一個加密，用另一個可以解密，
- 一個公鑰，一個私鑰，公鑰公開，私鑰只能自己持有，是自己的一個特征，就好像身份證上的照片，而且不能通過其中一個推算出另一一個，
3、混合加密--數字信封技術
通過公開密鑰加密演算法傳輸對稱加密演算法的密鑰，這樣就解決了對稱加密演算法的密鑰分發問題，
在實際的通信程序中，HTTPS 采用的是對稱加密和非對稱加密結合的「混合加密」方式：
在通信建立前采用非對稱加密的方式交換「會話秘鑰」，后續就不再使用非對稱加密， 在通信程序中全部使用對稱加密的「會話秘鑰」的方式加密明文資料， 采用「混合加密」的方式的原因： 對稱加密只使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換， 非對稱加密使用兩個密鑰：公鑰和私鑰，公鑰可以任意分發而私鑰保密，解決了密鑰交換問題但速度慢，4、摘要演算法（哈希演算法）
幾點說明：
- 哈希演算法也是一種加密演算法，
- 同樣的明文輸入，輸出的密文相同；無論多長的明文，密文的長度都是相同的，不同的明文，哪怕只是很長明文中改動一個字符，輸出的密文也會不同，
- 哈希演算法不可逆，就是不可能通過密文解密出明文，但是可以通過加密同樣的明文，來比對在傳輸程序中密文是否被改動過，
5、數字證書
客戶端先向服務器端索要公鑰，然后用公鑰加密資訊，服務器收到密文后，用自己的私鑰解密， 這就存在些問題，如何保證客戶端得到的服務器的公鑰沒有被篡改過、且不是釣魚網站的公鑰呢？ 所以這里就需要借助第三方權威機構 CA （數字證書認證機構），將服務器公鑰在數字證書認證機構中注冊，注冊后的公鑰就可以證明服務器的真實身份，
1、服務器把自己的公鑰在數字證書認證機構（CA）注冊，數字證書認證機構用自己的私鑰加密服務器的公鑰，得到服務器的數字證書，并發給服務器，
2、在客戶端和服務器通信時，服務器把自己的CA證書發送給客戶端，
3、客戶端用數字證書認證機構的公鑰解密服務器的數字證書，得到服務器的公鑰，并用服務器的公鑰加密通信資訊，傳給服務器，
4、服務器用自己的私鑰解密客戶端傳來的密文，得到明文，
綜上：一共講述了三種加密演算法和三種基于這些加密演算法的加密機制，加密演算法：對稱加密演算法、非對稱加密演算法（公開密鑰加密演算法）和哈希演算法（摘要演算法）；加密機制：數字信封技術、混合加密機制、數字證書，
四、HTTPS是如何建立連接的？其間互動了什么？
在傳輸層，通過TCP協議的三次握手通信雙方建立連接之后，SSL/TLS 協議的握手階段涉及四次通信，
這四次的通信程序其一為了產生一個雙方都知道的會話密鑰，來加密通信的內容；其二是驗證服務器的真實身份，具體可見下圖：：
SSL/TLS 協議建立的詳細流程： step1. 客戶端發起加密通信請求 客戶端主要向服務器發送以下資訊：2個支持+1個亂數 （1）客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本， （2）客戶端支持的密碼套件串列，如公開密鑰加密演算法RSA 加密演算法， （3）第一個亂數，即客戶端生產的亂數（ Client Random ），后面用于生產“會話秘鑰”， step2. 服務端回應step1中的請求 服務器收到客戶端請求后，向客戶端發出回應 ，服務器回應的內容有如下內容：2個確認+一個亂數+CA證書 針對客戶端發來的支持的TLS協議版本和加密演算法串列，給出2個確認， （1）確認 SSL/ TLS 協議版本，如果瀏覽器不支持，則關閉加密通信， （2）確認使用密碼套件串列，如RSA 加密演算法， （3）第二個亂數，即服務器生產的亂數（ Server Random ），后面用于生產“會話秘鑰”， （4）服務器的CA證書，用來驗證服務器的真實身份， step3. 客戶端回應服務器 客戶端收到服務器的回應之后，首先通過事先內置于瀏覽器或者作業系統中的 CA 公鑰，解密服務器的CA證書，如果可以解密成功，說明服務器身份真實，不是釣魚網站，解密出來的明文就是服務器的公鑰，然后向服務器發送如下資訊：2個通知+2個資料， 2個通知： 1、加密通信演算法改變通知，隨后客戶端發出的資訊都將用“會話秘鑰”加密通信， 2、客戶端握手結束通知，表示客戶端的握手階段已經結束， 2個資料： 1、第三個亂數，即用服務器公鑰加密過的亂數（ pre-master key ），也就是亂數pre-master key的密文， 2、用摘要演算法把之前通信的所有資料做個摘要，發送給服務端，用來供服務器校驗， 以上這樣服務器和客戶端就同時有三個亂數，即客戶端亂數、服務器亂數和pre-master key，接著就用雙方協商定的加密演算法，各自生成本次通信的“會話秘鑰”，在產生會話密鑰之前，服務器需要用私鑰解密得到第三個亂數pre-master key， step4. 服務器的最后回應 向客戶端發生最后的資訊：2個通知+一個摘要 （1）加密通信演算法改變通知，表示隨后的資訊都將用會話秘鑰加密通信， （2）服務器握手結束通知，表示服務器的握手階段已經結束， （3）服務器同時把之前所有通信資料做個摘要，用來供客戶端校驗， 至此，整個 SSL/TLS 的握手階段全部結束， 接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用會話秘鑰加密內容，
綜合四次握手程序，
在第一次和第二次握手中，雙方互換了各自亂數給對方，協定了TLS版本和加密演算法，
在第二次握手中，服務器發送自己的CA證書給客戶端，客戶端解密出服務器的公鑰，驗證了服務器的真實身份，防冒充
在第三次握手中，客戶端用服務器的公鑰加密第三個亂數，使得通信雙方都有了產生會話密鑰的全部的、原始的資訊：三個亂數和加密演算法，這樣產生了對稱加密的密鑰，并且分發給了通信雙方，防竊聽
在第三次握手中，客戶端除了向服務器傳輸了第三個亂數的密文，還有所有通信資料的摘要，供服務器比對校驗，防篡改
在第四次握手中，服務器向服務器向客戶端傳輸了所有通信資料的摘要，供客戶端比對校驗，防篡改，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423662.html
標籤：其他
上一篇：PRML 基礎知識