1. OpenSSL allows heartbeats during handshake. 2. Handshake request can come from any peer and is responded to (client or server is immaterial). You don't prevent it, so a peer can send heartbeat request and your openssl endpoint shall respond.
From what you describe, your application is vulnerable. -Amarendra -- sent via 100% recycled electrons from my mobile command center. > On Apr 10, 2014, at 2:02 PM, "mclellan, dave" <dave.mclel...@emc.com> wrote: > > We are looking more deeply into Heartbleed to determine the risk to our > proprietary, non-open application. > 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. > 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. > 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. > > Since we enclose the application client and server applications and we do no > heartbeat work ourselves, what is the risk? 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. > > +-+-+-+-+-+-+-+-+- > Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. > Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 > Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com > +-+-+-+-+-+-+-+-+- >
