Subject: [TLS] Interop failure due to wrong encoding of ServerDHParams

From: Florian Weimer <[email-masked]>
Date: Tue, 07 Apr 2015 14:04:37 +0200

I've encountered a TLS 1.2 server implementation which sometimes sends a
ServerDHParams structure as part of the ServerKeyExchange message which
indicates a length of 127 bytes for the dh_Ys parameter, but the
parameter actually sent contains 128 bytes.  As a result, parsing the
ServerKeyExchange message fails, leading to a handshake failure.  (Maybe
this happens if the most significant byte of dh_Ys is zero.)

In this situation, the OpenSSL client logs this error message:

error:1408D172:SSL routines:SSL3_GET_KEY_EXCHANGE:wrong signature
type:s3_clnt.c:1863:

Does this ring a bell?  I don't know any details about the server
implementation, unfortunately.

-- 
Florian Weimer / Red Hat Product Security

---

From: Hanno Böck <[email-masked]>
Date: Tue, 7 Apr 2015 14:31:48 +0200

On Tue, 07 Apr 2015 14:04:37 +0200
Florian Weimer <[email-masked]> wrote:

> I've encountered a TLS 1.2 server implementation which sometimes
> sends a ServerDHParams structure as part of the ServerKeyExchange
> message which indicates a length of 127 bytes for the dh_Ys
> parameter, but the parameter actually sent contains 128 bytes.  As a
> result, parsing the ServerKeyExchange message fails, leading to a
> handshake failure.  (Maybe this happens if the most significant byte
> of dh_Ys is zero.)

Hannes from ocaml-tls said something very similar a few days ago in a
talk at CCC Berlin. But I think he also said he observed something like
that on their servers, but doesn't know which implementation caused it.

The talk was streamed and recorded, but I think it's not online yet.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Hannes Mehnert <[email-masked]>
Date: Tue, 07 Apr 2015 15:45:47 +0200

Hi,

On 04/07/2015 14:31, Hanno Böck wrote:
> On Tue, 07 Apr 2015 14:04:37 +0200 Florian Weimer
> <[email-masked]> wrote:
> 
>> sends a ServerDHParams structure as part of the
>> ServerKeyExchange message which indicates a length of 127 bytes
>> for the dh_Ys parameter, but the parameter actually sent contains
>> 128 bytes.  As a result, parsing the ServerKeyExchange message
>> fails, leading to a handshake failure.  (Maybe this happens if
>> the most significant byte of dh_Ys is zero.)
> 
> Hannes from ocaml-tls said something very similar a few days ago in
> a talk at CCC Berlin. But I think he also said he observed
> something like that on their servers, but doesn't know which
> implementation caused it.

What I discovered while running https://tls.openmirage.org (a
handshake visualisation for TLS-1.* (it picks protocol version and
ciphersuite at random!) - gathered around 30000 TLS sessions) was that
our own OCaml-TLS implementation padded the DH parameters with 0 bytes
(both the public on the wire, as well as the shared secret).

When looking through the session traces, it seems that another
implementation does exactly the same: padding with 0 if the DH
shared/public has leading zeroes.
Using the list of ciphersuites and named curve extension as
fingerprint (obviously a very probabilistic approach, see below), the
recorded HTTP user-agents are:
293 Google-HTTP-Java-Client/1.17.0-rc (gzip)
174 Mozilla/5.0 ()
13 other

Thus, it seems to be likely that some Java implementation has this
behaviour. Maybe someone with more insight into the Java
implementation(s) could look deeper into this!?

hannes

Here is the fingerprint:
ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
extensions:
EllipticCurves: SECP256R1 SECT163K1 SECT163R2 SECP192R1 SECP224R1
SECT233K1 SECT233R1 SECT283K1 SECT283R1 SECP384R1 SECT409K1 SECT409R1
SECP521R1 SECT571K1 SECT571R1 SECP160K1 SECP160R1 SECP160R2 SECT163R1
SECP192K1 SECT193R1 SECT193R2 SECP224K1 SECT239K1 SECP256K1
ECPointFormats: UNCOMPRESSED