headers
Phil Pennock | 20 May 2012 12:16

GnuTLS/NSS interop in Exim 4.80 RC

Folks,

Short: NSS client to GnuTLS 2.12 (but not 2.8) fails TLS negotiation,
GnuTLS dropping connection after reporting receiving a phantom packet.

Long:

For the Exim 4.80 release, currently in Release Candidate, I re-did the
GnuTLS integration to stop using APIs which gave deprecation warnings.
As part of this, I removed the hard-coded lists of algorithms from Exim,
instead delegating that task to GnuTLS, and passing the Exim
tls_require_ciphers string to gnutls_priority_init().

Things had been going well in the Release Candidates, but we now have a
release blocker.  It seems that Thunderbird (NSS security library) can
not set up a TLS session with GnuTLS 2.12.18.  (I saw the .19
announcement, to me it doesn't look as though there's anything
relevant?)

Bug in 2.12.14 and 2.12.18, seen by two people (myself one of them); but
not in 2.8.5.  No problems observed with OpenSSL or GnuTLS clients, just
NSS.

Mail thread starts at:
  https://lists.exim.org/lurker/message/20120520.040118.edd7eecb.en.html
overview:
  https://lists.exim.org/lurker/thread/20120520.040118.edd7eecb.en.html#i20120520.040118.edd7eecb
Protocol dump in my mail:
  https://lists.exim.org/lurker/message/20120520.092423.0e38168b.en.html
(Continue reading)

Permalink | Reply |
headers
Phil Pennock | 20 May 2012 12:40

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-20 at 06:16 -0400, Phil Pennock wrote:
> Short: NSS client to GnuTLS 2.12 (but not 2.8) fails TLS negotiation,
> GnuTLS dropping connection after reporting receiving a phantom packet.

I am sorry.

Correction: there is no phantom packet.  GnuTLS returns the
"GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9    /* GNUTLS_A_RECORD_OVERFLOW */"
error code when there is an EOF because of abrupt client disconnect.

So much of my analysis is bonkers, but there's still an issue.  NSS
*can* set up a client connection to GnuTLS 2.8 but not 2.12,
disconnecting after receiving server_hello_done.

Any help / guidance appreciated.

Thanks,
-Phil
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 20 May 2012 16:24

Re: GnuTLS/NSS interop in Exim 4.80 RC

Hello,
 From what I can tell it is the client for some reason terminates the
connection. What is the output on the client? Do you have a tcpdump of
the issue? Have you tried alternative priority strings than normal
[0]?

[0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html

regards,
Nikos

On Sun, May 20, 2012 at 12:16 PM, Phil Pennock
<help-gnutls-phil <at> spodhuis.org> wrote:
> Folks,
>
> Short: NSS client to GnuTLS 2.12 (but not 2.8) fails TLS negotiation,
> GnuTLS dropping connection after reporting receiving a phantom packet.
>
> Long:
>
> For the Exim 4.80 release, currently in Release Candidate, I re-did the
> GnuTLS integration to stop using APIs which gave deprecation warnings.
> As part of this, I removed the hard-coded lists of algorithms from Exim,
> instead delegating that task to GnuTLS, and passing the Exim
> tls_require_ciphers string to gnutls_priority_init().
>
> Things had been going well in the Release Candidates, but we now have a
> release blocker.  It seems that Thunderbird (NSS security library) can
> not set up a TLS session with GnuTLS 2.12.18.  (I saw the .19
> announcement, to me it doesn't look as though there's anything
(Continue reading)

Permalink | Reply |
headers
Phil Pennock | 21 May 2012 01:17

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>  From what I can tell it is the client for some reason terminates the
> connection. What is the output on the client? Do you have a tcpdump of
> the issue? Have you tried alternative priority strings than normal
> [0]?
> 
> [0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html

Janne Snabb has done better detective work than I and found that NSS has
a hard-coded clamp on the number of DH bits used for ephemeral D-H and
GnuTLS's return value from gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH,
GNUTLS_SEC_PARAM_NORMAL) is over that limit.

I'll add a clamp option to Exim and default it to the current NSS limit.

Thanks,
-Phil
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 21 May 2012 11:41

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Mon, May 21, 2012 at 1:17 AM, Phil Pennock
<help-gnutls-phil <at> spodhuis.org> wrote:
> On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>>  From what I can tell it is the client for some reason terminates the
>> connection. What is the output on the client? Do you have a tcpdump of
>> the issue? Have you tried alternative priority strings than normal
>> [0]?
>>
>> [0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
> Janne Snabb has done better detective work than I and found that NSS has
> a hard-coded clamp on the number of DH bits used for ephemeral D-H and
> GnuTLS's return value from gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH,
> GNUTLS_SEC_PARAM_NORMAL) is over that limit.

That's very interesting. Our key sizes is according to recommendations
like ECRYPT [0]. What is the NSS limit? Did you report it to the NSS
people?

[0]. http://www.keylength.com/en/3/

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
https://lists.gnu.org/mailman/listinfo/help-gnutls
Permalink | Reply |
headers
Phil Pennock | 21 May 2012 12:06

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-21 at 11:41 +0200, Nikos Mavrogiannopoulos wrote:
> That's very interesting. Our key sizes is according to recommendations
> like ECRYPT [0]. What is the NSS limit? Did you report it to the NSS
> people?
> 
> [0]. http://www.keylength.com/en/3/

NSS limit is 2236 bits.  I haven't reported it yet, been too busy
unblocking release and staying on top of the flood of mails whenever a
release candidate happens.  ;)

I'll dig out the reporting method for GnuTLS now.  Thanks for the
reminder.

-Phil
Permalink | Reply |
headers
Phil Pennock | 22 May 2012 02:51

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-21 at 06:06 -0400, Phil Pennock wrote:
> On 2012-05-21 at 11:41 +0200, Nikos Mavrogiannopoulos wrote:
> > That's very interesting. Our key sizes is according to recommendations
> > like ECRYPT [0]. What is the NSS limit? Did you report it to the NSS
> > people?
> > 
> > [0]. http://www.keylength.com/en/3/
> 
> NSS limit is 2236 bits.  I haven't reported it yet, been too busy
> unblocking release and staying on top of the flood of mails whenever a
> release candidate happens.  ;)
> 
> I'll dig out the reporting method for GnuTLS now.  Thanks for the
> reminder.

I must've needed sleep, as I instead got hung up on creating a Savannah
account to file a GnuTLS bug (blocked on account creation).  A little
more rested, I see that Janne Snabb has beaten me to it, commenting on
the existing bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=636802

-Phil
Permalink | Reply |
headers
Janne Snabb | 22 May 2012 08:48
Favicon

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Mon, 21 May 2012, Phil Pennock wrote:

> I must've needed sleep, as I instead got hung up on creating a Savannah
> account to file a GnuTLS bug (blocked on account creation).

Maybe you were unconsicously planning to file a bug about the misleading
EOF handling? :) I think we both wasted several hours of debugging time
because of that.

If a new error code can not be introduced due to API compatibility
reasons, the debug output should at least clearly indicate what happened
(instead of "ASSERT: somefunction(): NNN").

--
Janne Snabb / EPIPE Communications
snabb <at> epipe.com - http://epipe.com/
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 22 May 2012 09:47

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Tue, May 22, 2012 at 8:48 AM, Janne Snabb <snabb <at> epipe.com> wrote:
>> I must've needed sleep, as I instead got hung up on creating a Savannah
>> account to file a GnuTLS bug (blocked on account creation).
> Maybe you were unconsicously planning to file a bug about the misleading
> EOF handling? :) I think we both wasted several hours of debugging time
> because of that.
> If a new error code can not be introduced due to API compatibility
> reasons, the debug output should at least clearly indicate what happened
> (instead of "ASSERT: somefunction(): NNN").

Hello,
 I don't really understand what you mean here. Is there an issue in
gnutls we can somehow improve?

regards,
Nikos
Permalink | Reply |
headers
Phil Pennock | 22 May 2012 10:24

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-22 at 09:47 +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, May 22, 2012 at 8:48 AM, Janne Snabb <snabb <at> epipe.com> wrote:
> > Maybe you were unconsicously planning to file a bug about the misleading
> > EOF handling? :) I think we both wasted several hours of debugging time
> > because of that.
> > If a new error code can not be introduced due to API compatibility
> > reasons, the debug output should at least clearly indicate what happened
> > (instead of "ASSERT: somefunction(): NNN").
> 
> Hello,
>  I don't really understand what you mean here. Is there an issue in
> gnutls we can somehow improve?

When we were tracking down the NSS interop issue, we were both led a
little astray by one error return.

<gnutls/gnutls.h> says:
  #define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9    /* GNUTLS_A_RECORD_OVERFLOW */

The error message was "A TLS packet with unexpected length was
received."

The problem is that *no* TLS packet was received.  Instead, there was an
EOF condition.  (Okay, sure there's a TCP RST involved, but that's not
TLS).

I spent a bit of time looking for the extra packet, and not seeing it in
ssltap/etc this is what led me to initially wonder if there was stale
data being left behind from a previous packet to GnuTLS.
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 22 May 2012 10:28

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Tue, May 22, 2012 at 10:24 AM, Phil Pennock
<help-gnutls-phil <at> spodhuis.org> wrote:

>> Hello,
>>  I don't really understand what you mean here. Is there an issue in
>> gnutls we can somehow improve?
> When we were tracking down the NSS interop issue, we were both led a
> little astray by one error return.
> <gnutls/gnutls.h> says:
>  #define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9    /* GNUTLS_A_RECORD_OVERFLOW */
>
> The error message was "A TLS packet with unexpected length was
> received."
> The problem is that *no* TLS packet was received.  Instead, there was an
> EOF condition.  (Okay, sure there's a TCP RST involved, but that's not
> TLS).
> I spent a bit of time looking for the extra packet, and not seeing it in
> ssltap/etc this is what led me to initially wonder if there was stale
> data being left behind from a previous packet to GnuTLS.
> If it can be accomplished without real interoperability issues, a
> separate error code for EOF would really help with diagnosis.

We have separate error codes for these conditions in gnutls 3.0.x.

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
(Continue reading)

Permalink | Reply |
headers
Phil Pennock | 23 May 2012 03:03

GnuTLS 3, BSD, netinet/ip.h

On 2012-05-22 at 10:28 +0200, Nikos Mavrogiannopoulos wrote:
[ EOF vs buffer overflow ]
> We have separate error codes for these conditions in gnutls 3.0.x.

Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
stuck to 2.12.

Building GnuTLS 3 on my dated FreeBSD 7 series install is failing, but
when I check on a more recent (FreeBSD 9) system I see that the relevant
type has been changed to avoid the issue.

----------------------------8< cut here >8------------------------------
  CC     serv.o
In file included from common.h:31,
                 from serv.c:28:
/usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long'
serv.c: In function 'tcp_server':
serv.c:1245: warning: cast to pointer from integer of different size
*** Error code 1
----------------------------8< cut here >8------------------------------

----------------------------8< cut here >8------------------------------
149 struct  ip_timestamp {
...
161         union ipt_timestamp {
162                 n_long  ipt_time[1];
163                 struct  ipt_ta {
164                         struct in_addr ipt_addr;
165                         n_long ipt_time;
166                 } ipt_ta[1];
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 23 May 2012 21:03
Picon
Gravatar

Re: GnuTLS 3, BSD, netinet/ip.h

On 05/23/2012 03:03 AM, Phil Pennock wrote:

> On 2012-05-22 at 10:28 +0200, Nikos Mavrogiannopoulos wrote:
> [ EOF vs buffer overflow ]
>> We have separate error codes for these conditions in gnutls 3.0.x.
> 
> Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
> stuck to 2.12.
> 
> Building GnuTLS 3 on my dated FreeBSD 7 series install is failing, but
> when I check on a more recent (FreeBSD 9) system I see that the relevant
> type has been changed to avoid the issue.
> ----------------------------8< cut here >8------------------------------
>   CC     serv.o
> In file included from common.h:31,
>                  from serv.c:28:
> /usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long'
> serv.c: In function 'tcp_server':
> serv.c:1245: warning: cast to pointer from integer of different size
> *** Error code 1
> ----------------------------8< cut here >8------------------------------

It looks like an issue in the system rather than something that's worth
fixing in gnutls. So it is that the netinet/in.h is unusable on this
system? In that case could you submit to gnulib [0] your suggested patch?

[0]. http://www.gnu.org/software/gnulib/

regards,
Nikos
(Continue reading)

Permalink | Reply |
headers
Phil Pennock | 23 May 2012 22:45

Re: GnuTLS 3, BSD, netinet/ip.h

On 2012-05-23 at 21:03 +0200, Nikos Mavrogiannopoulos wrote:
> It looks like an issue in the system rather than something that's worth
> fixing in gnutls. So it is that the netinet/in.h is unusable on this
> system?

netinet/ip.h != netinet/in.h

netinet/in.h is perfectly usable; ip.h defines struct ip, the IP
options, IPTOS values, struct ip_timestamp, ippseudo and some TTL & MSS
constants.  On a Linux box, mostly the same except that it's "struct
timestamp", no "ip_" prefix.

I wondered why this was needed so just did a build with the include
completely removed.

Everything built just fine.  It appears to be superfluous.

-Phil
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 24 May 2012 00:18
Picon
Gravatar

Re: GnuTLS 3, BSD, netinet/ip.h

On 05/23/2012 10:45 PM, Phil Pennock wrote:

 
> netinet/ip.h != netinet/in.h
> 
> netinet/in.h is perfectly usable; ip.h defines struct ip, the IP
> options, IPTOS values, struct ip_timestamp, ippseudo and some TTL & MSS
> constants.  On a Linux box, mostly the same except that it's "struct
> timestamp", no "ip_" prefix.
> 
> I wondered why this was needed so just did a build with the include
> completely removed.
> 
> Everything built just fine.  It appears to be superfluous.

Indeed. I've dropped it as well.

regards,
Nikos
Permalink | Reply |
headers
Janne Snabb | 24 May 2012 12:28
Favicon

Re: GnuTLS 3, BSD, netinet/ip.h

On Tue, 22 May 2012, Phil Pennock wrote:

> Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
> stuck to 2.12.

Ubuntu 12.04 actually has GnuTLS 3.0.11 but it is the same as in Debian
sid and testing: the package name is really confusing, they call it
"libgnutls28" for some strange reason. Unfortunately all the GnuTLS
consumers (such as Exim packages for example) are linking against some
older 2.x version depending on the distribution.

--
Janne Snabb / EPIPE Communications
snabb <at> epipe.com - http://epipe.com/
Permalink | Reply |
headers
Phil Pennock | 25 May 2012 08:42

Re: GnuTLS 3, BSD, netinet/ip.h

On 2012-05-24 at 10:28 +0000, Janne Snabb wrote:
> On Tue, 22 May 2012, Phil Pennock wrote:
> > Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
> > stuck to 2.12.
> 
> Ubuntu 12.04 actually has GnuTLS 3.0.11 but it is the same as in Debian
> sid and testing: the package name is really confusing, they call it
> "libgnutls28" for some strange reason. Unfortunately all the GnuTLS
> consumers (such as Exim packages for example) are linking against some
> older 2.x version depending on the distribution.

*sigh*  Well, we now use pkg-config for finding dependencies; I've
updated my Ubuntu colo VM from Oneiric to Pangolin, to get libgnutls28
available.  libgnutls28 remains non-default, but I have it now.

There are now two -dev packages containing headers and the pkg-config
file, "libgnutls-dev" and "libgnutls28-dev".  They're marked as
conflicting, so only one can be installed at once.

So Exim's current limitations concerning conflicts in include/library
paths for different components aren't an issue.  Install the -dev
package wanted, use USE_GNUTLS_PC=gnutls as suggested in Local/Makefile
and anyone building for themselves will get GnuTLS 3.

-Phil
Permalink | Reply |
headers
Tobias Gruetzmacher | 29 May 2012 11:35

Re: GnuTLS 3, BSD, netinet/ip.h

Hi,

On Thu, 24 May 2012 10:28:41 +0000 (UTC), Janne Snabb wrote:
> Ubuntu 12.04 actually has GnuTLS 3.0.11 but it is the same as in 
> Debian
> sid and testing: the package name is really confusing, they call it
> "libgnutls28" for some strange reason.

This "strange reason" is called "library versioning" - The internal 
major version of gnutls 3.0.x is 28 (That's LT_CURRENT-LT_AGE in 
m4/hooks.m4). And since Debian has the policy of using the library 
version in the package name to allow installation of multiple 
incompatible versions of the same library on the same system, you get 
libgnutls28 for gnutls 3.0 (or something like libx264-118, libx264-120 
and libx264-123 for packages with really unstable ABIs).

HTH, Tobias
Permalink | Reply |
headers
Janne Snabb | 22 May 2012 10:38
Favicon

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-22 14:47, Nikos Mavrogiannopoulos wrote:
>  I don't really understand what you mean here. Is there an issue in
> gnutls we can somehow improve?

The previously discussed interop problem between GnuTLS and NSS
manifests itself in such a way that NSS client just closes the TCP
connection after it receives the "Server Hello" packet which it does not
like. The GnuTLS library provides very misleading diagnostics in that case:

[..snip..]
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
length: 4
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
4011 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
4011 GnuTLS<2>: ASSERT: gnutls_record.c:969
4011 GnuTLS<2>: ASSERT: gnutls_handshake.c:3061
4011 LOG: MAIN
4011 TLS error on connection from localhost [127.0.0.1]
(gnutls_handshake): A TLS packet with unexpected length was received.
4003 child 4011 ended: status=0x0
4003 normal exit, 0

Instead of seeing an indication of EOF, GnuTLS reports "TLS packet with
unexpected length was received". One must dive into gnutls_buffers.c to
realize that it was EOF that just happened:

  if (ret == 0)
    {                           /* EOF */
      gnutls_assert ();
      return 0;
(Continue reading)

Permalink | Reply |
headers
Patrick Pelletier | 22 May 2012 11:15
Favicon

Re: GnuTLS/NSS interop in Exim 4.80 RC

On May 22, 2012, at 1:38 AM, Janne Snabb wrote:

> Even if the hard
> limit in NSS is fixed quickly, this will be a burden for TLS server  
> side
> developers for many years to come.

It almost seems like a new TLS extension should be proposed, where the  
client can tell the server how many bits of DH it is willing to  
accept.  (Similar in spirit, although simpler than, the extension used  
to negotiate curves for elliptic curve.)  If the client sends the  
extension, then the server can know with confidence what size of DH  
params are acceptable.  If the client doesn't send the extension, the  
server can make a conservative assumption.  (Probably 2236 bits.)

Without such an extension, it seems like TLS servers that are  
concerned about interoperability (such as on the Web) will have to  
avoid exceeding 2236 bits for quite a long time.

--Patrick
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 22 May 2012 11:23

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Tue, May 22, 2012 at 11:15 AM, Patrick Pelletier
<code <at> funwithsoftware.org> wrote:

> It almost seems like a new TLS extension should be proposed, where the
> client can tell the server how many bits of DH it is willing to accept.
>  (Similar in spirit, although simpler than, the extension used to negotiate
> curves for elliptic curve.)  If the client sends the extension, then the
> server can know with confidence what size of DH params are acceptable.  If
> the client doesn't send the extension, the server can make a conservative
> assumption.  (Probably 2236 bits.)

Such an extension would be useful, as it could be used to communicate
the DH exponent size which now is only known to the server. That would
also optimize the key exchange. However I doubt that the WG would
accept such a modification (most probably such a proposal will be
answered with why don't you use ECDH?).

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
https://lists.gnu.org/mailman/listinfo/help-gnutls
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 22 May 2012 11:18

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Tue, May 22, 2012 at 10:38 AM, Janne Snabb <snabb <at> epipe.com> wrote:

> The previously discussed interop problem between GnuTLS and NSS
> manifests itself in such a way that NSS client just closes the TCP
> connection after it receives the "Server Hello" packet which it does not
> like. The GnuTLS library provides very misleading diagnostics in that case:
> [..snip..]
> 4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
> length: 4
> 4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
> 4011 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
> 4011 GnuTLS<2>: ASSERT: gnutls_record.c:969
> 4011 GnuTLS<2>: ASSERT: gnutls_handshake.c:3061
[...]
> Instead of seeing an indication of EOF, GnuTLS reports "TLS packet with
> unexpected length was received". One must dive into gnutls_buffers.c to
> realize that it was EOF that just happened:

Indeed this was a long time request, but would have broken the API
(many clients or servers of gnutls check for that error code to
determine eof). Thus we have only incorporated that update in the
latest 3.0.x releases. Meaning that in a 3.0.x you should have
received the error code GNUTLS_E_PREMATURE_TERMINATION.

> I updated the NSS bug [1] with simple instructions on how to reproduce
> the issue using GnuTLS command line tools and Firefox. Even if the hard
> limit in NSS is fixed quickly, this will be a burden for TLS server side
> developers for many years to come. Luckily new versions of GnuTLS now
> have ECDHE-RSA key exchange support as it masks the DHE-RSA interop
> problem. People can survive with recent NSS clients if they make sure
(Continue reading)

Permalink | Reply |
headers
Janne Snabb | 22 May 2012 13:40
Favicon

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-22 16:18, Nikos Mavrogiannopoulos wrote:
> Meaning that in a 3.0.x you should have
> received the error code GNUTLS_E_PREMATURE_TERMINATION.

Thanks for the clarification!

I linked Exim against more recent GnuTLS library and can now see the
following error message when the EOF happens:

(gnutls_handshake): The TLS connection was non-properly terminated.

Sorry to bother with bugs that do not exist any more :).

--

-- 
Janne Snabb / EPIPE Communications
snabb <at> epipe.com - http://epipe.com/
Permalink | Reply |
headers
Janne Snabb | 25 May 2012 19:22
Favicon

Re: GnuTLS/NSS interop in Exim 4.80 RC

On Mon, 21 May 2012, Phil Pennock wrote:

> NSS limit is 2236 bits.

Just a brief update on this in case someone is interested:

It appears that this limit has been already increased to 3072 bits in
the latest NSS release 3.13.4. See the diff at:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=blapit.h&branch=&root=/cvsroot&subdir=mozilla/security/nss/lib/freebl&command=DIFF_FRAMESET&rev1=1.25&rev2=1.26

Thus we should be soon starting to see NSS based clients which can
negotiate DHE-RSA with GnuTLS at "NORMAL" security level.

Now they are planning to increase the limit to 16k in the next NSS
release 3.13.5. See the latest update of the NSS bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=636802

After that has been completed, NSS clients should be able to do DHE
(but probably not RSA) with GnuTLS server at all security levels.

--
Janne Snabb / EPIPE Communications
snabb <at> epipe.com - http://epipe.com/
Permalink | Reply |
headers
Phil Pennock | 21 May 2012 01:02

Re: GnuTLS/NSS interop in Exim 4.80 RC

On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>  From what I can tell it is the client for some reason terminates the
> connection. What is the output on the client? Do you have a tcpdump of
> the issue? Have you tried alternative priority strings than normal
> [0]?

The client is using NSS and from what I can tell does not log problems
at the NSS level.  I've searched for ways to do that but failed.  The
protocol dump email I referenced in the first post includes the output
from ssltap; is that sufficient or do you want a raw packet capture?

> [0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html

Well, I need to add a new test to the test suite, since I had omitted an
assignment and the default of NORMAL was always being used.

NORMAL:%COMPAT does not help.
NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT does not help.

NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128:%COMPAT
*does* work.

With just "NORMAL:-CIPHER-ALL:+ARCFOUR-128" negotiation works and the
negotiated protocol is TLS1.0:RSA_ARCFOUR_MD5:128.  So it's not %COMPAT
that causes issues.

"AEAD" isn't recognised in 2.12.  Looking at the .texi I see that 2.12
supports: AES-128-CBC, AES-256-CBC, CAMELLIA-128-CBC, CAMELLIA-256-CBC,
ARCFOUR-128, 3DES-CBC ARCFOUR-40.
(Continue reading)

Permalink | Reply |

Gmane