1.HTTP的痛點

超文本傳輸協議HTTP通常用于在客戶端和服務器端進行通信。但是，由于HTTP在發送消息時，不會對信息進行任何形式的加密，因此，可以說：在客戶端和服務器端之間來回穿梭的消息都是處于“裸奔”狀態。可以試想一下，我們的一舉一動一切信息就這樣隨時都有可能被人偷窺。因此，HTTP不適合一些敏感信息（如密碼、交易等）的傳送。這是HTTP最大的痛點所在——不安全。

2.HTTPS相對于HTTP的改進

既然HTTP協議那么不安全，一個相對安全的HTTPS協議便誕生了。
HTTPS是在HTTP的基礎上，又加入了SSL層，SSL層才是HTTPS安全性的關鍵所在。那么，SSL又是怎么保證安全性的呢？
總的來說，SSL層主要從兩個方面保證了安全性：加密信息傳輸和身份驗證。

2.1 加密信息傳輸

說到加密，有必要說說兩種常見的加密方式：對稱加密和非對稱加密。

• 對稱加密
  顧名思義，這種加密方式中加密和解密方式是對稱的，信息的加密和解密共用一個秘鑰key。通常是發送方和接收方首先約定一個秘鑰key，然后雙方用同一個key進行相互通信。
  那么問題來了：發送方和接收方如何約定這個共同的秘鑰key呢？你可能會說：發送方發送信息的時候，直接把密鑰連同信息一起發過去好了，可是，中間的惡意攔截者也可以輕松拿到密鑰，并且拿到key之后也能輕松解密信息。
  看到了吧，這種加密方法的癥結就在于加密和解密都共用同一個密鑰，惡意中間方拿到key之后可以輕易解密信息。發送方和接收方無法約定密鑰，因為在信息世界，無論你怎么搞，約定密鑰過程中都有可能被惡意中間方竊取到密鑰，有了密鑰就有了解開信息的鑰匙！
• 非對稱加密
  與對稱加密不同，非對稱加密會生成兩個密鑰：公鑰和私鑰。二者就像是磁鐵正負兩級：一段信息經過公鑰加密，只有私鑰才能解開；經過私鑰加密，只有公鑰才能解開。
  這下好了，有了這種非對稱加密算法，我們再來看看發送方和接收方約定密鑰key的問題。
  假設通信雙方為A和B

• A首先生成公鑰PubKey和私鑰PriKey。
• A將私鑰留在自己手里，只把公鑰PubKey發送給B（惡意中間方竊取到PubKey并沒什么用，因為PubKey加密的信息，只有PriKey才能解開，而PriKey在發送方手里！）。
• B收到公鑰PubKey后，生成一個密鑰key，并將其用PubKey加密，發送回給A。
• A收到后，用自己的私鑰PriKey解開，得到B之前生成的key。
  這樣A和B便完成了一次密鑰key的信息交換，達到了通信雙方約定key的目的。

約定key完成之后，發送方和接受方將采用對稱加密的方式進行后續的通信。

image.png

SSL層就是首先采用非對稱加密完成雙方約定key的過程，然后再使用對稱加密的方式進行后續通信。

那么，為什么不直接用非對稱加密來加密信息，而是通過非對稱加密約定key，然后用key進行對稱加密信息呢？原因在于非對稱加密和解密的耗時比較長，因此為了提高效率，通常只用非對稱加密交換密鑰，真正的信息通信還是利用對稱加密。

2.2 身份驗證

2.1中提到SSL通過非對稱加密和對稱加密相結合的方式，實現信息的加密傳輸。但是，仍然存在被惡意中間層惡意攻擊的危險。
看下面這種場景：
假設A和B要進行通信：

• A生成公鑰和私鑰，然后把公鑰發給B。
• 中間者M偽裝為B，并生成一個key，利用公鑰加密，發回給A；這樣，A以為和B建立了聯系，實際上卻是和M進行通信。

• 同時M自己生成另外一對公鑰和私鑰，將自己偽裝成A，和B進行一次密鑰交換。這樣，B以為自己和A建立了聯系，實際上卻是和M進行通信。

  
  
  image.png

這種情況下，M通過偽裝，依然可以竊取A和B之間的通信信息。

為了解決身份認證的問題，SSL層引入了一個非常權威的第三方，我們稱這個第三方為CA(Certificate Authority)。各個網站服務商可以向CA申請證書，CA則向網站服務商頒發證書。這樣，以后網站之間在建立連接時帶上他們的證書簽名，如果只有建立連接的網站有合法的證書，才會被瀏覽器認為是安全的（瀏覽器安裝時，會帶有一個默認的安全的CA證書列表）。
那么，CA的證書可以完全信任嗎？擁有它證書的網站就一定是安全的嗎？答案是不一定，但通常情況下，是值得信任的。一旦某個CA頒發的某個證書被發現非法，那么這個CA頒發過的所有證書都會被認為非法，因此在這種懲罰措施下，CA頒發證書都會比較嚴格。

2.3 HTTPS工作原理

基于前面所說的“加密信息傳輸”和“身份驗證”，HTTPS的工作原理就很容易理解了。我們詳細看一下HTTPS的工作流程。
STEP1：首先，由客戶端發起HTTPS請求。客戶端發起請求時，會帶上自己支持的加密規則和Hash算法列表。

HTTPS一般使用的加密與HASH算法如下：

• 非對稱加密算法：RSA，DSA/DSS
• 對稱加密算法：AES，RC4，3DES
• HASH算法：MD5，SHA1，SHA256

STEP2：服務器端收到客戶端請求后，從客戶端提供的加密規則列表中選擇一組加密算法和HASH算法，并將自己的身份信息通過證書的形式發送給客戶端。（證書信息包括：服務器地址、加密公鑰、頒發機構等信息）。
STEP3：客戶端收到證書信息，校驗證書的合法性（瀏覽器有一個合法證書機構列表）。如果校驗證書是合法的或者客戶端用戶選擇信任不安全的證書，則客戶端會生成一個隨機的key，并用證書中提供的公鑰加密。
STEP4：客戶端將加密過后的key加密之后，發送給服務器端。
STEP5：服務器端收到之后，用證書中的私鑰解密，得到key。這樣，客戶端和服務器端就完成了一次密鑰交換。
STEP6：客戶端和服務器端的以后通信都采用key進行對稱加密的方式來進行。