Le support ne répond plus

La cryptographie peut parfois être subtile. Pour tous ceux qui en doutaient encore, en voici un exemple concret.

Notre histoire commence en milieu de semaine dernière : Bouclier de Tempête sort une mise à jour pour sa gamme de produit réseau : La version 2.2.1 est disponible. Aussitôt publié, nous l’installons sur notre boitier de test : A priori pas de changement énorme, cela reste conforme à ce qui était annoncé.

Tentative de mise à mort du Sha

Une navigation rapide dans l’interface ne présente pas de changement significatif. Mais après quelques minutes de navigation sur le boitier depuis Firefox, nous constatons des échecs de connexion sur des services en SSL/TLS.

sslfail

Nous souhaitons alors nous connecter au site du support afin de voir s’il y a des infos à ce sujet : Malheureusement, le site du support fait partie des victimes. On va donc devoir se débrouiller seul.

Creusons un peu : tout d’abord allons faire un tour dans les journaux d’événements :

alarm

Visiblement une alarme du module ASQ (liée au niveau de chiffrement) est configurée pour bloquer notre trafic. Allons donc voir de quoi il retourne :

niveau_chiff

Le petit lien « Aide » renvoie vers une base de connaissance toujours aussi explicite… On y comprend qu’il y a très certainement un problème lors la négociation SSL.

Un petit coup de capture réseau sur les interfaces interne et externe devrait nous permettre de comprendre davantage. Commençons par analyser le trafic interne :

wireshark_int

On y voit bien notre « Client Hello » avec les 3 propositions de suites de chiffrement. Celui-ci est suivi d’un tcp RST. Voyons donc ce qui se passe de l’autre coté. De la même façon, nous y voyons notre « Client Hello » et ses 3 suites proposées.

wireshark_ext

Cependant, de coté de la barrière, le « Server Hello » arrive… Et le serveur choisit comme c’est son droit, (et oui c’est lui qui a le dernier mot, d’où une certaine prudence dans ce que nous lui proposons) la suite TLS_DHE_RSA_WITH_AES_256-CBC-SHA.
(Nous insistons ici sur la version du protocole : TLS 1.2. Vous verrez, c’est important pour la suite).

wireshark_ext_srv

Or si nous avons bien compris l’aide de l’alarme, le blocage par l’ASQ signifie que cette suite de chiffrement est interdite.

Notons que lorsque nous sommes soumis au filtrage du boitier, il semble que seuls deux mécanismes soient autorisés (« Semble » car la commande  « nmap –script ssl-enum-ciphers.nse  mystormshield.eu » dont le résultat est présenté ci-après est visiblement sensible au temps de réponse du serveur et l’ASQ induit une latence qui fait varier les résultats de la commande, mais on a jamais eu plus de 4 suites valides)

nmap

Nous comparons alors au résultat de la même commande mais cette fois ci sans filtrage :

%> nmap  --script ssl-enum-ciphers.nse  mystormshield.eu
Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-05 16:05 CET
Nmap scan report for mystormshield.eu (91.212.116.103)
Host is up (0.088s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

Dans ce cas-ci (sans filtrage), nous n’avons que l’embarras du choix…

Au passage, une question nous taraude l’esprit : Pourquoi diable le site du support n’accepte pas l’utilisation de ECDHE comme algorithme d’échange de clé ? Ils ont un truc contre  les courbes elliptiques ? Aurait-ce un rapport avec le revirement de la NSA sur ces méthodes ? Et RC4 est proposé par le serveur… Ce n’est pas faute d’avoir expliquer comment durcir une configuration SSL !

Mais revenons à nos moutons : à force de tentative, on découvre empiriquement que l’alarme bannit tout protocole qui utilise SHA-1 et ce un peu en avance par rapport au reste du monde. De plus cette alarme n’est pas nouvelle sur cette version (elle était déjà présente sur la version 2.1.2), son comportement est devenu plus « sectaire » vis à vis de SHA-1. Une relecture attentive de la documentation accompagnant la nouvelle version confirme cela :

Le niveau de sécurité de certains algorithmes de chiffrement avait été déprécié au sein du plugin
SSL: [...] algorithmes de type SHA1 passant au niveau moyen. (page 5)

Malheureusement la même documentation ne justifie pas cette décision.

Il est ici important de préciser que Firefox dans sa dernière version propose le SHA256 uniquement avec ECDHE (vous pouvez aussi vérifier la liste des suites activées et disponibles via about:config) :

FF

Donc finalement, on dira que FireFox ne propose pas suffisamment de suites pour permettre une bonne interopérabilité avec cette alarme ASQ et la navigation sur un grand nombre de sites.

Mais pourquoi sont-ils si méchants ?

Du coup, on est content : grace à cette alarme, nous sommes protégés contre les attaques sur SHA-1.

Oui mais non, rappelez vous plus haut : nous avons insisté à la version du protocole utilisé : en effet, cela a une petite importance. En lisant la RFC 5246, nous apprenons que HMAC-SHA1 et HMAC-MD5 sont automatiquement remplacés par HMAC-SHA256 (premier paragraphe) ! Ce qui en termes plus explicites  signifie qu’en TLS 1.2, la suite de chiffrement TLS_RSA_WITH_AES_256_CBC_SHA utilise HMAC-SHA256 comme fonction pseudo-aléatoire.  Cette fonction sert notamment à calculer la fameuse clé maitre du chiffrement. Le SHA n’est alors utilisé que dans le contrôle d’intégrité des paquets chiffrés.

Ce qui nous amène tout droit à notre deuxième point, les attaques sur SHA-1 précédemment citées ont-elles un impact sur la sécurité de HMAC-SHA1 ? Et bien non. D’ailleurs la plus part des annonces sont faites sur l’abandon de la fonction SHA-1 dans un cadre bien précis : les algorithmes de signature (type certificat, horodatage), ce qui n’est pas tout à fait la même chose.

De plus bloquer SHA-1 dans SSL/TLS, revient à interdire toutes les versions du protocole antérieures à TLS 1.2. La navigation va donc être fortement impactée avec cette alarme à ce niveau de sécurité.

Mais bon, nos amis lillois ont du voir grand et décider de bannir SHA-1 complétement de toutes les négociations cryptographiques… Effectivement c’est ce que nous pourrions nous dire, cependant naviguer vers des sites utilisant un certificat signé en SHA1_RSA est complétement possible (ici ou par exemple) alors que l’alarme est activée. Mais pour les administrateurs de boitier, vous pouvez simplement vous connecter à votre interface et vérifier l’algorithme de signature du certificat par défaut. C’est un petit point à garder en tête quand les principaux navigateurs vont bloquer SHA-1 : ça risque d’être un peu la panique en Janvier).

Du coup, ce blocage a-t-il un sens ?  Si oui, lequel ? En tous les cas, cela n’a rien d’évident.

Quelqu’un pourrait demander plus d’info à « bouclier de tempête » ? Nous, on aimerait bien mais on arrive pas à accéder au site du support !

Publicités

A propos JoMendes

Amateur de mathématiques et d'hexadécimal. Je m'intéresse de près ou de loin suivant mon niveau à tous les sujets de sécurité de l'information.
Cet article, publié dans Sensibilisation, Système, est tagué , , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s