Https協議簡介

 本篇博文的目錄：

一：Http協議的優勢與缺點

二：Https協議的特色

三：Https協議採用的加密技術

四：Https的安全通訊機制

五：爲何還有不少網站不使用Https

六：總結

 

一：Http協議的優勢與缺點

1.1：http協議的優勢

1.1.:效率高

限制每一個鏈接只有一個請求的無鏈接狀態，在服務器處理完客戶的請求，並收到客戶的反應，即斷開，經過這種方式能夠節省傳輸時間。

1.1.2: 簡單快速

當服務器客戶端請求服務時，只需傳送請求方法和路徑。請求方法經常使用的GET，HEAD，POST。每種方法規定了客戶端與服務器聯繫的是不一樣的類型。由於簡單的 HTTP 協議，通訊速度很快。

1.1.3: 靈活

HTTP 容許任何類型的數據對象的傳輸，輸入被傳輸的內容類型進行標記。

1.1.4：無狀態

HTTP 協議是無狀態的協議，沒有一個國家是沒有協議的事務處理和存儲能力。若是該狀態是指因爲缺少必要前述信息的後續處理中，它必須被重傳，這可能致使在數據傳輸增長了每一個鏈接。另外一方面，當不須要在服務器上的快速響應的先驗信息。

 

1.2:Http協議的缺點

1.2.1：有被竊聽的風險，Http通訊使用明文,傳輸過程當中沒有任何的保證措施，可能會被竊聽

1.2.2：在傳輸過過程當中，不驗證通訊方的身份，這中間就有可能被遭遇假裝

1.2.3：Http只是對報文進行了解析，並無對其進行完整的校驗，因此沒法驗證報文的完整形，可能被遭篡改

 

二：Https協議的特色

2.1：Https簡介

Https並非一個嶄新的協議，而是在http的基礎上發展而來，意爲http Secure.至關因而Http的升級版。它主要是爲了解決http協議安全性不足的問題而誕生的。在使用https以後，訪問瀏覽器的時候前綴由http變爲https，如今咱們看到網站都採用https的協議比比皆是，好比：以下都是https的網站：

 

 

可見https已經深入的滲入到咱們的常常訪問的網站中了，而關於它，本篇博文就來探討一下http協議如何變爲https.

2.2:Http+加密+認證+完整性保護=https

   Https的通訊端口由SSL和TSL代替了，它是一種應用層協議。通常的狀況下http直接和Tcp進行通訊，當使用了SSL以後，就會變成先和SSL通訊，SSL再和Tcp進行通訊，原理圖以下：

當採用了SSL協議以後，Http協議就具有了加密、證書、完整性保護三大功能，SSL是獨立於Http存在的，它是現存的普遍使用的網絡安全技術。

 

三：Https協議採用的加密技術

3.1：SSL採用的加密技術

   SSL採用的加密技術叫作「共享密鑰加密」，也叫做「對稱密鑰加密」，這種加密方法是這樣的，好比客戶端向服務器發送一條信息，首先客戶端會採用已知的算法對信息進行加密，好比MD5或者Base64加密，接收端對加密的信息進行解密的時候須要用到密鑰，中間會傳遞密鑰，（加密和解密的密鑰是同一個），密鑰在傳輸中間是被加密的。這種方式看起來安全，可是仍有潛在的危險，一旦被竊聽，或者信息被挾持，就有可能破解密鑰，而破解其中的信息。所以「共享密鑰加密」這種方式存在安全隱患：

 

3.3.2：非對稱密鑰加密

   「非對稱加密」使用的時候有兩把鎖，一把叫作「私有密鑰」，一把是「公開密鑰」，使用非對象加密的加密方式的時候，服務器首先告訴客戶端按照本身給定的公開密鑰進行加密處理，客戶端按照公開密鑰加密之後，服務器接受到信息再經過本身的私有密鑰進行解密，這樣作的好處就是解密的鑰匙根本就不會進行傳輸，所以也就避免了被挾持的風險。就算公開密鑰被竊聽者拿到了，它也很難進行解密，由於解密過程是對離散對數求值，這可不是垂手可得就能作到的事。如下是非對稱加密的原理圖：

 

 

四：Https的安全通訊機制

4.1：非稱加密方式的缺點

公開密鑰加密當然比共享密鑰加密的方式提高了一個檔次，可是它也存在兩個問題：

第一個是：如何保證接收端向發送端發出公開祕鑰的時候，發送端確保收到的是預先要發送的，而不會被挾持。只要是發送密鑰，就有可能有被挾持的風險。

第二個是：非對稱加密的方式效率比較低，它處理起來更爲複雜，通訊過程當中使用就有必定的效率問題而影響通訊速度

4.2：Https採用混合機制的加密方式

https則綜合了公開密鑰加密和共享密鑰加密的兩種方式，充分利用二者的優點，在最初的鏈接的時候使用非對稱密鑰的加密方式保證鏈接的安全性，以後穩定的通信採用對稱加密的方式，穩定的通信是指確保交換的密鑰是安全的。

4.3：https的證書機制

  在4.1中咱們講了非對稱加密的缺點，其中第一個就是公鑰極可能存在被挾持的狀況，沒法保證客戶端收到的公開密鑰就是服務器發行的公開密鑰。此時就引出了公開密鑰證書機制。數字證書認證機構是客戶端與服務器均可信賴的第三方機構。證書的具體傳播過程以下：

1：服務器的開發者攜帶公開密鑰，向數字證書認證機構提出公開密鑰的申請，數字證書認證機構在認清申請者的身份，審覈經過之後，會對開發者申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將密鑰放在證書裏面，綁定在一塊兒

 

 

   

2：服務器將這份數字證書發送給客戶端，由於客戶端也承認證書機構，客戶端能夠經過數字證書中的數字簽名來驗證公鑰的真僞，來確保服務器傳過來的公開密鑰是真實的。通常狀況下，證書的數字簽名是很難被僞造的，這取決於認證機構的公信力。一旦確認信息無誤以後，客戶端就會經過公鑰對報文進行加密發送，服務器接收到之後用本身的私鑰進行解密。

4.4：關於客戶端證書

  客戶端證書是進行客戶端認證的，證實服務器正在通訊的客戶端是安全的。可是使用客戶端證書使用存在如下幾個問題：

1：使用客戶端證書，客戶得本身安裝證書，客戶端證書是須要進行付費購買的，且每張證書對應到用戶意味着須要支付用戶數量對等的費用，這叫給用戶帶來了間接的問題。

2：客戶端證書存在另外一個問題是，客戶端證書只能證實客戶端的存在，而不能證實用戶本人的真實有效。

 

五：爲何還有不少網站不使用Https?

 Https既然如此安全可靠，爲何還有不少WEB網站不使用Https的協議？這其中的緣由有如下幾點：

5.1：加密通訊會消耗必定的cpu和服務器資源,若是每次通訊都加密，就會消耗更多的資源

 

5.2:若是全部的信息都採用https加密，這無疑是一種浪費。非敏感信息就算被竊取了，也無傷大雅。能夠在其傳輸敏感信息的時候，採用https協議進行加密

 

5.3：購買證書的開銷也是一筆很大的費用。向認證機構購買證書，證書價格會根據不一樣的認證機構略有不一樣，而通常的受權須要摺合人民幣600多元。

 

六：總結

 本篇博文由http協議出發，主要介紹了https協議，並對其加密機制進行了簡介，梳理其優缺點及其使用場景。做爲一名java開發者，應該對https有所瞭解，明白其背後的機制，不用深究其細節，此乃本篇博文的初衷。