在閱讀文章之前讀者應該對一些重要概念有一個基本的認識:
http&&ssl:
為了提高網絡傳輸的安全性，一般會在比較敏感的部分采用https傳輸，比 如注冊、登錄、控制臺等。像Gmail、網銀、icloud等則全部采用https傳輸。 https/ssl主要起到兩個作用：認證、內容加密傳輸和數據一致性。經CA簽發的證書才起到認證可信的作用，所有有效證書均可以起到加密傳輸的作用。
數字證書:
主要在互聯網上的用于身份驗證的用途。 安全站點在獲得CA（Certificate Authority數字證書認證機構）認證后，獲得一個數字證書，以此來標識其合法身份的真實性。數字證書主要分為服務器證書和客戶端證書。服務器證書（SSL證書）用來進行身份驗證和通信的加密，客戶端證書主要用于身份驗證和電子簽名。找CA申請證書是要收費的。
以下是正文
許多Android應用都在使用RESTful或其他基于HTTP協議的模式來和服務器進行通信。
在Android系統上使用HTTP是很簡單的,而且文檔也相當完備.在不同的Android系統版本上,HTTPClient和HttpURLConnection都是可以使用的,但是Google官方的建議是在2.3及以上版本使用HttpURLConnection,2.2及更早的版本使用HttpClient。
可是當你需要使用HTTPS的時候,會比使用HTTP稍微麻煩一點.在一個近期的項目中,我們要和一個需要客戶端證書校驗的HTTPS服務器進行通信,并且服務端證書要是自簽名的.這樣就變得有些棘手了,這篇文章接下來的部分就會介紹到我們遇到的一些挑戰。
如果你想直接看代碼的話,可以來這里獲取Github。當然你需要搭建自己的HTTPS服務器并且生成客戶端證書.其中一種方式就是使用Apache mod_ssl module。
在Android上使用HTTP或HTTPS之前,要確保你的應用有訪問網絡的權限,正確姿勢如下(在AndroidManifest.xml文件中添加):
<uses-permission android:name="android.permission.INTERNET"/>
挑戰1:使用客戶端證書
我們的客戶端證書是PKCS 12格式的,文件擴展名為.p12。
為了讓我們的應用能夠拿到證書,我們使用DDMS工具來把證書文件復制到設備SD卡的根目錄下,如果你在使用一臺虛擬機的話,也同樣可以把證書復制到SD卡根目錄下.你也可以通過USB的方式從電腦把證書文件復制到設備SD卡根目錄下。
在我們的最終版應用中,我們會把證書復制到應用特有的存儲空間中(應該是/Android/data/package name這個目錄下),之后把SD卡根目錄下的原始證書刪除掉。
使用客戶端證書的關鍵之處是創建一個包含證書的KeyStore,然后使用這個KeyStore創建一個自定義的SSLContext。
當我們拿到了包含客戶端證書和證書密碼的文件引用的時候,我們把它加載到一個合適的KeyStore中。(這里可以參考一下示例源碼中的SSLContextFactory.java):
keyStore = KeyStore.getInstance("PKCS12");
fis = new FileInputStream(certificateFile);
keyStore.load(fis, clientCertPassword.toCharArray());
現在我們已經擁有了包含客戶端證書的KeyStore,我們可以使用它來構建一個SSLContext:
KeyManagerFactory kmf = KeyManagerFactory.getInstance("X509");
kmf.init(keyStore, clientCertPassword.toCharArray());
KeyManager[] keyManagers = kmf.getKeyManagers();
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(keyManagers, null, null);
這個SSLContext可以應用在HTTPUrlConnection的方式與服務端連接的過程中用到:
String result = null;
HttpURLConnection urlConnection =null;
try {
URL requestedUrl = new URL(url);
urlConnection = (HttpURLConnection)requestedUrl.openConnection();
if(urlConnection instanceof HttpsURLConnection) {
((HttpsURLConnection)urlConnection).setSSLSocketFactory(sslContext.getSocketFactory());
}
urlConnection.setRequestMethod("GET");
urlConnection.setConnectTimeout(1500);
urlConnection.setReadTimeout(1500);
lastResponseCode = urlConnection.getResponseCode();
result = IOUtil.readFully(urlConnection.getInputStream());
lastContentType = urlConnection.getContentType();
} catch (Exception ex) {
result = ex.toString();
} finally {
if (urlConnection != null) {
urlConnection.disconnect();
}
}
挑戰2:如何確保自簽名證書[譯注2]是可信任的。
現在我們有了可以和HTTPS服務器通過證書連接的客戶端代碼了。同時持有著客戶端證書,可是這只在服務端的證書是可信任的情況下才有用。實際上,這意味著服務端的證書必須被至少一個主流的認證機構所認證,例如VeriSign,Thawte,Geotrust,Comodo等. CA(Certificate Authority數字證書認證機構) 認證過的證書都是可以在手機上預置進去的。
但我們的證書是自簽名的,這意味著SSLContext中默認的TrustManager是不會信任服務端證書的,并且也無法達成SSL連接。
如果你嘗試著在網絡上搜索如何實現自信任證書的HTTPS連接,可能會得到很多錯誤的建議,絕大多數的答案都是教給開發者直接信任任何證書就可以了。這當然算是一個誤導了,也是不安全的,因為這樣做會有被中間人攻擊[譯注1]的風險。
我們真正想做的是創建一個自定義的TrustManager,這個TrustManager可以信任我們的自簽名證書,并且能被我們的自定義SSLContext使用.因此我們需要一份服務端證書鏈的副本,這個副本必須包括CA的自簽名證書,至少也是CA簽署的中級證書。如果你正常地導出服務器的證書,你會得到一個文件,這個文件包含有三個證書- CA認證的證書,中級證書和服務器的證書。這是OK的,額外的證書不是必須的,但也不會有壞處(可以參見下面的挑戰#3)。
信任自簽名的服務端證書的方式和提供客戶端證書的方式是很相近的.我們把證書裝載到KeyStore中,使用KeyStore來生成一個TrustManger的數組,然后使用這些TrustManager來創建SSLContext。
在我們的app中,我們把服務端證書放到資源文件下(猜測應該是asset目錄下,因為證書對于每一個用戶來說都是相同的,并且也不會經常發生改變),但是也可以放在設備的外部存儲上。
下面是加載服務端證書鏈到keystore的代碼:
byte[] der = loadPemCertificate(new ByteArrayInputStream(certificateString.getBytes()));
ByteArrayInputStream derInputStream = new ByteArrayInputStream(der);
CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate) certificateFactory.generateCertificate(derInputStream);
String alias = cert.getSubjectX500Principal().getName();
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
trustStore.load(null);
trustStore.setCertificateEntry(alias, cert);
既然我們有了可信任并帶有服務端證書的keystore,就可以用它來初始化SSLContext,
基于我們之前的代碼,現在生成SSLContext的代碼變成了如下:
KeyManagerFactory kmf = KeyManagerFactory.getInstance("X509");
kmf.init(keyStore, clientCertPassword.toCharArray());
KeyManager[] keyManagers = kmf.getKeyManagers();
TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509");
tmf.init(trustStore);<br>TrustManager[] trustManagers = tmf.getTrustManagers();
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(keyManagers, trustManagers, null);
現在,我們可以安全的連接到服務端了,而且只信任我們自己的服務端證書,持有我們的客戶端證書。如果一切順利的話,你已經成功了,可以不用繼續讀下去了。
挑戰3:處理順序不正確的服務端證書鏈
事實證明,一些apache mod_ssl 安裝配置(或者其他的SSL提供者),
無論是bug還是錯誤配置,都會導致服務端證書順序出現錯誤。
為了保持正常工作,服務端證書鏈中的證書都要以root開頭,或者 CA certificate其次是中級證書,如果服務端證書也被包含進來,一定要放到最后一個,鏈中的每個證書(除了root開頭的)都必須在用來簽名的證書之前。
在我們的項目實際情況下,一個被錯誤配置的服務器會生成一個證書鏈,這個證書鏈以服務端的證書開頭,接下來是根證書,然后是中級證書,這會導致SSL手失敗。
這種情況下最簡單的做法就是:如果可以的話,把服務端證書鏈的順序調整好,
如果不能,亂序的證書鏈只能在客戶端處理了。
在我們的android app中,我們通過實現一個自定義的X509TrustManager來讓證書鏈重新排序。
X509TrustManager的代碼太長了,沒辦法完全展示到這里,但是當我們實現了它之后,就可以在SSLContext初始化的過程中,通過這個自定義實現來替換’trustStores’的數組。
KeyManagerFactory kmf = KeyManagerFactory.getInstance("X509");
kmf.init(keyStore, clientCertPassword.toCharArray());
KeyManager[] keyManagers = kmf.getKeyManagers();
TrustManager[] trustManagers = { new CustomTrustManager(trustStore)};
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(keyManagers, trustManagers,null);
只要加載我們自己的證書到keystore和 Truststore中,并且對服務端證書鏈進行重新排序的方式,我們就能夠創建一個通過客戶端證書連接到SSL服務器的SSLContext,即使證書鏈的書序是錯誤的并且是自簽名的。
譯注:
[1]中間人攻擊(Man-in-the-middle attack)
是指攻擊者與通訊的兩端分別創建獨立的聯系，并交換其所收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話并插入新的內容。在許多情況下這是很簡單的。
[2]自簽名證書(self-signed certificate)
非CA頒發的證書，通過自簽名的方式得到的證書。例如在Web上,瀏覽器會顯示一個對話框，詢問您是否希望信任一個自簽名證書。這個是不用花錢的。
由于公司有這方面的需求,查了很多資料,找到了一篇很好的文章,所以試著翻譯了一下,這是一篇譯文,并非原創!!!并非原創!!!并非原創!!!也沒有100%照著原文翻譯的,增加了一些標注解釋和自己的理解,翻譯的很爛,求噴,謝謝。
原文作者 : Rich Freedman
文章出處 : HTTPS with Client Certificates on Android
示例程序 : android-ssl
其他可以參考的資料:
http://developer.android.com/intl/zh-cn/training/articles/security-ssl.html
https://www.zhihu.com/question/31872273
http://www.open-open.com/lib/view/open1413071600531.html#6734290-tsina-1-33379-8c2b59db2c0455f25f549fc37e66faa9
http://blog.csdn.net/logo616/article/details/12983395
