Dear all,
sorry for bringing up this thread again. We were doing some further studies
with TLS implementations (all TLS 1.2) for embedded systems and found more
cases where, within substructures of handshake messages, trailing data without
any associated field in the specification is *not* rejected. One example is the
"Supported Elliptic Curves Extension" [RFC4492]:
struct {
NamedCurve elliptic_curve_list<1..2^16-1>;
} EllipticCurveList;
which is parsed as if there was an additional field "trailing" absorbing all
remaining data:
struct {
NamedCurve elliptic_curve_list<1..2^16-1>;
opaque trailing[];
} EllipticCurveList;
(There are various other places where this happens.)
I must say I'm having hard times finding any rationale behind ignoring such
data rather than rejecting it (and aborting the handshake). In fact, most
implementations do reject such messages and send a "decode_error" alert.
Do you see any argument why ignoring such trailing data would be acceptable (or
even desirable)?
Thanks again and Cheers,
Andi Walz
___________________________________
Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>> "Andreas Walz" <andreas.w...@hs-offenburg.de> 09/14/16 4:20 PM >>>
Hi,
>>> Hubert Kario <hka...@redhat.com> 09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer
@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
repository before and I skimmed through the code. However, I didn't run the
code and I don't know details about the way it is generating input. Is there
some paper or presentation about it?
>>> Peter Gutmann <pgut...@cs.auckland.ac.nz> 09/14/16 1:39 PM >>>
> My code checks for extensions all the way down, but I could quite easily be
> persuaded that ignoring trailing garbage is OK too, based on what earlier
> versions of TLS did. Like RFC 3546 originally did for extensions, some future
> RFC might add a new field at the end, so not failing on finding more data may
> be a good thing. Or at least I can't see why it would be a bad thing.
@Peter Gutmann: Thanks for your take on that. Actually, and I might easily be
missing something here, I do see some issues with adding new fields to the
ClientHello in the future (i.e. following the "client_hello_extension_list").
As far as I can see, there is no way within a ClientHello to convey some kind
of a version of the ClientHello format itself (as the ClientHello's version
field is just indicating the highest version the client supports). That is, the
only mechanism I see here is the same as the one that allowed to add extensions
to a ClientHello message with RFC3546. However, that door has explicitly been
closed therein in section 2.1 (as Hubert Kario pointed out)
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].
A similar statement is given in RFC5246, section 7.4.1.2.:
A server MUST accept ClientHello
messages both with and without the extensions field, and (as for all
other messages) it 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.
Thus, to my understanding, any new field in the ClientHello would automatically
break backward compatibility (at least with older compliant servers or unless
everyone explicitly skips a MUST check in the interest of forward
compatibility).
___________________________________
Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>> Peter Gutmann <pgut...@cs.auckland.ac.nz> 09/14/16 1:39 PM >>>
Martin Rex <m...@sap.com> writes:
>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.
Yup, and I'd say it's perfectly valid behaviour. Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.
>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter. Personally I prefer
>aborting in case of garbage trailing TLS extensions.
My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did. Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing. Or at least I can't see why it would be a bad thing.
>What the server does in presence of multiple TLS extensions of the same type
>is implementation defined. I think it would be extremely reasonable for a
>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.
+1. Remembering that you've already done a known extension is one thing, but
having to track a potentially arbitrary number of extensions that you don't
know what to do with anyway doesn't seem worthwhile. And then there's the
same problem as with ignoring extra data at the end of the hello, at some
point a future RFC may define an extension where having duplicate copies makes
sense or is even required for things to work. So you don't really gain
anything by ignoring duplicate unknown extensions, and will potentially break
things in the future if you do reject them.
Having said that, some extensions are purely signalling extensions, like EMS
and EtM. I'm not sure if there's any problem with accepting doubles of those,
it could just be the other side being emphatic. Consider how you'd need to
report this to the user, "shut down the TLS connection because I saw two
copies of some extension you've never heard of before", you can imagine what a
user who sees that would think of the anal-retentive &^@#* who added special
code to the handshake in order to reject it if this condition is encountered.
Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
