XML在傳統制造業B2B供應鏈中的應用分析（五）

XML數據傳輸的安全加密第一部分

郭 路
Technical Manager
2001 年 6 月

XML語言是一種面向數據的標記規範，與HTML不同，XML標記通常總是力求準確清晰地說明數據本身的涵義，即使對於一些非常陌生的XML文件，人們也很容易理解其所要表達的內容，從這個意義上講，XML數據是完全開放的。由於在XML規範中並不提供對數據的保密措施，因此，一旦含有商業信息的XML文檔被別有用心的人直接得到，泄密幾乎是必然的。要設計一個基於XML傳遞數據的商業系統，信息安全是非常關鍵的問題，通過對B2B供應鏈的分析，我們可以發現影響系統XML數據安全保密的因素主要有以下幾點：

• 監聽網絡端口或信道，數據在傳輸的過程中被截取；
• 存在本地或網絡存儲器中的XML文件被打開閱讀；
• 通過瀏覽器等工具非法訪問B2B網站的XML數據；
• 應用層中處理XML數據的組件被非法調用或修改；
• 用戶口令泄漏或存在後門可以進入前端管理界面；
• 使用木馬或陷阱等手段，記錄並分析業務流片斷；
• 修改、捏造請求或返回信息以得到應用的控制權；
• 獲取網絡中以文件形式共享的DTD/Schema、XSL。

一般而言，在B2B供應鏈中，前臺的B2B網站由於其開放性，因此受攻擊的風險較大；而後臺的ERP/MRP管理系統可以說涵蓋了企業所有重要的事務處理，因此數據的機密級別往往會更高。基於目前的計算機開發技術所限，通常B/S結構的應用系統其安全性較C/S結構更低，這也是影響Intranet在企業內部網中普及的一個重要原因。通常在B2B供應鏈系統中傳輸處理的XML文檔多以動態的數據流形式存在，生存週期很短，必須用指定的應用程序調用而不能直接打開文件，因此，要保障系統中的XML數據安全，除了實際使用過程中加強對計算機系統的全面管理外，在開發設計時選擇好的加密機制也很重要，通常對XML數據的加密有以下幾種主要方法：

數據祕鑰加密
XML數據是基於文本文件的，因此可以使用經典的加密算法對XML數據進行加密，通常我們稱XML源數據爲明文，加密後產生的目標數據爲密文，由明文產生密文的過程稱爲加密，而由密文恢復明文的過程稱爲解密。設明文爲M，密文N，則可用如下公式表示數據的加密解密過程，其中E爲加密算法，F爲解密算法：

• E（M）＝N
• F（N）＝M

上述公式具有很大的缺陷，即任何人只要破譯瞭解密算法F，就可以由密文N算出明文M，此時爲了保障數據安全，就必須修改或替換算法E和F，而這意味着要修改系統程序，顯然是不切實際的。現代密碼學通過祕鑰解決此問題，所謂祕鑰一般是由數字或字符組成的關鍵字，並作爲加密/解密算法的參數代入，當加密算法E和明文M固定時，採用不同的加密祕鑰K將得到不同的密文N，而此時由密文N恢復出明文M同樣需要一個解密祕鑰K解，根據加密/解密算法的不同，K解可以與加密祕鑰K相同或不同，修改後的加密/解密公式表示如下：

E（M，K）＝N         //K爲隨機產生的關鍵字
F（N，K解）＝M       //K解等於K或與K匹配

一般我們稱K解等於K的祕鑰算法爲對稱算法或單鑰算法，此時當有數據在不同計算機間交互時，發送方首先用祕鑰K將明文加密，然後傳輸至接收方，並由接收方採用同樣的祕鑰解密得到明文。這種方法的一個難題在於，如何使接收方安全地得到發送方隨機產生的祕鑰K，解決的辦法有好多種，這裏僅介紹其中最簡單的兩種，實際設計中可根據系統的要求靈活應變，有關更復雜嚴密的方法也可參看Kerberos、DASS等安全標準：

• 點對點祕鑰安全：爲不同計算機上的應用A與B建立一初始通信祕鑰K1，此祕鑰可手工輸入或編程時設定，並且未被使用過加密數據，因此認爲是安全的。當A、B兩方要通信時，發送方產生隨機祕鑰K2，並用K1將K2和XML數據加密，傳輸至接收方，接收方收到信息，用K1解密後，銷燬K1，保存K2，並通知發送方接收成功，發送方得到響應後銷燬K1，保存K2，否則重發數據，K2爲下一次雙方通信的加密祕鑰；
• 通過可信第三方的安全服務：在網絡中建立祕鑰數據庫C（即安全服務器），每個在C註冊的應用都有一個不同的用戶祕鑰，該祕鑰僅用於應用與數據庫C間的通信，由數據庫C產生髮給應用，一般是定期更換，可以認爲是安全的。當A和B通信時，發送方首先將事件告知數據庫C，由C產生隨機祕鑰K，並將K用A、B各自的用戶祕鑰Ka與Kb加密後交給A、B，然後雙方便可用解密後得到祕鑰K對XML數據進行加密/解密。

DES是最流行的對稱祕鑰算法，該算法在七十年代由IBM的密碼學專家發明，經過NSA（美國國家安全局）的評估與修改，先後被NIST、ISO等權威機構作爲工業標準發佈，可以免費用於商業應用。DES採用分組密碼技術，即將明文分爲長度爲64bit的單元組，然後用一個隨機產生的56bit數字祕鑰對每一組進行加密，並輸出長度爲64bit的密文，其基本加密步驟如下所示：

1. 對64bit的明文單元組進行初始置換IP，如將第1位換到第50位，第50位換到第28位，第28位換到第3位……，並建立置換記錄表S，然後將置換結果分爲32bit的左右兩部分R和L；
2. 祕鑰置換，將56bit的祕鑰分爲28bit的左右兩部分，每部分分別循環左移1或2位，然後從移動後產生的56位祕鑰中選出48位作爲壓縮祕鑰K縮；
3. 擴展置換，將單元組右半部分R切分爲每4位一小組輸入，經過E-盒運算，得到6位的輸出結果，即將32bit的R擴展爲48位的R擴；
4. S-盒代替，將R擴與壓縮祕鑰K縮作異或運算得到48bit的輸入數據Ri，將Rs輸入指定的8個S-盒，經過替換得到一個32位（8個4位分組）的輸出Ro；
5. P-盒置換，對Ro進行動態的P-盒置換，並將置換結果（32bit數據）與單元組左半部分L異或得到新的右半部分R_，然後將左、右半部分L與R_交換；
6. 重複步驟2～5，使該組合操作共循環16輪；
7. 將單元組的左、右半部分交換後合併，並進行與初始置換IP相逆的末置換IP－1，即得到該單元組的最終加密結果。

DES的解密算法與加密算法基本一致，差別在於壓縮祕鑰K縮的產生不同，二者順序正好相反，設加密過程中16輪加密的壓縮祕鑰依次爲K1，K2，K3……K16，則解密過程中的壓縮祕鑰便爲K16……K3,K2,K1。DES的算法複雜難懂，但卻很容易通過計算機實現，本文在此給出DES算法的C源程序，對DES算法有興趣的人可參看Bruce Schneier所著的《Applied Cryptography Protocols，algorithms，and source code in C》一書。

有關DES的爭論主要集中在其安全性上，儘管一直沒有確實的證據，仍有許多密碼學家對DES的可靠性表示擔心，其原因主要有二：

• DES採用56位祕鑰與固定的S-盒，而這都是由NSA制定的，並且沒有給出這樣做的理由，人們擔心NSA會在算法中嵌入後門，這樣便可以用簡單的方法對數據解密；
• DES是受分析與攻擊最多的祕鑰算法，隨着差分分析技術與線性分析技術的公開，使得大型DES破譯機的製造成本與破譯時間大大降低。

爲了提高DES算法的強度，人們提出了基於加密分組的鏈接模式（如CBC、OFB、CFB等）及DES的各種變型技術，如多重DES和更換S-盒等，其中有些已被證實了具有強化作用（如三重DES），而大多數還缺少數學上的驗證支持。

除了DES外，目前較爲流行的對稱祕鑰算法還有IDEA、FEAL、LOKI、Lucifer、RC2、RC4、RC5、Blowfish、GOST、CAST、SAFER、SEAL等，這些算法大多隻具有美國專利（這意味着你至少可以在國內免費使用），有關它們的算法介紹與源程序代碼在互聯網新聞組上都可得到。

與對稱祕鑰算法相對應的是公開祕鑰算法（又稱雙鑰加密或不對稱加密），該算法要求祕鑰成對出現，即K解<>K並且不能實現由K->K解或K解->K的直接推導。通常祕鑰K作爲公開祕鑰在網絡中發佈，任何人都可以此祕鑰爲加密祕鑰加密數據併發給接收方，而接收方用另一個匹配的祕鑰K解（私人祕鑰）作爲解密祕鑰將數據解密，公開祕鑰算法的最大優點就在於它不存在祕鑰傳送所帶來的泄密問題，因爲其公開祕鑰本來就可以隨意獲得。

RSA是目前應用最爲廣泛的公開祕鑰算法，也是最容易理解和實現的公開祕鑰算法，它是1977年由R.Rivest、A.Shamir和L.Adleman三人提出的。其基本算法如下：

1. 選擇兩個大素數p 和q（通常爲100到200位的十進制數）， 計算：n = p * q；
2. 隨機選擇加密祕鑰e，要求 e 和 ( p - 1 ) * ( q - 1 ) 互質；
3. 利用 Euclid 算法計算解密祕鑰d,滿足e * d = 1 ( mod ( p - 1 ) * ( q - 1 ) )其中n和d也要互質；
4. 數e和 n是公鑰，d是私鑰。兩個素數p和q不再需要，應該丟棄，不要讓任何人知道；
5. 加密信息 m（二進制表示）時，首先把m分成等長數據塊 m1 ,m2,...,mi （採用二進制數），塊長s ，其中 2^s <= n,s
6. 儘可能的大（s爲小於n的2的最大次冪）；
7. 加密公式：ci = mi^e ( mod n )
8. 解密公式：mi = ci^d ( mod n ) （其中ci爲密文分組，mi爲明文分組）

RSA算法的安全性完全依賴於分解大數的難度（即得到兩個大素數p、q相乘結果很容易，但要由此結果分解得到大素數p、q卻非常困難，這也是目前絕大多數公開祕鑰算法設計的基本思路），需要指出的是，就純技術的角度而言，這種邏輯是並不合理的，因爲事實上它所基於的僅僅是一種猜測（類似於歌德巴赫猜想），目前在數學上還從未有人能證明過必須先要分解n才能從c和e中計算出m，如果有一天有人能夠找到比窮舉法有效得多的因式分解法或RSA中的後門，那麼，所有用RSA加密的機密數據就有可能被一覽無遺。

RSA公開祕鑰算法的主要缺點在於1）加密/解密速度太慢，一般而言，與DES相比較，RSA的軟件實現要慢一百倍，硬件實現要慢一千倍；2)處理數據量小，最多隻能有其祕鑰的模數大小，如一個1024的RSA公共祕鑰最多隻能加密1013位數據（多出11位長度要用於編碼）。

事實上，在B2B供應鏈中，我們並不直接使用RSA加密業務數據，而是將它與DES等對稱祕鑰算法混合使用，即先用DES對稱祕鑰加密業務數據，然後用RSA公鑰加密DES祕鑰，並將加密後的業務數據與對稱祕鑰一起發給RSA私鑰持有者（即業務數據的接收端）。這樣，既避免了對稱祕鑰傳遞時的安全性問題，又消除了RSA算法速度太慢的缺點。

對於XML格式的數據，祕鑰加密不僅可用於全文加密，也可用於元素級的加密，這在實際應用中有着非常廣泛的意義。它不僅使數據加密可以精確到子元素，而且可以在一個文檔中無縫結合加密與未加密數據。以下是一張用XML描述的藥材模擬報價單：

<?xml version="1.0"  encoding="UTF-8"?>
<Price Sheet>
<addresser name="浙江思能" ></addresser>
<addressee name＝"杭州胡慶餘堂藥業"><Price><鐵皮石斛>
<EncryptedElement algorithm="DES/CBC" contentType="text/xml" encoding="base64">
vJqNpDrQT1vmCVbyGJfIwdIDBYoGXGmutgz6TVGoPuKVG7IxNEN50iKw8pmtxFixz5hOChOXgTtPqk
tQhEHO5+vLOLAFgIioDIRQGHHmHng3CLd+8tvrT8wxPBCRSMUpx4d2TGXW2tqSepam0ZxdmwUXwNSAg
aR8hmiromD+bh+tDomPv7eFZ4no5ft3JG3t0trLlwVupF/5vaIJimUSmuUkkgyG8x9AcS/kXJxHpm
M=peqGzIMf+8Aa</EncryptedElement>
<ValidTime>2001-1-1至2001-2-1</ValidTime></鐵皮石斛></Price></addressee>
<addressee name=" 哈爾濱製藥六廠">
...... ..... ......
...... ..... ......
</Price Sheet>

在這份報價單中，藥材價格是非公開的，因此原料商可以根據市場需求、生產成本、產量等因素定好藥材價格後，先產生一張原始的報價單，然後將其中的價格部分加密（本例中所使用的算法是DES/CBC），並交給代理（可以是一計算機消息隊列），代理根據單據上的不同收件人（addressee）將對應的報價部分提取轉發，整個過程中代理始終不曾知道藥材的報價。顯然，本例中若採用全文加密會麻煩的多（需要爲每個製藥商建立一張報價單，並在文件外部指定收件人）。

通信協議加密
XML是完全面向數據的，因此可以和任何通訊協議相結合，通常我們在XML數據傳遞的網絡編程中使用較多的有TCP/IP、IPX/SPX（通常用於後臺內部網）、Socket、HTTP、SOAP、XML-RPC、CORBA（IIOP）等協議。由於在B2B供應鏈中，XML數據主要以異地的輸入輸出流形式存在（包括表單等業務信息與RPC調用命令，而很少有永久性質的本地XML物理文檔存在），因此，我們可以使用面向通訊安全的網絡安全協議來實現XML數據傳輸的安全性。

通常，實現通信協議的加密有如下兩種方式：

1. 手工加密數據傳輸包，即以人工的方式將通信協議包中的數據分組進行加密，這種方式從實際編程上與單純的數據加密沒有什麼不同，不過有兩點需要注意：
   • 對分組數據進行加密後，通常數據的長度與校驗值都會改變，因此要記得修改分組頭中相應的字段定義部分；
   • 單個分組數據加密後也必須由單個分組打包發送，尤其是在某些無連接的通訊協議如IP、UDP、IPX中，不至於由一個包丟失引起整個分組數據的無效。
   
   採用手工加密XML數據傳輸包時基於實際通信協議的不同，可以選擇使用不同的加密策略。比如當採用Socket（傳輸層）編程時，我們需要建立一個進程之間的安全通道，實現端對端的安全通信，此時所有經過此通道的數據都將被加密。而當採用HTTP、SOAP等應用層協議時，我們就可以選擇採用端對端加密還是應用級加密，比如使用SOAP協議傳輸XML文檔時，我們就可以實現對某個指定元素的加密。這是由於應用層協議通常都可以理解所傳送文檔的內部結構，而傳輸層協議則沒有這種能力。
2. 使用安全網絡協議，所謂網絡安全協議是基於某一層網絡協議之上或對應於某種網絡協議的安全保密規範。即使用對稱祕鑰加密、公開祕鑰加密、數字簽名、CA證書等方法，按照指定的步驟，通過建立安全連接的方法，達到保證網絡數據安全傳輸的目的。

目前在電子商務領域較爲流行的網絡安全協議有SSL、SET、PCT、TLSP、S－HTTP、IPSec、PPTP、S/MIME、PGP 、MOSS、PEM等。其中S－HTTP是HTTP的安全增強版本，由CommerceNet公司於1994年制定，S-HTTP提供了基於HTTP框架的數據安全規範以及完整的客戶機/服務器認證機制。S/MIME、MOSS、PEM、PGP是電子郵件的安全傳輸標準，PEM是由IRTF安全研究小組設計的郵件保密與增強規範，它的實現基於PKI公鑰基礎結構並遵循X.509認證協議，PEM提供了數據加密、鑑別、消息完整性及祕鑰管理等功能，目前基於PEM的具體實現有TIS/PEM、RIPEM、MSP等多種軟件模型。S/MIME是由RSA公司於1995年提出電子郵件安全協議，與較爲傳統的PEM不同，由於其內部採用了MIME的消息格式，因此不僅能發送文本，還可以攜帶各種附加文檔，如包含國際字符集、HTML、音頻、語音郵件、圖象、多媒體等不同類型的數據內容，目前大多數電子郵件產品都包含了對S/MIME的內部支持。PGP是由美國人Phil Zimmermann開發的一個免費電子郵件（也可用於一般文件）加密工具包。PGP缺省採用IDEA進行數據加密，RSA（祕鑰長度最大爲2047位）進行祕鑰管理與數字簽名，PKZIP作爲數據預壓縮算法，MD5作爲單向散列算法。PGP符合PEM的絕大多數規範, 但不要求必須遵循PKI基礎結構，而是採用了分佈式的信任模型，即每個用戶都可維護一個公鑰環，PGP與S/MIME是目前最爲流行的兩個電子郵件安全協議。PPTP是微軟制定的用於建立虛擬專用網絡（VPN）的連接協議，PPTP允許客戶機以撥號方式建立虛擬通道訪問Internet上的異構網絡（如IPX或NetBEUI）。PPTP的底層傳輸協議必須爲IP，它採用了RAS公司的RC4作爲數據加密方法，保證了在PPTP客戶端與服務器之間的安全通信。IPSec是由IETF安全小組制定的面向TCP/IP網絡安全的協議集，主要包括兩個安全協議AH（驗證頭）和ESP（封裝安全載荷），以及密鑰管理協議IKE。其中AH提供無連接的完整性、數據發起驗證和重放保護；ESP除了AH的全部功能外還可另外提供數據流加密；密鑰管理協議IKE則負責提供共享的安全參數和密鑰協商。這些協議均獨立於算法，這種模塊化的設計允許只改變不同的算法而不影響實現的其它部分。SET是由Visa與MasterCard公司共同開發的用於互聯網安全信用卡數據傳輸的協議套件，它主要提供客戶、商家和銀行之間的認證，並確保交易數據的安全性、完整可靠性和交易的不可否認性，特別是保證不將客戶銀行卡號暴露給商家。SET採用公鑰密碼體制和X.509數字證書標準，屬於典型的PKI應用，由於其嚴密卓越的安全特性，SET已成爲目前公認的網上交易國際安全標準。不過由於目前在國內的電子商務領域中尤其是B2B市場中，還很少使用網上支付的交易方式，因此SET的實際應用非常有限。SSL是由Netscape制定的互聯網安全通信協議，目前的版本爲SSL 3.0，使用SSL可以建立一條點對點的安全信道用於實時的數據交互。PCT協議是微軟制定的SSL2改進版本，據微軟稱其安全性能要遠遠高於SSL2，二者格式上的主要差別在於它們版本號字段的最顯著位(The Most Significant Bit)取值有所不同: SSL該位取0，PCT該位取1。TLSP是基於TCP/IP的傳輸層安全協議，提供了類似於SSL3的安全性能 由ITEF的TLS安全技術小組制定，並作爲安全標準草案向IESG正式提交。

SSL是目前電子商務中應用最爲廣泛的安全協議，其實現模式非常適合編程開發。由於SSL提供傳輸層的通信加密而與應用層協議獨立無關，因此各種高層的應用層協議(如HTTP、FTP、TELNET、SOAP、WDDX等)能透明的建立於SSL協議之上。SSL協議在應用層協議通信之前就已經完成加密算法、通信密鑰的協商以及服務器認證工作，在此之後應用層協議所傳送的所有數據都會被加密，從而保證通信的安全性。如前面所述，由於目前國內B2B市場還很少使用網上支付，因此安全性很高的SET協議幾乎不太可能用到，而SSL由於其使用範圍廣（可結合大多數互聯網通信協議），所需費用少（可以到網上免費下載基於各種操作系統平臺、各種編程語言的工具包），實現方便（比如和IPSec相比較）、安全性高（經過多年實踐檢驗），所以已成爲一般網絡數據安全通信的首選方案。本文將在下面對SSL的實現作簡要介紹：

SSL協議包括SSL記錄協議和SSL握手協議兩部分，前者指定傳輸數據的具體格式。後者則負責在支持SSL的客戶端和服務器端之間建立安全傳輸通道，並實現：

• 在客戶端驗證服務器；
• 允許客戶端和服務器選擇雙方都支持的加密算法；
• 在服務器端驗證客戶（可選）；
• 用公鑰加密算法產生"共享安全信息"；
• 建立加密SSL連接。

在SSL協議中，所有的傳輸數據都被封裝在記錄中。記錄是由記錄頭和長度不爲0的記錄數據組成的。所有的SSL通信包括握手消息、安全空白記錄和應用數據都使用SSL記錄層。SSL記錄協議包括了記錄頭和記錄數據格式的規定。SSL的記錄頭可以是兩個或三個字節長的編碼。SSL記錄頭的包含的信息包括：記錄頭的長度、記錄數據的長度、記錄數據中是否有粘貼數據。其中粘貼數據是在使用塊加密算法時，填充實際數據，使其長度恰好是塊的整數倍。最高位爲1時，不含有粘貼數據，記錄頭的長度爲兩個字節，記錄數據的最大長度爲32767個字節；最高位爲0時，含有粘貼數據，記錄頭的長度爲三個字節，記錄數據的最大長度爲16383個字節。

SSL協議同時使用對稱密鑰算法和公鑰加密算法。前者在速度上比後者要快很多，但是後者可以實現更好的安全驗證。一個SSL傳輸過程首先需要握手：用公鑰加密算法使服務器端在客戶端得到驗證，以後就可以使雙方用商議成功的對稱密鑰來更快速的加密、解密數據。其基本過程描述如下：

1. 客戶端向服務器端發送客戶端SSL版本號、加密算法設置、隨機產生的數據和其他服務器需要用於根客戶端通訊的數據；
2. 服務器向客戶端發送服務器的SSL版本號、加密算法設置、隨機產生的數據和其他客戶端需要用於根服務器通訊的數據。另外，服務器還要發送自己的證書，如果客戶端正在請求需要認證的信息，那麼服務器同時也要請求獲得客戶端的證書；
3. 客戶端用服務器發送的信息驗證服務器身份，如果認證不成功，用戶就將得到一個警告，然後加密數據連接將無法建立；如果成功，則繼續下一步；
4. 用戶用握手過程至今產生的所有數據，創建連接所用的"關鍵安全信息"，用服務器的公鑰加密（在第二步中傳送的服務器證書中得到），傳送給服務器；
5. 如果服務器也請求客戶端驗證，那麼客戶端將對另外一份不同於上次用於建立加密連接使用的數據進行簽名。在這種情況下，客戶端會把這次產生的加密數據和自己的證書同時傳送給服務器；
6. 如果服務器也請求客戶端驗證，服務器將試圖驗證客戶端身份。如果客戶端不能獲得認證，連接將被中止；如果被成功認證，服務器用自己的私鑰解密"關鍵安全信息"並分解（其中包含產生祕鑰的參數條件）；
7. 服務器和客戶端同時產生會話祕鑰K，之後所有數據傳輸都用基於祕鑰K的對稱密鑰算法來交流數據；
8. 客戶端向服務器發送信息說明以後的所有信息都將用會話祕鑰K加密。至此，它會傳送一個單獨的信息標示客戶端的握手部分已經宣告結束；
9. 服務器也向客戶端發送信息說明以後的所有信息都將用會話祕鑰K加密。至此，它會傳送一個單獨的信息標示服務器端的握手部分已經宣告結束；
10. SSL握手過程成功結束，一個SSL數據傳送過程建立。客戶端和服務器開始用會話祕鑰K加密、解密雙方交互的所有數據。

一個SSL傳輸過程大致如此，但是還有很重要的一點不能忽略--即利用證書在客戶端和服務器端進行身份驗證。一個支持SSL的客戶端軟件通過下列步驟認證服務器的身份：

1. 服務器端傳送的證書中獲得相關信息（在SSL中有函數支持，在程序中有相關例子）；
2. 當天的時間是否在證書的合法期限內；
3. 簽發證書的機關是否客戶端信任的；
4. 簽發證書的公鑰是否符合簽發者的數字簽名；
5. 證書中的服務器域名是否符合服務器自己真正的域名；
6. 服務器被驗證成功，客戶繼續進行握手過程。

一個支持SSL的服務器通過下列步驟認證客戶端的身份：

1. 1. 客戶端傳送的證書中獲得相關信息；
2. 2. 用戶的公鑰是否符合用戶的數字簽名；
3. 3. 當天的時間是否在證書的合法期限內；
4. 4. 簽發證書的機關是否服務器信任的；
5. 5. 簽發證書的機關是否服務器端信任的；
6. 6. 用戶的證書是否被列在服務器的LDAP裏用戶的信息中；
7. 7. 得到驗證的用戶是否仍然又權限訪問請求的服務器資源；

目前IANA（Internet號碼分配當局）已經爲具備SSL功能的應用分配了固定端口號，例如，帶SSL的 HTTP(https)被分配的端口號爲443，帶SSL的SMTP(ssmtp)被分配的端口號爲465，帶SSL的NNTP(snntp)被分配的端口號爲563。有關面向不同操作系統與編程語言的SSL免費開發工具包及技術資料可到 http://www.openssl.org上獲得。

關於作者
郭路，杭州大學計算機系92屆本科應用專業，曾先後就職於浙江省紡織經貿總公司計算機中心、思能軟件、華企、飛時達等軟件公司，擔任技術主管，主要從事於企業 MIS、GIS、ERP 及電子商務項目的開發管理和系統分析，對 IBM、微軟、SUN、Autodesk 等公司的企業級產品有較深的研究及理解。
mailto:[email protected]