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

On Tue, Aug 19, 2014 at 9:53 AM, Lieven Govaerts <lgo_at_mobsol.be> wrote:

> 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:
> https://code.google.com/p/serf/issues/detail?id=135
>
> The user gets this error message:
> svn: E120171: Unable to connect to a repository at URL
> 'https://svn.company.com/ssl/repo/Math/trunk'
> 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 for the clarification. Based on this, I think an option is the way
to go. It sounds like most users will never need this, even if using
client certs. So making it an option for those impacted sounds like a good
plan.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/