轉自個人博客0pt1mus
在HTTP協議中有可能存在信息竊聽或身份僞裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題。
HTTP的缺點
HTTP主要有這些不足：
- 通信使用明文（不加密），內容可能會被竊聽
- 不驗證通信方的身份，因此有可能遭遇僞裝
- 無法證明報文的完整性，所以有可能已遭篡改
通信使用明文可能會被竊聽
-
TCP/IP是可能被竊聽的網絡
監聽相同段上的通信並非難事。只需要手機在互聯網上流動的數據包（幀）就行了。
-
加密處理防止被竊聽
加密的對象可以有這麼幾個：
**通信的加密。**一種方式就是將通信加密。HTTP協議中沒有加密機制，但可以通過和SSL（Secure Socket Layer，安全套接層）或TLS（Transport Layer Security，安全層傳輸協議）的組合使用，加密HTTP的通信內容。
用SSL建立安全通信線路之後，就可以在這條線路上進行HTTP通信了。與SSL組合使用的HTTP被稱爲HTTPS（HTTP Secure，超文本傳輸安全協議）或HTTP over SSL。
**內容的加密。**還有一種將參與通信的內容本身加密的方式。由於HTTP協議中沒有加密機制，那麼就對HTTP協議傳輸的內容本身加密。即把HTTP報文裏所含的內容進行加密處理。
有一點要引起注意，由於該方式不同於SSL或TLS將整個通信線路加密處理，所以內容任然有被篡改的風險。
不驗證通信方的身份就可能遭遇僞裝
HTTP協議中的請求和響應不會對通信方進行確認。
-
任何人都可發起請求
在HTTP協議通信時，由於不存在確認通信方的處理步驟，任何人都可以發起請求。另外，服務器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限於發送端的IP地址和端口號沒有被Web服務器設定限制訪問的前提下）。
不確認通信方，會存在以下各種隱患：
無法確定返回響應的Web服務器是真正的服務器
無法確定接收響應的客戶端是真正的客戶端
無法確定正在通信的對方是否具備訪問權限。
無法判定請求是來自何方、出自誰手。
即使無意義的請求也照單全收。DoS（Denial of Service，拒絕服務攻擊）。
-
查明對手的證書
HTTP協議無法確定通信方，但使用SSL則可以。SSL不僅提供加密處理，而且還使用了一種被稱爲證書（證書是第三方頒發的，從技術手段上是很難僞造的）的手段，可用於確定方。
無法證明報文完整性，可能已遭篡改
所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味着無法判斷信息是否準確。
- 接收到的內容可能有誤
- 如何防止篡改
常用的MD5和SHA-1等散列值校驗的方法，以及用來確認文件的數字簽名方法。
HTTP+加密+認證+完整性保護=HTTPS
HTTP加上加密處理和認證以及完整性保護後即是HTTPS。
HTTPS是身披SSL外殼的HTTP
HTTPS並非是應用層的一種新協議。只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。
通常，HTTP直接和TCP通信。當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。
SSL是當今世界上應用最爲廣泛的網絡安全技術。
相互交換密鑰的公開密鑰加密技術
SSL採用一種叫做公開密鑰加密（Public-key cryptography）的加密方式。
HTTPS採用混合加密機制。HTTPS採用共享密鑰加密和公開密鑰加密兩者並用的混合加密機制。
證明公開密鑰正確性的證書
公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。
爲了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。
數字證書認證機構的業務流程。首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一起。
此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發佈版本時，會事先在內部植入常用認證機關的公開密鑰。
