Re: Bug report: Regression SVN Client, SSL, Serf 1.3.9-3, SSLVerifyClient require

Folker Schamel <schamel23_at_spinor.com> writes:

> After upgrading, Subversion SSL connections with "SSLVerifyClient
> require" seem to be broken.
>
> Broken: SVN Client 1.9.5, Serf 1.3.9-3, Server "SSLVerifyClient require"
> Works:  SVN Client 1.9.5, Serf 1.3.9-3, Server "SSLVerifyClient off"
> Works:  SVN Client 1.9.5, Serf 1.3.8-1, Server "SSLVerifyClient require"

I can use client certificates on my Debian machine using 1.3.9-3 with
"SSLVerifyClient require" so it does work in some configurations.

I think that one of the changes between 1.3.8-1 and 1.3.9-3 on Debian is
that openssl was upgraded from 1.0 to 1.1. That's a major upgrade and
some sort of openssl incompatibility may be the problem.

You could use the openssl binary to debug the ssl connection. First you
need to convert Subversion's client certificate from pkcs12 to pem:

  openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem

then you can use:

  openssl s_client -connect example.com:443 -servername example.com -cert cert.pem

If you are using ssl-authority-files in .subversion/servers to verify
the server cert you can get s_client to do the same with the additional
parameter:

  openssl s_client ... -CAfile path/to/authority.pem

The s_client output may indicate what problem is occurring.

> For the broken setup, the client reports:
> svn: E120171: Error running context: An error occurred during SSL communication
> And the server Apache log reports:
> ssl_engine_io.c(1308): (70014)End of file found: [client xxxxx:xxxxx]
> AH02007: SSL handshake interrupted by system [Hint: Stop button
> pressed in browser?!]
>
> Using the latest TortoiseSVN client reports the same problem,
> presumably the same cause.

TortoiseSVN is probably built with openssl 1.1 as well.

> [Tue Jul 31 15:30:43.886183 2018] [ssl:debug] [pid xxxxx:tid xxxxx]
> ssl_engine_kernel.c(2122): [client xxxxx:xxxxx] AH02044: No matching
> SSL virtual host for servername xxxxx found (using default/first
> virtual host)

That looks like SNI isn't working but I don't know if that is relevant
for your problem. Some sort of vhost/servername problem in the apache
config?

> <Location /svn>
>     SetOutputFilter DEFLATE
>     SetInputFilter DEFLATE
>     Header append Vary User-Agent env=!dont-vary
> </Location>

DEFLATE combined with mod_dav_svn had problems in the past but I think
they are all fixed. Note that when mod_dav_svn and Subversion clients
communicate they do so using compressed deltas, so adding DEFLATE
doesn't result in very much additional compression. The combination has
a more significant compression effect if users are using non-Subversion
tools: web browsers, curl, etc. This is probably not relevant to your
problem.

-- 
Philip