ssl（secure socket layer）最初是由netscape公司開發的乙個協議，其目的在於為網際網路提供乙個安全的通訊機制。netscape最早對外公布的版本是ssl2.0，但是由於ssl2.0有一些安全方面的缺陷，所以後來又重新設計了ssl3.0。ssl後來被ietf（ineternet engineering task force）所採納並重命名為tls（transport layer security），也就是說，tls其實是ssl的後續版本。tls1.0是ssl3.0的乙個公升級版本，後續的小版本還有tls1.1和tls1.2。現在普遍使用的是ssl3.0或者tls1.0。
ssl/tls協議是位於應用層和傳輸層（如tcp）之間的，它和具體的應用層協議無關，也就是說，任何應用層協議都可以使用ssl/tls來獲得安全通訊的能力，如http/ftp/smtp等。
我們知道，網際網路本身是乙個公共的、不安全的網路。資料在網際網路上傳輸時，無法避免會被惡意的第三方監視、偷聽、截獲甚至篡改，更有甚者，正在和我們通訊的對方有可能根本就是假冒的，比如釣魚**等。既然ssl/tls要為網際網路提供乙個安全通訊的機制，那麼它必須解決這裡所有提到的安全問題，具體說，ssl/tls通過下面三個方面來為網際網路通訊提供安全保證。
ssl/tls對要傳輸的資料進行加密，這樣在網際網路的傳輸資料就是加密後的密文，即使被惡意的第三方監視和偷聽，由於沒有解密秘鑰，所以無法理解密文的意思。這也稱為ssl/tsl的防偷聽機制。
加密分為對稱加密和非對稱加密。對稱加密（aes/rc4/3des）的優點是效率高，然而對稱加密使用的加密解密秘鑰是一樣的，這意味著加密方（即傳送方）必須把秘鑰傳送給接收方，顯然，在傳輸秘鑰的過程中，如果不加以保護，秘鑰就會被洩露。非對稱加密（rsa/ecc）則克服了對稱加密需要傳輸秘鑰的弱點，但是非對稱加密的效率很低，如果傳輸的資料量很大，那麼使用非對稱加密將是十分耗時的。也就是說，無論是對稱加密還是非對稱加密，都不能很好地滿足資料加密傳輸的要求，為此，ssl/tls對這兩種方法取長補短，綜合應用。ssl/tls利用非對稱加密來交換秘鑰資訊（秘鑰資訊並不是秘鑰，而是生成秘鑰時所需要用到的資訊），由於秘鑰資訊的資料量很少，使用非對稱加密還是可以接受的。而對於要傳輸的資料，ssl/tls則使用對稱加密，其秘鑰由前面使用非對稱加密傳輸得到的秘鑰資訊生成。由於秘鑰資訊是使用非對稱加密的，所以其在傳輸過程中是安全的（惡意的第三方沒有私鑰無法進行解密）。
由於惡意的第三方能夠截獲傳輸中的資料並把資料篡改後再發給接收方，所以ssl/tls還必須提供一種方法來檢測資料是否被篡改過。這也稱為ssl/tls的防篡改機制。具體地說，ssl/tls使用mac（訊息驗證碼）來實現防篡改，即在傳送訊息之前，把該訊息和乙個通訊雙方共享的秘鑰作為乙個hash演算法（md5/sha1）的輸入，再把由此求得的摘要值聯通資訊一起傳送給對方。
ssl/tls通過驗證身份來確保不會和假冒的對方通訊。這也稱為ssl/tls的防假冒機制。ssl/tls使用由私鑰簽名的數字證書來實現防假冒。一般來說，伺服器需要把它的數字證書傳給客戶端來驗證，而客戶端不一定需要提供證書。
在開始傳輸應用程式資料之前，通訊的雙方必須先進行ssl/tls握手。在握手的過程，雙方交換並協商重要的資訊，包括將要使用的ssl/tls協議版本、加密演算法、mac演算法、驗證演算法，以及用於各種演算法的秘鑰等。當然，任一方都可以在握手的過程中來驗證對方的真偽，一旦驗證失敗，握手過程將被終止，同時這個ssl/tls連線也會被終止。具體說，ssl/tls的握手過程可以分為三個階段：引數協商、身份驗證，以及秘鑰交換。
在這個階段，客戶端和伺服器確定乙個雙方都能支援的最高版本的ssl/tls協議，同時確定它們所使用的演算法組合（cipher suite）。演算法組合是分別用於不同目的的三個演算法的組合，包含用於交換秘鑰（key exchange）和身份驗證的演算法，用於加密應用程式資料的對稱加密演算法，以及用於訊息驗證的mac演算法。在ssl/tls中，乙個演算法組合可以用乙個字串來表示，如「tls_rsa_whit_rc4_128_md5」，這個演算法組合表示使用rsa來交換秘鑰和驗證身份，使用rc4來加密應用程式資料，以及使用md5來驗證訊息內容（即防篡改）。另外，在這個階段中，客戶端和伺服器會分別產生乙個隨機數，然後把其傳給對方，它們將會在後面的秘鑰交換階段中用到。
如果在引數協商階段時所確定的演算法組合要求進行身份驗證（如rsa），則伺服器需要提供資訊（伺服器證書）來讓客戶端對齊進行身份驗證。反過來，伺服器也可以要求客戶端提供證書，以便伺服器也能夠驗證客戶端的身份，不過這並不是必須的。是否需要驗證客戶端主要是根據應用程式的要求。
在身份驗證通過以後，就可以進入金鑰交換階段。注意，在這個階段，客戶端和伺服器並不是直接交換秘鑰，而是交換生成秘鑰所需要用的資訊，這個資訊被稱為pre-master secret，其實就是乙個有客戶端產生的隨機數。如果在引數協商階段時所確定的演算法組合指明使用rsa來交換秘鑰，那麼客戶端將使用伺服器的公鑰（包含在伺服器的數字證書中）來加密這個pre-master secret，然後再傳給伺服器，由於只有伺服器才有私鑰來進行解密，所以pre-master secret的傳輸是安全的。有了pre-master secret之後，客戶端和伺服器還需要再計算乙個master secret，這是因為最終的秘鑰都是基於master secret而生成的。master secret本身則是通過對三個隨機數進行計算而得到的，除了pre-master secret之外，另外兩個隨機數則是在引數協商階段交換的客戶端隨機數和伺服器隨機數。
最終生成的秘鑰一共有4個，分別是：
下面結合對www.sogou.com的抓包，具體看著三個階段中的各個步驟：
總覽：
客戶端傳送乙個clienthello訊息給伺服器，該訊息包含客戶端所能支援的ssl/tls最高版本，以及乙個支援的演算法組合列表，當然，還有客戶端生成的隨機數。
伺服器給客戶端傳送乙個serverhello訊息，該訊息包含伺服器所選擇的ssl/tls版本號以及演算法組合，同時還有伺服器產生的隨機數
如果在步驟2中所選擇的演算法組合包含rsa，則伺服器向客戶端傳送它的數字證書，客戶端將會驗證伺服器的身份。
伺服器向客戶端傳送serverhellodone訊息，表示伺服器完成協商階段的工作。
客戶端產生乙個隨機的pre-master secret，然後想伺服器傳送乙個clientkeyexchange訊息，該訊息包含使用伺服器公鑰加密的pre-master secret
客戶端和伺服器各自使用pre-master secret，步驟1中產生的客戶端隨機數，以及步驟2中產生的伺服器隨機數來計算乙個master secret。有了master secret之後，客戶端和伺服器就可以使用master secret來計算後面所有需要用到的秘鑰。
客戶端傳送乙個changecipherspec通知給伺服器，表明客戶端將要開始使用剛才生成的秘鈅來加密和驗證資料。最後，客戶端傳送乙個clientfinish訊息。
伺服器收到了客戶端的changecipherspec通知之後，也會對客戶端傳送changecipherspec通知，最後，伺服器傳送乙個clientfinish訊息。
在完成握手之後，就可以使用握手過程中所生成的秘鈅來加密應用程式資料以及驗證訊息了。
SSL TLS 握手過程
transport layer security 傳輸層安全協議 high performance browser networking o reilly transport layer security tls defined protocol year ssl 1.0 n assl 2.0 19...
SSL TLS 握手過程詳解
我們知道，http 協議都是明文傳輸內容，在早期只展示靜態內容時沒有問題。伴隨著網際網路的快速發展，人們對於網路傳輸安全性的要求也越來越高，https 協議因此出現。如上圖所示，在 https 加密中真正起作用的其實是 ssl tls 協議。ssl tls 協議作用在 http 協議之下，對於上層應...
SSL TLS 握手過程詳解
我們知道，http 協議都是明文傳輸內容，在早期只展示靜態內容時沒有問題。伴隨著網際網路的快速發展，人們對於網路傳輸安全性的要求也越來越高，https 協議因此出現。如下圖所示，在 https 加密中真正起作用的其實是 ssl tls 協議。ssl tls 協議作用在 http 協議之下，對於上層應...