From 1.int32 at gmail.com  Fri Sep  1 09:49:48 2017
From: 1.int32 at gmail.com (=?UTF-8?B?QmFsw6F6cyBLw6lyaQ==?=)
Date: Fri, 1 Sep 2017 09:49:48 +0200
Subject: [gnutls-help] failing DTLS handshake
In-Reply-To: <CAGyX=JkRkB7uNgRXcZ5tQFnPvQpJmPM0HOegQeUW00jCjDWUDg@mail.gmail.com>
References: <CAGyX=J=JAs=Sji06CWFVKN+pK5QEfUBNMo1C5-yjea1=WtSfMQ@mail.gmail.com>
 <1503997609.6018.2.camel@gmail.com>
 <CAGyX=JkRkB7uNgRXcZ5tQFnPvQpJmPM0HOegQeUW00jCjDWUDg@mail.gmail.com>
Message-ID: <CAGyX=Jmd08HHSXDud=xG+VYEuwT1N-OtAJ628E90TReqSaee9w@mail.gmail.com>

Hi,

I do not know if this is right place to ask about source code but I found
something that may cause this problem:

This message is printed to the log:
531 [2017-Aug-24 10:13:38.768832] [7f9cf8ff9700] [ML_LoadB23] [trace]
GnuTLS -- [level:3]: ASSERT: buffers.c[parse_handshake_header]:961
532 [2017-Aug-24 10:13:38.768852] [7f9cf8ff9700] [ML_LoadB23] [trace]
GnuTLS -- [level:3]: ASSERT:
buffers.c[_gnutls_parse_record_buffered_msgs]:1292
533 [2017-Aug-24 10:13:38.768873] [7f9cf8ff9700] [ML_LoadB23] [trace]
GnuTLS -- [level:1]: Invalid handshake packet headers. Discarding.

The check at buffers.c:956 fails (condition becomes true) if the
hsk->start_offset == hsk->end_offset which is the case here (fragment
length is 1). By the way, a part of the condition that is checked at lines
956 to 959 is checked just before (lines 951-952).

Balazs Keri


2017-08-29 11:40 GMT+02:00 Bal?zs K?ri <1.int32 at gmail.com>:

> Hi,
>
> Here is more data included:
> sequence numbers in format [epoch.sequence]
> The client sends more ClientHello (these are discarded) before the server
> is connected and ready to receive messages.
> The client and server are started cleanly (no message exchange happens
> before).
> The message with epoch 1 is detected as duplicate but I do not see
> messages with epoch 1 before it.
> Fragment offsets and fragment lengths looks OK.
>
> client->server:
> ClientHello[0.0] (total 164 bytes)
> client->server:
> ClientHello[0.1] (total 164 bytes)
> client->server:
> ClientHello[0.2] (total 164 bytes)
>
> client->server:
> ClientHello[0.3] (total 164 bytes)
>
> server->client:
> ServerHello[0.0],Certificate[0.1],CertificateRequest[0.2],
> ServerHelloDone[0.3] (total 1159 bytes)
>
> client->server:
> Certificate(Fragment)(243)[0.4],Certificate(Fragment)(243)[0.5],
> Certificate(Fragment)(243)[0.6],Certificate(Fragment)(243)[0.7],Certificat
> e(Fragment)(13)[0.8],ClientKeyExchange(142)[0.9],CertificateVerify(62)
> [0.10],CertificateVerify(92)[0.11] (total 1427 bytes)
>
> client->server:
> ChangeCipherSpec(1)[0.12],EncryptedHandshakeMessage(64)[1.0] (total 133
> bytes)
>
> Bal?zs K?ri
>
> 2017-08-29 11:06 GMT+02:00 Nikos Mavrogiannopoulos <
> n.mavrogiannopoulos at gmail.com>:
>
>> On Mon, 2017-08-28 at 10:08 +0200, Bal?zs K?ri wrote:
>> > Hi!
>>
>> > 533 [2017-Aug-24 10:13:38.768873]  GnuTLS -- [level:1]: Invalid
>> > handshake packet headers. Discarding.
>> > 569 [2017-Aug-24 10:13:38.770813]  GnuTLS -- [level:5]:
>> > REC[0x7f9ce0013ea0]: Discarded duplicate message[1.0]: Handshake
>>
>> Check what the sent client record numbers are. That message was
>> detected as duplicate.
>>
>> regards,
>> Nikos
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170901/271b1df0/attachment.html>

From nmav at gnutls.org  Wed Sep  6 13:12:11 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 6 Sep 2017 13:12:11 +0200
Subject: [gnutls-help] [gnutls-devel] GnuTLS 3.6.0 released
In-Reply-To: <20170829152335.GF25801@redhat.com>
References: <1503298804.9015.4.camel@gnutls.org>
 <20170829152335.GF25801@redhat.com>
Message-ID: <CAJU7zaLMYgA=MeUCN4qtuiaDg3BCNaHXS-eFavYs5zp-Cohc1Q@mail.gmail.com>

On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote:
>> We are proud to announce a new GnuTLS release: Version 3.6.0.
>>
>> GnuTLS is a modern C library that implements the standard network
>> security protocol Transport Layer Security (TLS), for use by network
>> applications.  GnuTLS is developed for GNU/Linux, but works on many
>> Unix-like systems as well as Windows.
>>
>> The GnuTLS library is distributed under the terms of the GNU Lesser
>> General Public License version 2 (or later).
>>
>> The project pages of the library are available at:
>> http://www.gnutls.org/
>
> [snip]
>
>> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification
>>    of certificates signed with SHA1 is now considered insecure and will
>>    fail, unless flags intended to enable broken algorithms are set. Other uses
>>    of SHA1 are still allowed. This can be reverted on compile time with the configure
>>    flag --enable-sha1-support.
>
> FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will
> be generating certs that will never validate, since that API is hardcoded to
> use SHA1.  This tripped up the libvirt & QEMU test suites which used that API.
> I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256
> explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign()
> to use SHA256 too, or must it stick with SHA1 for backcompat reasons ?

It is documented as signing with SHA1, so changing will introduce a
behavioral "breakage", though I am not sure whether it matters in the
end.

> If so, it would be worth putting a note in the API docs that any use of
> gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted.

The options seem to be:
 * deprecate the API and force applications specify explicitly a hash
for signing
 * Update/break the ABI for 3.6 and make the underlying algorithm used
to be undefined (i.e., a secure but unspecified one).

I kind of like the second option, as applications may hard-code a
digest which will bring the problem back when that hash is broken. Any
other opinions/options?

regards,
Nikos

PS. I have still not managed to run the libvirt and openconnect test
suites under CI. gitlab runners for some reason cannot detect errors
from fedpkg and a failing build is detected as successful. I'd
appreciate any help on that item.
https://gitlab.com/gnutls/gnutls/merge_requests/477
https://gitlab.com/gnutls/gnutls/-/jobs/29756798


From nmav at gnutls.org  Wed Sep  6 13:34:55 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 6 Sep 2017 13:34:55 +0200
Subject: [gnutls-help] failing DTLS handshake
In-Reply-To: <CAGyX=Jmd08HHSXDud=xG+VYEuwT1N-OtAJ628E90TReqSaee9w@mail.gmail.com>
References: <CAGyX=J=JAs=Sji06CWFVKN+pK5QEfUBNMo1C5-yjea1=WtSfMQ@mail.gmail.com>
 <1503997609.6018.2.camel@gmail.com>
 <CAGyX=JkRkB7uNgRXcZ5tQFnPvQpJmPM0HOegQeUW00jCjDWUDg@mail.gmail.com>
 <CAGyX=Jmd08HHSXDud=xG+VYEuwT1N-OtAJ628E90TReqSaee9w@mail.gmail.com>
Message-ID: <CAJU7zaLN5=sxC3z7+07JXtSLZS7T4pKJOeyRr1tXP7TTGoeubA@mail.gmail.com>

On Fri, Sep 1, 2017 at 9:49 AM, Bal?zs K?ri <1.int32 at gmail.com> wrote:
> Hi,
>
> I do not know if this is right place to ask about source code but I found
> something that may cause this problem:
>
> This message is printed to the log:
> 531 [2017-Aug-24 10:13:38.768832] [7f9cf8ff9700] [ML_LoadB23] [trace] GnuTLS
> -- [level:3]: ASSERT: buffers.c[parse_handshake_header]:961
> 532 [2017-Aug-24 10:13:38.768852] [7f9cf8ff9700] [ML_LoadB23] [trace] GnuTLS
> -- [level:3]: ASSERT: buffers.c[_gnutls_parse_record_buffered_msgs]:1292
> 533 [2017-Aug-24 10:13:38.768873] [7f9cf8ff9700] [ML_LoadB23] [trace] GnuTLS
> -- [level:1]: Invalid handshake packet headers. Discarding.
>
> The check at buffers.c:956 fails (condition becomes true) if the
> hsk->start_offset == hsk->end_offset which is the case here (fragment length
> is 1).

Hi,
 If fragment length is 1, shouldn't start_offset be 0 and end_offset
be 1? Do you have some reproducer for that?

regards,
Nikos


From nmav at gnutls.org  Wed Sep  6 13:39:44 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 6 Sep 2017 13:39:44 +0200
Subject: [gnutls-help] [gnutls-devel] GnuTLS 3.6.0 released
In-Reply-To: <20170906112831.GN15510@redhat.com>
References: <1503298804.9015.4.camel@gnutls.org>
 <20170829152335.GF25801@redhat.com>
 <CAJU7zaLMYgA=MeUCN4qtuiaDg3BCNaHXS-eFavYs5zp-Cohc1Q@mail.gmail.com>
 <20170906112831.GN15510@redhat.com>
Message-ID: <CAJU7zaKPjdk7dNERmdk7r88MpbA-+1q2O+Fk2PecLnLiXhgupA@mail.gmail.com>

On Wed, Sep 6, 2017 at 1:28 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Wed, Sep 06, 2017 at 01:12:11PM +0200, Nikos Mavrogiannopoulos wrote:
>> On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> > On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote:
>> >> We are proud to announce a new GnuTLS release: Version 3.6.0.
>> >>
>> >> GnuTLS is a modern C library that implements the standard network
>> >> security protocol Transport Layer Security (TLS), for use by network
>> >> applications.  GnuTLS is developed for GNU/Linux, but works on many
>> >> Unix-like systems as well as Windows.
>> >>
>> >> The GnuTLS library is distributed under the terms of the GNU Lesser
>> >> General Public License version 2 (or later).
>> >>
>> >> The project pages of the library are available at:
>> >> http://www.gnutls.org/
>> >
>> > [snip]
>> >
>> >> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification
>> >>    of certificates signed with SHA1 is now considered insecure and will
>> >>    fail, unless flags intended to enable broken algorithms are set. Other uses
>> >>    of SHA1 are still allowed. This can be reverted on compile time with the configure
>> >>    flag --enable-sha1-support.
>> >
>> > FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will
>> > be generating certs that will never validate, since that API is hardcoded to
>> > use SHA1.  This tripped up the libvirt & QEMU test suites which used that API.
>> > I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256
>> > explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign()
>> > to use SHA256 too, or must it stick with SHA1 for backcompat reasons ?
>>
>> It is documented as signing with SHA1, so changing will introduce a
>> behavioral "breakage", though I am not sure whether it matters in the
>> end.
>>
>> > If so, it would be worth putting a note in the API docs that any use of
>> > gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted.
>>
>> The options seem to be:
>>  * deprecate the API and force applications specify explicitly a hash
>> for signing
>>  * Update/break the ABI for 3.6 and make the underlying algorithm used
>> to be undefined (i.e., a secure but unspecified one).
>>
>> I kind of like the second option, as applications may hard-code a
>> digest which will bring the problem back when that hash is broken. Any
>> other opinions/options?
>
> Is there any way to let gnutls_x509_crt_sign2() take a system priority
> as an alternative to a fixed algorithm ?  That way we can just pass
> "@SYSTEM" when generating a cert and be confident that gnutls will pick
> an algorithm that works when a session is set to use "@SYSTEM" priority
> string too.

The @SYSTEM applies to TLS sessions only, and there is nothing similar
to global configuration for non-TLS functionality.

>> PS. I have still not managed to run the libvirt and openconnect test
>> suites under CI. gitlab runners for some reason cannot detect errors
>> from fedpkg and a failing build is detected as successful. I'd
>> appreciate any help on that item.
>> https://gitlab.com/gnutls/gnutls/merge_requests/477
>> https://gitlab.com/gnutls/gnutls/-/jobs/29756798
>
> Perhaps it is confused by having multiple entries in the script:
> block. Does it work if you just chain them all together in a single
> command. eg
> make && make install && fedpkg-wrapper apps/libvirt && ....

I've pushed a version like that:
https://gitlab.com/gnutls/gnutls/-/jobs/31497850

regards,
Nikos


From dkg at fifthhorseman.net  Wed Sep  6 17:57:09 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 06 Sep 2017 11:57:09 -0400
Subject: [gnutls-help] [gnutls-devel] GnuTLS 3.6.0 released
In-Reply-To: <CAJU7zaLMYgA=MeUCN4qtuiaDg3BCNaHXS-eFavYs5zp-Cohc1Q@mail.gmail.com>
References: <1503298804.9015.4.camel@gnutls.org>
 <20170829152335.GF25801@redhat.com>
 <CAJU7zaLMYgA=MeUCN4qtuiaDg3BCNaHXS-eFavYs5zp-Cohc1Q@mail.gmail.com>
Message-ID: <87y3prbz1m.fsf@fifthhorseman.net>

On Wed 2017-09-06 13:12:11 +0200, Nikos Mavrogiannopoulos wrote:
> The options seem to be:
>  * deprecate the API and force applications specify explicitly a hash
> for signing
>  * Update/break the ABI for 3.6 and make the underlying algorithm used
> to be undefined (i.e., a secure but unspecified one).

fwiw, i prefer the second option.  It's always good to have a "do what
you currently think is best" simple API.

This also resolves the request for a "@SYSTEM" mechanism for _sign2(),
since the way to do that would just be to use _sign().  I don't even
think this is a large enough API/behavioral change to _sign() to warrant
an SONAME bump, personally, esp. since SHA1 is deprecated for this
purpose.

Thanks for thinking this through!

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170906/f045b222/attachment.sig>

From nmav at gnutls.org  Fri Sep  8 10:16:30 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 8 Sep 2017 10:16:30 +0200
Subject: [gnutls-help] [gnutls-devel] GnuTLS 3.6.0 released
In-Reply-To: <87y3prbz1m.fsf@fifthhorseman.net>
References: <1503298804.9015.4.camel@gnutls.org>
 <20170829152335.GF25801@redhat.com>
 <CAJU7zaLMYgA=MeUCN4qtuiaDg3BCNaHXS-eFavYs5zp-Cohc1Q@mail.gmail.com>
 <87y3prbz1m.fsf@fifthhorseman.net>
Message-ID: <CAJU7zaK+NN1z0+qE73_qTCW3J5w29GeUEWyL7fp-AD33Q_Rvbg@mail.gmail.com>

On Wed, Sep 6, 2017 at 5:57 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Wed 2017-09-06 13:12:11 +0200, Nikos Mavrogiannopoulos wrote:
>> The options seem to be:
>>  * deprecate the API and force applications specify explicitly a hash
>> for signing
>>  * Update/break the ABI for 3.6 and make the underlying algorithm used
>> to be undefined (i.e., a secure but unspecified one).
>
> fwiw, i prefer the second option.  It's always good to have a "do what
> you currently think is best" simple API.
>
> This also resolves the request for a "@SYSTEM" mechanism for _sign2(),
> since the way to do that would just be to use _sign().  I don't even
> think this is a large enough API/behavioral change to _sign() to warrant
> an SONAME bump, personally, esp. since SHA1 is deprecated for this
> purpose.

A merge request incorporating these:
https://gitlab.com/gnutls/gnutls/merge_requests/504/


From pwithopf at adiscon.com  Fri Sep  8 11:55:53 2017
From: pwithopf at adiscon.com (Pascal Withopf)
Date: Fri, 8 Sep 2017 11:55:53 +0200
Subject: [gnutls-help] More specific output when an error occurs
Message-ID: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>

Hi everyone,

when using GnuTLS in Rsyslog and the key file is empty then the following
error occurs from function gnutls_certificate_set_x509_key_file().

2017-09-07T16:07:43.981768+02:00 localhost rsyslogd[28575]: unexpected
GnuTLS error -302 in nsd_gtls.c:577: Error in parsing.  [v8.30.0.master try
http://www.rsyslog.com/e/2078 ]
2017-09-07T16:07:43.982798+02:00 localhost rsyslogd[28575]: error adding
our certificate. GnuTLS error -302, message: 'Error in parsing.', key:
'/home/usr/proj/certs/machine-key.pem', cert:
'/home/usr/proj/certs/machine-cert.pem' [v8.30.0.master try
http://www.rsyslog.com/e/2078 ]

Only after using the functions gnutls_global_set_log_function() and
gnutls_global_set_log_level() you can find more detailed output.

8676.147805605:main thread    : nsd_gtls.c: GnuTLS log msg, level 9: Could
not find '-----BEGIN RSA PRIVATE KEY'
8676.147809763:main thread    : nsd_gtls.c: GnuTLS log msg, level 9: Could
not find '-----BEGIN DSA PRIVATE KEY'
8676.147813879:main thread    : nsd_gtls.c: GnuTLS log msg, level 9: Could
not find '-----BEGIN EC PRIVATE KEY'

My question: Is there a way to get a more detailed output like this without
having to look at the whole debug output.

My goal is to give more specific information when the error occurs, so
Rsyslog users will know what is wrong without having to dig deeper
themselfs.

Best Regards
Pascal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170908/85dd2cfd/attachment.html>

From nmav at gnutls.org  Fri Sep  8 14:54:53 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 8 Sep 2017 14:54:53 +0200
Subject: [gnutls-help] More specific output when an error occurs
In-Reply-To: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>
References: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>
Message-ID: <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>

On Fri, Sep 8, 2017 at 11:55 AM, Pascal Withopf <pwithopf at adiscon.com> wrote:
> Hi everyone,
>
> when using GnuTLS in Rsyslog and the key file is empty then the following
> error occurs from function gnutls_certificate_set_x509_key_file().
>
> 2017-09-07T16:07:43.981768+02:00 localhost rsyslogd[28575]: unexpected
> GnuTLS error -302 in nsd_gtls.c:577: Error in parsing.  [v8.30.0.master try
> http://www.rsyslog.com/e/2078 ]
> 2017-09-07T16:07:43.982798+02:00 localhost rsyslogd[28575]: error adding our
> certificate. GnuTLS error -302, message: 'Error in parsing.', key:
> '/home/usr/proj/certs/machine-key.pem', cert:
> '/home/usr/proj/certs/machine-cert.pem' [v8.30.0.master try
> http://www.rsyslog.com/e/2078 ]
>
> Only after using the functions gnutls_global_set_log_function() and
> gnutls_global_set_log_level() you can find more detailed output.
>
> 8676.147805605:main thread    : nsd_gtls.c: GnuTLS log msg, level 9: Could
> not find '-----BEGIN RSA PRIVATE KEY'
> 8676.147809763:main thread    : nsd_gtls.c: GnuTLS log msg, level 9: Could
> not find '-----BEGIN DSA PRIVATE KEY'
> 8676.147813879:main thread    : nsd_gtls.c: GnuTLS log msg, level 9: Could
> not find '-----BEGIN EC PRIVATE KEY'
>
> My question: Is there a way to get a more detailed output like this without
> having to look at the whole debug output.>
> My goal is to give more specific information when the error occurs, so
> Rsyslog users will know what is wrong without having to dig deeper
> themselfs.

I am not sure if I understand the request, but isn't the quoted text sufficient?
> 2017-09-07T16:07:43.982798+02:00 localhost rsyslogd[28575]: error adding our
> certificate. GnuTLS error -302, message: 'Error in parsing.', key:
> '/home/usr/proj/certs/machine-key.pem', cert:
> '/home/usr/proj/certs/machine-cert.pem' [v8.30.0.master try
> http://www.rsyslog.com/e/2078 ]

You can run any application using GNUTLS_DEBUG_LEVEL=4 (or higher) to
get more debugging information, but I'd expect end-user applications
like rsyslog to provide a proper error message, such as error in
parsing certificate or key.

regards,
Nikos


From pwithopf at adiscon.com  Fri Sep  8 16:46:28 2017
From: pwithopf at adiscon.com (Pascal Withopf)
Date: Fri, 8 Sep 2017 16:46:28 +0200
Subject: [gnutls-help] More specific output when an error occurs
In-Reply-To: <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>
References: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>
 <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>
Message-ID: <CAJGZxNTHnnir=J73mXnzphq1+8sMUsZeq0O4sFTwPsckzXk=0A@mail.gmail.com>

At the moment rsyslog is giving the quoted text as error, but it is not
sufficient.
I made the experience, that users want to know more in detail what went
wrong.

The error is generic because it only tells you that something went wrong in
parsing.
But I would like to add the information What went wrong.

So my question is, if there is a way to get more information on the
specific error, like "Could not find '-----BEGIN EC PRIVATE KEY" without
having to look at the whole debugging output.

Best Regards
Pascal

2017-09-08 14:54 GMT+02:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Fri, Sep 8, 2017 at 11:55 AM, Pascal Withopf <pwithopf at adiscon.com>
> wrote:
> > Hi everyone,
> >
> > when using GnuTLS in Rsyslog and the key file is empty then the following
> > error occurs from function gnutls_certificate_set_x509_key_file().
> >
> > 2017-09-07T16:07:43.981768+02:00 localhost rsyslogd[28575]: unexpected
> > GnuTLS error -302 in nsd_gtls.c:577: Error in parsing.  [v8.30.0.master
> try
> > http://www.rsyslog.com/e/2078 ]
> > 2017-09-07T16:07:43.982798+02:00 localhost rsyslogd[28575]: error
> adding our
> > certificate. GnuTLS error -302, message: 'Error in parsing.', key:
> > '/home/usr/proj/certs/machine-key.pem', cert:
> > '/home/usr/proj/certs/machine-cert.pem' [v8.30.0.master try
> > http://www.rsyslog.com/e/2078 ]
> >
> > Only after using the functions gnutls_global_set_log_function() and
> > gnutls_global_set_log_level() you can find more detailed output.
> >
> > 8676.147805605:main thread    : nsd_gtls.c: GnuTLS log msg, level 9:
> Could
> > not find '-----BEGIN RSA PRIVATE KEY'
> > 8676.147809763:main thread    : nsd_gtls.c: GnuTLS log msg, level 9:
> Could
> > not find '-----BEGIN DSA PRIVATE KEY'
> > 8676.147813879:main thread    : nsd_gtls.c: GnuTLS log msg, level 9:
> Could
> > not find '-----BEGIN EC PRIVATE KEY'
> >
> > My question: Is there a way to get a more detailed output like this
> without
> > having to look at the whole debug output.>
> > My goal is to give more specific information when the error occurs, so
> > Rsyslog users will know what is wrong without having to dig deeper
> > themselfs.
>
> I am not sure if I understand the request, but isn't the quoted text
> sufficient?
> > 2017-09-07T16:07:43.982798+02:00 localhost rsyslogd[28575]: error
> adding our
> > certificate. GnuTLS error -302, message: 'Error in parsing.', key:
> > '/home/usr/proj/certs/machine-key.pem', cert:
> > '/home/usr/proj/certs/machine-cert.pem' [v8.30.0.master try
> > http://www.rsyslog.com/e/2078 ]
>
> You can run any application using GNUTLS_DEBUG_LEVEL=4 (or higher) to
> get more debugging information, but I'd expect end-user applications
> like rsyslog to provide a proper error message, such as error in
> parsing certificate or key.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170908/9a74d5cc/attachment-0001.html>

From nmav at gnutls.org  Mon Sep 11 15:01:00 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 11 Sep 2017 15:01:00 +0200
Subject: [gnutls-help] More specific output when an error occurs
In-Reply-To: <CAJGZxNTHnnir=J73mXnzphq1+8sMUsZeq0O4sFTwPsckzXk=0A@mail.gmail.com>
References: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>
 <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>
 <CAJGZxNTHnnir=J73mXnzphq1+8sMUsZeq0O4sFTwPsckzXk=0A@mail.gmail.com>
Message-ID: <CAJU7za++pU-_MqCvyCBJtmeja6kRjvrmOZ+VP+CKCkckJbJ0wg@mail.gmail.com>

On Fri, Sep 8, 2017 at 4:46 PM, Pascal Withopf <pwithopf at adiscon.com> wrote:
> At the moment rsyslog is giving the quoted text as error, but it is not
> sufficient.
> I made the experience, that users want to know more in detail what went
> wrong.
> The error is generic because it only tells you that something went wrong in
> parsing.
> But I would like to add the information What went wrong.

That's up to application to report correct errors. rsyslog knows that
this is an error at the certificate loading routine, and it's a
parsing error. Thus it can display something much more user friendly
rather than displaying the gnutls error code in isolation.

> So my question is, if there is a way to get more information on the specific
> error, like "Could not find '-----BEGIN EC PRIVATE KEY" without having to
> look at the whole debugging output.

That is unfortunately debugging output. This is not intended for
end-user to see, unless debugging. Imagine what would be the actual
message if that was a DER or a PKCS#12 file.

regards,
Nikos


From gregs at sloop.net  Mon Sep 11 15:56:37 2017
From: gregs at sloop.net (Gregory Sloop)
Date: Mon, 11 Sep 2017 06:56:37 -0700
Subject: [gnutls-help] More specific output when an error occurs
In-Reply-To: <CAJU7za++pU-_MqCvyCBJtmeja6kRjvrmOZ+VP+CKCkckJbJ0wg@mail.gmail.com>
References: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com> 
 <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>
 <CAJGZxNTHnnir=J73mXnzphq1+8sMUsZeq0O4sFTwPsckzXk=0A@mail.gmail.com>
 <CAJU7za++pU-_MqCvyCBJtmeja6kRjvrmOZ+VP+CKCkckJbJ0wg@mail.gmail.com>
Message-ID: <889995081.20170911065637@sloop.net>



NM> On Fri, Sep 8, 2017 at 4:46 PM, Pascal Withopf <pwithopf at adiscon.com> wrote:
>> At the moment rsyslog is giving the quoted text as error, but it is not
>> sufficient.
>> I made the experience, that users want to know more in detail what went
>> wrong.
>> The error is generic because it only tells you that something went wrong in
>> parsing.
>> But I would like to add the information What went wrong.

NM> That's up to application to report correct errors. rsyslog knows that
NM> this is an error at the certificate loading routine, and it's a
NM> parsing error. Thus it can display something much more user friendly
NM> rather than displaying the gnutls error code in isolation.

>> So my question is, if there is a way to get more information on the specific
>> error, like "Could not find '-----BEGIN EC PRIVATE KEY" without having to
>> look at the whole debugging output.

NM> That is unfortunately debugging output. This is not intended for
NM> end-user to see, unless debugging. Imagine what would be the actual
NM> message if that was a DER or a PKCS#12 file.

Having, myself, just gone through setup of RSyslog with TLS - I'll second that RSyslog is absolutely HORRIBLE in providing any really helpful output about any of the TLS layer stuff. It either works, or doesn't - but IMO it gives you absolutely nothing useful as to why.

But, IMO, this is really a RSyslog problem. They have terrible documentation on setting it up too. It doesn't surprise me in the least that they also don't provide any easily accessible output about problems with TLS.

The root problem, IMO, is: Neat software, really poor development of user-friendly output. 
But that's all on RSyslog. Lean on them. IMO, they should be getting the "Bad dog. No treat for you!" routine. :) 
[But I suspect that's likely to result in little change.]

-Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170911/96868d3e/attachment.html>

From pwithopf at adiscon.com  Wed Sep 13 11:54:39 2017
From: pwithopf at adiscon.com (Pascal Withopf)
Date: Wed, 13 Sep 2017 11:54:39 +0200
Subject: [gnutls-help] More specific output when an error occurs
In-Reply-To: <CAJU7za++pU-_MqCvyCBJtmeja6kRjvrmOZ+VP+CKCkckJbJ0wg@mail.gmail.com>
References: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>
 <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>
 <CAJGZxNTHnnir=J73mXnzphq1+8sMUsZeq0O4sFTwPsckzXk=0A@mail.gmail.com>
 <CAJU7za++pU-_MqCvyCBJtmeja6kRjvrmOZ+VP+CKCkckJbJ0wg@mail.gmail.com>
Message-ID: <CAJGZxNQMXP8NkimDX+DL10a61z8yc4uNGF+_O-WC09+jRr=ksg@mail.gmail.com>

2017-09-11 15:01 GMT+02:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Fri, Sep 8, 2017 at 4:46 PM, Pascal Withopf <pwithopf at adiscon.com>
> wrote:
> > At the moment rsyslog is giving the quoted text as error, but it is not
> > sufficient.
> > I made the experience, that users want to know more in detail what went
> > wrong.
> > The error is generic because it only tells you that something went wrong
> in
> > parsing.
> > But I would like to add the information What went wrong.
>
> That's up to application to report correct errors. rsyslog knows that
> this is an error at the certificate loading routine, and it's a
> parsing error. Thus it can display something much more user friendly
> rather than displaying the gnutls error code in isolation.
>

How would a more user friendly output look like in your opinion?
I'm trying to improve it, but at the moment I only get the error code from
gnutls_certificate_set_x509_key_file() and don't know what I can do with it.

>
> > So my question is, if there is a way to get more information on the
> specific
> > error, like "Could not find '-----BEGIN EC PRIVATE KEY" without having to
> > look at the whole debugging output.
>
> That is unfortunately debugging output. This is not intended for
> end-user to see, unless debugging. Imagine what would be the actual
> message if that was a DER or a PKCS#12 file.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170913/b43145b3/attachment.html>

From nmav at gnutls.org  Thu Sep 14 08:14:58 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 14 Sep 2017 08:14:58 +0200
Subject: [gnutls-help] More specific output when an error occurs
In-Reply-To: <CAJGZxNQMXP8NkimDX+DL10a61z8yc4uNGF+_O-WC09+jRr=ksg@mail.gmail.com>
References: <CAJGZxNSjqAnem0OYwxF516cteXORhiV7=N-QJQ-bUQP5u1qK1A@mail.gmail.com>
 <CAJU7zaLj7TJbrCHb9KRaQkey-UKBrn+VaZrxc-tBb1+UkqmOSA@mail.gmail.com>
 <CAJGZxNTHnnir=J73mXnzphq1+8sMUsZeq0O4sFTwPsckzXk=0A@mail.gmail.com>
 <CAJU7za++pU-_MqCvyCBJtmeja6kRjvrmOZ+VP+CKCkckJbJ0wg@mail.gmail.com>
 <CAJGZxNQMXP8NkimDX+DL10a61z8yc4uNGF+_O-WC09+jRr=ksg@mail.gmail.com>
Message-ID: <CAJU7zaJfFjSJ9q5eC2z=gLqUyKDahKP1rHC2jhjw=jZwSWxtVw@mail.gmail.com>

On Wed, Sep 13, 2017 at 11:54 AM, Pascal Withopf <pwithopf at adiscon.com> wrote:
>> On Fri, Sep 8, 2017 at 4:46 PM, Pascal Withopf <pwithopf at adiscon.com>
>> wrote:
>> > At the moment rsyslog is giving the quoted text as error, but it is not
>> > sufficient.
>> > I made the experience, that users want to know more in detail what went
>> > wrong.
>> > The error is generic because it only tells you that something went wrong
>> > in
>> > parsing.
>> > But I would like to add the information What went wrong.
>>
>> That's up to application to report correct errors. rsyslog knows that
>> this is an error at the certificate loading routine, and it's a
>> parsing error. Thus it can display something much more user friendly
>> rather than displaying the gnutls error code in isolation.

> How would a more user friendly output look like in your opinion?
> I'm trying to improve it, but at the moment I only get the error code from
> gnutls_certificate_set_x509_key_file() and don't know what I can do with it.

What is the goal of that message? I suppose you want to instruct the
user to go check it for potential problems. That is, if the error code
is GNUTLS_E_PARSING_ERROR, I'd print "There was an issue parsing the
certificate or private key files, please check for potential errors.".
If it is a GNUTLS_E_FILE_ERROR, then you could print in a similar
message that one of the files cannot be accessed.

regards,
Nikos


From jgh at wizmail.org  Thu Sep 14 11:14:55 2017
From: jgh at wizmail.org (Jeremy Harris)
Date: Thu, 14 Sep 2017 10:14:55 +0100
Subject: [gnutls-help] GnuTLS 3.6.0 released
In-Reply-To: <1503298804.9015.4.camel@gnutls.org>
References: <1503298804.9015.4.camel@gnutls.org>
Message-ID: <003c4877-2de0-5f38-74c1-8066975fe288@wizmail.org>

Hi,

https://gnutls.org/reference/gnutls-abstract.html
says, for gnutls_privkey_sign_hash() :-

"Note that, not all algorithm support signing already hashed data. When
 signing with Ed25519, gnutls_privkey_sign_data() should be used."


Meantime there's a draft[1] for extending DKIM to use Ed25519 signatures
which wants to use signing of an already-computed hash, as opposed
to a hash-plus-signing operation.

[ Subissue: sha256 hash, specifically.  The GnuTLS docs do not seem
to say _what_ hashes are acceptable for what signing algorithms; only
that there's a way to request a hash that is "preferred", and that
for some signings that hash might be mandatory].

The draft refers to RFC 8032, which defines both "Pure" and "Hash"
variants of signing  (section 4).

Is there intent to support the Pure variant of Ed25519 signing in
future?
-- 
Thanks,
  Jeremy

1: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-06


From 1.int32 at gmail.com  Thu Sep 14 15:09:26 2017
From: 1.int32 at gmail.com (=?UTF-8?B?QmFsw6F6cyBLw6lyaQ==?=)
Date: Thu, 14 Sep 2017 15:09:26 +0200
Subject: [gnutls-help] failing DTLS handshake
In-Reply-To: <CAJU7zaLN5=sxC3z7+07JXtSLZS7T4pKJOeyRr1tXP7TTGoeubA@mail.gmail.com>
References: <CAGyX=J=JAs=Sji06CWFVKN+pK5QEfUBNMo1C5-yjea1=WtSfMQ@mail.gmail.com>
 <1503997609.6018.2.camel@gmail.com>
 <CAGyX=JkRkB7uNgRXcZ5tQFnPvQpJmPM0HOegQeUW00jCjDWUDg@mail.gmail.com>
 <CAGyX=Jmd08HHSXDud=xG+VYEuwT1N-OtAJ628E90TReqSaee9w@mail.gmail.com>
 <CAJU7zaLN5=sxC3z7+07JXtSLZS7T4pKJOeyRr1tXP7TTGoeubA@mail.gmail.com>
Message-ID: <CAGyX=JnDqacqA9yCoYYvESqxnQJKUvajF28igWET-3G1srDs7Q@mail.gmail.com>

Hi,

I can reproduce the problem with the attached test programs. It is a
primitive server and client put together from the example code and removed
unneeded things. It can be compiled with gnutls-3.5.15 (or older versions,
earliest tested is 3.3.19). It is important to use the provided .pem files.
After starting server and client the handshake times out.

Bal?zs K?ri

2017-09-06 13:34 GMT+02:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Fri, Sep 1, 2017 at 9:49 AM, Bal?zs K?ri <1.int32 at gmail.com> wrote:
> > Hi,
> >
> > I do not know if this is right place to ask about source code but I found
> > something that may cause this problem:
> >
> > This message is printed to the log:
> > 531 [2017-Aug-24 10:13:38.768832] [7f9cf8ff9700] [ML_LoadB23] [trace]
> GnuTLS
> > -- [level:3]: ASSERT: buffers.c[parse_handshake_header]:961
> > 532 [2017-Aug-24 10:13:38.768852] [7f9cf8ff9700] [ML_LoadB23] [trace]
> GnuTLS
> > -- [level:3]: ASSERT: buffers.c[_gnutls_parse_record_buffered_msgs]:1292
> > 533 [2017-Aug-24 10:13:38.768873] [7f9cf8ff9700] [ML_LoadB23] [trace]
> GnuTLS
> > -- [level:1]: Invalid handshake packet headers. Discarding.
> >
> > The check at buffers.c:956 fails (condition becomes true) if the
> > hsk->start_offset == hsk->end_offset which is the case here (fragment
> length
> > is 1).
>
> Hi,
>  If fragment length is 1, shouldn't start_offset be 0 and end_offset
> be 1? Do you have some reproducer for that?
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170914/334b2175/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-fraglen-1.tar.gz
Type: application/x-gzip
Size: 20891 bytes
Desc: not available
URL: </pipermail/attachments/20170914/334b2175/attachment-0001.bin>

From nmav at gnutls.org  Fri Sep 15 15:33:49 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Sep 2017 15:33:49 +0200
Subject: [gnutls-help] GnuTLS 3.6.0 released
In-Reply-To: <003c4877-2de0-5f38-74c1-8066975fe288@wizmail.org>
References: <1503298804.9015.4.camel@gnutls.org>
 <003c4877-2de0-5f38-74c1-8066975fe288@wizmail.org>
Message-ID: <CAJU7zaKwL7HFYVsKLvd9b+G9amvhm6jvrs74kmAe1x5GUw_xCA@mail.gmail.com>

On Thu, Sep 14, 2017 at 11:14 AM, Jeremy Harris <jgh at wizmail.org> wrote:
> Hi,
>
> https://gnutls.org/reference/gnutls-abstract.html
> says, for gnutls_privkey_sign_hash() :-
>
> "Note that, not all algorithm support signing already hashed data. When
>  signing with Ed25519, gnutls_privkey_sign_data() should be used."
>
>
> Meantime there's a draft[1] for extending DKIM to use Ed25519 signatures
> which wants to use signing of an already-computed hash, as opposed
> to a hash-plus-signing operation.
>
> [ Subissue: sha256 hash, specifically.  The GnuTLS docs do not seem
> to say _what_ hashes are acceptable for what signing algorithms; only
> that there's a way to request a hash that is "preferred", and that
> for some signings that hash might be mandatory].
>
> The draft refers to RFC 8032, which defines both "Pure" and "Hash"
> variants of signing  (section 4).
>
> Is there intent to support the Pure variant of Ed25519 signing in
> future?

It's quite unfortunate that dkim decided to use the pre-hashed variant
because the curdle working group, which defined the PKIX additions for
ed25519, decided to drop it. As such, you can only sign using the
"pure" variant for certificates, as well as the PKCS#7/CMS structures.
That is this the reason only this variant was introduced in gnutls.

regards,
Nikos


From nmav at gnutls.org  Fri Sep 15 16:36:52 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Sep 2017 16:36:52 +0200
Subject: [gnutls-help] failing DTLS handshake
In-Reply-To: <CAGyX=JnDqacqA9yCoYYvESqxnQJKUvajF28igWET-3G1srDs7Q@mail.gmail.com>
References: <CAGyX=J=JAs=Sji06CWFVKN+pK5QEfUBNMo1C5-yjea1=WtSfMQ@mail.gmail.com>
 <1503997609.6018.2.camel@gmail.com>
 <CAGyX=JkRkB7uNgRXcZ5tQFnPvQpJmPM0HOegQeUW00jCjDWUDg@mail.gmail.com>
 <CAGyX=Jmd08HHSXDud=xG+VYEuwT1N-OtAJ628E90TReqSaee9w@mail.gmail.com>
 <CAJU7zaLN5=sxC3z7+07JXtSLZS7T4pKJOeyRr1tXP7TTGoeubA@mail.gmail.com>
 <CAGyX=JnDqacqA9yCoYYvESqxnQJKUvajF28igWET-3G1srDs7Q@mail.gmail.com>
Message-ID: <CAJU7za+qMi4ZEphk2LsM0e7BngPKuM03-bd4-=p7eGoL0+wtPQ@mail.gmail.com>

On Thu, Sep 14, 2017 at 3:09 PM, Bal?zs K?ri <1.int32 at gmail.com> wrote:
> Hi,
>
> I can reproduce the problem with the attached test programs. It is a
> primitive server and client put together from the example code and removed
> unneeded things. It can be compiled with gnutls-3.5.15 (or older versions,
> earliest tested is 3.3.19). It is important to use the provided .pem files.
> After starting server and client the handshake times out.


Very helpful, thank you.