SSL TLS協議執行機制的概述

（1）所有資訊都是加密傳播，第三方無法竊聽。（2）具有校驗機制，一旦被篡改，通訊雙方會立刻發現。

（3）配備身份證書，防止身份被冒充。

網際網路是開放環境，通訊雙方都是未知身份，這為協議的設計帶來了很大的難度。而且，協議還必須能夠經受所有匪夷所思的攻擊，這使得ssl/tls協議變得異常複雜。

ssl/tls協議的基本思路是採用公鑰加密法，也就是說，客戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。

（1）如何保證公鑰不被篡改？

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

（2）公鑰加密計算量太大，如何減少耗用的時間？

解決方法：每一次對話（session），客戶端和伺服器端都生成乙個"對話金鑰"（session key），用它來加密資訊。由於"對話金鑰"是對稱加密，所以運算速度非常快，

而伺服器公鑰只用於加密"對話金鑰"本身，這樣就減少了加密運算的消耗時間。

因此，ssl/tls協議的基本過程是這樣的：

（1）客戶端向伺服器端索要並驗證公鑰。（2）雙方協商生成"對話金鑰"。

（3）雙方採用"對話金鑰"進行加密通訊。

上面過程的前兩步，又稱為"握手階段"（handshake）。

首先，客戶端（通常是瀏覽器）先向伺服器發出加密通訊的請求，這被叫做clienthello請求。

在這一步，客戶端主要向伺服器提供以下資訊。

（1）支援的協議版本，比如tls 1.0版。（2）乙個客戶端生成的隨機數，稍後用於生成"對話金鑰"。（3）支援的加密方法，比如rsa公鑰加密。

（4）支援的壓縮方法。

這裡需要注意的是，客戶端傳送的資訊之中不包括伺服器的網域名稱。也就是說，理論上伺服器只能包含乙個**，否則會分不清應該向客戶端提供哪乙個**的數字證書。這就是為什麼通常一台伺服器只能有一張數字證書的原因。

伺服器收到客戶端請求後，向客戶端發出回應，這叫做severhello。伺服器的回應包含以下內容。

（1）確認使用的加密通訊協議版本，比如tls 1.0版本。如果瀏覽器與伺服器支援的版本不一致，伺服器關閉加密通訊。

（2）乙個伺服器生成的隨機數，稍後用於生成"對話金鑰"。（3）確認使用的加密方法，比如rsa公鑰加密。

（4）伺服器證書。

除了上面這些資訊，如果伺服器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供usb金鑰，裡面就包含了一張客戶端證書。

客戶端收到伺服器回應以後，首先驗證伺服器證書。如果證書不是可信機構頒布、或者證書中的網域名稱與實際網域名稱不一致、或者證書已經過期，就會向訪問者顯示乙個警告，由其選擇是否還要繼續通訊。

如果證書沒有問題，客戶端就會從證書中取出伺服器的公鑰。然後，向伺服器傳送下面三項資訊。

（1）乙個隨機數。該隨機數用伺服器公鑰加密，防止被竊聽。（2）編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。

（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供伺服器校驗。

上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以後，客戶端和伺服器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話金鑰"。

伺服器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的"會話金鑰"。然後，向客戶端最後傳送下面資訊。

（1）編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。

（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供客戶端校驗。