一、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證書給客戶端。客戶端解密出服務器的公鑰。驗證了服務器的真實身份，防冒充
在第三次握手中，客戶端用服務器的公鑰加密第三個隨機數，使得通信雙方都有了產生會話密鑰的全部的、原始的信息：三個隨機數和加密算法，這樣產生了對稱加密的密鑰，並且分發給了通信雙方。防竊聽
在第三次握手中，客戶端除了向服務器傳輸了第三個隨機數的密文，還有所有通信數據的摘要，供服務器比對校驗，防篡改
在第四次握手中，服務器向服務器向客戶端傳輸了所有通信數據的摘要，供客戶端比對校驗，防篡改。
