As you may have heard in the news OpenSSL has had a significant security vulnerability [1] [2]. Subversion by way of several of our dependencies uses OpenSSL. On the client side the Neon and Serf HTTP libraries can use OpenSSL (Neon can also use GNUTLS, which is not vulnerable to this issue) and on the server side Apache HTTP Server and Cyrus SASL can use OpenSSL (though Cyrus SASL's use of OpenSSL is not vulnerable).
As a result it is important to make sure that the OpenSSL version being used with Subversion is not vulnerable. It is impossible for the Subversion project to provide vulnerable version information for Subversion since if you are vulnerable depends on the OpenSSL used at build and/or run time. We do not publish binaries, so you should consult with your binary provider to make sure you are not vulnerable. If you've built your own version of Subversion you should check which version you have built against and/or are using at runtime. This specific issue lies in the implementation of a feature of the SSL/TLS protocols. Apache HTTP Servers running mod_ssl to provide SSL/TLS are vulnerable. While svnserve does support encryption via Cyrus SASL, and Cyrus SASL does use OpenSSL to provide the encryption algorithms, it does not use it to implement the SSL/TLS protocols. This means that svnserve is not directly vulnerable. However, you can use the svnserve over tunnels and those tunnels may be vulnerable. For instance stunnel implements the SSL/TLS protocol and does so via OpenSSL. SSH based tunnels are unaffected as they do not use the SSL/TLS protocols. If you're using some other tunnel not mentioned here you should check with the developers of that tunnel for details. It is important to understand that this vulnerability is not specific to the server side. Clients can be vulnerable to malicious servers using the same attack against clients. So care should be taken to ensure that clients are not using vulnerable OpenSSL versions as well. The unfortunate consequence of this vulnerability is that server or client memory may be exposed to the other side of the connection. This has the possibility of exposing private information that the other side of the connection should not have. Within the context of Subversion that means authentication information, details about working copies, data from other clients, private keys used with public key encryption, etc. As a result of the above potential data disclosures, after you have upgraded to non-vulnerable versions of the software, you may want to take additional actions including revoking and reissuing SSL/TLS server and client certificates and resetting user passwords. It is understood that retrieving private keys to certificates may be very difficult, but still possible. Other data may be much easier to retrieve. As such, if these steps are necessary are largely a matter of your risk tolerance. If you are using HTTPS to access your Subversion repositories and do decide to revoke your certificates you should understand that at current Subversion does not support rejecting revoked certificates that would otherwise be trusted. Our HTTP libraries (Neon and Serf) which we depend on for this sort of functionality do not currently provide support for providing an external CRL (Certificate Revocation List), retrieving CRLs from a URL in the certificate, checking certificates via OCSP (Online Certificate Status Protocol) or handling an OCSP response that has been stapled to the TLS handshake. In the meantime, you can disable trusting certificates based on trust in the Certifying Authorities to avoid accepting revoked certificates. To do this you will want to make some configuration changes in your server config file for Subversion (usually at /etc/subversion/servers, ~/.subversion/servers, or %APPDATA%\Subversion\servers, see [3] for more details). Set "ssl-trust-default-ca" to "no" and remove the "ssl-authority-files" setting. By doing this Subversion will prompt for all certificates giving you details on the certificate and a fingerprint. You will then have the opportunity to accept the certificate temporarily or permanently. Server admins should let their users know the fingerprints of the correct certificates. This is similar to the manner in which SSH handles validating they are talking to the server they expect to be. If you have already trusted certificates that are now revoked you will also need to remove them from your authentication store for Subversion. This will be stored under ~/.subversion/auth/svn.ssl.server or %APPDATA%\Subversion\auth\svn.ssl.server. You can delete the entire directory to remove all accepted certificates or just delete specific files within the directory to remove just those certs. The files are simply text files containing some data, you should be able to read them to locate the specific keys you which to remove. We realize that the handling for revoked certificates is far from ideal at this time. We plan to improve this in the future, but are unable to provide a time frame for such improvements. [1] http://www.openssl.org/news/secadv_20140407.txt [2] http://heartbleed.com/ [3] http://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html