深入剖析OkHttp系列（四） 来自官方的HTTPS

HTTPS

OkHttp attempts to balance two competing concerns: Connectivity to as many hosts as possible. That includes advanced hosts that run the latest versions of boringssl and less out of date hosts running older versions of OpenSSL. Security of the connection. This includes verification of the remote webserver with certificates and the privacy of data exchanged with strong ciphers.

OkHttp试图平衡两个相互竞争的问题：
.连接尽可能多的主机。 包括运行在最新版本boringssl上的高级主机和运行在旧版OpenSSL上的过时的主机。
.连接的安全性。 包含使用证书验证远程的服务器以及使用强密码交换的数据的隐私。

When negotiating a connection to an HTTPS server, OkHttp needs to know which TLS versions and cipher suites to offer. A client that wants to maximize connectivity would include obsolete TLS versions and weak-by-design cipher suites. A strict client that wants to maximize security would be limited to only the latest TLS version and strongest cipher suites.

在写上与HTTPS服务端的连接时， OkHtt需要知道需提供哪些TLS版本和密码序列。 希望最大化连接的客户端应该包括过时的TLS版本和弱密码序列。 希望最大化安全性的客户端应该仅限于最新的TLS版本和最强的密码序列。

Specific security vs. connectivity decisions are implemented by ConnectionSpec. OkHttp includes three built-in connection specs: MODERN_TLS is a secure configuration that connects to modern HTTPS servers. COMPATIBLE_TLS is a secure configuration that connects to secure–but not current–HTTPS servers. CLEARTEXT is an insecure configuration that is used for http:// URLs.

ConnectionSpec实现了特定的安全性和连接性决策。 OkHttp包含3个内置连接规范：
.MODERN_TLS是连接到现代HTTPS服务器的安全配置。
.COMPATIBLE_TLS是连接到安全但非当前的HTTPS服务器的安全配置。
.CLEARTEXT是一种不安全的配置， 用于http:// URLs.

By default, OkHttp will attempt a MODERN_TLS connection, and fall back to COMPATIBLE_TLS connection if the modern configuration fails.

OkHttp是默认尝试MODERN_TLS连接的， 如果配置失败， 会回退到COMPATIBLE_TLS连接。

The TLS versions and cipher suites in each spec can change with each release. For example, in OkHttp 2.2 we dropped support for SSL 3.0 in response to the POODLE attack. And in OkHttp 2.3 we dropped support for RC4. As with your desktop web browser, staying up-to-date with OkHttp is the best way to stay secure.

每个规范中的TLS版本和密码序列会随着版本而变化。 比如， 在OkHttp 2.2版本 我们放弃了SSL 3.0的支持来响应POODLE攻击。 在OkHttp 2.3版本 我们放弃了RC4的支持。 与您的桌面浏览器一样， 保持OkHttp的最新版本是保持安全的最佳方式。

You can build your own connection spec with a custom set of TLS versions and cipher suites. For example, this configuration is limited to three highly-regarded cipher suites. Its drawback is that it requires Android 5.0+ and a similarly current webserver.

你可以使用一组自定义的TLS版本和密码序列来构建你自己的连接。比如， 此配置仅限于3个最受推崇的密码序列。 它的缺点是需要Android5.0+类似的网络服务器。

ConnectionSpec spec = new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)  
    .tlsVersions(TlsVersion.TLS_1_2)
    .cipherSuites(
          CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
          CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
          CipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256)
    .build();

OkHttpClient client = new OkHttpClient.Builder() 
    .connectionSpecs(Collections.singletonList(spec))
    .build();
复制代码

证书锁定

By default, OkHttp trusts the certificate authorities of the host platform. This strategy maximizes connectivity, but it is subject to certificate authority attacks such as the 2011 DigiNotar attack. It also assumes your HTTPS servers’ certificates are signed by a certificate authority. Use CertificatePinner to restrict which certificates and certificate authorities are trusted. Certificate pinning increases security, but limits your server team’s abilities to update their TLS certificates. Do not use certificate pinning without the blessing of your server’s TLS administrator!

默认情况下， OkHttp信任主机平台的证书颁发机构。 该策略可最大限度的提高连接性。但它受到如2011 DigiNotar的攻击。 它还假定您的Https 服务端认证是由一个认证机构签名的。
使用CertificatePinner来限制受信任的证书和颁发机构。 证书锁定可以提高安全性， 但会受限于服务器团队更新TLS证书的能力。 没有服务器TLS管理员的保证， 请不要使用证书锁定！

public CertificatePinning() {
    client = new OkHttpClient.Builder()
        .certificatePinner(new CertificatePinner.Builder()
            .add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
            .build())
        .build();
  }

  public void run() throws Exception {
    Request request = new Request.Builder()
        .url("https://publicobject.com/robots.txt")
        .build();

    Response response = client.newCall(request).execute();
    if (!response.isSuccessful()) throw new IOException("Unexpected code " + response);

    for (Certificate certificate : response.handshake().peerCertificates()) {
      System.out.println(CertificatePinner.pin(certificate));
    }
  }
复制代码

The full code sample shows how to replace the host platform’s certificate authorities with your own set. As above, do not use custom certificates without the blessing of your server’s TLS administrator!

完整的代码展示了如何使用你自己的集来替换主机平台的证书。 如上所述， 如果没有服务器TLS管理员的祝福，请不要自定义证书。

private final OkHttpClient client;

  public CustomTrust() {
    SSLContext sslContext = sslContextForTrustedCertificates(trustedCertificatesInputStream());
    client = new OkHttpClient.Builder()
        .sslSocketFactory(sslContext.getSocketFactory())
        .build();
  }

  public void run() throws Exception {
    Request request = new Request.Builder()
        .url("https://publicobject.com/helloworld.txt")
        .build();

    Response response = client.newCall(request).execute();
    System.out.println(response.body().string());
  }

  private InputStream trustedCertificatesInputStream() {
    ... // Full source omitted. See sample.
  }

  public SSLContext sslContextForTrustedCertificates(InputStream in) {
    ... // Full source omitted. See sample.
  }
复制代码