[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    RE: Bug in ra_serf with client certificates
From:       "Bert Huijben" <bert () qqmail ! nl>
Date:       2014-01-28 14:36:59
Message-ID: 04ac01cf1c36$6840c280$38c24780$ () qqmail ! nl
[Download RAW message or body]



> -----Original Message-----
> From: lieven.govaerts@gmail.com [mailto:lieven.govaerts@gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: dinsdag 28 januari 2014 15:24
> To: Branko Čibej
> Cc: Subversion Development
> Subject: Re: Bug in ra_serf with client certificates
> 
> On Tue, Jan 28, 2014 at 2:46 PM, Branko Čibej <brane@wandisco.com>
> wrote:
> > On 28.01.2014 14:37, Lieven Govaerts wrote:
> > 
> > On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <brane@wandisco.com>
> wrote:
> > 
> > I just got a private report from a user that has a setup with a private
> > certificate. This user happened to select the wrong certificate for a
> > server, and got the following response:
> > 
> > svn: E120171: Unable to connect to a repository at URL
> > 'https://example.com/svn/foobar'
> > svn: E120171: Error running context: An error occurred during SSL
> > communication
> > 
> > 
> > This the error code E120171 comes from Serf and apparently means
> > SERF_ERROR_AUTHN_FAILED. There's corroboration in the server log:
> > 
> > 120171 = SERF_ERROR_SSL_COMM_FAILED
> > 
> > 
> > Ugh. That's me looking at the wrong part of serf.h. :(
> > 
> > 
> > The command line client doesn't ask for a client certificate, it
> > should be defined correctly in the servers file using:
> > ssl-client-cert-file
> > ssl-client-cert-password
> > 
> > 
> > (facepalm)
> > 
> > 
> > Unless (s)he's using TortoiseSVN which has its own dialog to select
> > certificates from the windows certificate store.
> > 
> > 
> > It's not TSVN, it's a different client but the result is the same -- it has
> > its own implementation of the authn callback.
> > 
> > In other words, is I expect there's no way to get the authn dialog to ask
> > for a different cert, given the error message; thanks, I'll pass this on.
> > 
> 
> It may be possible to implement this. The callback that OpenSSL calls
> in serf to ask for a client certificate now only calls the application
> once, and then returns that cached result.
> 
> If OpenSSL actually calls that callback again after a failed
> validation of a client certificate (to be tested) and we can detect
> that failure, it should be possible to ask the application for a new
> client cert.

If this works it would resolve quite a few problems in the current TortoiseSVN \
implementation. We heard multiple problem reports of users that use different \
certificates for different locations and currently the clients must implement their \
own support on the openssl layer to get this working.

With a proper Serf callback (through Subversion) we can just implement a proper store \
(either in Subversion or in the clients that implement this on Windows) as we have \
access to the uri of the repository. In the OpenSSL layer we don't have access to \
that.

	Bert 


[prev in list] [next in list] [prev in thread] [next in thread]