À quoi sert le coffre-fort Wildfly (JCEKS) lors de la sécurisation du keystore https?

Question

J'ai l'impression de manquer complètement le nouveau format de keystore JCEKS dans Wildfly. Peut-être que tu peux me redresser.

La façon dont nous avons wildfly configuré (et une grande partie de l'internet nous apprend à, for example):

• Nous avons mis les entrées standard keystore dans un fichier magasin Java standard Key (les "keystore.jks") avec un mot de passe ("jks_pw")
• Nous créons ensuite un keystore JCEKS ("keystore.jceks") avec un mot de passe, salt, et round-count ("jceks_s_n").
• Nous avons ensuite mis "pks_pw" dans "keystore.jceks"
• Nous ajoutons ensuite le mot de passe JCEKS/etc ("jceks_s_n") dans notre config jboss (de standalone.xml) sous forme de texte, définissant une entrée
• nous ajoutons ensuite une référence au mot de passe JKS voûte stocké à notre connecteur jboss https (de standalone.xml), comme "password =" $ {vAULT :: JKS :: JKS :: 1} ».

Qu'est-ce que le diable a fait tout cela?

Si nous avons simplement utilisé un fichier JKS et un mot de passe intégré dans standalone.xml, le système est susceptible de:

• Un attaquant obtenant une copie de standalone.xml et le fichier JKS, auquel cas tous les secrets sont connus.
• Un attaquant obtenant une copie du fichier JKS, auquel cas un attaquant peut utiliser des attaques par force brute ou table de recherche.

Si nous utilisons un conteneur JCEKS de la manière décrite, le système est sensible à:

• (SAME) Un attaquant obtenir une copie de standalone.xml, les fichiers JKS/JCEKS, dans lequel cas tous les secrets sont connus.
• (SAME) Attaquant obtenant une copie du fichier JKS, auquel cas un attaquant peut employer des attaques par force brute ou table de recherche.

Cela sorte de sens que si nous mettons les certs réelles à l'intérieur du fichier JCEKS, dans lequel les attaques de table cas force brute et consultation serait plus difficile dans le second cas d'attaque, mais jusqu'à présent je n » J'ai trouvé un moyen d'utiliser un keystore au format JCEKS directement avec un connecteur https. Vraiment, la seule raison pour laquelle je m'inquiète trop à ce sujet est que nous avons apparemment besoin d'une sécurité pour utiliser le "coffre-fort", mais cela semble inutile. MISE À JOUR: Il est important de noter qu'en utilisant le coffre-fort, vous utilisez un mot de passe «masqué» pour le coffre-fort dans votre fichier de configuration jboss, mais je n'arrive pas à comprendre ce que cela signifie. Apparemment, votre mot de passe masqué + salt + rounds peut déverrouiller le keystore JCEKS (source), donc je ne suis pas sûr de ce que fait exactement le masquage. Cela semble juste comme un troisième niveau de redirection. Je dois manquer quelque chose ...

Answer 1

JBoss indique que le mécanisme de sécurité derrière « voûte » est la sécurité par l'obscurité (https://developer.jboss.org/wiki/JBossAS7SecuringPasswords)

Vault utilise un mot de passe inconnu et algorithme effectuer un chiffrement symétrique de la keystore mot de passe.Sans HSM, vous serez toujours confronté au problème de "où stocker le, par exemple, mot de passe de source de données". Donc, normalement, vous devez définir un fichier de propriétés avec une liste de contrôle d'accès et y stocker le mot de passe codé. Le coffre-fort augmente simplement l'effort d'obtention du mot de passe sécurisé, laissant l'attaquant soit lire le pw en mémoire, soit désosser l'algorithme + clé de chiffrement du coffre-fort.