http/1.x,http/2,https,SSL,TLS

http協議封裝的數據包->tcp/ip->服務器  缺點：數據包中途被竊取或者被篡改。

http協議封裝的數據包->ssl加密->tcp/ip->服務器：缺點：雖然安全，可是開銷變大，傳輸數據變慢。

http的鏈接很簡單，是無狀態的;https協議是由ssl+http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

https如何保證數據的傳輸加密？

https在傳輸的過程當中涉及三個密鑰：

服務器端用的公鑰和私鑰（公鑰加密，私鑰解密），用來進行非對稱加密。

客戶端產生的隨機密鑰，用來進行對稱加密。

分爲8步：

1.客戶端向服務器發起HTTPS請求，鏈接到服務器的443端口。

2.服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存着私鑰，不能將其泄露，公鑰能夠發送給任何人。

3.服務器將數字證書（公鑰，域名）發送給客戶端。

4.客戶端對服務端發來的公鑰進行檢查，驗證其合法性，若是發現公鑰有問題，https傳輸就沒法繼續。而後會生成一個隨機值（採用僞隨機數生成器生成對稱密碼的私鑰），這個隨機值就是客戶端密鑰，而後用服務器公鑰對客戶端密鑰進行非對稱加密，這個客戶端密鑰就是密文，第一次https請求就結束了。

5.服務端接收到收到客戶端的密文，而後用私鑰進行非對稱解密，解密以後的明文就是客戶端密鑰，而後用客戶端密鑰對數據進行加密，這樣數據就變成了密文。

6.服務端數據加密後的密文發給客戶端。

7.客戶端收到服務器發來的密文，用客戶端的密鑰來進行對稱解密，獲得服務器端發來的數據，這樣第二次http請求就結束了。

 

 

在https請求中還有消息驗證碼（共享密鑰，消息散列值）：消息認證碼主要用於驗證消息的完整性與消息的認證，其中消息的認證指「消息來自正確的發送者」

1. 發送者與接收者事先共享祕鑰
2. 發送者根據發送消息計算 MAC 值
3. 發送者發送消息和 MAC 值
4. 接收者根據接收到的消息計算 MAC 值
5. 接收者根據本身計算的 MAC 值與收到的 MAC 對比
6. 若是對比成功，說明消息完整，並來自與正確的發送者

 https中的數字簽名（須要公鑰，私鑰，消息散列值）：消息認證碼的缺點在於沒法防止否定，由於共享祕鑰被 client、server 兩端擁有，server 能夠僞造 client 發送給本身的消息（本身給本身發送消息），爲了解決這個問題，咱們須要它們有各自的祕鑰不被第二個知曉（這樣也解決了共享祕鑰的配送問題）

 

 

數字簽名和消息認證碼都不是爲了加密
能夠將單向散列函數獲取散列值的過程理解爲使用 md5 摘要算法獲取摘要的過程

使用本身的私鑰對本身所承認的消息生成一個該消息專屬的簽名，這就是數字簽名，代表我認可該消息來自本身
注意：私鑰用於加簽，公鑰用於解籤，每一個人均可以解籤，查看消息的歸屬人

 用戶證書（須要公鑰密碼中的公鑰，數字簽名）：

    證書：全稱公鑰證書（Public-Key Certificate, PKC）,裏面保存着歸屬者的基本信息，以及證書過時時間、歸屬者的公鑰，並由認證機構（Certification Authority, CA）施加數字簽名，代表，某個認證機構認定該公鑰的確屬於此人（防止你隨便去拿一個公鑰就來進行通訊）

    服務器B發送給客戶端A的用戶證書, 是服務器B向CA機構(數字證書認證機構)申請而來的證書。

CA機構(數字證書認證機構)

1. CA機構有一對根密鑰。CA機構會用其私鑰加密服務器B的公鑰。結果就是:經過CA機構認證的證書(公鑰、域名)。
2. CA機構說白了就是一個受信任的中間人。

什麼是根證書

1. CA機構有一對根密鑰。其公鑰就是根證書。
2. 用戶的操做系統中,會集成世界範圍內全部被信任的CA機構(數字證書認證機構)的根證書。即全部被信任機構的公鑰。
3. iPhone->通用->關於本機->證書信任設置->進一步瞭解被信任的證書。能夠看到iOS中可用的受信任根證書的列表。

關於HTTPS握手過程當中關於對數字證書的細節：

1.服務器B返回的數字證書, 客戶端A會進行以下驗證:

1. 遍歷計算機和瀏覽器中保存的根證書, 若其中某個根證書的公鑰能夠解開服務器返回的數字證書, 得到服務器返回的數字證書中的公鑰和域名, 則說明OK。不然握手失敗。整個HTTPS通訊的核心就是這個可信的根證書。
2. 客戶端A判斷證書中的域名是否和正在訪問的域名相同。若不一樣,顯示證書不可信, 可是握手加密過程依然能夠進行。
3. 客戶端產生一個隨機的對稱密鑰。
4. 使用服務器B返回的數字證書中的公鑰來加密此對稱密鑰。
5. 將此加密後的對稱密鑰發送給服務器B。服務器B經過私鑰解密得到客戶端A隨機產生的對稱密鑰。至此客戶端A和服務器B都擁有了對稱密鑰。
6. 客戶端A經過自身隨機產生的對稱密鑰來加密HTTP通訊內容。服務器B能夠經過以前獲得的對稱密鑰解密通訊內容。

2.握手過程當中涉及到兩種證書。

1. 服務器B發送給客戶端A的證書－用戶證書。
2. 客戶端A所在計算機中本來保存的根證書。

http1.0和http2.0之間的區別？

http1.0：無狀態、無鏈接。

http1.1：持久鏈接，默認Connection:keep-alive,增長了host字段，增長了緩存處理：cache-control，根據客戶端請求的前後順序來返回相應的結果，以保證客戶端可以區分每次請求的響應內容。

http2.0：

1.引入二進制和流的概念，幀對數據進行順序標識，瀏覽器接收到數據之後根據序列對數據進行合併，不會出現數據錯亂的狀況。所以有了序列，服務器能夠並行的傳輸數據。

 

2.多路複用：

     一、全部的HTTP2.0通訊都在一個TCP鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。

     二、每一個數據流以消息的形式發送，而消息由一或多個幀組成。這些幀能夠亂序發送，而後再根據每一個幀頭部的流標識符（stream id）從新組裝。

         舉個例子，每一個請求是一個數據流，數據流以消息的方式發送，而消息又分爲多個幀，幀頭部記錄着stream id用來標識所屬的數據流，不一樣屬的幀能夠在鏈接中隨機混雜在一塊兒。接收方能夠根據stream id將幀再歸屬到各自不一樣的請求當中去。

     三、另外，多路複用（鏈接共享）可能會致使關鍵請求被阻塞。HTTP2.0裏每一個數據流均可以設置優先級和依賴，優先級高的數據流會被服務器優先處理和返回給客戶端，數據流還能夠依賴其餘的子數據流。

     四、可見，HTTP2.0實現了真正的並行傳輸，它可以在一個TCP上進行任意數量HTTP請求。而這個強大的功能則是基於「二進制分幀」的特性。

 

3.頭部壓縮

在HTTP1.x中，頭部元數據都是以純文本的形式發送的，一般會給每一個請求增長500~800字節的負荷。

HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。高效的壓縮算法能夠很大的壓縮header，減小發送包的數量從而下降延遲。

 

4.服務器推送：

服務器除了對最初請求的響應外，服務器還能夠額外的向客戶端推送資源，而無需客戶端明確的請求。

 GET,POST請求的區別：

基本：

1.get是從服務器上獲取數據，post是向服務器傳送數據。
2. POST比GET安全，由於數據在地址欄上不可見。
3.get方式提交的數據最多隻能有1024字節，而post則沒有此限制。
4.GET使用URL或Cookie傳參。而POST將數據放在BODY中。

深刻：

1.GET產生一個TCP數據包；POST產生兩個TCP數據包。

對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；

而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）

 

2.緩存回退：GET在瀏覽器回退時是無害的，而POST會再次提交請求,由於,Get請求瀏覽器有緩存,回退時讀取的是緩存中的數據. 可是Post沒有瀏覽器緩存會再次發送請求,消耗服務器性能。

SSL,TLS區別：

SSL（Secure Sockect Layer 安全套接字協議）的過程就是上面的那個，它所提供的服務：認證用戶和服務器，確保數據發送到正確的客戶機和服務器；加密數據以防止數據中途被竊取；維護數據的完整性，確保數據在傳輸過程當中不被改變。

TLS（Transport Layer Security 安全傳輸層協議）它在會話層

TLS的主要目標是使SSL更安全，並使協議的規範更精確和完善。TLS 在SSL v3.0 的基礎上，主要有如下加強內容：

1）TLS 使用「消息認證代碼的密鑰散列法」（HMAC）更安全的MAC算法。

2）TLS提供更多的特定和附加警報，還對什麼時候應該發送某些警報進行記錄。

3）加強的僞隨機功能，TLS對於安全性的改進。

 

HTTPS 降級攻擊

    攻擊者可利用 SSL 3.0 漏洞獲取安全鏈接當中某些是SSL3.0加密後的明文內容。由於兼容性問題，當瀏覽器進行 HTTPS 鏈接失敗的時候，將會嘗試使用舊的協議版本，因而，加密協議由更加安全的協議，好比 TLS 1.2降級成 SSL 3.0。

    若是服務器提供有漏洞的 SSL 3.0 協議的支持，同時，攻擊者又能做爲中間人控制被攻擊者的瀏覽器發起漏洞版本的 HTTPS 請求，那雖然攻擊者監聽到的也是加密過的數據，但由於加密協議有漏洞，能夠解密這些數據。攻擊者能夠利用此漏洞，截獲用戶的隱私數據，好比 Cookie，這樣攻擊者就能夠拿到這些隱私數據，進行更深層次的攻擊，進而形成了用戶隱私的泄漏。

解決：

惟一解決問題的方法是禁用 SSL 3.0 加密協議，防止TLS 1.2 或者 TLS 1.1 或者 TLS 1.0降級到 SSL 3.0 加密協議。

參考：http://www.javashuo.com/article/p-pmkibrtb-ds.html

 

SSH帳號密碼登陸：

（1）遠程主機收到用戶的登陸請求，把本身的公鑰發給用戶。

（2）用戶使用這個公鑰，將登陸密碼加密後，發送回來。

（3）遠程主機用本身的私鑰，解密登陸密碼，若是密碼正確，就贊成用戶登陸。

會發生中間人攻擊，截獲登陸請求，僞造服務器，從而獲取密碼。

因此咱們在首次登陸的時候須要咱們肯定」公鑰指紋」指紋是否是相同的。

SSH免登錄原理：