在nginx错误日志中:“SSL_BYTES_TO_CIPHER_LIST:不合适的回退”

我们最近改变了我们的nginxconfiguration,以支持TLSv1.2以及一些更安全的密码。 自更改以来,我们的nginx错误日志已填充以下错误:

2015/01/28 23:55:57 [crit] 16898#0:* 18712916 SSL握手,客户端:SSL_do_handshake()失败(SSL:错误:140A1175:SSL例程:SSL_BYTES_TO_CIPHER_LIST:不适当的回退) ,服务器:0.0.0.0:443

我们的nginxconfiguration如下:

server { root /var/www/fl/current/public; listen 443; ssl on; ssl_certificate /etc/nginx/ssl/wildcard.pem; ssl_certificate_key /etc/nginx/ssl/wildcard.key; ssl_session_timeout 5m; ssl_session_cache shared:SSL:50m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; 

我们收到了一些关于用户无法访问该网站的电子邮件。 一位用户表示这是他们在Firefox中遇到的错误:

安全连接失败

在与******.com连接期间发生错误。 服务器拒绝握手,因为客户端降级到比服务器支持的更低的TLS版本。 (错误代码:ssl_error_inappropriate_fallback_alert)

您尝试查看的页面无法显示,因为收到的数据的真实性无法validation。

如果我理解正确,那么当客户端使用比它和服务器支持的更低版本的TLS时,回退警报是一种安全防范措施。 考虑到我们现在支持更高的协议版本,这个错误似乎很有意义。 我不明白的是,为什么当连接到我们的网站时,这个改变会导致一些用户的问题。 这是我们的configuration或浏览器中的错误吗?

我们现在在Qualys SSL服务器testing中得到一个“A”,所以我犹豫回到我们的旧configuration。

浏览器通常会进行SSLv23握手。 通过这次握手,他们宣布了他们支持的最好的协议版本(现在主要是TLS1.2),但是不要把服务器限制到这个版本。 因此,具有正确实施和configuration的TLS堆栈但仅支持TLS1.0的服务器将简单地回复TLS1.0,并且连接将在第一次尝试中成功。

但是,在服务器端存在一些错误的TLS堆栈或错误configuration或一些不好的中间件(负载均衡器等),导致SSLv23握手失败。 在这种情况下,浏览器会降低握手中使用的协议,即尝试使用明确的TLS1.0握手,然后进行明确的SSL3.0握手(某些浏览器已禁用SSL3.0,因此不会尝试此操作)。

较新的浏览器将使用TLS_FALLBACK_SCSV伪密码,如果他们做了这样的降级连接。 如果能够使用TLS_FALLBACK_SCSV的服务器检测到具有较低协议版本的降级连接,则它支持(例如,降级使用TLS1.0,但服务器支持TLS1.2),而不是假设类似POODLE的攻击发生并closures连接。

但是,为什么客户在联系服务器时可能会降级?

  • 你可能在前面有一个破坏的负载均衡器,这会导致有些请求的hickup。
  • SSL握手完成之前,您的服务器或前面的一些反DOS设备可能会在高负载情况下closures连接。 在这种情况下,浏览器将承担协议问题,并以降级版本重试。
  • 任何其他types的问题,如内存不足等,可能导致在SSL握手中随机closures。

更改318904上传了一个相关的补丁集(BBlack):对客户端握手非暴击SSL_R_VERSION_TOO_LOW

https://gerrit.wikimedia.org/r/318904

https://phabricator.wikimedia.org/T148893