Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

On Fri, Nov 21, 2008 at 11:58:36AM -0500, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
> > Hello, this does not seem to be a gnutls error. The server merely asks
> > for renegotiation, gnutls-cli ignores it (legal behavior) and server
> > does not like it thus sends a fatal alert.
> 
> Do you think this is exposing a bug in mod_ssl, then?  If it is legal
> behavior to ignore a renegotiation, it seems to me that
> SSLVerifyClient optional should not cause the server to terminate the
> connection if a rehandshake is rejected.  Should we clone this bug, or
> open a new report against apache or openssl?

IIUC what will happen in this case is that mod_ssl puts OpenSSL into the 
state where it expects a full handshake - if it receives any app_data 
packets OpenSSL treats thas a hard failure.  And slso IIUC - this 
results in the server sending a ChangeCipherSpec message on the wire - 
and the client has no option to ignore that in TLS, right?

joe

Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
>> Hello, this does not seem to be a gnutls error. The server merely asks
>> for renegotiation, gnutls-cli ignores it (legal behavior) and server
>> does not like it thus sends a fatal alert.
> 
> Do you think this is exposing a bug in mod_ssl, then?  If it is legal
> behavior to ignore a renegotiation, it seems to me that
> SSLVerifyClient optional should not cause the server to terminate the
> connection if a rehandshake is rejected.  Should we clone this bug, or
> open a new report against apache or openssl?

Could you first send me a capture to be used with wireshark so i can
check precisely what is happening there (gnutls-cli) and rule out any
gnutls issue?

regards,
Nikos

Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

On Fri, Nov 21, 2008 at 09:24:02AM +0200, Nikos Mavrogiannopoulos wrote:
> For neon to solve this, it has to perform a handshake after the
> rehandshake request has been required.

Ah, I didn't realise that - OpenSSL will automatically rehandshake 
whenever requested by the server.  So to provide the equivalent 
behaviour with GnuTLS, I have to do something like:

start:
   ret = gnutls_record_send(blah);
   if (ret == GNUTLS_E_REHANDSHAKE) {
       gnutls_handshake(blah);
       goto start;
   }

and similarly with calls to record_recv?

Regards, Joe

Re: gnome-keyring patch

Daniel Black <dragonheart <at> gentoo.org> writes:

> Simon Josefsson wrote:
>
>> Daniel Black <dragonheart <at> gentoo.org> writes:
>> 
>>> gnome-keyring patch reported taking the libtasn1.m4 content and
>>> supporting libtasn1-config and pkg-config.
>>>
>>> http://bugzilla.gnome.org/show_bug.cgi?id=560869
>>>
>>> probably should of put the pkg-config bit first. oh well, only a
>>> transition strategy.
>> 
>> Thanks.  Btw, pkg-config has been supported by libtasn1 for quite a
>> while (0.2.14 to be precise), so maybe libtasn1-config isn't worth
>> supporting anymore?
>> 
>> /Simon
>
> Thanks for research into history. I probably should of done that and saved
> some m4 porting pain. Updated patch in gnome bugzilla. Thanks again Simon.

That patch looks simple and nice, thanks.

/Simon

GnuTLS 2.7.2

The GnuTLS 2.7.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.2.tar.bz2 (5.7MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.2.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.2.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.2.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon

* Version 2.7.2 (released 2008-11-18)

** libgnutls: Fix X.509 certificate chain validation error. [GNUTLS-SA-2008-3]
The flaw makes it possible for man in the middle attackers (i.e.,
active attackers) to assume any name and trick GNU TLS clients into
trusting that name.  Thanks for report and analysis from Martin von

libtasn1-1.6 removed libtasn1-config though gnutls still uses it

from the gnutls-2.6.2
checking for libtasn1-config... no
checking for libtasn1 - version >= 0.3.4... no
*** The libtasn1-config script installed by LIBTASN1 could not be found

can I request  libtasn1-config be reinstated until phased out by other things 
that use it?

also - not sure if you still use 
https://savannah.gnu.org/support/?group=gnutls

simple patchs are there
https://savannah.gnu.org/support/?106549
https://savannah.gnu.org/support/?106542

also still failing for me here:
https://savannah.gnu.org/support/?106543

Cheers,

--

-- 
Daniel Black <dragonheart <at> gentoo.org>
Gentoo Foundation

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel

GnuTLS 2.6.2 - Brown paper bag release

We are proud to announce a new stable GnuTLS release: Version 2.6.2.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed under
the GNU Free Documentation License version 1.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/

What's New
==========

Version 2.6.2 is a maintenance release on our stable branch.

* Version 2.6.2 (released 2008-11-12)

** libgnutls: Fix crash in X.509 validation code for self-signed certificates.
The patch to fix the security problem GNUTLS-SA-2008-3 introduced a
problem for certificate chains that contained just one self-signed
certificate.  Reported by Michael Meskes <meskes <at> debian.org> in

OpenLDAP related flaw in GnuTLS

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel

More intelligent path finding

Hi again.

While looking at _gnutls_x509_verify_certificate I realized that I
personally would have implemented this whole verification process a bit
differently. I'm not a regular reader of the gnutls-devel list, but I
have the feeling that some recent posts might go in the same direction.

I'd have the function called with a single certificate to verify, a list
of untrusted certificates to be used for the chain, and a list of
trusted certificates to be used as the root. The verification process
would look for the issuer of the current certificate first in the list
of trusted certificates. If it finds one, verify and return result. If
not, look for the issuer in the list of untrusted certificates. If it
finds one, verify that next (recursively), if not we don't have enough
material for a chain.

This process would have two benefits. The order in which the
intermediate certificates are submitted wouldn't matter any more. And
you could also add some intermediate certificate to the list of trusted
certificates, in order to trust a subtree of the hierarchy, and the
server could still continue to submit its whole chain. E.g. a server A
could submit the chain [A, B, C, D, E], with E as a self-signed root.
When you only want to trust certificates from C, you would add that to
your list of trusted CAs, never mind that it's not self signed, and
GnuTLS would accept A after verifying two signatures, A-B and B-C.

So far for my own ideas. I already included them in some private
correspondence with Simon, and he mentioned that this might cause DoS
issues, and that a DoS-proof setup should theoretically start at the
trusted root. As an alternative, one could find the path as described
above by simply looking at the distinguished names (and maybe some other
elements used to distinguish certificates over time?) and verify the
whole path the classical way once it's been found.

So much for my suggestion. I would assume that this should be fairly
easy to implement. I don't know whether I will find the time for this in
the forseeable future, though, especially as I still haven't read large
parts of the GnuTLS codebase. So I offer this for discussion, and leave
it for you to comment, maybe even implement, or wait until I find the
time and motivation.

Greetings,
 Martin

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel

How GNUTLS-SA-2008-3 was discovered

Hi guys!

Simon kindly asked me to share with you how I found this recent issue in
the first place. For those interested, read on. Others may skip it.

Simon Josefsson wrote:
> Martin, btw, how did you find the problem?  It can be useful for me to
> to understand when talking about how GnuTLS security reporting works.

I have a local server authenticated using a CAcert certificate. The
server is an Apache configured to submit its whole chain, which starts
at the CAcert root, includes an intermediate (class 3) certificate from
CAcert and finally arrives at the server certificate.

On that server I have a svn repository, which I recently tried to access
using bzr. The connection failed, and the error message wasn't
particularly useful, openssl s_client had no problems at all, so I
started debugging the code in order to find the cause of this error.

I found out that bzr tried to connect using pycurl, and that my curl
library was using GnuTLS. I'm using Gentoo here, and have most
allications that support GnuTLS use that. Inside the GnuTLS code I
finally got to the actual cause: the class 3 certificate from CAcert was
signed by the root certificate using MD5, which GnuTLS considers broken.

While I stopped to wonder for a moment, I also got worried that this
would affect several other servers I have set up in a similar way. Just
for comparison I connected one of them using the curl command line tool,
and to my surprise found out that it connected without any complaints.

I couldn't fathom the reason for this, and as I had my debugging
environment already set up and knew my way around the GnuTLS
verification code by then, I debugged both connections. I found out that
the problematic MD5-based signature was never actually verified in the
cases where connection succeeded. I found the cause for this in the
broken mechanics of _gnutls_x509_verify_certificate.

With that knowledge, I could finally find the difference in my server
configuration: I had concatenated the chain certificates in the wrong
order, so that the complete list or certificates was 0: server, 1: root,
2: intermediate. Thus on my system, the signature mechanism of the
intermediate certificate caused the error, while on those other systems
with correct setup the root was dropped, and the signature from
intermediate to server certificate was deemed valid, as it uses sha.

Of course once I realized that there was no bug in GnuTLS breaking my
lokal setup, but instead an intentional distrust towards MD5, and that
the other setups only worked because one step wasn't verified at all, I
knew I had found a serious security issue. I performed this model setup
I already wrote about to make sure, and then contacted Simon.

Greetings,
 Martin

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel

cve-2008-4989.c

Here is a self-test that detects whether the installed libgnutls is
vulnerable or not.

Build it:

gcc -o cve-2008-4989 cve-2008-4989.c -lgnutls

Output for vulnerable libraries:

jas <at> mocca:~/src/gnutls/tests master$ LD_PRELOAD=/usr/lib/libgnutls.so ./cve-2008-4989 ; echo $?
./cve-2008-4989: verify_status: 0
1
jas <at> mocca:~/src/gnutls/tests master$

Output for fixed libraries:

jas <at> mocca:~/src/gnutls/tests master$ ./cve-2008-4989 ; echo $?
0
jas <at> mocca:~/src/gnutls/tests master$

This will part of future releases to test regressions:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=4d0486baaf9d65d965ecefd38647f4518bf0d0d7

/Simon

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel