Re: Gnutls and secure renegotiation / CVE-2009-3555 / RFC 5746

2010-12-18 Thread Julien Cristau
On Wed, Dec  8, 2010 at 09:07:30 +0100, Stefan Fritsch wrote:

 OK. I think the best way forward is this:
 
 - We will not include gnutls in the first round of RFC5746-DSAs for 
 Lenny, which I hope to release before Christmas.
 - gnutls in squeeze will be updated by backport to 2.8.6 rather than 
 by upgrading to 2.10. This will happen as soon as someone has the time 
 to do the testing. IMHO, this can also be done in a DSA or point 
 release and should not delay squeeze's release.
 - When the backport+testing for 2.8.6 is done, we can decide about 
 what to do with 2.4.2 in Lenny.
 
Thanks for the summary.

Cheers,
Julien


signature.asc
Description: Digital signature


Re: Gnutls and secure renegotiation / CVE-2009-3555 / RFC 5746

2010-12-08 Thread Stefan Fritsch
On Tuesday 07 December 2010, Simon Josefsson wrote:
  But Suse has released updates for 2.4.1 and 2.8.6 [2]. I have put
  the extracted source rpms at [3]. The patches are huge but 80%
  seem to be the test suite. [3] contains two versions of each,
  the older one is the released package and the newer one is
  unreleased but has additional fixes.
  
  My current feeling is that we will just skip gnutls for the first
  round of Lenny-DSAs that add RFC5746 support. We can reconsider
  later if it causes many problems for users. Therefore patching
  squeeze has definitely higher priority. If you have time, it
  would be great if you could look at the patches.
 
 If back-ported patches are contributed back upstream (this is the
 first time I heard about Suse's work) we can do an semi-official

The release happened only a few days ago.

 release for 2.8.x with the renegotiation support.  However I don't
 have any free time to do serious checking of the old 2.8.x branch,
 so it will be all up to whoever does the work here to make sure it
 is working correctly.

OK. I think the best way forward is this:

- We will not include gnutls in the first round of RFC5746-DSAs for 
Lenny, which I hope to release before Christmas.
- gnutls in squeeze will be updated by backport to 2.8.6 rather than 
by upgrading to 2.10. This will happen as soon as someone has the time 
to do the testing. IMHO, this can also be done in a DSA or point 
release and should not delay squeeze's release.
- When the backport+testing for 2.8.6 is done, we can decide about 
what to do with 2.4.2 in Lenny.

Cheers,
Stefan


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201012080907.30957...@sfritsch.de



Re: Gnutls and secure renegotiation / CVE-2009-3555 / RFC 5746

2010-12-07 Thread Simon Josefsson
Stefan Fritsch s...@sfritsch.de writes:

 Putting debian-release on cc, they may want to comment.

 On Monday 06 December 2010, Andreas Metzler wrote:
 On 2010-12-05 Stefan Fritsch s...@sfritsch.de wrote:
  we are currently working on an upgrade for openssl and nss in
  lenny to support secure renegotiation. Do you have some
  plan/idea how to deal with Gnutls?
  
  Do you know any server or client software using gnutls in Debian
  that supports session renegotiation? As a client I have tried
  libcurl-gnutls via pycurl but I couldn't get client cert
  authentication with renegotiation to work.
 
 Could you retry with gnutls 2.10.x?

 Will do when I have time, but I suspect the problem is in libcurl. 
 AFAIK, gnutls consumers need to have special support for 
 renegotiation.

I searched for clients that supports renegotiation, and I think the only
client with proper renegotiation support is gnutls-cli.  Curl doesn't
have it, or at least it didn't when I looked.

 But Suse has released updates for 2.4.1 and 2.8.6 [2]. I have put the 
 extracted source rpms at [3]. The patches are huge but 80% seem to be 
 the test suite. [3] contains two versions of each, the older one is 
 the released package and the newer one is unreleased but has 
 additional fixes.

 My current feeling is that we will just skip gnutls for the first 
 round of Lenny-DSAs that add RFC5746 support. We can reconsider later 
 if it causes many problems for users. Therefore patching squeeze has 
 definitely higher priority. If you have time, it would be great if you 
 could look at the patches.

If back-ported patches are contributed back upstream (this is the first
time I heard about Suse's work) we can do an semi-official release for
2.8.x with the renegotiation support.  However I don't have any free
time to do serious checking of the old 2.8.x branch, so it will be all
up to whoever does the work here to make sure it is working correctly.

/Simon


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tyiqype8@latte.josefsson.org



Re: Gnutls and secure renegotiation / CVE-2009-3555 / RFC 5746

2010-12-06 Thread Stefan Fritsch
Putting debian-release on cc, they may want to comment.

On Monday 06 December 2010, Andreas Metzler wrote:
 On 2010-12-05 Stefan Fritsch s...@sfritsch.de wrote:
  we are currently working on an upgrade for openssl and nss in
  lenny to support secure renegotiation. Do you have some
  plan/idea how to deal with Gnutls?
  
  Do you know any server or client software using gnutls in Debian
  that supports session renegotiation? As a client I have tried
  libcurl-gnutls via pycurl but I couldn't get client cert
  authentication with renegotiation to work.
 
 Could you retry with gnutls 2.10.x?

Will do when I have time, but I suspect the problem is in libcurl. 
AFAIK, gnutls consumers need to have special support for 
renegotiation.

 
  As a server, I think apache/mod_gnutls should
  work, but I haven't tried that yet.
  
  Given that browser vendors are very likely to lock out
  non-RFC5746- conforming servers during the livetime of squeeze,

I have read a bit more and this may have been overly pessimistic. We 
have received mails from Opera that they will do that next year, but 
other browser vendors will likely be slower. For example, [1] seems to 
indicate that mozilla will only disable legacy _re_negotiation in 3.7, 
which would not be that big a problem. They would completely disable 
negotiation to legacy servers only later (cite: eventually, if enough 
sites have been upgraded to the new protocol versions).

  we need at least support in squeeze. But if it's not too
  difficult, I would like to see support in lenny, too.
 
 Hello,
 
 RFC 5746 support was introduced in the development reals 2.9.10, it
 is one of the major selling points of 2.10.x stable release over
 2.8.x. I was not aware on how important the feature was, otherwise
 I would have tried pushing 2.10.x into squeeze.
 
 Upstream probably will not backport this for 2.8.x (which is what
 we might end up with in squeeze) or 2.4.x. They have not got an
 abundance of manpower. I am lacking the skills. So I think lenny
 is out of question.
 
 I can still try to get this into squeeze, if it your best jugdement
 that it is a critical feature. It should not be a very painful
 transition (shlibs bump, but no soname bump).

The release team would probably kill us for just suggesting it :-/

But Suse has released updates for 2.4.1 and 2.8.6 [2]. I have put the 
extracted source rpms at [3]. The patches are huge but 80% seem to be 
the test suite. [3] contains two versions of each, the older one is 
the released package and the newer one is unreleased but has 
additional fixes.

My current feeling is that we will just skip gnutls for the first 
round of Lenny-DSAs that add RFC5746 support. We can reconsider later 
if it causes many problems for users. Therefore patching squeeze has 
definitely higher priority. If you have time, it would be great if you 
could look at the patches.

Cheers,
Stefan

 cu andreas
 
 http://article.gmane.org/gmane.network.gnutls.general/2046

[1] https://wiki.mozilla.org/Security:Renegotiation
[2] http://lwn.net/Articles/418864/
[3] http://www.sfritsch.de/~stf/suse-gnutls/


signature.asc
Description: This is a digitally signed message part.