We’re rewarding the question askers & reputations are being recalculated! Read more.
    Post Closed as "duplicate" by JZeolla, Adi, Steve, Xander, Eric G of
3 added 39 characters in body
source | link

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) itthat 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
HeartbeatResponse message.

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 this is what many exploits are doing 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)?

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) it.

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
HeartbeatResponse message.

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 this is what many exploits are doing today 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)?

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
HeartbeatResponse message.

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)?

2 edited tags
| link
1
source | link

Heartbleed detection

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) it.

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
HeartbeatResponse message.

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 this is what many exploits are doing today 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)?