Pourquoi faut-il contrôler la compression et l'intégrité des données échangées ?
D’après Sécurité informatique
Faille dans la compression (CRIME/BREACH)
CRIME : Une vulnérabilité historique dans TLS lorsqu’il combine compression du canal et cookies secrets. L’attaquant pouvait déduire, le contenu secret en jouant sur la taille du message compressé : mots de passe trop simple par exemple.
BREACH : Variante spécifique à HTTP compréssé, où on devine un token secret inséré dans le corps en manipulant la taille des requêtes.
Ces exemples illustrent comment une fonctionnalité a priori utile (la compression) peut se transformer en vecteur d’attaque si elle n’est pas mise en œuvre avec prudence.
Contrôle d’intégrité et signature des données
Outre la simple conversion de format, la couche Présentation peut associer aux données un code d’authentification ou une signature numérique :
HMAC (Hash-based Message Authentication Code) : L’expéditeur calcule un HMAC sur le contenu avec une clé partagée.
Le destinataire vérifie ce HMAC pour être sûr que les données n’ont pas été modifiées.
Signature asymétrique : Au lieu d’une clé symétrique, on utilise une paire de clés (privée/publique), par exemple RSA ou ECDSA.
Cela permet la non-répudiation et l’authentification de la source.
Empreinte (hash) stockée : Parfois, l’application calcule un hash (SHA-256, SHA-3, etc.) et l’attache aux données.
Avant lecture, le récepteur compare le hash pour détecter toute corruption.
Le fait de vérifier l’intégrité à ce niveau évite les insertions ou modifications arbitraires, même si un attaquant est parvenu à contourner ou affaiblir la couche Transport en dessous.