On Thu, Apr 10, 2014 at 05:02:17PM -0400, mclellan, dave wrote:
> We are looking more deeply into Heartbleed to determine the risk
> to our proprietary, non-open application.
Based on the below, it is vulnerable, and needs to be linked against
a patched OpenSSL library, or one built with -DOPENSS_NO_HEARTBEATS
(IIRC).
> 1. Background summary: Our proprietary client/server protocol
> is protected by TLS with OpenSSL 1.0.1c and 1.0.1e. We do not
> respond to http or any other standard protocols. The session
> initiation and RPC-like communication between client and server is
> encapsulated inside an API library which an application can't
> influence directly. Neither the physical socket nor the SSL object
> that represents the channel is directly accessible to the caller
> of the API library.
The attacker will not use your RPC library, she will connect with
a custom SSL client that is designed to slurp-up sensitive data
from memory. Since your RPC is encapsulated in SSL/TLS, the attack
will work even if the attacker has no knowledge of your RPC protocol.
> 2. Question: Heartbeat negotiation: Is there anything
> automatic in TLS session negotiation that causes the heartbeat
> protocol to be used by peers without application awareness? Our
> application does nothing explicit to negotiate the Heartbeat
> Extension; we do nothing to prevent it.
There is nothing you can do to prevent in 1.0.1 -- 1.0.1f, other
than recompile with hearbeat support disabled. Even if hearbeats
are not used by legitimate clients, they are available to malicious
clients.
> 3. Question: Heartbeat use: once negotiated, is there
> anything automatic in the protocol that causes one side to request
> a heartbeat from the peer? Our peers communicate at the application
> level in a strict synchronous request - response method; a client
> thread sends a request and waits for a response; no secondary
> threads are involved.
This is irrelevant, but heartbeats are not automatic, and legitimate
hearbeats are not the risk you need to mitigate. Malformed hearbeat
requests from malicious clients are what you need to defend against.
> Since we enclose the application client and server applications
> and we do no heartbeat work ourselves, what is the risk?
You're just as vulnerable as other applications.
> We
> recognize that reverse engineering our protocol is possible, but
> we believe that the difficulty of the exploit in the context of
> our server application is very high. We also recognize that we
> could be surprised by very clever attackers, so we want to do the
> right thing.
The same attack as for other protocols encapsulated in SSL works
equally well with your protocol, no need for any ingenuity. For
example the same attack works equally for HTTP, SMTP and XMPP
servers.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
