Re: [TLS] Suspicious behaviour of TLS server implementations

[Hubert Kario <[e-mail]>]

On Friday, 9 September 2016 16:23:52 CEST Andreas Walz wrote:
> Dear all,
> 
> we are working on an approach/framework for testing TLS implementations
> (currently only servers, but clients are planned for the future as well).

are you aware of the tlsfuzzer framework?
https://github.com/tomato42/tlsfuzzer

> (2) In a ClientHello several server implementations don't ignore data
> following the extension list. That is, they somehow seem to ignore the
> length field of the extension list and simply consider everything following
> the list of compression methods as extensions. Aside from this certainly
> being a deviation from the specification, I was wondering whether a server
> should silently ignore data following the extension list (e.g. for the sake
> of upward compatibility) or (as one could infer from RFC5246, p. 42) send
> e.g. a "decode_error" alert.

It is explicit in RFC 3546, section 2.1:
https://tools.ietf.org/html/rfc3546#section-2.1

   A server that supports the extensions mechanism MUST accept only
   client hello messages in either the original or extended ClientHello
   format, and (as for all other messages) MUST check that the amount of
   data in the message precisely matches one of these formats; if not
   then it MUST send a fatal "decode_error" alert.  This overrides the
   "Forward compatibility note" in [TLS].

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic