HTTPS工做原理 HTTP協議數據結構分析 HTTP和HTTPS協議的不一樣之處

HTTP有如下三個缺點：無加密，無身份認證，無完整性保護，所以所謂的HTTPS，它其實就是HTTP+加密+身份認證+完整性保護。HTTPS並非一種新的協議，在通訊接口使用了SSL和TLS協議而已。HTTP一般直接和TCP通訊，而HTTPS中HTTP先和SSL通訊，再由SSL和TCP進行通訊。模型以下

 

須要注意的是，SSL協議並非一個應用層協議，它是介於應用層和傳輸層協議之間的一個安全協議。

對稱密鑰加密
SSL採用對稱密鑰進行加密，所謂的對稱密鑰，就是加密和解密都用同一個密鑰，所以也叫作共享密鑰加密。

可是這種方法也有一個弊端，一旦密鑰被第三方得到了，就能夠對數據進行解密並竊取，所以這並非一個徹底安全的方法。事實上，若是加密解密方法十分簡單，是很容易被第三方截取的。

因此這種方法的缺陷就在於，若是一方不發送密鑰，對方就沒法利用密鑰解密。另外，若是發送了密鑰，可是密鑰被第三方截取了，數據就容易被竊取。所以，須要一種方式，可以保證該密鑰可以確保送到對方手中而且還不可以讓第三方截取。 

非對稱密鑰加密
SSL還採用了一種技術就是非對稱密鑰加密，所謂的非對稱密鑰，就是這是一對密鑰，一個是私鑰，一個是公鑰。私鑰不能讓其餘任何人知道，而公鑰能夠隨意發佈，任何人均可以得到到，所以這種加密方式也叫公開密鑰加密。

它的原理是這樣的：

客戶端向服務器發起請求，服務器建立一對非對稱密鑰，將公有私鑰返回給可客戶端，本身保留着這個私鑰而不發送。
客戶端收到了來自服務器的公鑰，因而將本身的數據經過公鑰加密，並返回給服務器
服務器接收到了客戶端的數據，由於使用本身發送的公鑰加密的，所以用本身的私鑰對其進行解密，拿到數據
即便第三方拿到了加密後的數據，由於沒有私鑰，所以也沒法獲取到真實的數據。假如想要破解這個解密方式，是十分困難的。
HTTPS使用兩種加密方式的混合加密
對稱密鑰加密方式的優缺點：

優勢：處理速度快
缺點：可是容易被第三方盜取
非對稱密鑰加密方式的優缺點：

優勢：更加安全，不容易被盜取
缺點：處理效率相比對稱密鑰加密要慢，若是在通訊時用這種方式加密，效率很低
因而HTTPS採用了二者的優勢，使用了混合加密的方式

使用非對稱密鑰加密的方式安全地交換再稍後對稱密鑰加密中要使用的密鑰
確保交換的密鑰是安全的以後，放棄非對稱密鑰加密，使用對稱密鑰加密來進行通訊，保證傳輸效率
HTTPS使用的各類證書
證實公開密鑰正確性的數字證書

客戶端沒法判斷本身收到的服務器的公鑰是不是正確的，是否在服務器發送給客戶端的過程當中被第三方篡改了。

爲了解決上面的問題，服務器可使用由數字證書認證機構（CA）頒發的證書，這種機構是客戶端和服務器雙方的第三方機構。服務器獲取證書的流程以下：

服務器運營人員向CA提出公開密鑰的申請
CA在判明申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後將這個簽名的公開密鑰和放入公鑰證書分配給服務器公司
服務器會把這個由CA頒發的公鑰證書以及公開密鑰發送給客戶端，以此來和客戶端進行通訊
接收到證書的客戶端可使用公開密鑰對證書上的簽名進行認證，一旦認證經過，客戶端就能夠知道認證服務器公開密鑰的是真實有效的CA，而且服務器的公開密鑰是值得信賴的
CA的公開密鑰已經事先植入到瀏覽器中，客戶端經過CA的公開密鑰向CA認證服務器的公鑰證書上的數字簽名的真實性。

 

證實企業真實性的EV SSL證書

該證書用來驗證服務器背後運營的企業的合法性

 

用以確認客戶端的客戶端證書

該證書用來向服務器證實，與之通訊的客戶單是預料以內的客戶端。

想要獲取證書 時，用戶得自行安裝客戶端證書，可是客戶端證書是要付費買的。

由於成本比較大，所以只有某些特定的業務，如網上銀行等，就須要使用客戶端證書。

 

HTTPS是怎麼解決HTTP協議的三大缺點的？
防監聽：採用對稱加密對數據進行加密，採用非對稱加密對對稱加密的密鑰進行加密
防假裝：通訊雙方攜帶證書，證書有第三方頒發，很難僞造
防篡改：採用摘要算法（MD5或是SHA-1），一樣的數據由一樣的摘要，而只要有一點不一樣的數據，它的摘要每每不一樣，只要數據作了篡改，就會被感知到。
 

HTTPS的通訊流程
客戶端向服務器發起SSL通訊，報文中包含客戶端支持的SSL的指定版本，加密組件列表（所使用的加密算法及密鑰長度）
服務器的響應報文中，包含SSL版本以及加密組件，服務器的加密組件內容是從客戶端發來的加密組件列表中篩選出來的，服務器還會發一個公開密鑰而且帶有公鑰證書
客戶端拿到服務器的公開密鑰，並驗證其公鑰證書（使用瀏覽器中已經植入的CA公開密鑰）
若是驗證成功，客戶端生成一個Pre-master secret隨機密碼串，這個隨機密碼串其實就是以後通訊要用的對稱密鑰，並用服務器的公開密鑰進行加密，發送給服務器，以此通知服務器，以後的報文都會經過這個對稱密鑰來加密
同時，客戶端用約定好的hash算法計算握手消息，而後用生成的密鑰進行加密，一塊兒發送給服務器
服務器收到客戶端發來的的公開密鑰加密的對稱密鑰，用本身的私鑰對其解密拿到對稱密鑰，再用對稱密鑰解析握手消息，驗證hash值是否與客戶端發來的一致。若是一致，則通知客戶端SSL握手成功
以後的數據交互都是HTTP通訊（固然通訊會得到SSL保護），且數據都是經過對稱密鑰來加密（這個密鑰不會每次都發，在握手的過程當中，服務器已經知道了這個對稱密鑰，再有數據來時，服務器知道這些數據就是經過對稱密鑰加密的，因而就直接解密了）

 

 

一：網絡協議HHTP

　　超文本傳輸協議

　　RFC2616

二：HTTP報文主要結構

　　1)Request

　　　　Method(get,post) ---請求方式

　　　　URL-------請求地址

　　　　Header------請求頭

　　　　Body--------請求體

　　2)Response

　　　　Status Code-------狀態碼

　　　　Header--------響應頭

　　　　Body--------響應體

三：HTTP狀態碼

　　200：成功，這個成功只是表示服務器正常處理完成了，並不能表示邏輯的正確性

　　301，320：跳轉，通常能夠在header中看到location，即跳轉地址，區別是一個是臨時跳轉一個是固定跳轉

　　304：未修改，服務器發現資源文件標識未變更，通知客戶端讀取本地緩存文件便可

　　400：客戶端請求信息格式問題

　　403：通常是禁止訪問，好比文件，目錄等存在，但作了訪問限制

　　404：通常爲文件，目錄不存在，但也能夠將其餘狀況假裝成爲不存在

　　500：出現這個通常都是服務端的代碼直接拋出異常致使

　　502，503，504：這個相似，在網絡異常等狀況下均可以出現，也有不少代碼拋出錯誤時候出現

 

四：HTTP常規Header信息與做用（Request）

　　Host：必須存在，域名指定（相似與分類，但端口用於區分訪問那個域名）

　　Accept：表示自身可接受的信息類容，相似建議，有子項

　　User-Agent：客戶端標識信息（系統版本，瀏覽器，內核等）

　　Cookie：特殊的信息存儲位置，用於自動交互，無需代碼干涉

　　Referer：來源，即經過什麼頁面或文件觸發的請求，若是是瀏覽器地址欄回車則沒有該值

　　Connection：控制長短連接，告訴對方當前連接狀態（Keep-Alive，Close）

　　Range：指定返回信息範圍（斷點持續子類使用）

　　Content-Type：請求正文的類型，編碼等信息

　　Content-Length：請求正文長度

　　If-Modifiled-Since：緩存相關，本地文件的標識有效期

　　If-None-Match：緩存相關，本地文件的特徵碼，對應返回信息中的ETag

 

五：HTTP常規Header信息與做用（Reaponse）

　　Date：時間，通常是服務器當前時間

　　Content-Encoding：返回正文的壓縮編碼類型

　　Content-Length：返回正文的長度

　　Content-Type：返回正文的類型，編碼等信息

　　Cache-Control：緩存機制以及策略，時間，方式等

　　Etag：返回文件信息的特徵碼

　　Expires：返回文件信息的緩存有限期

　　Set-Cookie：要求設置的Cookie，能夠屢次出現的頭信息

　　Location：自動重定向到其餘新的地址，通常狀態301，302時會出現

　　Connection：控制長短連接，告訴對方當前連接狀態，默認Keep，當雙方都爲Keep時則連接會在下次沿用

 

HTTPS和HTTP的區別：
https協議須要到ca申請證書，通常免費證書不多，須要交費。
http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議。
http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
http的鏈接很簡單,是無狀態的。
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全。

HTTPS解決的問題：
1 . 信任主機的問題.
採用https 的server 必須從CA 申請一個用於證實服務器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度纔信任此主機. 因此目前全部的銀行系統網站,關鍵部分應用都是https 的. 客戶經過信任該證書,從而信任了該主機. 其實這樣作效率很低,可是銀行更側重安全. 這一點對咱們沒有任何意義,咱們的server ,採用的證書無論本身issue 仍是從公衆的地方issue, 客戶端都是本身人,因此咱們也就確定信任該server.
2 . 通信過程當中的數據的泄密和被竄改

1. 通常意義上的https, 就是 server 有一個證書.
   a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點同樣.
   b) 服務端和客戶端之間的全部通信,都是加密的.
   i. 具體講,是客戶端產生一個對稱的密鑰,經過server 的證書來交換密鑰. 通常意義上的握手過程.
   ii. 全部的信息往來就都是加密的. 第三方即便截獲,也沒有任何意義.由於他沒有密鑰. 固然竄改也就沒有什麼意義了.
   2). 少量對客戶端有要求的狀況下,會要求客戶端也必須有一個證書.
   a) 這裏客戶端證書,其實就相似表示我的信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應爲我的證書通常來講別人沒法模擬的,全部這樣可以更深的確認本身的身份.
   b) 目前少數我的銀行的專業版是這種作法,具體證書多是拿U盤做爲一個備份的載體.
   3.HTTPS 必定是繁瑣的.
   a) 原本簡單的http協議,一個get一個response. 因爲https 要還密鑰和確認加密算法的須要.單握手就須要6/7 個往返.
   i. 任何應用中,過多的round trip 確定影響性能.
   b) 接下來纔是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容作加密/解密.
   i. 儘管對稱加密/解密效率比較高,但是仍然要消耗過多的CPU,爲此有專門的SSL 芯片. 若是CPU 信能比較低的話,確定會下降性能,從而不能serve 更多的請求. ii. 加密後數據量的影響. 因此，纔會出現那麼多的安全認證提示