HTTPS入門級總結

服務端配置證書，證書就是一個公私鑰對。

SSL握手過程

簡陋版本：

• 客戶端向服務端索要+驗證公鑰
• 雙方協商生成session key
• 利用session key進行對稱加密下的通訊

詳細版本：

• Client Hello，客戶端發起請求：客戶端向服務端傳送

  • 支援的加密協議和對應版本。如TLS 1.0
  • 一個由客戶端生成的隨機數A
  • 支援的加密方法，比如RSA公鑰加密
  • 支援的壓縮方法

• Server Hello：服務端迴應，服務端傳送

  • 確認使用的加密協議和版本，如果不支援客戶端發過來的協議and版本，伺服器會關閉該流程
  • 一個由伺服器生成的隨機數B
  • 確認伺服器使用的加密方法（可以理解為客戶端支援很多種，服務端使用其中一種）
  • 伺服器證書

• client reply：客戶端迴應，客戶端先驗證伺服器的證書，如果證書不可信則丟擲警告；如果證書正常，則客戶端從證書中提取伺服器公鑰，並向伺服器傳送

  • 一個隨機數C，稱為pre-master key。至此，客戶端和服務端同時有了3個隨機數，雙方會使用事先商定的加密方法，各自生成本次session所用的session key。這把session key在兩端都是相同的
  • 編碼改變通知。表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
  • 客戶端握手結束通知（相當於FIN），表示客戶端的握手階段已經結束。FIN的值等於前面傳送的所有內容的hash值，供伺服器校驗。

• server reply：服務端最後迴應，服務端收到pre-master key後生成session key

  • 編碼改變通知。表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
  • FIN，FIN的值等於前面傳送的所有內容的hash值，供客戶端校驗。

HTTP過程

• 就是普通的HTTP協議過程，只是用session key加密

如何保證公鑰不被篡改

• 解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

  • 怎麼保證證書是真的呢？

    • 一般是作業系統自帶的，所以提醒我們一定要買正版作業系統。

公鑰加密計算量很大，如何減少計算時間

• 解決方法：每一次對話（session），客戶端和伺服器端都生成一個"對話金鑰"（session key），用它來加密資訊。由於"對話金鑰"是對稱加密，所以運算速度非常快，而伺服器公鑰只用於加密"對話金鑰"本身，這樣就減少了加密運算的消耗時間。

為什麼生成session key要3個隨機數呢

• "不管是客戶端還是伺服器，都需要隨機數，這樣生成的金鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的金鑰的隨機性。對於RSA金鑰交換演算法來說，pre-master-key本身就是一個隨機數，再加上hello訊息中的隨機，三個隨機數通過一個金鑰匯出器最終匯出一個對稱金鑰。pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為金鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的金鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"

HTTPS是絕對安全的嗎？如果不是，什麼情況下會遭到攻擊

• 如果關閉了證書驗證，則可能會遭受雙重中間人攻擊，那什麼是雙重中間人攻擊？

  • 

    

    這裡應該上個圖

• 如果在SSL握手的時候資訊被嗅探到3個隨機數

TLS和SSL的關係是什麼，差異在哪裡

• 簡陋版本：TLS 1.0 = SSL 3.1，TLS總體比SSL更安全，TLS有更安全的MAC演算法，更嚴密的警報機制，

• 具體版本：

  • SSL，secure socket layer，安全套接字層。是在網路層和應用層之間的一層協議（該複習下OSI 7層模型了） HTTP - SSL/TLS - TCP - IP
  • TLS比SSL補充了更多的報警程式碼
  • 在加密計算 session key (master secret)時採用的方式不同
  • 填充：TLS支援填充密文塊長度任意整數倍的資料長度，而SSL只支援填充到最小整數倍

HTTPS怎麼做到資料防篡改和兩端的身份確認？

• 利用摘要演算法+數字簽名

  • 摘要演算法：採用單項Hash函式將需要加密的明文“摘要”成一串固定長度（通常是128位）的密文，這一串密文又稱為數字指紋，它有固定的長度，而且不同的明文摘要成密文，其結果總是不同的，而同樣的明文其摘要必定一致。“數字摘要“是https能確保資料完整性和防篡改的根本原因。

  • 數字簽名

    • 定義：數字簽名技術就是對“非對稱金鑰加解密”和“數字摘要“兩項技術的應用，它將摘要資訊用傳送者的私鑰加密，與原文一起傳送給接收者。接收者只有用傳送者的公鑰才能解密被加密的摘要資訊，然後用HASH函式對收到的原文產生一個摘要資訊，與解密的摘要資訊對比。如果相同，則說明收到的資訊是完整的，在傳輸過程中沒有被修改，否則說明資訊被修改過，因此數字簽名能夠驗證資訊的完整性。
    • 過程：明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數字簽名
    • 數字簽名只能驗證資料的完整性，資料本身是否加密不屬於數字簽名的控制範圍

HTTPS中的session可複用嗎？如何恢復

• 是可以的，主要有2種方式

  • 利用session ID

    • session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的”對話金鑰”，而不必重新生成一把。
    • session ID是目前所有瀏覽器都支援的方法，但是它的缺點在於session ID往往只保留在一臺伺服器上。所以，如果客戶端的請求發到另一臺伺服器，就無法恢復對話

  • 利用session token

    • 客戶端傳送一個伺服器在上一次對話中傳送過來的session ticket。這個session ticket是加密的，只有伺服器才能解密，其中包括本次對話的主要資訊，比如對話金鑰和加密方法。當伺服器收到session ticket以後，解密後就不必重新生成對話金鑰了。