在改造 API 请求中使用密码套件有什么优势?

Question

我读了这个 https://square.github.io/okhttp/https/但是我对从任何网站上都找不到的东西几乎没有疑问。 出于安全目的，在 API 端使用自签名 api(让我们加密( 我在我的安卓改造实例中使用以下代码，

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

我也使用开机自检请求。 以下是我的疑问，

1. 使用密码套件 安全保护如何工作？
2. 当我使用 Post 请求时，参数不会公开。但是基本网址呢？那么有机会破解该基本网址吗？我可以将基本网址隐藏为类似参数吗？
3. 上述改造实例、POST 方法和 Lets Encrypt API 将提供什么样的安全性？
除了
4. 这个之外，在 Android 应用程序端还有其他选项来保护 api 请求吗？
5. 我在 Retrofit 实例中所做的工作是否适合保护 API？这是怎么回事？
6. 我在这里缺少什么来保护 Android 应用程序端的 API？

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

Answer 1

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

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

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

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

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

• RESTRICTED_TLS：由于明年新发现的弱点，您需要发布紧急更新的可能性为 2%
• MODERN_TLS：由于明年新发现的弱点，您需要发布紧急更新的可能性为 5%
• COMPATIBLE_TLS：由于明年新发现的弱点，您需要发布紧急更新的可能性为 10%

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