Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTFR-2016-ACT-035

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 29 août 2016
No CERTFR-2016-ACT-035

Affaire suivie par :

CERT-FR

Objet : Bulletin d'actualité CERTFR-2016-ACT-035

1 - Présentation du protocole HSTS

La grande majorité des requêtes effectuées sur Internet reposent sur le protocole HTTP ou sa version HTTPS protégée via TLS.

Si rien n'empêche une tierce partie en position «d'homme du milieu» d'écouter, voire d'altérer les communications HTTP, ce n'est pas le cas du protocole HTTPS. Dans ce cadre, TLS assure alors l'intégrité et le chiffrement des données ainsi que l'authentification du serveur au moyen de certificats X.509.

Malgré l'emploi du protocole HTTPS par le serveur, le client reste sujet à deux attaques :

  • une tierce partie peut utiliser le protocole HTTP pour les communications avec le client puis transférer celles-ci vers le serveur au moyen du protocole HTTPS. Ce type d'attaque est possible si le client n'impose pas la mise en œuvre du protocole HTTPS ;
  • une tierce partie peut utiliser le protocole HTTPS pour les communications avec le client, déchiffrer celles-ci, puis transférer les communications vers le serveur au moyen du protocole HTTPS. Ce type d'attaque est possible si le client ne valide pas correctement le certificat d'authentification du serveur ou que l'attaquant s'est procuré un certificat permettant de se faire passer pour le serveur (par exemple en récupérant un certificat frauduleux auprès d'une autorité compromise ou en installant une fausse autorité de certification).

Afin de se prémunir de ces attaques, deux technologies peuvent être employées :

  • HTTP Strict Transport Security ou "HSTS" ;
  • Certificate pinning.

La technologie HSTS permet d'éviter en partie la première menace décrite en imposant au client de n'utiliser que le protocole HTTPS pour toutes les connexions avec le serveur.
Dès lors, toute communication HTTP vers le serveur sera refusée automatiquement par le client. Notons néanmoins qu'un attaquant interceptant le tout premier échange entre le client et le serveur, soit la requête définissant l'utilisation du HSTS, est en mesure de jouer le premier scénario d'attaque.

Le certificate pinning permet, quant à lui :

  • de détecter le changement de certificat du serveur ;
  • de s'assurer que l'autorité de certification ayant signé le certificat du serveur est bien celle attendue.

La deuxième mesure prend la forme de listes associant des domaines, des URL à des autorités de certification. Ces listes peuvent être intégrées aux produits, configurées manuellement ou spécifiées au moyen de politiques HPKP (HTTP Public Key Pinning).

Ainsi tout attaquant ayant réussi, d'une manière ou d'une autre, à obtenir un certificat valide pour le serveur cible (c'est-à-dire avec le bon Common Name) sera dans l'incapacité d'intercepter les communications, car ce certificat ne sera pas signé par l'autorité attendue. L'utilisation du certificate pinning s'avère donc être complémentaire à l'emploi du HSTS.

L'utilisation de la technologie HSTS par un serveur Apache est possible après avoir ajouté au fichier de configuration les lignes suivantes :

LoadModule headers_module modules/mod_headers.so

<VirtualHost ip_concernee:port>
#la valeur de max-age correspond ici a 180 jours
Header always set Strict-Transport-Security "max-age=15552001; includeSubdomains;"
</VirtualHost>

L'utilisation du certificate pinning est, quant à elle, intégrée à Firefox ou Chrome ou peut être mise en œuvre par EMET pour les systèmes Windows.


2 - Rappel des avis émis

Dans la période du 22 au 28 août 2016, le CERT-FR a émis les publications suivantes :

  • CERTFR-2016-AVI-285 : Multiples vulnérabilités dans les produits NVIDIA
  • CERTFR-2016-AVI-286 : Multiples vulnérabilités dans les produits VMware
  • CERTFR-2016-AVI-287 : Vulnérabilité dans les noyaux Linux de Red Hat
  • CERTFR-2016-AVI-288 : Multiples vulnérabilités dans Apple iOS

Gestion détaillée du document

29 août 2016
version initiale.
Dernière version de ce document : http://cert.ssi.gouv.fr/site/CERTFR-2016-ACT-035

CERT-FR
2016-08-30
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-07-21