Perché TLS ha bisogno di un protocollo di heartbeat esplicito?

Il battito del cuore ha due scopi: fare attività a livello di link (per evitare la chiusura con firewall zelanti) e per assicurarsi che il peer sia ancora vivo. Se si desidera eseguire entrambi con i frammenti vuoti, è necessaria una convenzione tra client e server, in modo che quando si invia un frammento vuoto, il peer risponda con un frammento vuoto. Questo ha potenziale per cicli infiniti se non eseguito correttamente.

Inoltre, quando i frammenti vuoti sono stati utilizzati come contromisura all'attacco BEAST, è emerso che alcune implementazioni ampiamente implementate hanno avuto problemi con esse. Questo è il motivo per cui facciamo un "1 / n-1 split", non uno "0 / n" split.

Pertanto, l'estensione heartbeat è principalmente una formalizzazione di quella convenzione ping-like, con una negoziazione e un formato iniziali tali da non creare problemi di interoperabilità.

Il vantaggio principale per un'implementazione basata su TLS è che lo stesso codice di elaborazione del record SSL può essere utilizzato per TLS e DTLS. In caso contrario, il codice di elaborazione del record SSL deve conoscere il meccanismo di trasporto sottostante.

L'altro uso per questo è per protocolli di trasporto affidabili multi-stream, su cui si dispone di TLS. L'esempio nella RFC è SCTP. In questo caso, c'è un po 'di uso.

L'uso pratico di questo su TCP è vicino a zero.

TCP ha già keepalive (e OGNI connessione TCP deve essere protetta da "firewall zelanti" se questo requisito esiste), quindi il mantenimento in SSL è inutile.