Re: [TLS] Suspicious behaviour of TLS server implementations

[[e-mail] (Martin Rex)]

My personal take on your questions:


Andreas Walz wrote:
> 
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression
> even if that has not been in the ClientHello's list.

Sounds like reasonable behaviour (improving interop) which does not cause
any security issues.

>
> The specification is rather clear that null compression MUST be part of
> the list.  However, I'm not aware of any clear statement about what a
> compliant server should do in case it receives a ClientHello without
> null compression. My best guess would have been that in such cases the
> server should abort the handshake (at least if it does not support
> whatever the client proposed).

The requirement is about the Client.  The Server behaviour is un(der)specifed.
The server choosing null compression anyway and continuing looks pretty
reasonable to me (least amount of code, so the safest to implement).

Aborting by the server would be OK with the specification, but not
necessarily reasonable.  Consider that there was a time when compression
within TLS was available and widely used.  A server that wanted and would
use TLS compression when offered would behave sort-of unrational when
complaining about an absence of a compression method it does not intend
to use (in presence of the compression method it wants to use).

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.


> 
> (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.

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.

When I looked at OpenSSL's implemenation of the extensions parser a few
years ago, I noticed that it was ignoring (I believe up to 3) trailing bytes.
(the shortest possible TLS extension is 4 bytes).


>
> (3) If a ClientHello contains multiple extensions of the same type,
> several server implementations proceed with the handshake (even if they
> parse these specific extensions). The specification again is clear that
> "there MUST NOT be more than one extension of the same type".
> However, what should a server do in case there are? Again, my guess
> would be that it should abort the handshake. Should this also be the
> case for extensions that a server simply ignores (as it e.g. doesn't
> know them)?

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.


-Martin