From nmav at gnutls.org  Sun May  3 20:03:47 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 May 2015 20:03:47 +0200
Subject: [gnutls-devel] gnutls 3.3.15
Message-ID: <1430676227.17186.1.camel@gnutls.org>

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

* Version 3.3.15 (released 2015-05-03)

** libgnutls: gnutls_certificate_get_ours: will return the certificate even
if a callback was used to send it.

** libgnutls: Fix for MD5 downgrade in TLS 1.2 signatures. Reported by
Karthikeyan Bhargavan [GNUTLS-SA-2015-2].

** libgnutls: Check for invalid length in the X.509 version field. Without the check
certificates with invalid length would be detected as having an arbitrary
version. Reported by Hanno B?ck.

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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.15.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.15.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  Sun May  3 20:05:29 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 May 2015 20:05:29 +0200
Subject: [gnutls-devel] gnutls 3.4.1
Message-ID: <1430676329.17186.2.camel@gnutls.org>

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

* Version 3.4.1 (released 2015-05-03)

** libgnutls: gnutls_certificate_get_ours: will return the certificate even
if a callback was used to send it.

** libgnutls: Check for invalid length in the X.509 version field. Without
the check certificates with invalid length would be detected as having an
arbitrary version. Reported by Hanno B?ck.

** libgnutls: Handle DNS name constraints with a leading dot. Patch by
Fotis Loukos.

** libgnutls: Updated system-keys support for windows to compile in more
versions of mingw. Patch by Tim Kosse.

** libgnutls: Fix for MD5 downgrade in TLS 1.2 signatures. Reported by
Karthikeyan Bhargavan [GNUTLS-SA-2015-2].

** libgnutls: Reverted: The gnutls_handshake() process will enforce a timeout
by default. That caused issues with non-blocking programs.

** certtool: It can generate SHA256 key IDs.

** gnutls-cli: fixed crash in --benchmark-ciphers. Reported by James Cloos.

** configure: re-enabled the --enable-local-libopts flag

** API and ABI modifications:
gnutls_x509_crt_get_pk_ecc_raw: Added


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.4/gnutls-3.4.1.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.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 dam at opencsw.org  Sun May  3 21:46:25 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 3 May 2015 21:46:25 +0200
Subject: [gnutls-devel] Build failure of GnuTLS
Message-ID: <1E915CC5-9F05-4AA4-A6AB-AEA3DBE9FB96@opencsw.org>

Hi,

I am trying the latest 3.3.14 on Solaris 10 Sparc with GCC 4.9 and get the following error:

gmake[6]: Entering directory '/home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnutls-3.3.14/src/gl'
  CC       c-ctype.lo
  CC       exitfail.lo
  CC       fd-hook.lo
  CC       gettime.lo
  CC       malloca.lo
  CC       parse-datetime.lo
  CC       progname.lo
  CC       read-file.lo
  CC       sockets.lo
  CC       sys_socket.lo
  CC       timespec.lo
  CC       unistd.lo
  CC       xmalloc.lo
  CC       xalloc-die.lo
  CC       xsize.lo
  CC       asnprintf.lo
  CC       error.lo
  CC       getdelim.lo
  CC       getline.lo
  CC       mktime.lo
gmake[6]: *** No rule to make target 'printf-args.c', needed by 'printf-args.lo'.  Stop.
gmake[6]: Leaving directory '/home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnutls-3.3.14/src/gl'


It looks like the bootstrapping from gnulib is missing some substitutions needed for Solaris.


Best regards

  ? Dago


-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2418 bytes
Desc: not available
URL: </pipermail/attachments/20150503/678df50a/attachment.bin>

From jaak.ristioja at cyber.ee  Mon May  4 09:53:10 2015
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Mon,  4 May 2015 10:53:10 +0300
Subject: [gnutls-devel] [PATCH] doc: Fixed typo in heartbeat documentation.
Message-ID: <1430725990-19613-1-git-send-email-jaak.ristioja@cyber.ee>

---
 doc/cha-intro-tls.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/cha-intro-tls.texi b/doc/cha-intro-tls.texi
index 6a15b0f..e5468ee 100644
--- a/doc/cha-intro-tls.texi
+++ b/doc/cha-intro-tls.texi
@@ -456,7 +456,7 @@ and is described in @xcite{RFC6520}. The extension is disabled by default and
 @funcref{gnutls_heartbeat_enable} can be used to enable it. A policy
 may be negotiated to only allow sending heartbeat messages or sending and receiving.
 The current session policy can be checked with @funcref{gnutls_heartbeat_allowed}. 
-The requests coming from the peer result to @code{GNUTLS_ at -E_@-HERTBEAT_ at -PING_@-RECEIVED}
+The requests coming from the peer result to @code{GNUTLS_ at -E_@-HEARTBEAT_ at -PING_@-RECEIVED}
 being returned from the receive function. Ping requests to peer can be send via
 @funcref{gnutls_heartbeat_ping}. 
 
-- 
2.4.0



From nmav at gnutls.org  Mon May  4 10:34:38 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 4 May 2015 10:34:38 +0200
Subject: [gnutls-devel] [PATCH] doc: Fixed typo in heartbeat
	documentation.
In-Reply-To: <1430725990-19613-1-git-send-email-jaak.ristioja@cyber.ee>
References: <1430725990-19613-1-git-send-email-jaak.ristioja@cyber.ee>
Message-ID: <CAJU7zaLe_8A5wfUa2RDffnc_m0tc0EZSEpkNspphNpf9mzLzAQ@mail.gmail.com>

Applied, thank you.

On Mon, May 4, 2015 at 9:53 AM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
> ---
>  doc/cha-intro-tls.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/cha-intro-tls.texi b/doc/cha-intro-tls.texi
> index 6a15b0f..e5468ee 100644
> --- a/doc/cha-intro-tls.texi
> +++ b/doc/cha-intro-tls.texi
> @@ -456,7 +456,7 @@ and is described in @xcite{RFC6520}. The extension is disabled by default and
>  @funcref{gnutls_heartbeat_enable} can be used to enable it. A policy
>  may be negotiated to only allow sending heartbeat messages or sending and receiving.
>  The current session policy can be checked with @funcref{gnutls_heartbeat_allowed}.
> -The requests coming from the peer result to @code{GNUTLS_ at -E_@-HERTBEAT_ at -PING_@-RECEIVED}
> +The requests coming from the peer result to @code{GNUTLS_ at -E_@-HEARTBEAT_ at -PING_@-RECEIVED}
>  being returned from the receive function. Ping requests to peer can be send via
>  @funcref{gnutls_heartbeat_ping}.
>
> --
> 2.4.0
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel


From n.mavrogiannopoulos at gmail.com  Mon May  4 15:50:23 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 4 May 2015 15:50:23 +0200
Subject: [gnutls-devel] libidn + 3.4.1 = cves?
Message-ID: <CAJU7za+tjcL=7cJwnuCgKak7KhcYhu3prJCqb5Q91rdrhPbztw@mail.gmail.com>

Hello,
 It seems that libidn cannot currently handle untrusted input [1].
According to thread in [0] libidn expects the input to be checked
before. However, we have no way to do that in gnutls, so most probably
we need to (1) disable libidn support by default in 3.4.x - i.e.,
internationalized dns names and correct comparison of them, (2) switch
to some other library, (3) wait until the issue (assigned
CVE-2015-2059) is resolved upstream.

I'm currently leaning towards (3), and take action before 3.4.x
becomes stable. Any suggestions on comments on the issue?

regards,
Nikos


[0]. http://permalink.gmane.org/gmane.comp.gnu.libidn.general/555
[1]. http://permalink.gmane.org/gmane.comp.gnu.libidn.general/573


From n.mavrogiannopoulos at gmail.com  Mon May  4 16:01:39 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 4 May 2015 16:01:39 +0200
Subject: [gnutls-devel] gnutls 3.3.x + nettle 3.x
Message-ID: <CAJU7za+U=yhk7LWrBB4jQ9TPV4mqQmZHwiKCUFBs48dt_hSgDA@mail.gmail.com>

Hello,
 I had to make a patch to compile gnutls 3.3.x using nettle 3.1 or
later. For that I make a short patch in [0]. Is there wider interest
for such a feature in 3.3.x? If there is it would make sense to add it
conditionally in the build.

regards,
Nikos

[0]. http://pkgs.fedoraproject.org/cgit/compat-gnutls28.git/tree/gnutls-3.3.15-nettle3.patch


From ametzler at bebt.de  Mon May  4 18:50:37 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 4 May 2015 18:50:37 +0200
Subject: [gnutls-devel] gnutls 3.3.x + nettle 3.x
In-Reply-To: <CAJU7za+U=yhk7LWrBB4jQ9TPV4mqQmZHwiKCUFBs48dt_hSgDA@mail.gmail.com>
References: <CAJU7za+U=yhk7LWrBB4jQ9TPV4mqQmZHwiKCUFBs48dt_hSgDA@mail.gmail.com>
Message-ID: <20150504165037.GA1639@downhill.g.la>

On 2015-05-04 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
>  I had to make a patch to compile gnutls 3.3.x using nettle 3.1 or
> later. For that I make a short patch in [0]. Is there wider interest
> for such a feature in 3.3.x? If there is it would make sense to add it
> conditionally in the build.
[...]

Hello,

I have seen this on the gnutls_3_3_x branch. And made a test-upload to
Debian/experimental
(https://buildd.debian.org/status/package.php?p=gnutls28&suite=experimental).
I would like to see this feature. We would use this in Debian
temporarily as it would allow us to decouple the nettle (2.7 -> 3.x)
and gnutls (3.3 -> to 3.4) transitions.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ametzler at bebt.de  Tue May  5 19:39:17 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 5 May 2015 19:39:17 +0200
Subject: [gnutls-devel] 3.3.15 testsuite error on kfreebsd-*
Message-ID: <20150505173917.GA1623@downhill.g.la>

Hello,

the newly added sign-md5-rep test often (but not always) fails on
kfreebsd-*. --verbose does not look enlightening to me, but I have
attached logs both of a failing and a working run nevertheless.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
client|<5>| REC[0x6227b0]: Allocating epoch #0
client|<3>| ASSERT: gnutls_constate.c:586
client|<5>| REC[0x6227b0]: Allocating epoch #1
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 (C0.11)
client|<4>| EXT[0x6227b0]: Sending extension STATUS REQUEST (5 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SAFE RENEGOTIATION (1 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SESSION TICKET (0 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SUPPORTED ECC (12 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
client|<4>| EXT[0x6227b0]: sent signature algo (1.1) RSA-MD5
client|<4>| EXT[0x6227b0]: Sending extension SIGNATURE ALGORITHMS (4 bytes)
client|<4>| HSK[0x6227b0]: CLIENT HELLO was queued [117 bytes]
client|<5>| REC[0x6227b0]: Preparing Packet Handshake(22) with length: 117 and min pad: 0
client|<5>| REC[0x6227b0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 122
client|<3>| ASSERT: gnutls_buffers.c:1138
server|<3>| ASSERT: common.c:1052
server|<3>| ASSERT: common.c:1052
server|<3>| ASSERT: x509_ext.c:115
server|<3>| ASSERT: x509.c:1396
server|<3>| ASSERT: common.c:1052
server|<3>| ASSERT: common.c:1052
server|<5>| REC[0x624170]: Allocating epoch #0
server|<3>| ASSERT: gnutls_constate.c:586
server|<5>| REC[0x624170]: Allocating epoch #1
server|<3>| ASSERT: gnutls_buffers.c:1138
server|<10>| READ: Got 5 bytes from 0x5
server|<10>| READ: read 5 bytes from 0x5
server|<10>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server|<10>| RB: Requested 5 bytes
server|<5>| REC[0x624170]: SSL 3.1 Handshake packet received. Epoch 0, length: 117
server|<5>| REC[0x624170]: Expected Packet Handshake(22)
server|<5>| REC[0x624170]: Received Packet Handshake(22) with length: 117
server|<10>| READ: Got 117 bytes from 0x5
server|<10>| READ: read 117 bytes from 0x5
server|<10>| RB: Have 5 bytes into buffer. Adding 117 bytes.
server|<10>| RB: Requested 122 bytes
server|<5>| REC[0x624170]: Decrypted Packet[0] Handshake(22) with length: 117
server|<13>| BUF[REC]: Inserted 117 bytes of Data(22)
server|<4>| HSK[0x624170]: CLIENT HELLO (1) was received. Length 113[113], frag offset 0, frag length: 113, sequence: 0
server|<4>| HSK[0x624170]: Client's version: 3.3
server|<3>| ASSERT: gnutls_db.c:263
server|<4>| EXT[0x624170]: Found extension 'STATUS REQUEST/5'
server|<4>| EXT[0x624170]: Found extension 'SAFE RENEGOTIATION/65281'
server|<4>| EXT[0x624170]: Found extension 'SESSION TICKET/35'
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC/10'
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
server|<4>| EXT[0x624170]: Found extension 'SIGNATURE ALGORITHMS/13'
server|<4>| EXT[0x624170]: Found extension 'STATUS REQUEST/5'
server|<4>| EXT[0x624170]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
server|<4>| EXT[0x624170]: Parsing extension 'SESSION TICKET/35' (0 bytes)
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC/10'
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
server|<4>| EXT[0x624170]: Found extension 'SIGNATURE ALGORITHMS/13'
server|<4>| EXT[0x624170]: Parsing extension 'STATUS REQUEST/5' (5 bytes)
server|<4>| EXT[0x624170]: Found extension 'SAFE RENEGOTIATION/65281'
server|<4>| EXT[0x624170]: Found extension 'SESSION TICKET/35'
server|<4>| EXT[0x624170]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
server|<4>| HSK[0x624170]: Selected ECC curve SECP256R1 (2)
server|<4>| EXT[0x624170]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes)
server|<4>| EXT[0x624170]: Parsing extension 'SIGNATURE ALGORITHMS/13' (4 bytes)
server|<4>| EXT[0x624170]: rcvd signature algo (1.1) RSA-MD5
server|<3>| ASSERT: server_name.c:297
server|<4>| HSK[0x624170]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
server|<4>| HSK[0x624170]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 (C0.11)
server|<4>| HSK[0x624170]: Requested cipher suites[size: 24]: 
server|<4>| 	0xc0, 0x2f ECDHE_RSA_AES_128_GCM_SHA256
server|<4>| HSK[0x624170]: Selected cipher suite: ECDHE_RSA_AES_128_GCM_SHA256
server|<4>| HSK[0x624170]: Selected Compression Method: NULL
server|<4>| HSK[0x624170]: Safe renegotiation succeeded
server|<3>| ASSERT: status_request.c:218
server|<4>| EXT[0x624170]: Sending extension SAFE RENEGOTIATION (1 bytes)
server|<4>| EXT[0x624170]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
server|<4>| HSK[0x624170]: SessionID: f7dd72bc01ec0252594a112bb135f2e30741b0da5f03efc7b9f4a72fa401702f
server|<4>| HSK[0x624170]: SERVER HELLO was queued [87 bytes]
server|<11>| HWRITE: enqueued [SERVER HELLO] 87. Total 87 bytes.
server|<4>| HSK[0x624170]: CERTIFICATE was queued [612 bytes]
server|<11>| HWRITE: enqueued [CERTIFICATE] 612. Total 699 bytes.
server|<4>| HSK[0x624170]: signing handshake data: using RSA-MD5
server|<4>| HSK[0x624170]: SERVER KEY EXCHANGE was queued [205 bytes]
server|<11>| HWRITE: enqueued [SERVER KEY EXCHANGE] 205. Total 904 bytes.
server|<4>| HSK[0x624170]: SERVER HELLO DONE was queued [4 bytes]
server|<11>| HWRITE: enqueued [SERVER HELLO DONE] 4. Total 908 bytes.
server|<11>| HWRITE FLUSH: 908 bytes in buffer.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 87 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 92 bytes for 0x5. Total 92 bytes.
server|<5>| REC[0x624170]: Sent Packet[1] Handshake(22) in epoch 0 and length: 92
server|<11>| HWRITE: wrote 1 bytes, 821 bytes left.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 612 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 617 bytes for 0x5. Total 709 bytes.
server|<5>| REC[0x624170]: Sent Packet[2] Handshake(22) in epoch 0 and length: 617
server|<11>| HWRITE: wrote 1 bytes, 209 bytes left.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 205 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 210 bytes for 0x5. Total 919 bytes.
server|<5>| REC[0x624170]: Sent Packet[3] Handshake(22) in epoch 0 and length: 210
server|<11>| HWRITE: wrote 1 bytes, 4 bytes left.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 4 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 9 bytes for 0x5. Total 928 bytes.
server|<5>| REC[0x624170]: Sent Packet[4] Handshake(22) in epoch 0 and length: 9
server|<11>| HWRITE: wrote 1 bytes, 0 bytes left.
server|<11>| WRITE FLUSH: 928 bytes in buffer.
server|<11>| WRITE: wrote 928 bytes, 0 bytes left.
server|<3>| ASSERT: gnutls_buffers.c:1138
client|<5>| REC[0x6227b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 87
client|<5>| REC[0x6227b0]: Expected Packet Handshake(22)
client|<5>| REC[0x6227b0]: Received Packet Handshake(22) with length: 87
client|<5>| REC[0x6227b0]: Decrypted Packet[0] Handshake(22) with length: 87
client|<4>| HSK[0x6227b0]: SERVER HELLO (2) was received. Length 83[83], frag offset 0, frag length: 83, sequence: 0
client|<4>| HSK[0x6227b0]: Server's version: 3.3
client|<4>| HSK[0x6227b0]: SessionID length: 32
client|<4>| HSK[0x6227b0]: SessionID: f7dd72bc01ec0252594a112bb135f2e30741b0da5f03efc7b9f4a72fa401702f
client|<4>| HSK[0x6227b0]: Selected cipher suite: ECDHE_RSA_AES_128_GCM_SHA256
client|<4>| HSK[0x6227b0]: Selected compression method: NULL (0)
client|<4>| EXT[0x6227b0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
client|<4>| EXT[0x6227b0]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes)
client|<4>| HSK[0x6227b0]: Safe renegotiation succeeded
client|<3>| ASSERT: gnutls_buffers.c:1138
client|<5>| REC[0x6227b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 612
client|<5>| REC[0x6227b0]: Expected Packet Handshake(22)
client|<5>| REC[0x6227b0]: Received Packet Handshake(22) with length: 612
client|<5>| REC[0x6227b0]: Decrypted Packet[1] Handshake(22) with length: 612
client|<4>| HSK[0x6227b0]: CERTIFICATE (11) was received. Length 608[608], frag offset 0, frag length: 608, sequence: 0
client|<3>| ASSERT: common.c:1052
client|<3>| ASSERT: common.c:1052
client|<3>| ASSERT: gnutls_buffers.c:1138
client|<5>| REC[0x6227b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 205
client|<5>| REC[0x6227b0]: Expected Packet Handshake(22)
client|<5>| REC[0x6227b0]: Received Packet Handshake(22) with length: 205
client|<5>| REC[0x6227b0]: Decrypted Packet[2] Handshake(22) with length: 205
client|<4>| HSK[0x6227b0]: SERVER KEY EXCHANGE (12) was received. Length 201[201], frag offset 0, frag length: 201, sequence: 0
client|<4>| HSK[0x6227b0]: Selected ECC curve SECP256R1 (2)
client|<3>| ASSERT: common.c:1052
client|<3>| ASSERT: common.c:1052
client|<4>| HSK[0x6227b0]: verify handshake data: using RSA-MD5
client|<3>| ASSERT: gnutls_sig.c:352
client|<3>| ASSERT: cert.c:2264
client|<3>| ASSERT: gnutls_kx.c:459
client|<3>| ASSERT: gnutls_handshake.c:2760
server|<10>| READ: Got 0 bytes from 0x5
server|<10>| READ: read 0 bytes from 0x5
server|<3>| ASSERT: gnutls_buffers.c:576
server|<3>| ASSERT: gnutls_record.c:1058
server|<3>| ASSERT: gnutls_record.c:1179
server|<3>| ASSERT: gnutls_buffers.c:1392
server|<3>| ASSERT: gnutls_handshake.c:1428
server|<3>| ASSERT: gnutls_handshake.c:3193
server|<5>| REC[0x624170]: Start of epoch cleanup
server|<5>| REC[0x624170]: End of epoch cleanup
server|<5>| REC[0x624170]: Epoch #0 freed
server|<5>| REC[0x624170]: Epoch #1 freed
server: Handshake has failed (The TLS connection was non-properly terminated.)

Child died with status 1
-------------- next part --------------
client|<5>| REC[0x6227b0]: Allocating epoch #0
client|<3>| ASSERT: gnutls_constate.c:586
client|<5>| REC[0x6227b0]: Allocating epoch #1
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
client|<4>| HSK[0x6227b0]: Keeping ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 (C0.11)
client|<4>| EXT[0x6227b0]: Sending extension STATUS REQUEST (5 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SAFE RENEGOTIATION (1 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SESSION TICKET (0 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SUPPORTED ECC (12 bytes)
client|<4>| EXT[0x6227b0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
client|<4>| EXT[0x6227b0]: sent signature algo (1.1) RSA-MD5
client|<4>| EXT[0x6227b0]: Sending extension SIGNATURE ALGORITHMS (4 bytes)
client|<4>| HSK[0x6227b0]: CLIENT HELLO was queued [117 bytes]
client|<5>| REC[0x6227b0]: Preparing Packet Handshake(22) with length: 117 and min pad: 0
client|<5>| REC[0x6227b0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 122
client|<3>| ASSERT: gnutls_buffers.c:1138
server|<3>| ASSERT: common.c:1052
server|<3>| ASSERT: common.c:1052
server|<3>| ASSERT: x509_ext.c:115
server|<3>| ASSERT: x509.c:1396
server|<3>| ASSERT: common.c:1052
server|<3>| ASSERT: common.c:1052
server|<5>| REC[0x624170]: Allocating epoch #0
server|<3>| ASSERT: gnutls_constate.c:586
server|<5>| REC[0x624170]: Allocating epoch #1
server|<3>| ASSERT: gnutls_buffers.c:1138
server|<10>| READ: Got 5 bytes from 0x5
server|<10>| READ: read 5 bytes from 0x5
server|<10>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server|<10>| RB: Requested 5 bytes
server|<5>| REC[0x624170]: SSL 3.1 Handshake packet received. Epoch 0, length: 117
server|<5>| REC[0x624170]: Expected Packet Handshake(22)
server|<5>| REC[0x624170]: Received Packet Handshake(22) with length: 117
server|<10>| READ: Got 117 bytes from 0x5
server|<10>| READ: read 117 bytes from 0x5
server|<10>| RB: Have 5 bytes into buffer. Adding 117 bytes.
server|<10>| RB: Requested 122 bytes
server|<5>| REC[0x624170]: Decrypted Packet[0] Handshake(22) with length: 117
server|<13>| BUF[REC]: Inserted 117 bytes of Data(22)
server|<4>| HSK[0x624170]: CLIENT HELLO (1) was received. Length 113[113], frag offset 0, frag length: 113, sequence: 0
server|<4>| HSK[0x624170]: Client's version: 3.3
server|<3>| ASSERT: gnutls_db.c:263
server|<4>| EXT[0x624170]: Found extension 'STATUS REQUEST/5'
server|<4>| EXT[0x624170]: Found extension 'SAFE RENEGOTIATION/65281'
server|<4>| EXT[0x624170]: Found extension 'SESSION TICKET/35'
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC/10'
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
server|<4>| EXT[0x624170]: Found extension 'SIGNATURE ALGORITHMS/13'
server|<4>| EXT[0x624170]: Found extension 'STATUS REQUEST/5'
server|<4>| EXT[0x624170]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
server|<4>| EXT[0x624170]: Parsing extension 'SESSION TICKET/35' (0 bytes)
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC/10'
server|<4>| EXT[0x624170]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
server|<4>| EXT[0x624170]: Found extension 'SIGNATURE ALGORITHMS/13'
server|<4>| EXT[0x624170]: Parsing extension 'STATUS REQUEST/5' (5 bytes)
server|<4>| EXT[0x624170]: Found extension 'SAFE RENEGOTIATION/65281'
server|<4>| EXT[0x624170]: Found extension 'SESSION TICKET/35'
server|<4>| EXT[0x624170]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
server|<4>| HSK[0x624170]: Selected ECC curve SECP256R1 (2)
server|<4>| EXT[0x624170]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes)
server|<4>| EXT[0x624170]: Parsing extension 'SIGNATURE ALGORITHMS/13' (4 bytes)
server|<4>| EXT[0x624170]: rcvd signature algo (1.1) RSA-MD5
server|<3>| ASSERT: server_name.c:297
server|<4>| HSK[0x624170]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
server|<4>| HSK[0x624170]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
server|<4>| HSK[0x624170]: Keeping ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 (C0.11)
server|<4>| HSK[0x624170]: Requested cipher suites[size: 24]: 
server|<4>| 	0xc0, 0x2f ECDHE_RSA_AES_128_GCM_SHA256
server|<4>| HSK[0x624170]: Selected cipher suite: ECDHE_RSA_AES_128_GCM_SHA256
server|<4>| HSK[0x624170]: Selected Compression Method: NULL
server|<4>| HSK[0x624170]: Safe renegotiation succeeded
server|<3>| ASSERT: status_request.c:218
server|<4>| EXT[0x624170]: Sending extension SAFE RENEGOTIATION (1 bytes)
server|<4>| EXT[0x624170]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
server|<4>| HSK[0x624170]: SessionID: 05d4f997cb5645f9fd6ea27fbb42b86a8409f44519d9d2d633d171d8c68e2558
server|<4>| HSK[0x624170]: SERVER HELLO was queued [87 bytes]
server|<11>| HWRITE: enqueued [SERVER HELLO] 87. Total 87 bytes.
server|<4>| HSK[0x624170]: CERTIFICATE was queued [612 bytes]
server|<11>| HWRITE: enqueued [CERTIFICATE] 612. Total 699 bytes.
server|<4>| HSK[0x624170]: signing handshake data: using RSA-MD5
server|<4>| HSK[0x624170]: SERVER KEY EXCHANGE was queued [205 bytes]
server|<11>| HWRITE: enqueued [SERVER KEY EXCHANGE] 205. Total 904 bytes.
server|<4>| HSK[0x624170]: SERVER HELLO DONE was queued [4 bytes]
server|<11>| HWRITE: enqueued [SERVER HELLO DONE] 4. Total 908 bytes.
server|<11>| HWRITE FLUSH: 908 bytes in buffer.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 87 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 92 bytes for 0x5. Total 92 bytes.
server|<5>| REC[0x624170]: Sent Packet[1] Handshake(22) in epoch 0 and length: 92
server|<11>| HWRITE: wrote 1 bytes, 821 bytes left.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 612 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 617 bytes for 0x5. Total 709 bytes.
server|<5>| REC[0x624170]: Sent Packet[2] Handshake(22) in epoch 0 and length: 617
server|<11>| HWRITE: wrote 1 bytes, 209 bytes left.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 205 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 210 bytes for 0x5. Total 919 bytes.
server|<5>| REC[0x624170]: Sent Packet[3] Handshake(22) in epoch 0 and length: 210
server|<11>| HWRITE: wrote 1 bytes, 4 bytes left.
server|<5>| REC[0x624170]: Preparing Packet Handshake(22) with length: 4 and min pad: 0
server|<9>| ENC[0x624170]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
server|<11>| WRITE: enqueued 9 bytes for 0x5. Total 928 bytes.
server|<5>| REC[0x624170]: Sent Packet[4] Handshake(22) in epoch 0 and length: 9
server|<11>| HWRITE: wrote 1 bytes, 0 bytes left.
server|<11>| WRITE FLUSH: 928 bytes in buffer.
server|<11>| WRITE: wrote 928 bytes, 0 bytes left.
server|<3>| ASSERT: gnutls_buffers.c:1138
client|<5>| REC[0x6227b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 87
client|<5>| REC[0x6227b0]: Expected Packet Handshake(22)
client|<5>| REC[0x6227b0]: Received Packet Handshake(22) with length: 87
client|<5>| REC[0x6227b0]: Decrypted Packet[0] Handshake(22) with length: 87
client|<4>| HSK[0x6227b0]: SERVER HELLO (2) was received. Length 83[83], frag offset 0, frag length: 83, sequence: 0
client|<4>| HSK[0x6227b0]: Server's version: 3.3
client|<4>| HSK[0x6227b0]: SessionID length: 32
client|<4>| HSK[0x6227b0]: SessionID: 05d4f997cb5645f9fd6ea27fbb42b86a8409f44519d9d2d633d171d8c68e2558
client|<4>| HSK[0x6227b0]: Selected cipher suite: ECDHE_RSA_AES_128_GCM_SHA256
client|<4>| HSK[0x6227b0]: Selected compression method: NULL (0)
client|<4>| EXT[0x6227b0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
client|<4>| EXT[0x6227b0]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes)
client|<4>| HSK[0x6227b0]: Safe renegotiation succeeded
client|<3>| ASSERT: gnutls_buffers.c:1138
client|<5>| REC[0x6227b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 612
client|<5>| REC[0x6227b0]: Expected Packet Handshake(22)
client|<5>| REC[0x6227b0]: Received Packet Handshake(22) with length: 612
client|<5>| REC[0x6227b0]: Decrypted Packet[1] Handshake(22) with length: 612
client|<4>| HSK[0x6227b0]: CERTIFICATE (11) was received. Length 608[608], frag offset 0, frag length: 608, sequence: 0
client|<3>| ASSERT: common.c:1052
client|<3>| ASSERT: common.c:1052
client|<3>| ASSERT: gnutls_buffers.c:1138
client|<5>| REC[0x6227b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 205
client|<5>| REC[0x6227b0]: Expected Packet Handshake(22)
client|<5>| REC[0x6227b0]: Received Packet Handshake(22) with length: 205
client|<5>| REC[0x6227b0]: Decrypted Packet[2] Handshake(22) with length: 205
client|<4>| HSK[0x6227b0]: SERVER KEY EXCHANGE (12) was received. Length 201[201], frag offset 0, frag length: 201, sequence: 0
client|<4>| HSK[0x6227b0]: Selected ECC curve SECP256R1 (2)
client|<3>| ASSERT: common.c:1052
client|<3>| ASSERT: common.c:1052
client|<4>| HSK[0x6227b0]: verify handshake data: using RSA-MD5
client|<3>| ASSERT: gnutls_sig.c:352
client|<3>| ASSERT: cert.c:2264
client|<3>| ASSERT: gnutls_kx.c:459
client|<3>| ASSERT: gnutls_handshake.c:2760
client|<5>| REC[0x6227b0]: Start of epoch cleanup
client|<5>| REC[0x6227b0]: End of epoch cleanup
client|<5>| REC[0x6227b0]: Epoch #0 freed
client|<5>| REC[0x6227b0]: Epoch #1 freed
Self test `./sign-md5-rep' finished with 0 errors

From a.radke at arcor.de  Tue May  5 18:46:45 2015
From: a.radke at arcor.de (Andreas Radke)
Date: Tue, 5 May 2015 18:46:45 +0200
Subject: [gnutls-devel] gnutls 3.4.1
In-Reply-To: <1430676329.17186.2.camel@gnutls.org>
References: <1430676329.17186.2.camel@gnutls.org>
Message-ID: <20150505184645.6697c386@laptop64.home>

Following your suggestion I'm trying to build the new release using
--without-idn and it fails one test: 

========================================
   GnuTLS 3.4.1: tests/test-suite.log
========================================

# TOTAL: 114
# PASS:  111
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: hostname-check
====================

1152: Hostname incorrectly does not match (0)


Is it safe to skip this failure? Is it caused by libidn removal?

-Andy
ArchLinux


From nmav at gnutls.org  Wed May  6 09:53:44 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 6 May 2015 09:53:44 +0200
Subject: [gnutls-devel] 3.3.15 testsuite error on kfreebsd-*
In-Reply-To: <20150505173917.GA1623@downhill.g.la>
References: <20150505173917.GA1623@downhill.g.la>
Message-ID: <CAJU7zaLWJR-53V_RMsRnawKx5-vB81mq+AnciJwXmsTe5nYAZw@mail.gmail.com>

On Tue, May 5, 2015 at 7:39 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
> the newly added sign-md5-rep test often (but not always) fails on
> kfreebsd-*. --verbose does not look enlightening to me, but I have
> attached logs both of a failing and a working run nevertheless.

Thanks. It seems there was some race condition which causes failures
randomly. I've updated it.

regards,
Nikos


From nmav at gnutls.org  Wed May  6 10:02:45 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 6 May 2015 10:02:45 +0200
Subject: [gnutls-devel] gnutls 3.4.1
In-Reply-To: <20150505184645.6697c386@laptop64.home>
References: <1430676329.17186.2.camel@gnutls.org>
 <20150505184645.6697c386@laptop64.home>
Message-ID: <CAJU7za+9cmpwgDe_GJNQjJa7MV5-9VErHC_Os-vjvpSLAFTF7g@mail.gmail.com>

On Tue, May 5, 2015 at 6:46 PM, Andreas Radke <a.radke at arcor.de> wrote:
> Following your suggestion I'm trying to build the new release using
> --without-idn and it fails one test:
> FAIL: hostname-check
> ====================
>
> 1152: Hostname incorrectly does not match (0)
> Is it safe to skip this failure? Is it caused by libidn removal?

Correct. I'll commit a fix for that.


From nmav at gnutls.org  Wed May  6 10:11:14 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 6 May 2015 10:11:14 +0200
Subject: [gnutls-devel] Build failure of GnuTLS
In-Reply-To: <1E915CC5-9F05-4AA4-A6AB-AEA3DBE9FB96@opencsw.org>
References: <1E915CC5-9F05-4AA4-A6AB-AEA3DBE9FB96@opencsw.org>
Message-ID: <CAJU7zaKGX04DxK5Ng-CfhiamGFe3ANLM7f5ZSMxgDWzJE2bvuw@mail.gmail.com>

On Sun, May 3, 2015 at 9:46 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi,
>
> I am trying the latest 3.3.14 on Solaris 10 Sparc with GCC 4.9 and get the following error:
> gmake[6]: Entering directory '/home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnutls-3.3.14/src/gl'
>   CC       c-ctype.lo
>   CC       exitfail.lo
>   CC       fd-hook.lo
>   CC       gettime.lo
>   CC       malloca.lo
>   CC       parse-datetime.lo
>   CC       progname.lo
>   CC       read-file.lo
>   CC       sockets.lo
>   CC       sys_socket.lo
>   CC       timespec.lo
>   CC       unistd.lo
>   CC       xmalloc.lo
>   CC       xalloc-die.lo
>   CC       xsize.lo
>   CC       asnprintf.lo
>   CC       error.lo
>   CC       getdelim.lo
>   CC       getline.lo
>   CC       mktime.lo
> gmake[6]: *** No rule to make target 'printf-args.c', needed by 'printf-args.lo'.  Stop.
> gmake[6]: Leaving directory '/home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnutls-3.3.14/src/gl'
> It looks like the bootstrapping from gnulib is missing some substitutions needed for Solaris.

Hello,
 I checked both 3.3.14 and 15, and this file is present there. Are you
sure you are building from the distributed sources?

regards,
Nikos


From ametzler at bebt.de  Thu May  7 18:35:25 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 7 May 2015 18:35:25 +0200
Subject: [gnutls-devel] 3.3.15 testsuite error on kfreebsd-*
In-Reply-To: <CAJU7zaLWJR-53V_RMsRnawKx5-vB81mq+AnciJwXmsTe5nYAZw@mail.gmail.com>
References: <20150505173917.GA1623@downhill.g.la>
 <CAJU7zaLWJR-53V_RMsRnawKx5-vB81mq+AnciJwXmsTe5nYAZw@mail.gmail.com>
Message-ID: <20150507163525.GA1616@downhill.g.la>

On 2015-05-06 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Tue, May 5, 2015 at 7:39 PM, Andreas Metzler <ametzler at bebt.de> wrote:
>> the newly added sign-md5-rep test often (but not always) fails on
>> kfreebsd-*. --verbose does not look enlightening to me, but I have
>> attached logs both of a failing and a working run nevertheless.

> Thanks. It seems there was some race condition which causes failures
> randomly. I've updated it.


Thanks, worked like a charm.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ametzler at bebt.de  Sun May 10 13:24:39 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 10 May 2015 13:24:39 +0200
Subject: [gnutls-devel] NORMAL:-SIGN-ALL changed behavior in 3.3.15
Message-ID: <20150510112439.GA1291@downhill.g.la>

Hello,

I have tried finding the reason for <https://bugs.debian.org/784430>
(lynx nor being able to connect to kernel.org since upgrading GnuTLS
to 3.3.15). Afaict it comes from lynx using this byzantine priority
string:
NONE:+VERS-SSL3.0:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-GCM:+AES-128-GCM:+AES-256-CBC:+AES-128-CBC:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC:+3DES-CBC:+COMP-NULL:+DHE-RSA:+RSA:+DHE-DSS:+SHA1:+MD5

Which notably does not add any of the following after removing all by
starting with NONE:
- SIGN-* (Signature algorithms)
- CURVE-* (Elliptic curves)
- CTYPE-* (Certificate type)

Boiling this down to the simplest case shows that 3.3.14 connected
successfully (including certificate verification) to www.kernel.org,
but 3.3.15 stopped doing so. I suspect it is side-effect of the fix
for GNUTLS-SA-2015-2.

Is this the right thing to do? And if it is (I personally think so)
shouldn't
gnutls-cli --priority=NORMAL:-CTYPE-ALL www.kernel.org
also fail?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From n.mavrogiannopoulos at gmail.com  Mon May 11 08:23:41 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 11 May 2015 08:23:41 +0200
Subject: [gnutls-devel] NORMAL:-SIGN-ALL changed behavior in 3.3.15
In-Reply-To: <20150510112439.GA1291@downhill.g.la>
References: <20150510112439.GA1291@downhill.g.la>
Message-ID: <F4DADE80-9D03-4A75-BA52-8358232B7144@gmail.com>

The priority string is indeed wrong. The issue is that it enables tls1.2 but no signature algorithms.  Given that the fix in 3.3.15 is to enforce the algorithms set, the issue seen is justified. 

On 10 May 2015 13:24:39 CEST, Andreas Metzler <ametzler at bebt.de> wrote:
>Hello,
>
>I have tried finding the reason for <https://bugs.debian.org/784430>
>(lynx nor being able to connect to kernel.org since upgrading GnuTLS
>to 3.3.15). Afaict it comes from lynx using this byzantine priority
>string:
>NONE:+VERS-SSL3.0:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-GCM:+AES-128-GCM:+AES-256-CBC:+AES-128-CBC:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC:+3DES-CBC:+COMP-NULL:+DHE-RSA:+RSA:+DHE-DSS:+SHA1:+MD5
>
>Which notably does not add any of the following after removing all by
>starting with NONE:
>- SIGN-* (Signature algorithms)
>- CURVE-* (Elliptic curves)
>- CTYPE-* (Certificate type)
>
>Boiling this down to the simplest case shows that 3.3.14 connected
>successfully (including certificate verification) to www.kernel.org,
>but 3.3.15 stopped doing so. I suspect it is side-effect of the fix
>for GNUTLS-SA-2015-2.
>
>Is this the right thing to do? And if it is (I personally think so)
>shouldn't
>gnutls-cli --priority=NORMAL:-CTYPE-ALL www.kernel.org
>also fail?
>
>cu Andreas

-- 
Sent fron my mobile. Please excuse my brevity.


From ametzler at bebt.de  Mon May 11 19:18:59 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 11 May 2015 19:18:59 +0200
Subject: [gnutls-devel] NORMAL:-SIGN-ALL changed behavior in 3.3.15
In-Reply-To: <F4DADE80-9D03-4A75-BA52-8358232B7144@gmail.com>
References: <20150510112439.GA1291@downhill.g.la>
 <F4DADE80-9D03-4A75-BA52-8358232B7144@gmail.com>
Message-ID: <20150511171859.GA1335@downhill.g.la>

On 2015-05-11 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:

> On 10 May 2015 13:24:39 CEST, Andreas Metzler <ametzler at bebt.de> wrote:
> >Hello,
> >
> >I have tried finding the reason for <https://bugs.debian.org/784430>
> >(lynx nor being able to connect to kernel.org since upgrading GnuTLS
> >to 3.3.15). Afaict it comes from lynx using this byzantine priority
> >string:
> >NONE:+VERS-SSL3.0:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-GCM:+AES-128-GCM:+AES-256-CBC:+AES-128-CBC:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC:+3DES-CBC:+COMP-NULL:+DHE-RSA:+RSA:+DHE-DSS:+SHA1:+MD5

>> Boiling this down to the simplest case shows that 3.3.14 connected
>> successfully (including certificate verification) to www.kernel.org,
>> but 3.3.15 stopped doing so. I suspect it is side-effect of the fix
>> for GNUTLS-SA-2015-2.

> The priority string is indeed wrong. The issue is that it enables
> tls1.2 but no signature algorithms.  Given that the fix in 3.3.15 is
> to enforce the algorithms set, the issue seen is justified. 

Thanks for the confirmation, I will submit a bug report against lynx.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ann.lai at oracle.com  Thu May 14 00:38:06 2015
From: ann.lai at oracle.com (Ann Lai)
Date: Wed, 13 May 2015 15:38:06 -0700
Subject: [gnutls-devel] gnutls 3.4 build failed to build on Solaris because
 of missing SOCK_CLOEXEC symbol
Message-ID: <5553D24E.7000907@oracle.com>

Hi,

gnutls 3.4.0 failed to build on Solaris systems because SOCK_CLOEXEC 
symbol.  Below is a proposed patch to fix.

--- ORIGINAL/./tests/utils.c    2015-05-07 17:10:15.668662904 -0700
+++ gnutls-3.4.0/./tests/utils.c        2015-05-07 18:33:41.145146750 -0700
@@ -33,6 +33,7 @@
  #include <netinet/in.h>
  #include <sys/types.h>
  #include <sys/socket.h>
+#include <fcntl.h>

  #include "utils.h"

@@ -187,8 +188,16 @@
                 .sin_port = 0
         };
         int fd;
+       int flags;

+#ifdef SOCK_CLOEXEC
         fd = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0);
+#else
+       fd = socket(AF_INET, SOCK_DGRAM, 0);
+       flags = fcntl(fd, F_GETFD, 0);
+       if (flags >= 0)
+               fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+#endif
          setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char*)&on, sizeof(on));
  #if defined(SO_REUSEPORT)
          setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, (char*)&on, sizeof(on));

Thanks,
Ann


From nmav at gnutls.org  Fri May 15 11:48:00 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 May 2015 11:48:00 +0200
Subject: [gnutls-devel] gnutls 3.4 build failed to build on Solaris
 because of missing SOCK_CLOEXEC symbol
In-Reply-To: <5553D24E.7000907@oracle.com>
References: <5553D24E.7000907@oracle.com>
Message-ID: <CAJU7zaK-ghL2VCxMCPjX6_U8kuW_NkYG9KYMkJm_uh+vkUFezg@mail.gmail.com>

On Thu, May 14, 2015 at 12:38 AM, Ann Lai <ann.lai at oracle.com> wrote:
> Hi,
> gnutls 3.4.0 failed to build on Solaris systems because SOCK_CLOEXEC symbol.
> Below is a proposed patch to fix.

Hi,
 Wasn't that fixed in 3.4.1 release?


From nmav at gnutls.org  Fri May 15 11:48:58 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 May 2015 11:48:58 +0200
Subject: [gnutls-devel] gnutls 3.3.x + nettle 3.x
In-Reply-To: <20150504165037.GA1639@downhill.g.la>
References: <CAJU7za+U=yhk7LWrBB4jQ9TPV4mqQmZHwiKCUFBs48dt_hSgDA@mail.gmail.com>
 <20150504165037.GA1639@downhill.g.la>
Message-ID: <CAJU7zaJFA29MkH=E0w1ir8gS2XXzJA3SqjxM=L_DMjOeB7bN8g@mail.gmail.com>

On Mon, May 4, 2015 at 6:50 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> On 2015-05-04 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
>>  I had to make a patch to compile gnutls 3.3.x using nettle 3.1 or
>> later. For that I make a short patch in [0]. Is there wider interest
>> for such a feature in 3.3.x? If there is it would make sense to add it
>> conditionally in the build.
> I have seen this on the gnutls_3_3_x branch. And made a test-upload to
> Debian/experimental
> (https://buildd.debian.org/status/package.php?p=gnutls28&suite=experimental).
> I would like to see this feature. We would use this in Debian
> temporarily as it would allow us to decouple the nettle (2.7 -> 3.x)
> and gnutls (3.3 -> to 3.4) transitions.

Hi,
 I've committed a patch in the 3.3.x branch which will compile against
the nettle library which is detected (3.x or 2.7.1).

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Wed May 20 17:10:20 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 20 May 2015 17:10:20 +0200
Subject: [gnutls-devel] weak dh issue
Message-ID: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>

According to https://weakdh.org/ there is a new attack which relies on
clients accepting weak DHE parameters. GnuTLS is unaffected by this
attack, and it seems like a good choice that we always imposed higher
standards for parameters than other implementations despite the many
bug reports [0] in the past.

[0]. http://www.gnutls.org/faq.html#prime-not-acceptable


From kurt at roeckx.be  Wed May 20 19:11:18 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 20 May 2015 19:11:18 +0200
Subject: [gnutls-devel] weak dh issue
In-Reply-To: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>
References: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>
Message-ID: <20150520171118.GA12189@roeckx.be>

On Wed, May 20, 2015 at 05:10:20PM +0200, Nikos Mavrogiannopoulos wrote:
> According to https://weakdh.org/ there is a new attack which relies on
> clients accepting weak DHE parameters. GnuTLS is unaffected by this
> attack, and it seems like a good choice that we always imposed higher
> standards for parameters than other implementations despite the many
> bug reports [0] in the past.

But you should consider changing the minimum to 1024 instead of
the current 768.


Kurt



From nmav at gnutls.org  Wed May 20 20:23:54 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 May 2015 20:23:54 +0200
Subject: [gnutls-devel] weak dh issue
In-Reply-To: <20150520171118.GA12189@roeckx.be>
References: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>
 <20150520171118.GA12189@roeckx.be>
Message-ID: <1432146234.3408.6.camel@gnutls.org>

On Wed, 2015-05-20 at 19:11 +0200, Kurt Roeckx wrote:
> On Wed, May 20, 2015 at 05:10:20PM +0200, Nikos Mavrogiannopoulos wrote:
> > According to https://weakdh.org/ there is a new attack which relies on
> > clients accepting weak DHE parameters. GnuTLS is unaffected by this
> > attack, and it seems like a good choice that we always imposed higher
> > standards for parameters than other implementations despite the many
> > bug reports [0] in the past.
> But you should consider changing the minimum to 1024 instead of
> the current 768.

Indeed, that attack provides a good opportunity for that. In fact the
only way to increase the security levels today is due to the publicity
of these attacks. Without that, it is an uphill battle to convince users
users and administrators that less than 1024-bit DH parameters is not
enough, when all the browsers connect to those sites with no warning.

regards,
Nikos




From nmav at gnutls.org  Wed May 20 20:32:29 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 May 2015 20:32:29 +0200
Subject: [gnutls-devel] weak dh issue
In-Reply-To: <20150520171118.GA12189@roeckx.be>
References: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>
 <20150520171118.GA12189@roeckx.be>
Message-ID: <1432146749.3408.7.camel@gnutls.org>

On Wed, 2015-05-20 at 19:11 +0200, Kurt Roeckx wrote:
> On Wed, May 20, 2015 at 05:10:20PM +0200, Nikos Mavrogiannopoulos wrote:
> > According to https://weakdh.org/ there is a new attack which relies on
> > clients accepting weak DHE parameters. GnuTLS is unaffected by this
> > attack, and it seems like a good choice that we always imposed higher
> > standards for parameters than other implementations despite the many
> > bug reports [0] in the past.
> But you should consider changing the minimum to 1024 instead of
> the current 768.

Checking it further, it seems the current is not 768 but 1008. It is the
web page that wasn't updated.

regards,
Nikos




From tim.kosse at filezilla-project.org  Wed May 20 22:36:56 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Wed, 20 May 2015 22:36:56 +0200
Subject: [gnutls-devel] weak dh issue
In-Reply-To: <1432146749.3408.7.camel@gnutls.org>
References: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>
 <20150520171118.GA12189@roeckx.be> <1432146749.3408.7.camel@gnutls.org>
Message-ID: <555CF068.2060704@filezilla-project.org>

Hi,

On 2015-05-20 20:32, Nikos Mavrogiannopoulos wrote:
> Checking it further, it seems the current is not 768 but 1008. It is the
> web page that wasn't updated.

The documentation for the deprecated gnutls_dh_set_prime_bits currently
says "values lower than 512 bits may allow decryption of the exchanged
data". I suppose this needs to be updated as well as long as the
function isn't removed.

Regards,
Tim Kosse

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

From nmav at gnutls.org  Thu May 21 11:57:34 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 21 May 2015 11:57:34 +0200
Subject: [gnutls-devel] weak dh issue
In-Reply-To: <555CF068.2060704@filezilla-project.org>
References: <CAJU7za+ZdeZk3iPiZWCg1LLh=jL-dupX2QeSy8z1fH79bn2Y+g@mail.gmail.com>
 <20150520171118.GA12189@roeckx.be>
 <1432146749.3408.7.camel@gnutls.org>
 <555CF068.2060704@filezilla-project.org>
Message-ID: <CAJU7zaJLY3mY9yA5pddMFC4NrbpX2V10nQmgM0HyQVMjdFf9hg@mail.gmail.com>

On Wed, May 20, 2015 at 10:36 PM, Tim Kosse
<tim.kosse at filezilla-project.org> wrote:
> Hi,
> The documentation for the deprecated gnutls_dh_set_prime_bits currently
> says "values lower than 512 bits may allow decryption of the exchanged
> data". I suppose this needs to be updated as well as long as the
> function isn't removed.

Updated to warn if setting anything lower than the current default.
https://gitlab.com/gnutls/gnutls/commit/de12109088650e3c55e1b942987d899b15ca2a17

regards,
Nikos


From thomas2.klute at uni-dortmund.de  Fri May 22 00:17:27 2015
From: thomas2.klute at uni-dortmund.de (Thomas Klute)
Date: Fri, 22 May 2015 00:17:27 +0200
Subject: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to
	prime
Message-ID: <555E5977.2090804@uni-dortmund.de>

Hello,

I believe I have found a bug in gnutls_dh_get_group: It returns the
prime with an extra zero byte at the beginning.

The small program at [1] tries a handshake with DHE and then compares
the parameters with those read from a PEM encoded PKCS3 file (assuming
it's the same one used by the server). The prime as read from the file
matches the one in the Server Key Exchange packet (checked with
Wireshark), but the gnutls_datum_t filled by gnutls_dh_get_group
contains the extra byte. With the one byte offset in lines 240 and 241
[2], the primes match.

You can try my example code as follows:

Compile:
$ gcc --std=gnu11 -o dh_check dh_check.c `pkg-config --libs --cflags gnutls`

Start gnutls-serv with an X.509 key/cert and custom DH params from
dhfile.pem (or store the default params in that file) and run the example:
$ ./dh_check -c dhfile.pem

By default, dh_check tries to connect to localhost:443, you can use -h
HOST and -p PORT to connect to somewhere else.

The handshake works as expected, so I guess the bug is just in the code
that retrieves the prime from the session. ;-)

Kind regards,
Thomas


[1] https://gist.github.com/airtower-luna/5a62fd9356a19157471c
[2]
https://gist.github.com/airtower-luna/5a62fd9356a19157471c#file-dh_check-c-L240-L241


From nmav at gnutls.org  Fri May 22 09:05:46 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 22 May 2015 09:05:46 +0200
Subject: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to
	prime
In-Reply-To: <555E5977.2090804@uni-dortmund.de>
References: <555E5977.2090804@uni-dortmund.de>
Message-ID: <CAJU7zaJR7802LZDi7Gsq=+-V3xpsOx4pdNtgxwu7RBATpC0=rw@mail.gmail.com>

On Fri, May 22, 2015 at 12:17 AM, Thomas Klute
<thomas2.klute at uni-dortmund.de> wrote:
> Hello,
> I believe I have found a bug in gnutls_dh_get_group: It returns the
> prime with an extra zero byte at the beginning.

Indeed, I see that the number is written as a non-negative integer
there, so it will have a leading zero if the number would have been
interpreted as negative. The intention was to assist applications who
may import that value in an mpz_t value. Would it make sense to
document the fact that there may be a leading zero in that case,
rather than eliminating? That behavior has been for quite some time
and I believe any users of this function would already use or work
around it.

regards,
Nikos


From thomas2.klute at uni-dortmund.de  Fri May 22 16:11:18 2015
From: thomas2.klute at uni-dortmund.de (Thomas Klute)
Date: Fri, 22 May 2015 16:11:18 +0200
Subject: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to
 prime
In-Reply-To: <CAJU7zaJR7802LZDi7Gsq=+-V3xpsOx4pdNtgxwu7RBATpC0=rw@mail.gmail.com>
References: <555E5977.2090804@uni-dortmund.de>
 <CAJU7zaJR7802LZDi7Gsq=+-V3xpsOx4pdNtgxwu7RBATpC0=rw@mail.gmail.com>
Message-ID: <555F3906.9040807@uni-dortmund.de>

Am 22.05.2015 um 09:05 schrieb Nikos Mavrogiannopoulos:
> On Fri, May 22, 2015 at 12:17 AM, Thomas Klute
> <thomas2.klute at uni-dortmund.de> wrote:
>> Hello,
>> I believe I have found a bug in gnutls_dh_get_group: It returns the
>> prime with an extra zero byte at the beginning.
> 
> Indeed, I see that the number is written as a non-negative integer
> there, so it will have a leading zero if the number would have been
> interpreted as negative. The intention was to assist applications who
> may import that value in an mpz_t value. Would it make sense to
> document the fact that there may be a leading zero in that case,
> rather than eliminating? That behavior has been for quite some time
> and I believe any users of this function would already use or work
> around it.

That makes sense, thank you. Knowing about the (possible) offset makes
it easy enough to work around where necessary. :-)

Kind regards,
Thomas


From home_pw at msn.com  Fri May 22 16:50:03 2015
From: home_pw at msn.com (Peter Williams)
Date: Fri, 22 May 2015 07:50:03 -0700
Subject: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte
 to	prime
Message-ID: <BAY404-EAS177893E5E072ED012682FBA92C00@phx.gbl>

Simply add comment that the value is output as an x409 integer in ber encoding (and perhaps der encoding).

In type theory, one can compare properly (according to the encoding).

When comparing certs (properly, as types), one needs formalities such as this. Historically, upon receipt of client cert during association binding, one issues a directory compare operation which, she executed by the resolver, would compare the value against the value(s) in the named directory record, to test existence of the operand in the "trust list".

Obviously a security critical operation, for which one uses formal type theory which, for certs was a little over formalized due to the any typing of the dh block.

All good fodder for structured vulnerability insertion in standards, of course, in the name of extensibility.

Sent from my Windows Phone
________________________________
From: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>
Sent: ?5/?22/?2015 12:06 AM
To: Thomas Klute<mailto:thomas2.klute at uni-dortmund.de>
Cc: bugs at gnutls.org<mailto:bugs at gnutls.org>
Subject: Re: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to prime

On Fri, May 22, 2015 at 12:17 AM, Thomas Klute
<thomas2.klute at uni-dortmund.de> wrote:
> Hello,
> I believe I have found a bug in gnutls_dh_get_group: It returns the
> prime with an extra zero byte at the beginning.

Indeed, I see that the number is written as a non-negative integer
there, so it will have a leading zero if the number would have been
interpreted as negative. The intention was to assist applications who
may import that value in an mpz_t value. Would it make sense to
document the fact that there may be a leading zero in that case,
rather than eliminating? That behavior has been for quite some time
and I believe any users of this function would already use or work
around it.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150522/8867cb63/attachment-0001.html>

From armin at arbur.net  Sun May 24 05:30:18 2015
From: armin at arbur.net (Armin Burgmeier)
Date: Sat, 23 May 2015 23:30:18 -0400
Subject: [gnutls-devel] [PATCH] gnutls_dh_get_prime_bits: return 0 if DH is
	not used
Message-ID: <1432438554.1451.17.camel@waverley>

Before, the number of bits of a zero-length number was attempted to be
extracted, resulting in an error. The changed behaviour is consistent with
the documentation which explicitly states that 0 should be returned if no DH
key exchange was performed.
---
 lib/gnutls_ui.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/gnutls_ui.c b/lib/gnutls_ui.c
index f557f6c..f5e8530 100644
--- a/lib/gnutls_ui.c
+++ b/lib/gnutls_ui.c
@@ -362,6 +362,9 @@ int gnutls_dh_get_prime_bits(gnutls_session_t session)
 		return GNUTLS_E_INVALID_REQUEST;
 	}
 
+	if(dh->prime.size == 0)
+		return 0;
+
 	return mpi_buf2bits(&dh->prime);
 }
 
-- 
2.1.4



From nmav at gnutls.org  Sun May 24 13:29:18 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 24 May 2015 13:29:18 +0200
Subject: [gnutls-devel] [PATCH] gnutls_dh_get_prime_bits: return 0 if DH
 is not used
In-Reply-To: <1432438554.1451.17.camel@waverley>
References: <1432438554.1451.17.camel@waverley>
Message-ID: <1432466958.7883.2.camel@gnutls.org>

On Sat, 2015-05-23 at 23:30 -0400, Armin Burgmeier wrote:
> Before, the number of bits of a zero-length number was attempted to be
> extracted, resulting in an error. The changed behaviour is consistent with
> the documentation which explicitly states that 0 should be returned if no DH
> key exchange was performed.

Applied. Thank you.




From armin at arbur.net  Sun May 24 18:12:24 2015
From: armin at arbur.net (Armin Burgmeier)
Date: Sun, 24 May 2015 12:12:24 -0400
Subject: [gnutls-devel] RSA vs. DHE-RSA with default priority string
Message-ID: <1432483944.2026.13.camel@arbur.net>

Hi,

I have a server [0] which allows use of DHE-RSA but does not enforce it.
It does not support any ECC, though.

When connecting with gnutls-cli from master (and 3.3), it chooses RSA
key exchange instead of DHE-RSA. I only get DHE-RSA when I specify
--priority=PFS.

I compared this to gnutls-cli from gnutls 2.12.23: with the default
priority string, I get DHE-RSA. I could switch to RSA with
--priority=PERFORMANCE.

The behaviour of gnutls 2.12 seems more reasonable to me. How would I
make the current version of gnutls prefer DHE-RSA but still allow RSA if
the server does not support DH? I understand --priority=PFS completely
disables any non-PFS kx algorithms. I'd prefer not to hand-craft a
priority string that explicitly contains algorithm names, so that I stay
upwards-compatible.

Thanks,
Armin

 [0] https://server01.komline.de



From nmav at gnutls.org  Sun May 24 18:34:23 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 24 May 2015 18:34:23 +0200
Subject: [gnutls-devel] RSA vs. DHE-RSA with default priority string
In-Reply-To: <1432483944.2026.13.camel@arbur.net>
References: <1432483944.2026.13.camel@arbur.net>
Message-ID: <1432485263.14036.5.camel@gnutls.org>

On Sun, 2015-05-24 at 12:12 -0400, Armin Burgmeier wrote:
> Hi,
> 
> I have a server [0] which allows use of DHE-RSA but does not enforce it.
> It does not support any ECC, though.
> 
> When connecting with gnutls-cli from master (and 3.3), it chooses RSA
> key exchange instead of DHE-RSA. I only get DHE-RSA when I specify
> --priority=PFS.

The priorities were adjusted for DHE to be in the end of the list
sometime during the 3.x branch because of the compatibility issues these
ciphersuites have. That is if as a client you connect to a server which
presents inadequate length of prime the handshake would fail (as seen in
http://www.gnutls.org/faq.html#prime-not-acceptable ).

There is no way to avoid that, thus the solution was to move DHE in the
end of the list by the time we had reliable ECDHE support. Said that, if
you want to prioritize DHE over RSA you can do:
"PFS:+RSA", or "NORMAL:-RSA:+RSA"

regards,
Nikos




From armin at arbur.net  Sun May 24 18:47:41 2015
From: armin at arbur.net (Armin Burgmeier)
Date: Sun, 24 May 2015 12:47:41 -0400
Subject: [gnutls-devel] RSA vs. DHE-RSA with default priority string
In-Reply-To: <1432485263.14036.5.camel@gnutls.org>
References: <1432483944.2026.13.camel@arbur.net>
 <1432485263.14036.5.camel@gnutls.org>
Message-ID: <1432486061.2026.17.camel@arbur.net>

On Sun, 2015-05-24 at 18:34 +0200, Nikos Mavrogiannopoulos wrote:
> On Sun, 2015-05-24 at 12:12 -0400, Armin Burgmeier wrote:
> > Hi,
> > 
> > I have a server [0] which allows use of DHE-RSA but does not enforce it.
> > It does not support any ECC, though.
> > 
> > When connecting with gnutls-cli from master (and 3.3), it chooses RSA
> > key exchange instead of DHE-RSA. I only get DHE-RSA when I specify
> > --priority=PFS.
> 
> The priorities were adjusted for DHE to be in the end of the list
> sometime during the 3.x branch because of the compatibility issues these
> ciphersuites have. That is if as a client you connect to a server which
> presents inadequate length of prime the handshake would fail (as seen in
> http://www.gnutls.org/faq.html#prime-not-acceptable ).
> 
> There is no way to avoid that, thus the solution was to move DHE in the
> end of the list by the time we had reliable ECDHE support. Said that, if
> you want to prioritize DHE over RSA you can do:
> "PFS:+RSA", or "NORMAL:-RSA:+RSA"

Thanks for the explanation and the suggestions! I'll go with that.

Armin



From ann.lai at oracle.com  Tue May 26 20:22:32 2015
From: ann.lai at oracle.com (Ann Lai)
Date: Tue, 26 May 2015 11:22:32 -0700
Subject: [gnutls-devel] gnutls 3.4 build failed to build on Solaris
 because of missing SOCK_CLOEXEC symbol
In-Reply-To: <CAJU7zaK-ghL2VCxMCPjX6_U8kuW_NkYG9KYMkJm_uh+vkUFezg@mail.gmail.com>
References: <5553D24E.7000907@oracle.com>
 <CAJU7zaK-ghL2VCxMCPjX6_U8kuW_NkYG9KYMkJm_uh+vkUFezg@mail.gmail.com>
Message-ID: <5564B9E8.8060109@oracle.com>


On 5/15/2015 2:48 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, May 14, 2015 at 12:38 AM, Ann Lai <ann.lai at oracle.com> wrote:
>> Hi,
>> gnutls 3.4.0 failed to build on Solaris systems because SOCK_CLOEXEC symbol.
>> Below is a proposed patch to fix.
> Hi,
>   Wasn't that fixed in 3.4.1 release?
Yes it's fixed in 3.4.1.  Thanks.



From ann.lai at oracle.com  Sat May 30 04:00:24 2015
From: ann.lai at oracle.com (Ann Lai)
Date: Fri, 29 May 2015 19:00:24 -0700
Subject: [gnutls-devel] --disable-ecdhe does not take out all ecdh
Message-ID: <556919B8.1060809@oracle.com>

Hi,

It looks like with this flag --disable-ecdhe on in configure, there are 
still ecdh code in /./lib/nettle/pk.c.  The code failed to compiled when 
this flag is enabled.

I made a fix by adding ifdef around the ecdhe parts in file pk.c below:
--- ORIGINAL/./lib/nettle/pk.c  2015-05-21 16:21:09.544206257 -0700
+++ gnutls-3.4.1/./lib/nettle/pk.c      2015-05-21 16:42:37.914953878 -0700
@@ -45,13 +45,17 @@
  #include <nettle/rsa.h>
  #include <gnutls/crypto.h>
  #include <nettle/bignum.h>
+#if defined(ENABLE_ECDHE)
  #include <nettle/ecc.h>
  #include <nettle/ecdsa.h>
  #include <nettle/ecc-curve.h>
+#endif
  #include <gnettle.h>
  #include <fips.h>

+#if defined(ENABLE_ECDHE)
  static inline const struct ecc_curve *get_supported_curve(int curve);
+#endif

  static void rnd_func(void *_ctx, size_t length, uint8_t * data)
  {
@@ -64,6 +68,7 @@
         }
  }

+#if defined(ENABLE_ECDHE)
  static void
  ecc_scalar_zclear (struct ecc_scalar *s)
  {
@@ -77,6 +82,7 @@
          zeroize_key(p->p, ecc_size_a(p->ecc)*sizeof(mp_limb_t));
          ecc_point_clear(p);
  }
+#endif

  static void
  _dsa_params_get(const gnutls_pk_params_st * pk_params,
@@ -113,6 +119,7 @@
         pub->size = nettle_mpz_sizeinbase_256_u(pub->n);
  }

+#if defined(ENABLE_ECDHE)
  static int
  _ecc_params_to_privkey(const gnutls_pk_params_st * pk_params,
                        struct ecc_scalar *priv,
@@ -161,6 +168,7 @@

         return;
  }
+#endif

  #define MAX_DH_BITS DEFAULT_MAX_VERIFY_BITS
  /* This is used when we have no idea on the structure
@@ -245,6 +253,7 @@

                 break;
         }
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:
                 {
                         struct ecc_scalar ecc_priv;
@@ -290,6 +299,7 @@
                                 goto cleanup;
                         break;
                 }
+#endif
         default:
                 gnutls_assert();
                 ret = GNUTLS_E_INTERNAL_ERROR;
@@ -447,6 +457,7 @@
         const mac_entry_st *me;

         switch (algo) {
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:      /* we do ECDSA */
                 {
                         struct ecc_scalar priv;
@@ -495,6 +506,7 @@
                         }
                         break;
                 }
+#endif
         case GNUTLS_PK_DSA:
                 {
                         struct dsa_params pub;
@@ -601,6 +613,7 @@
         bigint_t tmp[2] = { NULL, NULL };

         switch (algo) {
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:      /* ECDSA */
                 {
                         struct ecc_point pub;
@@ -647,6 +660,7 @@
                         ecc_point_clear(&pub);
                         break;
                 }
+#endif
         case GNUTLS_PK_DSA:
                 {
                         struct dsa_params pub;
@@ -726,6 +740,7 @@
         return ret;
  }

+#if defined(ENABLE_ECDHE)
  static inline const struct ecc_curve *get_supported_curve(int curve)
  {
         switch (curve) {
@@ -750,6 +765,7 @@
  {
         return ((get_supported_curve(curve)!=NULL)?1:0);
  }
+#endif

  /* Generates algorithm's parameters. That is:
   *  For DSA: p, q, and g are generated.
@@ -854,9 +870,11 @@
                         break;
                 }
         case GNUTLS_PK_RSA:
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:
                 ret = 0;
                 break;
+#endif
         default:
                 gnutls_assert();
                 return GNUTLS_E_INVALID_REQUEST;
@@ -884,6 +902,7 @@
                            const gnutls_datum_t *priv_key, const 
gnutls_datum_t *pu
b_key,
                            const gnutls_datum_t *peer_key, 
gnutls_datum_t *Z);

+#if defined(ENABLE_ECDHE)
  int _gnutls_ecdh_compute_key(gnutls_ecc_curve_t curve,
                            const gnutls_datum_t *x, const 
gnutls_datum_t *y,
                            const gnutls_datum_t *k,
@@ -893,6 +912,7 @@
  int _gnutls_ecdh_generate_key(gnutls_ecc_curve_t curve,
                               gnutls_datum_t *x, gnutls_datum_t *y,
                               gnutls_datum_t *k);
+#endif


  int _gnutls_dh_generate_key(gnutls_dh_params_t dh_params,
@@ -988,6 +1008,7 @@
         return ret;
  }

+#if defined(ENABLE_ECDHE)
  int _gnutls_ecdh_generate_key(gnutls_ecc_curve_t curve,
                               gnutls_datum_t *x, gnutls_datum_t *y,
                               gnutls_datum_t *k)
@@ -1116,6 +1137,7 @@
         gnutls_pk_params_clear(&priv);
         return ret;
  }
+#endif /*ENABLE_ECDHE*/
  #endif


@@ -1308,6 +1330,7 @@

                         break;
                 }
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:
                 {
                         struct ecc_scalar key;
@@ -1350,6 +1373,7 @@

                         break;
                 }
+#endif
         default:
                 gnutls_assert();
                 return GNUTLS_E_INVALID_REQUEST;
@@ -1494,6 +1518,7 @@
                 }

                 break;
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:
                 {
                         struct ecc_point r, pub;
@@ -1567,6 +1592,7 @@
                         mpz_clear(y2);
                 }
                 break;
+#endif
         default:
                 ret = gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);
         }
@@ -1584,6 +1610,7 @@
         case GNUTLS_PK_RSA:
         case GNUTLS_PK_DSA:
                 return 0;
+#if defined(ENABLE_ECDHE)
         case GNUTLS_PK_EC:
                 {
                         /* just verify that x and y lie on the curve */
@@ -1624,6 +1651,7 @@
                         ecc_point_clear(&pub);
                 }
                 break;
+#endif
         default:
                 ret = gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);
         }
@@ -1725,5 +1753,7 @@
         .generate_keys = wrap_nettle_pk_generate_keys,
         .pk_fixup_private_params = wrap_nettle_pk_fixup,
         .derive = _wrap_nettle_pk_derive,
+#if defined(ENABLE_ECDHE)
         .curve_exists = _wrap_nettle_pk_curve_exists,
+#endif
  };

Thanks,
Ann


From broodling6 at yahoo.com  Sun May 31 01:47:47 2015
From: broodling6 at yahoo.com (Benjamin)
Date: Sat, 30 May 2015 23:47:47 +0000 (UTC)
Subject: [gnutls-devel] different lib directories for gnutls and nettle
References: <437hbgql64.wl%bjg@gnu.org>
Message-ID: <loom.20150531T014603-795@post.gmane.org>




Brian Gough <bjg <at> gnu.org> writes:

> 
> 
>   checking whether to use nettle... yes
>   checking for libnettle... no
>   configure: error: 
>     ***
>     *** Libnettle 2.1 was not found.
> 
>   make: *** [configure-work/gnutls-2.12.0/configure] Error 1
> 
> See http://chapters.gnu.org/~bjg/gsrc/logs/gnutls.txt for a complete
> example.
> 




Yes, I have gotten that same error as well. Your post was useful to know
that I was not alone in that bug, however you omit a solution to that
problem. What is the solution for Ubuntu 15.04? I am new Linux user by the way.



From nmav at gnutls.org  Sun May 31 08:55:26 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 31 May 2015 08:55:26 +0200
Subject: [gnutls-devel] --disable-ecdhe does not take out all ecdh
In-Reply-To: <556919B8.1060809@oracle.com>
References: <556919B8.1060809@oracle.com>
Message-ID: <1433055326.1711.1.camel@gnutls.org>

On Fri, 2015-05-29 at 19:00 -0700, Ann Lai wrote:
> Hi,
> 
> It looks like with this flag --disable-ecdhe on in configure, there are 
> still ecdh code in /./lib/nettle/pk.c.  The code failed to compiled when 
> this flag is enabled.
> 
> I made a fix by adding ifdef around the ecdhe parts in file pk.c below:

Hi,
 This patch doesn't apply in master. The best is to use git am to
produce the patches.

regards,
Nikos