何 旭，鮮乾坤，雷建平

(1.達(dá)州職業(yè)技術(shù)學(xué)院，四川 達(dá)州 635001;2.四川理工學(xué)院計(jì)算機(jī)學(xué)院，四川 自貢 643000;3.61902部隊(duì)，四川 宜賓 644000)

引 言

Web瀏覽器的SSL已經(jīng)成為網(wǎng)絡(luò)安全的事實(shí)標(biāo)準(zhǔn)，SSL主要目的是針對中間件攻擊提供端到端的安全保障，即使網(wǎng)絡(luò)受到像DNS入侵或者路由器被控制等這樣的威脅，SSL也能夠保證客戶機(jī)與服務(wù)器之間通信的機(jī)密性、真實(shí)性、完整性［1-2］。

認(rèn)證服務(wù)器是SSL連接建立的關(guān)鍵部分，其公鑰證書身份驗(yàn)證發(fā)生于SSL握手階段。同時，為了保證SSL連接是安全的，客戶端必須確認(rèn)證書是有效證書，即既沒有過期也沒有被撤銷，用以檢查證書名稱、客戶端連接的匹配性［3-4］。

Web瀏覽器對SSL功能的實(shí)現(xiàn)可以通過加入補(bǔ)丁保證安全性，這樣許多與SSL相關(guān)的瀏覽器漏洞就可以得到修復(fù)［5-6］。然而，SSL也廣泛用于非瀏覽器軟件，如基于云計(jì)算虛擬基礎(chǔ)設(shè)施的遠(yuǎn)程管理以及發(fā)送本地?cái)?shù)據(jù)到云存儲，以及Android、iOS等移動應(yīng)用程序的驗(yàn)證服務(wù)。這些程序通常不實(shí)現(xiàn)SSL本身，主要依靠OpenSSL、JSSE與CryptoAPI等SSL庫以及更高層次數(shù)據(jù)傳輸庫作為SSL封閉，在基于Web服務(wù)軟件用額外抽象層引入Web服務(wù)中間件。

入侵者可能控制路由器、交換機(jī)、無線AP或DNS，也可以控制一個或多個擁有SSL證書的服務(wù)器。當(dāng)SSL客戶機(jī)試圖連接到一臺合法服務(wù)器時，入侵者可以通過DNS挾持誘導(dǎo)服務(wù)器，并欺騙用戶連接到一臺入侵者控制的服務(wù)器。

1 SSL證書認(rèn)證機(jī)制

SSL握手協(xié)議是一個更高層的客戶端SSL協(xié)議，該協(xié)議是用來協(xié)商會話的安全屬性，握手消息提供給SSL記錄層，并封裝在一個或多個SSLPlaintext數(shù)據(jù)結(jié)構(gòu)內(nèi)，用以處理與傳輸當(dāng)前活動會話狀態(tài)。SSL連接開始于客戶端和服務(wù)器之間的握手，這樣SSL客戶端的“確認(rèn)服務(wù)器認(rèn)證”容易作為攻擊目標(biāo)。SSL握手協(xié)議由RFC6101［7］給出了完整描述，其握手過程如圖1所示。

圖1 SSL握手協(xié)議描述

信任鏈驗(yàn)證。每個X.509證書有一個“issuer”屬性，其中包含CA的名稱，每臺SSL客戶端配置可信根CA證書列表。除自己的證書外，還有該服務(wù)器發(fā)送的發(fā)行CA認(rèn)證。如果簽發(fā)的CA不是根CA，服務(wù)器還發(fā)送一個更高級別通向根CA的證書列表。客戶端試圖建立一個從底部服務(wù)器證書開始的鏈，鏈中每個證書必須立即由上級CA簽署，根CA必須是客戶信任的CA之一，客戶驗(yàn)證證書沒有過期、中間CA認(rèn)證以及設(shè)置有“Basic Constraints”字段。完整的X.509證書認(rèn)證算法由 RFC5280［3］與 RFC2818［4］給出了描述。

主機(jī)驗(yàn)證。信任鏈建立后，客戶端必須驗(yàn)證服務(wù)器的身份。RFC2818［4］建議使用“SubjectAltNames”作為服務(wù)器標(biāo)識符主要來源以及支持“Common Name”向后兼容，但大多數(shù)軟件是先檢查“Common Name”。構(gòu)建服務(wù)器標(biāo)識列表后，客戶端嘗試匹配所有符合DNS域名的被請求服務(wù)器標(biāo)識符。如果客戶端在服務(wù)器標(biāo)識符列表中找到一條精確匹配，就通過簡單字符串比較進(jìn)行驗(yàn)證，客戶端也可以查找一個匹配規(guī)則復(fù)雜的通配符名字標(biāo)識符的列表［4，8］。

證書撤銷。OpenSSL的一些 SSL庫實(shí)現(xiàn)證書撤銷［9］，但要求應(yīng)用程序提供證書撤銷列表(CRL)。雖然JSSE庫要求應(yīng)用程序檢查自身CRL的有效性，但大多數(shù)應(yīng)用程序不用檢查，如有些SSL庫(Python的SSL)不公開CRL的檢查方法。

X.509擴(kuò)展。一些X.509證書擴(kuò)展包含關(guān)鍵安全信息，如key useage(CA允許使用該秘鑰簽署證書)、name constraints(限制子CA能夠簽署的認(rèn)證)以及RFC2527［10］描述的證書策略。雖然CA可以分配不同的信任級別給子CA，但應(yīng)用程序必須提供利用這些信息的策略，實(shí)際上這些擴(kuò)展在很大程度上可以被忽略，即或是目前的OpenSSL也沒有正確驗(yàn)證名字約束，而cURL甚至沒有接口用于指定應(yīng)用程序證書策略。

2 SSL抽象化安全分析

根據(jù)需求，應(yīng)用程序可以插入到不同層次抽象的SSL內(nèi)，但在最低層次有多種使用不同屬性、許可、硬件請求來實(shí)現(xiàn)通用 SSL，如 OpenSSL、JSSE、CryptoAPI等。因此，為了避免自己解析HTTP，所以使用SSL的HTTP應(yīng)用程序通常不直接使用，而使用HTTPS在內(nèi)部使用SSL庫，SOAP或基于REST的Web服務(wù)應(yīng)用程序在其上層使用額外中間件 HTTPS或 Web Socket，如圖2所示。

圖2 使用SSL的協(xié)議棧

2.1 SSL庫

OpenSSL。OpenSSL只提供信任鏈驗(yàn)證，而應(yīng)用程序必須支持自身主機(jī)驗(yàn)證。不同應(yīng)用層協(xié)議(HTTPS，LDAP)有不同有效主機(jī)組成限制和證書列表匹配要求，因此主機(jī)驗(yàn)證必須通過應(yīng)用程序自身管理或數(shù)據(jù)傳輸層封裝。OpenSSL通過提供返回函數(shù)或修改配置允許應(yīng)用程序定制信任鏈驗(yàn)證［11］，如配置“驗(yàn)證深度(verify depth)”和“驗(yàn)證模式(verify mode)”(圖3)。

使用OpenSSL的程序可以通過調(diào)用SSL_connect函數(shù)執(zhí)行SSL握手。證書驗(yàn)證錯誤信息通過SSL_connect函數(shù)返回值提供，而其他錯誤由SSL_connect函數(shù)設(shè)置內(nèi)部verify result標(biāo)識，應(yīng)用程序必須調(diào)用SSL_get_verify_result函數(shù)以檢查是否發(fā)生此類任何錯誤［12］。

圖3 使用缺省信任鏈驗(yàn)證SSL連接設(shè)置的OpenSSL API圖

JSSE。Java安全套接字?jǐn)U展(JSSE)提供大量接口給Java應(yīng)用程序(包括Android移動應(yīng)用程序)建立SSL連接。低層通過SSLSocketFactory創(chuàng)建的SSL客戶端API可能不執(zhí)行主機(jī)驗(yàn)證。

下面的代碼段來自于X.509的TrustManagerImpl.checkIdentity。

private void checkIdentity(String hostname，

X509Certificate cert，String algorithm)

throws CertificateException{

if(algorithm!=null＆＆algorithm.length()!=0){

....

if(algorithm.equalsIgnoreCase("HTTPS")){

HostnameChecker. getInstance(HostnameChecker.TYPE_TLS).match(hostname，cert);

}else if(algorithm.equalsIgnoreCase

("LDAP")){

HostnameChecker. getInstance(HostnameChecker.TYPE_LDAP).match(hostname，cert);

}else{

throw new CertificateException("Unknown

identification algorithm:"+algorithm);

}

}

}

上述代碼段的功能是實(shí)現(xiàn)對主機(jī)名與認(rèn)證的確認(rèn)。如果algorithm設(shè)置為HTTPS或 LDAP，checkIdentity方法就拋出一個異常，其不同于OpenSSL的返回值，即使驗(yàn)證失敗也認(rèn)為應(yīng)用程序會檢查該值。在HttpsClient和HttpsURLConnection等JSSE應(yīng)用程序中，當(dāng)創(chuàng)建SSL客戶端時就會調(diào)用SetHostnameVerification方法并設(shè)置為HTTPS，其結(jié)果是調(diào)用HostnameChecker和驗(yàn)證證書。

如果客戶端字段是NULL或空串，checkIdentitysilently跳過主機(jī)驗(yàn)證且不拋出異常。該作法是為了適應(yīng)基于證書協(xié)議實(shí)現(xiàn)而重用JSSE的默認(rèn)值HTTPS或LDAP以驗(yàn)證信任鏈。Java7.3的證書驗(yàn)證代碼與Java6不同，如果字段是NULL或空串，checkIdentity根本就不調(diào)用。

private void checkTrusted(X509Certificate［］chain，

String authType，Socket socket，boolean isClient)

throws CertificateException{

...

String identityAlg=sslSocket.getSSLParameters().

getEndpointIdentificationAlgorithm();

if(identityAlg!=null＆＆identityAlg.length!=0){

String hostname=session.getPeerHost();

checkIdentity(hostname，chain［0］，identityAlg);

}

}

上述代碼段實(shí)現(xiàn)對信任鏈的驗(yàn)證功能，驗(yàn)證鏈路中各節(jié)點(diǎn)主機(jī)間的信任關(guān)系。在SSL客戶端使用SSLSocketFactory，如果該字段為空J(rèn)SSE就不執(zhí)行主機(jī)驗(yàn)證，主機(jī)驗(yàn)證工作就由運(yùn)行在JSSE上層的軟件完成，該功能在JSSE參考指南有警告說明。

在發(fā)送任何數(shù)據(jù)前使用SSLSockets/SSLEngines應(yīng)該檢查各節(jié)點(diǎn)證書，因?yàn)镾SLSocket和SSLEngine類不自動驗(yàn)證與URL匹配的域名驗(yàn)證，如果不進(jìn)行主機(jī)驗(yàn)證應(yīng)用程序，這樣就可以利用 URL欺騙。Java軟件使用SSLSocketFactory創(chuàng)建SSL客戶端但不執(zhí)行主機(jī)驗(yàn)證，說明開發(fā)人員并沒意識到該特性，而JSSE接口執(zhí)行主機(jī)驗(yàn)證也增加了其混亂性。

2.2 數(shù)據(jù)運(yùn)輸層的安全機(jī)制

實(shí)際上大多數(shù)應(yīng)用程序依賴數(shù)據(jù)運(yùn)輸層建立HTTPS連接，這些在內(nèi)部使用SSL庫架構(gòu)通常是不透明的應(yīng)用程序。

Apache HttpClient。Apache HttpClient是基于 JDK的客戶端HTTP Java庫。Apache HttpClient廣泛用于Web服務(wù)中間件，是因?yàn)楸镜鼗疛DK不支持SOAP Web服務(wù)，且在發(fā)送HTTP POST請求等功能時，Apache Http-Client比JDK提供了更好性能。Apache HttpClient使用JSSE的SSLSocketFactory建立SSL連接，即Apache Http客戶端必須執(zhí)行自己的主機(jī)驗(yàn)證，這樣對于基于舊版本的HttpClient不驗(yàn)證主機(jī)就會導(dǎo)致很多漏洞。Apache HttpClient使用HttpHost數(shù)據(jù)結(jié)構(gòu)描述 HTTP連接，而HttpHost并沒有任何內(nèi)部一致性檢查，如允許連接到443端口。

cURL。cURL是一個從遠(yuǎn)程服務(wù)器獲取數(shù)據(jù)的工具和庫。從7.10版本開始，cURL默認(rèn)驗(yàn)證SSL證書。內(nèi)部cURL使用OpenSSL驗(yàn)證信任鏈和主機(jī)，其功能由參數(shù) CURLOPT_SSL_VERIFYPEER(默認(rèn)值 true)和CURLOPT_SSL_VERIFYHOST(默認(rèn)值2)控制，VERIFYPEER參數(shù)是布爾類型，而VERIFYHOST參數(shù)是整數(shù)。開發(fā)人員經(jīng)常誤解這些參數(shù)，而且將CURLOPT_SSL_VERIFYHOST設(shè)置為TRUE，從而改變其值為1，這樣如果意外禁用主機(jī)驗(yàn)證就會帶來不安全的后果。

PHP。PHP提供多種方法建立SSL連接，打開遠(yuǎn)程服務(wù)器套接字的fsockopen能夠通過在URL中加入“SSL://”連接到SSL服務(wù)器。盡管fsockopen不執(zhí)行任何證書檢查，PHP應(yīng)用程序開發(fā)人員通常用它來建立SSL連接。PHP也提供cURL綁定，使用cURL默認(rèn)設(shè)置建立SSL連接以適應(yīng)證書驗(yàn)證，開發(fā)人員可能設(shè)置cURL不正確選項(xiàng)改變默認(rèn)值，從而破壞證書驗(yàn)證。

3 非瀏覽器軟件SSL的分析

云客戶端API。云端API是連接云端與客戶端的橋梁，它包括面向各不同協(xié)議客戶端的API和面向第三方的API。前者的作用是云端與客戶端之間的交互，使用RTMP或RTMPE協(xié)議傳輸;后者允許定制特定函數(shù)輸出給第三方，使用RTMP或RTMPE傳輸，或通過本地的PHP中轉(zhuǎn)為HTTP傳輸。對于第三方云計(jì)算平臺的運(yùn)行在客戶端SDK，可以通過第三方軟件傳送用戶數(shù)據(jù)到基于云的存儲、管理用戶基于云的計(jì)算以及訪問其他云服務(wù)。如Amazon在Java、PHP、Python和Perl中提供的EC2 API工具，以及Apache提供的獨(dú)立庫訪問多個云的Libcloud。

Web services中間件。許多程序依賴于Web services。Web services是一軟件系統(tǒng)，用來支持網(wǎng)絡(luò)主機(jī)間的互操作性，其服務(wù)由一個接口描述計(jì)算機(jī)可讀的XML格式文檔。不同系統(tǒng)提供不同具體實(shí)現(xiàn)接口，異構(gòu)系統(tǒng)間通過發(fā)送和接收信息實(shí)現(xiàn)服務(wù)的互操作。

使用基于XML的SOAP或REST的Web services發(fā)送與接收消息。從客戶端軟件的角度來講，Web services可以被認(rèn)為是提供遠(yuǎn)程過程調(diào)用RPC接口，而SOAP或REST中間件是RPC調(diào)用參數(shù)的封裝和解封。

Web service通過使用SOAP中間件與現(xiàn)有Java軟件進(jìn)行交互。同樣地，如果一個Android應(yīng)用程序需要實(shí)時發(fā)送通知，它可以使用客戶端庫連接到基于REST的Pusher服務(wù)。這些中間件框架負(fù)責(zé)發(fā)送Web service信息到網(wǎng)絡(luò)，如果連接必須是安全的，中間件通常使用SSL，而不是現(xiàn)在的SSL連接管理數(shù)據(jù)傳輸庫代替。

4 Apache HttpClient的SSL API安全性應(yīng)用分析

2007年發(fā)布并廣泛使用的Apache HttpClient 3.1版本與較早期的版本一樣，使用JSSE的SSLSocketFactory而不執(zhí)行自身主機(jī)驗(yàn)證來建立SSL連接。這樣Apache HttpClient 3.*接受任何具有有效信任鏈的證書，而不管其名字。

HttpClient主機(jī)驗(yàn)證的缺陷在4.0版得到修正，在4.2.1版本中，有其自身的主機(jī)驗(yàn)證和指派JSSE進(jìn)行信任鏈驗(yàn)證。這樣依靠SSL連接建立HttpClient實(shí)現(xiàn)對應(yīng)用程序的安全性有較少影響。HttpClient的使用通常隱藏內(nèi)部Web services中間件，從而跳過主機(jī)關(guān)于SSL證書認(rèn)證。

值得注意的是，如果用戶將自定義主機(jī)驗(yàn)證代碼添加到HttpClient 4.*是錯誤的，并且將拒絕有效證書。下面的代碼來自HttpClient 4.2.1:

String parts［］=cn.split("\.");

boolean doWildcard=parts.length ＞ =3 ＆＆

parts［0］.endsWith("*")＆＆

acceptableCountryWildcard(cn)＆＆

!isIPAddress(host);

if(doWildcard){

if(parts［0］.length()＞1){

String prefix=parts［0］.substring(0，parts.length-2);

String suffix=cn.substring(parts［0］.length());

String hostSuffix=hostName.substring

(prefix.length());

match=hostName.startsWith(prefix)

＆＆ hostSuffix.endsWith(suffix);

}else{

match=hostName.endsWith(cn.substring(1));

}

if(match＆＆ strictWithSubDomains){

match=countDots(hostName)==countDots(cn);

}

}else{

match=hostName.equals(cn);

}

該代碼段具有計(jì)算來自CN的主機(jī)名驗(yàn)證、通配符使用處理、CN與主機(jī)通配符忽略處理功能。其方法是計(jì)算參數(shù)parts的數(shù)字部分減去2的前綴長度，域名第一部分有效性什么也不操作而其就不具有邏輯性。如，如果證書名是 a*.＜b＞.＜b＞.com，它將拒絕 ail.＜b＞.＜b＞.com。而且最初的補(bǔ)丁及其衍生代碼在解析IPv4地址通用表達(dá)式中有一個小缺陷，使其接受從0開始的IP地址，但這并不會立即導(dǎo)致安全漏洞。

5 結(jié)論

通過對具有代表性的中間件應(yīng)用程序使用SSL用于安全連接的情況分析，特別對中間件庫使用SSL作為多層軟件協(xié)議棧的一部分功能分析，發(fā)現(xiàn)程序在具有潛在不安全的公用網(wǎng)絡(luò)中傳輸極其敏感的數(shù)據(jù)時，非常重要的一點(diǎn)就是必須正確使用SSL。

同時通過對SSL在應(yīng)用程序軟件設(shè)計(jì)中的使用，詳細(xì)說明了依賴標(biāo)準(zhǔn)SSL庫的應(yīng)用程序(如JSSE、OpenSSL等)執(zhí)行SSL證書認(rèn)證可能存在的不安全因素，這些不安全性在有些軟件中是隨處可見的，如FPS、PayPal、EC2以及其他客戶端遠(yuǎn)程管理云存儲和云基礎(chǔ)設(shè)施等。這些特點(diǎn)對中間件攻擊來講，SSL連接是沒有安全性的。

另外，對于一些宣稱是更加安全的SSL策略，通過分析發(fā)現(xiàn)，可以通過開發(fā)代碼分析工具發(fā)現(xiàn)SSL連接建立邏輯錯誤問題。對于這類情況，可以通過形式驗(yàn)證技術(shù)設(shè)計(jì)和編程，支持自動檢查應(yīng)用程序是否正確使用SSL庫，而不誤解關(guān)鍵選項(xiàng)和參數(shù)的定義，以此來設(shè)計(jì)更好的API用于SSL或其他安全的網(wǎng)絡(luò)協(xié)議，從而解決其不安全隱患等。

［1］舒劍.一種無證書認(rèn)證密鑰協(xié)商協(xié)議的分析與改進(jìn)［J］.計(jì)算機(jī)應(yīng)用研究，2012，29(1):294-296.

［2］張延紅，陳明.標(biāo)準(zhǔn)模型下強(qiáng)安全的無證書認(rèn)證密鑰協(xié)商協(xié)議［J］.四川大學(xué)學(xué)報(bào):工程科學(xué)版，2013，45(1):125-132.

［3］ HTTP over TLS［EB/OL］.(2000-05-01)［2014-03-10］.http://www.ietf.org/rfc/rfc2818.txt.

［4］Internet X.509 public key infrastructure certificate and certificate revocation list(CRL)profile［EB/OL］.(2008-05-01)［2014-03-10］.http://tools.ietf.org/html/rfc5280.

［5］何 旭.一種可擴(kuò)展Web模型安全機(jī)制［J］.計(jì)算機(jī)系統(tǒng)應(yīng)用，2012，21(8):89-93.

［6］何旭.隱私模式瀏覽器的安全性分析［J］.西華大學(xué)學(xué)報(bào):自然科學(xué)版，2012，31(3):17-22.

［7］ The Secure Sockets Layer(SSL)protocol version 3.0［EB/OL］.(2011-08-01)［2014-03-11］.http://tools.ietf.org/html/rfc6101.

［8］ Representation and verification of domain-based application service identity within Internet public key infrastructure using X.509(PKIX)certificates in the context of Transport Layer Security(TLS)［EB/OL］.(2011-03-01)［2014-03-11］.http://tools.ietf.org/html/rfc6125.

［9］ https should check CN of x509 cert［EB/OL］.(2007-04-22)［2014-03-12］.https://issues.apache.org/jira/browse/HTTPCLIENT-613.

［10］ Internet X.509 public key infrastructure certificate policy and certification practices framework［EB/OL］.(1999-03-01)［2014-03-11］.http://www.ietf.org/rfc/rfc2527.txt.

［11］ Viega J，Messier M.Secure programming cookbook for C and C++［M］.California:O'Reilly Media，2003.

［12］ Moxie M.IE SSL vulnerability［EB/OL］.(2002-05-08)［2014-03-12］.http://www.thoughtcrime.org/ie-ssl-chain.txt.