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<mailto:dave.mclel...@emc.com> +-+-+-+-+-+-+-+-+-
