This question already has an answer here:
It is fairly easy to detect the heartbleed exploit if it all happens over cleartext, which it seems most things are doing for the time being. However, I believe that there are some heartbleed exploits occurring after encryption because the RFC allows (and suggests) that heartbeat requests be sent encrypted.
From RFC 6520:
A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. Whenever a HeartbeatRequest message is
received, it SHOULD be answered with a corresponding
However, a HeartbeatRequest message SHOULD NOT be sent during
handshakes. If a handshake is initiated while a HeartbeatRequest is
still in flight, the sending peer MUST stop the DTLS retransmission
timer for it. The receiving peer SHOULD discard the message
silently, if it arrives during the handshake. In case of DTLS,
HeartbeatRequest messages from older epochs SHOULD be discarded.
As it states above, a HeartbeatRequest SHOULD NOT be sent during handshakes. It is my assumption that many exploits today are being sent during the handshake in order to be more efficient.
If so, what does a HeartbeatRequest during the handshake look like in comparison to a HeartbeatRequest after it is encrypted, and how can we monitor for and detect post-encryption Heartbleed exploits on the network (not on the endpoint)?