Friedrich Delgado Friedrichs <[email protected]> writes: > reassign 530510 libneon27-gnutls > found 530510 0.28.4-1 > thank you > > Ok, I hope it's all correct now. I'm terribly sorry for the noise!
No problem, we want to help but there is a history of a tendency in the GnuTLS package that reporters group together different problems and it is very time consuming to sort out. So I'd prefer to not merge any problem unless we have confirmed that it really is the same problem. > Simon Josefsson schrieb: >> Can you explain how these bug reports suggests there is a bug in the >> GnuTLS packages? > > I'm staying with libneon27-gnutls now, unless you agree that it may be > a gnutls bug. > > The core of the problem is described in 530510, let me rephrase: > > With libneon24-gnutls version 0.28.4-1 authentication with client > certificates breaks on some servers. > > e.g. svn ls https://my-repo.dom/svn/project/ fails with > > svn: OPTIONS von »https://my-repo.dom/svn/project/«: SSL negotiation > failed: SSL error: Key usage violation in certificate has been > detected. (https://my-repo.dom/svn/project/) This is often a simple administrator problem: the cert needs to have the proper key usage bits in order to be useful as a TLS client/server cert. Try and reproduce using the gnutls-cli tool, that will help isolate whether this is a GnuTLS or administrator or svn problem. > Downgrading to libneon24-gnutls 0.28.2-6.1+b1 seemed to fix the > problem at first, but I discovered today that it fails against a > different server. That is odd, but it is possible that earlier versions didn't check the certs properly, or that it used a non-DHE cipher suite which doesn't have the same key usage bit requirements. > There is an old bug which would explain that behaviour with the old > version of libneon-gnutls: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474139 Which of those problems? Again there seem to be very different problem reported in that bug report. This has happened for GnuTLS before too, so I understand and share your pain in trying to sort things out. > So I had to find a way to make both servers work. > > I was confused because the same fix seems to help against 480041 and > the ubuntu bug > https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648, > namely > > alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn' > > But this seems to suggest to me that the problem only occurs when > libneon is linked against gnutls, hence the reassignment. It can also be a libneon problem -- the GnuTLS and OpenSSL code in neon is quite large and very different. Anyway, just because that workaround solves a problem doesn't (necessarily) mean there is a bug in either neon or GnuTLS. It needs to be debugged. > Unfortunately I can't provide client certificates for testing. Any > idea how to make this bug reproducible? One first step is to try and reproduce the problem with gnutls-cli instead of svn/libneon. Try '-d 4711' to get more debug information from GnuTLS. If that fails, you can always try to create dummy client/server/CA certificates that has the same key usage bits, extensions, etc, and set that up on a public server and ask us to test against it. >> To me, 480041 looks like a fairly common administrator problem. 530510 >> looks like it contains all sorts of problems, many of them were reported >> solved. I cannot find any succinct problem description describing a >> GnuTLS issue, but due to the length of the bug I didn't read it all. > > 480041 describes a lot of different problems. I shouldn't have merged > it with this bug. However the solution provided in the ubuntu bug > linked from there works as a fix for the "Key usage violation" I see > here. > > I assume you meant 530510 describes a common administrator problem? I > can't see which you mean. Yes. The administror problem is that you are trying to use a server or client cert with a DHE ciphersuite without having the necessary key usage bits (i.e., signing_key) asserted in the certificate. Can you print just the "key usage" portion of the certificates, to confirm this theory? >> I suspect some of the problem may have been triggered by the recent >> OpenSSL security advisory that disables TLS renegotiation, which is >> often used with client certificates. > ---Zitatende--- > > I reported 530510 in May 2009, Bug 480041 refers to renegotiation, but > it's much older than the OpenSSL security advisory you refer to, > assuming you mean http://www.openssl.org/news/secadv_20091111.txt Right. Ok, let's hope we don't have that to worry about. /Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
