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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
