From epirat07 at gmail.com  Sat Nov  1 13:39:34 2014
From: epirat07 at gmail.com (Marvin Scholz)
Date: Sat, 01 Nov 2014 13:39:34 +0100
Subject: [gnutls-help] Generating bcrypt hash with GnuTLS
Message-ID: <3BE325D1-96B1-4C20-8003-D1492A951626@gmail.com>

I am now looking around in the GnuTLS docs for some time but I can't 
find it, so I'm asking here:
Is it possible to hash a password with the bcrypt algorithm using 
GnuTLS?


From nmav at gnutls.org  Mon Nov 10 08:47:41 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Nov 2014 08:47:41 +0100
Subject: [gnutls-help] gnutls 3.1.28
Message-ID: <1415605661.2918.1.camel@gnutls.org>

Hello,
 I've just released gnutls 3.1.28. This is a bug-fix release
on the previous stable branch.


* Version 3.1.28 (released 2014-11-10)

** libgnutls: Corrected issue in export of ECC parameters to X9.63 format.
Reported by Sean Burford [GNUTLS-SA-2014-5].

** 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.1/gnutls-3.1.28.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.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 nmav at gnutls.org  Mon Nov 10 08:49:56 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Nov 2014 08:49:56 +0100
Subject: [gnutls-help] gnutls 3.2.20 / GNUTLS-SA-2014-5
Message-ID: <1415605796.2918.3.camel@gnutls.org>

Hello,
 I've just released gnutls 3.2.20 and posted the security advisory 
http://www.gnutls.org/security.html#GNUTLS-SA-2014-5
This release includes bug fixes for the previous stable branch.

* Version 3.2.20 (released 2014-11-10)

** libgnutls: Removed superfluous random generator refresh on every call
of gnutls_deinit(). That reduces load and usage of /dev/urandom.

** libgnutls: Corrected issue in export of ECC parameters to X9.63 format.
Reported by Sean Burford [GNUTLS-SA-2014-5].

** 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.2/gnutls-3.2.20.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.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 nmav at gnutls.org  Mon Nov 10 08:51:40 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Nov 2014 08:51:40 +0100
Subject: [gnutls-help] gnutls 3.3.10 / GNUTLS-SA-2014-5
Message-ID: <1415605900.2918.5.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.3.10 and the security advisory
http://www.gnutls.org/security.html#GNUTLS-SA-2014-5
This release contains bug-fixes release for the stable branch. 

* Version 3.3.10 (released 2014-11-10)

** libgnutls: Refuse to import v1 or v2 certificates that contain
extensions.

** libgnutls: Fixes in usage of PKCS #11 token callback

** libgnutls: Fixed bug in gnutls_x509_trust_list_get_issuer() when used
with a PKCS #11 trust module and without the GNUTLS_TL_GET_COPY flag.
Reported by David Woodhouse.

** libgnutls: Removed superfluous random generator refresh on every call
of gnutls_deinit(). That reduces load and usage of /dev/urandom.

** libgnutls: Corrected issue in export of ECC parameters to X9.63 format.
Reported by Sean Burford [GNUTLS-SA-2014-5].

** libgnutls: When gnutls_global_init() is called for a second time, it
will check whether the /dev/urandom fd kept is still open and matches
the original one. That behavior works around issues with servers that
close all file descriptors.

** libgnutls: Corrected behavior with PKCS #11 objects that are marked
as CKA_ALWAYS_AUTHENTICATE.

** certtool: The default cipher for PKCS #12 structures is 3des-pkcs12.
That option is more compatible than AES or RC4.

** 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.10.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.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 ossman at cendio.se  Mon Nov 10 19:25:56 2014
From: ossman at cendio.se (Pierre Ossman)
Date: Mon, 10 Nov 2014 19:25:56 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
Message-ID: <20141110192556.43452a6b@mjolnir.ossman.eu>

Hi,

We're having some interoperability issues between Java's SSLEngine and
GnuTLS in TigerVNC.

Java will throw this at us sometimes (actually, rather often):

> Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)
> 	at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)
> 	at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:658)
> 	at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127)
> 	... 10 more

After some debugging it turns out that the failing criteria is that
multiple of 64 bits requirement[1]. For some reason I've gotten a 1023
bit prime, even though I called gnutls_dh_params_generate2() with 1024
as the argument.

One example set of parameters I've gotten:

>  TLS:         DH prime:
>               691e93a4e2dcd04a785abd633b6c066c404809815b6983f140fa8e0cad702ffffd15e7b8361e9924858494df07a7cff50d1b971e4ce1ab396647183b4222aded580f7a079203980c952e8443e2dde055793307c407c686c34af4a5309077023f078e0443bb4b5662c20af6af6958a8d2a2c52a50267428dac8e15d7777b49d6b
>  TLS:         DH generator:
>               5783a44a1aae0e098a9474b191251397812fc201f4e38d58e9ea96f2a83793a2468f9bbc55c82b6e4c55e6674ef23db59de38f3446d1c6b84f5837f350d9b1598abe09c79a83c39402bcc53c9f4444b76bdb0f6b4c0a5ccbd3bf76a794f4e307912127bffcc81261ae4ae3bf36a20a02ec65251e4778a8e58e11f22e685bbf59
>  TLS:         DH bits: 158

This is with GnuTLS 3.2.15 and nettle 2.7.1 on Windows.

Who's to blame here? GnuTLS? Java? Us? Everybody? :)

And what do I do about it? Keep calling gnutls_dh_params_generate2()
until I get what I need?

[1] Is that even a valid requirement? I cannot find any reference for
this except that Java code.

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: </pipermail/attachments/20141110/4aa3879b/attachment.sig>

From dkg at fifthhorseman.net  Mon Nov 10 22:48:13 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 10 Nov 2014 11:48:13 -1000
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <20141110192556.43452a6b@mjolnir.ossman.eu>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
Message-ID: <87zjbywwv6.fsf@alice.fifthhorseman.net>

Hi Pierre--

On Mon 2014-11-10 08:25:56 -1000, Pierre Ossman wrote:
> We're having some interoperability issues between Java's SSLEngine and
> GnuTLS in TigerVNC.

what version of Java and its SSLEngine are you using?

> Java will throw this at us sometimes (actually, rather often):
>
>> Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)
>> 	at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)
>> 	at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:658)
>> 	at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127)
>> 	... 10 more
>
> After some debugging it turns out that the failing criteria is that
> multiple of 64 bits requirement[1]. For some reason I've gotten a 1023
> bit prime, even though I called gnutls_dh_params_generate2() with 1024
> as the argument.

ugh.  Java is at fault here -- there's no sense in this particular
severe limitation.  if they're willing to use 512-bit DHE parameters and
1024-bit DHE parameters, they should be willing to use 1023-bit DHE
parameters.

That said, i suppose it's possible that gnutls could always ensure that
the high bit is set when generating a prime of a given size.

> One example set of parameters I've gotten:
>
>>  TLS:         DH prime:
>>               691e93a4e2dcd04a785abd633b6c066c404809815b6983f140fa8e0cad702ffffd15e7b8361e9924858494df07a7cff50d1b971e4ce1ab396647183b4222aded580f7a079203980c952e8443e2dde055793307c407c686c34af4a5309077023f078e0443bb4b5662c20af6af6958a8d2a2c52a50267428dac8e15d7777b49d6b
>>  TLS:         DH generator:
>>               5783a44a1aae0e098a9474b191251397812fc201f4e38d58e9ea96f2a83793a2468f9bbc55c82b6e4c55e6674ef23db59de38f3446d1c6b84f5837f350d9b1598abe09c79a83c39402bcc53c9f4444b76bdb0f6b4c0a5ccbd3bf76a794f4e307912127bffcc81261ae4ae3bf36a20a02ec65251e4778a8e58e11f22e685bbf59
>>  TLS:         DH bits: 158


what is this output from?  I'm not sure how to reconcile the "DH bits:
158" with the other data.

> This is with GnuTLS 3.2.15 and nettle 2.7.1 on Windows.
>
> Who's to blame here? GnuTLS? Java? Us? Everybody? :)
>
> And what do I do about it? Keep calling gnutls_dh_params_generate2()
> until I get what I need?

arguably, gnutls could keep the high bit set in its generated primes,
just to coddle broken peers like this java implementation.

> [1] Is that even a valid requirement? I cannot find any reference for
> this except that Java code.

have you reported this bug to java?  it sounds like they should not be
doing this.

      --dkg


From nmav at gnutls.org  Mon Nov 10 23:59:18 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Nov 2014 23:59:18 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <87zjbywwv6.fsf@alice.fifthhorseman.net>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
Message-ID: <1415660358.6709.4.camel@gnutls.org>

On Mon, 2014-11-10 at 11:48 -1000, Daniel Kahn Gillmor wrote:
> Hi Pierre--

> > After some debugging it turns out that the failing criteria is that
> > multiple of 64 bits requirement[1]. For some reason I've gotten a 1023
> > bit prime, even though I called gnutls_dh_params_generate2() with 1024
> > as the argument.
> ugh.  Java is at fault here -- there's no sense in this particular
> severe limitation.  if they're willing to use 512-bit DHE parameters and
> 1024-bit DHE parameters, they should be willing to use 1023-bit DHE
> parameters.

That's indeed quite some arbitrary limitation.

> That said, i suppose it's possible that gnutls could always ensure that
> the high bit is set when generating a prime of a given size.

That should be the case in gnutls 3.3.x. That version delegates to
nettle the DH parameter generation and nettle seems to be more precise.

> > This is with GnuTLS 3.2.15 and nettle 2.7.1 on Windows.
> > Who's to blame here? GnuTLS? Java? Us? Everybody? :)
> > And what do I do about it? Keep calling gnutls_dh_params_generate2()
> > until I get what I need?

One option would be to upgrade to 3.3.x.

regards,
Nikos




From ossman at cendio.se  Tue Nov 11 07:58:03 2014
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 11 Nov 2014 07:58:03 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <87zjbywwv6.fsf@alice.fifthhorseman.net>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
Message-ID: <20141111075803.56284cc6@mjolnir.ossman.eu>

On Mon, 10 Nov 2014 11:48:13 -1000
Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> Hi Pierre--
> 
> On Mon 2014-11-10 08:25:56 -1000, Pierre Ossman wrote:
> > We're having some interoperability issues between Java's SSLEngine and
> > GnuTLS in TigerVNC.
> 
> what version of Java and its SSLEngine are you using?
> 

Fedora's IcedTea 1.7.0. 2.5.3, whatever that means. Some form of
OpenJDK 7 I guess?

> > One example set of parameters I've gotten:
> >
> >>  TLS:         DH prime:
> >>               691e93a4e2dcd04a785abd633b6c066c404809815b6983f140fa8e0cad702ffffd15e7b8361e9924858494df07a7cff50d1b971e4ce1ab396647183b4222aded580f7a079203980c952e8443e2dde055793307c407c686c34af4a5309077023f078e0443bb4b5662c20af6af6958a8d2a2c52a50267428dac8e15d7777b49d6b
> >>  TLS:         DH generator:
> >>               5783a44a1aae0e098a9474b191251397812fc201f4e38d58e9ea96f2a83793a2468f9bbc55c82b6e4c55e6674ef23db59de38f3446d1c6b84f5837f350d9b1598abe09c79a83c39402bcc53c9f4444b76bdb0f6b4c0a5ccbd3bf76a794f4e307912127bffcc81261ae4ae3bf36a20a02ec65251e4778a8e58e11f22e685bbf59
> >>  TLS:         DH bits: 158
> 
> 
> what is this output from?  I'm not sure how to reconcile the "DH bits:
> 158" with the other data.
> 

It was generated like this:

  if (gnutls_dh_params_generate2(dh_params, DH_BITS) != GNUTLS_E_SUCCESS)
    throw AuthFailureException("gnutls_dh_params_generate2 failed");

  gnutls_datum_t p, g;
  unsigned int b;
  char buffer[4096];
  size_t sz;

  gnutls_dh_params_export_raw(dh_params, &p, &g, &b);

  sz = sizeof(buffer);
  gnutls_hex_encode(&p, buffer, &sz);
  vlog.debug("DH prime: %s", buffer);
  sz = sizeof(buffer);
  gnutls_hex_encode(&g, buffer, &sz);
  vlog.debug("DH generator: %s", buffer);
  vlog.debug("DH bits: %u", b);

> 
> have you reported this bug to java?  it sounds like they should not be
> doing this.
> 

No. I found it a bit difficult to submit a good bug report as can't say
I'm familiar with DH beyond stating that Java and GnuTLS don't like each
other. :)

(It's also far from obvious how you report bugs to them)

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Link?ping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/112509906846170010689

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: </pipermail/attachments/20141111/297a5009/attachment.sig>

From ossman at cendio.se  Tue Nov 11 07:59:27 2014
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 11 Nov 2014 07:59:27 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <1415660358.6709.4.camel@gnutls.org>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <1415660358.6709.4.camel@gnutls.org>
Message-ID: <20141111075927.2090112d@mjolnir.ossman.eu>

On Mon, 10 Nov 2014 23:59:18 +0100
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> > > This is with GnuTLS 3.2.15 and nettle 2.7.1 on Windows.
> > > Who's to blame here? GnuTLS? Java? Us? Everybody? :)
> > > And what do I do about it? Keep calling gnutls_dh_params_generate2()
> > > until I get what I need?
> 
> One option would be to upgrade to 3.3.x.
> 

But that is still not considered a stable series, right?

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Link?ping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/112509906846170010689

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: </pipermail/attachments/20141111/f33f0479/attachment.sig>

From ossman at cendio.se  Tue Nov 11 08:00:53 2014
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 11 Nov 2014 08:00:53 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <CAJ5DRCCxUztwBHOwwWXwD8s+z4K=4isDuv4JDgPkiOqXzDLrvQ@mail.gmail.com>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <1415660358.6709.4.camel@gnutls.org>
 <CAJ5DRCCxUztwBHOwwWXwD8s+z4K=4isDuv4JDgPkiOqXzDLrvQ@mail.gmail.com>
Message-ID: <20141111080053.29710dc7@mjolnir.ossman.eu>

On Mon, 10 Nov 2014 18:12:48 -0500
Brian Hinz <bphinz at users.sourceforge.net> wrote:

> 
> I think that the actual limitation in question is that Java is requiring
> the prime length to be a multiple of 64.  Presumably this dates back to
> FIPS-186-1 which did require prime lengths to be multiples of 64.  The
> limitation on the prime length is supposedly being relaxed in Java 8.
> 

I checked the JDK 8 code, and the limitation is still there. As is it
in JDK 9. So there doesn't seem to be a fix on the way. :/

E.g.:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/ad04eada78e9/src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Link?ping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/112509906846170010689

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: </pipermail/attachments/20141111/6b2994fc/attachment.sig>

From bphinz at users.sourceforge.net  Tue Nov 11 00:12:48 2014
From: bphinz at users.sourceforge.net (Brian Hinz)
Date: Mon, 10 Nov 2014 18:12:48 -0500
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <1415660358.6709.4.camel@gnutls.org>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <1415660358.6709.4.camel@gnutls.org>
Message-ID: <CAJ5DRCCxUztwBHOwwWXwD8s+z4K=4isDuv4JDgPkiOqXzDLrvQ@mail.gmail.com>

On Mon, Nov 10, 2014 at 5:59 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Mon, 2014-11-10 at 11:48 -1000, Daniel Kahn Gillmor wrote:
> > > After some debugging it turns out that the failing criteria is that
> > > multiple of 64 bits requirement[1]. For some reason I've gotten a 1023
> > > bit prime, even though I called gnutls_dh_params_generate2() with 1024
> > > as the argument.
> > ugh.  Java is at fault here -- there's no sense in this particular
> > severe limitation.  if they're willing to use 512-bit DHE parameters and
> > 1024-bit DHE parameters, they should be willing to use 1023-bit DHE
> > parameters.
>
> That's indeed quite some arbitrary limitation.
>

I think that the actual limitation in question is that Java is requiring
the prime length to be a multiple of 64.  Presumably this dates back to
FIPS-186-1 which did require prime lengths to be multiples of 64.  The
limitation on the prime length is supposedly being relaxed in Java 8.


> > That said, i suppose it's possible that gnutls could always ensure that
> > the high bit is set when generating a prime of a given size.
>
> That should be the case in gnutls 3.3.x. That version delegates to
> nettle the DH parameter generation and nettle seems to be more precise.


Thanks, I'll try that.

-brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141110/e917b556/attachment-0001.html>

From bphinz at users.sourceforge.net  Tue Nov 11 05:35:55 2014
From: bphinz at users.sourceforge.net (Brian Hinz)
Date: Mon, 10 Nov 2014 23:35:55 -0500
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <CAJ5DRCCxUztwBHOwwWXwD8s+z4K=4isDuv4JDgPkiOqXzDLrvQ@mail.gmail.com>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <1415660358.6709.4.camel@gnutls.org>
 <CAJ5DRCCxUztwBHOwwWXwD8s+z4K=4isDuv4JDgPkiOqXzDLrvQ@mail.gmail.com>
Message-ID: <CAJ5DRCDbDpkMThrEY3txX2qnHbb-bEA3V-1Lw7-_gm+0U48Qww@mail.gmail.com>

On Mon, Nov 10, 2014 at 6:12 PM, Brian Hinz wrote:

> On Mon, Nov 10, 2014 at 5:59 PM, Nikos Mavrogiannopoulos wrote:
>
>> On Mon, 2014-11-10 at 11:48 -1000, Daniel Kahn Gillmor wrote:
>> > > After some debugging it turns out that the failing criteria is that
>> > > multiple of 64 bits requirement[1]. For some reason I've gotten a 1023
>> > > bit prime, even though I called gnutls_dh_params_generate2() with 1024
>> > > as the argument.
>> > ugh.  Java is at fault here -- there's no sense in this particular
>> > severe limitation.  if they're willing to use 512-bit DHE parameters and
>> > 1024-bit DHE parameters, they should be willing to use 1023-bit DHE
>> > parameters.
>>
>> That's indeed quite some arbitrary limitation.
>>
>
> I think that the actual limitation in question is that Java is requiring
> the prime length to be a multiple of 64.  Presumably this dates back to
> FIPS-186-1 which did require prime lengths to be multiples of 64.  The
> limitation on the prime length is supposedly being relaxed in Java 8.
>
>
>> > That said, i suppose it's possible that gnutls could always ensure that
>> > the high bit is set when generating a prime of a given size.
>>
>> That should be the case in gnutls 3.3.x. That version delegates to
>> nettle the DH parameter generation and nettle seems to be more precise.
>
>
> Thanks, I'll try that.
>

3.3.10 does in fact seem to resolve the issue.  Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141110/2a565917/attachment-0001.html>

From nmav at gnutls.org  Tue Nov 11 12:42:10 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Nov 2014 12:42:10 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <20141111075803.56284cc6@mjolnir.ossman.eu>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <20141111075803.56284cc6@mjolnir.ossman.eu>
Message-ID: <CAJU7za+5MRW4Pb7YZeOYQfSQAeYrm1at0aqFe2DpWY4xuwfn4Q@mail.gmail.com>

On Tue, Nov 11, 2014 at 7:58 AM, Pierre Ossman <ossman at cendio.se> wrote:
> It was generated like this:
>
>   if (gnutls_dh_params_generate2(dh_params, DH_BITS) != GNUTLS_E_SUCCESS)
>     throw AuthFailureException("gnutls_dh_params_generate2 failed");

A question that arises, is why do you generate those parameters
anyway? Why not ship some static parameters (via certtool
--get-dh-params).

>> One option would be to upgrade to 3.3.x.
>>
> But that is still not considered a stable series, right?

It is the current stable.

regards,
Nikos


From ossman at cendio.se  Tue Nov 11 12:50:14 2014
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 11 Nov 2014 12:50:14 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <CAJU7za+5MRW4Pb7YZeOYQfSQAeYrm1at0aqFe2DpWY4xuwfn4Q@mail.gmail.com>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <20141111075803.56284cc6@mjolnir.ossman.eu>
 <CAJU7za+5MRW4Pb7YZeOYQfSQAeYrm1at0aqFe2DpWY4xuwfn4Q@mail.gmail.com>
Message-ID: <20141111125014.22eb8164@ossman.lkpg.cendio.se>

On Tue, 11 Nov 2014 12:42:10 +0100,
Nikos Mavrogiannopoulos wrote:

> On Tue, Nov 11, 2014 at 7:58 AM, Pierre Ossman <ossman at cendio.se> wrote:
> > It was generated like this:
> >
> >   if (gnutls_dh_params_generate2(dh_params, DH_BITS) != GNUTLS_E_SUCCESS)
> >     throw AuthFailureException("gnutls_dh_params_generate2 failed");
> 
> A question that arises, is why do you generate those parameters
> anyway? Why not ship some static parameters (via certtool
> --get-dh-params).
> 

Unfortunately I have no idea as I did not write that code. It's probably
based on one of your examples that generates them on the fly.

TBH, I've never gotten a good grasp on what a good security policy is
with regard to DH params. Some have pregenerated values, but I also see
references that they should be regenerated every few hours/days/etc.

Got any insight to share?

> >> One option would be to upgrade to 3.3.x.
> >>
> > But that is still not considered a stable series, right?
> 
> It is the current stable.
> 

Oh. I got confused by the front page which states:

> Released GnuTLS 3.3.10, GnuTLS 3.2.20, GnuTLS 3.1.28, which are bug-fix releases on the next, current and previous stable branches respectively. 

I.e. 3.3.10 is being called "next", which suggests to me that it wasn't
stable yet. But I see now that the download page lists 3.3.x as stable.

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: </pipermail/attachments/20141111/037ab844/attachment.sig>

From ossman at cendio.se  Tue Nov 11 13:35:56 2014
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 11 Nov 2014 13:35:56 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <546201C1.4010901@elzevir.fr>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <20141111075803.56284cc6@mjolnir.ossman.eu>
 <CAJU7za+5MRW4Pb7YZeOYQfSQAeYrm1at0aqFe2DpWY4xuwfn4Q@mail.gmail.com>
 <20141111125014.22eb8164@ossman.lkpg.cendio.se>
 <546201C1.4010901@elzevir.fr>
Message-ID: <20141111133556.127a1ee4@ossman.lkpg.cendio.se>

On Tue, 11 Nov 2014 13:32:01 +0100,
Manuel P?gouri?-Gonnard wrote:

> On 11/11/2014 12:50, Pierre Ossman wrote:
> > TBH, I've never gotten a good grasp on what a good security policy is with
> > regard to DH params. Some have pregenerated values, but I also see 
> > references that they should be regenerated every few hours/days/etc.
> > 
> > Got any insight to share?
> > 
> The DH params (ie: prime and generator) can totally be static. There are even
> RFCs defining standardising values for them (3526, 5114, maybe more).
> 
> The thing that should be regenerated regularly (ideally every key exchange,
> for truly ephemeral DH) is your private-public DH key pair.
> 

Is that done by GnuTLS implicitly? I don't see anything in our use of
GnuTLS that generates such things even once.

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: </pipermail/attachments/20141111/cfa2e45b/attachment.sig>

From mpg at elzevir.fr  Tue Nov 11 13:32:01 2014
From: mpg at elzevir.fr (=?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?=)
Date: Tue, 11 Nov 2014 13:32:01 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <20141111125014.22eb8164@ossman.lkpg.cendio.se>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <20141111075803.56284cc6@mjolnir.ossman.eu>
 <CAJU7za+5MRW4Pb7YZeOYQfSQAeYrm1at0aqFe2DpWY4xuwfn4Q@mail.gmail.com>
 <20141111125014.22eb8164@ossman.lkpg.cendio.se>
Message-ID: <546201C1.4010901@elzevir.fr>

On 11/11/2014 12:50, Pierre Ossman wrote:
> TBH, I've never gotten a good grasp on what a good security policy is with
> regard to DH params. Some have pregenerated values, but I also see 
> references that they should be regenerated every few hours/days/etc.
> 
> Got any insight to share?
> 
The DH params (ie: prime and generator) can totally be static. There are even
RFCs defining standardising values for them (3526, 5114, maybe more).

The thing that should be regenerated regularly (ideally every key exchange,
for truly ephemeral DH) is your private-public DH key pair.

Manuel.


From nmav at gnutls.org  Tue Nov 11 18:57:47 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Nov 2014 18:57:47 +0100
Subject: [gnutls-help] too few bits from gnutls_dh_params_generate2() ?
In-Reply-To: <20141111133556.127a1ee4@ossman.lkpg.cendio.se>
References: <20141110192556.43452a6b@mjolnir.ossman.eu>
 <87zjbywwv6.fsf@alice.fifthhorseman.net>
 <20141111075803.56284cc6@mjolnir.ossman.eu>
 <CAJU7za+5MRW4Pb7YZeOYQfSQAeYrm1at0aqFe2DpWY4xuwfn4Q@mail.gmail.com>
 <20141111125014.22eb8164@ossman.lkpg.cendio.se>
 <546201C1.4010901@elzevir.fr>
 <20141111133556.127a1ee4@ossman.lkpg.cendio.se>
Message-ID: <1415728667.3744.2.camel@gnutls.org>

On Tue, 2014-11-11 at 13:35 +0100, Pierre Ossman wrote:
> On Tue, 11 Nov 2014 13:32:01 +0100,
> Manuel P?gouri?-Gonnard wrote:
> 
> > On 11/11/2014 12:50, Pierre Ossman wrote:
> > > TBH, I've never gotten a good grasp on what a good security policy is with
> > > regard to DH params. Some have pregenerated values, but I also see 
> > > references that they should be regenerated every few hours/days/etc.
> > > 
> > > Got any insight to share?
> > > 
> > The DH params (ie: prime and generator) can totally be static. There are even
> > RFCs defining standardising values for them (3526, 5114, maybe more).
> > 
> > The thing that should be regenerated regularly (ideally every key exchange,
> > for truly ephemeral DH) is your private-public DH key pair.
> Is that done by GnuTLS implicitly? I don't see anything in our use of
> GnuTLS that generates such things even once.

Yes, there is a new private key pair on every session in gnutls. There
is no option to change that.

regards,
Nikos




From nhrdls at gmail.com  Thu Nov 13 03:27:37 2014
From: nhrdls at gmail.com (Niranjan Rao)
Date: Wed, 12 Nov 2014 18:27:37 -0800
Subject: [gnutls-help] SSL Hanshake error
Message-ID: <54641719.10703@gmail.com>

Greetings,


I am getting ssl handshake error while visiting site 
https://www.pge.com/eum/login and some other sites using Webkit GTK 
2.2.6 on Ubuntu 12.04. I am really not certain which version of TLS 
library is getting used, but it appears that glib-networking version is 
2.36.1.

I raised the question on webkit gtk list and nice person 
mcatanzaro at igalia.com did some initial steps for debugging the issue and 
directed me to this mailing list for support. Following mail contains 
his analysis.

What can I do to solve this problem?


n Wed, 2014-11-12 at 11:44 -0800, Niranjan Rao wrote:

> Greetings,
>
> On Webkit 2.2.6/Ubuntu 12.04
>
> When visiting some sites, I get error SLS handshake error. For example
> sitehttps://www.pge.com/eum/login  gives SSL handshake error when using
> MiniBrowser. Usual browsers are doing ok when visiting the site.
>
> Is there any way to mitigate this problem?

Each such site requires individual investigation, unfortunately.

> I saw some documentation about TLS errors in webkitgtk web site. Not
> clear if this applies to me or not.

Well, that documentation describes how to handle "successful" TLS
connections with unverified TLS certificates, which is important for
developers because older versions of WebKitGTK+ handle this insecurely
by default. But it's not relevant here, since this connection has failed
completely. We use GnuTLS to handle TLS; here's what its command line
debug tool tells us:

$ gnutls-cliwww.pge.com
Processed 153 CA certificate(s).
Resolving 'www.pge.com'...
Connecting to '131.89.128.67:443'...
*** Fatal error: The TLS connection was non-properly terminated.
*** Handshake has failed
GnuTLS error: The TLS connection was non-properly terminated.

That error message is misleading:

$ gnutls-cli-debugwww.pge.com
Resolving 'www.pge.com'...
Connecting to '131.89.128.67:443'...
Checking for SSL 3.0 support... no
Connecting to '131.89.128.67:443'...
Checking whether %COMPAT is required... yes
Connecting to '131.89.128.67:443'...
Checking for TLS 1.0 support... no
Connecting to '131.89.128.67:443'...
Checking for TLS 1.1 support... no
Connecting to '131.89.128.67:443'...
Checking fallback from TLS 1.1 to... failed
Connecting to '131.89.128.67:443'...
Checking for TLS 1.2 support... no
Connecting to '131.89.128.67:443'...
Checking whether we need to disable TLS 1.2... yes

So GnuTLS thinks this server apparently does not support any TLS
protocol, and you get no connection. But for a second opinion I went to
https://www.ssllabs.com/ssltest/analyze.html?d=pge.com  which was able to
connect via TLS 1.0. The server supports very few cipher suites (you can
see that the site is completely inaccessible with the latest Safari, for
example), but we share three in common so I'm not sure what's wrong. The
next step would be to ask on the gnutls-help mailing list [1] to find
out whether there is a GnuTLS bug (not really likely) or why it's
refusing to connect if not. Please do CC me; I'm curious!

Michael

[1]http://lists.gnutls.org/mailman/listinfo/gnutls-help




From nmav at gnutls.org  Thu Nov 13 09:08:53 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 13 Nov 2014 09:08:53 +0100
Subject: [gnutls-help] SSL Hanshake error
In-Reply-To: <54641719.10703@gmail.com>
References: <54641719.10703@gmail.com>
Message-ID: <CAJU7za+AYRT4=_7yknLfRpL9Qz_yp4ZXAiraZzMq7VhVJAUJEw@mail.gmail.com>

On Thu, Nov 13, 2014 at 3:27 AM, Niranjan Rao <nhrdls at gmail.com> wrote:
> Greetings,
> I am getting ssl handshake error while visiting site
> https://www.pge.com/eum/login and some other sites using Webkit GTK 2.2.6 on
> Ubuntu 12.04. I am really not certain which version of TLS library is
> getting used, but it appears that glib-networking version is 2.36.1.
> I raised the question on webkit gtk list and nice person
> mcatanzaro at igalia.com did some initial steps for debugging the issue and
> directed me to this mailing list for support. Following mail contains his
> analysis.

Hi,
 It seems that following poodle many sites incorrectly banned SSL 3.0
record packet versions. Since gnutls uses an SSL 3.0 record to
advertise TLS 1.2, they are effectively banning it even if it doesn't
advertise SSL 3.0. That is a server issue, but it can be worked around
by using the modifier %LATEST_RECORD_VERSION, e.g.,
gnutls-cli www.pge.com --priority "NORMAL:%LATEST_RECORD_VERSION"
should work.

That seems like a good opportunity to make that the default.

regards,
Nikos


From nhrdls at gmail.com  Thu Nov 13 17:34:29 2014
From: nhrdls at gmail.com (Niranjan Rao)
Date: Thu, 13 Nov 2014 08:34:29 -0800
Subject: [gnutls-help] SSL Hanshake error
In-Reply-To: <CAJU7za+AYRT4=_7yknLfRpL9Qz_yp4ZXAiraZzMq7VhVJAUJEw@mail.gmail.com>
References: <54641719.10703@gmail.com>
 <CAJU7za+AYRT4=_7yknLfRpL9Qz_yp4ZXAiraZzMq7VhVJAUJEw@mail.gmail.com>
Message-ID: <5464DD95.1060600@gmail.com>

Thank you Nikos,

Unfortunately, I don't much about tls. If I want to use this in webkit, 
any idea what do I need to do?

Regards,

Niranjan

On 11/13/2014 12:08 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, Nov 13, 2014 at 3:27 AM, Niranjan Rao <nhrdls at gmail.com> wrote:
>> Greetings,
>> I am getting ssl handshake error while visiting site
>> https://www.pge.com/eum/login and some other sites using Webkit GTK 2.2.6 on
>> Ubuntu 12.04. I am really not certain which version of TLS library is
>> getting used, but it appears that glib-networking version is 2.36.1.
>> I raised the question on webkit gtk list and nice person
>> mcatanzaro at igalia.com did some initial steps for debugging the issue and
>> directed me to this mailing list for support. Following mail contains his
>> analysis.
> Hi,
>   It seems that following poodle many sites incorrectly banned SSL 3.0
> record packet versions. Since gnutls uses an SSL 3.0 record to
> advertise TLS 1.2, they are effectively banning it even if it doesn't
> advertise SSL 3.0. That is a server issue, but it can be worked around
> by using the modifier %LATEST_RECORD_VERSION, e.g.,
> gnutls-cli www.pge.com --priority "NORMAL:%LATEST_RECORD_VERSION"
> should work.
>
> That seems like a good opportunity to make that the default.
>
> regards,
> Nikos



From nmav at gnutls.org  Thu Nov 13 20:50:44 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 13 Nov 2014 20:50:44 +0100
Subject: [gnutls-help] SSL Hanshake error
In-Reply-To: <5464DD95.1060600@gmail.com>
References: <54641719.10703@gmail.com>
 <CAJU7za+AYRT4=_7yknLfRpL9Qz_yp4ZXAiraZzMq7VhVJAUJEw@mail.gmail.com>
 <5464DD95.1060600@gmail.com>
Message-ID: <1415908244.2039.0.camel@gnutls.org>

On Thu, 2014-11-13 at 08:34 -0800, Niranjan Rao wrote:
> Thank you Nikos,
> 
> Unfortunately, I don't much about tls. If I want to use this in webkit, 
> any idea what do I need to do?

You should contact again the glib-networking guys. There is a way to
override the priority string, and they may want to know about that
anyway.

regards,
Nikos




From ceving at gmail.com  Sun Nov 16 19:34:40 2014
From: ceving at gmail.com (Sascha Ziemann)
Date: Sun, 16 Nov 2014 19:34:40 +0100
Subject: [gnutls-help] Convert PEM to DER
Message-ID: <CAGUt3y7UUJLy0Nv8d4UrjeFbVz_G1V8uSWDkdHvO73ZJfu=HHg@mail.gmail.com>

I tried to convert a PEM file to DER:

$ certtool --load-certificate ca.crt.pem --outfile ca.crt --outder
certtool [options]
certtool --help for usage instructions.

But it does not work. How to do it?

Regards,
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141116/6e4b90aa/attachment.html>

From ceving at gmail.com  Sun Nov 16 20:07:33 2014
From: ceving at gmail.com (Sascha Ziemann)
Date: Sun, 16 Nov 2014 20:07:33 +0100
Subject: [gnutls-help] Year 2038 problem
Message-ID: <CAGUt3y4WKF9=tqxTPatDn3W33iQxL+bRp-9DoWOyzYMgTT4e9Q@mail.gmail.com>

Is there a year 2038 problem in GnuTLS?

I tried to create a certificate with the following template:

cn = "CA.ceving.de"
expiration_days = 25550
ca
signing_key
cert_signing_key
crl_signing_key
path_len = 0

I expected the certificate to be valid for 70 years. But GnuTLS greatly
increases the validity. unber shows the following:

<C T="[UNIVERSAL 16]" TL="4" V="1022">
    <C T="[UNIVERSAL 16]" TL="4" V="614">
        <C T="[0]" TL="2" V="3">
            <P T="[UNIVERSAL 2]" TL="2" V="1" F>2</P>
        </C T="[0]">
        <P T="[UNIVERSAL 2]" TL="2"
V="12">&#x54;&#x68;&#xeb;&#xb3;&#x23;&#xa2;&#xb6;&#x10;&#x88;&#x65;&#xf4;&#x79;</P>
        <C T="[UNIVERSAL 16]" TL="2" V="13">
            <P T="[UNIVERSAL 6]" TL="2" V="9" F>1.2.840.113549.1.1.11</P>
            <P T="[UNIVERSAL 5]" TL="2" V="0"></P>
        </C T="[UNIVERSAL 16]">
        <C T="[UNIVERSAL 16]" TL="2" V="23">
            <C T="[UNIVERSAL 17]" TL="2" V="21">
                <C T="[UNIVERSAL 16]" TL="2" V="19">
                    <P T="[UNIVERSAL 6]" TL="2" V="3" F>2.5.4.3</P>
                    <P T="[UNIVERSAL 19]" TL="2" V="12">CA.ceving.de</P>
                </C T="[UNIVERSAL 16]">
            </C T="[UNIVERSAL 17]">
        </C T="[UNIVERSAL 16]">
        <C T="[UNIVERSAL 16]" TL="2" V="34">
            <P T="[UNIVERSAL 24]" TL="2" V="15">20141116182347Z</P>
            <P T="[UNIVERSAL 24]" TL="2" V="15">99991231235959Z</P>

2084 gets 9999.

When I import this certificate into a iPhone the IOS tells me that the
certificate has expired in 1833, which is probably another year 2038 bug.

Regards,
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141116/75e67a7e/attachment.html>

From ceving at gmail.com  Mon Nov 17 16:47:30 2014
From: ceving at gmail.com (Sascha Ziemann)
Date: Mon, 17 Nov 2014 16:47:30 +0100
Subject: [gnutls-help] OID 1.3.6.1.5.5.7.3.4
Message-ID: <CAGUt3y4bHRehfQSRi8OMph3Qsvv7+QWL+hMx8RsYacbKbfs_yA@mail.gmail.com>

The OID 1.3.6.1.5.5.7.3.4 specifies the key usage for e-mail protection:

http://www.alvestrand.no/objectid/1.3.6.1.5.5.7.3.4.html

This OID is necessary to use the certificate with openssl smime -sign and
-verify. If it is not in the certificate, the verification fails with a
certificate purpose error.

I think it would be useful to add this OID to the sample template on the
certtool invocation page:

http://www.gnutls.org/manual/html_node/certtool-Invocation.html

Regards,
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141117/ea8ab12a/attachment-0001.html>

From nmav at gnutls.org  Mon Nov 17 18:00:54 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 17 Nov 2014 18:00:54 +0100
Subject: [gnutls-help] Year 2038 problem
In-Reply-To: <CAGUt3y4WKF9=tqxTPatDn3W33iQxL+bRp-9DoWOyzYMgTT4e9Q@mail.gmail.com>
References: <CAGUt3y4WKF9=tqxTPatDn3W33iQxL+bRp-9DoWOyzYMgTT4e9Q@mail.gmail.com>
Message-ID: <1416243654.6812.1.camel@gnutls.org>

On Sun, 2014-11-16 at 20:07 +0100, Sascha Ziemann wrote:
> Is there a year 2038 problem in GnuTLS?
> I tried to create a certificate with the following template:
> cn = "CA.ceving.de"
> expiration_days = 25550

No, at least not the supported versions of gnutls. Which version do 
you use? The best is to explicitly set the dates using expiration_date
and activation_date as in.
http://www.gnutls.org/manual/html_node/certtool-Invocation.html

regards,
Nikos





From nmav at gnutls.org  Mon Nov 17 18:37:45 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 17 Nov 2014 18:37:45 +0100
Subject: [gnutls-help] OID 1.3.6.1.5.5.7.3.4
In-Reply-To: <CAGUt3y4bHRehfQSRi8OMph3Qsvv7+QWL+hMx8RsYacbKbfs_yA@mail.gmail.com>
References: <CAGUt3y4bHRehfQSRi8OMph3Qsvv7+QWL+hMx8RsYacbKbfs_yA@mail.gmail.com>
Message-ID: <1416245865.6812.3.camel@gnutls.org>

On Mon, 2014-11-17 at 16:47 +0100, Sascha Ziemann wrote:
> The OID 1.3.6.1.5.5.7.3.4 specifies the key usage for e-mail
> protection:
> 
> http://www.alvestrand.no/objectid/1.3.6.1.5.5.7.3.4.html
> 
> 
> This OID is necessary to use the certificate with openssl smime -sign
> and -verify. If it is not in the certificate, the verification fails
> with a certificate purpose error.

Thanks. There is already a special keyword for it in master (i.e.,
3.4.0), but you can also specify it as "key_purpose_oid =
1.3.6.1.5.5.7.3.4" in all previous versions.

regards,
Nikos





From nmav at gnutls.org  Mon Nov 17 18:38:47 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 17 Nov 2014 18:38:47 +0100
Subject: [gnutls-help] Convert PEM to DER
In-Reply-To: <CAGUt3y7UUJLy0Nv8d4UrjeFbVz_G1V8uSWDkdHvO73ZJfu=HHg@mail.gmail.com>
References: <CAGUt3y7UUJLy0Nv8d4UrjeFbVz_G1V8uSWDkdHvO73ZJfu=HHg@mail.gmail.com>
Message-ID: <1416245927.6812.4.camel@gnutls.org>

On Sun, 2014-11-16 at 19:34 +0100, Sascha Ziemann wrote:
> I tried to convert a PEM file to DER:
> 
> $ certtool --load-certificate ca.crt.pem --outfile ca.crt --outder
> certtool [options]
> certtool --help for usage instructions.
> But it does not work. How to do it?

I use:
certtool --outder -i --infile ca.crt.pem --outfile ca.crt.der

regards,
Nikos





From ceving at gmail.com  Fri Nov 21 09:37:21 2014
From: ceving at gmail.com (Sascha Ziemann)
Date: Fri, 21 Nov 2014 09:37:21 +0100
Subject: [gnutls-help] Year 2038 problem
In-Reply-To: <1416243654.6812.1.camel@gnutls.org>
References: <CAGUt3y4WKF9=tqxTPatDn3W33iQxL+bRp-9DoWOyzYMgTT4e9Q@mail.gmail.com>
 <1416243654.6812.1.camel@gnutls.org>
Message-ID: <CAGUt3y4=sAB7uxeiCmtYm0_QX8ifiWffJc1dSDCgnAgk2tUZBg@mail.gmail.com>

2014-11-17 18:00 GMT+01:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Sun, 2014-11-16 at 20:07 +0100, Sascha Ziemann wrote:
> > Is there a year 2038 problem in GnuTLS?
> > I tried to create a certificate with the following template:
> > cn = "CA.ceving.de"
> > expiration_days = 25550
>
> No, at least not the supported versions of gnutls. Which version do
> you use?
>


$ certtool --version
certtool 3.3.10

$ certtool --generate-privkey --sec-param low > key
Generating a 1024 bit RSA private key...

$ echo -e "cn=test\nexpiration_days=$((100*365))" > cfg

$ certtool --generate-self-signed --template cfg --load-privkey key
--outder > crt
Generating a self signed certificate...
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 546ef3bf2acb5a50a3efbe0c
        Validity:
                Not Before: Fri Nov 21 08:11:43 UTC 2014
                Not After: Thu Dec 31 23:23:23 UTC 2037
        Subject: CN=test
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: Low (1024 bits)
                Modulus (bits 1024):
                        00:e7:50:7e:e7:65:d0:26:a8:b9:77:af:ca:3f:dd:a2
                        2e:26:b3:1c:3f:0b:9a:b4:7f:eb:bc:73:62:20:c1:65
                        00:94:f6:97:4b:09:5e:06:39:cf:00:87:ef:db:7c:50
                        81:08:ed:95:c3:07:3e:5d:ee:a0:41:ed:a9:ac:13:ad
                        e7:df:0f:97:2d:59:af:e4:a0:08:56:63:62:bc:30:7e
                        6f:db:b2:bc:fe:9f:75:4f:87:5f:a6:93:cc:3f:8a:87
                        f2:f9:9a:fe:10:14:e1:2f:bb:5f:e9:fe:3b:72:1d:12
                        ac:b2:60:da:61:83:5f:61:09:f7:96:1c:b3:1a:5a:f4
                        37
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Subject Key Identifier (not critical):
                        7b6baf0b484229ac5f3f013632e6ec9f9b70f60d
Other Information:
        Public Key ID:
                7b6baf0b484229ac5f3f013632e6ec9f9b70f60d
        Public key's random art:
                +--[ RSA 1024]----+
                |                 |
                | .   .           |
                |  * *            |
                | = * o           |
                |. o o o S        |
                | o . + o .       |
                |  + o E o .      |
                |   = + + o..     |
                |    =.. ..++.    |
                +-----------------+



Signing certificate...

$ unber -m crt|head -21
<C T="[UNIVERSAL 16]" TL="4" V="466">
    <C T="[UNIVERSAL 16]" TL="4" V="315">
        <C T="[0]" TL="2" V="3">
            <P T="[UNIVERSAL 2]" TL="2" V="1" F>2</P>
        </C T="[0]">
        <P T="[UNIVERSAL 2]" TL="2"
V="12">&#x54;&#x6e;&#xf3;&#xbf;&#x2a;&#xcb;&#x5a;&#x50;&#xa3;&#xef;&#xbe;&#x0c;</P>
        <C T="[UNIVERSAL 16]" TL="2" V="13">
            <P T="[UNIVERSAL 6]" TL="2" V="9" F>1.2.840.113549.1.1.11</P>
            <P T="[UNIVERSAL 5]" TL="2" V="0"></P>
        </C T="[UNIVERSAL 16]">
        <C T="[UNIVERSAL 16]" TL="2" V="15">
            <C T="[UNIVERSAL 17]" TL="2" V="13">
                <C T="[UNIVERSAL 16]" TL="2" V="11">
                    <P T="[UNIVERSAL 6]" TL="2" V="3" F>2.5.4.3</P>
                    <P T="[UNIVERSAL 19]" TL="2" V="4">test</P>
                </C T="[UNIVERSAL 16]">
            </C T="[UNIVERSAL 17]">
        </C T="[UNIVERSAL 16]">
        <C T="[UNIVERSAL 16]" TL="2" V="34">
            <P T="[UNIVERSAL 24]" TL="2" V="15">20141121081143Z</P>
            <P T="[UNIVERSAL 24]" TL="2" V="15">99991231235959Z</P>

certtool does not report the value written to the certificate. I would say
this is a bug.

When I try to set the expiration date, I get an error:

$ echo -e "cn=test\nexpiration_date=\"2050-01-01 00:00:00\"" > cfg

$ certtool --generate-self-signed --template cfg --load-privkey key
--outder > crt
Generating a self signed certificate...
Cannot parse date: 2050-01-01 00:00:00

What is wrong with the date?

I am using Debian 7 on AMD Geode with 32 bit.

Regards
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141121/e65ab49c/attachment-0001.html>

From nmav at gnutls.org  Fri Nov 21 12:51:44 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Nov 2014 12:51:44 +0100
Subject: [gnutls-help] Year 2038 problem
In-Reply-To: <CAGUt3y4=sAB7uxeiCmtYm0_QX8ifiWffJc1dSDCgnAgk2tUZBg@mail.gmail.com>
References: <CAGUt3y4WKF9=tqxTPatDn3W33iQxL+bRp-9DoWOyzYMgTT4e9Q@mail.gmail.com>
 <1416243654.6812.1.camel@gnutls.org>
 <CAGUt3y4=sAB7uxeiCmtYm0_QX8ifiWffJc1dSDCgnAgk2tUZBg@mail.gmail.com>
Message-ID: <CAJU7za+qaR2Ow=Nk_hCqYVeZgmmVr888LzYwjodF4=XwLr07kQ@mail.gmail.com>

On Fri, Nov 21, 2014 at 9:37 AM, Sascha Ziemann <ceving at gmail.com> wrote:
>                 Not Before: Fri Nov 21 08:11:43 UTC 2014
>                 Not After: Thu Dec 31 23:23:23 UTC 2037
[...]
> When I try to set the expiration date, I get an error:
>
> $ echo -e "cn=test\nexpiration_date=\"2050-01-01 00:00:00\"" > cfg
> $ certtool --generate-self-signed --template cfg --load-privkey key --outder
>> crt
> Generating a self signed certificate...
> Cannot parse date: 2050-01-01 00:00:00
> What is wrong with the date?
> I am using Debian 7 on AMD Geode with 32 bit.

It seems that this system uses a 32-bit time_t and this is the reason
you get these results.
The "2037-12-31 23:23:23" is the overflow time set by gnutls if the
result exceeds the maximum time that can be expressed. This is also
the reason date parsing fails (struct timespec also consists of 32-bit
values it seems).

What you can do on such system is to set expirations_days to -1, and
that would give you a certificate that doesn't expire. I was under the
impression that these systems already had a 64-bit time_t, but that
doesn't seem to be the case.

regards,
Nikos


From visser at terena.org  Wed Nov 26 17:28:40 2014
From: visser at terena.org (Dick Visser)
Date: Wed, 26 Nov 2014 17:28:40 +0100
Subject: [gnutls-help] Non-interactive way of printing certs with gnutls-cli
	and --starttls
Message-ID: <CAEQQDNmaiT8k2oGVKwOJt5o536wJzF8m_Gqa5Pe_JY7+vMTvtg@mail.gmail.com>

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