結合最近做支付遇到的一些問題,以及查閱的一些資料，整理了一下https的安全實現；希望多家多多支持！
1.Https的產生背景:
我們最開始用的較多的是HTTP協議用于數據傳輸,但是http數據是明文傳輸,這對于比如支付、轉賬等場景是不安全的,
很容易被第三方竊取并篡改參數信息,造成無法挽回的損失.
2.Https與http的不同
Https與http最的不同是把下層的協議由 TCP/IP 換成了 SSL/TLS(TLS可以理解為SSL的前身),而SSL/TLS 是信息安全領域中的權威標準，
采用多種先進的加密技術保證通信安全;OpenSSL 是著名的開源密碼學工具包，是 SSL/TLS 的具體實現；
3.Https特性及其關鍵詞介紹
特性:
機密性、完整性、身份認證、不可否認; 通常實現了這四個特性,我們就基本可以保證數據傳輸是‘安全’的了；
機密性：指的是傳輸的信息不能隨意給某人看,只有可信任的人能看到；
完整性：指的是服務器接收到你傳輸的數據是沒有被修改過的,比如去掉了數據的某些部分；
身份認證：指的是發送數據的客戶端怎么證明我就是我,不一樣的花朵,讓接收方(服務器)可以識別你的身份；
不可否認：也是就你發出的數據無法抵賴；
關鍵詞：
對稱加密、非對稱加密、摘要、數字簽名、數字證書
對稱加密：也就是加密和解密用的是同一個秘鑰，常見對稱加密算法：AES、ChaCha20
非對稱加密：加密和解密用的不是同一個秘鑰,也就是出現了'私鑰'和'公鑰'的概念,對于服務器私鑰只有一個,必須嚴格保密，而公鑰可以有很多個,隨意分發給客戶端
常用的非對稱加密算法：DSA、RSA(常用)、ECC
注意:公鑰和私鑰有個特別的“單向”性，雖然都可以用來加密解密，但公鑰加密后只能用私鑰解 密，反過來，私鑰加密后也只能用公鑰解密。
這里提個2個問題：
1.為什么有了對稱加密還需要非對稱加密呢？
2.我們使用的https協議到底是使用對稱加密還是非對稱加密呢？
問題先放這,原理剖析中會一 一解答；
摘要：這個主要可以保證上面說的數據完整性,也就是數據沒有被篡改，生成唯一"指紋"，可以與我們常說的"加鹽"結合使用；與服務器協商規則即可；
數字簽名：可以作為服務器識別用戶的真實身份,證明我是我，一般也就是通過秘鑰給摘要加密就可以實現；
數字證書：由第三方認證機構頒發，具有高信任度的，由它來給各個公鑰簽名，用自身的信譽來保證公鑰無法偽造，是可信的；
4.Http實現原理剖析
=========== 好了，重點來了===========
我們先從上面的問題引入:為什么有了對稱加密還需要非對稱加密呢？
前面提到 對稱加密加密和解密用的是同一個秘鑰,基于此如果用對稱加密，那如果別黑客攔截,那就可以隨意解密我們的數據，
這就要求我們客戶端與服務器要約定一種只有對方可以破解的公鑰和私鑰,也就是非對稱的加密方式;
那么問題來了........... 我們如何約定客戶端和服務器加密規則呢？何如解決服務器的公鑰安全的傳輸呢？
如果再用非對稱進行加密一層呢？那是不是還要一層一層有一層..... 形成俄羅斯套娃啦......
直接上結論:我們可以用非對稱加碼來約定雙方的傳輸秘鑰規則,約定好之后就可以通過對稱加密來傳輸數據
流程如下(圖片來源網絡):
1.客戶端發起https請求,服務端返回Ca證書,包含公鑰的信息
2.客戶端收到返回內容,會對證書進行校驗(瀏覽器自帶機制)，如果此時被黑客攔截,篡改了證書內容，則會進行告警提示
3.客戶端生成隨機數+摘要等等信息通過證書中的公鑰進行加密傳輸給服務端，此時即使黑客攔截，因為沒有私鑰，也無法進行解密
4.服務端解密,并通過客戶端傳入的隨機數構造對稱加密算法，對返回結果內容進行加密后傳輸(這一步就約定好了對稱加密算法,完成對稱秘鑰傳輸)
5.雙方可以通過約定好的算法進行加密傳輸數據
5.小結
1.https用了對稱加密和非對稱加密兩種算法,非對稱加密解決了"秘鑰交換"的問題,對稱加密則用于真正的數據傳輸;
2.非對稱加密的效率要遠遠低于對稱加密,所以兩者一般混合使用;
3. 摘要算法用來實現完整性，能夠為數據生成獨一無二的“指紋”，常用的算法是 SHA2；
4. 數字簽名是私鑰對摘要的加密，可以由公鑰解密后驗證，實現身份認證和不可否認；
5. 公鑰的分發需要使用數字證書，必須由 CA 的信任鏈來驗證，否則就是不可信的；
6. 作為信任鏈的源頭 CA 有時也會不可信，解決辦法有 CRL、OCSP，還有終止信任;
6.借助一張經典的網絡圖
