Android 界面設(shè)計

Android 用戶輸入

Android 后臺任務(wù)

Android 性能優(yōu)化

Android 安全與隱私

Android 測試程序

Android 測試你的Activity

閱讀(2.9k) 書簽贊(0) 我要糾錯

Android 使用HTTPS與SSL

2018-08-02 18:29 更新

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

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

概念

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

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

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

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

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

一個HTTP的例子

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

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

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

服務(wù)器普通問題的驗證

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

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.頒布證書給服務(wù)器的CA不是知名的。

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

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

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

無法識別證書機(jī)構(gòu)

在這種情況中，SSLHandshakeException異常產(chǎn)生的原因是我們有一個不被系統(tǒng)信任的CA。可能是我們的證書來源于新CA而不被安卓信任，也可能是應(yīng)用運行版本較老沒有CA。更多的時候，一個CA不知名是因為它不是公開的CA，而是政府，公司，教育機(jī)構(gòu)等組織私有的。

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

下面是一個華盛頓的大學(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);

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

注意：許多網(wǎng)站會提供一個可選解決方案：即讓用戶安裝一個無用的TrustManager。如果你這樣做還不如不加密通訊過程，因為任何人都可以在公共wifi熱點下，使用偽裝成你的服務(wù)器的代理發(fā)送你的用戶流量，進(jìn)行DNS欺騙，來攻擊你的用戶。然后攻擊者便可記錄用戶密碼和其他個人資料。這種方式可以奏效的原因是因為攻擊者可以生成一個證書，并且缺少可以驗證該證書是否來自受信任的來源的TrustManager。你的應(yīng)用可以同任何人會話。所以不要這樣做，即使是暫時性的也不行。除非你能始終讓你的應(yīng)用信任服務(wù)器證書的簽發(fā)者。

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

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

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

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

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

下面是一個 mail.google.com證書鏈，以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
---

這里顯示了一臺服務(wù)器發(fā)送了一個由Thawte SGC CA為mail.google.com頒發(fā)的證書，Thawte SGC CA是一個中間證書頒發(fā)機(jī)構(gòu)，Thawte SGC CA的證書由被安卓信任的Verisign CA頒發(fā)。然而，配置一臺服務(wù)器不包括中間證書機(jī)構(gòu)是不常見的。例如，一臺服務(wù)器導(dǎo)致安卓瀏覽器的錯誤和應(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ù)桌面瀏覽器訪問這臺服務(wù)器不會導(dǎo)致類似于完全未知CA的或者自簽名的服務(wù)器證書導(dǎo)致的錯誤。這是因為大多數(shù)桌面瀏覽器緩存隨著時間的推移信任中間證書機(jī)構(gòu)。一旦瀏覽器訪問并且從一個網(wǎng)站了解到的一個中間證書機(jī)構(gòu)，下一次它將不需要中間證書機(jī)構(gòu)包含證書鏈。

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

配置服務(wù)器使它包含服務(wù)器鏈中的中間證書頒發(fā)機(jī)構(gòu)
或者，像對待不知名的CA一樣對待中間CA，并且創(chuàng)建一個TrustManager來直接信任它，就像在前兩節(jié)中做的那樣。

驗證主機(jī)名常見問題

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

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

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

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

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

// 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);

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

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

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

注意： SSLSocket不具有主機(jī)名驗證功能。它取決于它自己的主機(jī)名驗證，通過傳入預(yù)期的主機(jī)名調(diào)用getDefaultHostNameVerifier())。進(jìn)一步需要注意的是，當(dāng)發(fā)生錯誤時，HostnameVerifier.verify()不知道拋出異常，而是返回一個布爾值，你需要進(jìn)一步明確的檢查。下面是一個演示的方法。這個例子演示了當(dāng)它連接gmail.com 443端口并且沒有SNI支持的時候，你將會收到一個mail.google.com的證書。你需要確保證書的確是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來確認(rèn)證書來自正確無誤服務(wù)器和域名的所有者。少數(shù)情況下，CA被欺騙，或者在Comodo和DigiNotar的例子中，一個主機(jī)名的證書被頒發(fā)給了除了服務(wù)器和域名的擁有者之外的人，導(dǎo)致被破壞。

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

阻塞

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

客戶端驗證

這篇文章聚焦在SSL的使用者同服務(wù)器的安全對話上。SSL也支持服務(wù)端通過驗證客戶端的證書來確認(rèn)客戶端的身份。這種技術(shù)也與TrustManager的特性相似。可以參考在HttpsURLConnection文檔中關(guān)于創(chuàng)建一個常規(guī)的KeyManager的討論。

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

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

發(fā)現(xiàn)錯誤和漏洞。
驗證修補(bǔ)程序和等待回歸。
了解應(yīng)用程序和設(shè)備產(chǎn)生的交通。

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

以上內(nèi)容是否對您有幫助：

← Android 安全要點

Android 更新你的Security Provider來對抗SSL漏洞利用 →

寫筆記

我要補(bǔ)充