Interoperability issues (Debian Bug #348046)

[Simon Josefsson]

Marc Haber <mh+gnutls-devel at zugschlus.de> writes:

>> In other words, openssl doesn't implement the TLS over SMTP protocol
>> properly, and exim4 rejects the connection.  This is clearly an openssl
>> bug and has nothing to do with gnutls.
>
> Agreed, and fixed in Debian sid.

Great.

>> > (D) gnutls-cli-debug not having an --starttls option (is this a bug in
>> >     gnutls-cli-debug? What is gnutls-cli-debug's Differnence from
>> >     gnutls-cli in the first place?)
>> 
>> Right, gnutls-cli-debug doesn't support starttls.  If someone wants to
>> work on providing that capability, feel free to submit patches...  I
>> note that openssl doesn't have any similar tool with starttls support
>> either.
>
> This is now Debian Bug #467022

Thanks.

>> The difference between gnutls-cli and gnutls-cli-debug is that the
>> former is a simple interactive TLS client (with some starttls support)
>> and the latter is a non-interactive debug tool.
>
> But it is obviously needed sometimes to debug an application.

Yeah.  It may be simpler to merge the gnutls-cli-debug functionality
into gnutls-cli -- the gnutls-cli-debug tool is quite limited and
doesn't handle certificates or anything.  The report is also rather
incorrect in some situations.

>> > (F) Vincent Lefevre saying (Message 130), that outgoign messages also
>> >     reduce entropy.
>> 
>> Which may be true.
>
> It is true, but can be remedied by having exim save the random seed to
> a file. However, Andreas' patch makes exim segfault occasionally, and
> I have therefore backed out the patch for the time being.

Ok.  I think a random seed is the right solution here.

>> > (G) Andrew McGlashan finding it impossible to connect to gnutls-serv
>> >     with incredimail (giving debug output in Message 224).
>
> That one is Debian Bug #459323 and has been pinned down to incredimail
> being unable to handle client certificate requests. This can be worked
> around by exim configuration and is clearly brokenness on
> incredimail's part. Additionally, this incredimail issue also happens
> when exim (in Debian's default configuration which requests client
> ceritificates, but does not act on them by default)  is compiled
> against OpenSSL and also explains why Postfix works.

Interesting.  Maybe some documentation on this issue is warranted,
especially if it affects other implementations than incredimail as well.

>> > I think this is a good case to show what happens when the error
>> > messages are too simple. This bug report is a mess of different issues
>> > since GnuTLS obviously returns the same, quite generic, error message
>> > text for a number of different issues. People look into the BTS for
>> > their error message and attach their issue to the existing bug report,
>> > leading to the horrible mess this bug report is. I'd like to use this
>> > opportunity to pledge for more distinctive error messages.
>> 
>> Before we know exactly what is the cause for the various problem, we
>> can't know what a better error message would be.
>
> I think that if the error message would indicate at which stage of
> negotiation the failure occurred it would be great.
>
> For example, the incredimail issue would have been more easily pinned
> down if the error message logged on the server would have been
> something like "A TLS packet with an unexpected length was received in
> response to our client certificate request", or the random MAC padding
> by "Connection was dropped by the remote side after we announced that
> we would like to do random MAC padding".

One "problem" with TLS is that each packet contains many requests so it
can be difficult to know what triggered the problem.  The handshake is
typically just two round trips.

However, to be able to improve the error messages here, I need to know
where in gnutls the error code was generated.  A debug log containing
the gnutls_assert() outputs from where the error code is generated is
needed.

>>   Reporting very narrow error messages is known to lead to security
>>   problems, where the other side can use different behaviour based on
>>   different error messages to attack the server.  So some caution to
>>   be very verbose in error message is warranted for security
>>   applications.
>
> Agreed, but it doesn't hurt to be a little more verbose in the local
> logs.

Sure.

>> I'm not sure if this message will help much to move things further.
>> There are simply too many completely different problems in this bug
>> report, and the original submitter stopped responding long time ago.
>> But I tried to answer the questions you raised at least.
>
> I really appreciate that and will try to dissect the bug into its
> sub-problems in dedicated BTS entries in the near future. I will also
> try to comment on the things that I have snipped in this message in
> due time.

Many thanks for your diligent work!

/Simon