版權(quán)聲明：版權(quán)歸原作者所有。
原文地址：SSL/TLS協(xié)議運行機制的概述_ITPUX技術(shù)網(wǎng)
原文地址：http://www.itpux.com/thread-4245-1-1.html
互聯(lián)網(wǎng)的通信安全，建立在SSL/TLS協(xié)議之上镐躲。
本文簡要介紹SSL/TLS協(xié)議的運行機制。文章的重點是設(shè)計思想和運行過程凿渊，不涉及具體的實現(xiàn)細節(jié)使鹅。如果想了解這方面的內(nèi)容，請參閱RFC文檔儡遮。
一、作用
不使用SSL/TLS的HTTP通信暗赶，就是不加密的通信鄙币。所有信息明文傳播，帶來了三大風險蹂随。
（1） 竊聽風險（eavesdropping） #第三方可以獲知通信內(nèi)容十嘿。
（2） 篡改風險（tampering） #第三方可以修改通信內(nèi)容。
（3） 冒充風險（pretending） #第三方可以冒充他人身份參與通信岳锁。
SSL/TLS協(xié)議是為了解決這三大風險而設(shè)計的绩衷，希望達到：
（1） 所有信息都是加密傳播，第三方無法竊聽激率。
（2） 具有校驗機制咳燕，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)乒躺。
（3） 配備***書招盲，防止身份被冒充。
互聯(lián)網(wǎng)是開放環(huán)境嘉冒，通信雙方都是未知身份曹货，這為協(xié)議的設(shè)計帶來了很大的難度。而且讳推，協(xié)議還必須能夠經(jīng)受所有匪夷所思的攻擊顶籽，這使得SSL/TLS協(xié)議變得異常復(fù)雜。
二银觅、歷史
互聯(lián)網(wǎng)加密通信協(xié)議的歷史礼饱，幾乎與互聯(lián)網(wǎng)一樣長。
- 1994年，NetScape公司設(shè)計了SSL協(xié)議（Secure Sockets Layer）的1.0版镊绪，但是未發(fā)布匀伏。
- 1995年，NetScape公司發(fā)布SSL 2.0版镰吆，很快發(fā)現(xiàn)有嚴重漏洞帘撰。
- 1996年，SSL 3.0版問世万皿，得到大規(guī)模應(yīng)用摧找。
- 1999年，互聯(lián)網(wǎng)標準化組織ISOC接替NetScape公司牢硅，發(fā)布了SSL的升級版TLS 1.0版蹬耘。
- 2006年和2008年，TLS進行了兩次升級减余，分別為TLS 1.1版和TLS 1.2版综苔。最新的變動是2011年TLS 1.2的修訂版。
- 目前位岔，應(yīng)用最廣泛的是TLS 1.0如筛，接下來是SSL 3.0。但是抒抬，主流瀏覽器都已經(jīng)實現(xiàn)了TLS 1.2的支持杨刨。
- TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2擦剑，TLS 1.2為SSL 3.3妖胀。
三、基本的運行過程
SSL/TLS協(xié)議的基本思路是采用公鑰加密法惠勒，也就是說赚抡，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息纠屋，服務(wù)器收到密文后涂臣，用自己的私鑰解密。
但是巾遭，這里有兩個問題肉康。
（1）如何保證公鑰不被篡改？
解決方法：將公鑰放在數(shù)字證書中灼舍。只要證書是可信的，公鑰就是可信的涨薪。
（2）公鑰加密計算量太大骑素，如何減少耗用的時間？
解決方法：每一次對話（session）刚夺，客戶端和服務(wù)器端都生成一個"對話密鑰"（session key）献丑，用它來加密信息末捣。由于"對話密鑰"是對稱加密，所以運算速度非炒撮希快箩做，而服務(wù)器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間妥畏。
因此邦邦，SSL/TLS協(xié)議的基本過程是這樣的：
（1） 客戶端向服務(wù)器端索要并驗證公鑰。
（2） 雙方協(xié)商生成"對話密鑰"醉蚁。
（3） 雙方采用"對話密鑰"進行加密通信燃辖。
上面過程的前兩步，又稱為"握手階段"（handshake）网棍。
四黔龟、握手階段的詳細過程
4.1 客戶端發(fā)出請求（ClientHello）
首先惑畴，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請求蛋欣，這被叫做ClientHello請求。
在這一步桨菜，客戶端主要向服務(wù)器提供以下信息豁状。
（1） 支持的協(xié)議版本，比如TLS 1.0版倒得。
** （2） 一個客戶端生成的隨機數(shù)泻红，稍后用于生成"對話密鑰"。**
** （3） 支持的加密方法霞掺，比如RSA公鑰加密谊路。**
** （4） 支持的壓縮方法。**
這里需要注意的是菩彬，客戶端發(fā)送的信息之中不包括服務(wù)器的域名缠劝。也就是說，理論上服務(wù)器只能包含一個網(wǎng)站骗灶，否則會分不清應(yīng)該向客戶端提供哪一個網(wǎng)站的數(shù)字證書惨恭。這就是為什么通常一臺服務(wù)器只能有一張數(shù)字證書的原因。
對于虛擬主機的用戶來說耙旦，這當然很不方便脱羡。2006年，TLS協(xié)議加入了一個Server Name Indication擴展，允許客戶端向服務(wù)器提供它所請求的域名锉罐。
4.2 服務(wù)器回應(yīng)（SeverHello）
服務(wù)器收到客戶端請求后帆竹，向客戶端發(fā)出回應(yīng)，這叫做SeverHello脓规。服務(wù)器的回應(yīng)包含以下內(nèi)容栽连。
（1） 確認使用的加密通信協(xié)議版本，比如TLS 1.0版本侨舆。如果瀏覽器與服務(wù)器支持的版本不一致秒紧，服務(wù)器關(guān)閉加密通信。
（2） 一個服務(wù)器生成的隨機數(shù)态罪，稍后用于生成"對話密鑰"噩茄。
（3） 確認使用的加密方法，比如RSA公鑰加密复颈。
（4） 服務(wù)器證書绩聘。
除了上面這些信息，如果服務(wù)器需要確認客戶端的身份耗啦，就會再包含一項請求凿菩，要求客戶端提供"客戶端證書"。比如帜讲，金融機構(gòu)往往只允許認證客戶連入自己的網(wǎng)絡(luò)衅谷，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書似将。
4.3 客戶端回應(yīng)
客戶端收到服務(wù)器回應(yīng)以后获黔，首先驗證服務(wù)器證書。如果證書不是可信機構(gòu)頒布在验、或者證書中的域名與實際域名不一致玷氏、或者證書已經(jīng)過期，就會向訪問者顯示一個警告腋舌，由其選擇是否還要繼續(xù)通信盏触。
如果證書沒有問題，客戶端就會從證書中取出服務(wù)器的公鑰块饺。然后赞辩，向服務(wù)器發(fā)送下面三項信息。
（1） 一個隨機數(shù)授艰。該隨機數(shù)用服務(wù)器公鑰加密辨嗽，防止被竊聽。
（2） 編碼改變通知淮腾，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送召庞。
（3） 客戶端握手結(jié)束通知岛心，表示客戶端的握手階段已經(jīng)結(jié)束来破。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值篮灼，用來供服務(wù)器校驗。
上面第一項的隨機數(shù)徘禁，是整個握手階段出現(xiàn)的第三個隨機數(shù)诅诱，又稱"pre-master key"。有了它以后送朱，客戶端和服務(wù)器就同時有了三個隨機數(shù)娘荡，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"驶沼。
至于為什么一定要用三個隨機數(shù)炮沐，來生成"會話密鑰"，dog250解釋得很好：
"不管是客戶端還是服務(wù)器回怜，都需要隨機數(shù)大年，這樣生成的密鑰才不會每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的玉雾，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性翔试。對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數(shù)复旬，再加上hello消息中的隨機垦缅，三個隨機數(shù)通過一個密鑰導(dǎo)出器最終導(dǎo)出一個對稱密鑰。pre master的存在在于SSL協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)驹碍，如果隨機數(shù)不隨機壁涎，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了志秃，因此必須引入新的隨機因素怔球，那么客戶端和服務(wù)器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機洽损，可是是三個偽隨機就十分接近隨機了庞溜，每增加一個自由度，隨機性增加的可不是一碑定。"
此外流码，如果前一步，服務(wù)器要求客戶端證書延刘，客戶端會在這一步發(fā)送證書及相關(guān)信息漫试。
4.4 服務(wù)器的最后回應(yīng)
服務(wù)器收到客戶端的第三個隨機數(shù)pre-master key之后，計算生成本次會話所用的"會話密鑰"碘赖。然后驾荣，向客戶端最后發(fā)送下面信息外构。
（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送播掷。
（2）服務(wù)器握手結(jié)束通知审编，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值歧匈，用來供客戶端校驗垒酬。
至此，整個握手階段全部結(jié)束件炉。接下來勘究，客戶端與服務(wù)器進入加密通信，就完全是使用普通的HTTP協(xié)議斟冕，只不過用"會話密鑰"加密內(nèi)容口糕。
