Summarizing Known Attacks on TLS and DTLS
jeudi 12 février 2015 à 05:04CAFAI Liens en Vrac 12/02/2015
Depuis quelques années, on entend souvent parler de failles dans TLS ou dans les mises en œuvre de TLS, comme OpenSSL. Un groupe de travail a été créé à l'IETF pour essayer de durcir la sécurité de TLS, le groupe UTA (Using TLS in Applications). Son premier RFC est un rappel de ces récentes failles. C'est l'occasion de réviser BEAST, CRIME ou Heartbleed.
Le protocole de cryptographie TLS (autrefois nommé SSL) est normalisé dans le RFC 5246. Les attaques récentes contre TLS sont très variées : mauvaise utilisation de TLS par les applications (la principale motivation pour la création du groupe UTA, et son centre d'intérêt principal), bogues dans un programme mettant en œuvre TLS, erreurs dans le protocole, erreurs dans un des algorithmes cryptographiques qu'il utilise... Ce RFC dresse une liste des problèmes de sécurité de ces dernières années, mais on peut être sûr que la liste va s'allonger. Comme le dit la NSA, « Attacks always get better; they never get worse » (cf. RFC 4270).
Le gros morceau du RFC est sa section 2, qui liste les problèmes. Par exemple, la plus évidente est d'empêcher complètement l'usage de TLS (ce qu'on nomme parfois SSL stripping). Par exemple, si un client HTTP se connecte en HTTP et compte sur le serveur pour le rediriger en HTTPS, un attaquant actif peut modifier la redirection, empêchant ainsi TLS de démarrer. Le SSL stripping est donc un cas particulier des attaques par repli (downgrade attacks). Normalement, HSTS (RFC 6797) est la bonne solution contre cette attaque.
Pour HTTP, il est habituel de démarrer directement en TLS. Pour les protocoles où on démarre sans TLS et où on utilise ensuite une commande STARTTLS pour commencer à chiffrer (comme SMTP), une attaque par repli analogue est possible en supprimant la commande STARTTLS. La seule protection possible serait un équivalent de HSTS (le RFC oublie de mentionner DANE, qui pourrait être utilisé à des fins de signalisation). Autre problème avec STARTLS, les attaques où le tampon d'entrée n'est pas vidé après le passage à TLS, ce qui fait que les commandes injectées avant que TLS ne sécurise la connexion sont exécutées après, en les croyant sûres (CVE-2011-0411). Ce n'est pas une faille du protocole mais de l'application.
(Permalink)
Depuis quelques années, on entend souvent parler de failles dans TLS ou dans les mises en œuvre de TLS, comme OpenSSL. Un groupe de travail a été créé à l'IETF pour essayer de durcir la sécurité de TLS, le groupe UTA (Using TLS in Applications). Son premier RFC est un rappel de ces récentes failles. C'est l'occasion de réviser BEAST, CRIME ou Heartbleed.
Le protocole de cryptographie TLS (autrefois nommé SSL) est normalisé dans le RFC 5246. Les attaques récentes contre TLS sont très variées : mauvaise utilisation de TLS par les applications (la principale motivation pour la création du groupe UTA, et son centre d'intérêt principal), bogues dans un programme mettant en œuvre TLS, erreurs dans le protocole, erreurs dans un des algorithmes cryptographiques qu'il utilise... Ce RFC dresse une liste des problèmes de sécurité de ces dernières années, mais on peut être sûr que la liste va s'allonger. Comme le dit la NSA, « Attacks always get better; they never get worse » (cf. RFC 4270).
Le gros morceau du RFC est sa section 2, qui liste les problèmes. Par exemple, la plus évidente est d'empêcher complètement l'usage de TLS (ce qu'on nomme parfois SSL stripping). Par exemple, si un client HTTP se connecte en HTTP et compte sur le serveur pour le rediriger en HTTPS, un attaquant actif peut modifier la redirection, empêchant ainsi TLS de démarrer. Le SSL stripping est donc un cas particulier des attaques par repli (downgrade attacks). Normalement, HSTS (RFC 6797) est la bonne solution contre cette attaque.
Pour HTTP, il est habituel de démarrer directement en TLS. Pour les protocoles où on démarre sans TLS et où on utilise ensuite une commande STARTTLS pour commencer à chiffrer (comme SMTP), une attaque par repli analogue est possible en supprimant la commande STARTTLS. La seule protection possible serait un équivalent de HSTS (le RFC oublie de mentionner DANE, qui pourrait être utilisé à des fins de signalisation). Autre problème avec STARTLS, les attaques où le tampon d'entrée n'est pas vidé après le passage à TLS, ce qui fait que les commandes injectées avant que TLS ne sécurise la connexion sont exécutées après, en les croyant sûres (CVE-2011-0411). Ce n'est pas une faille du protocole mais de l'application.
(Permalink)