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

Re: [PATCH] Add a configuration option to disable HTTP pipelining.

From: Lieven Govaerts <lgo_at_mobsol.be>
Date: Tue, 19 Aug 2014 14:53:07 +0100

On Tue, Aug 19, 2014 at 2:34 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Aug 19, 2014 at 9:25 AM, Lieven Govaerts <lgo_at_mobsol.be> wrote:
>> There's a bug in OpenSSL's SSL renegotiation algorithm. When it's
>> initiated by the server to request a client certificate, it'll fail
>> when on the connection pipelined requests are incoming at the server
>> side.
>> Short summary of the root cause: during renegotiation, OpenSSL reads
>> data from the TCP connection expecting it to be a proper client
>> certificate. However, if an HTTP request was still pending on the
>> connection or in the server's receive buffer, OpenSSL will read that
>> request's data, recognise its not a proper client certificate, discard
>> the data and report an error. Apache will then abort the connection in
>> response to that OpenSSL error.
>> Given that there's no fix planned in OpenSSL, the only available
>> mitigation is to disable HTTP pipelining on connections where a SSL
>> renegotiation can happen. Since that depends on the configuration of
>> the server, we can't really know or predict when such renegotiation
>> will happen.
>> Conclusion: give the user the option to disable HTTP pipelining, which
>> she can use in case of problems caused by renegotiation.
>> Attached patch implements just that.
>> Objections anyone? Other remarks?
> I assume it is not possible for Serf to know that it is using client
> connections and disable it automatically?

Serf knows that the application set the client cert callback, but it
only knows that the server requires a client certificate for a certain
resource when OpenSSL asks serf for a client certificate. Then it's
already too late to disable HTTP pipelining.

So indeed, it's not possible.

> I assume this problem does not happen all the time? How does it manifest
> currently? What error does user see.

The details can be found in serf issue #135:

The user gets this error message:
svn: E120171: Unable to connect to a repository at URL
svn: E120171: Error running context: An error occurred during SSL communication

> We have a few customers that use client certificates, and AFAIK, they have
> been using SVN 1.8 OK.

It has been reported a couple of times to the serf list by svn users,
and I can simulate it (see issue #135) repeatedly.

It does depend on the server configuration though. If the server is
configured to request for a client certificate on the root of the
repository, then it will request the client certificate in response to
one of the first requests on the connection. Typically - at least for
the first connection - the first requests will be sent one by one (see
svn's broken proxy detector), so this problem never triggers.

However, when the client certificate is requested for a resource
deeper in the repository, it's likely that say during a large
checkout, many (pipelined) requests will already be sent by the client
before the request for the protected resource. This is the scenario
that'll lead to the problem.

So with the combination of a general error message and a need for a
specific server configuration, it's not surprising that you won't have
heard of this issue before.


> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/
Received on 2014-08-19 15:53:54 CEST

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

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