From dkg at fifthhorseman.net  Fri Jan  2 18:59:38 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 02 Jan 2015 12:59:38 -0500
Subject: [gnutls-help] certtool: Serial number only 31 bit?
In-Reply-To: <CAJU7zaKt2A-y7da26=vMwwrYO53Z3VKes2thBK_cXqu5-rZA5w@mail.gmail.com>
References: <20140515100805.GD22643@raven.inka.de>
 <CAJU7zaKt2A-y7da26=vMwwrYO53Z3VKes2thBK_cXqu5-rZA5w@mail.gmail.com>
Message-ID: <87fvbtoygl.fsf@alice.fifthhorseman.net>

[ sorry, digging up an old thread as i happen to be thinking about the
  issue today ]

On Thu 2014-05-15 07:49:14 -0400, Nikos Mavrogiannopoulos wrote:
> On Thu, May 15, 2014 at 12:08 PM, Josef Wolf <jw at raven.inka.de> wrote:
>> Hello,
>> I am currently trying to use UUIDs (as Bignum) for the serial number of
>> certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard
>> time to specify more than 31 bits in the template file.
>> With a prefix of 0x (indicating hex number), I get serial number 0. Ough!
>> Given as a decimal number, the number is truncated to 0x7fffffff.
>> Is this a limitation in certtool or am I missing something?
>
> It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0.

If the value received from the user for the serial number exceeds 63
bits, should GnuTLS throw an error rather than truncate?  I worry that
silently proceeding with a truncation seems likely to cause people using
certtool to issue multiple certificates with serial numbers of
0x7fffffffffffffff.

It seems like an error and a failure would be better than truncation
here.

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

From nmav at gnutls.org  Sun Jan  4 20:38:37 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 04 Jan 2015 20:38:37 +0100
Subject: [gnutls-help] certtool: Serial number only 31 bit?
In-Reply-To: <87fvbtoygl.fsf@alice.fifthhorseman.net>
References: <20140515100805.GD22643@raven.inka.de>
 <CAJU7zaKt2A-y7da26=vMwwrYO53Z3VKes2thBK_cXqu5-rZA5w@mail.gmail.com>
 <87fvbtoygl.fsf@alice.fifthhorseman.net>
Message-ID: <1420400317.5377.1.camel@gnutls.org>

On Fri, 2015-01-02 at 12:59 -0500, Daniel Kahn Gillmor wrote:
> [ sorry, digging up an old thread as i happen to be thinking about the
>   issue today ]
> 
> On Thu 2014-05-15 07:49:14 -0400, Nikos Mavrogiannopoulos wrote:
> > On Thu, May 15, 2014 at 12:08 PM, Josef Wolf <jw at raven.inka.de> wrote:
> >> Hello,
> >> I am currently trying to use UUIDs (as Bignum) for the serial number of
> >> certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard
> >> time to specify more than 31 bits in the template file.
> >> With a prefix of 0x (indicating hex number), I get serial number 0. Ough!
> >> Given as a decimal number, the number is truncated to 0x7fffffff.
> >> Is this a limitation in certtool or am I missing something?
> >
> > It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0.
> If the value received from the user for the serial number exceeds 63
> bits, should GnuTLS throw an error rather than truncate?  I worry that
> silently proceeding with a truncation seems likely to cause people using
> certtool to issue multiple certificates with serial numbers of
> 0x7fffffffffffffff.

Does it truncate? As far as I see, it already throws an error for
out-of-range numbers.

regards,
Niko



From dkg at fifthhorseman.net  Sun Jan  4 20:57:08 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 04 Jan 2015 14:57:08 -0500
Subject: [gnutls-help] certtool: Serial number only 31 bit?
In-Reply-To: <1420400317.5377.1.camel@gnutls.org>
References: <20140515100805.GD22643@raven.inka.de>	
 <CAJU7zaKt2A-y7da26=vMwwrYO53Z3VKes2thBK_cXqu5-rZA5w@mail.gmail.com>	
 <87fvbtoygl.fsf@alice.fifthhorseman.net> <1420400317.5377.1.camel@gnutls.org>
Message-ID: <54A99B14.2010606@fifthhorseman.net>

On 01/04/2015 02:38 PM, Nikos Mavrogiannopoulos wrote:
> On Fri, 2015-01-02 at 12:59 -0500, Daniel Kahn Gillmor wrote:
>> [ sorry, digging up an old thread as i happen to be thinking about the
>>   issue today ]
>>
>> On Thu 2014-05-15 07:49:14 -0400, Nikos Mavrogiannopoulos wrote:
>>> On Thu, May 15, 2014 at 12:08 PM, Josef Wolf <jw at raven.inka.de> wrote:
>>>> Hello,
>>>> I am currently trying to use UUIDs (as Bignum) for the serial number of
>>>> certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard
>>>> time to specify more than 31 bits in the template file.
>>>> With a prefix of 0x (indicating hex number), I get serial number 0. Ough!
>>>> Given as a decimal number, the number is truncated to 0x7fffffff.
>>>> Is this a limitation in certtool or am I missing something?
>>>
>>> It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0.
>> If the value received from the user for the serial number exceeds 63
>> bits, should GnuTLS throw an error rather than truncate?  I worry that
>> silently proceeding with a truncation seems likely to cause people using
>> certtool to issue multiple certificates with serial numbers of
>> 0x7fffffffffffffff.
> 
> Does it truncate? As far as I see, it already throws an error for
> out-of-range numbers.

sorry, i should have been more clear that i was talking about certtool.

for example:

 certtool -p key.pem
 echo 'serial = 10000000000000000000' > template
 echo 'serial = 10000000000000000001' > template2


then these two commands:

 certtool --generate-self-signed --load-privkey key.pem \
          --template template 2>&1 | grep Serial
 certtool --generate-self-signed --load-privkey key.pem \
          --template template2 2>&1 | grep Serial

both produce:

	Serial Number (hex): 7fffffffffffffff



	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150104/0e0a78cb/attachment.sig>

From nmav at gnutls.org  Sun Jan  4 23:21:34 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 04 Jan 2015 23:21:34 +0100
Subject: [gnutls-help] certtool: Serial number only 31 bit?
In-Reply-To: <54A99B14.2010606@fifthhorseman.net>
References: <20140515100805.GD22643@raven.inka.de>
 <CAJU7zaKt2A-y7da26=vMwwrYO53Z3VKes2thBK_cXqu5-rZA5w@mail.gmail.com>
 <87fvbtoygl.fsf@alice.fifthhorseman.net>
 <1420400317.5377.1.camel@gnutls.org> <54A99B14.2010606@fifthhorseman.net>
Message-ID: <1420410094.14321.1.camel@gnutls.org>

On Sun, 2015-01-04 at 14:57 -0500, Daniel Kahn Gillmor wrote:

> >>> It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0.
> >> If the value received from the user for the serial number exceeds 63
> >> bits, should GnuTLS throw an error rather than truncate?  I worry that
> >> silently proceeding with a truncation seems likely to cause people using
> >> certtool to issue multiple certificates with serial numbers of
> >> 0x7fffffffffffffff.
> > 
> > Does it truncate? As far as I see, it already throws an error for
> > out-of-range numbers.
> sorry, i should have been more clear that i was talking about certtool.
> for example:
>  certtool -p key.pem
>  echo 'serial = 10000000000000000000' > template
>  echo 'serial = 10000000000000000001' > template2

Correct. I've now added a check.

regards,
Nikos




From rogerdpack2 at gmail.com  Tue Jan  6 00:40:22 2015
From: rogerdpack2 at gmail.com (Roger Pack)
Date: Mon, 5 Jan 2015 16:40:22 -0700
Subject: [gnutls-help] mkstemp mingw x86_64 failure
Message-ID: <CAL1QdWfpNDC5DbtkL+K6-EnoBy-z7b7jydY+75+0fPhHaaBgFw@mail.gmail.com>

As a note, gnutls cross compiler ok i386 [mingw-w64] however with x86_64

CCLD danetool.exe
danetool.o:danetool.c:(.text+0x1266): undefined reference to `mkstemp'
collect2: error: ld returned 1 exit status

Unless you feel this is something that mingw-w64 out to "just provide"
or what not. Kind of weird that it succeeds in i386.

Cheers!
-roger-


From nmav at gnutls.org  Tue Jan  6 16:45:19 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 6 Jan 2015 16:45:19 +0100
Subject: [gnutls-help] mkstemp mingw x86_64 failure
In-Reply-To: <CAL1QdWfpNDC5DbtkL+K6-EnoBy-z7b7jydY+75+0fPhHaaBgFw@mail.gmail.com>
References: <CAL1QdWfpNDC5DbtkL+K6-EnoBy-z7b7jydY+75+0fPhHaaBgFw@mail.gmail.com>
Message-ID: <CAJU7zaKUXOmTxBYu_nk=fz0b+xHbWkXqSvWqqm8n7Ynn4X4Zcg@mail.gmail.com>

On Tue, Jan 6, 2015 at 12:40 AM, Roger Pack <rogerdpack2 at gmail.com> wrote:
> As a note, gnutls cross compiler ok i386 [mingw-w64] however with x86_64
> CCLD danetool.exe
> danetool.o:danetool.c:(.text+0x1266): undefined reference to `mkstemp'
> collect2: error: ld returned 1 exit status
> Unless you feel this is something that mingw-w64 out to "just provide"
> or what not. Kind of weird that it succeeds in i386.

This program is not very useful in windows. You may as well ignore it.
I've added a fix to not compile it if the unbound libs are not found.

regards,
Nikos


From jgresula at gmail.com  Thu Jan  8 11:51:42 2015
From: jgresula at gmail.com (Jarda Gresula)
Date: Thu, 8 Jan 2015 10:51:42 +0000 (UTC)
Subject: [gnutls-help] gnutls-cli - handshake failed
Message-ID: <loom.20150108T113226-729@post.gmane.org>

Hello,

I came across a SSL handshake problem with gnutls-cli when connecting to 
some websites, see below. It is somehow specific to gnutls as 
openssl/Chrome/Firefox can connect fine. 

Is this is a bug in gnutls or do you have any ideas how to troubleshoot it?


$ gnutls-cli --version
gnutls-cli (GnuTLS) 2.12.23
Packaged by Debian (2.12.23-12ubuntu2.1)

$ gnutls-cli www.openlearning.com
Resolving 'www.openlearning.com'...
Connecting to '119.9.9.205:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.

$ gnutls-cli sequencewiz.com
Resolving 'sequencewiz.com'...
Connecting to '50.112.144.117:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.



Thank you,
-- 
Jarda



From tzz at lifelogs.com  Thu Jan  8 18:22:02 2015
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Thu, 08 Jan 2015 12:22:02 -0500
Subject: [gnutls-help] Detect whether certificate is self-signed
References: <87r3vvlg5i.fsf@arcor.de> <1419144278.6044.5.camel@gnutls.org>
 <87d27cyl79.fsf@engster.org> <m2r3vpb5ax.fsf@lifelogs.com>
 <1419616209.15986.3.camel@gnutls.org>
Message-ID: <877fwxqjb9.fsf@lifelogs.com>

On Fri, 26 Dec 2014 19:50:09 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On Wed, 2014-12-24 at 07:28 -0500, Ted Zlatanov wrote:
DE> Nikos Mavrogiannopoulos writes:
>> >> Said that, the easiest way to check for a self-signed certificate is
>> >> using gnutls_x509_crt_check_issuer() against itself.
DE> ...that's way simpler. :-)
>> Could this be abstracted into a function so, if GnuTLS implements it
>> differently in the future (following the RFC or something else), clients
>> don't have to be changed?  It seems to be fairly useful.

NM>  Not sure if I follow. gnutls_x509_crt_check_issuer() is already a
NM> function, what do you think should be abstracted into a function? 

That function checks the issuer. It can be *used* to check if a
certificate is self-signed as you explained, but I didn't find that in
the docs and IMO that verification feels like it should be an enum in
`gnutls_certificate_verify_flags`.  Maybe it's good enough to just add
that usage to the docs...

Ted



From nmav at gnutls.org  Thu Jan  8 23:01:19 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 08 Jan 2015 23:01:19 +0100
Subject: [gnutls-help] gnutls-cli - handshake failed
In-Reply-To: <loom.20150108T113226-729@post.gmane.org>
References: <loom.20150108T113226-729@post.gmane.org>
Message-ID: <1420754479.11467.1.camel@gnutls.org>

On Thu, 2015-01-08 at 10:51 +0000, Jarda Gresula wrote:
> Hello,
> 
> I came across a SSL handshake problem with gnutls-cli when connecting to 
> some websites, see below. It is somehow specific to gnutls as 
> openssl/Chrome/Firefox can connect fine. 
> 
> Is this is a bug in gnutls or do you have any ideas how to troubleshoot it?

The server doesn't like something in the TLS 1.2 support of gnutls 2.12
since if you disable it, it seems to work. The same server works with
gnutls 3.2 and the only difference in the client hello of the two
versions is that gnutls 3.2 has more features enabled. 

There is no point to try debugging such an old version of gnutls; the
best is to use a more modern version (the 2.12 branch is from 2011).

regards,
Nikos




From visser at terena.org  Mon Jan 12 21:33:21 2015
From: visser at terena.org (Dick Visser)
Date: Mon, 12 Jan 2015 21:33:21 +0100
Subject: [gnutls-help] Non-interactive way of printing certs with
	gnutls-cli and --starttls
In-Reply-To: <CAEQQDNmaiT8k2oGVKwOJt5o536wJzF8m_Gqa5Pe_JY7+vMTvtg@mail.gmail.com>
References: <CAEQQDNmaiT8k2oGVKwOJt5o536wJzF8m_Gqa5Pe_JY7+vMTvtg@mail.gmail.com>
Message-ID: <CAEQQDNmaxk0o+XroQu4mgyYfAu7bSKaTqra2p5L9Pz9OzxkgCw@mail.gmail.com>

Any ideas about this?

On 26 November 2014 at 17:28, Dick Visser <visser at terena.org> wrote:
> As it says on the tin.
> I'm looking for a way to retrieve the x509 cert for SMTP servers that
> offer STARTTLS.
> gnutls-cli can be used, but you have to manually type some steps: EHOL
> blah, STARTTLS and then ctrl-D (for EOF(:
>
> visser at nagios:~$ gnutls-cli --starttls --print-cert --port 25 aspmx.l.google.com
> Resolving 'aspmx.l.google.com'...
> Connecting to '2a00:1450:400c:c09::1a:25'...
>
> - Simple Client Mode:
>
> 220 mx.google.com ESMTP fu3si8792677wib.31 - gsmtp
> EHLO blah
> 250-mx.google.com at your service, [2001:610:158:98d::45]
> 250-SIZE 35882577
> 250-8BITMIME
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-CHUNKING
> 250 SMTPUTF8
> STARTTLS
> 220 2.0.0 Ready to start TLS
> *** Starting TLS handshake
> - Certificate type: X.509
>  - Got a certificate list of 3 certificates.
>  - Certificate[0] info:
>   - subject `C=US,ST=California,L=Mountain View,O=Google
> Inc,CN=mx.google.com', issuer `C=US,O=Google Inc,CN=Google Internet
> Authority G2', RSA key 2048 bits, signed using RSA-SHA1, activated
> `2014-07-15 08:56:16 UTC', e                  xpires `2015-04-04
> 15:15:55 UTC', SHA-1 fingerprint
> `2282b379696a721505f273fa1e6bbe36f0ba01e2'
>
> -----BEGIN CERTIFICATE-----
> MIIGhDCCBWygAwIBAgIIa7+rjwrecGgwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE
> BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
> cm5ldCBBdXRob3JpdHkgRzIwHhcNMTQwNzE1MDg1NjE2WhcNMTUwNDA0MTUxNTU1
> WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
> TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEWMBQGA1UEAwwNbXgu
> Z29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALXdZYG
>
>
>
>
> I'm looking for a way to avoid the interactive steps, so that it can
> be used in scripts.
>
> Background: I have a Nagios plugin that depends on the output of
> 'openssl s_client' to retrieve the certs, like this:
>
> visser at nagios:~$ openssl s_client -showcerts -starttls smtp -connect
> aspmx.l.google.com:25 < /dev/null 2>&1
> CONNECTED(00000003)
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> verify error:num=20:unable to get local issuer certificate
> verify return:0
> ---
> Certificate chain
>  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
>    i:/C=US/O=Google Inc/CN=Google Internet Authority G2
> -----BEGIN CERTIFICATE-----
> MIIGhDCCBWygAwIBAgIIa7+rjwrecGgwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE
> BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
> cm5ldCBBdXRob3JpdHkgRzIwHhcNMTQwNzE1MDg1NjE2WhcNMTUwNDA0MTUxNTU1
> WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
> etc etc
>
> but for some reason 'openssl s_client' does not work with IPv6.
> The mail servers I want to connect to only run IPv6, so openssl fails.
>
> GnuTLS works with IPv6, the only thing left is a way to script it...
>
>
>
>
> Thanks!!
>
>
> --
> Dick Visser
> Sr. System & Networking Engineer
> G?ANT Association, Amsterdam Office (formerly TERENA)
> Singel 468D, 1017 AW Amsterdam, the Netherlands
> Tel: +31 (0) 20 530 4488
>
> G?ANT Association
> Networking. Services. People.
>
> Learn more at: http://www.g?ant.org



-- 
Dick Visser
Sr. System & Networking Engineer
G?ANT Association, Amsterdam Office (formerly TERENA)
Singel 468D, 1017 AW Amsterdam, the Netherlands
Tel: +31 (0) 20 530 4488

G?ANT Association
Networking. Services. People.

Learn more at: http://www.g?ant.org


From nmav at gnutls.org  Mon Jan 12 23:16:23 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 12 Jan 2015 23:16:23 +0100
Subject: [gnutls-help] Non-interactive way of printing certs with
 gnutls-cli and --starttls
In-Reply-To: <CAEQQDNmaxk0o+XroQu4mgyYfAu7bSKaTqra2p5L9Pz9OzxkgCw@mail.gmail.com>
References: <CAEQQDNmaiT8k2oGVKwOJt5o536wJzF8m_Gqa5Pe_JY7+vMTvtg@mail.gmail.com>
 <CAEQQDNmaxk0o+XroQu4mgyYfAu7bSKaTqra2p5L9Pz9OzxkgCw@mail.gmail.com>
Message-ID: <1421100983.4263.1.camel@gnutls.org>

On Mon, 2015-01-12 at 21:33 +0100, Dick Visser wrote:
> Any ideas about this?
On 26 November 2014 at 17:28, Dick Visser <visser at terena.org> wrote:
> > As it says on the tin.
> > I'm looking for a way to retrieve the x509 cert for SMTP servers
that
> > offer STARTTLS.
> > gnutls-cli can be used, but you have to manually type some steps:
EHOL
> > blah, STARTTLS and then ctrl-D (for EOF(:
> 

There is some mechanism in the latest gnutls versions to connect to SMTP
and IMAP. Currently only danetool, and gnutls-cli-debug use it, but it
seems pretty easy to extend to gnutls-cli as well. I don't have a quick
solution, but if you don't want to use gnutls from git, check the next
gnutls release.

regards,
Nikos




From jonetsu at teksavvy.com  Tue Jan 13 11:47:04 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Tue, 13 Jan 2015 05:47:04 -0500
Subject: [gnutls-help] Compiling with the FIPS option
Message-ID: <20150113054704.69cf7080@mevla>

Hello,

I'm trying to compile gnutls-3.3.11 with the FIPS option.  The host
already has a libgnutls.so.28 installed but, I'm using the default
location of /usr/local/lib/ so this should cause no problem.  But it
does.  Here are the details.

This is in two parts.  The first part is about the error in the
linking of gnutls-cli against the /usr/local/lib/ new install.  The
second part is about some HMAC files that are missing.

Help would be greatly appreciated !

Already in the host, (a Linux Mint 17 system, 64 bit) :

% dpkg -l | grep tls
  [...]
  libgnutls28:amd64  3.2.11-2ubuntu1

Compiling the source:

% ./configure --enable-fips140-mode

Option is really set:

  [...]
  FIPS140 mode:   yes

Building, installling:

% make
% make install

1)

Verifying that gnutls-cli is the new one from /usr/local/ :

% which gnutls-cli
/usr/local/bin/gnutls-cli

Verifying the lib link:

ldd /usr/local/bin/gnutls-cli
 libgnutls.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls.so.28
(0x00007f6c2f0e9000)

Please note that it is linked against the host's library.

Verifying the FIPS option will then appropriately report an error:

% gnutls-cli --fips140-mode

gnutls-cli: relocation error: gnutls-cli: symbol
gnutls_fips140_mode_enabled, version GNUTLS_3_1_0 not defined in file
libgnutls.so.28 with link time reference

Why does it link to the lib in /usr/lib/x86_64-linux-gnu/ instead of
using its own in /usr/local ?



2) Re-do the host's link to point to the new lib:

libgnutls.so.28 -> /usr/local/lib/libgnutls.so.28

% gnutls-cli --fips140-mode
library is NOT in FIPS140-2 mode

OK.  Exporting the env. var.:

% export GNUTLS_FORCE_FIPS_MODE=1

% gnutls-cli --fips140-mode
Error in GnuTLS initialization: Error while performing self checks.
library is in FIPS140-2 mode

Now it goes that far.  When enabling some debug output, we see that it
fails trying to access soem HMAC files.  These files are nowhere to be
found, either on the host, or in the fresh sources.

% gnutls-cli --fips140-mode

gnutls[2]: Loading: /usr/lib/x86_64-linux-gnu/libgnutls.so.28

gnutls[2]: Could not open
/usr/lib/x86_64-linux-gnu/.libgnutls.so.28.hmac for MAC testing: Error
while reading file.

gnutls[2]: Could not open
/usr/lib/x86_64-linux-gnu/fipscheck/libgnutls.so.28.hmac for MAC
testing: Error while reading file.


How to get GnuTLS compiled in the right manner to have a FIPS build ?

Thanks.


From nmav at gnutls.org  Tue Jan 13 14:25:21 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Jan 2015 14:25:21 +0100
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <20150113054704.69cf7080@mevla>
References: <20150113054704.69cf7080@mevla>
Message-ID: <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>

On Tue, Jan 13, 2015 at 11:47 AM, jonetsu at teksavvy.com
<jonetsu at teksavvy.com> wrote:
> Hello,
> I'm trying to compile gnutls-3.3.11 with the FIPS option.  The host
> already has a libgnutls.so.28 installed but, I'm using the default
> location of /usr/local/lib/ so this should cause no problem.  But it
> does.  Here are the details.
> This is in two parts.  The first part is about the error in the
> linking of gnutls-cli against the /usr/local/lib/ new install.  The
> second part is about some HMAC files that are missing.
[...]
> Verifying that gnutls-cli is the new one from /usr/local/ :
> Verifying the lib link:
> ldd /usr/local/bin/gnutls-cli
>  libgnutls.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls.so.28
> (0x00007f6c2f0e9000)
> Please note that it is linked against the host's library.

You need to run ldconfig after installation of gnutls. After you did that, if
you had /usr/local/lib in ld.so.conf it should be linked correctly.

> 2) Re-do the host's link to point to the new lib:
> libgnutls.so.28 -> /usr/local/lib/libgnutls.so.28
> % gnutls-cli --fips140-mode
> library is NOT in FIPS140-2 mode

For gnutls to enter FIPS mode, one the following should be in place:
1. environment variable GNUTLS_FORCE_FIPS_MODE=1
2. /proc/sys/crypto/fips_enabled must contain "1"
   and /etc/system-fips must exist.

> % gnutls-cli --fips140-mode
> Error in GnuTLS initialization: Error while performing self checks.
> library is in FIPS140-2 mode
> Now it goes that far.  When enabling some debug output, we see that it
> fails trying to access soem HMAC files.  These files are nowhere to be
> found, either on the host, or in the fresh sources.

FIPS requires consistency check of the crypto libraries on startup and this
is the purpose of the hmac files. These files should be generated on
the installed
system. There is the fipshmac utility you can use (that support was
made for RHEL
where this utility is available), and you need to do something like
fipshmac -d /usr/local/lib /usr/local/lib/libgnutls.so.28.*.*
prepend a dot (.) to the .hmac file name.

Repeat that for nettle and gmp.

> How to get GnuTLS compiled in the right manner to have a FIPS build ?

You don't really need the FIPS140 mode. The library works much better
without it, as it is not restricted to NIST-approved algorithms and
random number generators.

regards,
Nikos


From jonetsu at teksavvy.com  Wed Jan 14 03:28:20 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Tue, 13 Jan 2015 21:28:20 -0500
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
References: <20150113054704.69cf7080@mevla>
 <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
Message-ID: <20150113212820.706310ee@mevla>

On Tue, 13 Jan 2015 14:25:21 +0100
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

Hello,

Thanks for the reply.  It did made some progress, but it's still not
there.  I have adjusted the lib path using ldconfig, and I have gotten
the fipshmac utility from Red Hat's fipscheck package (1.4.1) and
generated a .hmac file.  Details below.  The error now seems to
revolve around not agreeing witht he fipshmac utility.

Basically. hiding all symlinks except one, the libs in /usr/local/lib/
are:

 libfipscheck.la*
 libfipscheck.so.1.2.1*
 libgnutls.la*
 libgnutls-openssl.la*
 libgnutls-openssl.so.27.0.2*
 libgnutls.so.28.41.3*
 libgnutlsxx.la*
 libgnutlsxx.so.28.1.0*
 libgnutls.so.28 -> libgnutls.so.28.41.3*

fipshmac is run in this way:

% fipshmac -d /usr/local/lib /usr/local/lib/libgnutls.so.28.*.*

And will generate in /usr/local/lib/ :

% libgnutls.so.28.41.3.hmac

Which contains:

1a9863c56622f4abeb8b58671f4036ae44131a932058299c14c7f115cbaf16fd

% gnutls-cli looks for /usr/local/lib/.libgnutls.so.28.hmac, so I rename
the hmac file:

% mv libgnutls.so.28.41.3.hmac .libgnutls.so.28.hmac


% ldd $(which gnutls-cli)
 [...]
 libgnutls.so.28 => /usr/local/lib/libgnutls.so.28 (0x00007f3fd6f64000)
 [...]
 
% gnutls-cli --fips140-mod
[...]
gnutls[2]: Loading: /usr/local/lib/libgnutls.so.28
gnutls[2]: Calculated MAC for libgnutls.so.28 does not match
gnutls[3]: ASSERT: fips.c:234
gnutls[3]: ASSERT: fips.c:358
[...]
library is in FIPS140-2 mode

Please note that I haven't generated the HMAC for nettle nor gmp yet,
since the nature of the error so far.  

The fipscheck utility has also a problem verifying the file, as it
returns a value of 13, when ran like this:

% fipscheck .libgnutls.so.28.hmac
fipscheck .libgnutls.so.28.hmac
% echo $?
13


What adjustments should now be done in order to get gnutls working in
FIPS mode ?

> You don't really need the FIPS140 mode. The library works much
> better without it, as it is not restricted to NIST-approved
> algorithms and random number generators.

Is the restriction the only drawback or is there currently a problem
using gnutls in FIPS mode ?

Regards.



From nmav at gnutls.org  Wed Jan 14 08:13:47 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 14 Jan 2015 08:13:47 +0100
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <20150113212820.706310ee@mevla>
References: <20150113054704.69cf7080@mevla>
 <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
 <20150113212820.706310ee@mevla>
Message-ID: <CAJU7zaLomxAaKw7RvxDYz7x=vdG5sKu378jPYG=x6x+BvjynNQ@mail.gmail.com>

On Wed, Jan 14, 2015 at 3:28 AM, jonetsu at teksavvy.com
<jonetsu at teksavvy.com> wrote:
> On Tue, 13 Jan 2015 14:25:21 +0100
> Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>
> Hello,
> Thanks for the reply.  It did made some progress, but it's still not
> there.  I have adjusted the lib path using ldconfig, and I have gotten
> the fipshmac utility from Red Hat's fipscheck package (1.4.1) and
> generated a .hmac file.  Details below.  The error now seems to
> revolve around not agreeing witht he fipshmac utility.

Correct, I forgot about it. You'll need to patch gnutls' fips.c to use a key
that agrees with the fipscheck package. I.e., apply the following patch:

diff --git a/lib/fips.c b/lib/fips.c
index b99da2d..ac74533 100644
--- a/lib/fips.c
+++ b/lib/fips.c
@@ -107,7 +107,7 @@ void _gnutls_fips_mode_reset_zombie(void)
 #define HOGWEED_LIBRARY_NAME "libhogweed.so.2"
 #define GMP_LIBRARY_NAME "libgmp.so.10"

-static const char fips_key[] = "I'd rather be skiing";
+static const char fips_key[] = "orboDeJITITejsirpADONivirpUkvarP";

 #define HMAC_SUFFIX ".hmac"
 #define HMAC_SIZE 32

>> You don't really need the FIPS140 mode. The library works much
>> better without it, as it is not restricted to NIST-approved
>> algorithms and random number generators.
> Is the restriction the only drawback or is there currently a problem
> using gnutls in FIPS mode ?

I'm referring to the restrictions. There is no other known problem in
FIPS140-2 mode.

regards,
Nikos


From jonetsu at teksavvy.com  Thu Jan 15 11:44:46 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Thu, 15 Jan 2015 05:44:46 -0500
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <CAJU7zaLomxAaKw7RvxDYz7x=vdG5sKu378jPYG=x6x+BvjynNQ@mail.gmail.com>
References: <20150113054704.69cf7080@mevla>
 <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
 <20150113212820.706310ee@mevla>
 <CAJU7zaLomxAaKw7RvxDYz7x=vdG5sKu378jPYG=x6x+BvjynNQ@mail.gmail.com>
Message-ID: <20150115054446.2e208ded@mevla>

On Wed, 14 Jan 2015 08:13:47 +0100
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> Correct, I forgot about it. You'll need to patch gnutls' fips.c to
> use a key that agrees with the fipscheck package. I.e., apply the
> following patch:

Thanks.  Haven't had the opportunity to try it yet.  I have a general
question regarding FIPS mode, about the way it works.  Is there a need
to modify all applications using GnuTLS to add FIPS init code, or is
there some automatic function being called when the library is loaded
(or otherwise used) by an application, that will execute all
FIPS-related checks and tests ?

Regards.


From nmav at gnutls.org  Thu Jan 15 12:43:10 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 Jan 2015 12:43:10 +0100
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <20150115054446.2e208ded@mevla>
References: <20150113054704.69cf7080@mevla>
 <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
 <20150113212820.706310ee@mevla>
 <CAJU7zaLomxAaKw7RvxDYz7x=vdG5sKu378jPYG=x6x+BvjynNQ@mail.gmail.com>
 <20150115054446.2e208ded@mevla>
Message-ID: <CAJU7za+xeA_+3fwFS-gLr+yUajv668B+zqpRchtgcQOUg3nM6w@mail.gmail.com>

On Thu, Jan 15, 2015 at 11:44 AM, jonetsu at teksavvy.com
<jonetsu at teksavvy.com> wrote:
>> Correct, I forgot about it. You'll need to patch gnutls' fips.c to
>> use a key that agrees with the fipscheck package. I.e., apply the
>> following patch:
> Thanks.  Haven't had the opportunity to try it yet.  I have a general
> question regarding FIPS mode, about the way it works.  Is there a need
> to modify all applications using GnuTLS to add FIPS init code, or is
> there some automatic function being called when the library is loaded
> (or otherwise used) by an application, that will execute all
> FIPS-related checks and tests ?

It works transparently. The checks are executed on library load, and the default
algorithm sets are modified to contain only the FIPS140-2 allowed
ciphers. The only
issue you'll have is with applications that specifically request a
non-FIPS approved
cipher like RC4 or MD5. These applications will fail (as expected).

regards,
Nikos


From rj7252 at att.com  Thu Jan 15 15:52:27 2015
From: rj7252 at att.com (JONES, BILL)
Date: Thu, 15 Jan 2015 14:52:27 +0000
Subject: [gnutls-help] Testsuite summary for GnuTLS 3.3.11
Message-ID: <2B72DD7087E4A24A895A948352DA2F9217C826B3@MISOUT7MSGUSRCD.ITServices.sbc.com>

GnuTLS Team,

Please assist.  I saw a similar issue with someone building 3.3.1, but that also included many other failures.

What do you need to assist in tracking this down?

Bill

On Solaris 10 using GCC with Solaris AS and LD compiling as 64bit.

/appl/gfpip/local_build/src/gnutls/gnutls-3.3.11/build-aux/test-driver: line 107:  8177 Segmentation Fault      (core dumped) "$@" > $log_file 2>&1
FAIL: mini-global-load


$ cat test-suite.log
=========================================
   GnuTLS 3.3.11: tests/test-suite.log
=========================================

# TOTAL: 88
# PASS:  85
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: mini-record-range
=======================


SKIP: fips-test
===============

Please note that if in FIPS140 mode, you need to assure the library's integrity prior to running this test
We are not in FIPS140 mode

FAIL: mini-global-load
======================

Segmentation Fault(coredump)


$ ls -al mini-global*
-rwxr-xr-x   1 gfp-ip   gfpipusr   22440 Jan 14 22:12 mini-global-load
-rw-r--r--   1 gfp-ip   gfpipusr       0 Jan 14 22:18 mini-global-load.log
-rw-r--r--   1 gfp-ip   gfpipusr   13400 Jan 14 22:12 mini-global-load.o
-rw-r--r--   1 gfp-ip   gfpipusr      84 Jan 14 22:18 mini-global-load.trs
gfp-ip at gfpmtipb:pts18:/appl/gfpip/local_build/build/gnutls-3.3.11/tests
$ cat mini-global-load.trs
:test-result: FAIL
:global-test-result: FAIL
:recheck: yes
:copy-in-global-log: yes


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150115/fccd315b/attachment.html>

From nmav at gnutls.org  Fri Jan 16 09:32:07 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 16 Jan 2015 09:32:07 +0100
Subject: [gnutls-help] Testsuite summary for GnuTLS 3.3.11
In-Reply-To: <2B72DD7087E4A24A895A948352DA2F9217C826B3@MISOUT7MSGUSRCD.ITServices.sbc.com>
References: <2B72DD7087E4A24A895A948352DA2F9217C826B3@MISOUT7MSGUSRCD.ITServices.sbc.com>
Message-ID: <CAJU7zaKiVCQ9X8BUsC-UBMozvTYkoTbTicHP9FN3VosWJ_DMxw@mail.gmail.com>

On Thu, Jan 15, 2015 at 3:52 PM, JONES, BILL <rj7252 at att.com> wrote:
> GnuTLS Team,
> Please assist.  I saw a similar issue with someone building 3.3.1, but that
> also included many other failures.
> What do you need to assist in tracking this down?
> FAIL: mini-global-load

The best would be to try running the failed test under valgrind and
check the output.
Also if you can use the debugger please verify that lib_init() in
gnutls_global.c is loaded during the library load.

regards,
Nikos


From nmav at gnutls.org  Sat Jan 17 09:19:48 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 17 Jan 2015 09:19:48 +0100
Subject: [gnutls-help] gnutls 3.3.12
Message-ID: <1421482788.2029.3.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.3.12. This is a bug-fix release on
the current stable branch. It also fixes compatibility issues with
servers which reject clients with an SSL 3.0 record version, which 
merely indicates the format of the record not the negotiated version.
After this version GnuTLS will set TLS 1.0 as the record version number,
unless only SSL 3.0 is enabled. 


* Version 3.3.12 (released 2015-01-17)

** libgnutls: When negotiating TLS use the lowest enabled version in
the client hello, rather than the lowest supported. In addition, do
not use SSL 3.0 as a version in the TLS record layer, unless SSL 3.0
is the only protocol supported. That addresses issues with servers that
immediately drop the connection when the encounter SSL 3.0 as the record
version number. See:
http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html

** libgnutls: Corrected encoding and decoding of ANSI X9.62 parameters.

** libgnutls: Handle zero length plaintext for VIA PadLock functions.
This solves a potential crash on AES encryption for small size plaintext.
Patch by Matthias-Christian Ott.

** libgnutls: In DTLS don't combine multiple packets which exceed MTU.
Reported by Andreas Schultz. https://savannah.gnu.org/support/?108715

** libgnutls: In DTLS decode all handshake packets present in a record
packet, in a single pass. Reported by Andreas Schultz.
https://savannah.gnu.org/support/?108712

** libgnutls: When importing a CA file with a PKCS #11 URL, simply
import the certificates, if the URL specifies objects, rather than
treating it as trust module.

** libgnutls: When importing a PKCS #11 URL and we know the type of
object we are importing, don't require the object type in the URL.

** libgnutls: fixed openpgp authentication when gnutls_certificate_set_retrieve_function2
was used by the server.

** guile: Fix compilation on MinGW. Previously only the static version of the 
'guile-gnutls-v-2' library would be built, preventing dynamic loading from Guile.

** guile: Fix harmless warning during compilation of gnutls.scm
Initially reported at <https://bugzilla.redhat.com/show_bug.cgi?id=1177847>.

** certtool: --pubkey-info will also attempt to load a public key
from stdin.

** gnutls-cli: Added --starttls-proto option. That allows to specify a
protocol for starttls negotiation.

** API and ABI modifications:
No changes since last version.



Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos




From kimleanne at gmail.com  Sun Jan 25 08:09:02 2015
From: kimleanne at gmail.com (kimleanne)
Date: Sun, 25 Jan 2015 20:09:02 +1300
Subject: [gnutls-help] RSyslog not sending messages
Message-ID: <54C4968E.1010205@gmail.com>

Hi All.

I've been having some issues with missing messages when sending to
papertrail. This occurs about once or twice a day.
This is what I'm running on the Debian Jessie server:

rsyslogd 8.4.2

libcurl3-gnutls:amd64          7.38.0-4             amd64               
easy-to-use client-side URL transfer library (GnuTLS flavour)
libgnutls-deb0-28:amd64        3.3.8-5              amd64               
GNU TLS library - main runtime library
libgnutls-openssl27:amd64      3.3.8-5              amd64               
GNU TLS library - OpenSSL wrapper
libgnutls26:amd64              2.12.20-8+deb7u2     amd64               
GNU TLS library - runtime library
rsyslog-gnutls                 8.4.2-1              amd64               
TLS protocol support for rsyslog

I've run rsyslogd manually in debug mode and have seen some output that
I'd like to know more details about.
The ryslog-debug.log produces:
unexpected GnuTLS error -53 in nsd_gtls.c:1571
and stderr when running rsyslogd manually produces:
GnuTLS error: Error in the push function

Full details are here: http://kb.monitorware.com/post25198.html along
with the relevant files.

Can you please provide some details on how I can go about getting GnuTLS
to output more data about what happens when it encounters this failure?
Do I need to turn a debug flag on? If so, how? Do I need to run manually
(I'm assuming I do)? If so, how?

Thanks for your help?

lethalduck.


From nmav at gnutls.org  Sun Jan 25 10:14:08 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Jan 2015 10:14:08 +0100
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54C4968E.1010205@gmail.com>
References: <54C4968E.1010205@gmail.com>
Message-ID: <1422177248.2034.3.camel@gnutls.org>

On Sun, 2015-01-25 at 20:09 +1300, kimleanne wrote:
> Hi All.
> 
> I've been having some issues with missing messages when sending to
> papertrail. This occurs about once or twice a day.
> This is what I'm running on the Debian Jessie server:
[...]
> I've run rsyslogd manually in debug mode and have seen some output that
> I'd like to know more details about.
> The ryslog-debug.log produces:
> unexpected GnuTLS error -53 in nsd_gtls.c:1571
> and stderr when running rsyslogd manually produces:
> GnuTLS error: Error in the push function

That means that send() returned -1 for some reason. You could enable
more output by using GNUTLS_DEBUG_LEVEL=9 prior to running the
application, and that would at least provide you with the errno.

regards,
Nikos




From michelbriand at free.fr  Mon Jan 26 13:07:57 2015
From: michelbriand at free.fr (Michel Briand)
Date: Mon, 26 Jan 2015 13:07:57 +0100
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
	possible causes
Message-ID: <20150126130757.54f14351@eridu.kheb.dyndns.org>

Hello,

I'm new to GnuTLS, cheers all.

I've a strange bug in a client/server application using GnuTLS 3.3.8-5
on Debian.

I use async (non-blocking) send/recv.

99% of my messages are ok.

But when I fork the server to proxy messages I got this strange error
on the read side. Having first successfully sent a message, the other
side (symetric = this is the same program) answers and it get the
error :

ret = -24
GNUTLS_E_DECRYPTION_FAILED
Decryption has failed

There is two possible causes : in each errno has a different value.

* 1st case: errno = 9

[13754|10] READ: Got 5 bytes from 0x9
[13754|10] READ: read 5 bytes from 0x9
[13754|10] RB: Have 0 bytes into buffer. Adding 5 bytes.
[13754|10] RB: Requested 5 bytes
[13754| 5] REC[0x89ee3c8]: SSL 3.3 Application Data packet received.
Epoch 0, length: 225
[13754| 5] REC[0x89ee3c8]: Expected Packet Application Data(23)
[13754| 5] REC[0x89ee3c8]: Received Packet Application Data(23) with
length: 225
[13754|10] READ: Got 225 bytes from 0x9
[13754|10] READ: read 225 bytes from 0x9
[13754|10] RB: Have 5 bytes into buffer. Adding 225 bytes.
[13754|10] RB: Requested 230 bytes
[13754| 3] ASSERT: gnutls_cipher.c:728
[13754| 3] ASSERT: gnutls_cipher.c:167
[13754| 3] ASSERT: gnutls_record.c:1245
[13754| 1] Discarded message[2] due to invalid decryption
[13754| 3] ASSERT: gnutls_record.c:1437
error: *** Fatal error: Decryption has failed.
error[9]: Bad file descriptor; reading from 9 [-24]

In the last message my program combines the ret error from gnutls (-24)
and errno (9, which may be irrelevant I don't know)

* 2nd case: errno = 115

[19569|10] READ: Got 5 bytes from 0x9
[19569|10] READ: read 5 bytes from 0x9
[19569|10] RB: Have 0 bytes into buffer. Adding 5 bytes.
[19569|10] RB: Requested 5 bytes
[19569| 5] REC[0x93913d8]: SSL 3.3 Application Data packet received.
Epoch 0, length: 225 [19569| 5] REC[0x93913d8]: Expected Packet
Application Data(23) [19569| 5] REC[0x93913d8]: Received Packet
Application Data(23) with length: 225 [19569|10] READ: Got 225 bytes
from 0x9 [19569|10] READ: read 225 bytes from 0x9
[19569|10] RB: Have 5 bytes into buffer. Adding 225 bytes.
[19569|10] RB: Requested 230 bytes
[19569| 3] ASSERT: gnutls_cipher.c:728
[19569| 3] ASSERT: gnutls_cipher.c:167
[19569| 3] ASSERT: gnutls_record.c:1245
[19569| 1] Discarded message[2] due to invalid decryption
[19569| 3] ASSERT: gnutls_record.c:1437
error: *** Fatal error: Decryption has failed.
error[115]: Operation now in progress; reading from 9 [-24]

In the last message my program combines the ret error from gnutls (-24)
and errno (115, which may be irrelevant I don't know).


The only Internet ressource I could found related to that error is this
thread:
http://comments.gmane.org/gmane.emacs.gnus.general/83641

which tell about this patch:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk/tls_fix.diff?h=packages/gnutls&id=bd985e895a39a755c350c7433a1edc1f8a0bd06e


Any help appreciated :) !

Best regards,
Michel





From nmav at gnutls.org  Mon Jan 26 14:57:00 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 26 Jan 2015 14:57:00 +0100
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <20150126130757.54f14351@eridu.kheb.dyndns.org>
References: <20150126130757.54f14351@eridu.kheb.dyndns.org>
Message-ID: <CAJU7zaJgHvvYaY+wt9Y5VcCyjj2bwDrGSjS4Bj1VVGGfa9e+hw@mail.gmail.com>

On Mon, Jan 26, 2015 at 1:07 PM, Michel Briand <michelbriand at free.fr> wrote:
> Hello,
> I'm new to GnuTLS, cheers all.
> I've a strange bug in a client/server application using GnuTLS 3.3.8-5
> on Debian.
> I use async (non-blocking) send/recv.
> 99% of my messages are ok.
> But when I fork the server to proxy messages I got this strange error
> on the read side. Having first successfully sent a message, the other
> side (symetric = this is the same program) answers and it get the
> error :
> ret = -24
> GNUTLS_E_DECRYPTION_FAILED
> Decryption has failed

Could you explain this scenario more? What do you mean by fork to
proxy messages? Do you work the gnutls session, and send using the
same session from two processes?

regards,
Nikos


From michelbriand at free.fr  Mon Jan 26 15:18:06 2015
From: michelbriand at free.fr (michelbriand at free.fr)
Date: Mon, 26 Jan 2015 15:18:06 +0100 (CET)
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <CAJU7zaJgHvvYaY+wt9Y5VcCyjj2bwDrGSjS4Bj1VVGGfa9e+hw@mail.gmail.com>
Message-ID: <844347006.507442410.1422281886064.JavaMail.root@zimbra74-e12.priv.proxad.net>


> Could you explain this scenario more? What do you mean by fork to
> proxy messages? Do you work the gnutls session, and send using the
> same session from two processes?
>
> regards,
> Nikos

The session init, connect and handshake are done in the parent process.

A first exchange of messages (send/recv) takes place and works well.

Then both ends fork to continue their exchanges.

Child process has duplicated sockets and memory (so session should be ok ?).

The parent closes the socket but do NOT call gnutls_bye().
It calls gnutls_deinit(session) however.

Michel


From nmav at gnutls.org  Mon Jan 26 15:28:36 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 26 Jan 2015 15:28:36 +0100
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <844347006.507442410.1422281886064.JavaMail.root@zimbra74-e12.priv.proxad.net>
References: <CAJU7zaJgHvvYaY+wt9Y5VcCyjj2bwDrGSjS4Bj1VVGGfa9e+hw@mail.gmail.com>
 <844347006.507442410.1422281886064.JavaMail.root@zimbra74-e12.priv.proxad.net>
Message-ID: <CAJU7zaJDxE9Am8b9LOo_DAVodd1bKFLfgAEvX2BS+U=VKjoT9w@mail.gmail.com>

On Mon, Jan 26, 2015 at 3:18 PM,  <michelbriand at free.fr> wrote:
>> Could you explain this scenario more? What do you mean by fork to
>> proxy messages? Do you work the gnutls session, and send using the
>> same session from two processes?
>>
>> regards,
>> Nikos
> The session init, connect and handshake are done in the parent process.
> A first exchange of messages (send/recv) takes place and works well.
> Then both ends fork to continue their exchanges.
> Child process has duplicated sockets and memory (so session should be ok ?).

Based on the error you see, I'd bet that you either receive or send by
the parent when the child already exists.

regards,
Nikos


From michelbriand at free.fr  Mon Jan 26 15:57:00 2015
From: michelbriand at free.fr (michelbriand at free.fr)
Date: Mon, 26 Jan 2015 15:57:00 +0100 (CET)
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <CAJU7zaJDxE9Am8b9LOo_DAVodd1bKFLfgAEvX2BS+U=VKjoT9w@mail.gmail.com>
Message-ID: <894115969.507598824.1422284220131.JavaMail.root@zimbra74-e12.priv.proxad.net>

> On Mon, Jan 26, 2015 at 3:18 PM,  <michelbriand at free.fr> wrote:
> >> Could you explain this scenario more? What do you mean by fork to
> >> proxy messages? Do you work the gnutls session, and send using the
> >> same session from two processes?
> >>
> >> regards,
> >> Nikos
> > The session init, connect and handshake are done in the parent
> > process.
> > A first exchange of messages (send/recv) takes place and works
> > well.
> > Then both ends fork to continue their exchanges.
> > Child process has duplicated sockets and memory (so session should
> > be ok ?).
> 
> Based on the error you see, I'd bet that you either receive or send
> by
> the parent when the child already exists.
> 
> regards,
> Nikos

Yes. Indeed.

The parent process send a last message on the socket before it is given to the child.

Is it the cause of the error ?

In that case, what could I do to prevent it ?
For example in the child I could use a gnutls "reset" function ?

Is 
Michel


From nmav at gnutls.org  Mon Jan 26 18:53:58 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 26 Jan 2015 18:53:58 +0100
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <894115969.507598824.1422284220131.JavaMail.root@zimbra74-e12.priv.proxad.net>
References: <894115969.507598824.1422284220131.JavaMail.root@zimbra74-e12.priv.proxad.net>
Message-ID: <1422294838.2015.1.camel@gnutls.org>

On Mon, 2015-01-26 at 15:57 +0100, michelbriand at free.fr wrote:

> > Based on the error you see, I'd bet that you either receive or send
> > by
> > the parent when the child already exists.
> Yes. Indeed.
> The parent process send a last message on the socket before it is given to the child.
> Is it the cause of the error ?

Yes, TLS is a stateful protocol. In that case you modify the state and
then you continue from a previous state in the child. You have to send
your last message either from the child itself, or before it is created.

> In that case, what could I do to prevent it ?
> For example in the child I could use a gnutls "reset" function ?

I was thinking to add a function to serialize the session data and
deserialize them on a different process, but I never got to finish it;
so the answer is there is no reset function.

regards,
Nikos




From michelbriand at free.fr  Mon Jan 26 19:45:02 2015
From: michelbriand at free.fr (michelbriand at free.fr)
Date: Mon, 26 Jan 2015 19:45:02 +0100 (CET)
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <1422294838.2015.1.camel@gnutls.org>
Message-ID: <100727630.508657321.1422297902316.JavaMail.root@zimbra74-e12.priv.proxad.net>

> On Mon, 2015-01-26 at 15:57 +0100, michelbriand at free.fr wrote:
> 
> > > Based on the error you see, I'd bet that you either receive or
> > > send
> > > by
> > > the parent when the child already exists.
> > Yes. Indeed.
> > The parent process send a last message on the socket before it is
> > given to the child.
> > Is it the cause of the error ?
> 
> Yes, TLS is a stateful protocol. In that case you modify the state
> and
> then you continue from a previous state in the child. You have to
> send
> your last message either from the child itself, or before it is
> created.
> 
> > In that case, what could I do to prevent it ?
> > For example in the child I could use a gnutls "reset" function ?
> 
> I was thinking to add a function to serialize the session data and
> deserialize them on a different process, but I never got to finish
> it;
> so the answer is there is no reset function.
> 
> regards,
> Nikos

Nikos,

waiting for your answer, very quick BTW, I've modified the logic 
in my program to create the child processes after all messages have 
been exchanged by parents. It works nicely.

Anyway, I think about your idea above.

Serialize the session data would be nice, but the hard task would
be to synchronize it between processes : that would go against the
very advantage of creating a child process (to not bother about
synchronization).

Is it possible to improve the documentation to help people 
not to fall into this pitfall in the future ?

Thank you very much !
Michel



From nmav at gnutls.org  Mon Jan 26 20:47:48 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 26 Jan 2015 20:47:48 +0100
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <100727630.508657321.1422297902316.JavaMail.root@zimbra74-e12.priv.proxad.net>
References: <100727630.508657321.1422297902316.JavaMail.root@zimbra74-e12.priv.proxad.net>
Message-ID: <1422301668.2015.11.camel@gnutls.org>

On Mon, 2015-01-26 at 19:45 +0100, michelbriand at free.fr wrote:

> waiting for your answer, very quick BTW, I've modified the logic 
> in my program to create the child processes after all messages have 
> been exchanged by parents. It works nicely.
> 
> Anyway, I think about your idea above.
> 
> Serialize the session data would be nice, but the hard task would
> be to synchronize it between processes : that would go against the
> very advantage of creating a child process (to not bother about
> synchronization).
> Is it possible to improve the documentation to help people 
> not to fall into this pitfall in the future ?

Which part is unclear and needs to be improved? If you have any proposed
text please feel free to suggest.

regards,
Nikos




From jonetsu at teksavvy.com  Tue Jan 27 00:15:34 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Mon, 26 Jan 2015 18:15:34 -0500
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <CAJU7za+xeA_+3fwFS-gLr+yUajv668B+zqpRchtgcQOUg3nM6w@mail.gmail.com>
References: <20150113054704.69cf7080@mevla>
 <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
 <20150113212820.706310ee@mevla>
 <CAJU7zaLomxAaKw7RvxDYz7x=vdG5sKu378jPYG=x6x+BvjynNQ@mail.gmail.com>
 <20150115054446.2e208ded@mevla>
 <CAJU7za+xeA_+3fwFS-gLr+yUajv668B+zqpRchtgcQOUg3nM6w@mail.gmail.com>
Message-ID: <20150126181534.6bef20ca@mevla>

On Thu, 15 Jan 2015 12:43:10 +0100
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> It works transparently. The checks are executed on library load, and
> the default algorithm sets are modified to contain only the FIPS140-2
> allowed ciphers. 

Hello,

  It seems to be fine.  With GNUTLS_FORCE_FIPS_MODE=1 and
  GNUTLS_DEBUG_LEVEL=7 the output ends in:

	% gnutls-cli --fips140-mode
	gnutls[2]: Enabled GnuTLS logging...
	gnutls[2]: FIPS140-2 mode: 1
	gnutls[2]: AES-128-CBC self check succeeded
	gnutls[2]: Intel SSSE3 was detected
	gnutls[2]: Intel AES accelerator was detected
  [ snip ]
	gnutls[2]: Successfully verified library MAC for libgmp.so.10
	library is in FIPS140-2 mode

  A question regarding the hmac files.  The following was previously
seen for all library files apart from GnuTLS itself:

  gnutls[2]: Could not open
  /usr/lib/x86_64-linux-gnu/.libnettle.so.4.hmac for MAC testing: Error
  while reading file.

  gnutls[2]: Could not open
  /usr/lib/x86_64-linux-gnu/fipscheck/libnettle.so.4.hmac for MAC
  testing: Error while reading file.

I had to create a fipscheck/ subdirectory and copy all hmac files
generated by fipshmac there.  So now there are hmac files in the
parent directory (prefixed by a dot) and in this fipscheck directory.
Why is this redundancy needed ?

Regards.


From nmav at gnutls.org  Tue Jan 27 08:56:19 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 27 Jan 2015 08:56:19 +0100
Subject: [gnutls-help] Compiling with the FIPS option
In-Reply-To: <20150126181534.6bef20ca@mevla>
References: <20150113054704.69cf7080@mevla>
 <CAJU7za+DqBOiF72ptr6kWFdALGXigB2d6g8VTCuuNdAuPFwR6g@mail.gmail.com>
 <20150113212820.706310ee@mevla>
 <CAJU7zaLomxAaKw7RvxDYz7x=vdG5sKu378jPYG=x6x+BvjynNQ@mail.gmail.com>
 <20150115054446.2e208ded@mevla>
 <CAJU7za+xeA_+3fwFS-gLr+yUajv668B+zqpRchtgcQOUg3nM6w@mail.gmail.com>
 <20150126181534.6bef20ca@mevla>
Message-ID: <1422345379.2049.1.camel@gnutls.org>

On Mon, 2015-01-26 at 18:15 -0500, jonetsu at teksavvy.com wrote:

>   [ snip ]
> 	gnutls[2]: Successfully verified library MAC for libgmp.so.10
> 	library is in FIPS140-2 mode
>   A question regarding the hmac files.  The following was previously
> seen for all library files apart from GnuTLS itself:
>   gnutls[2]: Could not open
>   /usr/lib/x86_64-linux-gnu/.libnettle.so.4.hmac for MAC testing: Error
>   while reading file.
>   gnutls[2]: Could not open
>   /usr/lib/x86_64-linux-gnu/fipscheck/libnettle.so.4.hmac for MAC
>   testing: Error while reading file.
> I had to create a fipscheck/ subdirectory and copy all hmac files
> generated by fipshmac there.  So now there are hmac files in the
> parent directory (prefixed by a dot) and in this fipscheck directory.
> Why is this redundancy needed ?

It is not needed. Gnutls will check in two places for these files (one
is the fallback of the other), so if you have the files in any one of
them it should be able to work as expected. Isn't that the case?

regards,
Nikos




From michelbriand at free.fr  Tue Jan 27 15:24:22 2015
From: michelbriand at free.fr (Michel Briand)
Date: Tue, 27 Jan 2015 15:24:22 +0100
Subject: [gnutls-help] error -24 GNUTLS_E_DECRYPTION_FAILED with two
 possible causes
In-Reply-To: <1422301668.2015.11.camel@gnutls.org>
References: <100727630.508657321.1422297902316.JavaMail.root@zimbra74-e12.priv.proxad.net>
 <1422301668.2015.11.camel@gnutls.org>
Message-ID: <20150127152422.4d087dbc@eridu.kheb.dyndns.org>


Nikos Mavrogiannopoulos <nmav at gnutls.org> - Mon, 26 Jan 2015 20:47:48
+0100

>On Mon, 2015-01-26 at 19:45 +0100, michelbriand at free.fr wrote:
>
>> waiting for your answer, very quick BTW, I've modified the logic 
>> in my program to create the child processes after all messages have 
>> been exchanged by parents. It works nicely.
>> 
>> Anyway, I think about your idea above.
>> 
>> Serialize the session data would be nice, but the hard task would
>> be to synchronize it between processes : that would go against the
>> very advantage of creating a child process (to not bother about
>> synchronization).
>> Is it possible to improve the documentation to help people 
>> not to fall into this pitfall in the future ?
>
>Which part is unclear and needs to be improved? If you have any
>proposed text please feel free to suggest.
>
>regards,
>Nikos

There is not clear and explicit statement regarding that.

Sure, people using GnuTLS should be aware of the basics of TLS as a
stateful protocol, but a lot of people will learn TLS by
experimentation, through the way of trying a library.

I found some explicit things, though. For example in the function
gnutls_rnd clear() documentation, one could read :

 This function is thread-safe and also fork-safe.


You could help me to understand where the problem resides :
 - is the TLS state stored in gnutls_session ?
 - is the TLS state stored somewhere else ?

Then it could be explained explicitly in the documentation.

For example in ?6.1.1 General idea, one could write :

  "TLS protocol is stateful. The session is used to save those values.
   The session cannot be shared by distinct processes : i.e. two
   processes cannot read/write simultaneously with the same session
   structure.

   The traditional UNIX model that uses fork() to pass socket to child
   process can be used with secured sockets, but one has to ensure that
   only one process will read/write after to the socket after fork()."

This is just a try to explain what I've understood so far :) !!

Regards,
Michel


From mharvey at gmail.com  Tue Jan 27 22:26:22 2015
From: mharvey at gmail.com (Matt Harvey)
Date: Wed, 28 Jan 2015 10:26:22 +1300
Subject: [gnutls-help] gnutls-3.3.12 problems with Apple Push Notifications
Message-ID: <CAKjCRQ4=0DSpn+W0gjiiktFS+t47poPXvJHe81DpL6A+0Oq7tQ@mail.gmail.com>

I was wondering if anyone has used gnutls for Apple Push Notifications?

I am trying to use gnutls-cli to establish a connection with
gateway.sandbox.push.apple.com:2195 but am encountering the following error:

Received alert [46]: Unknown certificate

I can successfully connect with openssl which would suggest my
key/certificate is OK and perhaps I need to specify a particular gnutls
priority string?

openssl connection info:

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA


And here's a subset of gnutls-cli output with debugging on:

|<5>| REC[0xa1d7e60]: SSL 3.1 Alert packet received. Epoch 0, length: 2
|<5>| REC[0xa1d7e60]: Expected Packet Handshake(22)
|<5>| REC[0xa1d7e60]: Received Packet Alert(21) with length: 2
|<10>| READ: Got 2 bytes from 0x4
|<10>| READ: read 2 bytes from 0x4
|<10>| RB: Have 5 bytes into buffer. Adding 2 bytes.
|<10>| RB: Requested 7 bytes
|<5>| REC[0xa1d7e60]: Decrypted Packet[3] Alert(21) with length: 2
|<5>| REC[0xa1d7e60]: Alert[2|46] - Unknown certificate - was received
|<3>| ASSERT: gnutls_record.c:795
|<3>| ASSERT: gnutls_record.c:802
|<3>| ASSERT: gnutls_record.c:1322
|<3>| ASSERT: gnutls_buffers.c:1392
|<3>| ASSERT: gnutls_handshake.c:1428
|<3>| ASSERT: session_ticket.c:663
|<3>| ASSERT: gnutls_handshake.c:2834
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [46]: Unknown certificate
|<5>| REC: Sending Alert[2|80] - Internal error
|<5>| REC[0xa1d7e60]: Preparing Packet Alert(21) with length: 2 and min
pad: 0
|<9>| ENC[0xa1d7e60]: cipher: AES-128-CBC, MAC: SHA1, Epoch: 1
|<11>| WRITE: enqueued 37 bytes for 0x4. Total 37 bytes.
|<11>| WRITE FLUSH: 37 bytes in buffer.
|<2>| errno: 32
|<3>| ASSERT: gnutls_buffers.c:224
|<11>| WRITE error: code -53, 37 bytes left.
|<3>| ASSERT: gnutls_buffers.c:706
|<3>| ASSERT: gnutls_record.c:566
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.



gnutls-cli-debug --port=2195 gateway.sandbox.push.apple.com
Warning: getservbyport() failed. Using port number as service.
GnuTLS debug client 3.3.12
Checking gateway.sandbox.push.apple.com:2195
unknown protocol 2195
                             for SSL 3.0 (RFC6101) support... no
unknown protocol 2195
                        whether %NO_EXTENSIONS is required... yes
unknown protocol 2195
                               whether %COMPAT is required... yes
unknown protocol 2195
                             for TLS 1.0 (RFC2246) support... no
unknown protocol 2195
 for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no
unknown protocol 2195
                             for TLS 1.1 (RFC4346) support... no
unknown protocol 2195
                                  fallback from TLS 1.1 to... failed

Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150128/924938f4/attachment-0001.html>

From nmav at gnutls.org  Wed Jan 28 00:09:35 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 28 Jan 2015 00:09:35 +0100
Subject: [gnutls-help] gnutls-3.3.12 problems with Apple Push
 Notifications
In-Reply-To: <CAKjCRQ4=0DSpn+W0gjiiktFS+t47poPXvJHe81DpL6A+0Oq7tQ@mail.gmail.com>
References: <CAKjCRQ4=0DSpn+W0gjiiktFS+t47poPXvJHe81DpL6A+0Oq7tQ@mail.gmail.com>
Message-ID: <1422400175.2027.3.camel@gnutls.org>

On Wed, 2015-01-28 at 10:26 +1300, Matt Harvey wrote:
> I was wondering if anyone has used gnutls for Apple Push
> Notifications?
[...]
> I am trying to use gnutls-cli to establish a connection with
> gateway.sandbox.push.apple.com:2195 but am encountering the following
> error:
> openssl connection info:
>New, TLSv1/SSLv3, Cipher is AES256-SHA

Judging from the ciphers, and the protocol version, that must be very
old openssl, or the server is very limited.

> And here's a subset of gnutls-cli output with debugging on:
>|<5>| REC[0xa1d7e60]: SSL 3.1 Alert packet received. Epoch 0, length: 2

Unfortunately you quote the error only, and that is in no way sufficient
to understand why is that error there. All the previous dump would be
needed to see what could have been wrong. You could also try using
conservative priority strings, such as NORMAL:%COMPAT.


> gnutls-cli-debug --port=2195 gateway.sandbox.push.apple.com
> Warning: getservbyport() failed. Using port number as service.
> GnuTLS debug client 3.3.12
> Checking gateway.sandbox.push.apple.com:2195

gnutls-cli-debug wouldn't work because the server requires a certificate
to complete the handshake.

regards,
Nikos




From kimleanne at gmail.com  Wed Jan 28 07:00:53 2015
From: kimleanne at gmail.com (kimleanne)
Date: Wed, 28 Jan 2015 19:00:53 +1300
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <1422177248.2034.3.camel@gnutls.org>
References: <54C4968E.1010205@gmail.com> <1422177248.2034.3.camel@gnutls.org>
Message-ID: <54C87B15.8060705@gmail.com>

Running rsyslog in debug mode, it ran for a couple of days with no
visible error, but then the same error occurred. I had the
GNUTLS_DEBUG_LEVEL=9 variable set prior to running rsyslogd in debug
mode, but didn't seem to get any extra info in the debug log. Should I
be looking somewhere else? 15 minutes later sshd closed my idle session.
20 minutes later sshd closed the rest of my ssh sessions. The only
message I received on stderr was "Write failed: Broken pipe"

Any other ideas?
Thanks.

On 25/01/15 22:14, Nikos Mavrogiannopoulos wrote:
> On Sun, 2015-01-25 at 20:09 +1300, kimleanne wrote:
>> Hi All.
>>
>> I've been having some issues with missing messages when sending to
>> papertrail. This occurs about once or twice a day.
>> This is what I'm running on the Debian Jessie server:
> [...]
>> I've run rsyslogd manually in debug mode and have seen some output that
>> I'd like to know more details about.
>> The ryslog-debug.log produces:
>> unexpected GnuTLS error -53 in nsd_gtls.c:1571
>> and stderr when running rsyslogd manually produces:
>> GnuTLS error: Error in the push function
> That means that send() returned -1 for some reason. You could enable
> more output by using GNUTLS_DEBUG_LEVEL=9 prior to running the
> application, and that would at least provide you with the errno.
>
> regards,
> Nikos
>
>



From nmav at gnutls.org  Wed Jan 28 10:34:09 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 28 Jan 2015 10:34:09 +0100
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54C87B15.8060705@gmail.com>
References: <54C4968E.1010205@gmail.com> <1422177248.2034.3.camel@gnutls.org>
 <54C87B15.8060705@gmail.com>
Message-ID: <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>

On Wed, Jan 28, 2015 at 7:00 AM, kimleanne <kimleanne at gmail.com> wrote:
> Running rsyslog in debug mode, it ran for a couple of days with no
> visible error, but then the same error occurred. I had the
> GNUTLS_DEBUG_LEVEL=9 variable set prior to running rsyslogd in debug
> mode, but didn't seem to get any extra info in the debug log.

You should see these errors in stderr. If you don't try running
rsyslog on command line.

regards,
Nikos


From fweimer at redhat.com  Wed Jan 28 13:24:36 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 28 Jan 2015 13:24:36 +0100
Subject: [gnutls-help] gnutls-3.3.12 problems with Apple Push
	Notifications
In-Reply-To: <CAKjCRQ4=0DSpn+W0gjiiktFS+t47poPXvJHe81DpL6A+0Oq7tQ@mail.gmail.com>
References: <CAKjCRQ4=0DSpn+W0gjiiktFS+t47poPXvJHe81DpL6A+0Oq7tQ@mail.gmail.com>
Message-ID: <54C8D504.6010906@redhat.com>

On 01/27/2015 10:26 PM, Matt Harvey wrote:
> gnutls-cli-debug --port=2195 gateway.sandbox.push.apple.com

I don't think this is supposed to work at all because Apple requires the
use of client certificates for this service.

-- 
Florian Weimer / Red Hat Product Security


From kimleanne at gmail.com  Wed Jan 28 21:19:51 2015
From: kimleanne at gmail.com (kimleanne)
Date: Thu, 29 Jan 2015 09:19:51 +1300
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
References: <54C4968E.1010205@gmail.com>	<1422177248.2034.3.camel@gnutls.org>	<54C87B15.8060705@gmail.com>
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
Message-ID: <54C94467.5050909@gmail.com>

I've tried that. Where abouts does stderr log to? Doesn't appear to be
in /var/log anywhere based on a search for "gnutls" ignoring case.

Thanks.

On 28/01/15 22:34, Nikos Mavrogiannopoulos wrote:
> On Wed, Jan 28, 2015 at 7:00 AM, kimleanne <kimleanne at gmail.com> wrote:
>> Running rsyslog in debug mode, it ran for a couple of days with no
>> visible error, but then the same error occurred. I had the
>> GNUTLS_DEBUG_LEVEL=9 variable set prior to running rsyslogd in debug
>> mode, but didn't seem to get any extra info in the debug log.
> You should see these errors in stderr. If you don't try running
> rsyslog on command line.
>
> regards,
> Nikos



From kimleanne at gmail.com  Wed Jan 28 21:23:39 2015
From: kimleanne at gmail.com (kimleanne)
Date: Thu, 29 Jan 2015 09:23:39 +1300
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54C94467.5050909@gmail.com>
References: <54C4968E.1010205@gmail.com>	<1422177248.2034.3.camel@gnutls.org>	<54C87B15.8060705@gmail.com>
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
 <54C94467.5050909@gmail.com>
Message-ID: <54C9454B.4060509@gmail.com>

To clarify: I've been running on command line as you suggested. That's
how debug mode is run. I've also tried running as daemon. Any idea where
stderr would be going in this instance other than /var/log/ ?

Thanks.

On 29/01/15 09:19, kimleanne wrote:
> I've tried that. Where abouts does stderr log to? Doesn't appear to be
> in /var/log anywhere based on a search for "gnutls" ignoring case.
>
> Thanks.
>
> On 28/01/15 22:34, Nikos Mavrogiannopoulos wrote:
>> On Wed, Jan 28, 2015 at 7:00 AM, kimleanne <kimleanne at gmail.com> wrote:
>>> Running rsyslog in debug mode, it ran for a couple of days with no
>>> visible error, but then the same error occurred. I had the
>>> GNUTLS_DEBUG_LEVEL=9 variable set prior to running rsyslogd in debug
>>> mode, but didn't seem to get any extra info in the debug log.
>> You should see these errors in stderr. If you don't try running
>> rsyslog on command line.
>>
>> regards,
>> Nikos



From nmav at gnutls.org  Wed Jan 28 22:09:06 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 28 Jan 2015 22:09:06 +0100
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54C94467.5050909@gmail.com>
References: <54C4968E.1010205@gmail.com>
 <1422177248.2034.3.camel@gnutls.org>	<54C87B15.8060705@gmail.com>
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
 <54C94467.5050909@gmail.com>
Message-ID: <1422479346.31500.2.camel@gnutls.org>

On Thu, 2015-01-29 at 09:19 +1300, kimleanne wrote:
> I've tried that. Where abouts does stderr log to? Doesn't appear to be
> in /var/log anywhere based on a search for "gnutls" ignoring case.

stderr is your terminal you run it. If it doesn't print anything, are
you sure your rsyslog is linked with gnutls 3.3.x?




From kimleanne at gmail.com  Thu Jan 29 01:01:38 2015
From: kimleanne at gmail.com (kimleanne)
Date: Thu, 29 Jan 2015 13:01:38 +1300
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <1422479346.31500.2.camel@gnutls.org>
References: <54C4968E.1010205@gmail.com>		<1422177248.2034.3.camel@gnutls.org>	<54C87B15.8060705@gmail.com>	
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>	
 <54C94467.5050909@gmail.com> <1422479346.31500.2.camel@gnutls.org>
Message-ID: <54C97862.5040509@gmail.com>

Using lld doesn't produce any sign of gnutls:

    linux-vdso.so.1 (0x00007fff5a3fc000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe749ab1000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fe749894000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe74968f000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe749487000)
    libestr.so.0 => /usr/lib/x86_64-linux-gnu/libestr.so.0
(0x00007fe749283000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe74907d000)
    liblogging-stdlog.so.0 =>
/usr/lib/x86_64-linux-gnu/liblogging-stdlog.so.0 (0x00007fe748e78000)
    libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2
(0x00007fe748c6d000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7488c3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe749cd4000)

Using dpkg-query -l '*gnutls*'
produces:

Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                     Version                  
Architecture              Description
+++-========================================-=========================-=========================-=====================================================================================
un  gnutls-bin                               <none>                   
<none>                    (no description available)
un  gnutls0                                  <none>                   
<none>                    (no description available)
un  gnutls0.4                                <none>                   
<none>                    (no description available)
un  gnutls3                                  <none>                   
<none>                    (no description available)
ii  libcurl3-gnutls:amd64                    7.38.0-4                 
amd64                     easy-to-use client-side URL transfer library
(GnuTLS flavour)
ii  libgnutls-deb0-28:amd64                  3.3.8-5                  
amd64                     GNU TLS library - main runtime library
ii  libgnutls-openssl27:amd64                3.3.8-5                  
amd64                     GNU TLS library - OpenSSL wrapper
ii  libgnutls26:amd64                        2.12.20-8+deb7u2         
amd64                     GNU TLS library - runtime library
ii  rsyslog-gnutls                           8.4.2-1                  
amd64                     TLS protocol support for rsyslog

This is Debian Jessie.

Thanks.

On 29/01/15 10:09, Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-01-29 at 09:19 +1300, kimleanne wrote:
>> I've tried that. Where abouts does stderr log to? Doesn't appear to be
>> in /var/log anywhere based on a search for "gnutls" ignoring case.
> stderr is your terminal you run it. If it doesn't print anything, are
> you sure your rsyslog is linked with gnutls 3.3.x?
>
>



From dkg at fifthhorseman.net  Thu Jan 29 21:34:04 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 29 Jan 2015 15:34:04 -0500
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54C97862.5040509@gmail.com>
References: <54C4968E.1010205@gmail.com> <1422177248.2034.3.camel@gnutls.org>
 <54C87B15.8060705@gmail.com>
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
 <54C94467.5050909@gmail.com> <1422479346.31500.2.camel@gnutls.org>
 <54C97862.5040509@gmail.com>
Message-ID: <87d25xcon7.fsf@alice.fifthhorseman.net>

On Wed 2015-01-28 19:01:38 -0500, kimleanne wrote:
> Using lld doesn't produce any sign of gnutls:
>
>     linux-vdso.so.1 (0x00007fff5a3fc000)
>     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe749ab1000)
>     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007fe749894000)
>     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe74968f000)
>     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe749487000)
>     libestr.so.0 => /usr/lib/x86_64-linux-gnu/libestr.so.0
> (0x00007fe749283000)
>     libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe74907d000)
>     liblogging-stdlog.so.0 =>
> /usr/lib/x86_64-linux-gnu/liblogging-stdlog.so.0 (0x00007fe748e78000)
>     libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2
> (0x00007fe748c6d000)
>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7488c3000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007fe749cd4000)

You don't saw what you ran ldd on, but i assume it was on
/usr/sbin/rsyslogd.

aiui, rsyslogd uses libdl (linked above) to load libraries from
/usr/lib/rsyslog/.  As seen here:

https://packages.debian.org/sid/amd64/rsyslog-gnutls/filelist

it would load: /usr/lib/rsyslog/lmnsd_gtls.so

hth,

        --dkg


From kimleanne at gmail.com  Fri Jan 30 01:18:23 2015
From: kimleanne at gmail.com (kimleanne)
Date: Fri, 30 Jan 2015 13:18:23 +1300
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <87d25xcon7.fsf@alice.fifthhorseman.net>
References: <54C4968E.1010205@gmail.com> <1422177248.2034.3.camel@gnutls.org>
 <54C87B15.8060705@gmail.com>
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
 <54C94467.5050909@gmail.com> <1422479346.31500.2.camel@gnutls.org>
 <54C97862.5040509@gmail.com> <87d25xcon7.fsf@alice.fifthhorseman.net>
Message-ID: <54CACDCF.5060206@gmail.com>

Ah, OK. Yes it was /usr/sbin/rsyslogd (default location in Debian).

On 30/01/15 09:34, Daniel Kahn Gillmor wrote:
> On Wed 2015-01-28 19:01:38 -0500, kimleanne wrote:
>> Using lld doesn't produce any sign of gnutls:
>>
>>     linux-vdso.so.1 (0x00007fff5a3fc000)
>>     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe749ab1000)
>>     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>> (0x00007fe749894000)
>>     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe74968f000)
>>     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe749487000)
>>     libestr.so.0 => /usr/lib/x86_64-linux-gnu/libestr.so.0
>> (0x00007fe749283000)
>>     libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe74907d000)
>>     liblogging-stdlog.so.0 =>
>> /usr/lib/x86_64-linux-gnu/liblogging-stdlog.so.0 (0x00007fe748e78000)
>>     libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2
>> (0x00007fe748c6d000)
>>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7488c3000)
>>     /lib64/ld-linux-x86-64.so.2 (0x00007fe749cd4000)
> You don't saw what you ran ldd on, but i assume it was on
> /usr/sbin/rsyslogd.
>
> aiui, rsyslogd uses libdl (linked above) to load libraries from
> /usr/lib/rsyslog/.  As seen here:
>
> https://packages.debian.org/sid/amd64/rsyslog-gnutls/filelist
>
> it would load: /usr/lib/rsyslog/lmnsd_gtls.so
>
> hth,
>
>         --dkg



From Kim.Carter at binarymist.net  Fri Jan 30 01:09:47 2015
From: Kim.Carter at binarymist.net (Kim Carter)
Date: Fri, 30 Jan 2015 13:09:47 +1300
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54C97862.5040509@gmail.com>
References: <54C4968E.1010205@gmail.com>		<1422177248.2034.3.camel@gnutls.org>	<54C87B15.8060705@gmail.com>	
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>	
 <54C94467.5050909@gmail.com> <1422479346.31500.2.camel@gnutls.org>
 <54C97862.5040509@gmail.com>
Message-ID: <54CACBCB.50609@binarymist.net>

Looking at the lld output, where is gnutls 3.3.x linked?

On 29/01/15 13:01, kimleanne wrote:
> Using lld doesn't produce any sign of gnutls:
>
>     linux-vdso.so.1 (0x00007fff5a3fc000)
>     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe749ab1000)
>     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007fe749894000)
>     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe74968f000)
>     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe749487000)
>     libestr.so.0 => /usr/lib/x86_64-linux-gnu/libestr.so.0
> (0x00007fe749283000)
>     libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe74907d000)
>     liblogging-stdlog.so.0 =>
> /usr/lib/x86_64-linux-gnu/liblogging-stdlog.so.0 (0x00007fe748e78000)
>     libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2
> (0x00007fe748c6d000)
>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7488c3000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007fe749cd4000)
>
> Using dpkg-query -l '*gnutls*'
> produces:
>
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name                                     Version                  
> Architecture              Description
> +++-========================================-=========================-=========================-=====================================================================================
> un  gnutls-bin                               <none>                   
> <none>                    (no description available)
> un  gnutls0                                  <none>                   
> <none>                    (no description available)
> un  gnutls0.4                                <none>                   
> <none>                    (no description available)
> un  gnutls3                                  <none>                   
> <none>                    (no description available)
> ii  libcurl3-gnutls:amd64                    7.38.0-4                 
> amd64                     easy-to-use client-side URL transfer library
> (GnuTLS flavour)
> ii  libgnutls-deb0-28:amd64                  3.3.8-5                  
> amd64                     GNU TLS library - main runtime library
> ii  libgnutls-openssl27:amd64                3.3.8-5                  
> amd64                     GNU TLS library - OpenSSL wrapper
> ii  libgnutls26:amd64                        2.12.20-8+deb7u2         
> amd64                     GNU TLS library - runtime library
> ii  rsyslog-gnutls                           8.4.2-1                  
> amd64                     TLS protocol support for rsyslog
>
> This is Debian Jessie.
>
> Thanks.
>
> On 29/01/15 10:09, Nikos Mavrogiannopoulos wrote:
>> On Thu, 2015-01-29 at 09:19 +1300, kimleanne wrote:
>>> I've tried that. Where abouts does stderr log to? Doesn't appear to be
>>> in /var/log anywhere based on a search for "gnutls" ignoring case.
>> stderr is your terminal you run it. If it doesn't print anything, are
>> you sure your rsyslog is linked with gnutls 3.3.x?
>>
>>



From dkg at fifthhorseman.net  Fri Jan 30 18:26:48 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 30 Jan 2015 12:26:48 -0500
Subject: [gnutls-help] RSyslog not sending messages
In-Reply-To: <54CACBCB.50609@binarymist.net>
References: <54C4968E.1010205@gmail.com> <1422177248.2034.3.camel@gnutls.org>
 <54C87B15.8060705@gmail.com>
 <CAJU7zaKW37bJTNqRRD6e6VNZo209pTSVCAyDTcP6mOkiV35aiA@mail.gmail.com>
 <54C94467.5050909@gmail.com> <1422479346.31500.2.camel@gnutls.org>
 <54C97862.5040509@gmail.com> <54CACBCB.50609@binarymist.net>
Message-ID: <87386srxgn.fsf@alice.fifthhorseman.net>

On Thu 2015-01-29 19:09:47 -0500, Kim Carter wrote:
> Looking at the lld output, where is gnutls 3.3.x linked?

I think you mean ldd output.  libgnutls is not directly linked.  rsyslog
uses libdl (which is directly linked) to dynamically load another shared
object that *is* linked to libgnutls.

       --dkg