On 10 Apr 2014, at 2:02 PM, mclellan, dave 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.
If a malicious client can connect and go through the TLS handshake, even if they never speak the "inner" protocol, then they are able to issue heartbeat requests and extract memory contents. (Or if your client can be made to connect to a malicious server: the server can issue heartbeat requests to the client.) If it's impossible to make any TCP connections except through your API, then you're safer, because (a) no heartbeats will be sent, because nobody uses this feature with non-datagram TLS and (b) even if they were, a non-malformed heartbeat does not leak info. But if you're using TLS at all, then presumably this is because the TCPIP network over which TLS is running is potentially insecure in some way (e.g., it's the open internet); an attacker with the ability to send packets on that layer could start making TLS connections and extracting data even with no knowledge of your proprietary protocol. If you are in a situation where you are only concerned about purely passive eavesdroppers on that connection, though, then I believe you are safe. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
