https爲什麼更加安全

與https相比較來講http存在如下幾點不足:  

1.不驗證通訊方的身份，所以有可能遭遇假裝。  

2.通訊使用明文（不加密），內容可能會被竊聽。  

3.沒法證實報文的完整性，因此有可能已遭篡改。  

下面分這三方面來講明https如何在這三方面有所增強的。

1 通訊方身份：

        在配置https時，首先咱們應該到CA機構去購買一個ssl證書，咱們來看一下阿里雲上購買證書的流程：

        由於證書購買過程是要通過第三方CA（Certificate Authority）機構來進行域名驗證，因此這個第三方機構所發的證書是有公信力的。而咱們的瀏覽器中對於經常使用證書的CA機構是會預先存儲一份名單的，好比打開12306官網後點擊地址欄前"鎖"的標誌能夠看到：

        證書的頒發機構爲DigiCert，因此瀏覽器纔會認爲這是一個受信任的網站。而若是是咱們本身生成的證書，就不會被瀏覽器識別成可信的網站，仍是會提示用戶登陸有風險。當咱們在網站上下載證書的時候，會有兩個文件，.key和.pem文件，.key經過編輯器打開能夠看到'-----BEGIN RSA PRIVATE KEY-----'的開頭，即爲RSA非對稱加密算法加密的私鑰文件，.pem經過編輯器打開能夠看到'-----BEGIN CERTIFICATE-----'的開頭，即爲公鑰文件。

2 通訊方身份：

        首先，咱們先來看一下https創建鏈接的過程以下：

        上圖中省略了TCP的三次握手，在TCP三次握手以後，ssl協議的鏈接過程大致爲：

        1.客戶端先給服務端發送一個消息，消息內容包括：客戶端支持的加密方式，支持的壓縮方法，SSL的版本號，客戶端生成的隨機數，文本內容「Hello」等；  

        2.服務端接收到消息後，也回發一個Hello，並攜帶從客戶端支持的加密方式中選擇的加密方式，服務端生成的隨機數，服務端的SSL版本號等信息；  

        3.隨後服務器給客戶端發送一個Certificate報文，報文中包含服務端的公鑰證書；  

        4.緊接着服務器給客戶端發送Server Hello Done, 表示最初的協商握手過程結束；  

        5.客戶端接收到服務端發送的握手結束的消息後，以Client Key Exchange做爲迴應，此報文中包含通訊加密過程當中使用的一種被稱爲Pre-master secret的隨機密碼串，並使用第三步接收到的公鑰證書進行了加密；  

        6.接着客戶端發送Change Cipher Spec報文，該報文告知服務端，此步驟以後的全部數據將使用第五步中生成的master secret進行加密（master secret的生成過程看後面的介紹）；  

        7.隨後客戶端發送Finish報文，此報文中包含鏈接至今全部報文的總體校驗值，用於完整性驗證；  

        8.服務端接收到客戶端發送的Change Cliper Spec報文後，一樣以Change Cliper Spec報文做爲迴應；  

        9.接着服務端發送Finish報文給客戶端，表示服務端已正確解析客戶端發送的總體校驗值，至此，SSL握手的過程結束。  

        10.隨後開始使用HTTP協議傳輸使用master secret加密過的數據。

說明：

        1.前兩步是協商加密算法以及傳輸各自生成的隨機數（爲後續生成master secret作準備）的過程；  

        2.服務端收到客戶端發送的Change Cipher Spec（第五步），會使用本身的私鑰進行解密，獲取報文中的Pre-master secret，這時通訊雙方都擁有對方的Random(前兩步生成的)，Pre-master secret，以及自身的Random, 將三個數做爲種子經過算法生成master secret, 用來加密後續Http請求過程當中的數據。其中master secret的生成規則爲:

master_secret =

MD5(pre_master_secret + SHA('A' + pre_master_secret +

ClientHello.random + ServerHello.random)) +

MD5(pre_master_secret + SHA('BB' + pre_master_secret +

ClientHello.random + ServerHello.random)) +

MD5(pre_master_secret + SHA('CCC' + pre_master_secret +

ClientHello.random + ServerHello.random));

        這裏涉及到兩種加密方式，加密密鑰和解密密鑰相同的即爲對稱加密，不一樣的即爲非對稱加密。在第5步中客戶端發送Pre-master secret是經過公鑰加密過的，而服務端收到之後要經過私鑰來進行解密，因此傳送Pre-master secret的過程爲非對稱加密。然後續傳送http消息的過程，服務端和客戶端用的都是master_secret進行加密和解密，因此是對稱加密。爲什麼用兩種加密方式呢？由於非對稱加密安全性要更高，即便***者拿到了公鑰，沒有私鑰的話也沒法對加密後的Pre-master secret進行解密。可是非對稱加密成本較高，計算量較大比較耗費CPU，因此只對交換Pre-master secret採用了非對稱加密，然後續http傳輸的過程當中，master_secret不會在網絡中進行傳輸，因此能夠採用對稱加密，成本也較低。

3 完整性

        如何實現完整性呢？實現完整性的手段主要是摘要算法。其實經常使用的MD5就是一種摘要算法，MD5可用於從任意長度的字符串建立128位字符串值，最經常使用於驗證文件的完整性。而目前最經常使用的摘要算法還有SHA-2（Secure Hash Algorithm 2），他能夠生成22四、25六、384或512位的哈希值來驗證文件完整性。可是SHA-2畢竟是一種基於明文的加密方式，仍是不夠安全。在通訊中咱們仍是須要經過MAC來驗證信息的完整性，它是經過MAC算法從消息和密鑰生成，能夠檢測到消息內容的更改，來保護數據完整性。HMAC是MAC更進一步的擴展，它是使用MAC值+Hash值的組合方式，計算中可使用任意長度的Hash函數。

參考：

https://segmentfault.com/a/1190000022012971

https://juejin.im/post/6844903602494898183

《圖解HTTP》