標籤：發放 有用 顯示 period 版本號碼 socket for 公司 響應
from:http://hi.baidu.com/zkheartboy/blog/item/02cc5a0878454f920b7b827c.html
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容請看SSL。
它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP資料轉送。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的預設連接埠及一個加密/身分識別驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身分識別驗證與加密通訊方法，現在它被廣泛用於全球資訊網上安全敏感的通訊，例如交易支付方面。
它是由Netscape開發並內建於其瀏覽器中，用於對資料進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全通訊端層（SSL）作為
HTTP應用程式層的子層。（HTTPS使用連接埠443，而不是象HTTP那樣使用連接埠80來和TCP/IP進行通訊。）SSL使用40 位關鍵字作為RC4流密碼編譯演算法，這對於商業資訊的加密是合適的。HTTPS和SSL支援使用X.509數字認證，如果需要的話使用者可以確認寄件者是誰。
也就是說它的主要作用可以分為兩種：一種是建立一個資訊安全通道，來保證資料轉送的安全；另一種就是確認網站的真實性。
限制
它的安全保護依賴瀏覽器的正確實現以及伺服器軟體、實際密碼編譯演算法的支援。一種常見的誤解是”銀行使用者線上使用https: 就能充分徹底保障他們的銀行卡號不被偷竊。”實際上，與伺服器的加密串連中能保護銀行卡號的部分，只有使用者到伺服器之間的串連及伺服器自身，並不能絕對確 保伺服器自己是安全的，這點甚至已被攻擊者利用，常見例子是模仿銀行網域名稱的釣魚攻擊。少數罕見攻擊在網站傳輸客戶資料時發生，攻擊者嘗試竊聽資料於傳輸 中。
商業網站被人們期望迅速儘早引入新的特殊處理常式到金融網關，僅保留傳輸碼(transaction number)。不過他們常常儲存銀行卡號在同一個資料庫裡。那些資料庫和伺服器少數情況有可能被未授權使用者攻擊和損害。
TLS 1.1之前
針對TLS 1.1之前的狀況。因為SSL位於http的下一層，並不能理解更高層協議，通常SSL伺服器僅能頒證給特定的IP/連接埠組合。這是指它經常不能在虛擬機器主機(基於網域名稱)上與HTTP正常組合成HTTPS。這一點已被更新在即將來臨的TLS 1.1中—會完全支援基於網域名稱的虛擬機器主機。
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記錄協議之上，用於在實際的資料轉送開始前，通訊雙方進行身份認證、協商密碼編譯演算法、交換加密金鑰等。
SSL協議提供的服務主要有：
1）認證使用者和伺服器，確保資料發送到正確的客戶機和伺服器；
2）加密資料以防止資料中途被竊取；
3）維護資料的完整性，確保資料在傳輸過程中不被改變。
SSL協議的工作流程：
伺服器認證階段：1）用戶端向伺服器發送一個開始資訊“Hello”以便開始一個新的會話串連；2）伺服器根據客戶的資訊確定是否需要產生新的主要金鑰， 如需要則伺服器在響應客戶的“Hello”資訊時將包含產生主要金鑰所需的資訊；3）客戶根據收到的伺服器響應資訊，產生一個主要金鑰，並用伺服器的公開密鑰 加密後傳給伺服器；4）伺服器恢複該主要金鑰，並返回給客戶一個用主要金鑰認證的資訊，以此讓客戶證明伺服器。
使用者認證階段：在此之前，伺服器已經通過了客戶認證，這一階段主要完成對客戶的認證。經認證的伺服器發送一個提問給客戶，客戶則返回（數字）簽名後的提問和其公開密鑰，從而向伺服器提供認證。
從SSL 協議所提供的服務及其工作流程可以看出，SSL協議啟動並執行基礎是商家對消費者資訊保密的承諾，這就有利於商家而不利於消費者。在電子商務初級階段，由於運 作電子商務的企業大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務的發展，各中小型公司也參與進來，這樣在電子支付過程中的單一認 證問題就越來越突出。雖然在SSL3.0中通過數位簽章和數位憑證可實現瀏覽器和Web伺服器雙方的身分識別驗證，但是SSL協議仍存在一些問題，比如，只能 提供交易中客戶與伺服器間的雙方認證，在涉及多方的電子交易中，SSL協議並不能協調各方間的安全傳輸和信任關係。在這種情況下，Visa和 MasterCard兩大信用卡公組織制定了SET協議，為網上信用卡支付提供了全球性的標準。
SSL協議的握手過程 為了便於更好的認識和理解 SSL 協議，這裡著重介紹 SSL 協議的握手協議。SSL 協議既用到了公開金鑰加密技術又用到了對稱式加密技術，對稱式加密技術雖然比公開金鑰加密技術的速度快，可是公開金鑰加密技術提供了更好的身份認證技術。SSL 的握手協議非常有效讓客戶和伺服器之間完成相互之間的身份認證，其主要過程如下：
①用戶端的瀏覽器向伺服器傳送用戶端 SSL 協議的版本號碼，密碼編譯演算法的種類，產生的隨機數，以及其他伺服器和用戶端之間通訊所需要的各種資訊。
②伺服器向用戶端傳送 SSL 協議的版本號碼，密碼編譯演算法的種類，隨機數以及其他相關資訊，
同時伺服器還將向用戶端傳送自己的認證。
③客戶利用伺服器傳過來的資訊驗證伺服器的合法性，
伺服器的合法性包括：認證是否到期，發行伺服器憑證的 CA 是否可靠，發行者認證的公開金鑰能否正確解開伺服器憑證的“發行者的數位簽章”，伺服器憑證上的網域名稱是否和伺服器的實際網域名稱相匹配。如果合法性驗證沒有通過， 通訊將斷開；如果合法性驗證通過，將繼續進行第四步。
④使用者端隨機產生一個用於後面通訊的“對稱密碼”，然後用伺服器的公開金鑰（伺服器的公開金鑰從步驟②中的伺服器的認證中獲得）對其加密，然後將加密後的“預主密碼”傳給伺服器。
⑤如果伺服器要求客戶的身份認證（在握手過程中為可選），使用者可以建立一個隨機數然後對其進行資料簽名，將這個含有簽名的隨機數和客戶自己的認證以及加密過的“預主密碼”一起傳給伺服器。
⑥如果伺服器要求客戶的身份認證，伺服器必須檢驗客戶認證和簽名隨機數的合法性，
具體的合法性驗證過程包括：客戶的認證使用日期是否有效，為客戶提供證 書的CA 是否可靠，發行CA 的公開金鑰能否正確解開客戶認證的發行 CA 的數位簽章，檢查客戶的認證是否在認證廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，伺服器將用自己的私密金鑰解開加密的“預主密碼 ”，然後執行一系列步驟來產生主通訊密碼（用戶端也將通過同樣的方法產生相同的主通訊密碼）。
⑦伺服器和用戶端用相同的主密碼即“通話密碼”，一個對稱金鑰用於 SSL 協議的安全資料通訊的加解密通訊。同時在 SSL 通訊過程中還要完成資料通訊的完整性，防止資料通訊中的任何變化。
⑧用戶端向伺服器端發出資訊，指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知伺服器用戶端的握手過程結束。
⑨伺服器向用戶端發出資訊，指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知用戶端伺服器端的握手過程結束。
⑩SSL 的握手部分結束，SSL 安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時進行通訊完整性的檢驗。
雙向認證 SSL 協議的具體過程
① 瀏覽器發送一個串連請求給安全伺服器。
② 伺服器將自己的認證，以及同認證相關的資訊發送給客戶瀏覽器。
③ 客戶瀏覽器檢查伺服器送過來的認證是否是由自己信賴的 CA 中心所簽發的。如果是，就繼續執行協議；如果不是，客戶瀏覽器就給客戶一個警告訊息：警告客戶這個認證不是可以信賴的，詢問客戶是否需要繼續。
④ 接著客戶瀏覽器比較認證裡的訊息，例如網域名稱和公開金鑰，與伺服器剛剛發送的相關訊息是否一致，如果是一致的，客戶瀏覽器認可這個伺服器的合法身份。
⑤ 伺服器要求客戶發送客戶自己的認證。收到後，伺服器驗證客戶的認證，如果沒有通過驗證，拒絕串連；如果通過驗證，伺服器獲得使用者的公開金鑰。
⑥ 客戶瀏覽器告訴伺服器自己所能夠支援的通訊對稱密碼方案。
⑦ 伺服器從客戶發送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公開金鑰加過密後通知瀏覽器。
⑧ 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接著用伺服器的公開金鑰加過密後發送給伺服器。
⑨ 伺服器接收到瀏覽器送過來的訊息，用自己的私密金鑰解密，獲得通話密鑰。
⑩ 伺服器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱金鑰是加過密的。
上面所述的是雙向認證 SSL 協議的具體通訊過程，這種情況要求伺服器和使用者雙方都有認證。單向認證 SSL 協議不需要客戶擁有 CA 憑證，具體的過程相對於上面的步驟，只需將伺服器端驗證客戶認證的過程去掉，以及在協商對稱密碼方案，對稱通話密鑰時，伺服器發送給客戶的是沒有加過密的 （這並不影響 SSL 過程的安全性）密碼方案。 這樣，雙方具體的通訊內容，就是加過密的資料，如果有第三方攻擊，獲得的只是加密的資料，第三方要獲得有用的資訊，就需要對加密的資料進行解密，這時候的 安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強調要求使用 128 位加密通訊的原因。
認證各部分的含義
Version 認證版本號碼， 不同版本的認證格式不同 Serial Number 序號， 同一身分識別驗證機構簽發的認證序號唯一
Algorithm Identifier 簽名演算法， 包括必要的參數 Issuer 身分識別驗證機構的標識資訊
Period of Validity 有效期間
Subject 認證持有人的標識資訊
Subject’s Public Key 認證持有人的公開金鑰
Signature 身分識別驗證機構對認證的簽名</FONT>
認證的格式 認證中心所發放的認證均遵循 X.509 V3 標準，其基本格式如下：
認證版本號碼（Certificate Format Version）
含義：用來指定認證格式採用的 X.509 版本號碼。
認證序號（Certificate Serial Number）
含義：用來指定認證的唯一序號，以標識 CA 發出的所有密鑰憑證。
簽名（Signature） 演算法標識（Algorithm Identifier）
含義：用來指定 CA 簽發認證所用的簽名演算法。
簽發此認證的 CA 名稱（Issuer ）
含義：用來指定簽發認證的 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 認證的擴充部分（擴充域）及實現方法如下：
CA 的公開金鑰標識（Authority Key Identifier）
公開金鑰標識（SET 未使用）（Key Identifier）
簽發認證者認證的簽發者的甄別名（Certificate Issuer）
簽發認證者認證的序號（Certificate Serial Number）
X.509 V3 認證的擴充部分（擴充域）及實現CA 的公開金鑰標識（Authority Key Identifier）
公開金鑰標識（SET 未使用）（Key Identifier）
簽發認證者認證的簽發者的甄別名（Certificat簽發認證者認證的序號（Certificate Serial Number）
含義：CA 簽署憑證所用的金鑰組的唯一標識使用者的公開金鑰標識（Subject Key Identifier）
含義：用來標識與認證中公開金鑰相關的特定密鑰進行解密。
認證中的公開金鑰用途（Key Usage）
含義：用來指定公開金鑰用途。
使用者的私密金鑰有效期間（Private Key Usage Period） 起始日期（Note Before） 終止日期（Note After）
含義：用來指定使用者簽名私密金鑰的起始日期和終止日期。
CA 承認的認證政策列表（Certificate Policies）
含義：用來指定使用者認證所適用的政策，認證政策可由物件識別碼表示。
使用者的代用名（Substitutional Name）
含義：用來指定使用者的代用名。
CA 的代用名（Issuer Alt Name）
含義：用來指定 CA 的代用名。
基本制約（Basic Constraints）
含義：用來表明認證使用者是終端使用者還是 CA。 在 SET 系統中有一些私人擴充部分（擴充域）Hashed Root Key 含義：只在根憑證中使用，用於認證更新時進行回溯。
認證類型（Certificate Type）
含義：用來區別不同的實體。該項是必選的。
商戶資料（Merchant Data）
含義：包含支付網關需要的所有商戶資訊。
持卡人認證需求（Card Cert Required）
含義：顯示支付網關是否支援與沒有認證的持卡人進行交易。
SET 擴充（SETExtensions）
含義：列出支付網關支援的支付命令的 SET 資訊擴充。
CRL 資料定義版本（Version）
含義：顯示 CRL 的版本號碼。
CRL 的簽發者（Issuer）
含義：指明簽發 CRL 的 CA 的甄別名。
CRL 發布時間（this Update） 預計下一個 CRL 更新時間（Next Update） 撤銷認證資訊目錄（Revoked Certificates） CRL 擴充（CRL Extension） CA 的公開金鑰標識（Authority Key Identifier） CRL 號（CRL Number）
HTTPS原理詳解
