在 Retrofit Api 请求中使用密码套件有什么好处？答案

【问题标题】：What is the advantages of using Cipher suites in Retrofit Api request?在 Retrofit Api 请求中使用密码套件有什么好处？
【发布时间】：2020-10-22 17:05:10
【问题描述】：

我读到了这个https://square.github.io/okhttp/https/ 但是我对我在任何网站都找不到的一点怀疑。在 Api 端出于安全目的使用自签名 api(Lets Encrypt) 我在我的 Android 改造实例中使用以下代码，

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();

我也使用 POST 请求。以下是我的疑问，

使用密码套件如何实现安全保护？
由于我使用的是 Post 请求，所以不会暴露参数。但是基本网址呢？那么是否有机会破解该基本网址？我可以像参数一样隐藏基本网址吗？
上述 Retrofit Instance、POST 方法和 Lets Encrypt Api 将提供什么样的安全性？
除了在 Android 应用端，还有其他选项可以保护 api 请求吗？
我在 Retrofit 实例中所做的事情是否适合保护 Api？它是如何工作的？
为了在 Android 应用端保护 Api，我还遗漏了什么？

请任何人帮助我解决这些疑问。

【问题讨论】：

标签： android api security retrofit2 okhttp

【解决方案1】：

不要选择自己的密码套件。 OkHttp 具有安全的默认值，您的 HTTPS 连接将通过坚持这些默认值来确保安全。

默认配置是 MODERN_TLS，这是大多数应用程序应该使用的。

如果您只连接到您的组织维护的服务器，并且如果您只支持最新的 JVM 或 Android 设备（例如在微服务部署中），则可以改为配置 RESTRICTED_TLS。这是 OkHttp 的 TLS 配置，适用于您拥有专门的安全团队并控制客户端和服务器上的完整软件堆栈的部署。

在相反的情况下，如果您需要支持一组特别广泛的设备或 JVM 并连接到各种过时配置的服务器，那么 COMPATIBLE_TLS 适合您。它包括广泛的 TLS 版本和密码套件，这增加了漏洞的表面积，尽管目前还没有众所周知的漏洞。

考虑这些配置的另一种方式：我对新发现的漏洞的暴露程度如何？您可能还记得 Heartbleed，整个 Internet 都需要在短时间内升级 OpenSSL。如果出现此类漏洞，您可能需要更新客户端和/或服务器。以下是我对 OkHttp 内置配置的不科学和不合理的感觉：

RESTRICTED_TLS：由于明年新发现的弱点，您有 2% 的机会需要发布紧急更新
MODERN_TLS：由于明年新发现的弱点，您有 5% 的机会需要发布紧急更新
COMPATIBLE_TLS：由于明年新发现的弱点，您有 10% 的机会需要发布紧急更新

现在一切都是安全的，但是你支持的东西越多，表面积就越容易受到攻击。

【讨论】：