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

[Hannes Mehnert <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Hi,

On 04/07/2015 14:31, Hanno Böck wrote:
> On Tue, 07 Apr 2015 14:04:37 +0200 Florian Weimer
> <[e-mail]> 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.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCQAGBQJVI9+LAAoJELyJZYjffCjuF00P/00ZeIsxcmSCHzkAn60HXEYg
rVeW4aQ1ewIgGETCkQluh9QbJosKjh9w+I9FtbZnUYVd5DAb5kXpN4pKwGkc63GA
U830XQ2Uy4no7TViUhvb+TnWVPpIvXAqE8IGNtvGPhRsg9JlcZzINFcECGXPK9ee
/14ZlQGx00pn6vOc7Nh6oLNhcw7FViSzRwk9J9+zoa8khaGIRTCKHyw9VHCTDm13
v1U86ajfleqRqXV00NA6/pNICm1q86yW/ONcZ6pG/MQGncyzk88BXs755wlOooww
vPGl6LFrYFLfpKJhbJ8KPA/G9F5kpGmjYwPitXCNxrGttnXilS4bcjSnEhvSinWc
8CB1BsWupPtDnnvN0GXoY61clxcfx+mczzepwUzgQaaI1+HEeze3IqwcyCUeXo9U
bXbUki9g49cnC2k8IGyPZhR/6YRkKlGQMKcGbMR/oFQjWIIDF00beR0RZspZSzWN
BHodOei2hq+XyqIZCVHm4Qf5s02sLDxBov/XTn1HMP9HBxtakbjWlHHD/k8gtIAa
lJb2CKPXxZI1WuG02jz6xBcmYV1+FiFs/2M64HIoiosufmhXtiwYG0a2jqFYvv/y
Ar6bTtL01m3wvUqbG9SOhCxaL8AHlk+BU1zFbQRMmBj15R6TQqJ7iWc7Fq1USwSP
fx4JXDb1y5uqJ3g3AqoK
=lSY1
-----END PGP SIGNATURE-----