今天銀行對app和crm進行安全性檢測，被查出有明文，之前就用的https，但是crm部分還有在用http，簡單的寫了一下關于http和https安全性的問題，不同點和處理方法。
HTTP隱患：
1、與服務器進行通信使用的是明文，內容可能會被竊聽（HTTP協議本身并不具備加密功能，所以無法對請求和響應的內容進行加密）
2、使用HTTP協議的服務器與客戶端都不會驗證通信方的身份，可能遭遇偽裝。（所謂不驗證通信方身份的意思是，比如說服務端，在服務端接收到請求的時候，只要請求的信息正確，服務器并不會去驗證，這個請求是否由其對應的客戶端發出。并且，服務器會對請求立即做出一次響應，返回相應的數據）
3、使用HTTP協議的服務器與客戶端都無法驗證報文的完整性，所以在通信過程中，報文有可能會被篡改
等等。
基于這樣的安全問題，衍生出各種加密技術，對于HTTP協議來說，加密的對象有以下兩個：
1、對通信的加密：
HTTP中沒有加密功能，但是可以通過和SSL(Secure Socket Layer，安全套接層)組合使用，加密通信內容。使用SSL建立安全通信線路后，就可以在這條線路上進行HTTP通信了。與SSL組合使用的HTTP被稱為HTTPS（HTTP Secure，超文本傳輸安全協議）。
2、對通信內容本身進行加密
即對HTTP報文里所包含的內容進行加密。這樣，首先客戶端要先對報文進行加密，然后再發給服務器。服務器在接受到請求時，需要對報文進行解密，再處理報文。該方式不同于SSL將整個通信線路進行加密處理，所以內容仍然有被篡改的風險。SSL不僅提供了加密處理，還使用了"證書"的手段，可用于確認通信方。
1.任何人都可以發起請求
HTTP協議中，并未有確認通信方這一步驟，所以，任何人都可以發送請求，而服務器在接受到任何請求時，都會做出相應的響應。（僅限于發送端的ip地址和端口號沒有被服務器限制訪問）
所以：
1、無法確認請求發送到目標服務器（按照真實意圖返回響應的那臺服務器），這里可能在通信中途被偽裝的服務器返回響應。
2、無法確認響應返回的客戶端是目標客戶端（按照真實意圖接受響應的那臺客戶端），可能是偽裝的客戶端。
3、無法判斷請求來自何方、出自誰手。
4、即使是無意義的請求也會都接受（無法阻止海量請求下的DoS（拒絕服務攻擊）攻擊）。
解決方案：
查明對手的證書
雖然HTTP不能確認通信方，但SSL是可以的。SSL不僅提供了加密處理，還使用了"證書"的手段，可用于確認通信方。證書是由值得信賴的第三方機構頒布，可用于確定證明服務器和客戶端是實際存在的。所以，只要能確認通信方持有的證書，即可判斷通信方的真實意圖。
2.無法判斷報文是否完整（報文可能已遭篡改）
HTTP協議無法判斷報文是否被篡改，在請求或者響應發出后，在對方接收之前，即使請求或者響應遭到篡改是無法得知的。
防止篡改：
常用的，確定報文完整性方法：MD5、SHA-1 等 散列值校驗方法，以及用來確認文件的數字簽名方法。但是，使用這些方法，也無法百分百確保結果正確，因為MD5本身被修改的話，用戶是沒辦法意識到得。
在iOS開發中，我所遇到的加密技術，一般是使用MD5對密碼，交易密碼進行加密，這是每個項目必須的。
