前言

目前使用SSL的普及率相當高，（如果你在互聯網上訪問某些網站時在瀏覽器窗口的下方有一個鎖的小圖標，就表示它表示該網頁被SSL保護著。但用 SSL 防護的網站真的能夠防范黑客嗎? 現在國內有很多人對SSL存在這么一個認識誤區：SSL很安全，受到 SSL 防護網頁服務器的資料就一定是萬無一失的，這也導致這樣一個局面，只要有著 SSL 防護的網站服務器很少接受審查以及監測。其實不然，對于安全要求不甚高的交易或認證，SSL還是一個相當不錯的安全機制，然而若應用在特殊要求方面，它還存在有這樣那樣的問題。在下面的文中我將為大家簡單介紹到底SSL存在的安全漏洞及解決方案，希望本文對你有所幫助。

一、認識SSL

一般人認為SSL是保護主機或者只是一個應用程序，這是一個誤解，SSL不是設計用來保護操作系統的；SSL是Secure Sockets Layer 通訊協議的簡稱，它是被設計用來保護傳輸中的資料，它的業務是把在網頁以及服務器之間的數據傳輸加密起來。這個加密（encryption）的措施能夠防止資料竊取者直接看到傳輸中的資料，像是密碼或者信用卡號碼等等。在這里談到SSL，你就必須了解數字證書（（Digital Certificates）的概念。數字證書是一種能在完全開放系統中準確標識某些主體的機制。一個數字證書包含的信息必須能鑒定用戶身份，確保用戶就是其所持有證書中聲明的用戶。除了唯一的標識信息外，數字證書還包含了證書所有者的公共密鑰。數字證書的使用允許SSL提供認證功能－－保證用戶所請求連接的服務器身份正確無誤。在信用卡號或PIN號碼等機密信息被發送出去前讓用戶確切知道通訊的另一端的身份是毫無疑問的重要的。很明顯的，SSL技術提供了有效的認證。然而大多數用戶并未能正確意識到通過SSL進行安全連接的必需性。除非越來越多的用戶了解SSL和安全站點的基本知識，否則SSL仍不足以成為保護用戶網絡連接的必需技術。除非用戶能夠充分意識到訪問站點時應該注意安全連接標識，否則現有的安全技術仍不能稱為真正有效。

目前幾乎所有處理具有敏感度的資料，財務資料或者要求身分認證的網站都會使用 SSL 加密技術。（當你看到 https 在你的網頁瀏覽器上的 URL 出現時，你就是正在使用具有 SSL 保護的網頁服務器。） 在這里我把 SSL 比喻成是一種在瀏覽器跟網絡服務器之間「受密碼保護的導管」（cryptographic pipe），也就是我們常說的安全通道。這個安全通道把使用者以及網站之間往返的資料加密起來。但是 SSL 并不會消除或者減弱網站所將受到的威脅性。在 SSL這個安全通道的背后，一般沒有受到 SSL 防護的網站一樣具備了相同的網頁服務器程序，同樣的網頁應用程序，CGI 的 script 以及后端數據庫。目前普遍存在這么一個錯誤的認識：很多系統管理者卻認為，受到 SSL 防護的網頁服務器自動就變得安全了。其實不然，事實上，受到 SSL 防護的網頁服務器同樣還是會受到與一般其它網站服務器遭受攻擊的威脅，受到 SSL 防護的網頁服務器不一定是萬無一失的。

二、SSL的安全漏洞

雖然一個網站可能使用了SSL安全技術，但這并不是說在該網站中正在輸入和以后輸入的數據也是安全的。所有人都應該意識到SSL提供的僅僅是電子商務整體安全中的一小部份解決方案。SSL在網站上的使用可能會造成管理員對其站點安全性的某些錯覺。使用了SSL的網站所可能受到的攻擊和其它服務器并無任何區別，同樣應該留意各方面的安全性。簡言之，加密和數字證書，SSL的主要組成，從來都無法保護服務器－－它們僅僅可以保護該服務器所收發的數據。SSL常見安全問題下面三種：

1、攻擊證書

類似Verisign之類的公共CA機構并不總是可靠的，系統管理員經常犯的錯誤是過于信任Verisign等的公共CA機構。例如，如果Verisign發放一個證書說我是"某某某"，系統管理員很可能就會相信"我是某某某"。但是，對于用戶的證書，公共CA機構可能不象對網站數字證書那樣重視和關心其準確性。例如，Verisign發放了一個“keyman"組織的證書，而我是其中一員“JACK”。當一個網站要求認證用戶身份時，我們提交了“JACK”的證書。你可能會對其返回的結果大吃一驚的。更為嚴重的是，由于微軟公司的IIS服務器提供了"客戶端證書映射"（Client Certificate Mapping）功能，用于將客戶端提交證書中的名字映射到NT系統的用戶帳號，在這種情況下我們就能夠獲得該主機的系統管理員特權！

如果黑客不能利用上面的非法的證書突破服務器，他們可以嘗試暴力攻擊（brute-force attack）。雖然暴力攻擊證書比暴力攻擊口令更為困難，但仍然是一種攻擊方法。要暴力攻擊客戶端認證，黑客編輯一個可能的用戶名字列表，然后為每一個名字向CA機構申請證書。每一個證書都用于嘗試獲取訪問權限。用戶名的選擇越好，其中一個證書被認可的可能性就越高。暴力攻擊證書的方便之處在于它僅需要猜測一個有效的用戶名，而不是猜測用戶名和口令。

2、竊取證書

除上面的方法外，黑客還可能竊取有效的證書及相應的私有密鑰。最簡單的方法是利用特洛伊木馬。這種攻擊幾乎可使客戶端證書形同虛設。它攻擊的是證書的一個根本性弱點：私有密鑰－－整個安全系統的核心－－經常保存在不安全的地方。對付這些攻擊的唯一有效方法或許是將證書保存到智能卡或令牌之類的設備中，但這里我不打算討論這個范圍，在以后，我將會向大家詳細介紹。

3、安全盲點 系統管理員沒辦法使用現有的安全漏洞掃描（vulnerability scanners）或網絡入侵偵測系統（intrusion detection systems，IDS），來審查或監控網絡上的 SSL 交易。網絡入侵偵測系統是通過監測網絡傳輸來找尋沒有經過認證的活動。任何符合已知的攻擊模式或者并未經過政策上授權的網絡活動都被標起來以供系統管理者檢視。而要讓 IDS 能夠發生作用，IDS 必須能夠檢視所有的網絡流量信息，但是 SSL 的加密技術卻使得通過 http 傳輸的信息無法讓 IDS 辨認。再者，雖然我們可以用最新的安全掃描軟件審查一般的網頁服務器來尋找已知的安全盲點，這種掃描軟件并不會檢查經過 SSL 保護的服務器。受到 SSL 保護的網頁服務器的確擁有與一般服務器同樣的安全盲點，可是也許是因為建立 SSL 連結所需要的時間以及困難度，安全漏洞掃描軟件并不會審查受到 SSL 保護的網頁服務器。沒有網絡監測系統再加上沒有安全漏洞審查，使得最重要的服務器反而成為受到最少防護的服務器。

三、解決方法

至于如何保護證書的安全，你可以采用IDS（Intrusion Detection System），它是一種用于監測攻擊服務器企圖的技術和方法。典型的IDS監視網絡通訊，并將其與保存在數據庫中的已知攻擊"特征"或方法比較。如果發現攻擊，IDS可以提醒系統管理員、截斷連接或甚至實施反攻擊等。問題在于如果網絡通訊是加密的，IDS將無法監視。這反而可能會使攻擊更為輕松。假設在一個典型的被防火墻和IDS防護的DMZ環境中，黑客能輕松地探測被SSL保護的網站，因為SSL對數據的加密使得IDS無法正常監測攻擊。通常一臺單一的網站服務器會同時使用SSL和普通的TCP協議。由于黑客攻擊的服務器而不是網絡連接，他們可以選擇任意一種途徑。通過SSL途徑，黑客知道SSL加密為他們帶來的好處，這樣更容易避開IDS系統的監測。對于IDS方面的詳細內容，我以前向大家介紹過了，大家可以到天極網看《淺析網絡入侵監測系統-IDS的應用》一文。在這里我主要介紹的是如何解決系統管理員沒辦法使用現有的安全漏洞掃描或網絡入侵偵測系統而存在的網頁服務器安全盲點的情況，目前解決這個困擾的常用方法大致有以下三種：

1、通過 Proxy 代理服務器的 SSL
我們可以在一個 SSL Proxy 代理程序上使用這項資料審查技術。SSL Proxy 是一個在連接埠 80 上接收純文字的 HTTP 通訊請求的軟件， 它會將這些請求通過經由 SSL 加密過的連結，轉寄到目標網站。我們在連接埠 80 開一個聽取的 socket，通過上述的 OpenSSL 指令，將所有進入這個 proxy 的數據傳送出去。這在 Unix 上，只是個小技巧：你只須將以下的指令加到你們的/etc/inetd.conf 檔案里面，這個 inetd.conf 包含所有 inetd 所提供的網絡服務的設定：
www stream tcp nowait root /usr/sbin/tcpd /usr/local/bin/ssl_proxy.sh 
而 /usr/local/bin/ssl_proxy.sh 的內容則如下所述：
#!/bin/sh
/usr/local/ssl/bin/openssl s_client -no_tls1 -quiet -connect 168.172.100.10:443 2>/dev/null 
168.172.100.10 是 SSL 防護下的網站的地址所在。其中 -no_tls1 以及 -quiet 選項將 SSL 交談 （handshake）的標題顯示關掉，并且也刪除了 SSL 對于尚未經過授權的網站認證所發出的警告。
如果你要想測試你的 proxy 連結，那么你只要以純文字的方式，在執行 SSL proxy 的系統的連接端口 80 建立聯機。這個 proxy 會使用 SSL 來轉寄接收的請求到目標網站。
$ telnet 182.197.110.180 GET / HTTP/1.0
在這里，服務器正在 182.197.110.1的地址執行 SSL proxy 機制，而真正受到 SSL 保護的地址則是在 168.172.100.10。通過這個 SSL proxy 機制，我們只要將安全掃描軟件指向 proxy 的 IP 地址，就可以使用它來審查一個SSL 服務器。 
在這里，你可以使用whisker程序（網址：http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=2 ）來審查 SSL 防護的網站服務器。Whisker是一個由 Rain Forest Puppy 寫出來的 script，可以用來檢查已知的比較容易受到入侵的網站應用程序以及 CGI script。
./whisker.pl -h 168.172.100.2 
-- whisker / v1.3.0a / rain forest puppy / ADM / wiretrip -- 
- Loaded script database of 1691 lines
= - = - = - = - = - = 
= Host: 168.172.100.2 
= Server: Microsoft-IIS/4.0
+ 404 Object Not Found: GET /cfdocs/ 
+ 404 Object Not Found: GET /cfide/Administrator/startstop.html 
+ 404 Object Not Found: GET /cfappman/index.cfm 
+ 404 Object Not Found: GET /cgi-bin/ 
+ 403 Access Forbidden: HEAD /scripts/ 
+ 403 Access Forbidden: HEAD /scripts/cpshost.dll 
+ 404 Object Not Found: HEAD /samples/search/queryhit.htm 
+ 404 Object Not Found: HEAD /adsamples/config/site.csc 
+ 403 Access Forbidden: HEAD /scripts/counter.exe 
+ 403 Access Forbidden: HEAD /scripts/samples/ 
? 
以上情況是，在 182.197.110.1上執行 whisker，然后 whisker 使用 SSL 將所有的 HTTP 請求轉寄到 168.172.100.10。 
SSL proxy 的觀念已經存在一陣子了。目前有一個名為sslproxy.c（網址：http://www.obdev.at/Products/sslproxy.html ） 的程序，可以執行以上的功能。另外一個最近才出來，執行 SSL proxy 還有它額外功能的工具程序，叫做stunnel（http://www.stunnel.org/ ）， 是由 Brian Hatch 開發的。然而，因為使用命令列模式操作 OpenSSL 軟件相對來說比較簡單的，所以我將在下面介紹這種方式。
2、OpenSSL（相關資料網址：http://www.openssl.org/）
OpenSSL 包含了一套程序以及函式庫，提供前端使用者 SSL 功能，并且允許軟件工程師將 SSL 模塊與他們的程序結合。在眾多由 SSL 提供的產品里面，最能夠用來讓我們在這里討論的是命令列模式的（command-line） SSL 客戶端以及伺服端工具軟件。OpenSSL 程序是一個指令列接口的程序，它是用來以手動的方式起始 SSL 連結。OpenSSL 讓你重新導引與其它程序之間的資料輸入以及輸出。
使用普遍可得的安全掃描軟件來審查 SSL 服務器在研究技術文件時，我們在 Apache 提供給 OpenSSL 的接口模塊 mod_ssl(相關資料網址：http://www.modssl.org/)讀到了一些有趣的信息。其中有 一段常見問題（FAQ）討論到有關測試在 SSL 保護下的網站服務器。你可以利用 Telnet 連到網頁服務器第 80 號連接埠，然后下達如下的 http get 指令，從網頁服務器取得網頁：
telnet www.ramsec.com 80
Trying 216.182.36.154...
Connected to www.ramsec.com.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://216.182.36.154/index.html
Date: Mon, 10 Jul 2000 11:43:59 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 23 Mar 2000 01:41:15 GMT
ETag: "305fc7e06894bf1:38441"
Content-Length: 886
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; 
charset=iso-8859-1">
因為 SSL 通聯必須要經過一個安全的連接埠，而在這里我們使用的是沒有安全防護的連接埠 80，因此，這個技巧在 HTTPS 通訊協議上是行不通的。然而，如果我們用的是 OpenSSL程序，我們就可以在 SSL 連接上做同樣的一件事情。下面是OpenSSL 連結的細節openssl ：s_client -connect www.ramsec.com:443
CONNECTED(00000003)
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
i:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIClTCCAgICEGJTOhcnU+VNQDZ7fqS1K8UwDQYJKoZIhvcNAQEEBQAwXzELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYD
VQQLEyVTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAw
MDEyNDAwMDAwMFoXDTAxMDEyMzIzNTk1OVowgbsxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpXYXNoaW5ndG9uMRMwEQYDVQQHFApOZXcgQ2FzdGxlMSMwIQYDVQQKFBpS
YW1wYXJ0IFNlY3VyaXR5IEdyb3VwIExMQzEMMAoGA1UECxQDV2ViMTMwMQYDVQQL
FCpUZXJtcyBvZiB1c2UgYXQgd3d3LnZlcmlzaWduLmNvbS9SUEEgKGMpOTkxGjAY
BgNVBAMUEXNlY3VyZS5yYW1zZWMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQD+0K9xpPTh79iWWXc5JmTeJrg5YNdmwP5EwfKSPqOk2E8QSRNk8+Huv7h7
h636cDbmIh+J+VuRO5x5YP8apUCcqRfIMmQevTFzaIyCf3Mwm/OKNTs+4tqA5kjT
SedbBUGaaY2A1VcK0uby1djc+oX8XoCMoRWy+VGBkBrLK51t2QIDAQABMA0GCSqG
SIb3DQEBBAUAA34AhT7v59KwTvldIHJV7U4Doca+/wQ6ivbyd35K9hC/wxwE/jnO
oBXFKaJvV6mHk9hVz37CtLauUGYIZb3x7Cw6GajhhPicLi0l6ndH4VF9C4tbUb4t
2yw/6Jy9i+TfsO/Ldcu4KV0688vfORWm663+6miLYHKGNqFMaR3QaXc=
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=New Castle/O=Rampart Security Group
LLC/OU=Web/OU=Terms of use at www.verisign.com/RPA
(c)99/CN=secure.ramsec.com
issuer=/C=US/O=RSA Data Security, Inc./OU=Secure Server 
Certification
Authority
---
No client certificate CA names sent
---
SSL handshake has read 801 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 
020000001E9F693D9F9D5FF87E6DF24A0BAFC85391992415991DF3AB74522BCB
Session-ID-ctx: 
Master-Key: 
08FD7A5E6D058A45D0855AD359C0428F3BB5A685E6D74DFB9CDAB6D6A2ED7D53
E97147155DC7B9C61B946BE6
Key-Arg : None
Start Time: 963184785
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
GET / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://216.182.36.154/index.html
Date: Mon, 10 Jul 2000 11:41:25 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 23 Mar 2000 01:41:15 GMT
ETag: "305fc7e06894bf1:38441"
Content-Length: 886

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; 
charset=iso-8859-1">
通過上面OpenSSL這項技術，我們就可以直接傳送資料到有 SSL 保護的網站，然后用我們一般審查任何 HTTP 服務器安全性的方式來審查這個 SSL 網頁服務器。
3、監測 SSL 服務器
現在的網絡 IDS 只能夠監視純文字資料內容，所以我們只能夠有兩項選擇：監視服務器上的 SSL 連結或者將整個連結資料轉為純文字格式。大部分的網頁服務器都有一些基本的日志紀錄功能。例如：Microsoft 的 IIS Web server有內建的日志制作功能，使用的是 W3svc1 格式，它可以偵測到很多一般的網絡攻擊狀況。我通過前述的 SSL proxy 針對 Windows NT 4.0 上具備有 SSL 防護的 IIS 服務器，來作示范性的攻擊。我們用的是由 Rain Forest Puppy 發現的一般性常見的 msadc 安全穿透技術。我們的 IIS 服務器在 C:\WINNT\system32\LogFiles 的目錄下，記載了以下的日志：
12:25:45 10.0.0.1 GET /msadc/msadcs.dll 200
12:25:48 10.0.0.1 POST / msadc/msadcs.dll 200 
然而，因為這些日志文件通常是存在網頁服務器上面，因此，一個成功的攻擊事件表示黑客很可能已經對日志文件下了手腳了。此外，安全管理員必須每天檢查服務器上的日志文件（另外還有 IDS，防火墻等等），這實在不是個最佳的解決方案。 
除了使用主機日志文件的以外，另一個方式是將 SSL 連結轉換成純文字格式。如此一來網絡的 IDS 就能夠監視資料往來。有幾種產品提供這項功能，不過他們主要是為了要提升數據處理效能，而不是為了網絡安全的理由。建立以及維護 SSL 連結，必須耗用相當的 CPU 時間，如此一來會減損網頁服務器的效能。市面上有幾家廠商提供「電子商務加速器」，用來將與 SSL 交涉的工作移到不同的裝置或處理器。你可以將 IDS 置放于加速器跟網頁服務器之間，以監控純文字格式的網絡交通。用這種方式監控的話，有一個問題。那就是你必須有至少一個網絡區隔（network segment）。這個網絡區隔必須是安全的，而且與其它的網絡裝置分開來。
結論
總的來說SSL仍然不失為一套全面完善的安全策略中有效的組成元素。然而，與網絡安全的其它工具軟件一樣，僅使用單一的防護軟件都是無效的。對SSL的過高評價有可能帶來安全風險。它僅是網絡安全工具的一種，必須和其它網絡安全工具緊密結合，方能構造出全面、完善、安全可靠的網絡。最后有兩件重要的事情是你必須牢記在心的，首先，SSL 并不能夠防護你的網站安全。它僅僅防護使用者的網頁服務器以及目標網站之間的點對點數據鏈路，網頁服務器跟后端的網頁應用軟件， 仍舊會受到跟一般沒有 SSL 防護的網站同樣的攻擊威脅；第二點，雖然 SSL 會使網絡黑客很難用目前已知的攻擊模式直接攻擊 SSL 防護網站，不過，這些防衛仍舊是有可能用諸如 SSL proxy 等工具來加以突破，然而，相同的技術卻也可以被用來監視以及審查系統的安全漏洞。