Manish Patidar | 8 Mar 18:03 2010
Picon

GNU TLS 2.9.9 , sign/hash extension support

Hi ,

I was going through the GNU TLS 2.9.9 source code that support TLS 1.2. 
I have following doubts in gnutls that support of TLS 1.2 rfc

1. While selecting server cert and chain,  GNUTLS just compare server certificate with client requested sign/hash extension, not the whole chain.
    if it matched one of the server certificate , it will select the chain.
    but according to TLS 1.2 , whole chain must matched with one of the sign/hash algo supported by client.

    Is my understanding is correct ..?
  
    If not , how and which part of code GNU TLS compare the sign/hash algo with the whole chain.

2. While selecting client cert list in response of client cert request, GNU TLS doesn't use parsed sign/hash algo supported server.
    it just use the cert type and dns name for selecting cert chain ,not sign/hash algo 
    but according to TLS 1.2 , client must compare and select cert chain that matches with one of the sign/hash supported by server. 


    Please let me know if am correct or not.

    Please provide some of your valuable inputs which clarify above point 
 
Regards
Manish
 

_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnutls
Brenton Taylor | 13 Mar 20:11 2010
Picon

GnuTLS VirtualHost with properly signed certificates

Hello everyone,

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


This works good with a self signed certificate:

<VirtualHost *:443>
  GnuTLSEnable on
  ServerName www.brentontaylor.net.au
  GnuTLSPriorities NORMAL
  GnuTLSCertificateFile "/etc/ssl/certs/www.brentontaylor.net.au.crt"
  GnuTLSKeyFile "/etc/ssl/certs/www.brentontaylor.net.au.key"
  DocumentRoot "/var/www/store/it
</VirtualHost>

But I need to convert the following to work with GnuTLS

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol all -SSLv2
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
  SSLCertificateFile "/etc/ssl/certs/www.brentontaylor.com.au.crt"
  SSLCertificateKeyFile "/etc/ssl/certs/www.brentontaylor.com.au.no_enc.key"
  SSLCertificateChainFile "/etc/ssl/certs/www.brentontaylor.com.au.sub.class1.server.ca.pem"
  SSLCACertificateFile "/etc/ssl/certs/www.brentontaylor.com.au.ca.pem"
  SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
  ServerName www.brentontaylor.net.au
  DocumentRoot "/var/www/store/it
</VirtualHost>

Regards,
Brenton Taylor

PS: this is the second time I've used a mailing list :)

Send instant messages to your online friends http://au.messenger.yahoo.com

_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnutls
Daniel Kahn Gillmor | 14 Mar 01:14 2010
Picon

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
Simon Josefsson | 15 Mar 14:23 2010

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
Simon Josefsson | 15 Mar 14:44 2010

GNU Libtasn1 2.5

GNU Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding/decoding.  GNU Libtasn1 is used by
GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos
V5 structures.

* Noteworthy changes in release 2.5 (2010-03-15) [stable]
- doc: Improve GTK-DOC comments.
- misc: Updated gnulib files.

Homepage:
  http://www.gnu.org/software/libtasn1/

Here are the compressed sources (1.7MB):
   ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz
   http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz

Here are GPG detached signatures using key 0xB565716F:
   ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig
   http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig

A ZIP archive containing the Windows binaries (264KB):
  http://josefsson.org/gnutls4win/libtasn1-2.5.zip
  http://josefsson.org/gnutls4win/libtasn1-2.5.zip.sig

A Debian mingw32 package is also available (240KB):
  http://josefsson.org/gnutls4win/mingw32-libtasn1_2.5-1_all.deb

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

If you need help to use Libtasn1, or want to help others, you are
invited to join the help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

All manuals are available from:
  http://www.gnu.org/software/gsasl/manual/

Specifically, the following formats are available.

The main manual:
  HTML: http://www.gnu.org/software/gsasl/manual/gsasl.html
  PDF: http://www.gnu.org/software/gsasl/manual/gsasl.pdf

API Reference manual:
  http://www.gnu.org/software/gsasl/reference/ - GTK-DOC 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/

The software is cryptographically signed by the author using an
OpenPGP key identified by 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

Here are the SHA-1 and SHA-224 checksums:

e317282a86702fb57133b50199df47a7fcf681ca  libtasn1-2.5.tar.gz
69e53bb61f3512aa8d1eb72640778b4adebf6818a4493548cc7faf2d  libtasn1-2.5.tar.gz

784faa0f4aff35aee1ac420013a9e47aa4892d12  libtasn1-2.5.zip
98177b4e5cbc3bae34dd7813940bec99c802275c9dd0cb77f06a1d3d  libtasn1-2.5.zip

a5427f26d051a3ab30a8f5bea0abcdf6d3d83f0f  mingw32-libtasn1_2.5-1_all.deb
6e781ec4652f8d3fd58e3742dd19f69804665356c11c50e179ed1756  mingw32-libtasn1_2.5-1_all.deb

Happy hacking,
Simon
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel
Nikos Mavrogiannopoulos | 15 Mar 21:46 2010

safe renegotiation in client side

As you may have noticed there was a big fuss lately about a bug in the
TLS protocol that could cause a client to connect to the wrong server
via a renegotiation. There is a fix to the protocol that is
unfortunately incompatible with previous versions (if security is
required). Thus a gnutls client implementing the fix cannot connect to
any non-patched server[0]. To achieve compatibility one has to to
explicitly allow unsafe renegotiation with a priority string. This is
not always possible since gnutls might be used unintentionally by a
program via another library.

With some trials in my system I noticed that the current behavior causes
denial of service and a simple user might not even have control over the
priority string for gnutls.

Given your experiences (as system packager, user, implementor or so),
what do you think is the adoption of priority strings in programs? Given
a program that uses gnutls is it easy to set a string with the
algorithms etc. needed for the negotiation?

I have been in favor of enabling safe renegotiation for the client
before, but seeing how gnutls is being used today, I might have not been
correct and enabling it might cause more trouble than the issue it solves.

Please let me know of what you think.

regards,
Nikos

[0]. so far the fix adoption wasn't that great.
Simon Josefsson | 15 Mar 22:00 2010

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
Daniel Kahn Gillmor | 15 Mar 22:30 2010
Picon

Re: safe renegotiation in client side

On 03/15/2010 05:00 PM, Simon Josefsson wrote:
> I believe it would be painful to release a GnuTLS client that refused to
> talk to non-patched servers.

I agree that it would be painful.

> 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.

I don't think this is the case.  A client connecting to an unpatched
server is vulnerable to their connection being used to authenticate
another request that they are unaware of.

The attack in question is a plaintext prefix injection attack: the
attacker starts a session with the server, and then prompts a
re-negotiation.  It hands off the re-negotiation to the actual client,
which might then negotiate to the server thinking that it is the initial
connection (not a re-negotiation).  If the server then uses the new
connections credentials to act on the original (spoofed) part of the
session, it is the *client's* credentials which have been mis-applied,
not the server's.

clients which "fail closed" by rejecting connections to unpatched
servers cannot have their credentials mis-applied in this way.   (they
also won't be able to talk to the majority of the TLS-capable hosts on
the 'net today, unfortunately).

> Thus, I think we should let
> servers require patched clients when it makes sense, and otherwise be
> more lenient on the client side.

libnss (the mozilla tls implementation) has an interesting phased
approach planned to deal with this situation:

  https://wiki.mozilla.org/Security:Renegotiation

i know gnutls doesn't expose as much in the way of a UI as NSS clients
like firefox or thunderbird; but if there's some way to adopt a similar
approach, i'd like to examine it.

Every libgnutls-aware program can see the environment, for example.  is
using a clearly-scoped environment variable to provide a priority string
if none other are supplied out of the question?  Or what about
~/.libgnutls/config or something similar?  I'm just brainstorming here,
feel free to explain why these are horrible proposals.

> 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.

gnutls-cli can find out manually for a different connection -- it won't
let you inspect an active connection, will it?

i agree that configurable reporting would be useful, though (and i like
your assessment of the other concerns we might want to permit but warn
about).  Seems like a generic interface would be a way for library users
register a callback that reports "warnings about your connection", along
with an enumerated list (and maybe localized strings describing the
problems).

I like that idea, but if we can't convince application developers to let
end users pass in a priority string, it seems unlikely that we'd get
them to register such a callback, let alone report the warnings to their
users in a sane way :/

	--dkg

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel
Tomas Mraz | 15 Mar 22:31 2010
Picon

Re: safe renegotiation in client side

On Mon, 2010-03-15 at 21:46 +0100, Nikos Mavrogiannopoulos wrote: 
> As you may have noticed there was a big fuss lately about a bug in the
> TLS protocol that could cause a client to connect to the wrong server
> via a renegotiation. There is a fix to the protocol that is
> unfortunately incompatible with previous versions (if security is
> required). Thus a gnutls client implementing the fix cannot connect to
> any non-patched server[0]. To achieve compatibility one has to to
> explicitly allow unsafe renegotiation with a priority string. This is
> not always possible since gnutls might be used unintentionally by a
> program via another library.
> 
> With some trials in my system I noticed that the current behavior causes
> denial of service and a simple user might not even have control over the
> priority string for gnutls.
> 
> Given your experiences (as system packager, user, implementor or so),
> what do you think is the adoption of priority strings in programs? Given
> a program that uses gnutls is it easy to set a string with the
> algorithms etc. needed for the negotiation?

The OpenSSL upstream decided to allow the client to talk to the
unpatched servers by default. Of course it means that if the client
talks to such server it is vulnerable to the attack. They've also added
a function call so an application can query whether the connection is
protected by the safe renegotiation or not.

I, as maintainer of OpenSSL and gnutls packages in Fedora and Red Hat
Enterprise Linux, decided when backporting the safe renegotiation
patches to the old gnutls packages in released distributions, that the
client has to be tolerant to missing safe renegotiation support on
connected servers for now and so I have removed the strict client side
check from the backported patches. If the adoption of the safe
renegotiation extension gets better, we will release updated packages
which will contain the strict client side check.
--

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
Simon Josefsson | 15 Mar 23:33 2010

Re: safe renegotiation in client side

Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:

>> 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.
>
> I don't think this is the case.  A client connecting to an unpatched
> server is vulnerable to their connection being used to authenticate
> another request that they are unaware of.
>
> The attack in question is a plaintext prefix injection attack: the
> attacker starts a session with the server, and then prompts a
> re-negotiation.  It hands off the re-negotiation to the actual client,
> which might then negotiate to the server thinking that it is the initial
> connection (not a re-negotiation).  If the server then uses the new
> connections credentials to act on the original (spoofed) part of the
> session, it is the *client's* credentials which have been mis-applied,
> not the server's.

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?

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.

> clients which "fail closed" by rejecting connections to unpatched
> servers cannot have their credentials mis-applied in this way.   (they
> also won't be able to talk to the majority of the TLS-capable hosts on
> the 'net today, unfortunately).

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.

>> Thus, I think we should let
>> servers require patched clients when it makes sense, and otherwise be
>> more lenient on the client side.
>
> libnss (the mozilla tls implementation) has an interesting phased
> approach planned to deal with this situation:
>
>   https://wiki.mozilla.org/Security:Renegotiation
>
> i know gnutls doesn't expose as much in the way of a UI as NSS clients
> like firefox or thunderbird; but if there's some way to adopt a similar
> approach, i'd like to examine it.
>
> Every libgnutls-aware program can see the environment, for example.  is
> using a clearly-scoped environment variable to provide a priority string
> if none other are supplied out of the question?  Or what about
> ~/.libgnutls/config or something similar?  I'm just brainstorming here,
> feel free to explain why these are horrible proposals.

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

>> 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.
>
> gnutls-cli can find out manually for a different connection -- it won't
> let you inspect an active connection, will it?

Right, I'm just thinking of how to identify buggy/working servers.

> i agree that configurable reporting would be useful, though (and i like
> your assessment of the other concerns we might want to permit but warn
> about).  Seems like a generic interface would be a way for library users
> register a callback that reports "warnings about your connection", along
> with an enumerated list (and maybe localized strings describing the
> problems).
>
> I like that idea, but if we can't convince application developers to let
> end users pass in a priority string, it seems unlikely that we'd get
> them to register such a callback, let alone report the warnings to their
> users in a sane way :/

I agree, so it seems like a waste of time right now. :-(

/Simon

Gmane