GNU TLS 2.9.9 , sign/hash extension support

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

GnuTLS VirtualHost with properly signed certificates

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

Re: GnuTLS VirtualHost with properly signed certificates

Hi Brenton--

On 03/13/2010 02:11 PM, Brenton Taylor wrote:
> I can't seem to find any good documentation on the internet that can explain how 
> to use properly signed certificates with GnuTLS in my VirtualHost files.
> 
> Distro: Debian lenny
> Apache/2.2.9
> mod gnutls

I think your question is more about configuration the mod_gnutls apache
module than it has to do with the gnutls library.

The list you mailed (help-gnutls <at> gnu.org) is specifically related to the
gnutls library;   mod_gnutls is a separate project which happens to use
the gnutls library.

So you might have better luck getting an answer to your question from
someone on the mod_gnutls mailing list.

Here is information about mod_gnutls:

 http://www.outoforder.cc/projects/apache/mod_gnutls/

And here is the mailing list for mod_gnutls:

 http://lists.outoforder.cc/mailman/listinfo/modules

hope this helps!

	--dkg

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

GnuTLS 2.8.6

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

GnuTLS is a modern C library that implements 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.3 (or later).

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

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

** libgnutls: For CSRs, don't null pad integers for RSA/DSA value.
VeriSign rejected CSRs with this padding.  Reported by Wilankar Trupti
<trupti.wilankar <at> hp.com> and Boyan Kasarov <bkasarov <at> gmail.com>.

Note: As a side effect of this change, the "public key identifier"
value computed for a certificate using this version of GnuTLS will be
different from values computed using earlier versions of GnuTLS.

** libgnutls: For CSRs on DSA keys, don't add DSA parameters to the
** optional SignatureAlgorithm parameter field.
VeriSign rejected these CSRs.  They are stricly speaking not needed
since you need the signer's certificate to verify the certificate
signature anyway.  Reported by Wilankar Trupti
<trupti.wilankar <at> hp.com> and Boyan Kasarov <bkasarov <at> gmail.com>.

** libgnutls: When checking openpgp self signature also check the signatures
** of all subkeys.
Ilari Liusvaara noticed and reported the issue and provided test
vectors as well.

** libgnutls: Cleanups and several bug fixes.
Found by Steve Grubb and Tomas Mraz.

** Link libgcrypt explicitly to certtool, gnutls-cli, gnutls-serv.

** Fix --disable-valgrind-tests.
Reported by Ingmar Vanhassel in
<https://savannah.gnu.org/support/?107029>.

** examples: Use the new APIs for printing X.509 certificate information.

** Fix build failures on Solaris.
Thanks to Dagobert Michelsen <dam <at> opencsw.org>.

** i18n: Updated Czech, Dutch, French, Polish, Swedish and Vietnamese
** translations.  Added Simplified Chinese translation.

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/≥.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.2MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.8.6.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2011-03-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <jas <at> extundo.com>
uid                  Simon Josefsson <simon <at> josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

bff911d4fd7389aa6698a644b3748eb2d23715bc  gnutls-2.8.6.tar.bz2
a6b36fa1926a7fd3cb68746446c29dc1cbef0cc6bcfd25877fde64ad  gnutls-2.8.6.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

For developers interested in improving code quality, we publish
Cyclomatic code complexity charts that help you find code that may need
review and improvements:

  http://www.gnu.org/software/gnutls/cyclo/

Also useful are code coverage charts which indicate parts of the source
code that needs to be tested better by the included self-tests:

  http://www.gnu.org/software/gnutls/coverage/

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer includes
libgpg-error v1.7, libgcrypt v1.4.5, libtasn1 v2.4, and GnuTLS v2.8.6.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.8.6.exe (16MB)
  http://josefsson.org/gnutls4win/gnutls-2.8.6.exe.sig

The checksum values for SHA-1 and SHA-224 are:

cbfc717d33edbc1f6eb891e14e5d6935bcfb7dc6  gnutls-2.8.6.exe
42e5bc23dd110de93f36d1e4e13447083d4127e1da18b190f02b4031  gnutls-2.8.6.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.8.6.zip (5.3MB)
  http://josefsson.org/gnutls4win/gnutls-2.8.6.zip.sig

The checksum values for SHA-1 and SHA-224 are:

5009ea643cad906e86ec85d3d3814ac78a73e66a  gnutls-2.8.6.zip
965b5c535956ea8f8b0d93b3badd1ce23d21624a6fa35a05fa20919f  gnutls-2.8.6.zip

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.6-1_all.deb (4.8MB)

The checksum values for SHA-1 and SHA-224 are:

8719083d715ad5f244265bfeebedf491112f6a8a  mingw32-gnutls_2.8.6-1_all.deb
ef6b6b927968ea393ee3571a649d325232c33ee92335eaf2dc090c55  mingw32-gnutls_2.8.6-1_all.deb

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Malay, Polish, Swedish, and Vietnamese.  We welcome the
addition of more translations.

Support
=======

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.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon

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

Re: safe renegotiation in client side

Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:

> Given your experiences (as system packager, user, implementor or so),
> what do you think is the adoption of priority strings in programs?

I find it quite rare still, sadly.  I don't recall _any_ application
that allows users to configure priority strings per-IP address, which
would be the optimal approach.

I believe it would be painful to release a GnuTLS client that refused to
talk to non-patched servers.  If I understand correctly, it doesn't
improve anything for the client to behave like that, it is only the
server that is protected by such a client.  Thus, I think we should let
servers require patched clients when it makes sense, and otherwise be
more lenient on the client side.

I wish there was an easy way to warn the user somehow though.  Syslog a
message with the server hostname?  Should we add a function so that
applications can find out if a session is potentially insecure due to
this threat?  Any way to make it less specific to renegotiation issues?
We have other areas that users may want to be aware of too -- e.g., if
the connection is using a weak cipher, if the connection is not using
DHE, etc...  OTOH maybe this is overkill.  Power-users can use
gnutls-cli to find out manually, and other users are probably fine with
a lenient default anyway.

/Simon

Re: safe renegotiation in client side

On 03/15/2010 06:33 PM, Simon Josefsson wrote:
> Right.  But it is the server that makes the mistake of assuming that the
> newly negotiated client credentials has anything to do with the earlier
> request, isn't it?

yes, that's true, but it's true at the application layer which the TLS
implementation (and any client) can't actually know anything about.

basically, TLS without safe renegotiation has the property that any
single ongoing connection stream may in fact consist of a series of
communications with unrelated remote parties.  This property was
apparently surprising to most application developers, who were relying
on the presumed semantics that the remote endpoint in a TLS connection
would always be the same entity.

"safe renegotiation" enforces this presumed semantics.  If you're
communicating with an endpoint that does not support safe-reneg, it is
unsafe to assume those semantics hold (and so your current connection
might be part of a larger aggregated series of connections of which you
are unaware, with whatever consequences that might have on the remote peer).

> To me, the renegotiation protocol flaw means that any server that uses
> renegotiation MUST require support for safe-renegotiation in the client.
> This is a critical security issue with the server that needs to be
> addressed as quickly as possible.  I don't see any critical security
> issue on the client side at all.  The only reason clients needs to be
> upgraded is that without clients, servers will be unable to use
> renegotiation.

But clients have no way of knowing that their connections won't be seen
as part of a larger aggregate connection unless they are confident that
the server supports safe-reneg.  A client who wants to protect their
session from such a situation does need to "fail closed" when talking to
an incompatible server.

> Right, if a client has a policy of not talking to any potentially buggy
> server, this makes sense.  But I'm not sure that is useful -- servers
> are potentially buggy all the time (many still only supports SSL 3.0),
> but clients still wants to talk to them.

yup.  but if they want to talk to them with any particular security
guarantees, they need to fail to connect to peers which cannot negotiate
those security guarantees.

If you're willing to sacrifice the security guarantees (confidentiality,
authenticity, etc) for the same of just connecting, why use TLS in the
first place?

> Couldn't we be lenient today, and in 2-3 years time start to reject
> buggy servers by default?

yes, we could (though i hope that it won't be 3 years before that
happens).  I don't think that would be the worst policy to take.

But any popular TLS client implementation also plays a role in spurring
adoption of safe-reneg among servers by its choice of enforcement (and
warning messages, etc).  I'd like to see GnuTLS contribute to the "peer
pressure" here in some positive way.  i'm not saying that
default-fail-closed is necessarily the best way to do that, but an
entirely lenient policy is pretty weak on the peer pressure side and
doesn't contribute to the overall security of network communications in
general.

	--dkg

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

handshaking takes too long (although, session resuming *seems* to work)

[first: sorry for cross-posting, I accidentally posted into gnutls-devel
and wondered WTF my message doesn't arrive at help-gnutls :)]

Hey,

i've just implemented SSL in my little web server, however, the
handshaking tooks quite long, so I added session resuming to it (based on
the example code I found in the sources), and added some debug prints to
see whether they're actually invoked.

What I now see, is, that on first (client web browser) connect, a record
gets stored my cache, and on the second call, I successively return this
data back to gnutls, however, the session resuming still takes as much
time as on the first request.

I've tested it on my netbook (quite thin hardware, though), and there it
takes about 2.5 seconds. still too long even without session resuming?
Compared to Apache, even the first request responded quite instant.

But what could the reasons be?

Thanks in advance,
Christian Parpart.

Re: handshaking takes too long (although, session resuming *seems* to work)

On Tue, Mar 16, 2010 at 3:19 PM, Christian Parpart <trapni <at> gentoo.org> wrote:

> What I now see, is, that on first (client web browser) connect, a record
> gets stored my cache, and on the second call, I successively return this
> data back to gnutls, however, the session resuming still takes as much
> time as on the first request.

Does your client support session resumption? It has to be supported by both to
be effective. If you use gnutls-cli add the --resume option.

> I've tested it on my netbook (quite thin hardware, though), and there it
> takes about 2.5 seconds. still too long even without session resuming?
> Compared to Apache, even the first request responded quite instant.

Different algorithms in gnutls have different speeds. The defaults are sorted
on a security margin and speed was not a concern. Check the priority functions
documentation for more information.

regards,
Nikos

Re: safe renegotiation in client side

On Tue, Mar 16, 2010 at 1:02 PM, Simon Josefsson <simon <at> josefsson.org> wrote:

> I'll do some experiments with 2.9.10 on my machine... maybe best to get
> a release out first though.

At least in my system I couldn't do basic stuff (use svn over ssl) and
couldn't find any
fix for those (except changing gnutls). I no longer use openldap to
login in my system, but
I remember this also doesn't provide access to priority strings, which
would also cause a denial of
service. I'm also leaning towards having the first releases without
enforced safe renegotiation and
enforcing it at a later time that does not cause more trouble than it solves.

Debug strings warning about that are now being printed via the gnutls
logging, but are not visible
in most applications (and even if it was might not offer any
information to a typical user since it
will be issued for almost every server today). What we can do is add a
warning on the gnutls-cli
if the server does not support safe renegotiation? (gnutls-cli-debug
can also detect that).

regards,
Nikos

Re: handshaking takes too long (although, session resuming *seems* to work)

Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:

> On Tue, Mar 16, 2010 at 3:19 PM, Christian Parpart <trapni <at> gentoo.org> wrote:
>
>> What I now see, is, that on first (client web browser) connect, a record
>> gets stored my cache, and on the second call, I successively return this
>> data back to gnutls, however, the session resuming still takes as much
>> time as on the first request.
>
> Does your client support session resumption? It has to be supported by both to
> be effective. If you use gnutls-cli add the --resume option.
>
>> I've tested it on my netbook (quite thin hardware, though), and there it
>> takes about 2.5 seconds. still too long even without session resuming?
>> Compared to Apache, even the first request responded quite instant.
>
> Different algorithms in gnutls have different speeds. The defaults are sorted
> on a security margin and speed was not a concern. Check the priority functions
> documentation for more information.

A 2.5 second delay strongly suggest something outside GnuTLS is causing
the delays though.  I'm using mod_gnutls under Apache on a few
production systems and it is comparable in speed to mod_ssl.

/Simon