Impact de la faille SSL PODDLE dans les environnements MQ

L’article ci-dessous est une synthèse des informations sur la faille POODLE en environnement WebSphere MQ, publiées par IBM et la communauté technique dans différents forums.

SSL fait beaucoup parler de lui ces derniers jours.

Après Shellshock, la faille découverte dans l’interpréteur bash, voici maintenant Poodle.

Rien à voir avec les caniches : POODLE (Padding Oracle On Downgraded Legacy Encryption) est une faille de conception du protocole SSL qui permet de casser un chiffrement en forçant un mode SSL moins sécurisé (de TLS vers SSL v3 par exemple), mode qui permettra le decryptage progressif du flux échangé.

MQ n’était pas concerné par Shellshock, mais par contre l’est un peu plus par Poodle.

La fonction de chiffrement intégrée dans les canaux MQ ne permet pas le choix dynamique du ciper (il doit être le même des deux cotés), donc en théorie il n’y a pas de risque de forcer un retour de TLS vers SSL.

Par contre, l’utilisation d’un cipher de type SSL expose la communication MQ.

Que faut-il faire ?

Il faut s’assurer que les cipher utilisés sur chaque canal ne soient pas de type « SSL v3 ».

Exemples de cipher SSL V3 :

  • AES_SHA_US
  • RC4_SHA_US
  • RC4_MD5_US
  • TRIPLE_DES_SHA_US
  • DES_SHA_EXPORT1024
  • RC4_56_SHA_EXPORT1024
  • RC4_MD5_EXPORT
  • RC2_MD5_EXPORT
  • DES_SHA_EXPORT
  • NULL_SHA
  • NULL_MD5
  • FIPS_WITH_DES_CBC_SHA
  • FIPS_WITH_3DES_EDE_CBC_SHA

Si le cipher utilisé sur vos canaux ne fait pas partie de cette liste, votre serveur MQ n’est pas exposé à la faille POODLE.

Le cipher utilisé doit être le même des deux coté du canal. Les ciphers disponibles dépendent du niveau de version de MQ, de la plate-forme, et dans une moindre mesure du niveau de fixpack.

Si votre réseau MQ comporte des serveurs qui vont de la version 7.0 à la 8.0, des OS variés, des applications Java, le choix se réduit fortement. Un bon candidat est le cipher TLS_RSA_WITH_AES_128_CBC_SHA. C’est du TLS 1.0 / SHA1 / AES128, il est disponible sur toutes les plates-formes de MQ 7.0 à 8.0, et certifié FIPS.

La certification FIPS (Federal Information Processing Standards) d’un cipher signifie qu’il apporte un niveau de sécurité considéré comme suffisant par cet organisme.

L’activation de FIPS sur un Queue Manager empêche le démarrage de canaux utilisant un cipher non certifié FIPS.

Aucun cipher de type SSLv3 n’est certifié FIPS, donc son activation (via le paramètre SSLFIPS du Queue Manager) va empêcher l’utilisation de SSLv3 par un canal.

Par contre, SSLFIPS interdit aussi le démarrage de canaux utilisant certains autres ciphers :

  • ECDHE_ECDSA_NULL_SHA256
  • ECDHE_ECDSA_RC4_128_SHA256
  • ECDHE_RSA_NULL_SHA256
  • ECDHE_RSA_RC4_128_SHA256
  • TLS_RSA_WITH_DES_CBC_SHA
  • TLS_RSA_WITH_NULL_SHA256
  • TLS_RSA_WITH_RC4_128_SHA256

Il faut activer SSLFIPS avec précaution car contrairement au cipher qui se règle canal par canal, SSLFIPS se règle au niveau Queue Manager (ALTER QMGR SSLFIPS(YES | NO).

L’activation de FIPS n’est donc pas du tout obligatoire pour se protéger de Poodle, par contre une non-activation peut-être considérée (à tort) comme une faille de sécurité potentielle par un auditeur sécurité.

En résumé :

  • Pour ceux qui utilisent encore des cipher faibles (de type SSL par exemple), il est temps de passer à des cipher plus forts de type TLS, par exemple TLS_RSA_WITH_AES_128_CBC_SHA.
  • Pour s’assurer qu’aucun cipher faible ne sera utilisé sur un Queue Manager, il faut positionner le paramètre SSLFIPS à YES : ALTER QMGR SSLFIPS(YES)

Sources et liens :

  • Security Bulletin IBM : http://www-01.ibm.com/support : /docview.wss?uid=swg21687433&myns=swgws&mynp=OCSSFKSJ&mync=E
  • Ciphers MQ V7.0.1 : http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqzaw.doc/ja34740_.htm?lang=fr
  • Ciphers MQ V8.0 : http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q014260_.htm
  • FIPS : http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010140_.htm

(image source wikimedia)