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安全概览》和《权限概览》。
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的服务器发行了该证书。
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发行的证书。你可以进行一次安全请求用以下的简单代码。
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请求的全过程。
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的验证程序替换为仍验证主机名至少符合应用程序预期的验证程序：
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：
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开始，这个列表可以被远程更新以处理未来的危险。
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之一的破坏，从而导致违反应用程序安全通道。
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.
网友评论