Le chiffrement HTTPS suffit-il à protéger tous les échanges d'une application ?
D’après Sécurité informatique
HTTPS protège le canal de communication, mais n'élimine pas toutes les vulnérabilités des traitements qui l'utilisent. La compression, les configurations et les données manipulées doivent aussi être prises en compte dans l'analyse de sécurité.
Contrôle de la compression
Désactiver la compression TLS : Depuis CRIME et BREACH, il est recommandé de désactiver la compression SSL/TLS côté serveur.
Limiter la compression au niveau applicatif : Si l’on a besoin de compresser les données, mieux vaut le faire en amont, sur le contenu statique ou non sensible.
Vérifier l’implémentation : S’assurer que le code chargé de la décompression n’autorise pas des tailles exorbitantes ou un ratio de décompression infini (prévenir les ZIP bombs).
Communications chiffrées (TLS/SSL) pour les applications Web
HTTPS : Repose sur TLS pour chiffrer les requêtes et réponses HTTP.
Même si l’on place souvent TLS “entre” la couche Transport (TCP) et la couche Application (HTTP), dans le concept OSI, c’est clairement une fonction de “présentation” (mise en forme et cryptage).
Menaces résiduelles
Si le serveur autorise SSLv2 ou SSLv3, un attaquant peut tenter un “SSL downgrade”.
Les suites de chiffrement “weak” (export-grade) doivent être désactivées.
Les certificats autofirmés ou expirés réduisent la confiance.