From my perspective, all these changes would be fine.
The core information I care about is: Googling for "An error occurred
during SSL communication" should lead to this "openssl s_client" tip.
Cheers,
Folker
On 2018-08-03 13:04, Daniel Shahaf wrote:
> julianfoad_at_apache.org wrote on Thu, Aug 02, 2018 at 14:44:02 -0000:
>> +++ subversion/site/publish/docs/release-notes/1.10.html Thu Aug 2 14:44:02 2018
>> @@ -353,6 +353,43 @@ In particular, the behaviour of builds <
>>
>> </div> <!-- svnserve-use-sasl -->
>>
>> +<div class="h4" id="new-ca-keys">
>> +<h4>New CA keys may be required
>> + <a class="sectionlink" href="#new-ca-keys"
>> + title="Link to this section">¶</a>
>> +</h4>
>> +
>> +<p>
>> +Some binary distributions of this new Subversion version
>> +may link to a newer OpenSSL version than previous distributions.
>> +This may lead to different behavior.
> Should we state that it's possible, though less likely, for a new Subversion
> 1.9 binary package to be built against OpenSSL 1.1? I suppose we should do so
> if OpenSSL 1.1 is API-compatible with 1.0 [so a libssl1.0 consumer can
> recompile against libssl1.1 with no other changes].
>
> This does mean that users of such new 1.9 binaries will need to read the 1.10
> release notes to find this info, but I don't immediately see a better option.
>
>> +<p>
>> +Especially, some distributions may link this Subversion release to OpenSSL 1.1 instead of OpenSSL 1.0.
>> +OpenSSL 1.1 does not allow md5 hashes for CA keys anymore.
> As I said, I doubt that's the only incompatible change between 1.0 and 1.1, so
> we should be linking to information about further incompatibilities.
>
> As a datapoint, Debian's libssl1.1 package (which I looked into when drafting
> replies earlier in the thread) has an on-upgrade notice that warns that TLS 1.0
> support is being dropped, but has no upgrade notice about md5. I conclude that
> the Debian package maintainer judges the TLS change to be more impactful than
> the md5 change.
>
> (To see the notice at 'apt upgrade' time one needs to install apt-listchanges.)
>
>> +When using client certificates signed by such a CA,
>> +the new Subversion client may fail with <tt>An error occurred during SSL communication</tt>.
>> +You can analyze the underlying cause by first converting the client certificate from p12 to pem by
>> +<pre>
>> +openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem
>> +</pre>
>> +and then testing the SSL connection by
>> +<pre>
>> +openssl s_client -connect example.com:443 -servername example.com -cert cert.pem
>> +</pre>
> Is it possible to use «s_client -certform $FOO -cert cert.p12» here and skip
> the conversion step? It's not clear to me from the manpage on my system (and I
> can't easily test this).
>
> State somewhere to look into the server-side error logs in case they contain
> more information?
>
>> +If this test connection fails with <tt>ca md too weak</tt>
>> +then creating new CA keys using sha256 instead of md5
>> +and corresponding new client certificates should solve the problem.
> This bit of information (a) is duplicated between our releases notes and our
> FAQ, (b) should live in OpenSSL's docs rather than ours. [I have made point (b)
> in another thread so let's concentrate in this thread on point (a).]
>
>> +</p>
>> +
>> +<p>
>> +See also <a href="/faq.html#ssl-communication-error">When performing Subversion operations
>> +over SSL, I get the error <tt>An error occurred during SSL communication</tt></a>
>> +</p>
>> +
>> +</div> <!-- new-ca-keys -->
>> +
>> </div> <!-- compat-misc -->
>>
>> </div> <!-- compatibility -->
>> +++ subversion/site/publish/faq.html Thu Aug 2 14:44:02 2018
>> @@ -4158,6 +4160,48 @@ Subversion perform a normal recursive co
>>
>> </div>
>>
>> +<div class="h3" id="ssl-communication-error">
>> +
>> +<h3>When performing Subversion operations
>> + over SSL, I get the error <tt>An error occurred during SSL communication</tt>
>> + <a class="sectionlink" href="#ssl-communication-error"
>> + title="Link to this section">¶</a>
>> +</h3>
>> +<p>
>> +SSL communication errors can have various reasons.
>> +You can use the openssl binary to debug the ssl connection.
>> +<pre>
>> +openssl s_client -connect example.com:443 -servername example.com
>> +</pre>
>> +If you use a client certificate,
>> +then you need to convert Subversion's client certificate from pkcs12 to pem first:
>> +<pre>
>> +openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem
>> +</pre>
>> +Then you can use:
>> +<pre>
>> +openssl s_client -connect example.com:443 -servername example.com -cert cert.pem
>> +</pre>
> The -certform question above applies here too, as does the suggestion to
> recommend to look into the server-side error log.
>
>> +If you are using ssl-authority-files in <tt>.subversion/servers</tt> to verify
>> +the server cert you can get <tt>s_client</tt> to do the same with the additional
>> +parameter:
>> +<pre>
>> +openssl s_client ... -CAfile path/to/authority.pem
>> +</pre>
>> +The <tt>s_client</tt> output may indicate what problem is occurring.
>> +</p>
>> +
>> +<p>
>> +For example, if <tt>s_client</tt> reports
>> +<pre>
>> +error setting certificate
>> +140258270184704:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak:../ssl/ssl_rsa.c:303:
>> +</pre>
>> +then creating new CA keys with sha256 instead of md5 should solve the problem.
>> +</p>
>> +
>> +</div>
>> +
>> </div>
>>
>> <div class="h2" id="developer-questions">
>>
>>
Received on 2018-08-03 14:20:59 CEST