Le richieste crittografate SSL sono vulnerabili agli attacchi di riproduzione?

Il canale SSL / TLS stesso è protetto dagli attacchi di replay usando il MAC (Message Authentication Code), calcolato usando il segreto MAC e il numero di sequenza. (Il meccanismo MAC è ciò che garantisce l'integrità della comunicazione TLS). Vedi Specifiche TLS 1.1 Appendice F.2 :

To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings.

EDIT: come indicato da @CodesInChaos, anche l'handshake deve essere preso in considerazione, altrimenti l'intera connessione TLS potrebbe essere riprodotta (non solo alcuni record, che è il numero MAC e la sequenza proteggere contro). Se un utente malintenzionato ha ripetuto lo stesso messaggio Client Hello , il server restituirebbe un Server Hello con un diverso valore casuale del server, quindi alterando il resto dello scambio di chiavi . Inoltre, nella modalità di scambio di chiavi RSA, solo il client legittimo iniziale potrebbe conoscere il segreto pre-master che ha crittografato; nella modalità di scambio chiavi DHE, i randoms client e server sono firmati insieme nel messaggio di scambio chiave del server (da qui l'importanza di buoni numeri casuali anche lì). (C'è un po 'di più in queste due modalità in questa domanda .)

Non è chiaro dalla tua domanda che cosa stai cercando di proteggere dagli attacchi di riproduzione. In genere, si tratta di un messaggio inviato sopra il livello SSL / TLS, utilizzato dall'applicazione.

La crittografia fornita da SSL / TLS impedisce certamente a un intercettatore di vedere la richiesta dell'applicazione e quindi di riprodurla con la propria connessione SSL / TLS separata.

Tuttavia, SSL / TLS da solo non impedisce necessariamente all'utente legittimo di riprodurre una richiesta. I protocolli e le applicazioni che richiedono questo livello aggiuntivo di protezione tendono ad avere meccanismi basati su nonce a livello di applicazione per risolvere questo problema (che è piuttosto indipendente da SSL / TLS, anche se impedisce l'aiuto di eavesdropping).