網際網路的通信安全，建立在SSL/TLS協定之上。
本文簡要介紹SSL/TLS協定的運作機制。文章的重點是設計思想和運作過程，不涉及具體的實作細節。如果想了解這方面的内容，請參閱RFC文檔。
一、作用
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有資訊明文傳播，帶來了三大風險。
（1） 竊聽風險（eavesdropping）：第三方可以獲知通信内容。
（2） 篡改風險（tampering）：第三方可以修改通信内容。
（3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協定是為了解決這三大風險而設計的，希望達到：
（1） 所有資訊都是加密傳播，第三方無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。
網際網路是開放環境，通信雙方都是未知身份，這為協定的設計帶來了很大的難度。而且，協定還必須能夠經受所有匪夷所思的攻擊，這使得SSL/TLS協定變得異常複雜。
二、曆史
網際網路加密通信協定的曆史，幾乎與網際網路一樣長。
1994年，NetScape公司設計了SSL協定（Secure Sockets Layer）的1.0版，但是未釋出。
1995年，NetScape公司釋出SSL 2.0版，很快發現有嚴重漏洞。
1996年，SSL 3.0版問世，得到大規模應用。
1999年，網際網路标準化組織ISOC接替NetScape公司，釋出了SSL的更新版TLS 1.0版。
2006年和2008年，TLS進行了兩次更新，分别為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流浏覽器都已經實作了TLS 1.2的支援。
TLS 1.0通常被标示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
三、基本的運作過程
SSL/TLS協定的基本思路是采用公鑰加密法，也就是說，用戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。
但是，這裡有兩個問題。
（1）如何保證公鑰不被篡改？
解決方法：将公鑰放在數字證書中。隻要證書是可信的，公鑰就是可信的。
（2）公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），用戶端和伺服器端都生成一個"對話密鑰"（session key），用它來加密資訊。由于"對話密鑰"是對稱加密，是以運算速度非常快，而伺服器公鑰隻用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。
是以，SSL/TLS協定的基本過程是這樣的：
（1） 用戶端向伺服器端索要并驗證公鑰。
（2） 雙方協商生成"對話密鑰"。
（3） 雙方采用"對話密鑰"進行加密通信。
上面過程的前兩步，又稱為"握手階段"（handshake）。
四、握手階段的詳細過程
"握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的。
4.1 用戶端送出請求（ClientHello）
首先，用戶端（通常是浏覽器）先向伺服器發出加密通信的請求，這被叫做ClientHello請求。
在這一步，用戶端主要向伺服器提供以下資訊。
（1） 支援的協定版本，比如TLS 1.0版。
（2） 一個用戶端生成的随機數，稍後用于生成"對話密鑰"。
（3） 支援的加密方法，比如RSA公鑰加密。
（4） 支援的壓縮方法。
這裡需要注意的是，用戶端發送的資訊之中不包括伺服器的域名。也就是說，理論上伺服器隻能包含一個網站，否則會分不清應該向用戶端提供哪一個網站的數字證書。這就是為什麼通常一台伺服器隻能有一張數字證書的原因。
對于虛拟主機的使用者來說，這當然很不友善。2006年，TLS協定加入了一個Server Name Indication擴充，允許用戶端向伺服器提供它所請求的域名。
4.2 伺服器回應（SeverHello）
伺服器收到用戶端請求後，向用戶端發出回應，這叫做SeverHello。伺服器的回應包含以下内容。
（1） 确認使用的加密通信協定版本，比如TLS 1.0版本。如果浏覽器與伺服器支援的版本不一緻，伺服器關閉加密通信。
（2） 一個伺服器生成的随機數，稍後用于生成"對話密鑰"。
（3） 确認使用的加密方法，比如RSA公鑰加密。
（4） 伺服器證書。
除了上面這些資訊，如果伺服器需要确認用戶端的身份，就會再包含一項請求，要求用戶端提供"用戶端證書"。比如，金融機構往往隻允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裡面就包含了一張用戶端證書。
4.3 用戶端回應
用戶端收到伺服器回應以後，首先驗證伺服器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一緻、或者證書已經過期，就會向通路者顯示一個警告，由其選擇是否還要繼續通信。
如果證書沒有問題，用戶端就會從證書中取出伺服器的公鑰。然後，向伺服器發送下面三項資訊。
（1） 一個随機數。該随機數用伺服器公鑰加密，防止被竊聽。
（2） 編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。
（3） 用戶端握手結束通知，表示用戶端的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供伺服器校驗。
上面第一項的随機數，是整個握手階段出現的第三個随機數，又稱"pre-master key"。有了它以後，用戶端和伺服器就同時有了三個随機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。
至于為什麼一定要用三個随機數，來生成"會話密鑰"，dog250解釋得很好：
"不管是用戶端還是伺服器，都需要随機數，這樣生成的密鑰才不會每次都一樣。由于SSL協定中證書是靜态的，是以十分有必要引入一種随機因素來保證協商出來的密鑰的随機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個随機數，再加上hello消息中的随機，三個随機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協定不信任每個主機都能産生完全随機的随機數，如果随機數不随機，那麼pre master secret就有可能被猜出來，那麼僅适用pre master secret作為密鑰就不合适了，是以必須引入新的随機因素，那麼用戶端和伺服器加上pre master secret三個随機數一同生成的密鑰就不容易被猜出了，一個僞随機可能完全不随機，可是是三個僞随機就十分接近随機了，每增加一個自由度，随機性增加的可不是一。"
此外，如果前一步，伺服器要求用戶端證書，用戶端會在這一步發送證書及相關資訊。
4.4 伺服器的最後回應
伺服器收到用戶端的第三個随機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。然後，向用戶端最後發送下面資訊。
（1）編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。
（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供用戶端校驗。
至此，整個握手階段全部結束。接下來，用戶端與伺服器進入加密通信，就完全是使用普通的HTTP協定，隻不過用"會話密鑰"加密内容。