第7章
確保Web安全的HTTPS
在HTTP協議中有可能存在信息竊聽或身份偽裝等安全問題。使用HTTPS通信機制可以有效的防止這些問題。
7.1 HTTP的缺點
● 通信使用明文（不加密），內容可能會被竊聽
● 不驗證通信方的身份，因此有可能遭遇偽裝
● 無法證明報文的完整性，所以有可能已遭篡改
7.1.1 通信明文可能會被竊聽
由于HTTP本身不具備加密功能，所以也無法做到對通信整體進行加密。即，HTTP報文使用明文方式發送。
TCP/IP是可能被竊聽的網絡
按TCP/IP協議族的工作機制，通信內容在所有通信線路上都有可能遭到竊聽。
即使已經過加密處理的通信，也會被窺視到通信內容，這點和未加密的通信是相同的。 只是說如果通信經過加密，就有可能讓人無法破解
報文信息的含義，但加密處理后的報文信息本身還是會被看到的。
竊聽相同的通信并非難事。只要收集在互聯網上流動的數據包就可以了。對于收集來的數據包的解析工作，交給那些抓包工具就可以了。
加密處理防止被竊聽
通信的加密
一種是通信加密。HTTP協議中沒有加密機制，但可以空過和SSL（Secure Socket Layre 安全套接層）或者TLS（Transport Layer Security安全層傳輸協議）組合使用，加密HTTP的通信內容
用SSL建立安全通信線路之后，就可以在這條線路上進行HTTP通信了。與SSL組合使用的HTTP被稱為HTTPS（HTTP Secure 超文本傳輸安全協議）或 HTTP over SSL
內容加密
由于HTTP協議中沒有加密機制，那么就對HTTP協議傳輸的內容本身加密。
7.1.2　不驗證通信方的身份就可能遭遇偽裝
HTTP 協議中的請求和響應不會對通信方進行確認。也就是說存在“服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真
的返回到實際提出請求的客戶端”等類似問題。

任何人都可以發起請求
無法確定發送至目標的Web服務器是否按真實意圖返回響應的那臺服務器。有可能是以偽裝的Web服務器。
無法確定響應返回的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端。
無法確定正在通信的雙方是否具備訪問權限。因為某些Web服務器上保存著重要的信息，只想發給特定用戶通信的權限。
無法判定請求來自何方、出自誰手。
即使是無意義的請求也會照單全收。無法阻止海量請求下的Dos攻擊（Denial of Service 拒絕服務攻擊）

查明對手的證書
雖然使用HTTP協議無法確定通信方，但是如果使用SSL就可以。SSL不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用于確定方。
證書由值得信任的第三方機構頒布，用于證明服務器和客戶端是實際存在的。
另外，偽造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通信方持有的證書，即可判斷通信方的真實意圖。
7.1.3無法證明報文完整性，可能已經遭到篡改
從某個 Web 網站上下載內容，是無法確定客戶端下載的文件和服務器上存放的文件是否前后一致的。 文件內容在傳輸途中可能已經被篡改為其他的內容。
像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改內容的攻擊稱為中間人攻擊（Man-in-the-Middle attack， MITM）。
不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器無法自動幫用戶檢查。
可惜的是，用這些方法也依然無法百分百保證確認結果正確。因為PGP 和 MD5 本身被改寫的話，用戶是沒有辦法意識到的。
7.2　HTTP+ 加密 + 認證 + 完整性保護 =HTTPS
7.2.1　HTTP 加上加密處理和認證以及完整性保護后即是 HTTPS
在Web登錄頁面和購物界面等使用HTTPS通信。
當瀏覽器訪問HTTPS通信有效的Web網站時，瀏覽器的地址欄會出現一把鎖。
7.2.2　HTTPS 是身披 SSL 外殼的 HTTP
通常HTTP直接和TCP通信，當使用SSL時，演變成先和SSL通信，再由SSL和TCP通信。
所謂HTTPS，其實就是身披SSL協議外殼的HTTP。用了SSL后，HTTP就擁有了加密、證書和完整性保護這些功能。

SSL是獨立于HTTP的協議，所以不光是HTTP協議，其他運行在應用層的SMTP和Telnet等協議均可配合SSL協議使用。
可以說，SSL是當今世界上應用最為廣泛的網絡安全技術。
7.2.3　相互交換密鑰的公開密鑰加密技術
SSL 采用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。
加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common keycrypto system），也被叫做對稱密鑰加密。
使用兩把密鑰的公開密鑰加密
公開密鑰加密使用一對非對稱的密鑰。 一把叫做私有密鑰（privatekey），另一把叫做公開密鑰（public key）。
HTTPS采用混合加密機制
HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實現安全交換， 那么有可能會考慮僅使用公開密鑰加密
來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。
7.2.4　證明公開密鑰正確性的證書
可證明組織真實性的EV SSL證書
用以確認客戶端的客戶端證書
認證機構信譽第一
由自認證機構頒發的證書稱為自簽名證書
7.2.5　HTTPS 的安全通信機制

步驟 1：客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中
包含客戶端支持的 SSL 的指定版本、加密組件（Cipher
Suite）列表（所使用的加密算法及密鑰長度等）。

步驟 2：服務器可進行 SSL 通信時，會以 Server Hello 報文作為應
答。和客戶端一樣，在報文中包含 SSL 版本以及加密組
件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟 3：之后服務器發送 Certificate 報文。報文中包含公開密鑰證書。

步驟 4：最后服務器發送 Server Hello Done 報文通知客戶端，最初
階段的 SSL 握手協商部分結束。

步驟 5：SSL 第一次握手結束之后，客戶端以 Client Key Exchange
報文作為回應。報文中包含通信加密中使用的一種被稱為
Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公
開密鑰進行加密。

步驟 6：接著客戶端繼續發送 Change Cipher Spec 報文。該報文會
提示服務器，在此報文之后的通信會采用 Pre-master secret密鑰加密。

步驟 7：客戶端發送 Finished 報文。該報文包含連接至今全部報文
的整體校驗值。這次握手協商是否能夠成功，要以服務器
是否能夠正確解密該報文作為判定標準。

步驟 8：服務器同樣發送 Change Cipher Spec 報文。

步驟 9：服務器同樣發送 Finished 報文。

步驟 10：服務器和客戶端的 Finished 報文交換完畢之后， SSL 連接
就算建立完成。當然，通信會受到 SSL 的保護。從此處開
始進行應用層協議的通信，即發送 HTTP 請求。

步驟 11：應用層協議通信，即發送 HTTP 響應。

步驟 12：最后由客戶端斷開連接。斷開連接時，發送 close_notify報文。

HTTPS也存在一些問題，就是當使用SSL時，他的處理速度就會變慢。
SSL 的慢分兩種。一種是指通信慢。另一種是指由于大量消耗 CPU及內存等資源，導致處理速度變慢。
不一直使用HTTPS
1. 與純文本相比，加密通信會消耗更多的CPU及內存資源
2. 進行HTTPS通信，證書必不可少。而使用證書必須向認證機構CA購買。一般一年的授權需要 600人民幣

第8章 確認訪問用戶身份的認證
.1 何為認證
為確認當前用戶是否真的具有訪問系統的權限，就需要核對“登陸者本人才知道的信息”， “登錄者本人才有的信息”
● 密碼：只有本人才會知道的字符串信息。
● 動態令牌：僅限本人持有的設備內顯示的一次性密碼。
● 數字證書：僅限本人（終端）持有的信息。
● 生物認證： 指紋和虹膜等本人的生理信息。
● IC 卡等：僅限本人持有的信息。
HTTP/1.1 使用的認證方式
BASIC
DIGEST
SSL
FormBase
8.2　BASIC 認證
8.3　DIGEST 認證
8.4　SSL 客戶端認證
8.5　基于表單認證
8.5.1　認證多半為基于表單認證
8.5.2　Session 管理及 Cookie 應用

步驟 1： 客戶端把用戶 ID 和密碼等登錄信息放入報文的實體部分，
通常是以 POST 方法把請求發送給服務器。而這時，會使
用 HTTPS 通信來進行 HTML 表單畫面的顯示和用戶輸入
數據的發送。
步驟 2： 服務器會發放用以識別用戶的 Session ID。通過驗證從客
戶端發送過來的登錄信息進行身份認證，然后把用戶的認
證狀態與 Session ID 綁定后記錄在服務器端。
向客戶端返回響應時，會在首部字段 Set-Cookie 內寫入
Session ID（如 PHPSESSID=028a8c…）。
你可以把 Session ID 想象成一種用以區分不同用戶的等位號。
然而，如果 Session ID 被第三方盜走，對方就可以偽裝成你的
身份進行惡意操作了。因此必須防止 Session ID 被盜，或被
猜出。為了做到這點， Session ID 應使用難以推測的字符串，
且服務器端也需要進行有效期的管理，保證其安全性。
另外，為減輕跨站腳本攻擊（XSS）造成的損失，建議事
先在 Cookie 內加上 httponly 屬性。
步驟 3： 客戶端接收到從服務器端發來的 Session ID 后，會將其作
為 Cookie 保存在本地。下次向服務器發送請求時，瀏覽器
會自動發送 Cookie，所以 Session ID 也隨之發送到服務器。
服務器端可通過驗證接收到的 Session ID 識別用戶和其認
證狀態。

通常，一種安全的保存方法是，先利用給密碼加鹽（salt） A 的方式
增加額外信息， 再使用散列（hash）函數計算出散列值后保存。但是我
們也經常看到直接保存明文密碼的做法， 而這樣的做法具有導致密碼泄
露的風險。

salt其實就是由服務器隨機生成的一個字符串，但是要保證長度足夠長，并
且是真正隨機生成的。然后把它和密碼字符串相連接（前后都可以）生成散
列值。當兩個用戶使用了同一個密碼時，由于隨機生成的salt值不同，對應
的散列值也將是不同的。這樣一來，很大程度上減少了密碼特征， 攻擊者也
就很難利用自己手中的密碼特征庫進行破解

轉載于:https://www.cnblogs.com/ya-cpp/p/5168444.html

總結

以上是生活随笔為你收集整理的2016-1-29 图解HTTP(04)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。