Android 使用HTTPS與SSL

編寫(xiě):craftsmanBai - http://z1ng.net - 原文: http://developer.android.com/training/articles/security-ssl.html

SSL，安全套接層(TSL)，是一個(gè)常見(jiàn)的用來(lái)加密客戶(hù)端和服務(wù)器通信的模塊。 但是應(yīng)用程序錯(cuò)誤地使用SSL可能會(huì)導(dǎo)致應(yīng)用程序的數(shù)據(jù)在網(wǎng)絡(luò)中被惡意攻擊者攔截。為了確保這種情況不在我們的應(yīng)用中發(fā)生，這篇文章主要說(shuō)明使用網(wǎng)絡(luò)安全協(xié)議常見(jiàn)的陷阱和使用Public-Key Infrastructure(PKI)時(shí)一些值得關(guān)注的問(wèn)題。

概念

一個(gè)典型的SSL使用場(chǎng)景是，服務(wù)器配置中包含了一個(gè)證書(shū)，有匹配的公鑰和私鑰。作為SSL客戶(hù)端和服務(wù)端握手的一部分，服務(wù)端通過(guò)使用public-key cryptography(公鑰加密算法)進(jìn)行證書(shū)簽名來(lái)證明它有私鑰。

然而，任何人都可以生成他們自己的證書(shū)和私鑰，因此一次簡(jiǎn)單的握手不能證明服務(wù)端具有匹配證書(shū)公鑰的私鑰。一種解決這個(gè)問(wèn)題的方法是讓客戶(hù)端擁有一套或者更多可信賴(lài)的證書(shū)。如果服務(wù)端提供的證書(shū)不在其中，那么它將不能得到客戶(hù)端的信任。

這種簡(jiǎn)單的方法有一些缺陷。服務(wù)端應(yīng)該根據(jù)時(shí)間升級(jí)到強(qiáng)壯的密鑰(key rotation)，更新證書(shū)中的公鑰。不幸的是，現(xiàn)在客戶(hù)端應(yīng)用需要根據(jù)服務(wù)端配置的變化來(lái)進(jìn)行更新。如果服務(wù)端不在應(yīng)用程序開(kāi)發(fā)者的控制下，問(wèn)題將變得更加麻煩，比如它是一個(gè)第三方網(wǎng)絡(luò)服務(wù)。如果程序需要和任意的服務(wù)器進(jìn)行對(duì)話(huà)，例如web瀏覽器或者email應(yīng)用，這種方法也會(huì)帶來(lái)問(wèn)題。

為了解決這個(gè)問(wèn)題，服務(wù)端通常配置了知名的的發(fā)行者證書(shū)(稱(chēng)為Certificate Authorities(CAs)。提供的平臺(tái)通常包含了一系列知名可信賴(lài)的CAs。Android4.2(Jelly Bean)包含了超過(guò)100CAs并在每個(gè)發(fā)行版中更新。和服務(wù)端相似的是，一個(gè)CA擁有一個(gè)證書(shū)和一個(gè)私鑰。當(dāng)為一個(gè)服務(wù)端發(fā)布頒發(fā)證書(shū)的時(shí)候，CA用它的私鑰為服務(wù)端簽名?？蛻?hù)端可以通過(guò)服務(wù)端擁有被已知平臺(tái)CA簽名的證書(shū)來(lái)確認(rèn)服務(wù)端。

然而，使用CAs又帶來(lái)了其他的問(wèn)題。因?yàn)镃A為許多服務(wù)端證書(shū)簽名，你仍然需要其他的方法來(lái)確保你對(duì)話(huà)的是你想要的服務(wù)器。為了解決這個(gè)問(wèn)題，使用CA簽名的的證書(shū)通過(guò)特殊的名字如 gmail.com 或者帶有通配符的域名如 *.google.com 來(lái)確認(rèn)服務(wù)端。 下面這個(gè)例子會(huì)使這些概念具體化一些。openssl工具的客戶(hù)端命令關(guān)注Wikipedia服務(wù)端證書(shū)信息。端口為443（默認(rèn)為HTTPS）。這條命令將open s_client的輸出發(fā)送給openssl x509，根據(jù)X.509 standard格式化證書(shū)中的內(nèi)容。特別的是，這條命令需要對(duì)象（subject），包含服務(wù)端名字和簽發(fā)者（issuer）來(lái)確認(rèn)CA。

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

可以看到由RapidSSL CA頒發(fā)給匹配*.wikipedia.org的服務(wù)端證書(shū)。

一個(gè)HTTP的例子

假設(shè)我們有一個(gè)知名CA頒發(fā)證書(shū)的web服務(wù)器，那么可以使用下面的代碼發(fā)送一個(gè)安全請(qǐng)求:

URL url = new URL("https://wikipedia.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

是的，它就是這么簡(jiǎn)單。如果我們想要修改HTTP的請(qǐng)求，可以把它交付給 HttpURLConnection。Android關(guān)于HttpURLConnetcion文檔中還有更貼切的關(guān)于怎樣去處理請(qǐng)求、響應(yīng)頭、posting的內(nèi)容、cookies管理、使用代理、獲取responses等例子。但是就這些確認(rèn)證書(shū)和域名的細(xì)節(jié)而言，Android框架已經(jīng)通過(guò)API為我們考慮到了這些細(xì)節(jié)。下面是其他需要關(guān)注的問(wèn)題。

服務(wù)器普通問(wèn)題的驗(yàn)證

假設(shè)沒(méi)有從getInputStream()收到內(nèi)容，而是拋出了一個(gè)異常：

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
        at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
        at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

這種情況發(fā)生的原因包括：

1.頒布證書(shū)給服務(wù)器的CA不是知名的。

2.服務(wù)器證書(shū)不是CA簽名的而是自己簽名的。

3.服務(wù)器配置缺失了中間CA

下面將會(huì)分別討論當(dāng)我們和服務(wù)器安全連接時(shí)如何去解決這些問(wèn)題。

無(wú)法識(shí)別證書(shū)機(jī)構(gòu)

在這種情況中，SSLHandshakeException異常產(chǎn)生的原因是我們有一個(gè)不被系統(tǒng)信任的CA?？赡苁俏覀兊淖C書(shū)來(lái)源于新CA而不被安卓信任，也可能是應(yīng)用運(yùn)行版本較老沒(méi)有CA。更多的時(shí)候，一個(gè)CA不知名是因?yàn)樗皇枪_(kāi)的CA，而是政府，公司，教育機(jī)構(gòu)等組織私有的。

幸運(yùn)的是，我們可以讓HttpsURLConnection學(xué)會(huì)信任特殊的CA。過(guò)程可能會(huì)讓人感到有一些費(fèi)解，下面這個(gè)例子是從InputStream中獲得特殊的CA，使用它去創(chuàng)建一個(gè)密鑰庫(kù)，用來(lái)創(chuàng)建和初始化TrustManager。TrustManager是系統(tǒng)用來(lái)驗(yàn)證服務(wù)器證書(shū)的，這些證書(shū)通過(guò)使用TrustManager信任的CA和密鑰庫(kù)中的密鑰創(chuàng)建。 給定一個(gè)新的TrustManager，下面這個(gè)例子初始化了一個(gè)新的SSLContext，提供了一個(gè)SSLSocketFactory，我們可以覆蓋來(lái)自HttpsURLConnection的默認(rèn)SSLSocketFactory。這樣連接時(shí)會(huì)使用我們的CA來(lái)進(jìn)行證書(shū)驗(yàn)證。

下面是一個(gè)華盛頓的大學(xué)的組織性的CA的使用例子

// Load CAs from an InputStream
// (could be from a resource or ByteArrayInputStream or ...)
CertificateFactory cf = CertificateFactory.getInstance("X.509");
// From https://www.washington.edu/itconnect/security/ca/load-der.crt
InputStream caInput = new BufferedInputStream(new FileInputStream("load-der.crt"));
Certificate ca;
try {
    ca = cf.generateCertificate(caInput);
    System.out.println("ca=" + ((X509Certificate) ca).getSubjectDN());
} finally {
    caInput.close();
}

// Create a KeyStore containing our trusted CAs
String keyStoreType = KeyStore.getDefaultType();
KeyStore keyStore = KeyStore.getInstance(keyStoreType);
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);

// Create a TrustManager that trusts the CAs in our KeyStore
String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
tmf.init(keyStore);

// Create an SSLContext that uses our TrustManager
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, tmf.getTrustManagers(), null);

// Tell the URLConnection to use a SocketFactory from our SSLContext
URL url = new URL("https://certs.cac.washington.edu/CAtest/");
HttpsURLConnection urlConnection =
    (HttpsURLConnection)url.openConnection();
urlConnection.setSSLSocketFactory(context.getSocketFactory());
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

使用一個(gè)常用的了解你CA的TrustManager，系統(tǒng)可以確認(rèn)你的服務(wù)器證書(shū)來(lái)自于一個(gè)可信任的發(fā)行者。

注意：許多網(wǎng)站會(huì)提供一個(gè)可選解決方案：即讓用戶(hù)安裝一個(gè)無(wú)用的TrustManager。如果你這樣做還不如不加密通訊過(guò)程，因?yàn)槿魏稳硕伎梢栽诠瞱ifi熱點(diǎn)下，使用偽裝成你的服務(wù)器的代理發(fā)送你的用戶(hù)流量，進(jìn)行DNS欺騙，來(lái)攻擊你的用戶(hù)。然后攻擊者便可記錄用戶(hù)密碼和其他個(gè)人資料。這種方式可以奏效的原因是因?yàn)楣粽呖梢陨梢粋€(gè)證書(shū)，并且缺少可以驗(yàn)證該證書(shū)是否來(lái)自受信任的來(lái)源的TrustManager。你的應(yīng)用可以同任何人會(huì)話(huà)。所以不要這樣做，即使是暫時(shí)性的也不行。除非你能始終讓你的應(yīng)用信任服務(wù)器證書(shū)的簽發(fā)者。

自簽名服務(wù)器證書(shū)

第二種SSLHandshakeException取決于自簽名證書(shū)，意味著服務(wù)器就是它自己的CA。這同未知證書(shū)權(quán)威機(jī)構(gòu)類(lèi)似，因此你同樣可以用前面部分中提到的方法。

你可以創(chuàng)建自己的TrustManager，這一次直接信任服務(wù)器證書(shū)。將應(yīng)用于證書(shū)直接捆綁會(huì)有一些缺點(diǎn)，不過(guò)我們依然可以確保其安全性。我們應(yīng)該小心確保我們的自簽名證書(shū)擁有合適的強(qiáng)密鑰。到2012年，一個(gè)65537指數(shù)位且一年到期的2048位RSA簽名是合理的。當(dāng)輪換密鑰時(shí)，我們應(yīng)該查看權(quán)威機(jī)構(gòu)（比如NIST）的建議（recommendation）來(lái)了解哪種密鑰是合適的。

缺少中間證書(shū)頒發(fā)機(jī)構(gòu)

第三種SSLHandshakeException情況的產(chǎn)生于缺少中間CA。大多數(shù)公開(kāi)的CA不直接給服務(wù)器簽名。相反，他們使用它們主要的機(jī)構(gòu)（簡(jiǎn)稱(chēng)根認(rèn)證機(jī)構(gòu)）證書(shū)來(lái)給中間認(rèn)證機(jī)構(gòu)簽名，根認(rèn)證機(jī)構(gòu)這樣做，可以離線(xiàn)存儲(chǔ)減少危險(xiǎn)。然而，像安卓等操作系統(tǒng)通常只直接信任根認(rèn)證機(jī)構(gòu)，在服務(wù)器證書(shū)（由中間證書(shū)頒發(fā)機(jī)構(gòu)簽名）和證書(shū)驗(yàn)證者（只知道根認(rèn)證機(jī)構(gòu)）之間留下了一個(gè)缺口。為了解決這個(gè)問(wèn)題，服務(wù)器并不在SSL握手的過(guò)程中只向客戶(hù)端發(fā)送它的證書(shū)，而是一系列的從服務(wù)器到必經(jīng)的任何中間機(jī)構(gòu)到達(dá)根認(rèn)證機(jī)構(gòu)的證書(shū)。

下面是一個(gè) mail.google.com證書(shū)鏈，以openssls_client命令顯示：

$ openssl s_client -connect mail.google.com:443
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---

這里顯示了一臺(tái)服務(wù)器發(fā)送了一個(gè)由Thawte SGC CA為mail.google.com頒發(fā)的證書(shū)，Thawte SGC CA是一個(gè)中間證書(shū)頒發(fā)機(jī)構(gòu)，Thawte SGC CA的證書(shū)由被安卓信任的Verisign CA頒發(fā)。 然而，配置一臺(tái)服務(wù)器不包括中間證書(shū)機(jī)構(gòu)是不常見(jiàn)的。例如，一臺(tái)服務(wù)器導(dǎo)致安卓瀏覽器的錯(cuò)誤和應(yīng)用的異常:

$ openssl s_client -connect egov.uscis.gov:443
---
Certificate chain
 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---

更有趣的是，用大多數(shù)桌面瀏覽器訪(fǎng)問(wèn)這臺(tái)服務(wù)器不會(huì)導(dǎo)致類(lèi)似于完全未知CA的或者自簽名的服務(wù)器證書(shū)導(dǎo)致的錯(cuò)誤。這是因?yàn)榇蠖鄶?shù)桌面瀏覽器緩存隨著時(shí)間的推移信任中間證書(shū)機(jī)構(gòu)。一旦瀏覽器訪(fǎng)問(wèn)并且從一個(gè)網(wǎng)站了解到的一個(gè)中間證書(shū)機(jī)構(gòu)，下一次它將不需要中間證書(shū)機(jī)構(gòu)包含證書(shū)鏈。

一些站點(diǎn)會(huì)有意讓用來(lái)提供資源服務(wù)的二級(jí)服務(wù)器像上述所述的那樣。比如，他們可能會(huì)讓他們的主HTML頁(yè)面用一臺(tái)擁有全部證書(shū)鏈的服務(wù)器來(lái)提供，但是像圖片，CSS，或者JavaScript等這樣的資源用不包含CA的服務(wù)器來(lái)提供，以此節(jié)省帶寬。不幸的是，有時(shí)這些服務(wù)器可能會(huì)提供一個(gè)在應(yīng)用中調(diào)用的web服務(wù)。 這里有兩種解決這些問(wèn)題的方法：

• 配置服務(wù)器使它包含服務(wù)器鏈中的中間證書(shū)頒發(fā)機(jī)構(gòu)

• 或者，像對(duì)待不知名的CA一樣對(duì)待中間CA，并且創(chuàng)建一個(gè)TrustManager來(lái)直接信任它，就像在前兩節(jié)中做的那樣。

驗(yàn)證主機(jī)名常見(jiàn)問(wèn)題

就像在文章開(kāi)頭提到的那樣，有兩個(gè)關(guān)鍵的部分來(lái)確認(rèn)SSL的連接。第一個(gè)是確認(rèn)證書(shū)來(lái)源于信任的源，這也是前一個(gè)部分關(guān)注的焦點(diǎn)。這一部分關(guān)注第二部分：確保你當(dāng)前對(duì)話(huà)的服務(wù)器有正確的證書(shū)。當(dāng)情況不是這樣時(shí)，你可能會(huì)看到這樣的典型錯(cuò)誤：

java.io.IOException: Hostname 'example.com' was not verified
        at libcore.net.http.HttpConnection.verifySecureSocketHostname(HttpConnection.java:223)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:446)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

服務(wù)器配置錯(cuò)誤可能會(huì)導(dǎo)致這種情況發(fā)生。服務(wù)器配置了一個(gè)證書(shū)，這個(gè)證書(shū)沒(méi)有匹配的你想連接的服務(wù)器的subject或者subject可選的命名域。一個(gè)證書(shū)被許多不同的服務(wù)器使用是可能的。比如，使用 openssl s_client -connect google.com:443 |openssl x509 -text 查看google證書(shū)，你可以看到一個(gè)subject支持 google.con .youtube.com, *.android.com或者其他的。這種錯(cuò)誤只會(huì)發(fā)生在你所連接的服務(wù)器名稱(chēng)沒(méi)有被證書(shū)列為可接受。

不幸的是另外一種原因也會(huì)導(dǎo)致這種情況發(fā)生：虛擬化服務(wù)。當(dāng)用HTTP同時(shí)擁有一個(gè)以上主機(jī)名的服務(wù)器共享時(shí)，web服務(wù)器可以從 HTTP/1.1請(qǐng)求中找到客戶(hù)端需要的目標(biāo)主機(jī)名。不行的是，使用HTTPS會(huì)使情況變得復(fù)雜，因?yàn)榉?wù)器必須知道在發(fā)現(xiàn)HTTP請(qǐng)求前返回哪一個(gè)證書(shū)。為了解決這個(gè)問(wèn)題，新版本的SSL，特別是TLSV.1.0和之后的版本，支持服務(wù)器名指示(SNI)，允許SSL客戶(hù)端為服務(wù)端指定目標(biāo)主機(jī)名，從而返回正確的證書(shū)。 幸運(yùn)的是，從安卓2.3開(kāi)始，HttpsURLConnection支持SNI。不幸的是，Apache HTTP客戶(hù)端不這樣，這也是我們不鼓勵(lì)用它的原因之一。如果你需要支持安卓2.2或者更老的版本或者Apache HTTP客戶(hù)端，一個(gè)解決方法是建立一個(gè)可選的虛擬化服務(wù)并且使用特別的端口，這樣服務(wù)端就能夠清楚該返回哪一個(gè)證書(shū)。

采用不使用你的虛擬服務(wù)的主機(jī)名HostnameVerifier而不是服務(wù)器默認(rèn)的來(lái)替換，是很重要的選擇。

注意：替換HostnameVerifier可能會(huì)非常危險(xiǎn)，如果另外一個(gè)虛擬服務(wù)不在你的控制下，中間人攻擊可能會(huì)直接使流量到達(dá)另外一臺(tái)服務(wù)器而超出你的預(yù)想。 如果你仍然確定你想覆蓋主機(jī)名驗(yàn)證，這里有一個(gè)為單URLConnection替換驗(yàn)證過(guò)程的例子：

// Create an HostnameVerifier that hardwires the expected hostname.
// Note that is different than the URL's hostname:
// example.com versus example.org
HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String hostname, SSLSession session) {
        HostnameVerifier hv =
            HttpsURLConnection.getDefaultHostnameVerifier();
        return hv.verify("example.com", session);
    }
};

// Tell the URLConnection to use our HostnameVerifier
URL url = new URL("https://example.org/");
HttpsURLConnection urlConnection =
    (HttpsURLConnection)url.openConnection();
urlConnection.setHostnameVerifier(hostnameVerifier);
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

但是請(qǐng)記住，如果你發(fā)現(xiàn)你在替換主機(jī)名驗(yàn)證，特別是虛擬服務(wù)，另外一個(gè)虛擬主機(jī)不在你的控制的情況是非常危險(xiǎn)的，你應(yīng)該找到一個(gè)避免這種問(wèn)題產(chǎn)生的托管管理。

關(guān)于直接使用SSL Socket的警告

到目前為止，這些例子聚焦于使用HttpsURLConnection上。有時(shí)一些應(yīng)用需要讓SSL和HTTP分開(kāi)。舉個(gè)例子，一個(gè)email應(yīng)用可能會(huì)使用SSL的變種，SMTP,POP3,IMAP等。在那些例子中，應(yīng)用程序會(huì)想使用SSLSocket直接連接，與HttpsURLConnection做的方法相似。 這種技術(shù)到目前為止處理了證書(shū)驗(yàn)證問(wèn)題，也應(yīng)用于SSLSocket中。事實(shí)上，當(dāng)使用常規(guī)的TrustManager時(shí)，傳遞給HttpsURLConnection的是SSLSocketFactory。如果你需要一個(gè)帶常規(guī)的SSLSocket的TrustManager，采取下面的步驟使用SSLSocketFactory來(lái)創(chuàng)建你的SSLSocket。

注意： SSLSocket不具有主機(jī)名驗(yàn)證功能。它取決于它自己的主機(jī)名驗(yàn)證，通過(guò)傳入預(yù)期的主機(jī)名調(diào)用getDefaultHostNameVerifier())。進(jìn)一步需要注意的是，當(dāng)發(fā)生錯(cuò)誤時(shí)，HostnameVerifier.verify()不知道拋出異常，而是返回一個(gè)布爾值，你需要進(jìn)一步明確的檢查。 下面是一個(gè)演示的方法。這個(gè)例子演示了當(dāng)它連接gmail.com 443端口并且沒(méi)有SNI支持的時(shí)候，你將會(huì)收到一個(gè)mail.google.com的證書(shū)。你需要確保證書(shū)的確是mail.google.com的。

// Open SSLSocket directly to gmail.com
SocketFactory sf = SSLSocketFactory.getDefault();
SSLSocket socket = (SSLSocket) sf.createSocket("gmail.com", 443);
HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier();
SSLSession s = socket.getSession();

// Verify that the certicate hostname is for mail.google.com
// This is due to lack of SNI support in the current SSLSocket.
if (!hv.verify("mail.google.com", s)) {
    throw new SSLHandshakeException("Expected mail.google.com, "
                                    "found " + s.getPeerPrincipal());
}

// At this point SSLSocket performed certificate verificaiton and
// we have performed hostname verification, so it is safe to proceed.

// ... use socket ...
socket.close();

黑名單

SSL 主要依靠CA來(lái)確認(rèn)證書(shū)來(lái)自正確無(wú)誤服務(wù)器和域名的所有者。少數(shù)情況下，CA被欺騙，或者在Comodo和DigiNotar的例子中，一個(gè)主機(jī)名的證書(shū)被頒發(fā)給了除了服務(wù)器和域名的擁有者之外的人，導(dǎo)致被破壞。

為了減少這種危險(xiǎn)，安卓可以將一些黑名單或者整個(gè)CA列入黑名單。盡管名單是以前是嵌入操作系統(tǒng)的，從安卓4.2開(kāi)始，這個(gè)名單在以后的方案中可以遠(yuǎn)程更新。

阻塞

一個(gè)應(yīng)用可以通過(guò)阻塞技術(shù)保護(hù)它自己免于受虛假證書(shū)的欺騙。這是簡(jiǎn)單運(yùn)用使用未知CA的例子，限制應(yīng)用信任的CA僅來(lái)自被應(yīng)用使用的服務(wù)器。阻止了來(lái)自系統(tǒng)中另外一百多個(gè)CA的欺騙而導(dǎo)致的應(yīng)用安全通道的破壞。

客戶(hù)端驗(yàn)證

這篇文章聚焦在SSL的使用者同服務(wù)器的安全對(duì)話(huà)上。SSL也支持服務(wù)端通過(guò)驗(yàn)證客戶(hù)端的證書(shū)來(lái)確認(rèn)客戶(hù)端的身份。這種技術(shù)也與TrustManager的特性相似?？梢詤⒖荚?a rel="external nofollow" target="_blank" rel="external nofollow" target="_blank" rel="external nofollow" target="_blank" rel="external nofollow" target="_blank" target="_blank">HttpsURLConnection文檔中關(guān)于創(chuàng)建一個(gè)常規(guī)的KeyManager的討論。

nogotofail：網(wǎng)絡(luò)流量安全測(cè)試工具

對(duì)于已知的TLS／SSL漏洞和錯(cuò)誤，nogotofail提供了一個(gè)簡(jiǎn)單的方法來(lái)確認(rèn)你的應(yīng)用程序是安全的。它是一個(gè)自動(dòng)化的、強(qiáng)大的、用于測(cè)試網(wǎng)絡(luò)的安全問(wèn)題可擴(kuò)展性的工具，任何設(shè)備的網(wǎng)絡(luò)流量都可以通過(guò)它。 nogotofail主要應(yīng)用于三種場(chǎng)景：

• 發(fā)現(xiàn)錯(cuò)誤和漏洞。

• 驗(yàn)證修補(bǔ)程序和等待回歸。

• 了解應(yīng)用程序和設(shè)備產(chǎn)生的交通。

nogotofail 可以工作在Android，iOS，Linux，Windows，Chrome OS，OSX環(huán)境下，事實(shí)上任何需要連接到Internet的設(shè)備都可以。Android和Linux環(huán)境下有簡(jiǎn)單易用獲取通知的客戶(hù)端配置設(shè)置，以及本身可以作為靶機(jī)，部署為一個(gè)路由器，VPN服務(wù)器，或代理。 你可以在nogotofail開(kāi)源項(xiàng)目訪(fǎng)問(wèn)該工具。