On Mon, Apr 14, 2014 at 1:47 PM, Ben Reser <ben_at_reser.org> wrote:
> On 4/12/14, 3:41 PM, Nico Kadel-Garcia wrote:
>> For our own safety and benefito of combined HTTP/HTTPS servers for
>> Subversion worldwide: is there a published test to verify that HTTP
>> servers do not have the same flaw due to also being configured for
>> SSL?
>
> Stefan Sperling replied to you on the dev list already, but I think it's worth
> answering here again since there's a different audience here.
>
> A HTTP server that has no ports enabled to use SSL but that has mod_ssl is not
> vunlerable. This is the case because the issue only occurs when using the
> heartbeat extension of TLS (which requires an SSL/TLS enabled connection).
>
> However, servers that have both HTTP and HTTPS ports enabled may leak
> information about the HTTP only traffic via the HTTPS connections. I wouldn't
> be surprised if people have servers with public facing connections that are SSL
> enabled but internal only connections that do not use SSL at all.
But they're not leaking it over the HTTP port connections, even on a
vulnerable server that is HTTPS enabled, which is certainly not
unheard of. People host public spaces via HTTP on hosts that have
internal, administrative services like Nagios or Subversion, with
HTTPS "write" access exposed only internally.
> Consider this scenario. You have a public website with SSL enabled and a SVN
> repository (not SSL enabled) that's only accessible on your own private network
> (probably even on private address space). You are using the same httpd
> instance to host both. It is possible that information ranging from
> authentication details, tree structure, to even full file contents can be
> leaked by the SSL connection about the HTTP SVN connections.
Oh, yes, and I'm not discounting the risk of internally root-kitted or
zombied hosts scanning the internal SSL traffic.
> Essentially anything in memory of a process utilizing a vulnerable version of
> OpenSSL to implement the heartbeat extension to TLS is subject to being
> revealed to clients of the TLS connections.
>
>
Received on 2014-04-15 23:46:21 CEST