ssl

要了解SSL協議，首先要了解：加密演演算法、消息摘要演演算法（又稱為哈希演演算法Hash），數字簽名等概念。這些技術每個都可以寫出一整本的書，它們結合在一起，提供了保密性、完整性和身份驗證的功能。

加密演演算法

設想：ALICE想發消息給她的銀行要匯出一筆款。ALICE希望這些消息是保密的，因為這裡面包括她的帳戶資料和匯款金額。一種辦法是使用加密演演算法，這種技術將她要傳遞的消息變成經過加密的密文，直接銀行解密才可以被讀取。如果採用這種形式，消息只能被一個密鑰所加密。沒有這個密鑰，消息就是無用的。一個良好的加密演演算法，可以使入侵者面臨無法克服困難來解密原文。

有兩種加密演演算法系列：傳統加密演演算法（對稱加密）和公鑰加密演演算法（非對稱加密）

傳統加密演演算法---對稱加密，需要發送者和接收者共享一個密鑰：同時用於加密和解密的信息。只要密鑰是保密的，除了收件人和發件人外沒有人可以閱讀該消息。如果Alice和銀行知道這個密鑰，那麼他們可以給對方發送的經過此密鑰加密的消息。這種演演算法的主要任務在於發送者和接收者如何共享一個密鑰，同時確保沒有第三方知道這個密鑰，如果多人之間傳遞消息，如何保證這麼多密鑰的安全，就是一個棘手的問題。

公鑰加密演演算法---為非對稱加密技術，通過使用2個密鑰（其中一個可以解密另外一個加密的消息），解決了加密密鑰交換的問題。如果用其中的一個密鑰用於加密信息，必須使用另外一個密鑰來解密。這樣就有可能獲得簡單地發布一個密鑰（公鑰），並使用未發布的密鑰（私鑰）來接受經過公鑰加密的消息。

任何人都可以使用公共密鑰加密消息，但只有私鑰擁有者將能夠讀取它。這樣，ALICE可以在發送需要保密的匯款消息給銀行的時候，可以使用銀行的密鑰對中的公鑰來對這個消息進行加密，而只有銀行可以使用他們自己保管的私鑰來進行解密。

消息摘要演演算法

雖然ALICE可以加密她的消息，但仍然有一個問題，就是有人可能會修改她發給銀行的消息，並將ALICE的錢轉移到自己的帳戶上。為了保證ALICE消息在傳遞過程中沒有被人篡改，可以讓她創建一個消息的摘要和加密的消息一起寄到銀行，銀行收到消息后，將消息和消息的摘要做一個比較，如果消息內容和摘要匹配，則就可以證明消息傳遞過程中，沒有別人篡改。

像這樣的摘要被稱為消息摘要，單向函數或哈希函數。消息摘要用於創建一個簡短的固定長度，或可變長度的消息。消息摘要演演算法被設計成為每個消息產生一條獨立的信息摘要。消息摘要演演算法的目的，就是讓人無法為兩條不同的消息找到相同的消息摘要，從而消除了使用一條摘要相同的消息替換另外一條消息的可能性。

另一個愛麗絲面臨的挑戰是找到一種方法，即使安全地將消息摘要發送到銀行；如果消息摘要發送過程不安全，銀行將無法判斷消息是否就是來自ALICE。只有在消息摘要能安全地發送，才能夠使消息的完整性被確定。

一個安全發送消息摘要的方式是使用數字簽名。

數字簽名

當Alice將消息發送給銀行，銀行需要確保消息真正地是從她這裡發出的，以確保入侵者不能使用她的帳戶進行交易。簽名就是由ALICE為實現這一目的而創建的一個專門消息。

數字簽名主要使用私鑰來加密消息摘要和其他信息，譬如一個序列號，雖然任何人都可以使用公鑰解密數字簽名，只有發送方知道私鑰。這意味著，只有發件人可以簽署了該消息。包含了信息摘要的簽名表示這個簽名只對這個消息有效，而且它確保了消息的完整性，即這個消息的發送過程中沒人可以改變摘要並另外對它做簽名。

為了防止入侵者攔截，並在以後再次使用這個簽名，簽名包含一個唯一的序列號。這樣可以保證ALICE無法否認她曾經發送過這條消息，因為只有她可以簽名這條消息（不可抵賴性）。

證書

雖然ALICE給銀行發出一條經過她個人私鑰簽名的消息，並且可以確保她發送的消息是真實可靠的，但她依然要確保她的確是和銀行在通信。這意味著她必須確保她使用的公鑰是銀行密鑰對中的公鑰，而不是入侵者的。同樣道理，銀行業也需要核實用於簽名該消息的私鑰是屬於ALICE的。如何使銀行和ALICE能否核實對方的身份呢？

如果每個人的證書都由一個大家都信任的機構簽名，那麼每個人都可以驗證其他有該證書的人的身份。這種被大家都信任的機構，稱為認證中心（CA)，比如知名的認證中心有Versign，Wosign，Thawte等，他們負責認證證書。

證書的內容

證書內容包括：公鑰和真實身份識別信息，包括個人，伺服器或其他實體。如表1所示，主題信息包括身份識別信息（DN）和公鑰。它還包括認證和簽發的CA簽發這個證書的有效期，還可能有一些其他的信息（或者成為擴展信息），一般由CA自行定義使用的管理信息，譬如序列號等。

表一：證書信息

識別名DN是用來提供對某個特定背景下的身份，例如：某個人作為公司的一個僱員而擁有一個證書。識別名DN有X.509標準定義，包括它的欄位，欄位名和相應的縮寫表示。（如表2所示）

表二：識別名(DN)信息

證書頒發機構可以定義一個策略，指明哪些識別名欄位名是可選的，哪些是必需的。很多證書還對某些欄位的內容做出要求。例如，Netsacpe瀏覽器要求一個伺服器證書的CN能夠匹配通配符樣式的域名，例如：*.snakeoil.com。

證書的二進位格式是使用了ASN.1（抽象語法標記）定義[X208] [ PKCS]。這種表示法定義了如何指定編碼規則的內容和如何將信息轉換成二進位形式。證書的二進位編碼使用了區分編碼規則Distinguished Encoding Rules (DER)，它是基本編碼規則Basic Encoding Rules (BER)的一個子集。對於那些不能採用二進位的信息傳遞，二進位形式可以轉化為一個ASCII形式使用Base64編碼[MIME]。當證書放置在Begin和End分割線中的時候，這種編碼被稱為增強型安全私人郵件格式(PEM -"Privacy Enhanced Mail") 編碼的證書。

PEM編碼證書的樣例（snakioil.crt)

Example of a PEM-encoded certificate (snakeoil.crt)

-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG

A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h

a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl

cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN

AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB

gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB

gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----

證書頒發機構CA

通過在批准證書之前核實證書請求中的信息，CA可以保證密鑰對的私鑰所有人的身份。舉例，如果Alice請求一個個人證書，證書頒發機構必須首先核實ALICE在證書申請中所提交的個人信息和資料。

證書鏈

CA機構有時也會為另外一家CA機構頒發證書。當檢查證書的時候，ALICE可能需要檢查每一級證書的父親證書，一直找到一個她所能信任的證書為止。為了降低她在檢查證書鏈中遇到一個“壞”證書的風險，ALICE可能會設定可信證書鏈的深度。

創建一個根CA

如前所述，每個證書需要發行者來聲明證書擁有者身份的有效性，一直到最頂層CA。這就產生了一個問題：誰來保證最頂層CA的權威性，而這個CA是沒有發行者。在這個獨特的情況下，證書採用一種“自簽名”的方式，所以證書的發行者就是證書擁有者自己。瀏覽器會將一些知名的CA配置成可信，將他們的根證書安裝到自己的受信根證書列表中，但如果要自己添加信任的自簽名證書，就需要特別當心。

一些公司，例如 GlobalSign、Thawte、Comodo、GeoTrust、Wosign 和 Verisign已經建立了他們自己的證書頒發機構。這些公司提供以下服務：

驗證證書請求

處理證書申請

發行和管理證書

用戶也可以創建自己的證書頒發機構。雖然在網際網路上存在比較大的風險，但它在企業內網中是很有用的，可以輕鬆地驗證個人和伺服器的身份。

證書管理

建立一個證書機構需要有堅實的行政，技術和管理框架。證書頒發機構不僅頒發證書，他們還要管理好證書，也就是說，他們確定證書在多久的時間內仍然有效，他們有一個列表，裡面列舉了過去頒發的，但已經不再有效的證書，並且不斷更新這個列表（證書吊銷清單，或CRL）。

例如：ALICE曾經作為公司的僱員獲得一個證書，但她現在已經離開公司了，她的證書就需要被吊銷。由於證書只在審核完當事人身份后被簽發，並且被傳遞給需要和當事人溝通的同事，從證書本身告訴去告知它已經被吊銷了是不可能的。因此要檢查一個證書是否有效，就必須聯繫CA機構獲取證書吊銷清單CRL，而這通常是無法自動完成的。

注意：

如果你需要使用一個不是瀏覽器預設信任的CA機構，就必須將這個CA的根證書裝入瀏覽器的可信根證書列表，使瀏覽器可以識別這個CA頒發的伺服器證書，但這樣做是非常危險的，因為一旦載入了這個CA的根證書，瀏覽器將接受所有由這個根證書籤發的伺服器證書。

Secure Sockets Layer(SSL) 安全套接字層

SSL是工作在面對連接網路層（如TCP層）和應用層（HTTP層）之間的協議層。SSL層協議通過為客戶端和伺服器提供雙向認證，對隱私數據的加密，和用數字簽名來保證數據完整性，從而提供了一個安全的通信通道。

本協議被設計為支持一系列制定的演演算法用於加密，數據摘要和簽名。這允許對特定伺服器的演演算法選擇建立在法律、出口和其他問題的基礎上，並且使協議能夠利用新的演演算法。在客戶機和伺服器試圖建立一個對話的時候，會協商演演算法。

表4：SSL協議的版本

如表4所示，有多個SSL協議的版本，其中SSL3.0的一個優勢就是它增加了對證書鏈載入的支持。這項功能使伺服器可以將自己的伺服器證書和發行者的證書一起傳給瀏覽器。證書鏈的載入，使得客戶機即使沒有安裝過伺服器的中間證書，也可以來驗證伺服器證書的有效性，因為伺服器的中間證書被放在證書鏈中一起發送給了客戶機。SSL 3.0是安全傳輸層TLS協議的基礎，這項協議正由IETF負責制訂開發。

建立會話

客戶機和伺服器同構一種“握手”次序來建立SSL會話，如圖1.這個握手次序可能會有所不同，這取決於伺服器是否配置成提供伺服器證書，或者需要客戶機提供客戶證書。雖然在其他情況下存在因對密碼管理要求不同而不同的“握手”步驟，詳見各種SSL協議規範，但本文總結了一個基本的握手次序。圖1：基本握手次序

注意：

伺服器為每個SSL會話分配一個唯一的會話標識符並緩存在伺服器和客戶端（直到會話標識符過期），使客戶在下次連接的時候減少了握手的時間。

在握手序列中的被客戶端和伺服器使用的各項要素，如下列所示：

協商數據傳輸中使用的加密套接字。

在客戶機和伺服器中建立並共享一個會話密鑰。

可選的伺服器端身份認證

可選的客戶端身份認證

首先，加密套接字協商，允許客戶端和伺服器選擇一個他們都是支持的加密套接字方式。SSL3.0協議定義了31中加密套接字方式，每一種安全套接字由下列部分組成：

密鑰交換方法

數據加密傳輸

創建消息認證碼（MAC）的消息摘要

這3個要素將在下面的幾節中詳細描述。

密鑰交換方法

密鑰交換方法定義在客戶端和伺服器之間共享雙方都同意的，被用於應用數據傳輸的對稱加密的密鑰。SSL2.0協議只適用RSA密鑰交換方式，而SSL3.0不僅支持RSA密鑰交換（在使用證書的情況下），還支持Diffie-Hellman密鑰交換（在沒有使用證書或者沒有客戶端和伺服器之間通信密鑰之前的情況下。）

在決定密鑰交換方式中的變數是選擇是否需要數字簽名和使用什麼樣的簽名。使用私鑰簽名可以防止在交換共享密鑰的時候，遭受中間人攻擊。

數據加密傳輸

SSL在加密會話中的消息時採用傳統的對稱加密方法，有9種加密方式可以選擇，包括也可以選擇不加密。

No encryption

Stream Ciphers

--RC4 with 40-bit keys

--RC4 with 128-bit keys

CBC Block Ciphers

--RC2 with 40 bit key

--DES with 40 bit key

--DES with 56 bit key

--Triple-DES with 168 bit key

--Idea (128 bit key)

--Fortezza (96 bit key)

“CBC”是Cipher Block Chaining的縮寫，意思為密碼分組鏈接，表示前一段加密后的密文被用當前段的加密中使用。

"DES" 是指Data Encryption Standard，有一系列不同的變數。包括DES40和3DES_EDE

"Idea" 是目前最好的，也是加密強度最高的演演算法。

"RC2" 是RSA DSI專用的演演算法。

摘要函數

對信息摘要函數的選擇決定了如何從一個記錄單元創建一個摘要。SSL支持以下模式：

無摘要

128位哈希的MD5

160位的安全哈希演演算法（SHA - 1）

消息摘要是用來創建一個消息認證碼（MAC），MAC是與消息加密，來核實消息的完整性和保護消息不受回放式攻擊。

握手次序協議

握手次序使用三個協議：

SSL Handshake Protocol. SSL握手協議執行客戶端和伺服器SSL會話的建立過程。

SSL Change Cipher Spec Protocol .SSL更改密碼協議負責協商會話用的密碼套接字。

SSL Alert Protocol.SSL告警協議負責在客戶端和伺服器間傳遞SSL錯誤信息。

這些協議以及應用協議數據，都被SSL記錄協議封裝，如圖2所示。封裝好的數據被不檢查數據的低一層的協議傳遞。下一層的協議對封裝協議來說是未知的。

圖2：SSL協議棧

SSL控制協議對記錄協議的封裝，使一個正在進行的會話在需要重新協商時，控制協議能夠被安全地傳輸。如果沒有前一個會話，則使用空的密碼套接字，也就是說，在會話建立以前，不會使用密碼也沒有驗證完整性的消息摘要。

數據傳輸

SSL記錄協議，如圖3所示 , 用於在客戶端和伺服器之間傳遞SSL控制協議和應用層數據，必需將這些數據分割成較小的單元，或者將多個較高層協議數據合併為一個單元。它可能會在將這些數據傳遞到下一層可靠的傳遞協議前將這些數據壓縮、加密和附加一個摘要簽名。（註：目前主流的SSL都沒有對壓縮的支持）。圖3：SSL記錄協議

安全HTTP通信

SSL最常見的一想用途就是在瀏覽器和WEB伺服器之間加密安全的WEB HTTP通信。使用加密的HTTP（稱為HTTPS），即在SSL協議上使用HTTP協議，並沒有排除HTTP協議，不過在URL地址中使用HTTPS來替換原來的HTTP，並使用另外一個伺服器埠（HTTPS預設使用443，HTTP使用80）。

SSL證書經過身份驗證，確保證書持有組織的真實性。從而最大限度上確保網站的安全性，樹立網站可信形象，不給欺詐釣魚網站以可乘之機。

如果不是綠色地址欄的 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記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密演演算法、交換加密密鑰等。

1）認證用戶和伺服器，確保數據發送到正確的客戶機和伺服器；

2）加密數據以防止數據中途被竊取；

3）維護數據的完整性，確保數據在傳輸過程中不被改變。

1. Tomcat 5.x

2. Nginx

3. IIS

4. Apache 2.x

5. IBM HTTP SERVER 6.0

伺服器認證階段：1）客戶端向伺服器發送一個開始信息“Hello”以便開始一個新的會話連接；2）伺服器根據客戶的信息確定是否需要生成新的主密鑰，如需要則伺服器在響應客戶的“Hello”信息時將包含生成主密鑰所需的信息；3）客戶根據收到的伺服器響應信息，產生一個主密鑰，並用伺服器的公開密鑰加密後傳給伺服器；4）伺服器回復該主密鑰，並返回給客戶一個用主密鑰認證的信息，以此讓客戶認證伺服器。

用戶認證階段：在此之前，伺服器已經通過了客戶認證，這一階段主要完成對客戶的認證。經認證的伺服器發送一個提問給客戶，客戶則返回（數字）簽名后的提問和其公開密鑰，從而向伺服器提供認證。

SSL協議提供的安全通道有以下三個特性：

機密性：SSL協議使用密鑰加密通信數據。

可靠性：伺服器和客戶都會被認證，客戶的認證是可選的。

完整性：SSL協議會對傳送的數據進行完整性檢查。

從SSL 協議所提供的服務及其工作流程可以看出，SSL協議運行的基礎是商家對消費者信息保密的承諾，這就有利於商家而不利於消費者。在電子商務初級階段，由於運作電子商務的企業大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務的發展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL3.0中通過數字簽名和數字證書可實現瀏覽器和Web伺服器雙方的身份驗證，但是SSL協議仍存在一些問題，比如，只能提供交易中客戶與伺服器間的雙方認證，在涉及多方的電子交易中，SSL協議並不能協調各方間的安全傳輸和信任關係。在這種情況下，Visa和 MasterCard兩大信用卡公司組織制定了SET協議，為網上信用卡支付提供了全球性的標準。

SSL的體系結構中包含兩個協議子層，其中底層是SSL記錄協議層（SSL Record Protocol Layer）；高層是SSL握手協議層（SSL HandShake Protocol Layer）。SSL的協議棧如圖1所示，其中陰影部分即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記錄協議（Record Protocol）為SSL連接提供兩種服務。

（1）保密性：利用握手協議所定義的共享密鑰對SSL凈荷（Payload）加密。

（2）完整性：利用握手協議所定義的共享的MAC密鑰來生成報文的鑒別碼（MAC）。

SSL的工作過程如下。

（1）發送方的工作過程為：

從上層接受要發送的數據（包括各種消息和數據）；

對信息進行分段，分成若干記錄；

使用指定的壓縮演演算法進行數據壓縮（可選）；

使用指定的MAC演演算法生成MAC；

使用指定的加密演演算法進行數據加密；

添加SSL記錄協議的頭，發送數據。

（2）接收方的工作過程為：

接收數據，從SSL記錄協議的頭中獲取相關信息；

使用指定的解密演演算法解密數據；

使用指定的MAC演演算法校驗MAC；

使用壓縮演演算法對數據解壓縮（在需要進行）；

將記錄進行數據重組；

將數據發送給高層。

SSL記錄協議處理的最後一個步驟是附加一個SSL記錄協議的頭，以便構成一個SSL記錄。SSL記錄協議頭中包含了SSL記錄協議的若干控制信息。

會話（Session）和連接（Connection）是SSL中兩個重要的概念，在規範中定義如下。

（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使用的密鑰，長度為128 bit。

（3）客戶寫MAC密值，伺服器發送數據時，用於數據加密的密鑰，長度為128 bit 。

（4）客戶寫密鑰：客戶發送數據時，用於數據加密的密鑰，長度為128 bit。

（5）初始化向量：當使用CBC模式的分組密文演演算法是=時，需要為每個密鑰維護初始化向量。

（6）序列號：通信的每一端都為每個連接中的發送和接收報文維持著一個序列號。

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)。不過他們常常存儲銀行卡號在同一個資料庫里。那些資料庫和伺服器少數情況有可能被未授權用戶攻擊和損害。

extended validation ssl certificates翻譯為中文即擴展驗證（EV）SSL證書，該證書經過最徹底的身份驗證，確保證書持有組織的真實性。獨有的綠色地址欄技術將循環顯示組織名稱和作為CA的GlobalSign名稱，從而最大限度上確保網站的安全性，樹立網站可信形象，不給欺詐釣魚網站以可乘之機。

對線上購物者來說，綠色地址欄是驗證網站身份及安全性的最簡便可靠的方式。在IE7.0、FireFox3.0、Opera 9.5等新一代高安全瀏覽器下，使用擴展驗證（EV）SSL證書的網站的瀏覽器地址欄會自動呈現綠色，從而清晰地告訴用戶正在訪問的網站是經過嚴格認證的。此外綠色地址欄臨近的區域還會顯示網站所有者的名稱和頒發證書CA機構名稱，這些均向客戶傳遞同一信息，該網站身份可信，信息傳遞安全可靠，而非釣魚網站。