SSL/TLS協議運行機制的概述

1、做用

（1） 全部信息都是加密傳播，第三方沒法竊聽。

（2） 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

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

互聯網是開放環境，通訊雙方都是未知身份，這爲協議的設計帶來了很大的難度。並且，協議還必須可以經受全部匪夷所思的攻擊，這使得SSL/TLS協議變得異常複雜。

2、基本的運行過程

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密。

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

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

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

解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。因爲"對話密鑰"是對稱加密，因此運算速度很是快，
而服務器公鑰只用於加密"對話密鑰"自己，這樣就減小了加密運算的消耗時間。

所以，SSL/TLS協議的基本過程是這樣的：

（1） 客戶端向服務器端索要並驗證公鑰。

（2） 雙方協商生成"對話密鑰"。

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

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

2.1 客戶端發出請求（ClientHello）

首先，客戶端（一般是瀏覽器）先向服務器發出加密通訊的請求，這被叫作ClientHello請求。

在這一步，客戶端主要向服務器提供如下信息。

（1） 支持的協議版本，好比TLS 1.0版。

（2） 一個客戶端生成的隨機數，稍後用於生成"對話密鑰"。

（3） 支持的加密方法，好比RSA公鑰加密。

（4） 支持的壓縮方法。

這裏須要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，不然會分不清應該向客戶端提供哪個網站的數字證書。這就是爲何一般一臺服務器只能有一張數字證書的緣由。

2.2 服務器迴應（SeverHello）

服務器收到客戶端請求後，向客戶端發出迴應，這叫作SeverHello。服務器的迴應包含如下內容。
（1） 確認使用的加密通訊協議版本，好比TLS 1.0版本。若是瀏覽器與服務器支持的版本不一致，服務器關閉加密通訊。

（2） 一個服務器生成的隨機數，稍後用於生成"對話密鑰"。

（3） 確認使用的加密方法，好比RSA公鑰加密。

（4） 服務器證書。

除了上面這些信息，若是服務器須要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。好比，金融機構每每只容許認證客戶連入本身的網絡，就會向正式客戶提供USB密鑰，裏面就包含了一張客戶端證書。

2.3 客戶端迴應

客戶端收到服務器迴應之後，首先驗證服務器證書。若是證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已通過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。

若是證書沒有問題，客戶端就會從證書中取出服務器的公鑰。而後，向服務器發送下面三項信息。

（1） 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。

（2） 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。

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

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

2.4 服務器的最後迴應

服務器收到客戶端的第三個隨機數pre-master key以後，計算生成本次會話所用的"會話密鑰"。而後，向客戶端最後發送下面信息。

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

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