前言
本篇文章會主要介紹網路中資料安全傳輸，加密演算法，Https如何保證資料傳輸安全,SSL證書決議，CA認證流程，OpenSSL，Nginx中實作高性能Https，
資料加密技術
加密演算法之對稱加密（AES加密） 及在jdk中應用_踩踩踩從踩的博客-CSDN博客_jdk對稱加密
加密演算法之安全hash演算法、RSA非對稱加密演算法分析_踩踩踩從踩的博客-CSDN博客
都是從原理上去分析幾個加密技術，包括對稱加密、一致性hash演算法、非對稱加密，
Http安全性能
HTTP
HTTP協議，即超文本傳輸協議(Hypertext transfer protocol)，是一種詳細規定了瀏覽器和萬維網
(WWW = World Wide Web)服務器之間互相通信的規則，通過因特網傳送萬維網檔案的資料傳送協議，
如果單從傳輸中來說，http是很好的傳輸協議，因為它在請求頭上面，添加了包括cookie 長連接標識、資料大小、請求型別、請求資源等等，在資料傳遞上，非常好用，
但它是在網路中傳輸，特別是在互聯網的環境下
明文傳輸，容易泄密，容易被攔截
在瀏覽器中就能清晰的看到，
因此產生了對資料進行加密，加密技術 ；https的產生
摘要演算法
訊息摘要演算法用來驗證資料的完整性，分為三類
- MD(Message Digest)：訊息摘要
- SHA(Secure Hash Algorithm)：安全散列
- MAC(Message Authentication Code)：訊息認證碼
最常見的登錄密碼加密處理，MD5加密，MD5屬于訊息摘要類，
可以用來保證內容不被篡改：密碼加密、檔案校驗碼
對稱加密
DES(Data Encryption Standard，資料加密演算法)
PBE(Password-based encryption，基于密碼驗證)
非對稱加密
RSA(演算法的名字以發明者的名字命名：Ron Rivest, AdiShamir 和Leonard Adleman)
DH(Diffie-Hellman演算法，密鑰一致協議)
DSA(Digital Signature Algorithm，數字簽名)
ECC(Elliptic Curves Cryptography，橢圓曲線密碼編碼學)
用在不可信的環境下
Https協議
SSL/STL
- SSL(Secure Socket Layer 安全套接層)是基于HTTPS下的一個 協議加密層，HTTP在傳輸資料時使用的是明文，是不安全的，為了解決這一隱患網景公司推出了SSL安全套接字協議層，SSL是基于HTTP之下TCP之上的一個協議層，是基于HTTP標準并對TCP傳輸資料時進行加密，所以HPPTS是HTTP+SSL/TCP的簡稱，
- TLS(Transport Layer Security)即安全傳輸層協議，保障應用程式之間通信的安全性，SSL 3.0版本改名叫TLS，所以TLS是從SSl轉過來的，
把明文變成密文進行加密，
HTTPS
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer超文本傳輸安全協議），是以安全為目標的HTTP通道，簡單講是HTTP的安全版，HTTP下加入SSL層，HTTPS的安
全基礎是SSL，因此加密的詳細內容就需要SSL，
Https協議架構組成
安全保證：
- 身份認證，認證用戶或服務器，確保資料 發送到正確的客戶機或服務器
- 內容加密，加密資料以防止資料中途被竊取，防止被竊取，
- 資料完整性，維護資料的完整性，確保數 據在傳輸程序中不被篡改
兼容不只是用在http上面，也包括ftp ，mqtt協議呀，redis協議等等，
HTTPS完全基于SSL/TLS實作3點安全保證
- SSL/TLS在握手階段依賴數字證書建立安全會話
-
數字證書包含一個非對稱加密生成的公鑰、一個對自己的數字簽名
-
SSL/TLS在傳輸階段使用對稱加密
- 數字簽名依賴非對稱加解密、數字摘要
對數字進行簽名，數字摘要，
Https與Http的區別
- https協議需要到CA申請數字證書，
- http是超文本傳輸協議，資訊是明文傳輸；https 則是具有安全性的ssl加密傳輸協議，
- http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，后者是 443，
- http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、 身份認證的網路協議，比http協議安全
HTTPS對資料進行加解密，決定了它比http慢
Https如何保證資料傳輸安全
SSL/TLS的握手程序—秘鑰協商
- 在請求連接時，支持的協議版本，支持的加密和壓縮演算法，并產生亂數，給服務端；
- 服務端確定要加密協議版本和加密演算法，服務器的證書，產生亂數 ，回傳給客戶端 生成私鑰
- 公鑰加密后的亂數 編碼改變 握手結束
-
編碼改變通知 ，三個亂數產生的密鑰
-
對稱加密進行資料傳輸
Https協議安全保證的原因
SSL協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密，也就是說在SSL上傳送的資料是使用對稱密鑰加密的！因為非對稱加密的速度緩慢，耗費資源，
- 其實當客戶端和主機使用非對稱加密方式建立連接后，客戶端和主機已經決定好了在傳輸程序使用的對稱加密演算法和關鍵的對稱加密密鑰，由于這個程序本身是安全可靠的，也即對稱加密密鑰是不可能被竊取盜用的，因此，保證了在傳輸程序中對資料進行對稱加密也是安全可靠的，因為除了客戶端和主機之外，不可能有第三方竊取并解密出對稱加密密鑰！
- 如果有人竊聽通信，他可以知道雙方選擇的加密方法，以及三個亂數中的兩個，整個通話的安全，只取決于第三個亂數能不能被破解，
https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加
密、非對稱加密、證書，等技術進行客戶端與服務器的資料加密傳輸，最終達到保證整個通信的
安全性，
SSL證書
CA和數字證書
怎么能確定客戶端所得到的公鑰一定是從目標主機那里發布的，而且沒有被篡改過呢？
需要有一個權威的值得信賴的第三方機構CA(一般是由政府審核并授權的機構)來統一對外發放主
機機構的公鑰，只要請求方這種機構獲取公鑰，就避免了上述問題的發生，
數字證書的頒發程序
用戶首先產生自己的密鑰對，并將公共密鑰及部分個人身份資訊傳送給認證中心，認證中心在核
實身份后，將執行一些必要的步驟，以確信請求確實由用戶發送而來，然后，認證中心將發給用戶一 個數字證書，該證書內包含用戶的個人資訊和他的公鑰資訊，同時還附有認證中心的簽名資訊(根證書 私鑰簽名)，用戶就可以使用自己的數字證書進行相關的各種活動，數字證書由獨立的證書發行機構發布，數字證書各不相同，每種證書可提供不同級別的可信度，
瀏覽器CA認證流程
瀏覽器默認都會內置CA根證書，其中根證書包含了CA的公鑰
- 證書頒發的機構是偽造的：瀏覽器不認識，直接認為是危險證書 證書頒發的機構是確實存在的，于是根據CA名，找到對應內置的CA根證 書、CA的公鑰，用CA的公鑰，對偽造的證書的摘要進行解密，發現解不了，認為是危險證書，
- 對于篡改的證書，使用CA的公鑰對數字簽名進行解密得到摘要A，然后 再根據簽名的Hash演算法計算出證書的摘要B，對比A與B，若相等則正常， 若不相等則是被篡改過的，
- 證書可在其過期前被吊銷，通常情況是該證書的私鑰已經失密，較新的 瀏覽器如Chrome、Firefox、Opera和Internet Explorer都實作了在線 證書狀態協議（OCSP）以排除這種情形：瀏覽器將網站提供的證書的序列號通過OCSP發送給證書頒發機構，后者會告訴瀏覽器證書是否還是有效的，
1、2點是對偽造證書進行的，3是對于篡改后的證書驗證，4是對于過期失效的驗證，
OpenSSL
OpenSSL是個多功能命令列工具、他可以實作加密解密、甚至還可以當CA來用、可以讓你創建證書、吊銷證書，
OpenSSL由應用、TLS、加密、引擎四個組 件層組成，加密組件通過引擎組件來擴展，
TLS依賴加密組件，應用組件則依賴TLS和加密組件，
制作證書
SSL 證書就是遵守 SSL協議，由受信任的數字證書頒發機構CA，在驗證服務器身份后頒發，具有服務器身份驗證和 資料傳輸加密功能的檔案，當前大多數的ssl證書是收費的，
通過OpenSSL自建一個CA服務，自己給自己的服務辦法數字證書
生成 一個 ssl證書 提取碼：s5xe
準備工具
安裝keytool（jdk自帶）、openssl、nginx、web服務
有兩種方法生成數字證書，一種是用JDK帶的keytool，另一種是用openssl，
大致流程為上面的，
Nginx中配置HTTPS
找到nginx運行的組態檔，將服務器證書servercert.pem、鑰serverkey.pem、ca根證書cacert.pem放到配置目錄下，修改內容如下
http {
# 配置https服務
server {
# 開啟443埠，ssl安全協議
listen 443 ssl;
server_name localhost;
# 配置證書及服務器私鑰
ssl_certificate servercert.pem;
ssl_certificate_key serverkey.pem;
ssl_client_certificate cacert.pem; # 根級證書公鑰，用于驗證各個二級client
ssl_verify_client on; #開啟客戶端證書驗證
# 會話引數的快取,所有作業行程之間共享的快取
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# 啟用的密碼
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
# SSLv3和TLS協議時,服務器密碼優先于客戶端密碼
ssl_prefer_server_ciphers on;
location / {
root /data/www/;
index welcome.html;
}
}
}Nginx https 雙向認證 - i野老i - 博客園 (cnblogs.com)
這在官方核心檔案中就有配置方式
Https服務的優化
優化方法
SSL操作消耗額外的CPU資源，在多處理器系統上，應該運行多個作業行程，而不小于可用CPU核的數量，CPU密集型操作
是SSL握手，有兩種方法可以使每個客戶端的這些操作的數量最小化：
第一個是通過啟用Keepalive連接來通過一個連接發送多個請求，
第二個是重用SSL會話引數，以避免用于并行和后續連接的SSL握手，
Nginx中為了減少處理器負載，建議
- 1. 將作業行程的數量設定為等于處理器的數目，worker_processes
- 2. 啟用維持生命的連接，keepalive_timeout
- 3. 啟用共享會話快取，禁用內置會話快取，ssl_session_cache shared:SSL:10m; off，禁用、 none，客戶端可重用服務端不快取builtin，在openssl中重構快取，`builtin`[:`size`] shared，在worker行程間共享的快取，`shared`:`name`:`size`
- 4. 增加會話生存期(默認為5分鐘)，ssl_session_timeout
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/344113.html
標籤：其他