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

亓春傑發表於2018-08-16
HTTP

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.
  }
複製程式碼

相關文章