https

   



   HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協(xié)議

它是由Netscape開發(fā)并內(nèi)置于其瀏覽器中，用于對數(shù)據(jù)進行壓縮和解壓操作，并返回網(wǎng)絡上傳送回的結(jié)果。HTTPS實際上應用了Netscape的完全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信。）SSL使用40 位關(guān)鍵字作為RC4流加密算法，這對于商業(yè)信息的加密是合適的。HTTPS和SSL支持使用X.509數(shù)字認證，如果需要的話用戶可以確認發(fā)送者是誰。。

https是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，https的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容請看SSL。

它是一個URI scheme(抽象標識符體系)，句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統(tǒng)的最初研發(fā)由網(wǎng)景公司進行，提供了身份驗證與加密通訊方法，現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面。

限制
它的安全保護依賴瀏覽器的正確實現(xiàn)以及服務器軟件、實際加密算法的支持.

一種常見的誤解是“銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號不被偷竊�！睂嶋H上，與服務器的加密連接中能保護銀行卡號的部分，只有用戶到服務器之間的連接及服務器自身。并不能絕對確保服務器自己是安全的，這點甚至已被攻擊者利用，常見例子是模仿銀行域名的釣魚攻擊。少數(shù)罕見攻擊在網(wǎng)站傳輸客戶數(shù)據(jù)時發(fā)生，攻擊者嘗試竊聽數(shù)據(jù)于傳輸中。

商業(yè)網(wǎng)站被人們期望迅速盡早引入新的特殊處理程序到金融網(wǎng)關(guān)，僅保留傳輸碼(transaction number)。不過他們常常存儲銀行卡號在同一個數(shù)據(jù)庫里。那些數(shù)據(jù)庫和服務器少數(shù)情況有可能被未授權(quán)用戶攻擊和損害。


TLS 1.1之前
這段僅針對TLS 1.1之前的狀況。因為SSL位于http的下一層，并不能理解更高層協(xié)議，通常SSL服務器僅能頒證給特定的IP/端口組合。這是指它經(jīng)常不能在虛擬主機(基于域名)上與HTTP正常組合成HTTPS。

這一點已被更新在即將來臨的TLS 1.1中—會完全支持基于域名的虛擬主機。


SSL介紹
SSL (Secure Socket Layer)
為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡
上之傳輸過程中不會被截取及竊聽。目前一般通用之規(guī)格為40 bit之安全標準，美國則已推出128 bit之更高安全
標準，但限制出境。只要3.0版本以上之I.E.或Netscape瀏覽器即可支持SSL。
當前版本為3.0。它已被廣泛地用于Web瀏覽器與服務器之間的身份認證和加密數(shù)據(jù)傳輸。
SSL協(xié)議位于TCP/IP協(xié)議與各種應用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層： SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。
SSL協(xié)議提供的服務主要有：
1）認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器；
2）加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊��；
3）維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。
SSL協(xié)議的工作流程：
服務器認證階段：1）客戶端向服務器發(fā)送一個開始信息“Hello”以便開始一個新的會話連接；2）服務器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要則服務器在響應客戶的“Hello”信息時將包含生成主密鑰所需的信息；3）客戶根據(jù)收到的服務器響應信息，產(chǎn)生一個主密鑰，并用服務器的公開密鑰加密后傳給服務器；4）服務器恢復該主密鑰，并返回給客戶一個用主密鑰認證的信息，以此讓客戶認證服務器。
用戶認證階段：在此之前，服務器已經(jīng)通過了客戶認證，這一階段主要完成對客戶的認證。經(jīng)認證的服務器發(fā)送一個提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰，從而向服務器提供認證。
從SSL 協(xié)議所提供的服務及其工作流程可以看出，SSL協(xié)議運行的基礎(chǔ)是商家對消費者信息保密的承諾，這就有利于商家而不利于消費者。在電子商務初級階段，由于運作電子商務的企業(yè)大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務的發(fā)展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL3.0中通過數(shù)字簽名和數(shù)字證書可實現(xiàn)瀏覽器和Web服務器雙方的身份驗證，但是SSL協(xié)議仍存在一些問題，比如，只能提供交易中客戶與服務器間的雙方認證，在涉及多方的電子交易中，SSL協(xié)議并不能協(xié)調(diào)各方間的安全傳輸和信任關(guān)系。在這種情況下，Visa和 MasterCard兩大信用卡公組織制定了SET協(xié)議，為網(wǎng)上信用卡支付提供了全球性的標準。

SSL協(xié)議的握手過程 　　為了便于更好的認識和理解 SSL 協(xié)議，這里著重介紹 SSL 協(xié)議的握手協(xié)議。SSL 協(xié)議既用到了公鑰加密技術(shù)又用到了對稱加密技術(shù)，對稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公鑰加密技術(shù)提供了更好的身份認證技術(shù)。SSL 的握手協(xié)議非常有效的讓客戶和服務器之間完成相互之間的身份認證，其主要過程如下：

　　①客戶端的瀏覽器向服務器傳送客戶端 SSL 協(xié)議的版本號，加密算法的種類，產(chǎn)生的隨機數(shù)，以及其他服務器和客戶端之間通訊所需要的各種信息。

　�、诜�務器向客戶端傳送 SSL 協(xié)議的版本號，加密算法的種類，隨機數(shù)以及其他相關(guān)信息，同時服務器還將向客戶端傳送自己的證書。

　　③客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發(fā)行服務器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務器證書的“發(fā)行者的數(shù)字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續(xù)進行第四步。

　　④用戶端隨機產(chǎn)生一個用于后面通訊的“對稱密碼”，然后用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中獲得）對其加密，然后將加密后的“預主密碼”傳給服務器。

　�、萑绻�服務器要求客戶的身份認證（在握手過程中為可選），用戶可以建立一個隨機數(shù)然后對其進行數(shù)據(jù)簽名，將這個含有簽名的隨機數(shù)和客戶自己的證書以及加密過的“預主密碼”一起傳給服務器。

　�、奕绻�服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數(shù)的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發(fā)行CA 的公鑰能否正確解開客戶證書的發(fā)行 CA 的數(shù)字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，服務器將用自己的私鑰解開加密的“預主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生主通訊密碼（客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼）。

　�、叻�務器和客戶端用相同的主密碼即“通話密碼”，一個對稱密鑰用于 SSL 協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時在 SSL 通訊過程中還要完成數(shù)據(jù)通訊的完整性，防止數(shù)據(jù)通訊中的任何變化。

　�、嗫蛻舳讼蚍�務器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知服務器客戶端的握手過程結(jié)束。

　�、岱�務器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知客戶端服務器端的握手過程結(jié)束。
　�、釹SL 的握手部分結(jié)束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶和服務器開始使用相同的對稱密鑰進行數(shù)據(jù)通訊，同時進行通訊完整性的檢驗。

雙向認證 SSL 協(xié)議的具體過程

　�、� 瀏覽器發(fā)送一個連接請求給安全服務器。

　�、� 服務器將自己的證書，以及同證書相關(guān)的信息發(fā)送給客戶瀏覽器。

　　③ 客戶瀏覽器檢查服務器送過來的證書是否是由自己信賴的 CA 中心所簽發(fā)的。如果是，就繼續(xù)執(zhí)行協(xié)議；如果不是，客戶瀏覽器就給客戶一個警告消息：警告客戶這個證書不是可以信賴的，詢問客戶是否需要繼續(xù)。

　�、� 接著客戶瀏覽器比較證書里的消息，例如域名和公鑰，與服務器剛剛發(fā)送的相關(guān)消息是否一致，如果是一致的，客戶瀏覽器認可這個服務器的合法身份。

　�、� 服務器要求客戶發(fā)送客戶自己的證書。收到后，服務器驗證客戶的證書，如果沒有通過驗證，拒絕連接；如果通過驗證，服務器獲得用戶的公鑰。

　　⑥ 客戶瀏覽器告訴服務器自己所能夠支持的通訊對稱密碼方案。

　�、� 服務器從客戶發(fā)送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密后通知瀏覽器。

　�、� 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接著用服務器的公鑰加過密后發(fā)送給服務器。

　�、� 服務器接收到瀏覽器送過來的消息，用自己的私鑰解密，獲得通話密鑰。

　�、� 服務器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱密鑰是加過密的。

　　上面所述的是雙向認證 SSL 協(xié)議的具體通訊過程，這種情況要求服務器和用戶雙方都有證書。單向認證 SSL 協(xié)議不需要客戶擁有 CA 證書，具體的過程相對于上面的步驟，只需將服務器端驗證客戶證書的過程去掉，以及在協(xié)商對稱密碼方案，對稱通話密鑰時，服務器發(fā)送給客戶的是沒有加過密的（這并不影響 SSL 過程的安全性）密碼方案。 這樣，雙方具體的通訊內(nèi)容，就是加過密的數(shù)據(jù)，如果有第三方攻擊，獲得的只是加密的數(shù)據(jù)，第三方要獲得有用的信息，就需要對加密的數(shù)據(jù)進行解密，這時候的安全就依賴于密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強調(diào)要求使用 128 位加密通訊的原因。

證書各部分的含義

<FONT face=宋體>Version　　　　　　　　　證書版本號，不同版本的證書格式不同
Serial Number　　　　　　序列號，同一身份驗證機構(gòu)簽發(fā)的證書序列號唯一
Algorithm Identifier 　　簽名算法，包括必要的參數(shù) Issuer 身份驗證機構(gòu)的標識信息
Period of Validity 　　　有效期
Subject　　　　　　　　　證書持有人的標識信息
Subject’s Public Key　　證書持有人的公鑰
Signature　　　　　　　　身份驗證機構(gòu)對證書的簽名</FONT>

證書的格式　 認證中心所發(fā)放的證書均遵循 X.509 V3 標準，其基本格式如下：

證書版本號（Certificate Format Version）
含義：用來指定證書格式采用的 X.509 版本號。

證書序列號（Certificate Serial Number）
含義：用來指定證書的唯一序列號，以標識 CA 發(fā)出的所有公鑰證書。

簽名（Signature） 算法標識（Algorithm Identifier）
含義：用來指定 CA 簽發(fā)證書所用的簽名算法。

簽發(fā)此證書的 CA 名稱（Issuer ）
含義：用來指定簽發(fā)證書的 CA 的 X.500 唯一名稱（DN， Distinguished Name）。

證書有效期（Validity Period） 起始日期（notBefore） 終止日期（notAfter）
含義：用來指定證書起始日期和終止日期。

用戶名稱（Subject）
含義：用來指定證書用戶的 X.500 唯一名稱（DN，Distinguished Name）。

用戶公鑰信息（Subject Public Key Information） 算法（algorithm） 算法標識（Algorithm　Identifier） 用戶公鑰（subject　Public　Key）
含義：用來標識公鑰使用的算法，并包含公鑰本身。

證書擴充部分（擴展域）（Extensions）
含義：用來指定額外信息�！�

X.509 V3 證書的擴充部分（擴展域）及實現(xiàn)方法如下：

CA 的公鑰標識（Authority　Key　Identifier）
公鑰標識（SET 未使用）（Key　Identifier）
簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificate　Issuer）
簽發(fā)證書者證書的序列號（Certificate Serial Number）

X.509 V3 證書的擴充部分（擴展域）及實現(xiàn)CA 的公鑰標識（Authority　Key　Identifier）
公鑰標識（SET 未使用）（Key　Identifier）

簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificat簽發(fā)證書者證書的序列號（Certificate Serial Number）
含義：CA 簽名證書所用的密鑰對的唯一標識用戶的公鑰標識（Subject　Key　Identifier）　
含義：用來標識與證書中公鑰相關(guān)的特定密鑰進行解密。

證書中的公鑰用途（Key　Usage）

含義：用來指定公鑰用途。

用戶的私鑰有效期（Private　Key　Usage　Period） 起始日期（Note　Before） 終止日期（Note　After）
含義：用來指定用戶簽名私鑰的起始日期和終止日期。

CA 承認的證書政策列表（Certificate Policies）
含義：用來指定用戶證書所適用的政策，證書政策可由對象標識符表示。

用戶的代用名（Substitutional　Name）
含義：用來指定用戶的代用名。

CA 的代用名（Issuer　Alt　Name）
含義：用來指定 CA 的代用名。

基本制約（Basic　Constraints）
含義：用來表明證書用戶是最終用戶還是 CA。 在 SET 系統(tǒng)中有一些私有擴充部分（擴展域）Hashed　Root　Key 含義：只在根證書中使用，用于證書更新時進行回溯。

證書類型（Certificate　Type）
含義：用來區(qū)別不同的實體。該項是必選的。

商戶數(shù)據(jù)（Merchant　Data）
含義：包含支付網(wǎng)關(guān)需要的所有商戶信息。

持卡人證書需求（Card　Cert　Required）
含義：顯示支付網(wǎng)關(guān)是否支持與沒有證書的持卡人進行交易。

SET 擴展（SETExtensions）
含義：列出支付網(wǎng)關(guān)支持的支付命令的 SET 信息擴展。

CRL 數(shù)據(jù)定義版本（Version）
含義：顯示 CRL 的版本號。

CRL 的簽發(fā)者（Issuer）
含義：指明簽發(fā) CRL 的 CA 的甄別名。

CRL 發(fā)布時間（this　Update） 預計下一個 CRL 更新時間（Next　Update） 撤銷證書信息目錄（Revoked　Certificates） CRL 擴展（CRL　Extension） CA 的公鑰標識（Authority　Key　Identifier） CRL 號（CRL　Number）


   

• 通信詞典解釋