[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with SSL Client auth and libserf

From: Lieven Govaerts <lgo_at_apache.org>
Date: Thu, 25 Jul 2013 17:56:36 +0200

Hi,

On Thu, Jul 25, 2013 at 4:25 PM, Bernd May
<bernd_at_net.t-labs.tu-berlin.de> wrote:
> Hello,
>
> I am experiencing re-negotiation issues namely connection closed when
> trying to use a subversion client >=1.8 against an svn server running
>
> Debian Wheezy
> apache 2.2.22
> libapache 1.8.1
> subversion 1.8.1
> openssl 1.0.1e
>
> with ssl client auth.
>
> I have now spent about 4 hours of searching through old ssl client auth
> errors in the openssl issues, subversion maillinglist and tried the
> following combinations of client libraries and binaries against the
> server mentioned above:
>
> * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1
> * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e
>
> Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive
> the following error on the client side, regardless of the openssl version:
>
> svn: E120108: Unable to connect to a repository at URL
> 'https://example.com/svn/myrepo'
> svn: E120108: Error running context: The server unexpectedly closed the
> connection.
>
> Disabling the 'SSLVerifyClient Require' directive yields a successful
> listing of the svn content, so this really appears to be related to
> client auth.
> Using an svn client with libneon also yields a successful repository
> listing so this points quite directly at libserf.
>
> On the server side the error messages in debug mode look like this:
>
> ... initial ssl connection setup completes ...
> [Thu Jul 25 16:20:12 2013] [info] Initial (No.1) HTTPS request received
> for child 77 (server inet-svn.net.t-labs.tu-berlin.de:443)
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(510): [client
> <myip>] Changed client verification type will force renegotiation
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1554): [client
> <myip>] filling buffer, max size 131072 bytes
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1606): [client
> <myip>] total of 131 bytes in buffer, eos=1
> [Thu Jul 25 16:20:12 2013] [info] [client <myip>] Requesting connection
> re-negotiation
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O
> error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3]
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(764): [client
> <myip>] Performing full renegotiation: complete handshake protocol
> (client does support secure renegotiation)
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL:
> Handshake: start
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
> Loop: SSL renegotiate ciphers
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
> Loop: SSLv3 write hello request A
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
> Loop: SSLv3 flush data
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
> Loop: SSLv3 write hello request C
> [Thu Jul 25 16:20:12 2013] [info] [client <myip>] Awaiting
> re-negotiation handshake
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL:
> Handshake: start
> [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
> Loop: before accept initialization
> [Thu Jul 25 16:20:22 2013] [info] [client <myip>] Request body read timeout
> [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O
> error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3]
> [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_kernel.c(1903): OpenSSL:
> Exit: error in SSLv3 read client hello B
> [Thu Jul 25 16:20:22 2013] [error] [client <myip>] Re-negotiation
> handshake failed: Not accepted by client!?
> [Thu Jul 25 16:20:22 2013] [debug] mod_deflate.c(615): [client <myip>]
> Zlib: Compressed 0 to 2 : URL /svn/bernd
>

Renegotiation has been tested in serf, maybe it doesn''t work in all cases.

>
> So either the client sent garbage or not what the server expects or
> there is some kind of hiccup in the server libraries?
>
> If anyone could point me to a way to further debug this or a solution,
> I'd be very gracious

Enabling logging in serf will probably give you more detailed info on
the failure on the client side.
Logging can be activated by setting these flags in serf_private.h and
then rebuilding serf:
#define SSL_VERBOSE 1
#define CONN_VERBOSE 1
#define SOCK_VERBOSE 1

If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but
the info you'll need will be at the end. Alternatively you can upgrade
to serf 1.3.0 where ssl logging has been cleaned up. You can send the
log files to the list or to me privately, I'll have a look.

Lieven

> --
> Technische Universität Berlin - FGINET
>
> Bernd May
>
> System Administration
> Sekr. TEL 16
> Ernst-Reuter-Platz 7
> 10587 BERLIN
> GERMANY
>
> Mobile: 0160/90257737
> E-Mail: bernd_at_inet.tu-berlin.de
> WWW: inet.tu-berlin.de
>
Received on 2013-07-25 18:08:25 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.