SSL/TLS產(chǎn)生原因
不加密的通信方式计贰，會有三大風險：
- 竊聽風險（eavesdropping）：第三方可以獲知通信內(nèi)容
- 篡改風險（tampering）：第三方可以修改通信內(nèi)容
- 冒充風險（pretending）：第三方可以冒充他人身份參與通信
為了解決這些風險，所以需要對通信進行加密，于是就有了SSL/TLS協(xié)議的出現(xiàn)十办。SSL/TLS希望能實現(xiàn)以下功能：
- 所有信息都是加密傳播，第三方無法竊聽
- 具有校驗機制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)
- 配備身份證書路克，防止身份被冒充
運行原理
SSL/TLS協(xié)議的基本思路是采用公鑰加密法樟结，也就是說，客戶端先向服務(wù)器端索要公鑰精算，然后用公鑰加密信息瓢宦，服務(wù)器收到密文后，用自己的私鑰解密灰羽。
這里有兩個問題驮履，如何保證公鑰的完整性以及計算耗費資源和時間的問題。
對于這兩個方法谦趣，解決方法分別如下：
- 公鑰篡改： 將公鑰放在數(shù)字證書
中疲吸。只要證書可信，公鑰就是可信的前鹅。 - 加密計算量大： 每一次對話（session），生成一個“對話密鑰”（session key）峭梳，用來加密信息舰绘。“對話密鑰”是對稱加密的葱椭，所以運算速度非澄媸伲快，而服務(wù)器公鑰只用于加密“對話密鑰”孵运，較少了加密運算的時間秦陋。
基于以上的處理方式，SSL/TLS的基本過程是這樣的：
- 客戶端向服務(wù)器端索要并驗證公鑰治笨。
- 雙方協(xié)商生成"對話密鑰"驳概。
- 雙方采用"對話密鑰"進行加密通信。
前兩步也被稱為“握手階段”（handshake）旷赖。
握手階段過程
"握手階段"涉及四次通信顺又。需要注意的是，"握手階段"的所有通信都是明文的等孵。
客戶端發(fā)出請求（ClientHello）
首先稚照，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請求，這被叫做ClientHello請求俯萌。
在這一步果录，客戶端主要向服務(wù)器提供以下信息。
- 支持的協(xié)議版本咐熙，比如TLS 1.0版弱恒。
- 一個客戶端生成的隨機數(shù)，稍后用于生成"對話密鑰"糖声。
- 支持的加密方法斤彼，比如RSA公鑰加密分瘦。
- 支持的壓縮方法。
這里需要注意的是琉苇，客戶端發(fā)送的信息之中不包括服務(wù)器的域名嘲玫。也就是說，理論上服務(wù)器只能包含一個網(wǎng)站并扇，否則會分不清應(yīng)該向客戶端提供哪一個網(wǎng)站的數(shù)字證書去团。這就是為什么通常一臺服務(wù)器只能有一張數(shù)字證書的原因。
對于虛擬主機的用戶來說穷蛹，這當然很不方便土陪。2006年，TLS協(xié)議加入了一個Server Name Indication擴展肴熏，允許客戶端向服務(wù)器提供它所請求的域名鬼雀。
服務(wù)器回應(yīng)（SeverHello）
服務(wù)器收到客戶端請求后，向客戶端發(fā)出回應(yīng)蛙吏，這叫做SeverHello源哩。服務(wù)器的回應(yīng)包含以下內(nèi)容。
- 確認使用的加密通信協(xié)議版本鸦做，比如TLS 1.0版本励烦。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信泼诱。
- 一個服務(wù)器生成的隨機數(shù)坛掠，稍后用于生成"對話密鑰"。
- 確認使用的加密方法治筒，比如RSA公鑰加密屉栓。
- 服務(wù)器證書。
除了上面這些信息矢炼，如果服務(wù)器需要確認客戶端的身份系瓢，就會再包含一項請求，要求客戶端提供"客戶端證書"句灌。比如夷陋，金融機構(gòu)往往只允許認證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰胰锌，里面就包含了一張客戶端證書骗绕。
客戶端回應(yīng)
客戶端收到服務(wù)器回應(yīng)以后，首先驗證服務(wù)器證書资昧。如果證書不是可信機構(gòu)頒布酬土、或者證書中的域名與實際域名不一致、或者證書已經(jīng)過期格带，就會向訪問者顯示一個警告撤缴，由其選擇是否還要繼續(xù)通信刹枉。
如果證書沒有問題，客戶端就會從證書中取出服務(wù)器的公鑰屈呕。然后微宝，向服務(wù)器發(fā)送下面三項信息。
- 一個隨機數(shù)虎眨。該隨機數(shù)用服務(wù)器公鑰加密蟋软，防止被竊聽。
- 編碼改變通知嗽桩，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送岳守。
- 客戶端握手結(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ù)通過一個密鑰導出器最終導出一個對稱密鑰俩檬。
pre master的存在在于SSL協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)萎胰，如果隨機數(shù)不隨機，那么pre master secret就有可能被猜出來棚辽，那么僅適用pre master secret作為密鑰就不合適了技竟，因此必須引入新的隨機因素，那么客戶端和服務(wù)器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了屈藐，一個偽隨機可能完全不隨機榔组，可是是三個偽隨機就十分接近隨機了熙尉，每增加一個自由度，隨機性增加的可不是一搓扯。"
此外检痰，如果前一步，服務(wù)器要求客戶端證書擅编，客戶端會在這一步發(fā)送證書及相關(guān)信息攀细。
服務(wù)器的最后回應(yīng)
服務(wù)器收到客戶端的第三個隨機數(shù)pre-master key之后，計算生成本次會話所用的"會話密鑰"爱态。然后谭贪，向客戶端最后發(fā)送下面信息。
- 編碼改變通知锦担，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送俭识。
- 服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束洞渔。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值套媚，用來供客戶端校驗。
至此磁椒，整個握手階段全部結(jié)束堤瘤。接下來，客戶端與服務(wù)器進入加密通信浆熔，就完全是使用普通的HTTP協(xié)議本辐，只不過用"會話密鑰"加密內(nèi)容。
