在網路上傳輸敏感資訊時,通常會使用 HTTPS 協定,讓客戶端與伺服器端對資料進行 SSL 加密處理,以降低資料在傳輸過程中被監聽或中間人攻擊的風險。HTTPS 的重要性逐漸被重視,Google 除了預設開啟 HTTPS 之外,未來更會將 HTTPS 的網站搜尋排名加分。但為了確保傳輸的安全,過程中客戶端會核對伺服器的憑證鏈 (certificate chain) 是否有效,若判定為無效時會作出警告。(詳見Wikipedia)
而在手機應用程式上 HTTPS 同樣重要,例如網路銀行、線上購物等。系統同樣會做憑證核對,但對被判定為無效的憑證就需要開發者作出額外的處理了。許多手機應用程式開發商在這個部分並沒有妥善處理好,以下我們就幾個常見的成因做基本的探討。
會被系統判定為無效的常見成因?
在探討該如何處理這個問題之前,這裡先列出一些有可能被系統判定成無效憑證的成因。
1. 系統支援問題 1
在 Android 2.2 及之前的版本,對 SSL 的支援上存在著一些問題,像是 SNI 和 Multiple Chain。而 Android 上不接受缺少中繼 CA 憑證的憑證鏈,例如:https://egov.uscis.gov/
2. 相關憑證未被預載到系統中
以 GCA 簽發的 SSL 憑證為例,在 Windows 上被判定為有效,但在 iOS 系統上卻因為 CA 不在系統的預載清單中而被判定為無效。
3. 使用自行簽發的憑證
這種情況常出現在應用程式開發階段的內部測試環境中,由於是內部測試環境一般都不會花錢去申請憑證。
4. 連線被中間人(MITM)攻擊
當連線被 MITM 攻擊時,使用者原本的連線目的地會被導到攻擊者的設備上,此時伺服器憑證也會被取代成攻擊者自行簽發的憑證,造成原本正常的連線出現異常。
開發者該如何處理?
理想情況下,客戶端的支援度充足,伺服器憑證鏈的來源及設定正確,只需使用系統原有的方式去檢查憑證即可達到安全效果。但若非得要相容低版本系統或是自行簽發憑證的時候,就得自行做額外的檢查。
在處理方式上,普遍是使用憑證綁定 (certificate pinning) 的方式,把需要比對的憑證預先存放在應用程式裡,待要進行 SSL Handshake 的時候再與伺服器的憑證做比對。
可是在實務上,大多開發人員採用消極的方法,把錯誤警告略過讓連線繼續進行,使得本來使用 SSL 加密連線帶來的安全性形同虛設。據 2012 年 Why Eve and Mallory Love Android: An Analysis of SSL (In)Security on Android 這篇論文指出,在 Google Play 上 13500 個免費熱門應用程式當中,共有 1074 個 (8%) 應用程式因錯誤的 SSL 處理而導致使用者陷入 MITM 攻擊的風險中。
下面我們整理了一些在手機應用開發上,常見的 SSL 處理錯誤,以及其對應適當的處理方法。
Android 錯誤處理情況1
1 @Override
2 public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
3 handler.proceed();
4 }
當透過 WebView 元件訪問 HTTPS 網站發生 SSL 錯誤時,會觸發 onReceivedSslError 這個函數。根據官方文件指出,可藉由執行 handler.proceed() 或是 handler.cancel() 來決定是否讓連線繼續進行。在不覆寫這函數的情況下預設會執行 handler.cancel()。而上面的做法卻讓異常的連線繼續進行了。
較為恰當的做法是使用 handler.cancel() 讓連線終止,或是限制在開發階段才執行 handler.proceed()。像 Apache Coradova 和 Facebook Android SDK 皆有對這部分做控管。
Android 錯誤處理情況2
1 TrustManager[] trustAllManager = new TrustManager[] { new X509TrustManager() {
2 @Override
3 public void checkClientTrusted(X509Certificate[] chain, String authType) {
4 }
5
6 @Override
7 public void checkServerTrusted(X509Certificate[] chain, String authType) {
8 }
9
10 @Override
11 public X509Certificate[] getAcceptedIssuers() {
12 return null;
13 }
14 } };
15
16 SSLContext sslContext = SSLContext.getInstance("TLS");
17 sslContext.init(null, trustAllManager, null);
本用來檢查伺服器憑證的 checkServerTrusted 被留空,導致警告被略過。Google 建議不要自行實作 TrustManager,而是把憑證放到 KeyStore,再把 KeyStore 放到 TrustManagerFactory,最後從 TrustManagerFactory 產出相關的 TrustManager,開發文件中有提供處理的範例。OWASP 的 WIKI 上也有提供自行實作 TrustManager 做 certificate pinning 的範例。2
下面節錄 Android 官方文件上的範例:
1 KeyStore keyStore = ...;
2 String algorithm = TrustManagerFactory.getDefaultAlgorithm();
3 TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm);
4 tmf.init(keyStore);
5
6 SSLContext context = SSLContext.getInstance("TLS");
7 context.init(null, tmf.getTrustManagers(), null);
8
9 URL url = new URL("https://www.example.com/");
10 HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
11 urlConnection.setSSLSocketFactory(context.getSocketFactory());
12 InputStream in = urlConnection.getInputStream();
Android 錯誤處理情況3
1 URL url = new URL("https://www.example.com/");
2 HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
3 conn.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
或是
1 HostnameVerifier allHostVerifier = new HostnameVerifier() {
2 @Override
3 public boolean verify(String hostname, SSLSession session) {
4 return true;
5 }
6 };
上述寫法略過了憑證中的 hostname 檢查,導致即使連線端與憑證中指定的 hostname 不一致也能通過。較為恰當的做法是不特別設定,讓他使用預設的 DefaultHostnameVerifier,或是採用更為嚴謹的 StrictHostnameVerifier。
iOS 錯誤處理情況1
1 @implementation NSURLRequest (IgnoreSSL)
2 + (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host
3 {
4 return YES;
5 }
6 @end
此情況使用到 Framework 中的 Private API,雖然這種寫法會因為不能通過 Apple 的審查而不會出現在 AppStore 上(使用回避技巧不在這討論範圍內),但仍有機會在無需經過 Apple 審查的 Enterprise App 中使用。較為適當的做法是用 “#if DEBUG”,”#endif” 包起來以確保該段程式在編譯時只能對開發中的 debug 版上有作用。
iOS 錯誤處理情況2
1 - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
2 return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust];
3 }
4
5 - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
6 if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust])
7 [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
8
9 [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];
10 }
上面的做法會讓使用 NSURLConnection 的連線略過憑證檢查,容許任意憑證通過。下面節錄 OWASP WIKI 上的範例:
1 - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:
2 (NSURLAuthenticationChallenge *)challenge
3 {
4 if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust])
5 {
6 do
7 {
8 SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
9 if(nil == serverTrust)
10 break; /* failed */
11
12 OSStatus status = SecTrustEvaluate(serverTrust, NULL);
13 if(!(errSecSuccess == status))
14 break; /* failed */
15
16 SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0);
17 if(nil == serverCertificate)
18 break; /* failed */
19
20 CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate);
21 [(id)serverCertificateData autorelease];
22 if(nil == serverCertificateData)
23 break; /* failed */
24
25 const UInt8* const data = CFDataGetBytePtr(serverCertificateData);
26 const CFIndex size = CFDataGetLength(serverCertificateData);
27 NSData* cert1 = [NSData dataWithBytes:data length:(NSUInteger)size];
28
29 NSString *file = [[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"];
30 NSData* cert2 = [NSData dataWithContentsOfFile:file];
31
32 if(nil == cert1 || nil == cert2)
33 break; /* failed */
34
35 const BOOL equal = [cert1 isEqualToData:cert2];
36 if(!equal)
37 break; /* failed */
38
39 // The only good exit point
40 return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust]
41 forAuthenticationChallenge: challenge];
42 } while(0);
43 }
44
45 // Bad dog
46 return [[challenge sender] cancelAuthenticationChallenge: challenge];
47 }
處理方式與前面的 Android 情況2類同,做了 certificate pinning。
iOS 錯誤處理情況3
1 - (void) URLSession:(NSURLSession *)session
2 didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
3 completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition,
4 NSURLCredential *credential))completionHandler
5 {
6 NSURLProtectionSpace * protectionSpace = challenge.protectionSpace;
7 if ([protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
8 SecTrustRef serverTrust = protectionSpace.serverTrust;
9 completionHandler(NSURLSessionAuthChallengeUseCredential, [NSURLCredential credentialForTrust: serverTrust]);
10 } else {
11 completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
12 }
13 }
與前面 NSURLConnection 的情況類同,只是這裡使用到的是 iOS7 新增的 NSURLSession 元件。對應的處理方式如下:
1 - (void) URLSession:(NSURLSession *)session
2 didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
3 completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition,
4 NSURLCredential *credential))completionHandler
5 {
6 if ([[[challenge protectionSpace] authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust]) {
7 SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
8 if (serverTrust != NULL) {
9 OSStatus status = SecTrustEvaluate(serverTrust, NULL);
10 if(!(errSecSuccess == status)) {
11 completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil);
12 return;
13 }
14
15 NSData *localCertData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle]
16 pathForResource:@"random-org"
17 ofType:@"der"]];
18
19 SecCertificateRef remoteServerCert = SecTrustGetCertificateAtIndex(serverTrust, 0);
20 CFDataRef remoteCertData = SecCertificateCopyData(remoteServerCert);
21 BOOL isMatch = [localCertData isEqualToData: (__bridge NSData *)remoteCertData];
22 CFRelease(remoteCertData);
23
24 if (isMatch) {
25 completionHandler(NSURLSessionAuthChallengeUseCredential, [NSURLCredential credentialForTrust:serverTrust]);
26 } else {
27 completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil);
28 }
29 }
30 } else {
31 completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
32 }
33 }
對 WebView 的一些補充
在對 WebView 做處理上,除了對 SSL 錯誤直接略過外,目前無論是在 Android 還是 iOS 上,SDK API 都尚未直接提供方法讓開發者能在 SSL Handshake 的途中作 Server Certificate Pinning。其中一個替代方法是,利用其他能夠作 Pinning 的元件將資料下載回來,接著把資料傳到 WebView 進行讀取,避開原本用 WebView 直接設定連線網址。蘋果公司有提供這種處理的範例。
結語
本來為了提高安全性而使用的 SSL 加密連線,卻由於程式處理不當讓原來的保護形同虛設。觀念不足與為節省時間而沒做好處理相信是主要原因。網路上大量的文章在引指開發者略過錯誤警告的時候,卻沒有提醒他們這樣做帶來的影響,也助長了不當處理的發生。
除了 SSL 處理問題外,手機應用程式開發還有許多要注意的安全問題,像是 OWASP 列出的 Top 10 Mobile Risks、由日本智慧型手機安全協會發佈 Android Application Secure Design/Secure Coding Guidebook 裡面所建議的。開發商有責任做好安全把關以保障雙方權益。
參考
- Rethinking SSL Development in an Appified World
- Unifying Key Store Access in ICS | Android Developers Blog
- The CommonsBlog — SSL on Android: The Basics
- Security with HTTPS and SSL | Android Developers
- Networking Programming Topics: Overriding TLS Chain Validation Correctly
- Technical Note TN2232: HTTPS Server Trust Evaluation
- Certificate and Public Key Pinning - OWASP