From stbuehler at lighttpd.net  Fri Aug  2 00:53:26 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Fri, 2 Aug 2013 00:53:26 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
Message-ID: <20130802005326.46a4eb9a@chromobil.localdomain>

Hi,

I get segfaults with libgnutls28-3.2.3-1:i386 from debian unstable, client is firefox (iceweasel) 22,
TLS1.0, ciphersuite TLS_RSA_WITH_RC4_128_SHA (0x0005).
Usually this happens when I start a second request when another one is already running,
but pausing and resuming a download can trigger it too.

Thread 1 (Thread 0xb73346c0 (LWP 21681)):
#0  0xb5125add in _gnutls_epoch_set_keys () from /usr/lib/i386-linux-gnu/libgnutls.so.28
No symbol table info available.
#1  0xb5125f4b in _gnutls_write_connection_state_init () from /usr/lib/i386-linux-gnu/libgnutls.so.28
No symbol table info available.
#2  0xb5111149 in _gnutls_send_handshake_final () from /usr/lib/i386-linux-gnu/libgnutls.so.28
No symbol table info available.
#3  0xb5114cc7 in gnutls_handshake () from /usr/lib/i386-linux-gnu/libgnutls.so.28
No symbol table info available.
[...]

(dbg package is installed, but it somehow didn't contain more source information)

From the disassemble output I gathered that in gnutls_constate.c:327 
params->cipher == NULL, and dereferencing it triggers the segfault:

  if (_gnutls_cipher_priority (session, params->cipher->id) < 0)

(gdb) disassemble
Dump of assembler code for function _gnutls_epoch_set_keys:
   0xb5025a70 <+0>:     push   %ebp
   0xb5025a71 <+1>:     push   %edi
   0xb5025a72 <+2>:     push   %esi
   0xb5025a73 <+3>:     push   %ebx
   0xb5025a74 <+4>:     sub    $0x3c,%esp
   0xb5025a77 <+7>:     mov    0x50(%esp),%esi
   0xb5025a7b <+11>:    call   0xb5005ed0 <__x86.get_pc_thunk.bx>
   0xb5025a80 <+16>:    add    $0xd8580,%ebx
   0xb5025a86 <+22>:    mov    0x54(%esp),%eax
   0xb5025a8a <+26>:    mov    0xd0(%esi),%edi
   0xb5025a90 <+32>:    test   %edi,%edi
   0xb5025a92 <+34>:    je     0xb5025d86 <_gnutls_epoch_set_keys+790>
   0xb5025a98 <+40>:    lea    0x2c(%esp),%edx
   0xb5025a9c <+44>:    movzwl %ax,%eax
   0xb5025a9f <+47>:    mov    %edx,0x8(%esp)
   0xb5025aa3 <+51>:    mov    %eax,0x4(%esp)
   0xb5025aa7 <+55>:    mov    %esi,(%esp)
   0xb5025aaa <+58>:    call   0xb50255b0 <_gnutls_epoch_get>
   0xb5025aaf <+63>:    test   %eax,%eax
   0xb5025ab1 <+65>:    js     0xb5025b78 <_gnutls_epoch_set_keys+264>
   0xb5025ab7 <+71>:    mov    0x2c(%esp),%eax
   0xb5025abb <+75>:    xor    %ebp,%ebp
   0xb5025abd <+77>:    mov    0x4(%eax),%edx
   0xb5025ac0 <+80>:    test   %edx,%edx
   0xb5025ac2 <+82>:    jne    0xb5025b68 <_gnutls_epoch_set_keys+248>
   0xb5025ac8 <+88>:    mov    -0x14(%ebx),%ecx
   0xb5025ace <+94>:    cmpl   $0x3,(%ecx)
   0xb5025ad1 <+97>:    jg     0xb5025da4 <_gnutls_epoch_set_keys+820>
   0xb5025ad7 <+103>:   mov    0x8(%eax),%ebp
   0xb5025ada <+106>:   mov    0xc(%eax),%eax
=> 0xb5025add <+109>:   mov    0x4(%eax),%eax
   0xb5025ae0 <+112>:   mov    %esi,(%esp)
   0xb5025ae3 <+115>:   mov    %eax,0x4(%esp)
   0xb5025ae7 <+119>:   call   0xb50a7e00 <_gnutls_cipher_priority>

(%eax is 0)


I could ofc be doing something wrong in lighttpd2 mod_gnutls, but imho it doesn't look like it.

Regards,
Stefan


From nmav at gnutls.org  Fri Aug  2 08:32:04 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 2 Aug 2013 08:32:04 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <20130802005326.46a4eb9a@chromobil.localdomain>
References: <20130802005326.46a4eb9a@chromobil.localdomain>
Message-ID: <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>

On Fri, Aug 2, 2013 at 12:53 AM, Stefan B?hler <stbuehler at lighttpd.net> wrote:
> Hi,
> I get segfaults with libgnutls28-3.2.3-1:i386 from debian unstable, client is firefox (iceweasel) 22,
> TLS1.0, ciphersuite TLS_RSA_WITH_RC4_128_SHA (0x0005).
> Usually this happens when I start a second request when another one is already running,
> but pausing and resuming a download can trigger it too.

Hello Stefan,
 Is that crash on a resumed session? Is that re-producable using gnutls-serv?

> I could ofc be doing something wrong in lighttpd2 mod_gnutls, but imho it doesn't look like it.

It could be but I don't think so. Gnutls 3.2 had quite some
re-organization to go for speed and there could be still some rough
edges. As we have abolished the development branch, maybe it should be
explicit that development occurs with the latest stable, and mark/name
it as next-stable or something.

regards,
Nikos


From stbuehler at lighttpd.net  Fri Aug  2 15:21:29 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Fri, 2 Aug 2013 15:21:29 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
References: <20130802005326.46a4eb9a@chromobil.localdomain>
 <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
Message-ID: <20130802152129.25c9a937@chromobil.localdomain>

Hi,

On Fri, 2 Aug 2013 08:32:04 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Fri, Aug 2, 2013 at 12:53 AM, Stefan B?hler
> <stbuehler at lighttpd.net> wrote:
> > Hi,
> > I get segfaults with libgnutls28-3.2.3-1:i386 from debian unstable,
> > client is firefox (iceweasel) 22, TLS1.0, ciphersuite
> > TLS_RSA_WITH_RC4_128_SHA (0x0005). Usually this happens when I
> > start a second request when another one is already running, but
> > pausing and resuming a download can trigger it too.
> 
> Hello Stefan,
>  Is that crash on a resumed session? Is that re-producable using
> gnutls-serv?

Yes, I think it is a resumed session; it is using tickets, not cookies.

gnutls-serv somehow doesn't return a ticket, although I'm not sure why; 
I couldn't reproduce it with gnutls-serv so far, so it probably has
something to do with tickets.


I disabled keep-alive on my local test config for lighttpd2/mod_gnutls,
and now it was really easy to reproduce... just did 2 or 3 requests :)
Also I have a better backtrace now (this is amd64):

(gdb) bt full
#0  0x00007fffee4e2e76 in _gnutls_epoch_set_keys (session=session at entry=0x6bdaa0, epoch=epoch at entry=1) at gnutls_constate.c:327
        comp_algo = GNUTLS_COMP_NULL
        params = 0x6bc980
        ret = <optimized out>
#1  0x00007fffee4e3224 in _gnutls_write_connection_state_init (session=session at entry=0x6bdaa0) at gnutls_constate.c:489
        epoch_next = 1
        ret = <optimized out>
#2  0x00007fffee4d09cd in _gnutls_send_handshake_final (session=session at entry=0x6bdaa0, init=init at entry=1) at gnutls_handshake.c:2907
        ret = <optimized out>
#3  0x00007fffee4d3e39 in _gnutls_handshake_server (session=0x6bdaa0) at gnutls_handshake.c:3156
        ret = <optimized out>
#4  gnutls_handshake (session=0x6bdaa0) at gnutls_handshake.c:2530
        ret = <optimized out>
        params = 0x69d680
#5  0x00007fffee7b916f in do_gnutls_handshake (f=0x6b8b40, writing=0) at /home/stefan/projects/lighttpd/lighttpd2/src/modules/gnutls_filter.c:260
        r = <optimized out>
[...]

(gdb) p *params
$1 = {epoch = 1, initialized = 0, compression_algorithm = GNUTLS_COMP_NULL, cipher = 0x0, mac = 0x0, record_sw = {0 <repeats 64 times>}, record_sw_head_idx = 0, record_sw_size = 0, read = {mac_secret = {data = 0x0, size = 0}, IV = {data = 0x0, size = 0}, key = {
      data = 0x0, size = 0}, cipher_state = {cipher = {handle = 0x0, e = 0x0, encrypt = 0x0, decrypt = 0x0, auth = 0x0, tag = 0x0, setiv = 0x0, deinit = 0x0}, mac = {dig = {e = 0x0, hash = 0x0, output = 0x0, deinit = 0x0, key = 0x0, keysize = 0, handle = 0x0}, mac = {
          e = 0x0, mac_len = 0, hash = 0x0, setnonce = 0x0, output = 0x0, deinit = 0x0, handle = 0x0}}, is_mac = 0, ssl_hmac = 0, non_null = 0, tag_size = 0}, compression_state = {handle = 0x0, algo = GNUTLS_COMP_UNKNOWN}, sequence_number = {
      i = "\000\000\000\000\000\000\000"}, new_record_padding = 0 '\000'}, write = {mac_secret = {data = 0x0, size = 0}, IV = {data = 0x0, size = 0}, key = {data = 0x0, size = 0}, cipher_state = {cipher = {handle = 0x0, e = 0x0, encrypt = 0x0, decrypt = 0x0, 
        auth = 0x0, tag = 0x0, setiv = 0x0, deinit = 0x0}, mac = {dig = {e = 0x0, hash = 0x0, output = 0x0, deinit = 0x0, key = 0x0, keysize = 0, handle = 0x0}, mac = {e = 0x0, mac_len = 0, hash = 0x0, setnonce = 0x0, output = 0x0, deinit = 0x0, handle = 0x0}}, 
      is_mac = 0, ssl_hmac = 0, non_null = 0, tag_size = 0},
      compression_state = {handle = 0x0, algo = GNUTLS_COMP_UNKNOWN},
      sequence_number = {i = "\000\000\000\000\000\000\000"},
      new_record_padding = 0 '\000'}, usage_cnt = 0}


From stbuehler at lighttpd.net  Fri Aug  2 16:20:21 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Fri, 2 Aug 2013 16:20:21 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <20130802152129.25c9a937@chromobil.localdomain>
References: <20130802005326.46a4eb9a@chromobil.localdomain>
 <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
 <20130802152129.25c9a937@chromobil.localdomain>
Message-ID: <20130802162021.556b6ce6@chromobil.localdomain>

Hi,

I think I found the problem:

_gnutls_epoch_set_cipher_suite fails, because my normal priority string
has RC4 disabled; the hello_cb is supposed to enable RC4 for TLS1.0

Although the callback gets called (and sees the correct version and
sets the RC4 priority), _gnutls_epoch_set_cipher_suite still doesn't
accept the RC4 cipher from the ticket state.

The return value of _gnutls_epoch_set_cipher_suite isn't checked by any
of the calling functions... this should probably be fixed (same for
_gnutls_epoch_set_compression and so on).

Also it'd be nice if the hello callback could change the priority :)



From stbuehler at lighttpd.net  Fri Aug  2 16:28:40 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Fri, 2 Aug 2013 16:28:40 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <20130802162021.556b6ce6@chromobil.localdomain>
References: <20130802005326.46a4eb9a@chromobil.localdomain>
 <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
 <20130802152129.25c9a937@chromobil.localdomain>
 <20130802162021.556b6ce6@chromobil.localdomain>
Message-ID: <20130802162840.5406f4a6@chromobil.localdomain>

And again, sry :)

On Fri, 2 Aug 2013 16:20:21 +0200
Stefan B?hler <stbuehler at lighttpd.net> wrote:

> Hi,
> 
> I think I found the problem:
> 
> _gnutls_epoch_set_cipher_suite fails, because my normal priority
> string has RC4 disabled; the hello_cb is supposed to enable RC4 for
> TLS1.0
> 
> Although the callback gets called (and sees the correct version and
> sets the RC4 priority), _gnutls_epoch_set_cipher_suite still doesn't
> accept the RC4 cipher from the ticket state.

The hello callback comes after the _gnutls_epoch_set_cipher_suite
obviously, so no surprises here (the log shows this too).

> The return value of _gnutls_epoch_set_cipher_suite isn't checked by
> any of the calling functions... this should probably be fixed (same
> for _gnutls_epoch_set_compression and so on).
> 
> Also it'd be nice if the hello callback could change the priority :)
> 



From nmav at gnutls.org  Sat Aug  3 19:52:58 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 03 Aug 2013 19:52:58 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <20130802162021.556b6ce6@chromobil.localdomain>
References: <20130802005326.46a4eb9a@chromobil.localdomain>
 <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
 <20130802152129.25c9a937@chromobil.localdomain>
 <20130802162021.556b6ce6@chromobil.localdomain>
Message-ID: <51FD437A.5090806@gnutls.org>

On 08/02/2013 04:20 PM, Stefan B?hler wrote:
> Hi,
> 
> I think I found the problem:
> 
> _gnutls_epoch_set_cipher_suite fails, because my normal priority string
> has RC4 disabled; the hello_cb is supposed to enable RC4 for TLS1.0
> 
> Although the callback gets called (and sees the correct version and
> sets the RC4 priority), _gnutls_epoch_set_cipher_suite still doesn't
> accept the RC4 cipher from the ticket state.
> The return value of _gnutls_epoch_set_cipher_suite isn't checked by any
> of the calling functions... this should probably be fixed (same for
> _gnutls_epoch_set_compression and so on).
> Also it'd be nice if the hello callback could change the priority :)

Ah, ok I understand what you're trying to do. I don't think it's worth
the effort though. Both RC4 and AES-CBC are severely broken in so many
ways it doesn't make sense to try to mitigate the issues (a more
advanced ciphersuite selection process would have been nicer though).

Using the "normal" priority string and adding the server precedence
option would help as the best possible option will be used depending on
the client.

regards,
Nikos



From stbuehler at lighttpd.net  Sun Aug  4 11:07:58 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Sun, 4 Aug 2013 11:07:58 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <51FD437A.5090806@gnutls.org>
References: <20130802005326.46a4eb9a@chromobil.localdomain>
 <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
 <20130802152129.25c9a937@chromobil.localdomain>
 <20130802162021.556b6ce6@chromobil.localdomain>
 <51FD437A.5090806@gnutls.org>
Message-ID: <20130804110758.5c332447@chromobil.localdomain>

On Sat, 03 Aug 2013 19:52:58 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 08/02/2013 04:20 PM, Stefan B?hler wrote:
> > Hi,
> > 
> > I think I found the problem:
> > 
> > _gnutls_epoch_set_cipher_suite fails, because my normal priority
> > string has RC4 disabled; the hello_cb is supposed to enable RC4 for
> > TLS1.0
> > 
> > Although the callback gets called (and sees the correct version and
> > sets the RC4 priority), _gnutls_epoch_set_cipher_suite still doesn't
> > accept the RC4 cipher from the ticket state.
> > The return value of _gnutls_epoch_set_cipher_suite isn't checked by
> > any of the calling functions... this should probably be fixed (same
> > for _gnutls_epoch_set_compression and so on).

Looks like you fixed that part, thx :)

> > Also it'd be nice if the hello callback could change the priority :)
> 
> Ah, ok I understand what you're trying to do. I don't think it's worth
> the effort though. Both RC4 and AES-CBC are severely broken in so many
> ways it doesn't make sense to try to mitigate the issues (a more
> advanced ciphersuite selection process would have been nicer though).
> 
> Using the "normal" priority string and adding the server precedence
> option would help as the best possible option will be used depending
> on the client.

Afaik AES-CBC is ok to use with TLS1.1+ and better than RC4, but for
TLS1.0 and before you really want RC4. server preference can't fix this.
And afaics in my ssllabs analysis no client supports AES-GCM yet, so I
really need AES-CBC.

But even without that usecase I still think it'd be nice to support
different priority settings from the hello callback; for example I
could allow less secure ciphers for some SNI names, and require better
ciphers for others.

I'm not sure why you check in the epoch setters whether the cipher and
the mac are present in the priority; if a session gets resumed the
values were good not long ago, and otherwise you selected good values
right before.
Or perhaps the check could be delayed until the hello callback is done?


Whatever your decision is, it would be nice if it would be documented
and perhaps even be enforced; if you don't want the priority changed in
the hello callback, then it probably should fail somehow, instead of
setting up sesions that can't be resumed (or trigger segfaults :D).

regards,
Stefan


From fw at deneb.enyo.de  Sun Aug  4 11:17:48 2013
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 04 Aug 2013 11:17:48 +0200
Subject: [gnutls-devel] gnutls 3.2.3 segfault in _gnutls_epoch_set_keys
In-Reply-To: <20130804110758.5c332447@chromobil.localdomain> ("Stefan
 =?iso-8859-1?Q?B=FChler=22's?= message of "Sun, 4 Aug 2013 11:07:58 +0200")
References: <20130802005326.46a4eb9a@chromobil.localdomain>
 <CAJU7zaL0BpCvxqeS3k2kHHE=hCsVvR9J0cePWThCJdCQC3oO_w@mail.gmail.com>
 <20130802152129.25c9a937@chromobil.localdomain>
 <20130802162021.556b6ce6@chromobil.localdomain>
 <51FD437A.5090806@gnutls.org>
 <20130804110758.5c332447@chromobil.localdomain>
Message-ID: <878v0h6chv.fsf@mid.deneb.enyo.de>

* Stefan B?hler:

> Afaik AES-CBC is ok to use with TLS1.1+ and better than RC4, but for
> TLS1.0 and before you really want RC4.

Not really.  Only relatively few applications are vulnerable to
adaptive chosen-plaintext attacks (and these attacks are anything but
stealthy), but all suffer from RC4 weaknesses which enable passive
attacks.


From kmac at poczta.fm  Sun Aug 11 19:02:59 2013
From: kmac at poczta.fm (Mac)
Date: Sun, 11 Aug 2013 19:02:59 +0200
Subject: [gnutls-devel] mcabber GnuTLS related problem
Message-ID: <hgjbnblziwhljhzovwxj@luvu>

Hello,

after upgrade from GnuTLS 3.2.1 to 3.2.3 I'm unable to connect up to my jabber account with use of mcabber 0.10.2, the error:

** (process:8630): WARNING **: Parsing failed: Error on line 1 char 797: 'xth'' is not a valid name: '''

after downgrade to GnuTLS 3.2.1 it works properly.

My system is:
Linux konkurs 3.6.11-14-ARCH+ #1 PREEMPT Sun Jul 21 17:39:58 CDT 2013 armv6l GNU/Linux

I've contacted with mcabber developer and he told me that its because of GnuTLS.

greetings



From jonny.tornbom at axis.com  Mon Aug 12 16:05:38 2013
From: jonny.tornbom at axis.com (Jonny =?iso-8859-1?Q?T=F6rnbom?=)
Date: Mon, 12 Aug 2013 16:05:38 +0200
Subject: [gnutls-devel] gnutls 3.2.3-1 breaks irssi/xmpp
Message-ID: <20130812140538.GA1549@lnxjonnyt.se.axis.com>

Hi,

Using gnutls 3.2.3-1 (Arch linux release) breaks irssi/xmpp combo for
me. When trying to connect to a jabber server with latest stable irssi
and xmpp plugin (http://cybione.org/~irssi-xmpp/) I'm getting parsing
failures about TLS. I'm connecting to the server and is prompted to put
in my password, when I do that and hit enter, thats when the parsing
failure occurs and connection doesn't fully establish.

When downgrading gnutls to 3.2.1 it works perfectly fine.

Br,
Jonny


From nmav at gnutls.org  Mon Aug 12 19:13:33 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 12 Aug 2013 19:13:33 +0200
Subject: [gnutls-devel] gnutls 3.2.3-1 breaks irssi/xmpp
In-Reply-To: <20130812140538.GA1549@lnxjonnyt.se.axis.com>
References: <20130812140538.GA1549@lnxjonnyt.se.axis.com>
Message-ID: <CAJU7zaLw2Md0g_jUH9cHR+EzXCfbWHoRvH1N44ZkNBUsuiF9yQ@mail.gmail.com>

On Mon, Aug 12, 2013 at 4:05 PM, Jonny T?rnbom <jonny.tornbom at axis.com> wrote:
> Hi,
> Using gnutls 3.2.3-1 (Arch linux release) breaks irssi/xmpp combo for
> me. When trying to connect to a jabber server with latest stable irssi
> and xmpp plugin (http://cybione.org/~irssi-xmpp/) I'm getting parsing
> failures about TLS. I'm connecting to the server and is prompted to put
> in my password, when I do that and hit enter, thats when the parsing
> failure occurs and connection doesn't fully establish.
> When downgrading gnutls to 3.2.1 it works perfectly fine.

Hello,
 Thank you for reporting that. Is there a way to reproduce that using
gnutls-cli to obtain any debugging information?

regards,
Nikos


From nmav at gnutls.org  Mon Aug 12 19:15:11 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 12 Aug 2013 19:15:11 +0200
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <hgjbnblziwhljhzovwxj@luvu>
References: <hgjbnblziwhljhzovwxj@luvu>
Message-ID: <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>

On Sun, Aug 11, 2013 at 7:02 PM, Mac <kmac at poczta.fm> wrote:
> Hello,
>
> after upgrade from GnuTLS 3.2.1 to 3.2.3 I'm unable to connect up to my jabber account with use of mcabber 0.10.2, the error:
> ** (process:8630): WARNING **: Parsing failed: Error on line 1 char 797: 'xth'' is not a valid name: '''
> after downgrade to GnuTLS 3.2.1 it works properly.

Hello,
 Thank you for reporting that, but it seems that the error you quote
isn't related to gnutls so it is difficult to help. Is there a way to
reproduce that error using gnutls-cli to obtain any debugging
information (or ask the developer of your program how to obtain gnutls
debugging info)?

regards,
Nikos


From psvaiter at gmail.com  Mon Aug 12 19:49:18 2013
From: psvaiter at gmail.com (Patrick Svaiter)
Date: Mon, 12 Aug 2013 14:49:18 -0300
Subject: [gnutls-devel] gnutls 3.2.3 test-select fail
Message-ID: <CAAJyq02iegQTDHk6zfy_uE26x7FxaReOzTZbYTRwkCOwTtn7Gw@mail.gmail.com>

I've just built gnutls from the sources, with the options --disable-guile
and --disable-doc, using mingw32.
Configure and make steps seemed go well, but make check failed in
test-select.
Follow the log as suggested after the summary.

===========================================
   GnuTLS 3.2.3: gl/tests/test-suite.log
===========================================

# TOTAL: 131
# PASS:  124
# SKIP:  6
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: test-float
================


SKIP: test-lstat
================

skipping test: symlinks not supported on this file system

SKIP: test-open
===============

skipping test: symlinks not supported on this file system

FAIL: test-select
=================

Invalid nfd test... failed (invalid errno after negative nfds)
Invalid fd test... passed
Unconnected socket test... passed
Connected sockets test... passed
General socket test with fork... passed
Pipe test... passed

SKIP: test-stat
===============

skipping test: symlinks not supported on this file system

SKIP: test-symlink
==================

skipping test: symlinks not supported on this file system

SKIP: test-vc-list-files-git.sh
===============================

test-vc-list-files-git.sh: skipped test: git not found in PATH



Patrick Svaiter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130812/c9f28682/attachment.html>

From falkenauge_mihawk at gmx.ch  Mon Aug 12 23:16:38 2013
From: falkenauge_mihawk at gmx.ch (Falki ^_^)
Date: Mon, 12 Aug 2013 23:16:38 +0200
Subject: [gnutls-devel] GnuTLS and NPN
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAOj9dRqt6N9DtiIYLZyse07CgAAAEAAAAAE3aGegPqNAnirDP03nK1IBAAAAAA==@gmx.ch>

Hello,

 

I'm asking, how the NPN externsion is doing. I wan't to use SPDY, but I
can't because one of the Google Project member said, GnuTLS doesn't have the
npn extension.

 

https://code.google.com/p/mod-spdy/issues/detail?id=37

 

When will you add the npn extension to GnuTLS?

 

Regards

FalkenaugeMihawk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130812/0e709e53/attachment.html>

From nmav at gnutls.org  Tue Aug 13 15:45:59 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Aug 2013 16:45:59 +0300
Subject: [gnutls-devel] GnuTLS and NPN
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAOj9dRqt6N9DtiIYLZyse07CgAAAEAAAAAE3aGegPqNAnirDP03nK1IBAAAAAA==@gmx.ch>
References: <!&!AAAAAAAAAAAYAAAAAAAAAOj9dRqt6N9DtiIYLZyse07CgAAAEAAAAAE3aGegPqNAnirDP03nK1IBAAAAAA==@gmx.ch>
Message-ID: <CAJU7zaKTyykZHAzPK0gFAb3D7DRGSgPEnn4C7LuUv3X6uWc1vQ@mail.gmail.com>

On Tue, Aug 13, 2013 at 12:16 AM, Falki ^_^ <falkenauge_mihawk at gmx.ch> wrote:
> Hello,
> I?m asking, how the NPN externsion is doing. I wan?t to use SPDY, but I
> can?t because one of the Google Project member said, GnuTLS doesn?t have the
> npn extension.
> https://code.google.com/p/mod-spdy/issues/detail?id=37
> When will you add the npn extension to GnuTLS?

Hello,
 The NPN extension is a private google extension which we don't plan
to support. The IETF protocol for negotiating high-level protocols
over TLS is ALPN [0] which we already support.

[0]. http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-01

regards,
Nikos


From nmav at gnutls.org  Tue Aug 13 15:47:52 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Aug 2013 16:47:52 +0300
Subject: [gnutls-devel] gnutls 3.2.3 test-select fail
In-Reply-To: <CAAJyq02iegQTDHk6zfy_uE26x7FxaReOzTZbYTRwkCOwTtn7Gw@mail.gmail.com>
References: <CAAJyq02iegQTDHk6zfy_uE26x7FxaReOzTZbYTRwkCOwTtn7Gw@mail.gmail.com>
Message-ID: <CAJU7za+MsW_9EZHZ7-+MmPw-nwZY4kAND5k96MjB_NQcMw5O6A@mail.gmail.com>

Hello,
 This is a failure on gnulib. Most probably you can ignore that and
just try make check in the tests/ directory which is the main gnutls
tests. However, I have tested gnutls on windows using mingw64-32 and
had no issues.

regards,
Nikos

On Mon, Aug 12, 2013 at 8:49 PM, Patrick Svaiter <psvaiter at gmail.com> wrote:
> I've just built gnutls from the sources, with the options --disable-guile
> and --disable-doc, using mingw32.
> Configure and make steps seemed go well, but make check failed in
> test-select.
> Follow the log as suggested after the summary.
>
> ===========================================
>    GnuTLS 3.2.3: gl/tests/test-suite.log
> ===========================================
>
> # TOTAL: 131
> # PASS:  124
> # SKIP:  6
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> SKIP: test-float
> ================
>
>
> SKIP: test-lstat
> ================
>
> skipping test: symlinks not supported on this file system
>
> SKIP: test-open
> ===============
>
> skipping test: symlinks not supported on this file system
>
> FAIL: test-select
> =================
>
> Invalid nfd test... failed (invalid errno after negative nfds)
> Invalid fd test... passed
> Unconnected socket test... passed
> Connected sockets test... passed
> General socket test with fork... passed
> Pipe test... passed
>
> SKIP: test-stat
> ===============
>
> skipping test: symlinks not supported on this file system
>
> SKIP: test-symlink
> ==================
>
> skipping test: symlinks not supported on this file system
>
> SKIP: test-vc-list-files-git.sh
> ===============================
>
> test-vc-list-files-git.sh: skipped test: git not found in PATH
>
>
>
> Patrick Svaiter
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel


From stbuehler at lighttpd.net  Sun Aug 18 19:47:04 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Sun, 18 Aug 2013 19:47:04 +0200
Subject: [gnutls-devel] session resumption broken when tickets and db is
	enabled
Message-ID: <20130818194704.1a30f32a@chromobil.localdomain>

Hi again :)

lighttpd2/mod_gnutls supports session db and tickets by default; a
nginx proxy had problems connecting:

  SSL_do_handshake() failed (SSL: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac) while SSL handshaking to upstream

The first two requests were fine, the 3rd and later failed.
Debugging wasn't easy, because...

Bug 1:
  gnutls-serv doesn't support tickets, although there is a parameter
  "--noticket". Please remove the stupid #ifdef magic ...

Now:
    gnutls-serv --http -p 5556 --x509keyfile=server.pem --x509certfile=server.pem

    echo | openssl s_client -connect 127.0.0.1:5556 -sess_out tmp.session
    echo | openssl s_client -connect 127.0.0.1:5556 -sess_in tmp.session
    echo | openssl s_client -connect 127.0.0.1:5556 -sess_in tmp.session
    [...]
    140720615724712:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:484:
    (Also now gnutls-serv is burning my cpu)

That shows something is broken. When --nodb or --noticket is added to gnutls-serv, everything is fine.

Testing with gnutls client requires patching again. I patched doc/examples/ex-client-resume.c
to connect 3 times and delete the session data at the end (see below).

    cd doc/examples
    gcc ex-alert.c tcp.c ex-client-resume.c -lgnutls -o client-resume
    ./client-resume
    [...]
    *** Handshake failed
    GnuTLS error: An unexpected TLS packet was received.

Same as with the openssl client; broken with ticket and db, works if one is disabled.

The problem probably is in lib/gnutls_handshake.c:3193 - in the 2nd request there
is no new ticket sent, but the ticket is still used, and it will store the session
in the db (Bug 2).
Then, in the 3rd request and later, in lib/gnutls_handshake.c:516 it first tries to
restore the session from db, before knowing whether a ticket is present (if a ticket is
present this call is "wasted" and also the data shouldn't be used -> Bug 3).

regards,
Stefan

---
diff --git a/doc/examples/ex-client-resume.c b/doc/examples/ex-client-resume.c
index 1842c5e..f0d60df 100644
--- a/doc/examples/ex-client-resume.c
+++ b/doc/examples/ex-client-resume.c
@@ -41,7 +41,7 @@ main (void)
 
   gnutls_certificate_set_x509_trust_file (xcred, CAFILE, GNUTLS_X509_FMT_PEM);
 
-  for (t = 0; t < 2; t++)
+  for (t = 0; t < 3; t++)
     {                           /* connect 2 times to the server */
 
       sd = tcp_connect ();
@@ -56,7 +56,6 @@ main (void)
         {
           /* if this is not the first time we connect */
           gnutls_session_set_data (session, session_data, session_data_size);
-          free (session_data);
         }
 
       gnutls_transport_set_int (session, sd);
@@ -147,6 +146,8 @@ main (void)
 
     }                           /* for() */
 
+  if (NULL != session_data) free (session_data);
+
   gnutls_certificate_free_credentials (xcred);
 
   gnutls_global_deinit ();
---


From stbuehler at lighttpd.net  Sun Aug 18 22:32:37 2013
From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=)
Date: Sun, 18 Aug 2013 22:32:37 +0200
Subject: [gnutls-devel] some patches
Message-ID: <20130818223237.24208c0a@chromobil.localdomain>

Hi,

0001-fix-transport-parameter-casts-in-tests.patch
  gcc gave a lot of warnings for converting int to pointer with
  different size. converted to use gnutls_transport_set_int where
  possible, or cast through (long) instead (as gnutls_transport_set_int
  does internally).

0002-add-some-RC4-128-SHA1-ciphersuites-based-on-ECDH-E-k.patch
  Given that some people like to use RC4 with https right now, it would
  be nice to support the ECDH(E) RC4 cipher suites to achieve Forward
  Secrecy.
  I don't know why they are missing, openssl s_client worked fine in a
  simple test, showing ECDHE-RSA-RC4-SHA as cipher.
  I assume the others are working too :)

0003-don-t-store-session-if-a-ticket-is-used.patch
  This should fix the earlier reported bug with ticket/db; it doesn't
  store the session if a ticket is in use.
  Doesn't fix the unnecessary (and broken) session lookup when a ticket
  was sent.

regards,
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fix-transport-parameter-casts-in-tests.patch
Type: text/x-patch
Size: 40722 bytes
Desc: not available
URL: </pipermail/attachments/20130818/c9725f4e/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-add-some-RC4-128-SHA1-ciphersuites-based-on-ECDH-E-k.patch
Type: text/x-patch
Size: 4727 bytes
Desc: not available
URL: </pipermail/attachments/20130818/c9725f4e/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-don-t-store-session-if-a-ticket-is-used.patch
Type: text/x-patch
Size: 2550 bytes
Desc: not available
URL: </pipermail/attachments/20130818/c9725f4e/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: </pipermail/attachments/20130818/c9725f4e/attachment-0001.sig>

From thomas at thwitt.de  Sun Aug 18 23:08:26 2013
From: thomas at thwitt.de (Thomas Witt)
Date: Sun, 18 Aug 2013 23:08:26 +0200
Subject: [gnutls-devel] gnutls-3.2.3: Test failure in cert-tests,
	complex-cert
Message-ID: <521137CA.8070900@thwitt.de>

If you have different src and build directories, the complex-cert tests 
fails due to a bug in tests/cert-tests/pem-decoding:

tmp-pem.pem is obviously created in the builddir, so the test cannot 
find it in $srcdir

Greetings, Thomas

--- pem-decoding.orig	2013-08-18 23:06:16.812555680 +0200
+++ pem-decoding	2013-08-18 23:06:35.525554400 +0200
@@ -62,7 +62,7 @@
  fi

  cat $srcdir/complex-cert.pem |grep -v "Not After:" >tmp1
-cat $srcdir/tmp-pem.pem |grep -v "Not After:" >tmp2
+cat tmp-pem.pem |grep -v "Not After:" >tmp2
  diff --strip-trailing-cr tmp1 tmp2
  rc=$?


From richard at frithmacdonald.me.uk  Mon Aug 19 15:19:37 2013
From: richard at frithmacdonald.me.uk (Richard Frith-Macdonald)
Date: Mon, 19 Aug 2013 14:19:37 +0100
Subject: [gnutls-devel] gnutls-3.2.2 memory leak in handshake
Message-ID: <0FDC4412-97CD-4F76-B8CF-3A9A9A0A660A@frithmacdonald.me.uk>

I have a server process using gnutls, and it's leaking substantial amounts of memory when sitting idle.
It  is receiving incoming HTTP connections from an OpenNMS system monitoring the port it's listening on, by establishing a connection to the port at fairly frequent intervals.
Running under valgrind reports as follows;

=10642== 24,341,716 bytes in 1,481 blocks are definitely lost in loss record 4,805 of 4,805
==10642==    at 0x4005B83: malloc (vg_replace_malloc.c:195)
==10642==    by 0x4F18D5A: _mbuffer_alloc (gnutls_mbuffers.c:287)
==10642==    by 0x4F19908: _gnutls_io_read_buffered (gnutls_buffers.c:272)
==10642==    by 0x4F14310: _gnutls_recv_in_buffers (gnutls_record.c:1038)
==10642==    by 0x4F1B92A: _gnutls_handshake_io_recv_int (gnutls_buffers.c:1223)
==10642==    by 0x4F1E963: _gnutls_recv_handshake (gnutls_handshake.c:1383)
==10642==    by 0x4F221FE: gnutls_handshake (gnutls_handshake.c:3046)
==10642==    by 0x4551F79: _i_GSTLSSession__handshake (GSTLS.m:1462)
==10642==    by 0x45D4039: _i_GSTLSHandle__sslHandshakeEstablished_outgoing_ (NSFileHandle.m:1026)
==10642==    by 0x41887B0: _i_WebServerConnection___timeout_ (WebServerConnection.m:1805)
==10642==    by 0x462838C: _i_NSObject__performSelector_withObject_ (NSObject.m:2029)
==10642==    by 0x469B047: _i_NSTimer(float, int, long double,...) (NSTimer.m:258)
==10642==    by 0x4667BF5: _i_NSRunLoop__limitDateForMode_ (NSRunLoop.m:1016)
==10642==    by 0x4031CDA: _i_EcProcess__ecRun (EcProcess.m:2137)
==10642==    by 0x804A647: main (main.m:54)
==10642== 


I think the issue is that gnutls_handshake() tries to read and immediately gets EOF, and in this case the memory allocated to buffer the input is leaked.

If you change _gnutls_io_read_buffered() in gnutls_buffers.c to free the buffer on EOF this should fix this case (though there may be other similar problems elsewhere, so perhaps a different fix, eg in _gnutls_read(), would make more sense).

      if (ret == 0) /* EOF */
        {
          _mbuffer_xfree (&bufel);
          return gnutls_assert_val(0);
        }



From ametzler at downhill.at.eu.org  Sat Aug 24 16:28:42 2013
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 24 Aug 2013 16:28:42 +0200
Subject: [gnutls-devel] [Patch] Clean up after test
Message-ID: <20130824142842.GA6015@downhill.g.la>

Hello,

tests/sha2/sha2 leaves a file named "out" after running, delete it.

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 --------------
A non-text attachment was scrubbed...
Name: 0001-Clean-up-after-test.patch
Type: text/x-diff
Size: 669 bytes
Desc: not available
URL: </pipermail/attachments/20130824/144292c0/attachment.patch>

From nmav at gnutls.org  Sat Aug 24 22:33:35 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Aug 2013 23:33:35 +0300
Subject: [gnutls-devel] gnutls-3.2.2 memory leak in handshake
In-Reply-To: <0FDC4412-97CD-4F76-B8CF-3A9A9A0A660A@frithmacdonald.me.uk>
References: <0FDC4412-97CD-4F76-B8CF-3A9A9A0A660A@frithmacdonald.me.uk>
Message-ID: <CAJU7za+gs4zMqxTRMty3TkgecGcs47MTOaYOkCag5MSFKCxeKw@mail.gmail.com>

On Mon, Aug 19, 2013 at 4:19 PM, Richard Frith-Macdonald <
richard at frithmacdonald.me.uk> wrote:

> I have a server process using gnutls, and it's leaking substantial amounts
> of memory when sitting idle.
> It  is receiving incoming HTTP connections from an OpenNMS system
> monitoring the port it's listening on, by establishing a connection to the
> port at fairly frequent intervals.
> Running under valgrind reports as follows;
> =10642== 24,341,716 bytes in 1,481 blocks are definitely lost in loss
> record 4,805 of 4,805
> ==10642==    at 0x4005B83: malloc (vg_replace_malloc.c:195)
> ==10642==    by 0x4F18D5A: _mbuffer_alloc (gnutls_mbuffers.c:287)
> ==10642==    by 0x4F19908: _gnutls_io_read_buffered (gnutls_buffers.c:272)
> ==10642==    by 0x4F14310: _gnutls_recv_in_buffers (gnutls_record.c:1038)
> ==10642==    by 0x4F1B92A: _gnutls_handshake_io_recv_int
> (gnutls_buffers.c:1223)
> ==10642==    by 0x4F1E963: _gnutls_recv_handshake (gnutls_handshake.c:1383)
> ==10642==    by 0x4F221FE: gnutls_handshake (gnutls_handshake.c:3046)
> ==10642==    by 0x4551F79: _i_GSTLSSession__handshake (GSTLS.m:1462)
> ==10642==    by 0x45D4039:
> _i_GSTLSHandle__sslHandshakeEstablished_outgoing_ (NSFileHandle.m:1026)
> ==10642==    by 0x41887B0: _i_WebServerConnection___timeout_
> (WebServerConnection.m:1805)
> ==10642==    by 0x462838C: _i_NSObject__performSelector_withObject_
> (NSObject.m:2029)
> ==10642==    by 0x469B047: _i_NSTimer(float, int, long double,...)
> (NSTimer.m:258)
> ==10642==    by 0x4667BF5: _i_NSRunLoop__limitDateForMode_
> (NSRunLoop.m:1016)
> ==10642==    by 0x4031CDA: _i_EcProcess__ecRun (EcProcess.m:2137)
> ==10642==    by 0x804A647: main (main.m:54)
> ==10642==
> I think the issue is that gnutls_handshake() tries to read and immediately
> gets EOF, and in this case the memory allocated to buffer the input is
> leaked.
>

Hello,
 Could that be the same as the issue fixed in:
https://www.gitorious.org/gnutls/gnutls/commit/9c66a020d7e424c19bb4eb1ba33d9603a0f03f45

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130824/7e5bf761/attachment.html>

From nmav at gnutls.org  Sun Aug 25 00:19:05 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Aug 2013 01:19:05 +0300
Subject: [gnutls-devel] gnutls-3.2.3: Test failure in cert-tests,
	complex-cert
In-Reply-To: <521137CA.8070900@thwitt.de>
References: <521137CA.8070900@thwitt.de>
Message-ID: <CAJU7zaJ2pX5QY3R8Twmw3cPfo8vxknJoigMB6yVvy3xbVAb=xQ@mail.gmail.com>

On Mon, Aug 19, 2013 at 12:08 AM, Thomas Witt <thomas at thwitt.de> wrote:

> If you have different src and build directories, the complex-cert tests
> fails due to a bug in tests/cert-tests/pem-decoding:
> tmp-pem.pem is obviously created in the builddir, so the test cannot find
> it in $srcdir
>



Thank you. Corrected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130825/34dc9139/attachment.html>

From nmav at gnutls.org  Sun Aug 25 00:20:24 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Aug 2013 01:20:24 +0300
Subject: [gnutls-devel] [Patch] Clean up after test
In-Reply-To: <20130824142842.GA6015@downhill.g.la>
References: <20130824142842.GA6015@downhill.g.la>
Message-ID: <CAJU7za+MPyN2Xbj7Utj3rwoLm3Mx_WOv2TU=4aG6vUgOPcVTiA@mail.gmail.com>

On Sat, Aug 24, 2013 at 5:28 PM, Andreas Metzler <
ametzler at downhill.at.eu.org> wrote:

> Hello,
>
> tests/sha2/sha2 leaves a file named "out" after running, delete it.
>

Applied, thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130825/6ad7d518/attachment.html>

From nmav at gnutls.org  Sun Aug 25 11:21:08 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Aug 2013 12:21:08 +0300
Subject: [gnutls-devel] session resumption broken when tickets and db is
 enabled
In-Reply-To: <20130818194704.1a30f32a@chromobil.localdomain>
References: <20130818194704.1a30f32a@chromobil.localdomain>
Message-ID: <20130825122108.3e09039c@aspire.lan>

On Sun, 18 Aug 2013 19:47:04 +0200
Stefan B?hler <stbuehler at lighttpd.net> wrote:

> Hi again :)
> 
> lighttpd2/mod_gnutls supports session db and tickets by default; a
> nginx proxy had problems connecting:
> 
>   SSL_do_handshake() failed (SSL: error:1408F119:SSL
> routines:SSL3_GET_RECORD:decryption failed or bad record mac) while
> SSL handshaking to upstream
> 
> The first two requests were fine, the 3rd and later failed.
> Debugging wasn't easy, because...
> Bug 1:
>   gnutls-serv doesn't support tickets, although there is a parameter
>   "--noticket". Please remove the stupid #ifdef magic ...

Done.

>     echo | openssl s_client -connect 127.0.0.1:5556 -sess_out
> tmp.session echo | openssl s_client -connect 127.0.0.1:5556 -sess_in
> tmp.session echo | openssl s_client -connect 127.0.0.1:5556 -sess_in
> tmp.session [...]
>     140720615724712:error:1408F119:SSL
> routines:SSL3_GET_RECORD:decryption failed or bad record
> mac:s3_pkt.c:484: (Also now gnutls-serv is burning my cpu)
> That shows something is broken. When --nodb or --noticket is added to
> gnutls-serv, everything is fine.

Thank you. I've solved it a bit differently than your patch but the
result should be the same.

regards,
Nikos


From nmav at gnutls.org  Sun Aug 25 14:48:54 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Aug 2013 15:48:54 +0300
Subject: [gnutls-devel] some patches
In-Reply-To: <20130818223237.24208c0a@chromobil.localdomain>
References: <20130818223237.24208c0a@chromobil.localdomain>
Message-ID: <CAJU7zaKk9hHku0iBkq5zrh8QdxwOBKv7ucHZyLtM9CXyMrA0YQ@mail.gmail.com>

On Sun, Aug 18, 2013 at 11:32 PM, Stefan B?hler <stbuehler at lighttpd.net>wrote:

> Hi,
>
> 0001-fix-transport-parameter-casts-in-tests.patch
>   gcc gave a lot of warnings for converting int to pointer with
>   different size. converted to use gnutls_transport_set_int where
>   possible, or cast through (long) instead (as gnutls_transport_set_int
>   does internally).
>
> 0002-add-some-RC4-128-SHA1-ciphersuites-based-on-ECDH-E-k.patch
>   Given that some people like to use RC4 with https right now, it would
>   be nice to support the ECDH(E) RC4 cipher suites to achieve Forward
>   Secrecy.
>   I don't know why they are missing, openssl s_client worked fine in a
>   simple test, showing ECDHE-RSA-RC4-SHA as cipher.
>   I assume the others are working too :)
>

Applied, thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130825/b39a2403/attachment.html>

From petr.pisar at atlas.cz  Wed Aug 28 22:18:29 2013
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Wed, 28 Aug 2013 22:18:29 +0200
Subject: [gnutls-devel] Regression in gnutls-3.2.2: server accepts clients
 without a certificate
Message-ID: <20130828201829.GC3778@album.bayer.uni.cx>

Hello,

I've found a regression between 3.2.1 and 3.2.2. `gnutls-serv -r' used to
refuse TLS clients without a valid certificate, this is not true in GnuTLS
3.2.2 anymore.

I tried to find the faulty commit in git tree, but server compiled from the
git tag gnutls_3_2_1 behaves differently then the one from 3.2.1 tar ball.

I observe the regression with my application that uses GnuTLS library too.

petr at album:~/gnutls-3.2.1/src $ ./gnutls-serv --http --x509cafile ~/projekty/libisds/libisds-devel/server/tls/ca.cert --x509keyfile ~/projekty/libisds/libisds-devel/server/tls/server.key --x509certfile ~/projekty/libisds/libisds-devel/server/tls/server.cert -p 1443 -r
Set static Diffie-Hellman parameters, consider --dhparams.
Processed 1 CA certificate(s).
HTTP Server listening on IPv4 0.0.0.0 port 1443...done
HTTP Server listening on IPv6 :: port 1443...done

* Accepted connection from IPv4 127.0.0.1 port 38986 on Wed Aug 28 22:10:50 2013
Error in handshake
Error: No certificate was found.


petr at album:~/gnutls-3.2.2/src $ ./gnutls-serv --http --x509cafile ~/projekty/libisds/libisds-devel/server/tls/ca.cert --x509keyfile ~/projekty/libisds/libisds-devel/server/tls/server.key --x509certfile ~/projekty/libisds/libisds-devel/server/tls/server.cert -p 1443 -r
Set static Diffie-Hellman parameters, consider --dhparams.
Processed 1 CA certificate(s).
HTTP Server listening on IPv4 0.0.0.0 port 1443...done
HTTP Server listening on IPv6 :: port 1443...done

* Accepted connection from IPv4 127.0.0.1 port 38997 on Wed Aug 28 22:11:58 2013

* Successful handshake from IPv4 127.0.0.1 port 38997
- Description: (TLS1.2-PKIX)-(ECDHE-RSA-SECP521R1)-(AES-256-GCM)-(AEAD)
- Session ID: D6:31:F4:FF:98:48:81:E5:4D:E7:F3:5B:8C:84:59:90:A5:9A:0E:49:B7:F7:3B:C6:A8:EE:40:45:A9:56:E0:82
No certificates found!
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP521R1
 - Curve size: 528 bits
- Version: TLS1.2
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-SHA512
- Cipher: AES-256-GCM
- MAC: AEAD
- Compression: NULL
- Channel binding 'tls-unique': 2cd27becdddd69e754b4686c
- Peer did not send any certificate.


And the connection remains established.

For information, the git tag gnutls_3_2_1 output is:

petr at album:~/gnutls/src $ git describe --long
gnutls_3_2_1-0-g34ce019
petr at album:~/gnutls/src $ ./gnutls-serv --http --x509cafile ~/projekty/libisds/libisds-devel/server/tls/ca.cert --x509keyfile ~/projekty/libisds/libisds-devel/server/tls/server.key --x509certfile ~/projekty/libisds/libisds-devel/server/tls/server.cert -p 1443 -r
Set static Diffie-Hellman parameters, consider --dhparams.
Processed 1 CA certificate(s).
HTTP Server listening on IPv4 0.0.0.0 port 1443...done
HTTP Server listening on IPv6 :: port 1443...done

* Accepted connection from IPv4 127.0.0.1 port 38998 on Wed Aug 28 22:15:01 2013
Error in handshake
Error: Could not negotiate a supported cipher suite.


And the connection gets closed.

I used `openssl s_client -connect localhost:1443' as a TLS client.

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: </pipermail/attachments/20130828/3bf08a59/attachment.sig>

From nmav at gnutls.org  Thu Aug 29 13:24:27 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 29 Aug 2013 14:24:27 +0300
Subject: [gnutls-devel] Regression in gnutls-3.2.2: server accepts
 clients without a certificate
In-Reply-To: <20130828201829.GC3778@album.bayer.uni.cx>
References: <20130828201829.GC3778@album.bayer.uni.cx>
Message-ID: <CAJU7zaLB48GRfJ=mb_71Abt4YL1pT_C0H9aZnhOt4GU67JR-jw@mail.gmail.com>

On Wed, Aug 28, 2013 at 11:18 PM, Petr Pisar <petr.pisar at atlas.cz> wrote:

> Hello,
> I've found a regression between 3.2.1 and 3.2.2. `gnutls-serv -r' used to
> refuse TLS clients without a valid certificate, this is not true in GnuTLS
> 3.2.2 anymore.
>
> I tried to find the faulty commit in git tree, but server compiled from the
> git tag gnutls_3_2_1 behaves differently then the one from 3.2.1 tar ball.
> I observe the regression with my application that uses GnuTLS library too.
>

Thank you for reporting that. I've committed a fix in the repository and
added a test case to avoid this regression from occurring again.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130829/3a7bd218/attachment.html>

From petr.pisar at atlas.cz  Thu Aug 29 15:54:11 2013
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Thu, 29 Aug 2013 15:54:11 +0200
Subject: [gnutls-devel] Regression in gnutls-3.2.2: server accepts
 clients without a certificate
In-Reply-To: <CAJU7zaLB48GRfJ=mb_71Abt4YL1pT_C0H9aZnhOt4GU67JR-jw@mail.gmail.com>
References: <20130828201829.GC3778@album.bayer.uni.cx>
 <CAJU7zaLB48GRfJ=mb_71Abt4YL1pT_C0H9aZnhOt4GU67JR-jw@mail.gmail.com>
Message-ID: <20130829135411.GD3782@album.bayer.uni.cx>

On Thu, Aug 29, 2013 at 02:24:27PM +0300, Nikos Mavrogiannopoulos wrote:
> On Wed, Aug 28, 2013 at 11:18 PM, Petr Pisar <petr.pisar at atlas.cz> wrote:
> 
> > I've found a regression between 3.2.1 and 3.2.2. `gnutls-serv -r' used to
> > refuse TLS clients without a valid certificate, this is not true in GnuTLS
> > 3.2.2 anymore.
> >
> > I tried to find the faulty commit in git tree, but server compiled from the
> > git tag gnutls_3_2_1 behaves differently then the one from 3.2.1 tar ball.
> > I observe the regression with my application that uses GnuTLS library too.
> >
> 
> Thank you for reporting that. I've committed a fix in the repository and
> added a test case to avoid this regression from occurring again.
> 
Thanks for quick fix. I confirm that applying the commit
4aebdbe7d424f2a1705f3751c5fef6f2e5f4e616 to 3.2.3 release fixes the
regression.

BTW, ISO C 99 recognizes `_Bool' type which you could use instead of the
1-bit-long integer bit-fields.

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: </pipermail/attachments/20130829/d5881ed8/attachment.sig>

From niels_ole at salscheider-online.de  Thu Aug 29 20:06:41 2013
From: niels_ole at salscheider-online.de (Niels Ole Salscheider)
Date: Thu, 29 Aug 2013 20:06:41 +0200
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>
References: <hgjbnblziwhljhzovwxj@luvu>
 <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>
Message-ID: <3332389.coFW0obecb@olelaptop>

Hello,

I have a similar problem with telepathy-gabble / wocky. For me, it fails with 
"TLS Negotiated: -12: GNUTLS_E_FATAL_ALERT_RECEIVED" when I try to connect to 
swissjabber.de.

This is with the default priority strings:
"NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP-
NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC:
+RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
and
"NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
(depending on whether you want to prefer stream chiphers or not).

However, when I set the priority string to "NORMAL", it works for me. Is there 
something wrong with the priority strings?

Regards,

Ole


From nmav at gnutls.org  Thu Aug 29 20:47:27 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 29 Aug 2013 21:47:27 +0300
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <3332389.coFW0obecb@olelaptop>
References: <hgjbnblziwhljhzovwxj@luvu>
 <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>
 <3332389.coFW0obecb@olelaptop>
Message-ID: <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>

On Thu, Aug 29, 2013 at 9:06 PM, Niels Ole Salscheider <
niels_ole at salscheider-online.de> wrote:

> Hello,
>
> I have a similar problem with telepathy-gabble / wocky. For me, it fails
> with
> "TLS Negotiated: -12: GNUTLS_E_FATAL_ALERT_RECEIVED" when I try to connect
> to
> swissjabber.de.
>
> This is with the default priority strings:
> "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP-
> NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC:
> +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
>

That is a pretty dangerous priority string. While modern versions of gnutls
would not negotiate DES, RC4-40 or RC2, having them in the priority string
reveals something fishy.


> and
> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> (depending on whether you want to prefer stream chiphers or not).
>

The only difference of the priority string above with NORMAL is that it
prioritizes compression.  It may be that there is some issue with
negotiating compression with this server (do you have any information on
the server?). In general there is no reason to use compression with TLS. It
can only cause harm (including reveal of plaintext).

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130829/f3d82fc0/attachment-0001.html>

From nmav at gnutls.org  Thu Aug 29 20:47:27 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 29 Aug 2013 21:47:27 +0300
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <3332389.coFW0obecb@olelaptop>
References: <hgjbnblziwhljhzovwxj@luvu>
 <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>
 <3332389.coFW0obecb@olelaptop>
Message-ID: <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>

On Thu, Aug 29, 2013 at 9:06 PM, Niels Ole Salscheider <
niels_ole at salscheider-online.de> wrote:

> Hello,
>
> I have a similar problem with telepathy-gabble / wocky. For me, it fails
> with
> "TLS Negotiated: -12: GNUTLS_E_FATAL_ALERT_RECEIVED" when I try to connect
> to
> swissjabber.de.
>
> This is with the default priority strings:
> "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP-
> NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC:
> +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
>

That is a pretty dangerous priority string. While modern versions of gnutls
would not negotiate DES, RC4-40 or RC2, having them in the priority string
reveals something fishy.


> and
> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> (depending on whether you want to prefer stream chiphers or not).
>

The only difference of the priority string above with NORMAL is that it
prioritizes compression.  It may be that there is some issue with
negotiating compression with this server (do you have any information on
the server?). In general there is no reason to use compression with TLS. It
can only cause harm (including reveal of plaintext).

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130829/f3d82fc0/attachment-0002.html>

From niels_ole at salscheider-online.de  Thu Aug 29 20:06:41 2013
From: niels_ole at salscheider-online.de (Niels Ole Salscheider)
Date: Thu, 29 Aug 2013 20:06:41 +0200
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>
References: <hgjbnblziwhljhzovwxj@luvu>
 <CAJU7za+_Hgaf8SaJ3Pq+Uh2H+hG0G3Zi++Aj=btGpSZ5Y=sKbQ@mail.gmail.com>
Message-ID: <3332389.coFW0obecb@olelaptop>

Hello,

I have a similar problem with telepathy-gabble / wocky. For me, it fails with 
"TLS Negotiated: -12: GNUTLS_E_FATAL_ALERT_RECEIVED" when I try to connect to 
swissjabber.de.

This is with the default priority strings:
"NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP-
NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC:
+RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
and
"NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
(depending on whether you want to prefer stream chiphers or not).

However, when I set the priority string to "NORMAL", it works for me. Is there 
something wrong with the priority strings?

Regards,

Ole


From nmav at gnutls.org  Thu Aug 29 21:15:25 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 29 Aug 2013 22:15:25 +0300
Subject: [gnutls-devel] Regression in gnutls-3.2.2: server accepts
 clients without a certificate
In-Reply-To: <20130829135411.GD3782@album.bayer.uni.cx>
References: <20130828201829.GC3778@album.bayer.uni.cx>
 <CAJU7zaLB48GRfJ=mb_71Abt4YL1pT_C0H9aZnhOt4GU67JR-jw@mail.gmail.com>
 <20130829135411.GD3782@album.bayer.uni.cx>
Message-ID: <CAJU7zaLaCECTDpcbu0b3fmichAPPoyz5UCfi3_zH4wN+cpYjRg@mail.gmail.com>

On Thu, Aug 29, 2013 at 4:54 PM, Petr Pisar <petr.pisar at atlas.cz> wrote:


> > Thank you for reporting that. I've committed a fix in the repository and
> > added a test case to avoid this regression from occurring again.
> >
> Thanks for quick fix. I confirm that applying the commit
> 4aebdbe7d424f2a1705f3751c5fef6f2e5f4e616 to 3.2.3 release fixes the
> regression.
>
> BTW, ISO C 99 recognizes `_Bool' type which you could use instead of the
> 1-bit-long integer bit-fields.
>

Would that provide any advantage over unsigned int:1? We use the latter
quite some time now with no reported issues.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130829/8722e8d9/attachment.html>

From niels_ole at salscheider-online.de  Thu Aug 29 21:33:12 2013
From: niels_ole at salscheider-online.de (Niels Ole Salscheider)
Date: Thu, 29 Aug 2013 21:33:12 +0200
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
Message-ID: <2161964.iGtGAuAqzE@oledesktop>

Hello,

> > I have a similar problem with telepathy-gabble / wocky. For me, it fails
> > with
> > "TLS Negotiated: -12: GNUTLS_E_FATAL_ALERT_RECEIVED" when I try to connect
> > to
> > swissjabber.de.
> > 
> > This is with the default priority strings:
> > "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP
> > -
> > NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC
> > :
> > +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
> 
> That is a pretty dangerous priority string. While modern versions of gnutls
> would not negotiate DES, RC4-40 or RC2, having them in the priority string
> reveals something fishy.

I have CC-ed the telepathy mailing list; maybe they want to update the 
priority string...

> > and
> > "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> > (depending on whether you want to prefer stream chiphers or not).
> 
> The only difference of the priority string above with NORMAL is that it
> prioritizes compression.  It may be that there is some issue with
> negotiating compression with this server (do you have any information on
> the server?). In general there is no reason to use compression with TLS. It
> can only cause harm (including reveal of plaintext).

This seems to be the problem. Leaving out "+COMP-DEFLATE" in the first string 
works, too.

Unfortunately, I have no information about the server, except for what is 
available on the homepage and:

<query xmlns="jabber:iq:version">
	<name>ejabberd</name>
	<version>2.1.5</version>
	<os>unix/linux 2.6.32</os>
</query>

Regards,

Ole


From niels_ole at salscheider-online.de  Thu Aug 29 21:33:12 2013
From: niels_ole at salscheider-online.de (Niels Ole Salscheider)
Date: Thu, 29 Aug 2013 21:33:12 +0200
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
Message-ID: <2161964.iGtGAuAqzE@oledesktop>

Hello,

> > I have a similar problem with telepathy-gabble / wocky. For me, it fails
> > with
> > "TLS Negotiated: -12: GNUTLS_E_FATAL_ALERT_RECEIVED" when I try to connect
> > to
> > swissjabber.de.
> > 
> > This is with the default priority strings:
> > "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP
> > -
> > NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC
> > :
> > +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
> 
> That is a pretty dangerous priority string. While modern versions of gnutls
> would not negotiate DES, RC4-40 or RC2, having them in the priority string
> reveals something fishy.

I have CC-ed the telepathy mailing list; maybe they want to update the 
priority string...

> > and
> > "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> > (depending on whether you want to prefer stream chiphers or not).
> 
> The only difference of the priority string above with NORMAL is that it
> prioritizes compression.  It may be that there is some issue with
> negotiating compression with this server (do you have any information on
> the server?). In general there is no reason to use compression with TLS. It
> can only cause harm (including reveal of plaintext).

This seems to be the problem. Leaving out "+COMP-DEFLATE" in the first string 
works, too.

Unfortunately, I have no information about the server, except for what is 
available on the homepage and:

<query xmlns="jabber:iq:version">
	<name>ejabberd</name>
	<version>2.1.5</version>
	<os>unix/linux 2.6.32</os>
</query>

Regards,

Ole


From petr.pisar at atlas.cz  Thu Aug 29 22:19:26 2013
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Thu, 29 Aug 2013 22:19:26 +0200
Subject: [gnutls-devel] Regression in gnutls-3.2.2: server accepts
 clients without a certificate
In-Reply-To: <CAJU7zaLaCECTDpcbu0b3fmichAPPoyz5UCfi3_zH4wN+cpYjRg@mail.gmail.com>
References: <20130828201829.GC3778@album.bayer.uni.cx>
 <CAJU7zaLB48GRfJ=mb_71Abt4YL1pT_C0H9aZnhOt4GU67JR-jw@mail.gmail.com>
 <20130829135411.GD3782@album.bayer.uni.cx>
 <CAJU7zaLaCECTDpcbu0b3fmichAPPoyz5UCfi3_zH4wN+cpYjRg@mail.gmail.com>
Message-ID: <20130829201926.GF3782@album.bayer.uni.cx>

On Thu, Aug 29, 2013 at 10:15:25PM +0300, Nikos Mavrogiannopoulos wrote:
> On Thu, Aug 29, 2013 at 4:54 PM, Petr Pisar <petr.pisar at atlas.cz> wrote:
> >
> > BTW, ISO C 99 recognizes `_Bool' type which you could use instead of the
> > 1-bit-long integer bit-fields.
> >
> 
> Would that provide any advantage over unsigned int:1? We use the latter
> quite some time now with no reported issues.
> 
Not sure. It matches semantically better.

And you get correct coercion too. With

    _Bool value = 2;

the value becomes 1, i.e. true, while

    unsigned int bit:1 = 2;

stores 0, i.e. false, because of wrapping.

Of course problem is storage size. _Bool usually occupies one word due to
performance reasons. You would still have to write

struct {
    _Bool value:1;
    ...
}

to get packed bit-field to spare memory.

On the other hand, integer bit-field allows to preserve API by enlarging the
size if it turns out that the value should be able to represent more than
two different states.

-- Petr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: </pipermail/attachments/20130829/0a02f2e9/attachment.sig>

From dkg at fifthhorseman.net  Fri Aug 30 00:09:44 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 29 Aug 2013 18:09:44 -0400
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <2161964.iGtGAuAqzE@oledesktop>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
 <2161964.iGtGAuAqzE@oledesktop>
Message-ID: <521FC6A8.5060302@fifthhorseman.net>

On 08/29/2013 03:33 PM, Niels Ole Salscheider wrote:
> Unfortunately, I have no information about the server, except for what is 
> available on the homepage and:
> 
> <query xmlns="jabber:iq:version">
> 	<name>ejabberd</name>
> 	<version>2.1.5</version>
> 	<os>unix/linux 2.6.32</os>
> </query>

fwiw, these version numbers correspond to the linux kernel and ejabberd
versions in debian squeeze.  If you can't get more details about how the
system was configured, you could try setting up a new (virtual) machine
running debian squeeze to try to replicate the situation.

	--dkg

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

From dkg at fifthhorseman.net  Fri Aug 30 00:09:44 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 29 Aug 2013 18:09:44 -0400
Subject: [gnutls-devel] mcabber GnuTLS related problem
In-Reply-To: <2161964.iGtGAuAqzE@oledesktop>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
 <2161964.iGtGAuAqzE@oledesktop>
Message-ID: <521FC6A8.5060302@fifthhorseman.net>

On 08/29/2013 03:33 PM, Niels Ole Salscheider wrote:
> Unfortunately, I have no information about the server, except for what is 
> available on the homepage and:
> 
> <query xmlns="jabber:iq:version">
> 	<name>ejabberd</name>
> 	<version>2.1.5</version>
> 	<os>unix/linux 2.6.32</os>
> </query>

fwiw, these version numbers correspond to the linux kernel and ejabberd
versions in debian squeeze.  If you can't get more details about how the
system was configured, you could try setting up a new (virtual) machine
running debian squeeze to try to replicate the situation.

	--dkg

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

From nmav at gnutls.org  Fri Aug 30 15:56:28 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 30 Aug 2013 16:56:28 +0300
Subject: [gnutls-devel] [Telepathy]  mcabber GnuTLS related problem
In-Reply-To: <52209F68.1060201@collabora.co.uk>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
 <2161964.iGtGAuAqzE@oledesktop> <52209F68.1060201@collabora.co.uk>
Message-ID: <CAJU7zaJrOzshjGceZnLWj72nOCSRK1RB+GtJ_5xHZJHEte1Wjg@mail.gmail.com>

On Fri, Aug 30, 2013 at 4:34 PM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:

> On 29/08/13 20:33, Niels Ole Salscheider wrote:
>
>  >>> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> ...
> >> In general there is no reason to use compression with TLS. It
> >> can only cause harm (including reveal of plaintext).
>
> XMPP is a fairly verbose protocol (XML, with namespaces used for
> extensibility). I'm led to believe that XMPP + deflate is much more
> bandwidth-efficient.
>

Hello,
 I understand that. However the length of compressed data may reveal the
plaintext data in certain scenarios, and there is no clear solution to
these issues so far. For that I'd suggest to use the uncompressed protocol
by default and allowing an option for the user to enable TLS compression
(in the case benefits outweigh the risks).

Having said that gnutls offers an new (experimental) API to control padding
and avoid the length of data reveal the plaintext. This is around
gnutls_record_send_range() and the %NEW_PADDING priority string option.


> What priority string would the GNUTLS team recommend for XMPP traffic?
> (If the answer is "don't call gnutls_priority_set_direct() by default at
> all", that'll be a little more code, but we can do that.)
>

gnutls_priority_set_direct() is required so you cannot avoid that. I'd
suggest to use the default "NORMAL" or "NORMAL:%COMPAT" option, and allow
alternatives by user options. The normal priority string will always
contain conservative security options suitable for generic usage (and will
be updated as security threats change).  By using a custom priority string
you take the responsibility of such updates.


> That's not the normal configuration. It's intended to be enabled in
> bandwidth-constrained environments by ./configure
> --enable-prefer-stream-ciphers, documented as "prefer stream ciphers
> over block ciphers to save bandwidth (at the possible expense of
> security". I believe it may have been implemented for OLPC, in which
> they initially deployed clear-text XMPP, then switched on TLS solely for
> the bandwidth-reduction of getting compression as a side-effect (their
> experimental mesh networking didn't cope well with uncompressed XMPP).
>

You may also use the "performance" string if you'd like to increase the
priority of arcfour. However recent gnutls versions also support the
AES-GCM ciphersuites that use the same bandwidth as arcfour-sha1 so normal
may as well do better there.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130830/d04a56e8/attachment.html>

From nmav at gnutls.org  Fri Aug 30 15:56:28 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 30 Aug 2013 16:56:28 +0300
Subject: [gnutls-devel] [Telepathy]  mcabber GnuTLS related problem
In-Reply-To: <52209F68.1060201@collabora.co.uk>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
 <2161964.iGtGAuAqzE@oledesktop> <52209F68.1060201@collabora.co.uk>
Message-ID: <CAJU7zaJrOzshjGceZnLWj72nOCSRK1RB+GtJ_5xHZJHEte1Wjg@mail.gmail.com>

On Fri, Aug 30, 2013 at 4:34 PM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:

> On 29/08/13 20:33, Niels Ole Salscheider wrote:
>
>  >>> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> ...
> >> In general there is no reason to use compression with TLS. It
> >> can only cause harm (including reveal of plaintext).
>
> XMPP is a fairly verbose protocol (XML, with namespaces used for
> extensibility). I'm led to believe that XMPP + deflate is much more
> bandwidth-efficient.
>

Hello,
 I understand that. However the length of compressed data may reveal the
plaintext data in certain scenarios, and there is no clear solution to
these issues so far. For that I'd suggest to use the uncompressed protocol
by default and allowing an option for the user to enable TLS compression
(in the case benefits outweigh the risks).

Having said that gnutls offers an new (experimental) API to control padding
and avoid the length of data reveal the plaintext. This is around
gnutls_record_send_range() and the %NEW_PADDING priority string option.


> What priority string would the GNUTLS team recommend for XMPP traffic?
> (If the answer is "don't call gnutls_priority_set_direct() by default at
> all", that'll be a little more code, but we can do that.)
>

gnutls_priority_set_direct() is required so you cannot avoid that. I'd
suggest to use the default "NORMAL" or "NORMAL:%COMPAT" option, and allow
alternatives by user options. The normal priority string will always
contain conservative security options suitable for generic usage (and will
be updated as security threats change).  By using a custom priority string
you take the responsibility of such updates.


> That's not the normal configuration. It's intended to be enabled in
> bandwidth-constrained environments by ./configure
> --enable-prefer-stream-ciphers, documented as "prefer stream ciphers
> over block ciphers to save bandwidth (at the possible expense of
> security". I believe it may have been implemented for OLPC, in which
> they initially deployed clear-text XMPP, then switched on TLS solely for
> the bandwidth-reduction of getting compression as a side-effect (their
> experimental mesh networking didn't cope well with uncompressed XMPP).
>

You may also use the "performance" string if you'd like to increase the
priority of arcfour. However recent gnutls versions also support the
AES-GCM ciphersuites that use the same bandwidth as arcfour-sha1 so normal
may as well do better there.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130830/d04a56e8/attachment-0001.html>

From morgner at informatik.hu-berlin.de  Fri Aug 30 15:53:14 2013
From: morgner at informatik.hu-berlin.de (Frank Morgner)
Date: Fri, 30 Aug 2013 15:53:14 +0200
Subject: [gnutls-devel] Patch for GnuTLS 2.10.2 - The DCO
In-Reply-To: <20C69A88F591DE4FA9456202570661A402B09AEA@svmail2.aed.dir>
References: <20C69A88F591DE4FA9456202570661A402B09AEA@svmail2.aed.dir>
Message-ID: <20130830135314.GB15992@gruenau1.informatik.hu-berlin.de>

Please find the ported patch for RSA-PSK here:
https://github.com/frankmorgner/gnutls/tree/master

The currently not building branch gnutls_2_10_x should be updated, see
https://github.com/frankmorgner/gnutls/tree/gnutls_2_10_x


By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.


-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc


From simon.mcvittie at collabora.co.uk  Fri Aug 30 15:34:32 2013
From: simon.mcvittie at collabora.co.uk (Simon McVittie)
Date: Fri, 30 Aug 2013 14:34:32 +0100
Subject: [gnutls-devel] [Telepathy]  mcabber GnuTLS related problem
In-Reply-To: <2161964.iGtGAuAqzE@oledesktop>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
 <2161964.iGtGAuAqzE@oledesktop>
Message-ID: <52209F68.1060201@collabora.co.uk>

On 29/08/13 20:33, Niels Ole Salscheider wrote:
>>> This is with the default priority strings:

For testing/debugging, you can set WOCKY_GNUTLS_OPTIONS="NORMAL" (or
whatever) in telepathy-gabble's environment to override these priority
strings. telepathy-gabble is an "activated" D-Bus service, so altering
its environment might involve replacing the binary with a wrapper script
that sets environment variables and execs the original binary.

>>> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
...
>> In general there is no reason to use compression with TLS. It
>> can only cause harm (including reveal of plaintext).

XMPP is a fairly verbose protocol (XML, with namespaces used for
extensibility). I'm led to believe that XMPP + deflate is much more
bandwidth-efficient.

If the GNUTLS team's considered opinion is "using deflate is now too
dangerous, and the bandwidth reduction isn't worth it" then we can get
rid of that bit, and point anyone who complains to that explanation.

What priority string would the GNUTLS team recommend for XMPP traffic?
(If the answer is "don't call gnutls_priority_set_direct() by default at
all", that'll be a little more code, but we can do that.)

Do you consider calling gnutls_priority_set_direct() to be a bad idea in
general?

>>> "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP
>>> -
>>> NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC
>>> :
>>> +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
>>
>> That is a pretty dangerous priority string. While modern versions of gnutls
>> would not negotiate DES, RC4-40 or RC2, having them in the priority string
>> reveals something fishy.

That's not the normal configuration. It's intended to be enabled in
bandwidth-constrained environments by ./configure
--enable-prefer-stream-ciphers, documented as "prefer stream ciphers
over block ciphers to save bandwidth (at the possible expense of
security". I believe it may have been implemented for OLPC, in which
they initially deployed clear-text XMPP, then switched on TLS solely for
the bandwidth-reduction of getting compression as a side-effect (their
experimental mesh networking didn't cope well with uncompressed XMPP).

I believe the trailing cipher configurations were copied from the cipher
specs used by then-current GNUTLS, but I could be wrong.

If the GNUTLS team consider this to be dangerous, we could delete that
option altogether, and tell anyone who really wants it to set
$WOCKY_GNUTLS_OPTIONS at their own risk...

    S



From simon.mcvittie at collabora.co.uk  Fri Aug 30 15:34:32 2013
From: simon.mcvittie at collabora.co.uk (Simon McVittie)
Date: Fri, 30 Aug 2013 14:34:32 +0100
Subject: [gnutls-devel] [Telepathy]  mcabber GnuTLS related problem
In-Reply-To: <2161964.iGtGAuAqzE@oledesktop>
References: <hgjbnblziwhljhzovwxj@luvu> <3332389.coFW0obecb@olelaptop>
 <CAJU7zaJbQRp9+GojL7jA7jy6uvzrufiTDyoE7nwL7cCofDNHNg@mail.gmail.com>
 <2161964.iGtGAuAqzE@oledesktop>
Message-ID: <52209F68.1060201@collabora.co.uk>

On 29/08/13 20:33, Niels Ole Salscheider wrote:
>>> This is with the default priority strings:

For testing/debugging, you can set WOCKY_GNUTLS_OPTIONS="NORMAL" (or
whatever) in telepathy-gabble's environment to override these priority
strings. telepathy-gabble is an "activated" D-Bus service, so altering
its environment might involve replacing the binary with a wrapper script
that sets environment variables and execs the original binary.

>>> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
...
>> In general there is no reason to use compression with TLS. It
>> can only cause harm (including reveal of plaintext).

XMPP is a fairly verbose protocol (XML, with namespaces used for
extensibility). I'm led to believe that XMPP + deflate is much more
bandwidth-efficient.

If the GNUTLS team's considered opinion is "using deflate is now too
dangerous, and the bandwidth reduction isn't worth it" then we can get
rid of that bit, and point anyone who complains to that explanation.

What priority string would the GNUTLS team recommend for XMPP traffic?
(If the answer is "don't call gnutls_priority_set_direct() by default at
all", that'll be a little more code, but we can do that.)

Do you consider calling gnutls_priority_set_direct() to be a bad idea in
general?

>>> "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP
>>> -
>>> NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC
>>> :
>>> +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
>>
>> That is a pretty dangerous priority string. While modern versions of gnutls
>> would not negotiate DES, RC4-40 or RC2, having them in the priority string
>> reveals something fishy.

That's not the normal configuration. It's intended to be enabled in
bandwidth-constrained environments by ./configure
--enable-prefer-stream-ciphers, documented as "prefer stream ciphers
over block ciphers to save bandwidth (at the possible expense of
security". I believe it may have been implemented for OLPC, in which
they initially deployed clear-text XMPP, then switched on TLS solely for
the bandwidth-reduction of getting compression as a side-effect (their
experimental mesh networking didn't cope well with uncompressed XMPP).

I believe the trailing cipher configurations were copied from the cipher
specs used by then-current GNUTLS, but I could be wrong.

If the GNUTLS team consider this to be dangerous, we could delete that
option altogether, and tell anyone who really wants it to set
$WOCKY_GNUTLS_OPTIONS at their own risk...

    S



From nmav at gnutls.org  Fri Aug 30 16:18:40 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 30 Aug 2013 17:18:40 +0300
Subject: [gnutls-devel] Patch for GnuTLS 2.10.2 - The DCO
In-Reply-To: <20130830135314.GB15992@gruenau1.informatik.hu-berlin.de>
References: <20C69A88F591DE4FA9456202570661A402B09AEA@svmail2.aed.dir>
 <20130830135314.GB15992@gruenau1.informatik.hu-berlin.de>
Message-ID: <CAJU7zaKFPoCffcZb_VUiDtC0G3Fe+ExEtYgaKJUXnk3R8068kA@mail.gmail.com>

On Fri, Aug 30, 2013 at 4:53 PM, Frank Morgner <
morgner at informatik.hu-berlin.de> wrote:

> Please find the ported patch for RSA-PSK here:
> https://github.com/frankmorgner/gnutls/tree/master
>
> The currently not building branch gnutls_2_10_x should be updated, see
> https://github.com/frankmorgner/gnutls/tree/gnutls_2_10_x
>

Thank you. I have updated the 2.10.x branch. While doing few changes to
adopt it for the master branch, I have a question on the implementation.
You add _gnutls_kx_needs_rsa_params(). Is that supposed to return true when
the ciphersuite requires an RSA certificate, or that temporary RSA
parameters are needed? The code seems to imply the latter, but I'm not sure
that this is needed.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130830/c0319497/attachment.html>

From morgner at informatik.hu-berlin.de  Fri Aug 30 22:05:50 2013
From: morgner at informatik.hu-berlin.de (Frank Morgner)
Date: Fri, 30 Aug 2013 22:05:50 +0200
Subject: [gnutls-devel] Patch for GnuTLS 2.10.2 - The DCO
In-Reply-To: <CAJU7zaKFPoCffcZb_VUiDtC0G3Fe+ExEtYgaKJUXnk3R8068kA@mail.gmail.com>
References: <20C69A88F591DE4FA9456202570661A402B09AEA@svmail2.aed.dir>
 <20130830135314.GB15992@gruenau1.informatik.hu-berlin.de>
 <CAJU7zaKFPoCffcZb_VUiDtC0G3Fe+ExEtYgaKJUXnk3R8068kA@mail.gmail.com>
Message-ID: <20130830200550.GC15992@gruenau1.informatik.hu-berlin.de>

On Friday, August 30 at 05:18PM, Nikos Mavrogiannopoulos wrote:
> On Fri, Aug 30, 2013 at 4:53 PM, Frank Morgner <
> morgner at informatik.hu-berlin.de> wrote:
> 
> > Please find the ported patch for RSA-PSK here:
> > https://github.com/frankmorgner/gnutls/tree/master
> >
> > The currently not building branch gnutls_2_10_x should be updated, see
> > https://github.com/frankmorgner/gnutls/tree/gnutls_2_10_x
> >
> 
> Thank you. I have updated the 2.10.x branch. While doing few changes to
> adopt it for the master branch, I have a question on the implementation.
> You add _gnutls_kx_needs_rsa_params(). Is that supposed to return true when
> the ciphersuite requires an RSA certificate, or that temporary RSA
> parameters are needed? The code seems to imply the latter, but I'm not sure
> that this is needed.

Yes indeed, it should return 1 if the ciphersuite requires rsa paraters.
Although I personally don't like the #define in question, because it is
somewhat not intuitive, I still kept it for consistency. It is the same
mechanism as used in _gnutls_kx_needs_dh_params and it has also been in
the original patch from Bardenheuer.

-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc


From nmav at gnutls.org  Fri Aug 30 22:41:36 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 30 Aug 2013 23:41:36 +0300
Subject: [gnutls-devel] Patch for GnuTLS 2.10.2 - The DCO
In-Reply-To: <20130830200550.GC15992@gruenau1.informatik.hu-berlin.de>
References: <20C69A88F591DE4FA9456202570661A402B09AEA@svmail2.aed.dir>
 <20130830135314.GB15992@gruenau1.informatik.hu-berlin.de>
 <CAJU7zaKFPoCffcZb_VUiDtC0G3Fe+ExEtYgaKJUXnk3R8068kA@mail.gmail.com>
 <20130830200550.GC15992@gruenau1.informatik.hu-berlin.de>
Message-ID: <CAJU7zaKVy60eKRx=kwKWWx1x_wrdzZFp9f2LGfrEU6Aoea_GOQ@mail.gmail.com>

On Fri, Aug 30, 2013 at 11:05 PM, Frank Morgner <
morgner at informatik.hu-berlin.de> wrote:


> > Thank you. I have updated the 2.10.x branch. While doing few changes to
> > adopt it for the master branch, I have a question on the implementation.
> > You add _gnutls_kx_needs_rsa_params(). Is that supposed to return true
> when
> > the ciphersuite requires an RSA certificate, or that temporary RSA
> > parameters are needed? The code seems to imply the latter, but I'm not
> sure
> > that this is needed.
> Yes indeed, it should return 1 if the ciphersuite requires rsa paraters.
> Although I personally don't like the #define in question, because it is
> somewhat not intuitive, I still kept it for consistency. It is the same
> mechanism as used in _gnutls_kx_needs_dh_params and it has also been in
> the original patch from Bardenheuer.
>

I have applied the patch but simplified few things, and tried to update
rsa-psk.c the same direction rsa.c had been, so that it can be used with
HSMs. A rewrite to keep some common base will be needed, but I leave that
for a later time.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130830/4bc7a8ad/attachment.html>

From nmav at gnutls.org  Sat Aug 31 11:43:18 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 31 Aug 2013 12:43:18 +0300
Subject: [gnutls-devel] gnutls 3.0.32
Message-ID: <20130831124318.0455bc7f@aspire.lan>

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

* Version 3.0.32 (released 2013-08-31)

** libgnutls: Fixes when session tickets and session DB are used.
Report and initial patch by Stefan Buehler.

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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.32.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.32.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  Sat Aug 31 12:03:35 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 31 Aug 2013 13:03:35 +0300
Subject: [gnutls-devel] gnutls 3.1.14
Message-ID: <20130831130335.6c19568a@aspire.lan>

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

* Version 3.1.14 (released 2013-08-31)

** libgnutls: Fixes when session tickets and session DB are used.
Report and initial patch by Stefan Buehler.

** libgnutls: Added the PFS priority string option.

** libgnutls: Fixes in gnutls_record_send_range(). Report and initial
fix by Alfredo Pironti.

** API and ABI modifications:
gnutls_record_set_timeout: Exported


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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.14.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.14.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  Sat Aug 31 16:17:58 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 31 Aug 2013 17:17:58 +0300
Subject: [gnutls-devel] gnutls 3.2.4
Message-ID: <20130831171758.4108f196@aspire.lan>

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

* Version 3.2.4 (released 2013-08-31)

** libgnutls: Fixes when session tickets and session DB are used.
Report and initial patch by Stefan Buehler.

** libgnutls: Added the RSA-PSK key exchange. Patch by by Frank Morgner,
based on previous patch by Bardenheuer GmbH and Bundesdruckerei GmbH.

** libgnutls: Added ciphersuites that use ARCFOUR with ECDHE. Patch
by Stefan Buehler.

** libgnutls: Added the PFS priority string option.

** libgnutls: Gnulib included files are strictly LGPLv2.

** libgnutls: Corrected gnutls_certificate_server_set_request().
Reported by Petr Pisar.

** API and ABI modifications:
gnutls_record_set_timeout: Exported


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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.4.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.4.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 mark at markelee.com  Sat Aug 31 17:37:44 2013
From: mark at markelee.com (Mark E. Lee)
Date: Sat, 31 Aug 2013 11:37:44 -0400
Subject: [gnutls-devel] gnutls 3.2.4
In-Reply-To: <20130831171758.4108f196@aspire.lan>
References: <20130831171758.4108f196@aspire.lan>
Message-ID: <1377963464.7345.0.camel@melech-server.localdomain>

On Sat, 2013-08-31 at 17:17 +0300, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I've just released gnutls 3.2.4. This is a bug-fix release on the
> next stable branch.
> 
> * Version 3.2.4 (released 2013-08-31)
> 
> ** libgnutls: Fixes when session tickets and session DB are used.
> Report and initial patch by Stefan Buehler.
> 
> ** libgnutls: Added the RSA-PSK key exchange. Patch by by Frank Morgner,
> based on previous patch by Bardenheuer GmbH and Bundesdruckerei GmbH.
> 
> ** libgnutls: Added ciphersuites that use ARCFOUR with ECDHE. Patch
> by Stefan Buehler.
> 
> ** libgnutls: Added the PFS priority string option.
> 
> ** libgnutls: Gnulib included files are strictly LGPLv2.
> 
> ** libgnutls: Corrected gnutls_certificate_server_set_request().
> Reported by Petr Pisar.
> 
> ** API and ABI modifications:
> gnutls_record_set_timeout: Exported
> 
> 
> 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.4.tar.xz
>   ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.4.tar.lz
> 
> Here are OpenPGP detached signatures signed using key 0x96865171:
> 
>   ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.4.tar.xz.sig
>   ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.4.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
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel

Compiled and tested on Arch Linux-x64; works for me.

From,
Mark
-- 
Mark E. Lee <mark at markelee.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20130831/380d7526/attachment.sig>