【Using English】28 - Security with HTTPS and SSL

For better format, visit youdao_note_security_with_https

The Secure Sockets Layer (SSL)—now technically known as Transport Layer Security (TLS)—is a common building block for encrypted communications between clients and servers. It's possible that an application might use SSL incorrectly such that malicious entities may be able to intercept an app's data over the network. To help you ensure that this does not happen to your app, this article highlights the common pitfalls when using secure network protocols and addresses some larger concerns about using Public-Key Infrastructure (PKI).

安全鏈路層(SSL, 現在技術上應該叫傳輸層安全)是一種用於客戶端與伺服器端加密通訊的常見的構建區塊。應用程式不當地使用SSL是很有可能的，這會導致一些惡意通過網路來機構擷取應用程式的資料。為了讓你確認這些事情沒有發生在你的APP中，這篇文章將突出講解使用安全網路協議時常見的“坑”以及大聲疾呼大家在使用公鑰基礎設施(PKI)時要特別小心。

You should also read Android Security Overview as well as Permissions Overview.

你也應該閱讀《Android安全概覽》和《許可權概覽》。

Concepts(概念)

In a typical SSL usage scenario, a server is configured with a certificate containing a public key as well as a matching private key. As part of the handshake between an SSL client and server, the server proves it has the private key by signing its certificate with public-key cryptography.

作為一種SSL應用的典型場景，伺服器會配置一個證照，該證照包含了公鑰以及一個匹配的私鑰。作為客戶端與伺服器端SSL連線握手中的一部分，伺服器使用公鑰加密的方式對證照進行簽名來證明自己有私鑰。

However, anyone can generate their own certificate and private key, so a simple handshake doesn't prove anything about the server other than that the server knows the private key that matches the public key of the certificate. One way to solve this problem is to have the client have a set of one or more certificates it trusts. If the certificate is not in the set, the server is not to be trusted.

然而，任何人都可以生成自己的證照和私鑰，所以一次簡單的握手不能證明任何服務端的任何事情，除非服務端知道匹配證照公鑰的私鑰。解決這個問題的一種方式是：設定客戶端信任一個集合的證照，這個證照擁有一個或多個證照。如果那些信任的證照不在伺服器中，那麼該伺服器不被客戶端信任。

There are several downsides to this simple approach. Servers should be able to upgrade to stronger keys over time ("key rotation"), which replaces the public key in the certificate with a new one. Unfortunately, now the client app has to be updated due to what is essentially a server configuration change. This is especially problematic if the server is not under the app developer's control, for example if it is a third party web service. This approach also has issues if the app has to talk to arbitrary servers such as a web browser or email app.

這種簡單的方式有幾個缺點：隨著時間的推移，伺服器應該升級到更強大的金鑰(金鑰轉換)，這個過程需要更換證照中的公鑰。不幸的是,此時客戶端必須更新(證照)，因為本質上這是服務端配置的更改。如果服務端不受客戶端開發者控制，那麼很容易產生問題，例如第三方的web服務。這種策略也會有問題如果App必須訪問任意伺服器比如瀏覽器或者郵件客戶端。

In order to address these downsides, servers are typically configured with certificates from well known issuers called Certificate Authorities (CAs). The host platform generally contains a list of well known CAs that it trusts. As of Android 4.2 (Jelly Bean), Android currently contains over 100 CAs that are updated in each release. Similar to a server, a CA has a certificate and a private key. When issuing a certificate for a server, the CA signsthe server certificate using its private key. The client can then verify that the server has a certificate issued by a CA known to the platform.

為了解決這些缺點，伺服器通常配置來自人們熟知的發行人CA的證照。主機平臺通常包含一個信任CA的列表。比如Android4.2(Jelly Bean), Android目前包含超過100個每次釋出都會更新的證照頒發機構。與伺服器相同，一個證照頒發機構有一個證照和一個私鑰。每當對某一個伺服器髮型一個證照時，證照頒發機構用私鑰給伺服器的證照籤名。客戶端就可以驗證伺服器擁有來自該平臺已知證照頒發機構發行的證照。

However, while solving some problems, using CAs introduces another. Because the CA issues certificates for many servers, you still need some way to make sure you are talking to the server you want. To address this, the certificate issued by the CA identifies the server either with a specific name such as gmail.com or a wildcarded set of hosts such as *.google.com.

但是，在解決一些問題時，使用證照頒發機構會引入其他問題。因為證照頒發機構對很多伺服器都發型證照，你需要分清楚與你通訊的是正確的伺服器。為了解決這個問題，證照頒發機構發行的證照通過特定的名稱(如“gmail.com”)或主機的萬用字元集合(如“*.google.com”)來識別伺服器。

The following example will make these concepts a little more concrete. In the snippet below from a command line, the openssl tool's s_client command looks at Wikipedia's server certificate information. It specifies port 443 because that is the default for HTTPS. The command sends the output of openssl s_client to openssl x509, which formats information about certificates according to the X.509 standard. Specifically, the command asks for the subject, which contains the server name information, and the issuer, which identifies the CA.

下面的例子會讓這些概念更加清晰。下面的命令列程式碼塊片段中，OPENSSL工具s_client命令訪問維基百科伺服器證照資訊。 它指定了埠443，因為443是HTTPS的預設埠。命令將openssl s_client的輸出資訊傳送給openssl x509。openssl x509使用X.509標準格式化證照的資訊。特別地，命令請求了包含伺服器名稱資訊的主題資訊和發行者來區分證照頒發機構。

You can see that the certificate was issued for servers matching *.wikipedia.org by the RapidSSL CA.

可以看出來, RapidSSL 證照頒發機構為匹配*.wikipedia.org的伺服器發行了該證照。

An HTTPS example

Assuming you have a web server with a certificate issued by a well known CA, you can make a secure request with code as simple this:

假設你有一臺伺服器，它配置了知名CA發行的證照。你可以進行一次安全請求用以下的簡單程式碼。

JAVA

Yes, it really can be that simple. If you want to tailor the HTTP request, you can cast to an HttpURLConnection. The Android documentation for HttpURLConnection has further examples about how to deal with request and response headers, posting content, managing cookies, using proxies, caching responses, and so on. But in terms of the details for verifying certificates and hostnames, the Android framework takes care of it for you through these APIs. This is where you want to be if at all possible. That said, below are some other considerations.

是的，它很簡單。如果你想定製HTTP請求，你可以對映到一個HttpURLConnection中。Android關於HttpURLConnection的文件中有更多的事例關於怎樣處理請求和回覆請求頭，傳送內容，管理cookies，使用代理，以及快取響應等。可是涉及到驗證證照和主機名的細節時，Android框架層通過API來為你提供幫助。這就是你想要達成的方向，以下是一些其他要考慮的因素。

Common problems verifying server certificates

Suppose instead of receiving the content from getInputStream(), it throws an exception:

假設沒有接收到內容，而是丟擲一個異常

This can happen for several reasons, including: 有幾個原因導致這個問題：

The CA that issued the server certificate was unknown

證照頒發機構未知。

The server certificate wasn't signed by a CA, but was self signed

伺服器的證照來自與獨自簽名，而非被證照頒發機構簽名。

The server configuration is missing an intermediate CA

伺服器配置缺乏中間證照頒發機構。

The following sections discuss how to address these problems while keeping your connection to the server secure.

以下部分討論如何解決這些問題，同時保持與伺服器連線的安全。

Unknown certificate authority(位置的證照頒發機構)

In this case, the SSLHandshakeException occurs because you have a CA that isn't trusted by the system. It could be because you have a certificate from a new CA that isn't yet trusted by Android or your app is running on an older version without the CA. More often a CA is unknown because it isn't a public CA, but a private one issued by an organization such as a government, corporation, or education institution for their own use.

這種情況下，發生了異常SSLHandshakeException，因為你的證照頒發機構並不被系統信任。這種異常可能發生在你的證照來自一個未被Android系統信任的新的證照頒發機構，或者你的舊版本的應用沒有證照頒發機構。證照頒發機構未知更常見的可能是它不是一個公開的證照頒發機構，而是一個組織發行的私有機構，比如政府，企業或教育機構自己使用。

Fortunately, you can teach HttpsURLConnection to trust a specific set of CAs. The procedure can be a little convoluted, so below is an example that takes a specific CA from an InputStream, uses it to create a KeyStore, which is then used to create and initialize a TrustManager. A TrustManager is what the system uses to validate certificates from the server and—by creating one from a KeyStore with one or more CAs—those will be the only CAs trusted by that TrustManager.

幸運的是，你可以讓HttpsURLConnection信任指定的CA集合。過程有點複雜，下面是一個示例，關於從InputStream讀取一個指定CA，然後用它來生成一個KeyStore，然後用來建立和初始化一個TrustManager。系統使用TrustManager來驗證來自伺服器的證照，並且TrustManager只信任那些建立了建立TrustManager時使用的CAs。

Given the new TrustManager, the example initializes a new SSLContext which provides an SSLSocketFactoryyou can use to override the default SSLSocketFactory from HttpsURLConnection. This way the connection will use your CAs for certificate validation.

得到了新的TrustManager後，示例中初始化了一個新的SSLContext，它提供了一個SSLSocketFactory可以被用來覆蓋HttpsURLConnection中的預設SSLSocketFactory。這樣，連線中就會使用你的CA來做證照校驗。

Here is the example in full using an organizational CA from the University of Washington:

下面就是使用來自華盛頓大學組織的CA進行一次HTTPS請求的全過程。

JAVA

With a custom TrustManager that knows about your CAs, the system is able to validate that your server certificate come from a trusted issuer.

使用新增了自己CAs的自定義TrustManager，系統能夠驗證你的伺服器證照來自一個信任的證照發行者。

Caution: Many web sites describe a poor alternative solution which is to install a TrustManager that does nothing. If you do this you might as well not be encrypting your communication, because anyone can attack your users at a public Wi-Fi hotspot by using DNS tricks to send your users' traffic through a proxy of their own that pretends to be your server. The attacker can then record passwords and other personal data. This works because the attacker can generate a certificate and—without a TrustManager that actually validates that the certificate comes from a trusted source—your app could be talking to anyone. So don't do this, not even temporarily. You can always make your app trust the issuer of the server's certificate, so just do it.

警告： 許多網站提供了一種很差的替代方案，這種方案新增了一個不做任何事情的TrustManager。如果你這麼做，那麼你並沒有加密你的通訊，因為任何人都可以攻擊你的使用者，只要通過公共的Wi-Fi熱點，然後使用DNS技巧來把它們代理伺服器的資料假裝來自你的伺服器。攻擊者接下來就可以記錄密碼或者其他使用者資訊。這樣是有效的，因為攻擊者可以生成一個證照而且不需要TrustManager的驗證是否來自信任的伺服器。所以不要這麼做，甚至也不要短暫地這麼做。你可以一直讓你的應用信任伺服器證照的頒發者，你只需要這麼做就好。

Self-signed server certificate(自簽名的伺服器證照)

The second case of SSLHandshakeException is due to a self-signed certificate, which means the server is behaving as its own CA. This is similar to an unknown certificate authority, so you can use the same approach from the previous section.

SSLHandshakeException異常的第二種情況是由於自簽名的證照，這意味著伺服器同時扮演了自己的證照頒發機構。這與未知的證照頒發機構是一樣的，所以你可以使用與上一節同樣的方式。

You can create your own TrustManager, this time trusting the server certificate directly. This has all of the downsides discussed earlier of tying your app directly to a certificate, but can be done securely. However, you should be careful to make sure your self-signed certificate has a reasonably strong key. As of 2012, a 2048-bit RSA signature with an exponent of 65537 expiring yearly is acceptable. When rotating keys, you should check for recommendationsfrom an authority (such as NIST) about what is acceptable.

你可以建立一個自己的TrustManager，這一次直接信任伺服器證照即可。這種方式擁有所有前面討論的所有缺點，但可以保證安全通訊。但是，你一定要注意，確保你的自簽名證照有一個健壯的金鑰。到2012年為止，一個指數為65537的2048位的RSA簽名是可以接受的。當需要更換金鑰的時候，你應該檢視權威機構(比如 NIST)的推薦方法來得到一個推薦的方式。

Missing intermediate certificate authority(缺失中級證照頒發機構)

The third case of SSLHandshakeException occurs due to a missing intermediate CA. Most public CAs don't sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise. However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate—signed by the intermediate CA—and the certificate verifier, which knows the root CA. To solve this, the server doesn't send the client only it's certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA.

異常SSLHandshakeException的第三種可能發生在缺失中級證照頒發機構的情況。因為大多數公共證照頒發機構並不直接為伺服器的證照籤名。而是用他們的main CA 證照(簡稱為根證照)簽名中級證照頒發機構。他們這麼做是為了離線儲存根證照來降低危害的風險。然而，類似Android這樣的作業系統直接信任的只有根證照，這樣，在證照被中級機構簽名的伺服器與知道根證照的證照驗證者之間產生一個小的信任空白。為了解決這個問題，在SSL握手期間，伺服器不僅僅傳送證照給客戶端，還傳送了一個來自中級機構伺服器的證照鏈來獲取根證照。

To see what this looks like in practice, here's the mail.google.com certificate chain as viewed by the openssls_client command:

想要知道如何操作，下面就是通過openssl命令來檢視Gmail證照鏈：

This shows that the server sends a certificate for mail.google.com issued by the Thawte SGC CA, which is an intermediate CA, and a second certificate for the Thawte SGC CA issued by a Verisign CA, which is the primary CA that's trusted by Android.

以上內容表明，伺服器傳送一個被中級機構Thawte SGC 發行的mail.google.com 證照，還有第二個來自機構Verisign發行的Thawte SGC CA的證照，VerisignCA 是Android新人的主機構。

However, it is not uncommon to configure a server to not include the necessary intermediate CA. For example, here is a server that can cause an error in Android browsers and exceptions in Android apps:

然而，一種很常見的方式是，將伺服器配置為不包含必要的中級CA。例如，下面的伺服器就會造成Android瀏覽器的錯誤以及Android App的異常。

What is interesting to note here is that visiting this server in most desktop browsers does not cause an error like a completely unknown CA or self-signed server certificate would cause. This is because most desktop browsers cache trusted intermediate CAs over time. Once a browser has visited and learned about an intermediate CA from one site, it won't need to have the intermediate CA included in the certificate chain the next time.

這裡需要指出很有趣的一點是，使用桌面瀏覽器訪問這臺伺服器不會造成像未知CA或自簽名伺服器那樣的錯誤。這是因為隨著時間的推移，大多數的桌面瀏覽器都會快取中級機構的CA。一旦一個瀏覽器從某個網站訪問而且得到了一箇中級CA，下一次訪問時就不必再從證照鏈中獲取該中級CA了。

Some sites do this intentionally for secondary web servers used to serve resources. For example, they might have their main HTML page served by a server with a full certificate chain, but have servers for resources such as images, CSS, or JavaScript not include the CA, presumably to save bandwidth. Unfortunately, sometimes these servers might be providing a web service you are trying to call from your Android app, which is not as forgiving.

一些網站故意為服務資源的輔助伺服器採取這種操作。例如：他們可能讓他們的主要HTML頁面可能由具有完整證照鏈的伺服器提供服務，但伺服器的資源（如影象，CSS或JavaScript）不包含CA，可能會節省頻寬。不幸的是，有時候這些伺服器可能會提供一個您嘗試從您的Android應用程式呼叫的Web服務，這是不被相容的。

There are two approaches to solve this issue: 有兩種方法解決這個問題。

Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers. This is the only approach if you need the site to work with default Android browsers at least through Android 4.2.

配置伺服器以將中間CA包含在伺服器鏈中。大多數CA提供有關如何為所有常見Web伺服器執行此操作的文件。如果您需要該網站至少通過Android4.2使用預設的Android瀏覽器，則這是唯一的方法。

Or, treat the intermediate CA like any other unknown CA, and create a TrustManagerto trust it directly, as done in the previous two sections.

或者，像處理其他未知的CA一樣對待中間CA，並建立TrustManager以直接信任它，如前兩節所述。

Common problems with hostname verification(主機名驗證的常見問題)

As mentioned at the beginning of this article, there are two key parts to verifying an SSL connection. The first is to verify the certificate is from a trusted source, which was the focus of the previous section. The focus of this section is the second part: making sure the server you are talking to presents the right certificate. When it doesn't, you'll typically see an error like this:

如本文開頭所述，驗證SSL連線有兩個關鍵部分。首先是驗證證照是否來自可信來源，這是上一節的重點。本節的重點是第二部分：確保您正在通話的伺服器提供正確的證照。 如果沒有，您通常會看到類似這樣的錯誤：

One reason this can happen is due to a server configuration error. The server is configured with a certificate that does not have a subject or subject alternative name fields that match the server you are trying to reach. It is possible to have one certificate be used with many different servers. For example, looking at the google.com certificate withopenssl s_client -connect google.com:443 | openssl x509 -text you can see that a subject that supports *.google.com but also subject alternative names for *.youtube.com, *.android.com, and others. The error occurs only when the server name you are connecting to isn't listed by the certificate as acceptable.

這可能發生的一個原因是由於伺服器配置錯誤。該伺服器配置有證照，該證照沒有與您嘗試訪問的伺服器相匹配的主題或主題替代名稱欄位。可以將許可證與多個不同的伺服器一起使用。 例如，使用openssl s_client-connect google.com:443 |檢視google.com證照 openssl x509- 文字您可以看到支援*.google.com的主題，但也可以使用*.youtube.com，*.android.com和其他名稱替代名稱。僅當您連線的伺服器名稱未被證照列為可接受時才會出現錯誤。

Unfortunately this can happen for another reason as well: virtual hosting. When sharing a server for more than one hostname with HTTP, the web server can tell from the HTTP/1.1 request which target hostname the client is looking for. Unfortunately this is complicated with HTTPS, because the server has to know which certificate to return before it sees the HTTP request. To address this problem, newer versions of SSL, specifically TLSv.1.0 and later, support Server Name Indication (SNI), which allows the SSL client to specify the intended hostname to the server so the proper certificate can be returned.

不幸的是，這可能會發生另一個原因：虛擬主機。 在使用HTTP共享多個主機名的伺服器時，Web伺服器可以從HTTP / 1.1請求中告知客戶端正在查詢哪個目標主機名。 不幸的是，HTTPS很複雜，因為伺服器在看到HTTP請求之前必須知道要返回哪個證照。 為了解決這個問題，較新版本的SSL，特別是TLSv.1.0及更高版本，支援伺服器名稱指示（SNI），它允許SSL客戶端指定伺服器的預期主機名，以便返回適當的證照。

Fortunately, HttpsURLConnection supports SNI since Android 2.3. One workaround if you need to support Android 2.2 (and older) is to set up an alternative virtual host on a unique port so that it's unambiguous which server certificate to return.

幸運的是，自Android 2.3以來，HttpsURLConnection支援SNI。 如果您需要支援Android 2.2（及更早版本），一種解決方法是在唯一埠上設定備用虛擬主機，以便明確返回哪個伺服器證照。

The more drastic alternative is to replace HostnameVerifier with one that uses not the hostname of your virtual host, but the one returned by the server by default.

更為激烈的選擇是將HostnameVerifier替換為不使用虛擬主機主機名的主機名，而是預設情況下由伺服器返回的主機名。

Caution: Replacing HostnameVerifier can be very dangerous if the other virtual host is not under your control, because a man-in-the-middle attack could direct traffic to another server without your knowledge.

警告：如果其他虛擬主機不在您的控制之下，則替換HostnameVerifier會非常危險，因為中間人攻擊可能會在您不知情的情況下將流量導向另一臺伺服器。

If you are still sure you want to override hostname verification, here is an example that replaces the verifier for a single URLConnection with one that still verifies that the hostname is at least on expected by the app:

如果您仍然確定要覆蓋主機名驗證，請使用以下示例將單個URLConnection的驗證程式替換為仍驗證主機名至少符合應用程式預期的驗證程式：

JAVA

But remember, if you find yourself replacing hostname verification, especially due to virtual hosting, it's still very dangerous if the other virtual host is not under your control and you should find an alternative hosting arrangement that avoids this issue.

但請記住，如果您發現自己更換了主機名驗證（尤其是虛擬主機），但如果其他虛擬主機不在您的控制範圍內，則仍然非常危險，您應該找到另一種避免此問題的主機安排。

Warnings about using SSLSocket directly(直接使用SSLSocket的警告)

So far, the examples have focused on HTTPS using HttpsURLConnection. Sometimes apps need to use SSL separate from HTTP. For example, an email app might use SSL variants of SMTP, POP3, or IMAP. In those cases, the app would want to use SSLSocketdirectly, much the same way that HttpsURLConnection does internally.

到目前為止，這些示例都著眼於使用HttpsURLConnection的HTTPS。 有時，應用程式需要使用與HTTP分開的SSL。 例如，電子郵件應用程式可能使用SMTP，POP3或IMAP的SSL變體。 在這些情況下，應用程式會直接使用SSLSocket，這與HttpsURLConnection內部的方式非常相似。

The techniques described so far to deal with certificate verification issues also apply to SSLSocket. In fact, when using a custom TrustManager, what is passed to HttpsURLConnection is an SSLSocketFactory. So if you need to use a custom TrustManager with an SSLSocket, follow the same steps and use that SSLSocketFactory to create your SSLSocket.

到目前為止描述的處理證照驗證問題的技術也適用於SSLSocket。 實際上，在使用自定義TrustManager時，傳遞給HttpsURLConnection的是SSLSocketFactory。 因此，如果您需要使用具有SSLSocket的自定義TrustManager，請遵循相同步驟並使用該SSLSocketFactory建立您的SSLSocket。

Caution: SSLSocket does not perform hostname verification. It is up to your app to do its own hostname verification, preferably by calling getDefaultHostnameVerifier() with the expected hostname. Further beware that HostnameVerifier.verify() doesn't throw an exception on error but instead returns a boolean result that you must explicitly check.

警告：SSLSocket不會執行主機名驗證。 這取決於您的應用程式執行自己的主機名驗證，最好通過使用預期的主機名呼叫getDefaultHostnameVerifier（）。 進一步要注意，HostnameVerifier.verify（）不會在錯誤時丟擲異常，而是返回一個必須明確檢查的布林結果。

Here is an example showing how you can do this. It shows that when connecting to gmail.com port 443 without SNI support, you'll receive a certificate for mail.google.com. This is expected in this case, so check to make sure that the certificate is indeed for mail.google.com:

這裡是一個顯示你如何做到這一點的例子。 它顯示，當連線到沒有SNI支援的gmail.com埠443時，您將收到mail.google.com的證照。 預計在這種情況下，請檢查以確保證照確實適用於mail.google.com：

JAVA

Blacklisting(黑名單)

SSL relies heavily on CAs to issue certificates to only the properly verified owners of servers and domains. In rare cases, CAs are either tricked or, in the case of Comodo or DigiNotar, breached, resulting in the certificates for a hostname to be issued to someone other than the owner of the server or domain.

SSL嚴重依賴於CA向只有經過適當驗證的伺服器和域名所有者頒發證照。 在極少數情況下，CA可能被欺騙，或者在Comodo或DigiNotar的情況下被違反，從而導致將主機名證照頒發給除伺服器或域所有者之外的其他人。

In order to mitigate this risk, Android has the ability to blacklist certain certificates or even whole CAs. While this list was historically built into the operating system, starting in Android 4.2 this list can be remotely updated to deal with future compromises.

為了降低這種風險，Android有能力將某些證照甚至整個CA列入黑名單。 雖然這個列表歷史上已經嵌入到作業系統中，但從Android 4.2開始，這個列表可以被遠端更新以處理未來的危險。

Pinning(固定)

An app can further protect itself from fraudulently issued certificates by a technique known as pinning. This is basically using the example provided in the unknown CA case above to restrict an app's trusted CAs to a small set known to be used by the app's servers. This prevents the compromise of one of the other 100+ CAs in the system from resulting in a breach of the apps secure channel.

應用程式可以通過稱為固定的技術進一步保護自己免受欺詐性簽發的證照的侵害。 這基本上是使用上述未知CA案例中提供的示例將應用程式的可信CA限制為已知由應用程式的伺服器使用的小集合。 這樣可以避免系統中其他100多個CA之一的破壞，從而導致違反應用程式安全通道。

Client certificates(客戶端證照)

This article has focused on the user of SSL to secure communications with servers. SSL also supports the notion of client certificates that allow the server to validate the identity of a client. While beyond the scope of this article, the techniques involved are similar to specifying a custom TrustManager. See the discussion about creating a custom KeyManager in the documentation for HttpsURLConnection.

本文專注於SSL使用者以保護與伺服器的通訊。 SSL還支援允許伺服器驗證客戶端身份的客戶端證照的概念。 雖然超出了本文的範圍，但涉及的技術類似於指定自定義TrustManager。 請參閱關於在HttpsURLConnection文件中建立自定義KeyManager的討論。

Nogotofail: A network traffic security testing tool(Nogotofial: 網路流量安全測試工具)

Nogotofail is a tool gives you an easy way to confirm that your apps are safe against known TLS/SSL vulnerabilities and misconfigurations. It's an automated, powerful, and scalable tool for testing network security issues on any device whose network traffic could be made to go through it.

Nogotofail是一種工具，可讓您輕鬆確認您的應用程式對已知的TLS / SSL漏洞和錯誤配置是否安全。 它是一款自動化，功能強大且可擴充套件的工具，用於測試網路流量可能經過的任何裝置上的網路安全問題。

Nogotofail is useful for three main use cases:

Finding bugs and vulnerabilities.

Verifying fixes and watching for regressions.

Understanding what applications and devices are generating what traffic.

Nogotofial主要用於以下三個方面：

查詢漏洞和錯誤。

驗證修復並觀察迴歸

瞭解什麼應用程式和裝置正在生成什麼流量。

Nogotofail works for Android, iOS, Linux, Windows, Chrome OS, OSX, in fact any device you use to connect to the Internet. There’s an easy-to-use client to configure the settings and get notifications on Android and Linux, as well as the attack engine itself which can be deployed as a router, VPN server, or proxy.

Nogotofail適用於Android，iOS，Linux，Windows，Chrome OS，OSX，實際上是您用來連線網際網路的任何裝置。 有一個易於使用的客戶端來配置設定並獲取Android和Linux上的通知，以及可以作為路由器，VPN伺服器或代理部署的攻擊引擎本身。

You can access the tool at the Nogotofail open source project.

可以從這裡獲取Nogotofial.