Https和Http區別
WEB服務存在http和https兩種通信方式，http默認採用80作爲通訊端口，對於傳輸採用不加密的方式，https默認採用443，對於傳輸的數據進行加密傳輸
目前主流的網站基本上開始默認採用HTTPS作爲通信方式，一切的考慮都基於對安全的要求，那麼如何對自己的網站配置HTTPS通信，是本文着重介紹的
本文的主要內容包括：https加密傳輸的原理、如何申請https所用的CA證書，如何配置WEB服務支持https
https=http+ssl，顧名思義，https是在http的基礎上加上了SSL保護殼，信息的加密過程就是在SSL中完成的
首先我們先不談https，先從一個簡單的通訊原理圖講起：
http通信原理
客戶端發送一句client hello給服務器端，服務器端返回一句serverhello給客戶端，鑑於本文討論是https的加密主題，我們只討論信息傳輸的加密問題, 欲實現客戶端和服務端發送的信息client hello 和server hello，即使中間的包被竊取了，也無法解密傳輸的內容
http：client hello和server hello在通訊的過程中，以明文的形式進行傳輸，採用wireshark抓包的效果如下圖：
有沒有感覺這個的信息傳輸是完全暴露在互聯網上面，你請求的所有信息都可以被窺測到，不過不用擔心，我們的安全信息現在都是採用https的傳輸，後面講到https的時候大家心裏會頓時輕鬆。但這不是最關鍵的，http的傳輸最大的隱患是信息劫持和篡改，如下圖：
可以看到，http的信息傳輸中，信息很容易被×××給劫持，更有甚者，×××可以僞裝服務器將篡改後的信息返回給用戶，試想一下，如果×××劫持的是你的銀行信息，是不是很可怕。所以對於http傳出存在的問題可以總結如下：
（1）信息篡改：修改通信的內容
（2）信息劫持：攔截到信息通信的內容
這些是http不安全的體現，說完http，我們回到本文的主題https，看下人家是怎麼保護信息的，所有的請求信息都採用了TLS加密，如果沒有祕鑰是無法解析傳輸的是什麼信息
對於加密傳輸存在對稱加密和非對稱加密
對稱加密傳輸
當客戶端發送Hello字符串的時候，在進行信息傳輸前，採用加密算法（上圖中的祕鑰S）將hello加密程JDuEW8&*21!@#進行傳輸，即使中間被×××劫持了，如果沒有對應的祕鑰S也無法知道傳出的信息爲何物，在上圖中信息的加密和解密都是通過同一個祕鑰進行的，對於這種加密我們稱之爲對稱加密，只要A和B之間知道加解密的祕鑰，任何第三方都無法獲取祕鑰S，則在一定條件下，基本上解決了信息通信的安全問題。但在現實的情況下（www），實際的通訊模型遠比上圖複雜，下圖爲實際的通信模型
server和所有的client都採用同一個祕鑰S進行加解密，但大家思考下，如果這樣的話，無異於沒有加密，請做下思考
由於server和所有的client都採用同一個祕鑰S，則×××們作爲一個client也可以獲取到祕鑰S，此地無銀三百兩。所以在實際的通訊中，一般不會採用同一個祕鑰，而是採用不同的祕鑰加解密，如下圖
通過協商的方式獲取不同的祕鑰
如上圖，A和server通信採用對稱加密A算法，B和server通信採用對稱祕鑰B算法，因此可以很好的解決了不同的客戶端採用相同的祕鑰進行通訊的問題
那現在又存在問題了，A通過明文傳輸和server協商採用了加密算法A，但這條信息本身是沒有加密的，因此×××們還是可以竊取到祕鑰的，整個的通訊仍然存在風險。那該如何處理呢？有人說，把這條信息（協調祕鑰的過程）再次加密，那是不是還要協商加密祕鑰，如此反覆，永無止境。從根本上無法解決信息通訊的安全問題
如何對協商過程進行加密
非對稱加密
在密碼學跟對稱加密一起出現的，應用最廣的加密機制“非對稱加密”，如上圖，特點是私鑰加密後的密文，只要是公鑰，都可以解密，但是反過來公鑰加密後的密文，只有私鑰可以解密。私鑰只有一個人有，而公鑰可以發給所有的人。
基於上述的特點，我們可以得出如下結論：
（1）公鑰是開放給所有人的，但私鑰是需要保密的，存在於服務端
（2）服務器端server向client端（A、B.....）的信息傳輸是不安全的：因爲所有人都可以獲取公鑰
（3）但client端（A、B.....）向server端的信息傳輸確實安全的：因爲私鑰只有server端存在
因此，如何協商加密算法的問題，我們解決了，非對稱加密算法進行對稱加密算法協商過程。
在這裏我們做個小結：
信息通信採用http是不安全的，存在信息劫持、篡改的風險，https是加密傳輸，是安全的通信，對於https加密的過程，我們首先介紹的對稱加密，採用對稱加密進行通信存在祕鑰協商過程的不安全性，因此我們採用了非對稱加密算法解決了對協商過程的加密，因此https是集對稱加密和非對稱加密爲一體的加密過程
安全的獲取公鑰
細心的人可能已經注意到瞭如果使用非對稱加密算法，我們的客戶端A，B需要一開始就持有公鑰，要不沒法開展加密行爲啊。
這下，我們又遇到新問題了，如何讓A、B客戶端安全地得到公鑰？
client獲取公鑰最最直接的方法是服務器端server將公鑰發送給每一個client用戶，但這個時候就出現了公鑰被劫持的問題，如上圖，client請求公鑰，在請求返回的過程中被×××劫持，那麼我們將採用劫持後的假祕鑰進行通信，則後續的通訊過程都是採用假祕鑰進行，數據庫的風險仍然存在。在獲取公鑰的過程中，我們又引出了一個新的話題：如何安全的獲取公鑰，並確保公鑰的獲取是安全的， 那就需要用到終極武器了：SSL 證書（需要購買）和CA機構
如上圖所示，在第 ② 步時服務器發送了一個SSL證書給客戶端，SSL 證書中包含的具體內容有證書的頒發機構、有效期、公鑰、證書持有者、簽名，通過第三方的校驗保證了身份的合法，解決了公鑰獲取的安全性
以瀏覽器爲例說明如下整個的校驗過程：
- 瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
- 瀏覽器開始查找操作系統中已內置的受信任的證書發佈機構CA，與服務器發來的證書中的頒發者CA比對，用於校驗證書是否爲合法機構頒發
- 如果找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。
- 如果找到，那麼瀏覽器就會從操作系統中取出 頒發者CA 的公鑰，然後對服務器發來的證書裏面的簽名進行解密
- 瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中籤名做對比 (防止信息被修改)
- 對比結果一致，則證明服務器發來的證書合法，沒有被冒充, 此時瀏覽器就可以讀取證書中的公鑰，用於後續加密了
至此第一部分關於HTTPS的原理介紹已經結束了，總結一下：
HTTPS要使客戶端與服務器端的通信過程得到安全保證，必須使用的對稱加密算法，但是協商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務器不直接使用公鑰，而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通信安全問題。
證書的簽發過程：
- 服務方 S 向第三方機構CA提交公鑰、組織信息、個人信息(域名)等信息並申請認證；
- CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等；
- .如信息審覈通過，CA 會向申請者簽發認證文件-證書。
- 證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；
- 簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然後，採用 CA 的私鑰對信息摘要進行加密，密文即簽名；
- 客戶端 C 向服務器 S 發出請求時，S 返回證書文件；
- 客戶端 C 讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法；
- 客戶端然後驗證證書相關的域名信息、有效時間等信息；
- 客戶端會內置信任 CA 的證書信息(包含公鑰)，如果CA不被信任，則找不到對應 CA 的證書，證書也會被判定非法。
在這個過程注意幾點：
1.申請證書不需要提供私鑰，確保私鑰永遠只能服務器掌握；
2.證書的合法性仍然依賴於非對稱加密算法，證書主要是增加了服務器信息以及簽名；
3.內置 CA 對應的證書稱爲根證書，頒發者和使用者相同，自己爲自己簽名，即自簽名證書；
4.證書=公鑰+申請者與頒發者信息+簽名；
HTTPS的優點
儘管HTTPS並非絕對安全，掌握根證書的機構、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現行架構下最安全的解決方案，主要有以下幾個好處：
（1）使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
（2）HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程中不被竊取、改變，確保數據的完整性。
（3）HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
（4）谷歌曾在2014年8月份調整搜索引擎算法，並稱“比起同等HTTP網站，採用HTTPS加密的網站在搜索結果中的排名將會更高”。
HTTPS的缺點
雖然說HTTPS有很大的優勢，但其相對來說，還是存在不足之處的：
（1）HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；
（2）HTTPS連接緩存不如HTTP高效，會增加數據開銷和功耗，甚至已有的安全措施也會因此而受到影響；
（3）SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。
（5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。
對稱算法和非對稱算法舉例：
算法選擇：對稱加密AES，非對稱加密: ECC，消息摘要: MD5，數字簽名:DSA
對稱加密算法(加解密密鑰相同)
|
名稱 |
密鑰長度 |
運算速度 |
安全性 |
資源消耗 |
|
DES |
56位 |
較快 |
低 |
中 |
|
3DES |
112位或168位 |
慢 |
中 |
高 |
|
AES |
128、192、256位 |
快 |
高 |
低 |
非對稱算法(加密密鑰和解密密鑰不同)
|
名稱 |
成熟度 |
安全性(取決於密鑰長度) |
運算速度 |
資源消耗 |
|
RSA |
高 |
高 |
慢 |
高 |
|
DSA |
高 |
高 |
慢 |
只能用於數字簽名 |
|
ECC |
低 |
高 |
快 |
低(計算量小,存儲空間佔用小,帶寬要求低) |
散列算法比較
|
名稱 |
安全性 |
速度 |
|
SHA-1 |
高 |
慢 |
|
MD5 |
中 |
快 |
對稱與非對稱算法比較
|
名稱 |
密鑰管理 |
安全性 |
速度 |
|
對稱算法 |
比較難,不適合互聯網,一般用於內部系統 |
中 |
快好幾個數量級(軟件加解密速度至少快100倍,每秒可以加解密數M比特數據),適合大數據量的加解密處理 |
|
非對稱算法 |
密鑰容易管理 |
高 |
慢,適合小數據量加解密或數據簽名 |
算法選擇(從性能和安全性綜合)
對稱加密: AES(128位),
非對稱加密: ECC(160位)或RSA(1024),
消息摘要: MD5
數字簽名:DSA
輕量級：TEA、RC系列（RC4），Blowfish （不常換密鑰）
速度排名（個人估測，未驗證）：IDEA <DES <GASTI28<GOST<AES<RC4<TEA<Blowfish
簡單的加密設計： 用密鑰對原文做 異或，置換，代換，移位
參考博客 :
https://blog.csdn.net/qq_34337272/article/details/78334155
https://blog.csdn.net/weixin_42504145/article/details/85207103