Les requêtes cryptées SSL sont-elles vulnérables aux attaques de relecture?
Les requêtes cryptées SSL sont-elles vulnérables aux attaques de relecture? Si oui, quelles sont les bonnes options pour éviter cela?
Le canal SSL/TLS lui-même est protégé contre les attaques de relecture à l'aide du MAC (Message Authentication Code), calculé à l'aide du secret MAC et du numéro de séquence. (Le mécanisme MAC est ce qui assure l'intégrité de la communication TLS). Voir Annexe F.2 de la spécification TLS 1.1 :
Pour empêcher les attaques de relecture ou de modification des messages, le MAC est calculé à partir du secret MAC, du numéro de séquence, de la longueur du message, du contenu du message et de deux chaînes de caractères fixes.
EDIT: Comme le souligne @CodesInChaos, la prise de contact doit également être prise en compte, sinon toute la connexion TLS pourrait être rejouée (pas seulement certains enregistrements, qui est ce contre quoi le MAC et le numéro de séquence se protégeraient). Si un attaquant rejouait le même Client Hello message, le serveur renverrait un Server Hello avec une valeur aléatoire de serveur différente, ce qui modifiant le reste de l'échange de clés . De plus, en mode d'échange de clés RSA, seul le client légitime initial connaîtrait le secret pré-maître qu'il a chiffré; en mode d'échange de clé DHE, les aléas client et serveur sont signés ensemble dans le message d'échange de clé serveur (d'où l'importance de bons nombres aléatoires là aussi). (Il y a un peu plus sur ces deux modes dans cette question .)
Votre question ne précise pas ce que vous essayez de protéger contre les attaques par rejeu. Il s'agit généralement d'un message envoyé au-dessus de la couche SSL/TLS, utilisé par votre application.
Le cryptage fourni par SSL/TLS empêche certainement un espion de voir cette demande d'application, et donc de la rejouer avec sa propre connexion SSL/TLS distincte.
Cependant, SSL/TLS à lui seul n'empêche pas nécessairement l'utilisateur initial légitime de relire une demande. Les protocoles et les applications qui nécessitent ce niveau de protection supplémentaire ont tendance à avoir des mécanismes non basés au niveau de l'application pour résoudre ce problème (qui est plutôt indépendant de SSL/TLS, bien que la prévention des écoutes aide).