Discussion:Attaque par repli
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
Tout ou partie de cet article est issu de la traduction de l'article sous licence CC-BY-SA « (en) Downgrade attack » dans sa version du 22/06/2018.
Consultez l'historique de la page originale pour connaître la liste de ses auteurs.
Cet article est indexé par le projet Informatique.
Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.
| Avancement | Importance | pour le projet | |
|---|---|---|---|
| Ébauche | Faible |  | Informatique (discussion • critères • liste • stats • hist. • comité • stats vues) |
Cet article ne comporte pas de liste de tâches suggérées. Vous pouvez saisir une liste de tâches à accomplir (par exemple sous forme d'une liste à puces), puis sauvegarder. Vous pouvez aussi consulter la page d'aide.
Brouillon[modifier le code]
C'est l'un des types les plus courants d'attaques de déclassement. Un autre exemple est l'interception du trafic Web et la redirection de l'utilisateur de la version HTTPS sécurisée d'un site Web vers une version HTTP non chiffré.Les attaques à la baisse sont souvent mises en œuvre dans le cadre d'une attaque de l'homme du milieu, et peuvent être utilisées pour permettre une attaque cryptographique qui ne serait pas possible autrement. Les attaques à la baisse ont été un problème constant avec la famille de protocoles SSL/TLS ; des exemples de telles attaques incluent l'attaque POODLE.
La suppression de la rétrocompatibilité est souvent le seul moyen d'empêcher les attaques de downgrade. Cependant, il arrive parfois que le client et le serveur se reconnaissent mutuellement comme étant à jour d'une manière qui les en empêche. Par exemple, si un serveur Web et un agent utilisateur implémentent tous les deux HTTP Strict Transport Security et que l'agent utilisateur le sait (soit parce qu'il y a déjà accédé via HTTPS, soit parce qu'il est sur une "liste de préchargement HSTS"), l'agent utilisateur refuse d'accéder au site via HTTP vanilla, même si un routeur malveillant le représente et le serveur à un autre comme non compatible HTTPS. — Le message qui précède, non signé, a été déposé par EulerObama (discuter), le 14 septembre 2018 à 16:28 (CEST).