Https和Http區別

眾所周知，WEB服務存在http和https兩種通訊方式，http預設採用80作為通訊埠，對於傳輸採用不加密的方式，https預設採用443，對於傳輸的資料進行加密傳輸

目前主流的網站基本上開始預設採用HTTPS作為通訊方式，一切的考慮都基於對安全的要求，那麼如何對自己的網站配置HTTPS通訊，是本文著重介紹的

本文的主要內容包括：https加密傳輸的原理、如何申請https所用的CA證書，如何配置WEB服務支援https

1、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&*

[email protected]#進行傳輸，即使中間被×××劫持了，如果沒有對應的祕鑰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 證書中包含的具體內容有證書的頒發機構、有效期、公鑰、證書持有者、簽名，通過第三方的校驗保證了身份的合法，解決了公鑰獲取的安全性

以瀏覽器為例說明如下整個的校驗過程：

（1）首先瀏覽器讀取證書中的證書所有者、有效期等資訊進行一一校驗

（2）瀏覽器開始查詢作業系統中已內建的受信任的證書釋出機構CA，與伺服器發來的證書中的頒發者CA比對，用於校驗證書是否為合法機構頒發 

（3）如果找不到，瀏覽器就會報錯，說明伺服器發來的證書是不可信任的。

（4）如果找到，那麼瀏覽器就會從作業系統中取出  頒發者CA  的公鑰，然後對伺服器發來的證書裡面的簽名進行解密

（5）瀏覽器使用相同的hash演算法計算出伺服器發來的證書的hash值，將這個計算的hash值與證書中籤名做對比

（6）對比結果一致，則證明伺服器發來的證書合法，沒有被冒充

（7）此時瀏覽器就可以讀取證書中的公鑰，用於後續加密了

 

 

至此第一部分關於HTTPS的原理介紹已經結束了，總結一下：

HTTPS要使客戶端與伺服器端的通訊過程得到安全保證，必須使用的對稱加密演算法，但是協商對稱加密演算法的過程，需要使用非對稱加密演算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與伺服器不直接使用公鑰，而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密演算法，就此雙方使用該演算法進行加密解密。從而解決了客戶端與伺服器端之間的通訊安全問題。

 

 

---

 

對稱演算法和非對稱演算法舉例：

 

演算法選擇：對稱加密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://www.cnblogs.com/qiangxia/p/5261813.html