[gnutls-devel] interoperability issue 3.3.x vs. 3.5.5

[Nikos Mavrogiannopoulos]

On Wed, Oct 26, 2016 at 2:52 PM, Stefan Bühler <stbuehler at lighttpd.net> wrote:
> Hi,
> On 10/26/2016 01:12 PM, Andreas Metzler wrote:
>> Hello,
>> a gnutls server running 3.5.5 is not accessible by a client using GnuTLS
>> 3.3.x. This popped up in Debian https://bugs.debian.org/841723 against
>> 3.3.8 vs 3.5.5 but also applies to 3.3.25/3.5.5. It is reproducible with
>> gnutls-serv and gnutls-cli without any special options (just
>> --x509keyfile/--x509certfile).
>
> I think the original bug in https://bugs.debian.org/841723 could be
> about something else; gnutls-cli.out in message #40 shows receiving "554
> S" instead of a ServerHello - the reporter probably didn't actually use
> --starttls-proto=smtp, but without the real log it is hard to say.
> That said I also reproduced the issue; the fault is with the older
> version, as it requires a CertificateStatus message if ServerHello
> included the (empty) "status_request" extension, although RFC 6066
> explicitly states:
>
>    Note that a server MAY also choose not to send a "CertificateStatus"
>    message, even if has received a "status_request" extension in the
>    client hello message and has sent a "status_request" extension in the
>    server hello message.

Right. That was identified and fixed in the 3.4.x branch but it was
never backported to 3.3.x.
I've done it just now at:
https://gitlab.com/gnutls/gnutls/compare/aaddef3787a7df83dc2bcfb3bd510535f1601b46...417a7934d66f907c1bb5a2cd285782345625b1ac

> So the new gnutls code doesn't do anything wrong by replying with an
> empty "status_request" extension, even if there is no chance of sending
> a CertificateStatus message, just the old versions can't handle it.

I think that I should revert that behavior, and make sure that the
releases are compatible between them. An even better move would be to
add an interop check between 3.3.x and the latest master.

regards,
Nikos