互聯網的通信安全，建立在SSL/TLS協議之上。
以下僅介紹SSL/TLS協議的運行機制。重點是設計思想和運行過程，不涉及具體的實現細節。如果想了解這方面的內容，可參閱RFC文檔。
簡介
SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是爲網絡通信提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層對網絡連接進行加密
歷史
Secure Socket Layer，爲Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術，可確保數據在網絡上之傳輸過程中不會被截取及竊聽。一般通用之規格爲40 bit之安全標準，美國則已推出128 bit之更高安全標準，但限制出境。只要3.0版本以上之I.E.或Netscape瀏覽器即可支持SSL。
當前版本爲3.0。它已被廣泛地用於Web瀏覽器與服務器之間的身份認證和加密數據傳輸。
SSL協議位於TCP/IP協議與各種應用層協議之間，爲數據通訊提供安全支持。SSL協議可分爲兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。
其實，互聯網加密通信協議的歷史，幾乎與互聯網一樣長。
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的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來了三大風險。（第三方是指除客戶端和服務器端者）
（1） 竊聽風險（eavesdropping）：第三方可以獲知通信內容。
（2） 篡改風險（tampering）：第三方可以修改通信內容。
（3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協議是爲了解決這三大風險而設計的，希望達到：
（1） 所有信息都是加密傳播，第三方無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。
互聯網是開放環境，通信雙方都是未知身份，這爲協議的設計帶來了很大的難度。而且，協議還必須能夠經受所有匪夷所思的攻擊，這使得SSL/TLS協議變得異常複雜。
服務器類型
- Tomcat 5.x
- Nginx
- IIS
- Apache 2.x
- IBM HTTP SERVER 6.0[1]
運行過程
SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然後用公鑰加密信息，服務器收到密文後，用自己的私鑰解密。
但是，這裏有兩個問題。
（1）如何保證公鑰不被篡改？
解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。
（2）公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由於"對話密鑰"是對稱加密，所以運算速度非常快，而服務器公鑰只用於加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。
因此，SSL/TLS協議的基本過程是這樣的：
（1） 客戶端向服務器端索要並驗證公鑰。
（2） 雙方協商生成"對話密鑰"。
（3） 雙方採用"對話密鑰"進行加密通信。
上面過程的前兩步，又稱爲"握手階段"（handshake）。
握手階段詳細流程
"握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的。
SSL協議提供的安全通道有以下三個特性：
機密性：SSL協議使用密鑰加密通信數據。
可靠性：服務器和客戶都會被認證，客戶的認證是可選的。
完整性：SSL協議會對傳送的數據進行完整性檢查。
從SSL 協議所提供的服務及其工作流程可以看出，SSL協議運行的基礎是商家對消費者信息保密的承諾，這就有利於商家而不利於消費者。在電子商務初級階段，由於運作電子商務的企業大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨着電子商務的發展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL3.0中通過數字簽名和數字證書可實現瀏覽器和Web服務器雙方的身份驗證，但是SSL協議仍存在一些問題，比如，只能提供交易中客戶與服務器間的雙方認證，在涉及多方的電子交易中，SSL協議並不能協調各方間的安全傳輸和信任關係。在這種情況下，Visa和 MasterCard兩大信用卡公組織制定了SET協議，爲網上信用卡支付提供了全球性的標準。
1. 客戶端發出請求（ClientHello）
首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做ClientHello請求。
在這一步，客戶端主要向服務器提供以下信息。
（1） 支持的協議版本，比如TLS 1.0版。
（2） 一個客戶端生成的隨機數，稍後用於生成"對話密鑰"。
（3） 支持的加密方法，比如RSA公鑰加密。
（4） 支持的壓縮方法。
這裏需要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是爲什麼通常一臺服務器只能有一張數字證書的原因。
對於虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
2. 服務器迴應（SeverHello）
服務器收到客戶端請求後，向客戶端發出迴應，這叫做SeverHello。服務器的迴應包含以下內容。
（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
（2） 一個服務器生成的隨機數，稍後用於生成"對話密鑰"。
（3） 確認使用的加密方法，比如RSA公鑰加密。
（4） 服務器證書。
除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裏面就包含了一張客戶端證書。
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. 服務器的最後迴應
服務器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。然後，向客戶端最後發送下面信息。
（1）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。
至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。
SSL體系結構
SSL的體系結構中包含兩個協議子層，其中底層是SSL紀錄協議層（SSL Record Protocol Layer）；高層是SSL握手協議層（SSL HandShake Protocol Layer）。SSL的協議棧如圖所示，其中陰影部分即SSL協議。
SSL紀錄協議層的作用是爲高層協議提供基本的安全服務。SSL紀錄協議針對HTTP協議進行了特別的設計，使得超文本的傳輸協議HTTP能夠在SSL運行。紀錄封裝各種高層協議，具體實施壓縮解壓縮、加密解密、計算和校驗MAC等與安全有關的操作。
SSL握手協議層包括SSL握手協議（SSL HandShake Protocol）、SSL密碼參數修改協議（SSL Change Cipher Spec Protocol）、應用數據協議（Application Data Protocol）和SSL告警協議（SSL Alert Protocol）。握手層的這些協議用於SSL管理信息的交換，允許應用協議傳送數據之間相互驗證，協商加密算法和生成密鑰等。SSL握手協議的作用是協調客戶和服務器的狀態，使雙方能夠達到狀態的同步。
SSL記錄協議
SSL紀錄協議（Record Protocol）爲SSL連提供兩種服務。[2]
（1）保密性：利用握手協議所定義的共享密鑰對SSL淨荷（Payload）加密。
（2）完整性：利用握手協議所定義的共享的MAC密鑰來生成報文的鑑別碼（MAC）。
SSL的工作過程如下。
（1）發送方的工作過程爲：
從上次接受要發送的數據（包括各種消息和數據）；
對信息進行分段，分成若干紀錄；
使用指定的壓縮算法進行數據壓縮（可選）；
使用指定的MAC算法生成MAC；
使用指定的加密算法進行數據加密；
添加SSL紀錄協議的頭，發送數據。
（2）接收方的工作過程爲：
接收數據，從SSL紀錄協議的頭中獲取相關信息；
使用指定的解密算法解密數據；
使用指定的MAC算法校驗MAC；
使用壓縮算法對數據解壓縮（在需要進行）；
將紀錄進行數據重組；
將數據發送給高層。
SSL紀錄協議處理的最後一個步驟是附加一個SSL紀錄協議的頭，以便構成一個SSL紀錄。SSL紀錄協議頭中包含了SSL紀錄協議的若干控制信息。
會話狀態
會話（Session）和連接（Connection）是SSL中兩個重要的概念，在規範中定義如下。[3]
（1）SSL連接：用於提供某種類型的服務數據的傳輸，是一種點對點的關係。一般來說，連接的維持時間比較短暫，並且每個連接一定與某一個會話相關聯。
（2）SSL會話：是指客戶和服務器之間的一個關聯關係。會話通過握手協議來創建。它定義了一組安全參數。
一次會話過程通常會發起多個SSL連接來完成任務，例如一次網站的訪問可能需要多個HTTP/SSL/TCP連接來下載其中的多個頁面，這些連接共享會話定義的安全參數。這種共享方式可以避免爲每個SSL連接單獨進行安全參數的協商，而只需在會話建立時進行一次協商，提高了效率。
每一個會話（或連接）都存在一組與之想對應的狀態，會話（或連接）的狀態表現爲一組與其相關的參數集合，最主要的內容是與會話（或連接）相關的安全參數的集合，用會話（或連接）中的加密解密、認證等安全功能的實現。在SSL通信過程中，通信算法的狀態通過SSL握手協議實現同步。
根據SSL協議的約定，會話狀態由以下參數來定義：
（1）會話標識符：是由服務器選擇的任意字節序列，用於標識活動的會話或可恢復的會話狀態。
（2）對方的證書：會話對方的X.509v3證書。該參數可爲空。
（3）壓縮算法：在加密之前用來壓縮數據的算法。
（4）加密規約（Cipher Spec）：用於說明對大塊數據進行加密採用的算法，以及計算MAC所採用的散列算法。
（5）主密值：一個48字節長的祕密值，由客戶和服務器共享。
（6）可重新開始的標識：用於指示會話是否可以用於初始化新的連接。
連接狀態可以一下參數來定義：
（1）服務器和客戶器的隨機數：是服務器和客戶爲每個連接選擇的用於標識連接的字節序列。
（2）服務器寫MAC密值：服務器發送數據時，生成MAC
（3）使用的密鑰，長度爲128 bit。
（4）客戶寫MAC密值，服務器發送數據時，用於數據加密的密鑰，長度爲128 bit 。
（5）客戶寫密鑰：客戶發送數據時，用於數據加密的密鑰，長度爲128 bit。
（6）初始化向量：當使用CBC模式的分組密文算法是=時，需要爲每個密鑰維護初始化向量。
（7）序列號：通信的每一端都爲每個連接中的發送和接收報文維持着一個序列號。
SSL證書
HTTP+SSL = HTTPS http是明文傳輸
Secure Socket Layer 安全套接字層
分類：
擴展驗證型(EV)SSL證書
組織驗證型(OV)SSL證書
域名驗證型（DV）SSL證書
DV：指只驗證網站域名所有權的簡易型SSL證書，此類證書僅能起到網站機密信息加密的作用，無法向用戶證明網站的真實身份。
10分鐘左右就可完成域名驗證和快速頒發證書，無需遞交紙質文件，僅驗證域名管理權，無需人工驗證申請單位真實身份。DV SSL 證書不在證書中顯示申請單位名稱，只顯示網站域名。
OV：指需要驗證網站所有單位的真實身份的標準型SSL證書，此類證書也就是正常的SSL證書，不僅能起到網站機密信息加密的作用，而且能向用戶證明網站的真實身份。從 SSL 證書的誕生史可以看出：標準型 SSL 證書就是 OV SSL證書(Organization Validation SSL)。
通過證書頒發機構審查網站企業身份和域名所有權以證明申請單位是一個合法存在的真實實體，CA機構將在人工覈實後簽發證書，用戶可以在證書裏面看到申請SSL證書的公司名稱。
EV：（ Extended Validation SSL）指遵循全球統一的嚴格身份驗證標準頒發的SSL證書，是目前業界最高安全級別的SSL證書。用戶訪問部署了EV SSL證書的網站，不僅瀏覽器地址欄會顯示安全鎖標誌，而且瀏覽器地址欄會變成綠色。
通過極其嚴格甚至苛刻審查網站企業身份和域名所有權，確保網站身份的真實可靠並且需要 CA 機構人工驗證組織和電話信息。
包含信息
證書的發佈機構 SecureTrust CA
證書的有效期 valid from，valid to
公鑰 public key
證書所有者（Subject）
簽名所使用的算法 signature algorithm
指紋以及指紋算法 Thumbprint, Thumbprint algorithm ：保證證書完整性，證書所有內容的hash值。
包含協議
SSL的工作原理中包含如下三個協議。
握手協議（Handshake protocol）
記錄協議（Record protocol）
警報協議（Alert protocol）
https介紹
HTTPS（Hypertext Transfer Protocol Secure）安全超文本傳輸協議
它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的完全套接字層（SSL）作爲HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信。）SSL使用40 位關鍵字作爲RC4流加密算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。。
https是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，https的安全基礎是SSL，因此加密的詳細內容請看SSL。
它是一個URI scheme(抽象標識符體系)，句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。
限制
它的安全保護依賴瀏覽器的正確實現以及服務器軟件、實際加密算法的支持.
一種常見的誤解是“銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號不被偷竊。”實際上，與服務器的加密連接中能保護銀行卡號的部分，只有用戶到服務器之間的連接及服務器自身。並不能絕對確保服務器自己是安全的，這點甚至已被攻擊者利用，常見例子是模仿銀行域名的釣魚攻擊。少數罕見攻擊在網站傳輸客戶數據時發生，攻擊者嘗試竊聽數據於傳輸中。
商業網站被人們期望迅速儘早引入新的特殊處理程序到金融網關，僅保留傳輸碼(transaction number)。不過他們常常存儲銀行卡號在同一個數據庫裏。那些數據庫和服務器少數情況有可能被未授權用戶攻擊和損害。[4]
應用
extended validation ssl certificates翻譯爲中文即擴展驗證（EV）SSL證書，該證書經過最徹底的身份驗證，確保證書持有組織的真實性。獨有的綠色地址欄技術將循環顯示組織名稱和作爲CA的GlobalSign名稱，從而最大限度上確保網站的安全性，樹立網站可信形象，不給欺詐釣魚網站以可乘之機。
對線上購物者來說，綠色地址欄是驗證網站身份及安全性的最簡便可靠的方式。在IE7.0、FireFox3.0、Opera 9.5等新一代高安全瀏覽器下，使用擴展驗證（EV）SSL證書的網站的瀏覽器地址欄會自動呈現綠色，從而清晰地告訴用戶正在訪問的網站是經過嚴格認證的。此外綠色地址欄臨近的區域還會顯示網站所有者的名稱和頒發證書CA機構名稱，這些均向客戶傳遞同一信息，該網站身份可信，信息傳遞安全可靠，而非釣魚網站。