注：本文是HTTP權威指南這本書讀的過程中記錄下來的一些case
第十一章、客戶端識別與cookie機制
HTTP協議是無狀態協議。 服務器想知道那個客戶端是誰就需要在HTTP請求中指明我是誰。
在header中可以指定
1、From 用戶的email地址
2、User-Agent 用戶的瀏覽器軟件
3、Referer 用戶是從這個頁面上依照鏈接跳過來的。
4、authorization 用戶名密碼等認證。
5、Client-IP 客戶端的IP地址。
6、X-Forwarded-For 客戶端的IP地址
7、Cookie 服務器產生的ID標籤
上述的屬性並不是都可以唯一標識一個用戶。但是都是用戶的信息屬性。
Cookie
cookie分爲會話cookie和持久cookie 會話cookie 在用戶退出瀏覽器時銷燬。 持久cookie會生存一段時間(設定)
上述兩種cookie區別就是過期時間。
客戶端首次訪問服務端時，服務器是一無所知的。 會執行如下流程。
在服務器往客戶端發送cookie時。可以加上domain域名。 瀏覽器也會根據域名記錄哪個cookie屬於哪個服務器。這樣就不會導致多個cookie發送到錯誤的域名下。
關於cookie 風險還是挺多的，使用時需要小心謹慎。 像七天免登錄這種功能可以用cookie來實現。
第十二章、基本認證機制(basic authentication)
HTTP 定義了兩個官方的認證協議：基本認證和摘要認證。
basic authentication 和 digest authentication
認證的信息是通過 header發送給服務器的。
其中basic 生成的英文串是 name ：password 生成的base64編碼。 base64是可以隨便解碼的，由此可見這個東西在傳輸層被劫持有很大的風險。 basic的使用一般伴隨着 SSL (介於TCP和HTTP的加密協議)
basic可以有代理服務器進行代理認證，只需要改請求頭的key就可以了。 代理服務器可以作爲一個專門進行認證的服務器，這樣更統一管理了。
web服務器 代理服務器
Uauthorized status code:401 unauthorized status code: 407
WWW-Authenticate proxy-Authenticate
Authorization proxy-Authorization
Authentication-Info proxy-Authentication-Info
第十三章、摘要認證
摘要是一種單向函數，主要用於將無限的輸入值轉換成爲優先的濃縮輸出值。常見的摘要函數：MD5 將任意長度的字節序列轉換成一個128位的摘要，這個128位的摘要會被寫成32個十六進制的字符。每個字符表示4位。
摘要使用隨機數防止重放攻擊。
基本認證每次都是一樣的basic值，如果傳輸層被截獲，第三方就獲取到你的加密密碼了。即使他不解密用這個密碼構造HTTP請求也是可以假扮成真實用戶的。
摘要認證在每次單向摘要時加入一個隨機數，這樣即使被劫持了，認證的時間不一樣，這個摘要生成的結果也是不一樣的。
密碼+隨機數 進行計算。並將用戶名一同發送給服務器，服務器根據用戶查找到密碼加上傳給客戶端的隨機數進行校驗
下面是摘要認證的握手流程。
在第(1)步中，服務器會計算出一個隨機數
在第(2)步中，服務器將這個隨機數放在WWW-Authenticate質詢報文中，與服務器所支持的算法列表一同發往客戶端
在第(3)步中，客戶端選擇一個算法，計算出密碼和其他數據的摘要
在第(4)步中，將摘要放在一條Authorization報文中發回服務器。如果客戶端要對服務器進行認證，可以發送客戶端隨機數
在第(5)步中，服務器接收摘要、選中的算法以及支撐數據，計算出與客戶端相同的摘要。然後服務器將本地生成的摘要與網絡傳送過來的摘要進行比較，驗證其是否匹配。如果客戶端反過來用客戶端隨機數對服務器進行質詢，就會創建客戶端摘要。服務器可以預先將下一個隨機數計算出來，提前將其傳遞給客戶端，這樣下一次客戶端就可以預先發送正確的摘要了
2、發送質問報文時。如下報文格式
HTTP /1.1 401 Unauthorized
WWW-Authenticate:Digest
realm= ”Unauthorized required” //域信息 一段字符串
qop=auth,auth-int” //認證的方式，設計摘要計算(A2) 後面會有敘述ctrl+F
nonce=”AHSD12HDHQ2D1280HAHDH1I2HID1” // 服務端生成的一個隨機數。防止重放攻擊用的。
opaque="8asnd12ndnwh81dnwlhd17f40e41" //透傳字段（客戶端會原樣返回）
下面是一個請求的報文詳細流程
WWW-Authentication：用來定義使用何種方式（Basic、Digest、Bearer等）去進行認證以獲取受保護的資源realm：表示Web服務器中受保護文檔的安全域（比如公司財務信息域和公司員工信息域），用來指示需要哪個域的用戶名和密碼qop：保護質量，包含auth（默認的）和auth-int（增加了報文完整性檢測）兩種策略，（可以爲空，但是）不推薦爲空值nonce：服務端向客戶端發送質詢時附帶的一個隨機數，這個數會經常發生變化。客戶端計算密碼摘要時將其附加上去，使得多次生成同一用戶的密碼摘要各不相同，用來防止重放攻擊nc：nonce計數器，是一個16進制的數值，表示同一nonce下客戶端發送出請求的數量。例如，在響應的第一個請求中，客戶端將發送“nc=00000001”。這個指示值的目的是讓服務器保持這個計數器的一個副本，以便檢測重複的請求cnonce：客戶端隨機數，這是一個不透明的字符串值，由客戶端提供，並且客戶端和服務器都會使用，以避免用明文文本。這使得雙方都可以查驗對方的身份，並對消息的完整性提供一些保護response：（密碼摘要）服務器需要計算驗證。根據username找到密碼與發送的nonce計算進行密碼摘要的對比。Authorization-Info：用於返回一些與授權會話相關的附加信息nextnonce：下一個服務端隨機數，使客戶端可以預先發送正確的摘要rspauth：響應摘要，用於客戶端對服務端進行認證stale：當密碼摘要使用的隨機數過期時，服務器可以返回一個附帶有新隨機數的401響應，並指定stale=true，表示服務器在告知客戶端用新的隨機數來重試，而不再要求用戶重新輸入用戶名和密碼了
f 質詢的時候客戶端再發起請求時將賬號和與nonce隨機數拼接的MD5加密密碼一同返回。
摘要是根據單向散列函數H(d) 和摘要 KD(s,d)組成的一對函數，其中s表示密碼，d表示數據。
一個包含了安全信息的數據塊，包括密碼，稱爲A1；一個包含了請求報文中非保密屬性的數據塊，稱爲A2
摘要是由上述三個組件計算出來的。
計算A1的方式有MD5 MD5-sess A1 是一個與安全性相關的數據塊
MD5 ===== <user>:<realm>:<password>
MD5-sess ===== MD5(<user>:<realm>:<password>):<nonce>:<cnonce>
A2包括報文自身有關的一些信息，比如 URL，請求方法和報文實體的主體部分。
RFC2617 根據所選擇的保護質量 qop 爲A2 定義兩種策略。
1.只包含請求方法個URL qop = auth
2.添加了報文的主體部分 qop = auth-int
預授權
這個就是爲了減少每次都需要發送請求+質問的報文。 減少網絡IO 提高速度。
例如：預先加載下一個隨機數 nextnonce 減少請求+質問報文。
多重質詢
服務器在不知道客戶端的具體能力時, 可以對客戶端既發出基本認證質詢,又發出摘要認證質詢. 客戶端在在面臨多重質詢時, 必須以它支持的最強的機制來應答.
差錯處理
在摘要認證中, 客戶端在請求時若某一個指令或其值使用不當, 或者缺少某個指令, 服務器就應該以400 Bad request響應.
如果請求的摘要不匹配, 就應該記錄一次登錄失敗, 一客戶端連續多次失敗, 可能存在攻擊者在猜測密碼.
服務器一定要確定URL指令的值和請求行中的值相同.服務器也應該以400 Bad request響應.
保護空間
通過域可以將服務器的資源劃分爲不同的保護空間. 每一個保護空間都有自己的認證機制. 保護空間決定了可以自動應用證書的區域. 比如某條請求已經被授權, 再接下來的一段時間內, 該保護空間的其他請求也可以使用該證書.若沒有想過說明, 單個保護空間是不能擴展到其他範圍的.
重寫URI
若請求經過了代理, 而代理對URI進行了重寫.這樣就會破壞摘要認證.因爲摘要認證會對URI進行檢查.
首部篡改
爲了防止對header進行篡改，需要進行端對端的加密或者對header進行簽名。可以對www-authenticate authorization進行簽名來保證http事務的安全。
摘要認證沒解決中間人攻擊的問題。這個在SSL中可以得以解決，也就是HTTPS
第十四章、安全HTTP(HTTPS)
HTTPS 是在HTTP和TCP即應用層和傳輸層之間加了安全層（SSL/TLS）
數字加密的一些名詞如下
1.密碼
對文本進行編碼，使偷窺者無法識別的算法。
2.密鑰
改變密碼行爲的數字化參數(像摘要認證的nonce)
3.對稱密鑰加密系統
編解碼使用相同的密鑰的算法
4.不對稱密鑰加密系統
編解碼使用不同的密鑰的算法
5.公開密鑰加密算法
一種能夠使數百萬計算機便捷地發送機密報文的系統
6.數字簽名
用來驗證報文未被僞造或篡改的校驗和
7.數字證書
由一個可信的組織驗證和簽發的識別信息
對於對稱加密系統來說
D(C,d) 計算密碼的函數，C表示登錄的密碼口令，d表示密鑰，通過D算法之後得出一個加密的P 這個P就是密文的。
相當於算法是共有的。但是密鑰是你一個加密的口令，配合原本你的口令進行D計算得出P。 逆着來進行解密。只要解密知道加密時的密鑰就可以進行解密。 對稱加密的密鑰在編解碼時是一樣的。
用暴力遍歷破解密鑰稱爲枚舉攻擊。 所以密鑰長度越長也就越難破解。
常見的對稱加密算法：DES、 RC2、RC4 128位的密鑰認爲是無法暴力破解的。
公開密鑰加密技術
公開密鑰加密技術使用了兩個密鑰。其中一個所有客戶端都使用的公鑰進行加密，然後服務端使用私鑰進行解密。這個私鑰是每個客戶端所私有的。RSA算法就是一個流行的公開密鑰加密系統。
數字簽名技術
除了加解密報文之外，還可以用加密系統對報文進行簽名，以說明是誰編寫的報文，同時證明報文沒有被篡改過。這種技術被稱爲數字簽名。
數字簽名是加了密的校驗和。數字簽名是附加在報文上的特殊的加密校驗碼。
數字簽名通常是用非對稱公開密鑰技術產生的。只有作者才知道私鑰相當於一個“指紋”，一旦計算出簽名，就會將其附加到報文的末尾一起發送。
私鑰解密+簽名 公鑰加密+驗證。
流程：客戶端對報文進行簽名，即使用客戶端的私鑰進行簽名，發送給服務器，服務器在和客戶端建立連接時存在了客戶端的公鑰，此時，服務端使用客戶端的公鑰的反函數進行拆包，如果拆包的摘要與服務端收到的摘要一致證明沒有被篡改。
可以參考數字簽名：http://www.youdzone.com/signature.html
數字證書
certs數字證書。數字證書包括：對象的名稱(服務器，組織)。過期時間。證書發佈者。來着證書發佈者的數字簽名。
數字證書中通常還包括對象的公鑰等。
數字證書沒有一個全球統一的標準，大多數證書使用X.509 v3格式來存儲。
用證書對服務器進行認證。對於HTTPS協議，如果服務器沒有證書安全鏈接就會失敗，如果這個證書不是標準CA發佈的，瀏覽器會提示這個證書不安全。
服務器證書包括：web站點的名稱和主機名。web站點的公鑰。簽名頒發機構的名稱。來自簽名頒發機構的簽名。
如果證書的頒發機構是一個很權威的機構，瀏覽器一般都會有這個機構的公鑰，這樣就可以對證書完整性進行校驗了。
用證書對服務器進行認證：
CA對web站點的信息(包括站點的公鑰)進行CA私鑰加密生成數字證書，服務端在給客戶端發響應時只要在簽名時附帶上這個CA頒發的證書，然後客戶端使用CA的公鑰對證書進行拆包，就能得到web站點的公鑰。然後就可以校驗簽名是否正確了。
HTTPS 方案
HTTPS 是比以上的方式都要安全的，通過SSL對傳輸層進行加密。SSL是個二進制協議，流量都是承載在443端口的。
如果SSL發送在80端口，HTTP會誤認爲這是錯誤的HTTP流量，並進行關閉。
在HTTPS中，客戶端首先打開一條到服務器443端口的連接，建立了TCP連接後就會初始化SSL層，對加密參數進行溝通。並交換密鑰。握手完成之後，SSL初始化就完成了。客戶端就可以將請求報文發送給安全層了，在將這些報文發送給TCP之前，要先對它進行加密。
SSL握手要完成如下工作
1.交換協議版本號。
2.選擇一個兩端都瞭解的密碼。
3.對兩端的身份進行認證
4.生成臨時的會話密鑰，以便加密信道。
服務器證書
SSL支持雙向證書，將服務器證書承載回客戶端，再將客戶端證書回送給服務器。服務器證書是以X.509 v3爲標準的
對於虛擬主機（一臺服務器有多個主機名）站點上的安全流量處理一般使用重定向，將部分主機重定向到綁定證書的域名下。
如果做測試的話，可以使用OpenSSL來生成證書，配合Nginx 完全可以玩HTTPS 但是證書是不被信任的，需要CA機構綁定域名。
以上：可以使用wireshark這種抓包工具來驗證/查看 報文
參考：https://www.cnblogs.com/xiaoxiaotank/p/11078571.html
https://juejin.im/post/5aa5e50a6fb9a028b410b394
