在 Spring Boot 中启用 TLSv1 密码

Question

我正在尝试在我的 Spring Boot REST 服务中启用 TLSv1 密码，以便较旧的 android 客户端可以连接到它，但由于某种原因它无法正常工作。我正在运行openjdk version "1.8.0_131"，默认情况下似乎启用了 TLSv1、TLSv1.1 和 TLSv1.2
我正在使用nmap --script ssl-enum-ciphers -p 8443 127.0.0.1 来扫描服务器可以获取的内容，我得到了这个

8443/tcp open  https-alt
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (secp256k1) - A
|       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (secp521r1) - A
|       TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (secp521r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256k1) - A
|       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (secp521r1) - A
|       TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (secp521r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256k1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256k1) - A
|       TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (secp521r1) - A
|       TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (secp521r1) - A
|       TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (secp521r1) - A
|       TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (secp521r1) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256k1) of lower strength than certificate key
|_  least strength: A

没有成功的 TLSv1 或 TLSv1.1。但他们没有残疾！我知道这一点是因为当我通过设置server.ssl.enabled-protocols=TLSv1.2 禁用它们时，我会在服务器 ssl 日志中看到

javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.1 not enabled or not supported

当我删除该行（因此再次启用默认值）时，我没有看到该错误。我看到的是

javax.net.ssl.SSLHandshakeException: no cipher suites in common

这是 nmap 扫描发送的密码列表，这是一个巨大的列表，因此很难相信 TLSv1 或 TLSv1.1 中没有共同点：

Cipher Suites: [Unknown 0xc0:0xa9, TLS_PSK_WITH_AES_256_GCM_SHA384, Unknown 0xc0:0x64, Unknown 0xc0:0x6a, Unknown 0xc0:0x65, Unknown 0xc0:0x6b, Unknown 0xc0:0x94, Unknown 0xc0:0x8e, Unknown 0xc0:0x95, Unknown 0xc0:0x8f, Unknown 0xcc:0xab, TLS_PSK_WITH_NULL_SHA, TLS_PSK_WITH_NULL_SHA256, TLS_PSK_WITH_NULL_SHA384, TLS_PSK_WITH_RC4_128_SHA, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, Unknown 0x0:0x61, Unknown 0x0:0x60, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA, TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_PSK_WITH_AES_128_CBC_SHA256, TLS_RSA_PSK_WITH_AES_128_GCM_SHA256, TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, Unknown 0xc0:0x68, Unknown 0xc0:0x6e, Unknown 0xc0:0x69, Unknown 0xc0:0x6f, Unknown 0xc0:0x98, Unknown 0xc0:0x92, Unknown 0xc0:0x99, Unknown 0xc0:0x93, Unknown 0xcc:0xae, TLS_RSA_PSK_WITH_NULL_SHA, TLS_RSA_PSK_WITH_NULL_SHA256, TLS_RSA_PSK_WITH_NULL_SHA384, TLS_RSA_PSK_WITH_RC4_128_SHA, Unknown 0x0:0x7c, SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x7d, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, Unknown 0xc0:0x9c, Unknown 0xc0:0xa0, TLS_RSA_WITH_AES_128_GCM_SHA256, Unknown 0x0:0x7e, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, Unknown 0xc0:0x9d, Unknown 0xc0:0xa1, TLS_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xc0:0x3c, Unknown 0xc0:0x50]

一些背景，我正在尝试启用 TLSv1，希望我的 android 4.4.4 客户端随后能够连接。在发送密码列表时，它与 nmap 具有相同的 no cipher suites in common 错误。然而，nmap 成功使用了一些 TLSv1.2 密码，而 android 却没有，因为它支持的密码较少。所以我试图在 android 中启用更多密码（似乎更难/不可能）或在我的服务器中启用更多密码（似乎更容易）。这些是 android 在 ClientHello 中发送的密码

TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

如果我在 spring 中使用server.ssl.ciphers 明确启用那些，nmap 显示实际上根本没有密码被接受。什么可能导致 spring/java/somethingelse 无法启用 android 尝试使用的任何（通用和标准）密码？

Answer 1

在我的情况下，问题不在于未启用 TLS 版本。它与密码的签名算法有关。

Jetty 禁用所有使用 SHA1 或 MD5 的密码，从客户端列表中可以看出，在我的情况下，它们都是 SHA1 密码。这是在码头代码中

SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setExcludeCipherSuites(
        "^.*_(MD5|SHA|SHA1)$");

更多详情here

为了解决这个问题，我创建了一个明确的密码列表以在我的 Spring Boot 配置中使用（使用配置属性 server.ssl.ciphers），我在其中启用了 SHA1 密码

我不得不说，至少在将它与 TLS1.2 一起使用时，基于this post（虽然我不是安全专家），这个码头决定对我来说似乎是不必要的。要点是绝对不安全的是使用 SHA1 签署证书，但使用在其 HMAC 中使用 SHA1 的密码套件仍然被认为是安全的