[TLS] Antw: Re: Suspicious behaviour of TLS server implementations

Hi,

thanks for your detailed answers. Yes, we are in contact with the developers of the implementations in question and fixes are going to be implemented. I just wanted to get an idea of what is considered the correct or at least most appropriate behaviour in each case.

Thanks and Cheers

>>> Martin Thomson <martin.thomson@gmail.com> 10.09.16 12.39 Uhr >>>
I think that Martin (R) provided you with the answers I would have.

Have you filed bugs against the servers in question for the issues
that you have seen?

On 10 September 2016 at 00:23, Andreas Walz
<andreas.walz@hs-offenburg.de> 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).
> While running our tests against a bunch of different TLS (server)
> implementations, we found several types of suspicious behaviour (see below).
> As the TLS specification left me with doubts on what the correct behaviour
> should be, I'd like to raise this questions here (please let me know if this
> is not the appropriate place or this has been answered before).
>
> (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. 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).
>
> (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.
>
> (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)?
>
> Thank you very much.
>
> Cheers,
> Andi
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>