在Spring Boot中启用TLSv1密码 [英] Enable TLSv1 ciphers in Spring Boot

问题描述

我正在尝试在我的Spring启动REST服务中启用TLSv1密码，以便较旧的Android客户端可以连接到它但由于某种原因它不起作用。我正在运行 openjdk版本1.8.0_131，默认情况下TLSv1，TLSv1.1和TLSv1.2似乎已启用

我是使用 nmap --script ssl-enum-ciphers -p 8443 127.0.0.1 来扫描服务器可以采取什么，我得到了这个

I am trying to enable TLSv1 ciphers in my spring boot REST service so that older android clients can connect to it but it is not working for some reason. I'm running openjdk version "1.8.0_131" and by default TLSv1, TLSv1.1 and TLSv1.2 seem to be enabled
I'm using nmap --script ssl-enum-ciphers -p 8443 127.0.0.1 to scan what the server can take and I'm getting this

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日志上我看到了

There are no TLSv1 or TLSv1.1 that succeeded. But they are not disabled! I know this because when I do disable them by setting server.ssl.enabled-protocols=TLSv1.2, on the server ssl logs I see

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

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

When I remove that line (so defaults are enabled again), I don't see that error. What I see is

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

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

This is the list of ciphers that the nmap scan is sending, it's a huge list so it's hard to believe there are none in common in TLSv1 or 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。然而，nmap成功使用了一些TLSv1.2密码，因为它支持的密码较少，所以android不会。所以我试图在android中启用更多密码（似乎更难/不可能）或在我的服务器中启用更多密码（似乎更容易）。这些是android在ClientHello中发送的密码

Some background, I am trying to enable TLSv1 hoping that my android 4.4.4 client will then connect. It is having the same error of no cipher suites in common as nmap when it sends its ciphers list. However nmap succeeds with some TLSv1.2 ciphers, android does not since it supports less ciphers. So I'm trying to either enable more ciphers in android (seems harder/impossible) or enable more ciphers in my server (seems easier). These are the ciphers that android is sending in the 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

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

If I explicitly enable only those in spring using server.ssl.ciphers, nmap reveals that no cipher at all is actually being accepted. What could be causing spring/java/somethingelse not enabling any of the (common and standard) ciphers that android is trying to use?

推荐答案

我的案例中的问题不在于未启用TLS版本。这是密码的签名算法。

The issue in my case was not with TLS versions not being enabled. It was with the cipher's signing algorithm.

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

Jetty disables all ciphers that use SHA1 or MD5 and, as can be seen in the client's list, they are all SHA1 ciphers in my case. This is in the Jetty code

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

更多详情这里

要修复它，我创建了一个明确的密码列表，用于我的春季启动配置，我启用了SHA1密码

To fix it, I created an explicit list of ciphers to use in my spring boot config where I enabled the SHA1 ciphers

我不得不说这个码头决定对我来说似乎没必要基于这篇文章（I 不是安全专家，至少在与TLS1.2一起使用时是这样。要点是肯定不安全的是使用SHA1签署证书，但使用在HMAC中使用SHA1的密码套件仍然被认为是安全的

I have to say that this jetty decision seems unnecessary to me based on this post (I'm no security expert though) at least when using it with TLS1.2. The gist is that what is definitely not secure is signing certificates with SHA1, but using cipher suites that use SHA1 within their HMAC is still considered secure

这篇关于在Spring Boot中启用TLSv1密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！