On Sat, Apr 12, 2014 at 10:08 PM, Ben Reser <bre...@apache.org> wrote:
> 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. Thank you, Ben. In all the furor about the bug, the publicly available "heartbleed" test tools all seem to be test only https://, not http://, and I've not seen the client vulnerability you mention discussed at all. Do you have anything a bit more authoritative about the "httpd servers with mod_ssl loaded are also vulnerable over plain HTTP://" ? I believe you, I'm just trying to make sure when I bring this up at work that I don't have to spend an hour explaining the details of httpd configuration and loadable modules. I'm assuming that the vulnerability for particular httpd (Apache 2.x) web servers is *only* activated when the "mod_ssl" module is loaded, or other similar encryption modules. I'm afraid that I've also seen people who believe they're immune because they route all oficial traffic through an SSL proxy, and the SSL proxy is safe. But the internal server the proxy connects to supports *both* HTTP and HTTPS, so it has mod_ssl loaded, and is thus vulnerable to *internal* attack. That' would be true even if the external proxy blocks such attacks. I've not seen any verification that proxies set for simple HTTP pass-through are vulnerable. I suspect they're safe, but I'd really like to have a test tool to verify this. Has anyone seen a Heartbleed test tool that will test HTTP sites, or HTTPS on ports other than 443? Especially one that can be run from an iPhone 4 like mine, or downloaded and run on a local Linux system? I've seen the Android tool already in use. Make no mistake, this is a big risk for entire environments: Stolen Subversion access alone can often provide access to internal software or site configuration tool repositories such as Puppet or CFengine, or software build environments and source trees for sensitive software. One someone has been sniffing important passwords from one exposed server, they may be able to use those for access through your VPN or external SSH jumpgates and go rooting around your much less secured internal systems. Worse: many sites use their AD or LDAP based credentials for VPN access, for SSH login access to home directories with NFS acess to other people's accounts, and for internal "sudo" access. So those exposed passwords may also provide far, far more internal exposure. Couple such VPN access with internal NFS, which only rarely uses the Kerberos enabled NFSv4 settings and an attacker has visibility into stored Subversion passwords in NFS home directories or un-passphrase protected SSH keys in NFS home directories. That.... gets *nasty*. The SSL key theft, and possible site forgery or Man-in-the-Middle attacks, have gathered a lot of the attention of the HeartBleed bug. But the password theft risks are much more awkward to clean up in a quick sweep. Nico Kadel-Garcia