前言
大家好，我是蝸牛，在上一篇中，我們介紹了不同版本的HTTP區別和發展背景，這篇文章我們來聊聊HTTP的缺點，HTTP缺點大致總結有以下三點：
- 通信使用明文（不加密），內容可能會被竊聽，
- 不驗證通信方的身份，因此有可能遭遇偽裝（客戶端和服務端都有可能）
- 無法證明報文的完整性，有可能會被篡改，
其實以上問題不止HTTP有，其他未加密的協議也有此類問題，下面就以上三點詳細介紹
通信使用明文（不加密），內容可能會被竊聽
因為HTTP不具備加密的功能，所以無法對通信報文進行加密，所以是使用明文進行發送，那么就有可能被竊聽，
可以看到竊聽無處不在
竊聽的方式有多種，比較常見有抓包工具（Wireshark）或者嗅探器（Sniffer）等工具，進行竊聽，
下面圖片是使用Wireshark抓取的資料：
如何防止
-
通信的層加密
通過HTTP與SSL/TLS的組合使用（SSL/TSS后續章節介紹），可以加密http通信內容，
-
通信報文內容加密
雙方約定好密鑰，在傳輸前對原報文進行一個加密，傳輸至服務端或客戶端在進行解密，因為此類方式不同于https方式，所以還是有一定的風險，
- 密鑰不是一次一密，而且是內嵌在代碼中，都有可能被獲取，
- 如果是基于瀏覽器的工程，那么這個密鑰是內嵌在js中的，而js是可以訪問的，那么就有可能被獲取，
- 如果是app工程中，也有可能被反編譯獲取，
不驗證通信方的身份，因此有可能遭遇偽裝
HTTP協議的請求與回應不會對通信方進行身份的確認，因此這種無法確認通信方，總結有以下幾類問題：
- 無法確定請求目標的Web服務器是否，真正要訪問的服務器，
- 無法確定客戶端是否是真實要回應的客戶端，
- 無法確定正在通信的雙方是否具備訪問權限，比如：提供的WEB服務只想開發給指定的客戶端訪問，
- 無法判定請求來自何方，出自誰手，
- 即使是無意義的請求，也會照單全收，如海量的Dos攻擊，
如何防止
使用SSL才可以防止此類問題，SSL不僅提供加密功能，還提供證書，通過證書可以確定通信的方是意料之中的，這里肯定有人會問那證書如何保證可信呢？
證書是有公認值得信賴的CA機構頒發的，其他機構是沒有頒發證書權限的，CA機構是可信賴的，那么頒發的證書也是可信賴的，
客戶端驗證服務端是否是可信的服務端，即單向認證，
客戶端與服務端相互認證，即雙向認證，
無法證明報文的完整性，有可能會被篡改
所謂完整性是指資訊的準確度，無法證明完整性，那么也就無法判定資訊是否準確，
由于HTTP協議無法證明通信的完整性，那么請求或者回應程序中報文就有可能被篡改，而服務端或者客戶端是無法感知的，
比如從網上下載的內容，是無法確認下載后的內容是否跟服務器上的內容一致，
像這樣在請求/回應途中，遭攻擊者攔截并篡改內容攻擊，稱為中間人攻擊，
如何防止
- 使用md5/sha1/pgp來確定報文完整性的方法
點擊下載后，可以查看對應檔案簽名或者散列值，當我點擊MD5后，如下圖：
通過對下載后檔案在通過MD5生成散列碼，與官網上的散列碼進行比較，來確定檔案是否被篡改，
但是從其他方式證明此種方式也不是絕對安全的，具體可以參見：http://bobao.360.cn/news/detail/768.html大概意思就是構造”前綴碰撞法“，來制造MD5值一樣，檔案內容不一樣的檔案，
總結
HTTP雖然使用極為廣泛, 但是卻存在不小的安全缺陷, 主要是其資料的明文傳送和訊息完整性檢測的缺乏, 而這兩點恰好是網路支付, 網路交易等新興應用中安全方面最需要關注的
因此為了解決以上問題需要和SSL/TLS相關協議組合，這就是HTTPS，下篇我們介紹HTTPS
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/510842.html
標籤：Java
上一篇：Go微服務實戰 - 用戶服務開發(gRPC+Protocol Buffer)
下一篇：自定義映射resultMap