5. 前向安全性
6. pki
二 、通訊模式演化
三、ssl/tls 基本執行過程
目前，應用最廣泛的是tls 1.0，接下來是ssl 3.0。但是，主流瀏覽器都已經實現了tls 1.2的支援。
tls 1.0通常被標示為ssl 3.1，tls 1.1為ssl 3.2，tls 1.2為ssl 3.3。
tls、ssl協議一般構建在tcp上，也可以構建在udp上，稱為dtls，在web裡應用的較少。
tls/ssl 的設計規範有一系列的rfc文件，實現的庫有:
openssl 是比較通用的tls/ssl實現。
2023年，openssl爆出「心臟出血」漏洞，影響了很多產品和服務。
openssl包含兩種型別的庫：
openssl已整合到大部分的linux作業系統中。
將http與tls/ssl結合實現的協議，用於加密應用層。
一般瀏覽器將https預設在443埠。
證書鏈檢測工具： myssl.com
由於公鑰演算法執行速度較慢，所以一般用於通訊握手期間，在正常資料通訊時使用對稱金鑰演算法。
協商目的就是生成對稱金鑰演算法的金鑰。
客戶端向服務端發連線請求；
伺服器端發rsa金鑰對的公鑰給客戶端；
客戶端生成隨機數作為預備主金鑰，用伺服器公鑰加密，再發給伺服器；
伺服器解密成功，即認為雙方協商出預備主金鑰。
客戶端向伺服器端發連線請求；
伺服器生成rsa金鑰對，把公鑰發給客戶端；
伺服器端生成dh引數和伺服器dh金鑰對，用rsa私鑰簽名dh引數和伺服器dh公鑰，最後將簽名值、dh引數、伺服器dh公鑰發給客戶端；
客戶端通過伺服器rsa的公鑰驗證簽名，獲取到dh引數和伺服器dh公鑰；
客戶端通過dh引數生成客戶端的dh金鑰對，把客戶端dh公鑰發給伺服器端；
客戶端通過客戶端dh私鑰和伺服器端dh公鑰計算出預備主金鑰；
伺服器端接收到客戶端的dh公鑰，結合伺服器的dh私鑰計算出預備主金鑰；
最終客戶端與伺服器端計算的預備主金鑰保持一致。
伺服器每次傳送的dh引數和dh公鑰如果是固定的，稱為靜態dh演算法；
否則每次連線時臨時生成，稱為臨時dh演算法（edh演算法）。
上面rsa演算法中，攻擊者無法獲得伺服器rsa金鑰對，無法解密截獲的資料。
但是攻擊者如果把資料先儲存下來，後來由於某種原因伺服器金鑰洩露了，即使伺服器立刻改變金鑰，但攻擊者就可以解密歷史資料，歷史通訊資料將都被解密。
靜態dh演算法也無法保持前向安全性，一旦伺服器的dh引數和dh金鑰洩露，攻擊者能破解出預備主金鑰，歷史通訊資料就會被破解。
pki用於解決中間人攻擊，由多個不同的組織構成，主要有：
正常通訊，無加密
通訊過程很不安全，黑客可以監聽雙方的通訊、攔截通訊、偽造資料進行攻擊。
使用金鑰加密
為了應對攻擊，對通訊資料使用對稱加密演算法進行加密。通訊雙方需要共享金鑰。
2023年，出現對稱加密演算法des。des使用56bit的金鑰。但由於雙方需要共享金鑰，這個金鑰在傳輸過程中有可能被攔截。
更高強度的金鑰
des可能被暴力破解。為了更高的安全性，出現了triple-des(最長168bit金鑰)、aes (最高 256bit金鑰 )。
這仍沒解決雙方傳遞共享金鑰的問題。
非對稱加密
最著名的非對稱加密演算法rsa演算法，其加密與解密使用不同金鑰，加密的金鑰可以公開。這樣可以有效解決雙方共享金鑰的問題。在使用中，通訊雙方都有乙個公鑰和私鑰。
a要給b發網路資料流程：
a使用私鑰加密資料的hash值
a再用b的公鑰加密資料。
a將加密的hash值和加密的資料加上一些其它資訊（如時間戳）發給b
b 先用私鑰解密資料
b本地執行乙個hash值
b用a的公鑰解密hash值，與自己執行的比較，檢驗資料完整性。
但最初通訊交換公鑰的過程，仍存在被中間人攻擊的可能。
使用可信任機構頒布數字證書
客戶端向伺服器端索要並驗證公鑰
雙方協商生成「對話金鑰」
雙方採用「對話金鑰」進行加密通訊。
ssl/tls 使用非對稱加密 。
流程示意圖：
通訊抓包示意圖：
握手階段涉及4次通訊。
客戶端資料主要包含：
客戶端傳送的資訊中不包括伺服器的網域名稱。2023年，tls協議加入了乙個service name indication擴充套件，允許客戶端向伺服器提供它所請求的網域名稱。
支援的加密演算法示例：
伺服器收到客戶端請求後，向客戶端發出回應，包含：
如果是雙向認證，伺服器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供客戶端證書。即金融機構伺服器端只允許認證客戶連入自己的網路，會向正式客戶提供usb金鑰，裡面就包含了一張客戶端證書。
下面是單向認證抓包示意，server hello分成兩個包傳送。
客戶端收到伺服器回應以後，首先驗證伺服器證書。如果有以下問題：
如果證書沒有問題，客戶端就會從證書中取出伺服器的公鑰，然後，向伺服器傳送以下資訊：
客戶端與伺服器同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把」會話金鑰「。
使用三次隨機數，防止有的主機生成的只是偽隨機數。
伺服器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的」會話金鑰「，然後給客戶端傳送下面資訊：
Https安全通訊原理
是什麼？是基於安全目的的http 通道，其安全基礎由ssl 層來保證。最初由netscape 2.與http 主要區別 協議基礎不同 https 在http 下加入了ssl層，通訊方式不同 https 在資料通訊之前需要客戶端 伺服器進行握手 身份認證 建立連線後，傳輸資料經過加密，通訊埠443。傳...
通訊安全與HTTPS
什麼是通訊的安全性？考慮通訊的幾個要素 對方通過一條線路傳送資訊。對方 如何判斷對方身份真實性 偽裝 資訊 如何保證資訊不被竊聽和篡改？防竊聽，防篡改，防偽裝，是總的需求。加密演算法 明文,金鑰k 密文 解密演算法 密文,金鑰k 明文 例如 餘則成 老余 和上級通訊，雙方約定了秘鑰k。老余加密資訊 ...
Https安全通訊機制
通訊使用明文 不加密 內容可能可能會被竊聽 不驗證通訊方的身份，因此可能遭遇偽裝 無法驗證報文的完整性，所以可能已被篡改 1 加密處理和認證 如果在http中使用未經加密的明文，比如在web頁面中輸入了信用卡號，如果這條通訊線路找到竊聽，那麼你的信用卡號就暴露了，另外服務端和客戶端都是沒法確認通訊方...