Rilevazione heartbleed [duplicato]

Question

Rilevazione heartbleed [duplicato]

#1 da (2 voti)

1

È abbastanza facile rilevare l'exploit heartbleed se tutto accade su cleartext, cosa che sembra che la maggior parte delle cose stia facendo per il momento. Tuttavia, credo che ci siano alcuni exploit senza problemi che si verificano dopo la crittografia, perché la RFC consente (e suggerisce) che le richieste di heartbeat vengano inviate crittografate.

Da 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.

Come sopra riportato, un HeartbeatRequest NON DEVE essere inviato durante le strette di mano. La mia ipotesi è che molti exploit oggi vengano inviati durante la stretta di mano per essere più efficienti.

In caso affermativo, che aspetto ha un HeartbeatRequest durante l'handshake rispetto a HeartbeatRequest dopo che è stato crittografato e in che modo è possibile monitorare e rilevare gli exploit di Heartbleed post-crittografia sulla rete (non sull'endpoint)?

openssl tls heartbleed detection

posta JZeolla 13.04.2014 - 13:21

fonte

1 risposta

Leggi altre domande sui tag openssl tls heartbleed detection

elenco delle estensioni dei file del certificato PKCS7 Multi-tenancy e Heartbleed

score 2 · Answer 1

Per essere precisi, RFC consiglia di eseguire heartbeat legit dopo il completamento dell'handshake; non consiglia exploit mai. (Compatibile con il link che purtroppo non è mai arrivato a BCP.)

Sì , Heartbeat è un tipo di record distinto (24 o 0x18). Qualsiasi risposta più lunga della richiesta da parte di un riempimento più che ragionevole è una prova di exploit. Anche qualsiasi richiesta o risposta più lunga di 2 ^ 14 più epsilon è male, e direi che qualcosa di più di circa 50 in TLS è sospetto perché sarebbe utile solo per PMTU e PMTU qui è utile solo, se non del tutto, per DTLS non TLS. Non hai bisogno del testo in chiaro.