HTTP缺點和HTTPS

倒黴的我吧體檢手冊弄不見了，哎，倒黴，不說了，寫筆記，Http缺點如下：

• 通訊使用明文（不加密），內容可能會被竊聽
  TCP/IP協議族分別屬於傳輸層和網路層，由於它們的工作性質導致通訊內容在所有的通訊線路上都會遭遇到窺視，不管是加密的還是不加密的，都有可能被竊取，只是加密的可能讓人無法破解報文資訊的含義。常用的抓包工具比如wireshark.

解決方法就是把通訊加密或者把內容加密，http協議無加密機制，但可以使用SSL安全套接層和TLS安全層傳輸協議組合使用，加密通訊內容。與SSL組合使用的就稱為HTTPS，SSL使用了證書，證書由值得信任的第三方機構頒發，可以確認同通訊方的身份。
- 不驗證通訊方的身份，因此有可能遭遇偽裝

http協議無加密機制，那麼傳送請求的就一定是客戶端嗎？響應的就一定是我們所期望的那臺伺服器的響應報文嗎？不一定，所以不驗證通訊方的身份就可能會被偽裝，而且有時我們希望只給特定使用者返回。無法拒絕無意義的請求，有可能出現海量請求下的DOS攻擊
- 無法證明報文的完整性，所以有可能已遭篡改
接受到的內容有可能中途已經被篡改（MITM攻擊），那麼接收到的內容可能有誤，HTTP協議無法證明通訊報文的完整性，可以使用MD5值和SHA-1等雜湊值校驗方法但如果MD5和PGP本身被改寫，那麼還是判斷不了

HTTP+加密+認證+完整性保護=HTTPS

定義：添加了加密和認證機制的HTTP稱為HTTPS，HTTPS是身披SSL外殼的HTTP，並非是應用層的一種新協議，只是HTTP通訊介面部分用SSL和TLS協議代替而已。HTTP(應用層)和TCP（傳輸層）通訊時，若使用了SSL就變成了HTTP先和SSL通訊，SSL在和TCP通訊。

SSL是獨立於HTTP的協議，其他執行在應用層的SMIP均可配合HTTP協議使用，SSL是世界上應用最為廣泛的安全技術之一。

SSL加密

SSL加密採用公開金鑰加密，演算法公開，加密祕鑰保密，加密解密都需要祕鑰，當祕鑰被攻擊時加密就失去了意義。

• 共享祕鑰加密（對稱祕鑰加密）
  當加密解密用同一個祕鑰時就為對稱加密，但當傳輸祕鑰時被竊取，此時就失去了意義。
• 公開祕鑰加密（非對稱祕鑰加密）
  一把私有祕鑰一把公開祕鑰，公開祕鑰加密，私有祕鑰解密。

HTTPS使用混合加密的機制，即採用共享和公開祕鑰加密的結合體，在交換祕鑰環境採用公開加密方式，之後建立通訊交換報文階段採用共享祕鑰加密。通過採用數字證書（EVSSL）來證明公開祕鑰是預想的那臺伺服器所發行的證書。

• 客戶端證書
  客戶端證書是相當於伺服器端證書一樣的存在，但是客戶端證書只能證明客戶端實際存在，不能用來證明使用者本人的真實有效性，只要獲得了安裝有客戶端證書的計算機使用期限，也就同時意味著同時擁有了客戶端證書的使用許可權。

HTTPS的安全通訊機制

• 第一步：客戶端傳送報文開始SSL通訊，報文包含客戶端支援的SSL指定版本加密元件列表
• 第二步：服務端可進行SSL通訊時，在報文中包含SSL版本以及加密元件（加密元件的內容是從客戶端篩選出來的）
• 第三步：伺服器傳送Certificate(證書)報文，報文包含公開祕鑰證書
• 第四步：伺服器傳送報文通知客戶端，最初階段SSL握手協商結束。
• 第五步：客戶端在第一次握手結束後以Client Key Exchange報文做為迴應，報文中包含Pre-master-secret的隨機密碼串，報文用第三步中的公開祕鑰加密。
• 第六步：客戶端繼續傳送報文（Change Cipher Spec）提示伺服器在此之後將採用Pre-master-secret祕鑰加密。
• 第七步：客戶端傳送Finished報文，該報文包含至今全部報文的整體校驗值，以伺服器正確解密該報文為握手協商成功的標誌。
• 第八步：伺服器同樣傳送報文（Change Cipher Spec）
• 第九步：伺服器同樣傳送Finished報文
• 第十步：伺服器和客戶端Finished報文交換完畢，SSL建立完成，通訊受到SSL保護髮送HTTP請求
• 第十一步：應用層協議通訊，傳送HTTP響應

• 第十二步：客戶端斷開連線傳送close_notify報文，之後再發送TCP FIN報文來關閉與TCP的通訊。

  應用層傳送資料時會在報文上附加MAC的報文摘要，MAC能夠查知報文師父被修改，從而保證報文完整性。

為何不一直使用HTTPS？

• 第一：與純文字通訊相比，加密通訊會消耗更多的CPU和記憶體資源
• 第二：節約購買證書的開銷。