【正文】 息方面獲得一致 :協(xié)議版本、密碼算法、是否認證對方、用什么技術(shù)來產(chǎn)生共享秘密數(shù)據(jù)，等等。 SSL握手協(xié)議的流程 交換 Hello消息，對于算法、交換隨機值等協(xié)商一致。 交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的premaster secret， 交換證書和相應的密 碼信息，以便進行身份認證。 產(chǎn)生 master secret。 把安全參數(shù)提供給 TLS記錄層。 檢驗雙方是否已經(jīng)獲得同樣的安全參數(shù)。 握手協(xié)議使用的消息 消息 參數(shù) hello_request Null client_hello 版本，隨機數(shù)，會話 id，密碼參數(shù)，壓縮方法 server_hello certificate v3證書鏈 server_key_exchange 參數(shù)，簽名 certificate_request 類型， CAs server_done Null certificate_verify 簽名 client_key_exchange 參數(shù)，簽名 finished Hash值 第一階段：建立起安全能力屬性 客戶發(fā)送一個 client_hello消息，包括以下參數(shù)： 版本、隨機數(shù) (32位時間戳 +28字節(jié)隨機序列 )、會話 ID、客戶支持的密碼算法列表 (CipherSuite)、客戶支持的壓縮方法列表； 然后，客戶等待服務器的 server_hello消息； 服務器發(fā)送 server_hello消息，參數(shù)： 客戶建議的低版本以及服務器支持的最高版本、服務器產(chǎn)生的隨機數(shù)、會話 ID、服務器從客戶建議的密碼算法中挑出一套、服務器從客戶建議的壓縮方法中挑出一個。 關(guān)于會話 ID(Session ID) 客戶方 ? 客戶指定的會話 ID如果不等于 0，則表示它希望基于這個會話來更新已有連接的安全參數(shù)，或者創(chuàng)建一個新的連接 ? 如果會話 ID等于 0，則表示客戶希望在一個新的會話上建立一個新的連接 服務器 ? 或者同意客戶指定的會話 ID，需要檢查 cache中的會話狀態(tài) ? 或者返回一個新的會話 ID CipherSuite 第一個元素指定了密鑰交換的方法， SSL支持以下一些方法： ? RSA，要求服務器提供一個 RSA證書 ? DH(DiffieHellman)，要求服務器的證書中包含了由 CA簽名的 DH公開參數(shù)?？蛻艋蛘咴谧C書中提供 DH公開參數(shù)，或者在密鑰 交換消息中提供此參數(shù) ? EDH(Ephemeral DiffieHellman)，產(chǎn)生臨時的密鑰， DH公開參數(shù)由發(fā)送者的私鑰進行簽名，接收者用對應的公鑰進行驗證 ? 匿名的 DH，不加認證。會受到中間人攻擊 然后，指定以下信息 ? 加密算法，和類型 (流還是分組密碼算法 ) ? HMAC算法， MD5還是 SHA1 ? 是否可出口 ? HashSize ? Key Material ? IV Size 第二階段：服務器認證和密鑰交換 服務器發(fā)送自己的證書，消息包含一個 ，或者一條證書鏈 ? 除了匿名 DH之外的密鑰交換方法都需要 服務器發(fā)送 server_key_exchange消息 ? 可選的，有些情況下可以不需要。只有當服務器的證書沒有包含必需的數(shù)據(jù)的時候才發(fā)送此消息 ? 消息包含簽名，被簽名的內(nèi)容包括兩個隨機數(shù)以及服務器參數(shù) 服務器發(fā)送 certificate_request消息 ? 非匿名 server可以向客戶請求一個證書 ? 包含證書類型和 CAs 服務器發(fā)送 server_hello_done, 然后等待應答 第三階段：客戶認證和密鑰交換 客戶收到 server_done消息后，它根據(jù)需要檢查服務器提供 的證書，并判斷 server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個或多個消息給服務器 。 如果服務器請求證書的話，則客戶首先發(fā)送一個certificate消息，若客戶沒有證書，則發(fā)送一個no_certificate警告 。 然后客戶發(fā)送 client_key_exchange消息，消息的內(nèi)容取決于密鑰交換的類型 。 最后，客戶發(fā)送一個 certificate_verify消息，其中包含一個簽名，對從第一條消息以來的所有握手消息的 HMAC值(用 master_secret)進行簽名。 第四階段：結(jié)束 第四階段建立起一個安全的連接 。 客戶發(fā)送一個 change_cipher_spec消息，并且把協(xié)商得到的 CipherSuite拷貝到當前連接的狀態(tài)之中 。 然后，客戶用新的算法、密鑰參數(shù)發(fā)送一個 finished消息，這條消息可以檢查密鑰交換和認證過程是否已經(jīng)成功。其中包括一個校驗值，對所有以來的消息進行校驗 。 服務器同樣發(fā)送 change_cipher_spec消息和 finished消息。 握手過程完成，客戶和服務器可以交換應用層數(shù)據(jù)。 SET協(xié)議概 述 ? SET協(xié)議 (Secure Electronic Transaction 安全 電子 交 易 )是 由 VISA和 MasterCard兩 大信用 卡 公 司 于 1997年 5月 聯(lián)合推 出 的 規(guī) 范。 ? SET主要 是 為了解 決用戶 商家 和 銀 行 之 間通過信用 卡 支 付的交 易而設 計的以保證 支 付 信息的機密 支 付 過程的完整 商 戶及持 卡 人 的 合法身份 以 及 可操作性 SET中的 核心 技術(shù) ， 主要有 公 開密 鑰 加密、數(shù)字簽名、 電子 信 封電、子 安全證 書等。SET能在 電子 交 易 環(huán)節(jié)上提 供更 大的信 任 度， 更 完整的交 易信息， 更高 的安全性和 更 少受欺詐 的可能性。 ? SET協(xié)議 用以 支持 B to C Business to Consumer 這種類型 的 電子商 務模式，即 消 費 者持 卡 在網(wǎng)上 購物 與交 易 的模式。 SET SET實現(xiàn) 架 構(gòu) 實現(xiàn) 架 構(gòu) SET交 易 過程 ? SET 交 易 分 三個 階 段進行 : ? 在 購買 請求 階 段，用戶與 商家 確定 所用 支 付 方 式的 細 節(jié)； ? 在 支 付 確認 階 段中， 商家 會 與 銀 行 核 實 ,隨 著 交 易 的進 展他 們 將 得到 付款； ? 在 收 款階 段， 商家向 銀 行 出示 所有交 易 的 細 節(jié)，然后 銀 行以 適 當方 式 轉(zhuǎn) 移貨款。 ? 如果不是使用 借 記 卡， 而 直 接 支 付 現(xiàn) 金，商家 在 第二 階 段完成。以后的 任 何 時間即可以 供 貨 支 付。 第三 階 段將 緊 接 著第二 階 段進行，用戶 只 和 第一 階 段交 易 有關(guān)， 銀 行與 第二、三 階 段有關(guān)， 而 商家 與 三個 階 段 都要 發(fā)生關(guān)系。 每個 階 段 都涉 及到 RSA對數(shù)據(jù)加密，以 及 RSA數(shù)字簽名。 SET交 易 過程 1. 商家 收到 PIMD、 OI 、 DS 計算 H(PIMD||H(OI))和 DKUc(DS) 2. 銀 行 收到 OIMD 、 PI 、 DS 計算 H(H(PI)||OIMD)和 DKUc(DS) 3. 顧 客將 PI 、 OI鏈 在 一起，起到 簽名作用 SET交 易 過程 ? 事 實 上， SET和 SSL除了都采 用 RSA公鑰 算 法 以外， 二者在其 他 技術(shù)方 面 沒有 太 多 相 似之 處， 而 RSA在 二者 中 也被 用來 實現(xiàn) 不同的安全目 標。 ? SET協(xié)議 比 SSL協(xié)議復 雜。 因為 SET不 僅 加密 兩個 端點間的單 個會話， 它 還 非常 詳細 而準確 地 反映 了 卡 交 易 各 方之 間存在的 各 種 關(guān)系。 SET還定義了 加密信息的格式和完成 一 筆卡 支 付 交 易 過程中 各 方 傳輸信息的 規(guī)則。事 實 上， SET遠遠不止是 一個技術(shù)方 面 的 協(xié)議， 它 還說明了每一方 所 持 有的數(shù)字證 書 的 合法 含 義， 希望 得到 數(shù)字證 書 以 及 響 應信息的 各 方應有的動作，與 一 筆 交 易 緊 密 相 關(guān)的 責 任 分 擔。 ? SET實現(xiàn) 非常 復 雜。商家 和 銀 行 都需要 改造系 統(tǒng)， 以 實現(xiàn)互 操作。 另 外 SET協(xié)議需要認 證中 心 的 支持。 SSL與 SET協(xié)議 的 比較 ? SET是 一個多方 的 報 文 協(xié)議， 它 定義了銀 行 商家 持 卡 人之間的 必須 的 報 文 規(guī) 范。 與 此 同時， SSL只 是 簡 單地在 兩方之間 建立了一 條 安全連接。 SSL是 面向 連接的， 而 SET允 許 各方之 間的 報 文交 換 不是 實 時的， SET報 文能 夠 在 銀 行內(nèi)部網(wǎng)或 者 其 他 網(wǎng)絡上傳輸， 而 SSL之 上的 卡 支 付 系 統(tǒng) 只 能與 Web瀏覽器 捆綁 在 一起。 ? SSL相 對不安全。 實 際 上，當 初 它 并 不是 為支持 電子商 務而設 計的， 很 多銀 行和 電子商 務 解 決 方 案 提 供 商 仍然在使用SSL來構(gòu) 建更多 的安全 支 付 系 統(tǒng)，但 是如果沒有經(jīng) 裁剪 的客戶 方 軟件的 話，基 于 SSL的系 統(tǒng) 是不能 到 像 SET這種 專 用 銀行 卡 支 付 協(xié)議 所能 達 到 的安全性的。