svn over https with client certificates broken (regression in intrepid)

[Anton Gyllenberg]

Binary package hint: subversion

After upgrading from hardy to intrepid, svn with https client certificates authentication stopped working, giving the following error:

user@testhost:~$ svn info https://svn.example.org/svn/main/
svn: OPTIONS of 'https://svn.example.org/svn/main': Could not read status line: SSL error: Rehandshake was requested by the peer. (https://svn.example.org)

This is against an apache2 server with
<Location /svn>
          SSLVerifyClient require
...

If I set "SSLVerifyClient none" everything just works, hence the conclusion that this is related to client certificate verification. I have configured my svn client to use a pkcs#12 file.

This may be related to http://bugs.debian.org/480041

Version info:
subversion 1.5.1dfsg1-1ubuntu2
libneon27-gnutls 0.28.2-2build1

[Anton Gyllenberg (antong)]

I now found https://bugs.launchpad.net/hardy-backports/+bug/265065 which seems to be the same issue.

[Anton Gyllenberg (antong)]

There is a workaround described in the comments to https://bugs.launchpad.net/hardy-backports/+bug/265065, to use a PKCS#12 file without a CA certificate in it. However, I tried this and cannot get it to work.

[Jan Vissers (jan-vissers)]

I'm hitting a similar issue. However I get the following message upon 'ci' or any other operation that interacts with the repository.

svn: OPTIONS of 'http://********/repo/techupdate': SSL negotiation failed: SSL alert received: Unexpected message (https://********)

[Magnus Runesson (m-runesson)]

There is a backport for Hardy that solves this problem and works fine in Intrepid

See: http://theworldofapenguin.blogspot.com/2008/12/subversion-and-ssl.html

[Robert Coup (rcoup)]

@Magnus: I'm not sure "use the old version" is a real fix... ;)

The core problem seems to be subversion linking to libneon-gnutls.so.27 instead of libneon.so.27 - because GnuTLS is more picky/grumpy/broken than libssl, especially with respect to client certificates. This is the outcome I've gathered from the various Ubuntu and Debian bug reports on this topic, as linked from here/#265065.

Workaround I used successfully:
cd /usr/lib/
sudo rm libneon-gnutls.so.27
sudo ln -s /usr/lib/libneon.so.27 libneon-gnutls.so.27

[Onno Steenbergen (osteenbergen)]

Thx to Rick (https://launchpad.net/~rick-wzoeterwoude):

http://rickvanderzwet.blogspot.com/2008/12/ubuntu-810-subversion-ssl-libary.html

This works for me. SVN works with the new P12 file created by his instructions

[Magnus Runesson (m-runesson)]

@Robert; Note that the hardy backport is the same version as in Intrepid plus some fixes.

See the log at: https://launchpad.net/ubuntu/+source/subversion

[Anton Gyllenberg (antong)]

I can confirm that the problem goes away when replacing libneon-gnutls.so.27 with /usr/lib/libneon.so.27. Recreating the p12 with gnutls did not help. Also, I don't even get a p12 passphrase prompt when using the gnutls version of the library.

[Andreas Jellinghaus (tolonuga)]

Downgrading my intrepid subversion and libsvn1 packages to the hardy-packports situation solved the problem for me as well.
please fix the subversion packages in intrepid.

my setup: hardy server, apache2 with subversion, with optional client certificates, but for the write operations they are required.
this did not work with the intrepid subversion client (which works well, if the client certificates are required, but not if they are optoinal, and apache+subversion client need to re-negotiate the ssl session). this setup worked for a long time with apache and subversion, and was now broken after several years with the new subversion in intrepid.

[Craig Ringer (ringerc)]

This has been reliably reproduced with the Ubuntu packages and with the underlying packages from Debian. It's still an issue in Intrepid. Flagging "confirmed" unless someone objects.

[Craig Ringer (ringerc)]

Rebuild the subversion package against the version of libneon that's linked to openssl rather than gnutls to work around this issue. Instructions (run as a normal user, NOT AS ROOT):

$ mkdir -p tmp && cd tmp
$ apt-get source subversion
$ apt-get build-dep subversion
$ apt-get install fakeroot libneon26-dev
$ cd subversion-1.5.1dfsg1
$ DEB_BUILD_OPTIONS="nocheck no-javahl no-apache no-ruby" fakeroot debian/rules binary
$ sudo dpkg -i ../libsvn1_1.5.1dfsg1-1ubuntu2_i386.deb ../subversion_1.5.1dfsg1-1ubuntu2_i386.deb ../subversion-tools_1.5.1dfsg1-1ubuntu2_all.deb

You should now see that the subversion binary is linked to libneon not libneon-gnutls:

$ ldd `which svn` | grep neon
 libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 (0xb7d40000)
 libneon.so.26 => /usr/lib/libneon.so.26 (0xb7d21000)

... and it should work correctly when you connect to your client-certificate-protected repositories.

[ Note that you may want to remove the openjdk-6-jre and openjdk-6-jdk packages if they were installed by "apt-get build-dep subversion", especially if you use sun-java6-{jre,jdk} instead. If you don't use Java (or only use Java applets in your web browser), though, you probably don't care and can just ignore them. ]

[Mike Walton (mike-farsouthnet)]

I have a simpler workaround, that does not involve root privileges and messing with /usr/lib links.

alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'

This causes the non-GnuTLS library to be preloaded, which means the linker uses its symbols by preference. I added this to my .bashrc for seamless operation.

[Andrew Elwell (andrew-elwell)]

Still affects the jaunty RC -- but the LD_PRELOAD workaround in comment #14 works for me

[Alejandro Mery (amery)]

in intrepid, LD_PRELOAD worked around the problem.

[edlutz (edlutz)]

The problem still happens in Jaunty.
The LD_PRELOAD workaround does not work for me.

This is a MAJOR problem for my project. It might force us to drop Ubuntu.

[Robert Coup (rcoup)]

@edlutz: did you install the libneon27 package?

in which case, you should see the following when running ldd:
# the shell makes aliases work, so ldd won't setup the environment variable
$ ldd /usr/bin/svn | grep neon
        libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 (0x00002b936ab71000)
        libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0x00002b936ad94000)
# set it up explicitly
$ LD_PRELOAD=/usr/lib/libneon.so.27 ldd /usr/bin/svn | grep neon
        /usr/lib/libneon.so.27 (0x00002b435b90c000)
        libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 (0x00002b435d9db000)
        libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0x00002b435dbff000)

then add:
alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'
to /etc/profile to make it work for all users & shells

[Michael Diers (mdiers)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

edlutz wrote:
> The problem still happens in Jaunty.
> The LD_PRELOAD workaround does not work for me.
>
> This is a MAJOR problem for my project. It might force us to drop
> Ubuntu.

My PPA has builds that use OpenSSL instead of GNU TLS. Could you please
test those.

https://launchpad.net/~mdiers/+archive/svn16

- --
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iEYEAREDAAYFAkqylgsACgkQcEKlWnqVgz0i2wCfQDM2C2ZJgeCbsQnK+oQ5Gs0k
qGUAoIs5PWedDGsoB0rJjtJXJMcOfSnm
=Di2n
-----END PGP SIGNATURE-----

[edlutz (edlutz)]

Wow, that was fast! :) Thanks!

My results:

$ ldd /usr/bin/svn | grep neon
 libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 (0xb7dfc000)
 libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0xb7ddb000)

$ LD_PRELOAD=/usr/lib/libneon.so.27 ldd /usr/bin/svn | grep neon
 /usr/lib/libneon.so.27 (0xb7eec000)
 libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 (0xb7c36000)
 libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0xb7c15000)

It looks right. Then I tested the alias:
$ alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'
$ svn co https://<my project address>
Authentication realm: https://<my project address>:443
Client certificate filename: <certificate path>
Passphrase for '<certificate path>': <password>
svn: Server sent unexpected return value (501 Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet API ) in response to PROPFIND request for '<my project path>'

Note that it shouldn't even ask me for a certificate/password since that information is in ~/.subversion/servers.

I tried also other alternatives. Compile/ install the newest svn client with libneon 2.7 (similar results). With libneon 2.6 (same thing). With and without libneon-gnutls. No solution so far.

[edlutz (edlutz)]

I forgot to tell: my project lives in CollabNet.
Last year I worked on a project there without problems with Ubuntu 8.04, using https, certificates, etc.

Any ideas are wellcome.

Thanks!

[edlutz (edlutz)]

Thanks, Michael!

I hadn't seen your suggestion before my previous posts.

It looks like a brilliant idea.

I have followed the link, select the i386 item and 12 deb files appeared.
After downloading and trying to install (with dpkg), there were a lot of broken dependency problems.

I think I will have to follow the dependency network with more attention to get this working.

It is late in my timezone now and I have to stop working for now and continue tomorrow.

If this one works, it will be excellent, since I don't trust subversion 1.5 for some operations.

Thanks again!

[edlutz (edlutz)]

Duh! I didn't take the serf and other files! That was dumb!

Sorry!

I'll test that tomorrow.

[edlutz (edlutz)]

Here are my test results for Michael's PPA builds.

svn co https:... still asks for a client certificate ignoring the configuration files. I can live with that.

But then, the result is:
svn: OPTIONS of 'https://<my project>.csd200a.com/<path>': 200 OK (https://<my project>.csd200a.com)

It stops right there. No checkout happens.

We've made a lot of progress here, but we are not there yet. I'll review my environment/configuration.

Thanks for the help so far.

[edlutz (edlutz)]

Update: Michael's PPA builds work perfectly on my environment!

Many thanks for, Michael!

Checking everything, I've found out that the path to my project was incorrect. It is working now!

Next releases of Ubuntu should include solutions like that!

[Michael Diers (mdiers)]

edlutz wrote:
> Update: Michael's PPA builds work perfectly on my environment!
>
> Many thanks for, Michael!
>
> Checking everything, I've found out that the path to my project was
> incorrect. It is working now!
>
> Next releases of Ubuntu should include solutions like that!

Thanks for the feedback. Could you please give me the output of

svn --version

and perhaps the list of packages that you have installed?

COLUMNS=1234 dpkg -l | awk '/^ii / {print $2, $3}'

I'm only really interested in a subset of the ones that subversion uses,
so you may wish to crop that list:

egrep '(subversion|libsvn|libneon|libserf|libapr|openssl)'

--
Michael Diers, elego Software Solutions GmbH, http://www.elego.de

[Michael Diers (mdiers)]

edlutz wrote:
> Update: Michael's PPA builds work perfectly on my environment!

Oh, another thing: would you mind testing this using ra_serf instead of
ra_neon?

svn --config-option servers:global:http-library=serf \
  ls https://<my project>.csd200a.com/<path>

--
Michael Diers, elego Software Solutions GmbH, http://www.elego.de

[edlutz (edlutz)]

Just to explain how I chose the packages: I added the following entries to apt sources:

deb http://ppa.launchpad.net/mdiers/svn16/ubuntu jaunty main
deb-src http://ppa.launchpad.net/mdiers/svn16/ubuntu jaunty main

Then I installed the corresponding subversion package (1.6.5) (dependencies were handled by apt-get).

$ svn --version
svn, version 1.6.5 (r38866 w/ double-tc patch)
   compiled Sep 16 2009, 19:19:17

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme

List of installed packages (cropped):

libapr1 1.2.12-5ubuntu0.1
libapr1-dev 1.2.12-5ubuntu0.1
libapreq2 2.08-5build1
libapreq2-dev 2.08-5build1
libapreq2-doc 2.08-5build1
libaprutil1 1.2.12+dfsg-8ubuntu0.3
libaprutil1-dev 1.2.12+dfsg-8ubuntu0.3
libcrypt-openssl-x509-perl 0.7-1
libneon26 0.26.4-2build1
libneon26-dev 0.26.4-2build1
libneon27 0.28.2-6.1
libneon27-gnutls 0.28.2-6.1
libserf-0-0 0.3.0-0.3ubuntu1~ppa1~jaunty1
libsvn-doc 1.6.5dfsg-1ubuntu1~ppa4~jaunty1
libsvn1 1.6.5dfsg-1ubuntu1~ppa4~jaunty1
libsvncpp1 0.9.6-1
openssl 0.9.8g-15ubuntu3.3
python-openssl 0.7-2ubuntu1
subversion 1.6.5dfsg-1ubuntu1~ppa4~jaunty1

Test for ra_serf:
$ svn --config-option servers:global:http-library=serf \
  ls https://<my project>.csd200a.com/<path>

It works and does not ask me for certificate files!

Thanks a lot!

[Michael Diers (mdiers)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

edlutz wrote:
> Just to explain how I chose the packages: I added the following entries
> to apt sources:
>
> deb http://ppa.launchpad.net/mdiers/svn16/ubuntu jaunty main
> deb-src http://ppa.launchpad.net/mdiers/svn16/ubuntu jaunty main
>
> Then I installed the corresponding subversion package (1.6.5)
> (dependencies were handled by apt-get).
>
> $ svn --version
> svn, version 1.6.5 (r38866 w/ double-tc patch)
> compiled Sep 16 2009, 19:19:17
>
> Copyright (C) 2000-2009 CollabNet.
> Subversion is open source software, see http://subversion.tigris.org/
> This product includes software developed by CollabNet (http://www.Collab.Net/).
>
> The following repository access (RA) modules are available:
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
> - handles 'http' scheme
> - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
> - with Cyrus SASL authentication
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
> - handles 'http' scheme
> - handles 'https' scheme
>
>
> List of installed packages (cropped):
>
> libapr1 1.2.12-5ubuntu0.1
> libapr1-dev 1.2.12-5ubuntu0.1
> libapreq2 2.08-5build1
> libapreq2-dev 2.08-5build1
> libapreq2-doc 2.08-5build1
> libaprutil1 1.2.12+dfsg-8ubuntu0.3
> libaprutil1-dev 1.2.12+dfsg-8ubuntu0.3
> libcrypt-openssl-x509-perl 0.7-1
> libneon26 0.26.4-2build1
> libneon26-dev 0.26.4-2build1
> libneon27 0.28.2-6.1
> libneon27-gnutls 0.28.2-6.1
> libserf-0-0 0.3.0-0.3ubuntu1~ppa1~jaunty1
> libsvn-doc 1.6.5dfsg-1ubuntu1~ppa4~jaunty1
> libsvn1 1.6.5dfsg-1ubuntu1~ppa4~jaunty1
> libsvncpp1 0.9.6-1
> openssl 0.9.8g-15ubuntu3.3
> python-openssl 0.7-2ubuntu1
> subversion 1.6.5dfsg-1ubuntu1~ppa4~jaunty1
>
>
> Test for ra_serf:
> $ svn --config-option servers:global:http-library=serf \
> ls https://<my project>.csd200a.com/<path>
>
> It works and does not ask me for certificate files!

Excellent, thanks. Please note that there are upstream bugs filed
against ra_serf, so it might not always work _just_ right. In other
words, ra_neon is preferred.

- --
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iEYEAREDAAYFAkqzp5UACgkQcEKlWnqVgz36NwCgldTgtrOxh3YTuvF/yAElkCfH
ZH4An1iTO7WJRdD+cHxBU5UXv/NXtAvo
=IBCa
-----END PGP SIGNATURE-----

[edlutz (edlutz)]

Update: I found an error in my ~/.subversion/servers file: a leftover from some experiments that I did trying to force the use of predefined certificates (trying workarounds for the "certificates bug").

After fixing this config problem, everything works as expected, both with na_neon and na_serf.

Bottom line: the PPA builds seem quite solid.

Thanks!

[gero (gerod)]

Hi, I've had problems since upgrading from Hardy to Lucid:

$ svn update
svn: OPTIONS of 'https://svn.example.com/path/to/svn/trunk': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://svn.example.com)

I assume the old svn client version was 1.4.6: http://packages.ubuntu.com/hardy/subversion The new version is 1.6.6.

The repository has other users for whom it continues to work.

Could this be the same problem? Using libneon instead of libneon-gnutls has not helped, only changed the error message slightly:

svn: OPTIONS of 'https://svn.example.com/path/to/svn/trunk': SSL handshake failed: SSL error code -1/1/336032856 (https://svn.example.com)

Any other ideas?

[Tony Bayley (tony-bayleyfamily)]

My SVN problems were fixed when I changed from a self-generated SSL
certificate to one obtained from a certification authority (Free SSL
certificate obtained from StartCom: http://www.startssl.com/?app=39 )

I am not sure why this made a difference, but it might be worth trying if
you have run out of ideas!

Regards
Tony.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of gero
Sent: 05 September 2010 13:26
To: <email address hidden>
Subject: [Bug 294648] Re: svn over https with client certificates
broken(regression in intrepid)

Hi, I've had problems since upgrading from Hardy to Lucid:

$ svn update
svn: OPTIONS of 'https://svn.example.com/path/to/svn/trunk': SSL handshake
failed: SSL error: A TLS warning alert has been received.
(https://svn.example.com)

I assume the old svn client version was 1.4.6:
http://packages.ubuntu.com/hardy/subversion The new version is 1.6.6.

The repository has other users for whom it continues to work.

Could this be the same problem? Using libneon instead of libneon-gnutls
has not helped, only changed the error message slightly:

svn: OPTIONS of 'https://svn.example.com/path/to/svn/trunk': SSL
handshake failed: SSL error code -1/1/336032856
(https://svn.example.com)

Any other ideas?

--
svn over https with client certificates broken (regression in intrepid)
https://bugs.launchpad.net/bugs/294648
You received this bug notification because you are a direct subscriber
of the bug.

Status in subversion: New
Status in "subversion" package in Ubuntu: Confirmed

Bug description:
Binary package hint: subversion

After upgrading from hardy to intrepid, svn with https client certificates
authentication stopped working, giving the following error:

user@testhost:~$ svn info https://svn.example.org/svn/main/
svn: OPTIONS of 'https://svn.example.org/svn/main': Could not read status
line: SSL error: Rehandshake was requested by the peer.
(https://svn.example.org)

This is against an apache2 server with
<Location /svn>
          SSLVerifyClient require
...

If I set "SSLVerifyClient none" everything just works, hence the conclusion
that this is related to client certificate verification. I have configured
my svn client to use a pkcs#12 file.

This may be related to http://bugs.debian.org/480041

Version info:
subversion 1.5.1dfsg1-1ubuntu2
libneon27-gnutls 0.28.2-2build1

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/subversion/+bug/294648/+subscribe

[Andreas Jellinghaus (tolonuga)]

alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'

also you need the libneon27 package installed,
only libneon27-gnutls is not enough.

Regards, Andreas

Am Sonntag 05 September 2010, um 14:25:39 schrieben Sie:
> Hi, I've had problems since upgrading from Hardy to Lucid:
>
> $ svn update
> svn: OPTIONS of 'https://svn.example.com/path/to/svn/trunk': SSL handshake
> failed: SSL error: A TLS warning alert has been received.
> (https://svn.example.com)
>
> I assume the old svn client version was 1.4.6:
> http://packages.ubuntu.com/hardy/subversion The new version is 1.6.6.
>
> The repository has other users for whom it continues to work.
>
> Could this be the same problem? Using libneon instead of libneon-gnutls
> has not helped, only changed the error message slightly:
>
> svn: OPTIONS of 'https://svn.example.com/path/to/svn/trunk': SSL
> handshake failed: SSL error code -1/1/336032856
> (https://svn.example.com)
>
> Any other ideas?

[gero (gerod)]

Thank you for the advice!

Tony, I'm afraid I don't control the server.

Andreas, that's one of the methods I tried, but like I said: "Using libneon instead of libneon-gnutls has not helped, [...]"

Either way, AFAIC the current Ubuntu subversion package is broken and needs to be fixed.

[Bryan Cain (plombo)]

This bug bug is actually in neon, not Subversion. The attached patch applied to neon27-0.29.0 in lucid fixes it.

[Joe Orton (jorton)]

Bryan, that patch looks good - thanks. Please remember to send fixes upstream too!

[Bryan Cain (plombo)]

Thanks, I'll be sure to send it upstream!

[Joe Orton (jorton)]

Never mind, I've already merged it. This is fixed in neon 0.29.5.

[Bryan Cain (plombo)]

It looks like Debian unstable has integrated the upstream release of neon 0.29.5. Now Ubuntu just needs to apply the change, and this bug will finally be fixed in Ubuntu!

[Bryan Cain (plombo)]

The fix for this was committed to the neon27 repository in Ubuntu some time ago.

[Max Bowsher (maxb)]

@Bryan Cain

Please follow https://wiki.ubuntu.com/Bugs/Status when setting bug status of Ubuntu bugtasks. If the bug is fixed in natty, the appropriate status is "Fix Released".

[Max Bowsher (maxb)]

Per Joe Orton's comment about this being fixed in 0.29.5, marking Fix Released on the upstream bugtask.

[John Ryan (johnryannz)]

Just to throw a spanner in the works, I am still seeing this problem with Bryan's patch (comment #35) in all three of the following scenarios:

1) libneon27-gnutls built from Maverick sources with patch manually applied.
2) libneon27-gnutls built from Natty sources in Maverick.
3) Using the libneon27-gnutls binary package in Natty.

The only way I can get this to work is using Mike's LD_PRELOAD work-around (comment #14).

[gero (gerod)]

For me this bug hasn't been fixed either. I've installed libneon27_0.29.5-1_i386.deb and by dependency libssl0.9.8_0.9.8o-1ubuntu4.3_i386.deb on Lucid. I still get the error messages:

$ svn update
svn: OPTIONS of 'https://<server>/<path>': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://<server>)

$ LD_PRELOAD=/usr/lib/libneon.so.27 svn update
svn: OPTIONS of 'https://<server>/<path>': SSL handshake failed: SSL error code -1/1/336032856 (https://<server>)

[John Ryan (johnryannz)]

I've been digging through the source trying to track down the problem I am experiencing. This has actually led me into the source for libgnutls26 rather than neon but I'm posting here for completeness. libneon-gnutls27 calls gnutls_handshake() in libgnutls26 which calls _gnutls_handshake_client() which appears to proceed through the following stages successfully:

Send hello.
Receive server hello.
Receive server certificate.
Receive server key exchange message.
Receive server certificate request message.
Receive server hello done.
Send client certificate.
Send client key exchange.
Send client certificate verify.

It then calls _gnutls_handshake_common() which first successfully calls _gnutls_send_handshake_final() but falls over on _gnutls_recv_handshake_final() where it interprets the response from the server as a GNUTLS_ALERT packet instead of a GNUTLS_CHANGE_CIPHER_SPEC packet.

I have to assume that it is the gnutls client misinterpreting the packet rather than the server sending something unexpected because client certificate authentication works when using the LD_PRELOAD workaround and also when using Firefox.

I really want to get this working so I'll keep digging but if anyone has any ideas or wants to discuss please let me know.

[Bryan Cain (plombo)]

Hm...for all of you still having problems, could you try checking out the following SVN repository and see if you get a similar the issue appears?

svn co https://lavalit.com/svn/openbor/trunk

That's the repository I originally tested my patch on.

[Andreas Jellinghaus (tolonuga)]

you could also try:

svn co https://www.opensc-project.org/svn/test/

works with libneon27 0.29.0-1 on 10.04, but only if LD_PRELOAD hack is used.

Thats a live subversion server for the opensc project.

Regards, Andreas

[gero (gerod)]

Here's what I see with the setup from #44:

$ svn co https://lavalit.com/svn/openbor/trunk
svn: OPTIONS of 'https://lavalit.com/svn/openbor/trunk': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://lavalit.com)
$ LD_PRELOAD=/usr/lib/libneon.so.27 svn co https://lavalit.com/svn/openbor/trunk
svn: OPTIONS of 'https://lavalit.com/svn/openbor/trunk': SSL handshake failed: SSL error code -1/1/336032856 (https://lavalit.com)

$ svn co https://www.opensc-project.org/svn/test/
svn: OPTIONS of 'https://www.opensc-project.org/svn/test': Could not read status line: SSL alert received: Handshake failed (https://www.opensc-project.org)
$ LD_PRELOAD=/usr/lib/libneon.so.27 svn co https://www.opensc-project.org/svn/test/
Authentication realm: https://www.opensc-project.org:443
Client certificate filename:

[Bryan Cain (plombo)]

@gero

Is that with or without the patch?

[Bryan Cain (plombo)]

Even with the patch, I can reproduce the issue with the www,opensc-project.org URL. I'm reopening this bug since the bug description is broad enough to encompass instances like this one that still have issues.

[gero (gerod)]

Bryan, my results in #48 are with libneon27_0.29.5-1_i386.deb which, according to #38, includes the patch.

I would appreciate reopening this bug, thanks.

[Bryan Cain (plombo)]

gero, I might have been wrong about the patch being in Natty, then. The
LavaLit SVN error goes away (at least for me) when I apply the patch. Could
you try applying the patch to the Maverick neon27 sources and see if the
issue persists?

After saying I'd reopen this bug, I realized that Launchpad won't even let
me change the status of the bug for neon27. Which is ridiculous, especially
since I opened the bug for neon27 in the first place.

[John Ryan (johnryannz)]

Happy New Year everyone. Here are my results of trying with the two sites in Maverick and Natty.

In summary the lavalit.com site will only work with a patched version of neon. The LD_PRELOAD trick does not work for lavalit.com! On the other hand, the www.opensc-project.com site will only work with the LD_PRELOAD trick (although unsurprisingly it fails when it doesn't recognise my client certificate's CA). The patch doesn't solve the problem here!

It seems there are definitely two different problems at play here.

Full details attached.

[Joe Orton (jorton)]

I am not following what patches are where or what the differences are between the different builds are in Ubuntu. Here is what we use in Fedora, which is an unpatched neon 0.29.5 built against GnuTLS:

$ rpm -q subversion gnutls neon
subversion-1.6.13-1.fc14.x86_64
gnutls-2.8.6-2.fc14.x86_64
neon-0.29.5-1.fc14.x86_64
$ svn co https://www.opensc-project.org/svn/test
Authentication realm: https://www.opensc-project.org:443
Client certificate filename:
...
$ svn co https://lavalit.com/svn/openbor/trunk t2
A t2/openborscript.h
...

You are saying above, that only the Ubuntu build of neon using OpenSSL is working? Maybe the version of GnuTLS in use makes a difference.

[John Ryan (johnryannz)]

@Joe, here are the versions from Maverick and Natty for the record. However, you'll notice that the Fedora version of subversion is linked directly against libneon27 instead of libneon27-gnutls which is where the problem seems to lie in Ubuntu.

MAVERICK
libgnutls26-2.8.6-1
libneon27-gnutls-0.29.3-2
subversion-1.6.12dfsg-1ubuntu1
---
NATTY
libgnutls26-2.8.6-1ubuntu1
libneon27-gnutls-0.29.5-3
subversion-1.6.12dfsg-2ubuntu3
---
FEDORA 14
gnutls-2.8.6-2.fc14
neon-0.29.5-1.fc14
subversion-1.6.13-1.fc14
---

MAVERICK
# ldd /usr/bin/subversion | egrep "neon|gnutls"
libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1
libgnutls.so.26 => /usr/lib/libgnutls.so.26
libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27
---
FEDORA 14
# ldd /usr/bin/subversion | egrep "neon|gnutls"
libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0
libneon.so.27 => /usr/lib64/libneon.so.27
libgnutls.so.26 => /usr/lib64/libgnutls.so.26

[Joe Orton (jorton)]

Ignore the contortions of the neon packaging in Debian/Ubuntu. "libneon-gnutls.so.x" is an invention of Debian, who weirdly persist in shipping two builds of neon. The Fedora neon (libneon.so.x) is built against GnuTLS.

If anybody can show me SSL sites which fail with neon 0.29.5 please speak up. If you are seeing failures with a 0.29.3 build which doesn't have Bryan Cain's patch applied, that is expected. Upgrade to 0.29.5.

[Daniel Bingham (dbingham)]

Just going to add that I am currently experiencing this bug in 10.10 with the latest versions of OpenSSL, neon and subversion all compiled from source. I get the following error message with fail:

svn: OPTIONS of '<REPO>': SSL handshake failed: SSL error code -1/1/336032856 (<HOST>)

Versions

svn, version 1.6.17 (r1128011)
   compiled Jun 10 2011, 15:49:30

neon 0.29.6

openssl 1.0.0d

[Craig Ringer (ringerc)]

Daniel: Check `ldd svn' and the ldd output for neon to see if you're actually linked to OpenSSL or to gnutls.

[Dan Kegel (dank)]

For what it's worth, on Ubuntu 11.10 64 bit, LD_PRELOAD=/usr/lib/libneon.so.27 is enough to let me connect to my company's SVN server.

[Martin Lindhe (martinlindhe)]

Hello. Yesterday I updated our dev server from Ubuntu 11.04 to 11.10. And now all our LTS server installs (Ubuntu 10.04) can no longer communicate with the svn repository:

svn: OPTIONS of 'https://xxx/xxx': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://xxx)

using the suggested libneon alias:

svn: OPTIONS of 'https://xxx/xxx': SSL handshake failed: SSL error code -1/1/336032856 (https://xxx)

I also tried the "SSLVerifyClient none" apache config without success

Ubuntu 10.04 LTS has libneon27 version 0.29.0-1

Can the libneon package be backported to LTS to fix up this infrastructure mess, or do you expect us to upgrade all LTS servers to non LTS builds in order to continue to check out code to them (production systems)?

[Martin Lindhe (martinlindhe)]

Re: myself

I actually fixed my problem. It turned out our dev server did not have a ServerName in the apache hosts config. Setting this to the same name as in the server CA, fixed the problem.

This error:

[Tue Feb 14 16:49:15 2012] [warn] RSA server certificate CommonName (CN) `xxx.xxx' does NOT match server name!?

Seems to indicate the issue.

However, since i have had this "faulty" setup, this warning has been in this server's error logs for years already and it didnt occur to meit was the cause. Perhaps upgrade this from a warning to an "error", since it now is actually an error.

[Sun Jul 24 06:52:13 2011] [warn] RSA server certificate CommonName (CN) `xxx.xxx' does NOT match server name!?

[grubert (grubert)]

on 12.04 symlinking libneon ::

  cd /usr/lib
  sudo mv libneon-gnutls.so.27 libneon-gnutls.so.27.old
  sudo ln -s libneon.so.27 libneon-gnutls.so.27

no longer works

so i took libneon from oneiric,from here

  https://launchpad.net/ubuntu/oneiric/i386/libneon27/0.29.5-3

installed it ::

  dpkg -i libneon27_0.29.5-3_i386.deb

and set to hold to prevent it getting updated ::

  echo libneon27 hold | dpkg --set-selections

the symlink might still ned resetting from time to time
maybe setting LD_PRELOAD ::

  alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'

in .bashrc might be better than