1169061 - "decode errors" during TLS handshake with addons.mozilla.org

Status: RESOLVED INVALID

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Pavel Kankovsky]

User Agent: Mozilla/5.0 (X11; Linux; rv:10) Gecko/20119999 Firefox/10.99
Build ID: 20150512232818

Steps to reproduce:

I had trouble using about:addons in one of my FF profiles, because addons.mozilla.org (and services.addons.mozilla.org) kept refusing TLS connections with a fatal "decode error" alert (code 50) immediately after it received a ClientHello message.

I have found out the server dislikes certain combinations of cipher suites. Namely, the following set of cipher suites proposed by my browser (I had tweaked its settings in the past) did always lead to the aformentioned error:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

The problem can be reproduced with OpenSSL:

$ openssl s_client -connect addons.mozilla.org:443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA
CONNECTED(00000003)
140284090132296:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:744:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 129 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---




Actual results:

The server returns a bogus (but fatal) "decode error" alert and addon management in the browser is... impaired to put it lightly. ECDHE suites appear to be the culprit because 1. the handshake fails whenever any of them appears on the list and 2. succeeds when they are omitted.

But there is a bizzare twist: If I add *yet another* ECDHE suite, namely TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (enabled by security.ssl3.ecdh_rsa_aes_256_sha), to the list, the ClientHello is accepted.
As far as I can tell, the extra "magic" cipher suite is the only difference between the unacceptable ClientHello and the acceptable one.Moreover, the server *does not* choose that "magic" suite (it picks TLS_RSA_WITH_AES_128_CBC_SHA) and handshakes fail when it is only cipher suite is proposed by the client.


Expected results:

The server should pick an acceptable cipher suite, ignore the rest, and finish the handshake. And even if an acceptable suite were not found among those proposed by the client, it should send a handshake alert (see RFC 5246, section 7.4.1.2.) rather than a bogus decode error alert.

Comment 1

[Mathieu Agopian [:magopian]]

:jason is that something that you can investigate?

Comment 2

[Jason Thomas [:jason]]

This is probably no longer a issue since we changed SSL Termination products.