如果Web服務中的SSL和TLS協議出現安全問題，後果會如何？很明顯，這樣的話攻擊者就可以擁有你所有的安全資訊，包括我們的使用者名稱、密碼、信用卡、銀行資訊……所有的一切。本文將向讀者詳細介紹如何針對Web服務中的SSL和TLS協議進行安全滲透測試。我們首先對這兩種協議進行了概述，然後詳細介紹了針對加密通道安全性的黑盒測試和白盒測試。最後列出了一些常用的安全測試工具。

一、簡介

目前，許多重要的Web服務都使用了SSL和TLS協議對通訊進行保護。我們知道，http協議是使用明文進行傳輸的，但是像網路銀行之類的web應用如果使用http協議的話，那麼所有的機密資訊都會暴露在網路連線中，這就像銀行用一個透明的信封給我們郵寄信用卡帳號和密碼一樣，在從銀行到達使用者之間任何接觸過這封信的人，都能看到我們的帳號和密碼。為了提高其安全性，經常需要通過SSL或者TLS隧道傳輸這些明文，這樣就產生了https通訊流量。例如網路銀行之類的應用，在伺服器和客戶端之間傳輸密碼，信用卡號碼等重要資訊時，都是通過https協議進行加密傳送的。

SSL和TLS是兩種安全協議，它們通過加密技術為傳輸的資訊提供安全通道、機密性和身份驗證等安全功能。我們知道由於對高階密碼技術的出口限制，會造成遺留系統使用的是弱加密技術。如果系統採用了弱密碼，或者說密碼強度過低的話，攻擊者可以在有效的時間內破解金鑰，而攻擊者一旦得到了金鑰，就像小偷得到了我們家的鑰匙一樣，所有的鎖都會形同虛設。但是，新Web伺服器就不會使用弱加密系統了嗎？答案是否定的，因為許多新Web伺服器也經常被配置成處理虛密碼選項。為了實現這些安全特性，協議必須確保使用的密碼演算法有足夠的強度，並且密碼演算法得到了正確的實現。即使伺服器安裝使用了高階的加密模組，但是如果配置不當的話，也有可能為安全特性要求較高的通訊通道的設定了較弱的加密技術。下面，我們將詳細介紹如何對這兩種協議的配置進行安全審計。

二、測試SSL/TLS的密碼規範

我們知道，http協議是使用明文進行傳輸的，為了提高其安全性，經常需要通過SSL或者TLS隧道傳輸這些明文，這樣就產生了https通訊流量。除對傳輸的資料進行加密處理之外，https（安全超文字傳輸協議，HTTPS）還能利用數字證書為伺服器或客戶端提供身份標識。

過去，美國政府對加密系統的出口有許多限制，如金鑰長度最大為40位，因為金鑰長度越短，它就越容易破解。後來，密碼出口條例已經放寬了許多，但是，檢查伺服器的SSL配置仍然十分重要，因為它有可能配置使用了弱加密技術。基於SSL的服務不應該提供選擇弱密碼的機會。

注意，我們這裡所說的弱密碼，指的是加密強度不夠、容易破解的加密系統。不同的加密演算法具有不同的密碼強度，但是在演算法一定的情況下，金鑰的長度越長，加密強度越高。

技術上，選擇加密技術的過程如下所示：在建立SSL連線的初期，客戶端向伺服器傳送一個Client Hello訊息，以告知伺服器它支援哪些加密技術等。一般情況下，客戶端通常是一個Web瀏覽器，所以瀏覽器是目前最常見的SSL客戶端；然而，任何支援SSL的應用程式都可以作為SSL客戶端使用。比如，有時候SSL客戶端是些SSL代理（如stunnel），它們使得那些不支援SSL的工具也能與SSL服務通訊。同理，SSL伺服器端通常為Web伺服器，但是其他應用程式也可以充當SSL伺服器端。 加密套件規定了具體的密碼協議（DES、RC4、AES）、金鑰長度（諸如40、56或者128位）和用於完整性檢驗的雜湊演算法（SHA、MD5）。收到Client Hello訊息後，伺服器以此確定該會話所使用的加密套件。當然，通過配置可以規定伺服器能夠接受哪些密碼套件，這樣的話，我們就能夠控制是否跟僅支援40位加密的客戶端通話

三、黑盒測試

為了檢測可能支援的弱密碼，必須找出與SSL/TLS服務相關的埠。通常情況下，要檢查埠443，因為它是標準的https埠；不過執行在443埠上的卻未必是https服務，因為通過配置，https服務可以執行在非標準的埠上，同時，Web應用程式也許使用了其它利用SSL/TLS封裝的服務。一般而言，為了找出這些埠，必須找出使用了哪些服務。

利用掃描程式nmap時，加上掃描選項–sV，就能用來識別SSL服務。實際上，安全漏洞掃描器除了可以顯示使用的服務之外，還能用來檢查弱密碼，比如，Nessus就能檢查任意埠上的SSL服務，並報告弱密碼。

如果攻擊者在您修復弱密碼之前發現了它們的話，那麼您的處境可就不妙了——利用當前強大的桌面計算力，例如藉助GPU的並行運算，他們能夠在有效的時間內破解出金鑰，然後就能解密出https通道中加密過的機密資訊，如口令，使用者名稱，如果您在使用網路銀行，還能獲得他們的帳號和口令，等等。所以，我們一定要在攻擊者下手之前發現並修復存在的弱密碼配置。

例1. 通過nmap識別SSL服務

[[email protected]]# nmap -F -sV localhostStarting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2009-07-28 13:31 CESTInteresting ports on localhost.localdomain (127.0.0.1):(The 1205 ports scanned but not shown below are in state: closed)PORT      STATE SERVICE         VERSION443/tcp   open  ssl             OpenSSL901/tcp   open  http            Samba SWAT administration server8080/tcp  open  http            Apache httpd 2.0.54 ((Unix) mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/4.3.11)8081/tcp  open  http            Apache Tomcat/Coyote JSP engine 1.0Nmap run completed -- 1 IP address (1 host up) scanned in 27.881 seconds[[email protected]]# 

例2. 利用Nessus識別弱密碼。

下面內容摘自Nessus掃描程式生成的報告，它發現了一個允許弱密碼的伺服器證書（黑體字部分）。

https (443/tcp) Description Here is the SSLv2 server certificate: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=**, ST=******, L=******, O=******, OU=******, CN=****** Validity Not Before: Oct 17 07:12:16 2007 GMT Not After : Oct 16 07:12:16 2008 GMT Subject: C=**, ST=******, L=******, O=******, CN=****** Subject Public Key Inf Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:98:4f:24:16:cb:0f:74:e8:9c:55:ce:62:14:4e: 6b:84:c5:81:43:59:c1:2e:ac:ba:af:92:51:f3:0b: ad:e1:4b:22:ba:5a:9a:1e:0f:0b:fb:3d:5d:e6:fc: ef:b8:8c:dc:78:28:97:8b:f0:1f:17:9f:69:3f:0e: 72:51:24:1b:9c:3d:85:52:1d:df:da:5a:b8:2e:d2: 09:00:76:24:43:bc:08:67:6b:dd:6b:e9:d2:f5:67: e1:90:2a:b4:3b:b4:3c:b3:71:4e:88:08:74:b9:a8: 2d:c4:8c:65:93:08:e6:2f:fd:e0:fa:dc:6d:d7:a2: 3d:0a:75:26:cf:dc:47:74:29 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate Page 10 Network Vulnerability Assessment Report 25.07.2009 X509v3 Subject Key Identifier: 10:00:38:4C:45:F0:7C:E4:C6:A7:A4:E2:C9:F0:E4:2B:A8:F9:63:A8 X509v3 Authority Key Identifier: keyid:CE:E5:F9:41:7B:D9:0E:5E:5D:DF:5E:B9:F3:E6:4A:12:19:02:76:CE DirName:/C=**/ST=******/L=******/O=******/OU=******/CN=******serial:00 Signature Algorithm: md5WithRSAEncryption 7b:14:bd:c7:3c:0c:01:8d:69:91:95:46:5c:e6:1e:25:9b:aa: 8b:f5:0d:de:e3:2e:82:1e:68:be:97:3b:39:4a:83:ae:fd:15:2e:50:c8:a7:16:6e:c9:4e:76:cc:fd:69:ae:4f:12:b8:e7:01: b6:58:7e:39:d1:fa:8d:49:bd:ff:6b:a8:dd:ae:83:ed:bc:b2: 40:e3:a5:e0:fd:ae:3f:57:4d:ec:f3:21:34:b1:84:97:06:6f: f4:7d:f4:1c:84:cc:bb:1c:1c:e7:7a:7d:2d:e9:49:60:93:12: 0d:9f:05:8c:8e:f9:cf:e8:9f:fc:15:c0:6e:e2:fe:e5:07:81: 82:fc Here is the list of available SSLv2 ciphers: RC4-MD5EXP-RC4-MD5RC2-CBC-MD5EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 RC4-64-MD5 The SSLv2 server offers 5 strong ciphers, but also 0 medium strength and 2 weak "export class" ciphers. The weak/medium ciphers may be chosen by an export-grade or badly configured client software. They only offer a limited protection against a brute force attack Solution: disable those ciphers and upgrade your client software if necessary. See http://support.microsoft.com/default.aspx?scid=kben-us216482 or http://httpd.apache.org/docs-2.0/mod/mod_ssl.html#sslciphersuite This SSLv2 server also accepts SSLv3 connections.This SSLv2 server also accepts TLSv1 connections. Vulnerable hosts (以下從略)

例3. 利用OpenSSL以手工方式審計SSL的弱密碼

這裡我們試圖通過SSLv2連線到Google.com：

[[email protected]]# openssl s_client -no_tls1 -no_ssl3 -connect www.google.com:443CONNECTED(00000003)depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.comverify error:num=20:unable to get local issuer certificateverify return:1depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.comverify error:num=27:certificate not trustedverify return:1depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.comverify error:num=21:unable to verify the first certificateverify return:1---Server certificate-----BEGIN CERTIFICATE-----MIIDYzCCAsygAwIBAgIQYFbAC3yUC8RFj9MS7lfBkzANBgkqhkiG9w0BAQQFADCBzjELMAkGA1UEB

hMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYDVQQ

KExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaX

Zpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlw

cmVtaXVtLXNlcnZlckB0aGF3dGUuY29tMB4XDTA2MDQyMTAxMDc0NVoXDTA3MDQyMTAxMDc0NVow

aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1vdW50YWluIFZpZX

cxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnd3dy5nb29nbGUuY29tMIGfMA0GCSqGSIb3D

QEBAQUAA4GNADCBiQKBgQC/e2Vs8U33fRDk5NNpNgkB1zKw4rqTozmfwty7eTEI8PVH1Bf6nthocQ9d9SgJ

AI2WOBP4grPj7MqOdXMTFWGDfiTnwes16G7NZlyh6peT68r7ifrwSsVLisJp6pUf31M5Z3D88b+Yy4PED

7BJaTxq6NNmP1vYUJeXsGSGrV6FUQIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr

BgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUHJlbWl1bV

NlcnZlckNBLmNybDAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRo

YXd0ZS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQADlTbBdVY6LD1nHWkhT

admzuWq2rWE0KO3Ay+7EleYWPOo+EST315QLpU6pQgblgobGoI5x/fUg2U8WiYj1I1cbavhX2h1hda3FJW

nB3SiXaiuDTsGxQ267EwCVWD5bCrSWa64ilSJTgiUmzAv0a2W8YHXdG08+nYcX/dVk5WRTw==-----END CERTIFICATE-----subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.comissuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected] client certificate CA names sent---Ciphers common between both SSL endpoints:RC4-MD5         EXP-RC4-MD5     RC2-CBC-MD5EXP-RC2-CBC-MD5 DES-CBC-MD5     DES-CBC3-MD5RC4-64-MD5---SSL handshake has read 1023 bytes and written 333 bytes---New, SSLv2, Cipher is DES-CBC3-MD5Server public key is 1024 bitCompression: NONEExpansion: NONESSL-Session:    Protocol  : SSLv2    Cipher    : DES-CBC3-MD5Session-ID: 709F48E4D567C70A2E49886E4C697CDE    Session-ID-ctx:    Master-Key: 649E68F8CF936E69642286AC40A80F433602E3C36FD288C3    Key-Arg   : E8CB6FEB9ECF3033    Start Time: 1156977226    Timeout   : 300 (sec)    Verify return code: 21 (unable to verify the first certificate)---closed

例4.中間人攻擊

為了幫助讀者理解中間人攻擊，我們舉一個現例項子。罪犯冒充公安人員給受害者打電話，說有人利用使用者的網路銀行帳號進行洗錢活動，公安機關要求該使用者協助調查，給出其帳號的具體資訊，包括密碼。如果使用者上當，交出了密碼等資訊，那麼犯罪分子就可以利用這些資訊洗劫賬戶內的資金。這就是一種典型的中間人攻擊。

下面是一個Web環境下的中間人攻擊示意圖。

首先，在IE瀏覽器的位址列輸入登入地址，如下圖所示：

然後，利用代理篡改返回的資料包，讓它返回502錯誤（或其他錯誤），並插入一個iframe，讓瀏覽器請求真實地址，同時插入一段如下所示的指令碼：這樣就能讀取iframe的內容，如下圖所示：圖4  讀取的iframe內容

實際上，攻擊者不僅能夠讀取該iframe的內容，還能夠向該域進行提交。在真實的攻擊環境中，攻擊者可以讀取防止跨站請求偽造令牌，實施跨站請求攻擊，甚至截獲使用者名稱和密碼。

四、白盒測試

對於提供https服務的web伺服器，要仔細檢查其配置；如果Web應用程式提供了其他使用SSL/TLS封裝的服務，也應當對其進行仔細檢查。例如，以下Microsoft Windows 2003的登錄檔路徑定義了伺服器可用的加密技術：

EY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\

五、測試SSL證書的有效性

通過https協議訪問Web應用程式時，就會在客戶端(通常為瀏覽器)和伺服器之間建立一個安全通道。然後，通過數字證書為通訊的一方（伺服器）或雙方（客戶和伺服器）建立身份標識。為了進行通訊，這些證書需要通過多道檢測。基於SSL和證書的身份驗證超出了本文的範圍，我們這裡主要探討證書有效性的主要標準：檢查認證中心是否是可信的機構；檢查證書當前的有效性；站點名稱和證書中所聲稱的是否一致。要經常升級您的瀏覽器，因為CA證書也會過期，在瀏覽器的不同版本中，CA證書會重新生成。另外，因為越來越多的網站要求強度高於40或者56位的加密，這時也需要更新瀏覽器，因為一些老版本不支援這些高強度加密。下面我們做進一步的解釋。

1.每個瀏覽器都帶有一個預裝的受信CA列表，當我們收到證書時，可以到簽發該證書的認證中心CA去驗證一下。當然，這個列表是可以隨意定製和擴充套件的。 在與https伺服器的初步磋商期間，如果伺服器證書是瀏覽器不瞭解的認證中心簽發的，那麼就會丟擲一個警告。出現這種情況，一般是因為Web應用程式的證書是由一個自建的認證中心所簽發的。 對於內部網環境來說，自建認證中心是比較合適的，因為企業web電子郵件是通過https傳輸的，同時，企業內的所有使用者都會信任這個內部認證中心。但是，當通過Internet向公眾提供服務時，則需要使用一個所有公共使用者都信任的認證中心。

2.證書都有一個有效期，因此，它也是會過期的。同樣，如果證書過期的話，瀏覽器也會丟擲一個警告。公用服務需要一個暫時有效的證書；否則，當我們跟一個伺服器通訊時，只要它的證書是受信任的認證中心頒發的，即使過期也無需重新生成。

3.如果證書中的名稱跟伺服器的名稱不相配怎麼辦呢？如果出現這種情況，就說明很可疑。一個系統可以託管許多基於名稱的虛擬主機，這些虛擬主機共享同一個IP地址，彼此靠HTTP 1.1的Host:頭部相互區別。在這個例子中，因為在處理HTTP請求之前，SSL握手時會檢查伺服器證書，所以它不可能為每個虛擬伺服器分配不同的證書。因此，如果站點的名稱和證書中所指出的名稱不匹配，那麼我們瀏覽器就會發出通知。為了避免這種情況，必須使用基於IP的虛擬伺服器。 RFC2817（http://www.ietf.org/rfc/rfc2817.txt）和RFC3546（http://www.ietf.org/rfc/rfc3546.tx）這兩個文件描述了處理這個問題並允許正確引用基於名稱的虛擬主機的方法。

證書有效性的黑盒測試

下面介紹如何檢查應用程式使用的證書的有效性。當瀏覽器遇到過期的證書、由不可信的認證中心簽發的證書以及證書上的名稱跟伺服器名稱不一致時，它就會發出一個警告。 訪問https站點的時候，我們只要單擊在瀏覽器視窗中的“鎖”圖示，就能看到與證書有關的資訊，如證書籤發機構、有效期、加密特性等。

如果應用程式要求客戶端證書，那也不要緊，因為訪問該程式之前我們很可能已經安裝過證書，所以可以通過檢視瀏覽器證書列表中已安裝的的相關證書來獲得必要的證書資訊。

對於應用程式所用的所有SSL通訊通道，必須進行上述檢查。雖然https服務通常執行在443埠上，但還可能有依賴這個Web應用程式的其它服務，從而導致https管理埠一直開啟，或者在非標準的埠上執行https服務，等等。 因此，要對所有已經發現的使用SSL進行封裝的埠進行檢查，比如，nmap掃描程式提供了一個掃描模式——需要在命令列中加上–sV選項來啟用該模式 ——專門用來查詢使用SSL進行封裝的服務。安全漏洞掃描程式Nessus也能對所有使用SSL/TLS封裝的服務進行檢查。

以下截圖取自一個公司的站點。它是一個Microsoft IE發出的警告，呵呵，我們要訪問的是一個.it站點，而該證書卻是發給一個.com 站點的？！ IE警告說，證書上的名稱與站點的名稱不匹配。

證書有效性的白盒測試

在伺服器和客戶端級別都檢查應用程式所用的證書的有效性。證書最初是應用在Web 伺服器級別的，然而，SSL還可能用來保護其它通訊路徑，例如DBMS使用的路徑。您應該檢查應用程式體系結構來尋找所有的SSL保護的通道。

六、測試工具

下面介紹在測試加密通道的安全性的時候，可能有到的測試工具：   

安全漏洞掃描器可以檢查證書的有效性，包括名稱匹配情況和過期情況。此外，它們通常還報告其他資訊，諸如頒發證書的機構等等。 請記住，哪些CA是可信的，完全取決於人們的觀念和軟體的配置；不過，瀏覽器通常帶有一組預設的可信認證中心。 如果您的Web應用程式使用的CA沒有位於這個列表中的話，例如依靠一個自建的認證中心，那麼您應該讓使用者重新配置他們的瀏覽器，讓瀏覽器認可這個認證中心。    

掃描程式Nessus有一個外掛可以用來檢查已經過期的證書、或者在60天內將過期的證書。該外掛的id為15901，名字為SSL certificate expiry。 這個外掛將檢查安裝在伺服器上的證書。    

有的安全漏洞掃描器也能檢查弱密碼，比如，掃描程式Nessus，它就能指出存在的SSL弱密碼。    

此外，我們還可能需要一些特殊的工具，例如SSL Digger（http://www.foundstone.com/resources/proddesc/ssldigger.htm）；或者Openssl工具，它能直接從UNIX命令列下訪問Openssl加密函式。     為了識別基於SSL的服務，可以使用具有服務識別能力的安全漏洞掃描程式或者埠掃描程式。掃描程式nmap具有一個-sV掃描選項，用以識別服務；安全漏洞掃描程式Nessus則能識別在任意的埠上的基於SSL的服務，並對這些服務進行安全漏洞檢查——不管它們是在標準埠還是非標準的埠上。    

如果需要與SSL服務互動但是您喜愛的工具卻不支援SSL的話，可以求助於SSL代理，例如stunnel，它能在底層協議中打通隧道跟SSL服務進行通訊。    

最後，儘管人們樂於使用常規瀏覽器來檢查證書，但是瀏覽器通常具有許多漏洞，此外瀏覽器進行檢測時可能受到許多不易察覺的配置設定的影響。相反，依靠安全漏洞掃描器或者專門的工具來進行檢查則要好得多。