POST over HTTPS "suffisamment sécurisé" pour les données sensibles?
Je me demande si pour éviter la possibilité d'un certificat SSL compromis conduisant à la divulgation d'informations sensibles s'il serait prudent de chiffrer davantage les données transmises via SSL.
Scénario imaginaire: deux applications web. L'une est une application Web, l'autre est une application fournissant une API d'authentification.
L'application Web envoie un HTTPS POST à l'API d'authentification contenant le nom d'utilisateur et le mot de passe. Il est crypté via SSL.
Cependant, ces données ne pourraient-elles pas être reniflées si un attaquant devait compromettre le certificat SSL?
Ma pensée est d'ajouter un autre niveau de cryptage - par exemple nous avons une paire de clés publique/privée supplémentaire et nous chiffrons toutes les informations dans le POST par cela aussi.
Cela signifierait qu'un attaquant qui aurait compromis votre certificat SSL devra trouver une clé privée supplémentaire afin de rompre la communication.
Pensées?
Au lieu d'un chiffrement supplémentaire, si vous devez être sécurisé, utilisez l'authentification à deux facteurs. Demandez aux utilisateurs utilisateurs d'entrer un nom d'utilisateur, un mot de passe et un nombre aléatoire à 6 chiffres envoyés par e-mail ou SMS. Un certificat compromis signifie que l'attaquant peut éventuellement contrôler l'intégralité de la charge utile SSL dans les deux sens; y compris tout code que vous envoyez au client pour effectuer le cryptage requis pour l'authentification auprès du serveur.
Pensez également à séparer votre serveur d'applications et votre serveur d'authentification. Cela rend beaucoup plus difficile pour un attaquant de faire quoi que ce soit d'utile avec une liste acquise de noms d'utilisateur et de mots de passe s'ils ne sont pas réellement acceptés par le serveur d'applications; c'est le concept derrière OAuth2. Il est beaucoup plus facile de récupérer un serveur que d'attaquer deux serveurs (au moins, en théorie).
Je suppose que lorsque vous dites que "l'application Web" envoie un POST, ce que vous voulez vraiment dire, c'est que la page Web html dans le navigateur des utilisateurs fait un POST demande à un serveur tiers.
L'événement d'un compromis SSL/TLS par un attaquant extérieur (AC/gouvernement non autorisé) est probablement assez faible. Cela laisse deux possibilités.
#1. Votre serveur a été compromis par une attaque indépendante, et la clé privée a été volée
Si quelqu'un se trouve dans votre système et peut accéder à la clé privée, il peut probablement accéder à votre application/source et la modifier pour siphonner les données (MITM). À ce stade, aucun crypto supplémentaire ne vous sauvera.
# 2. Les paramètres utilisés pour créer/déployer SSL/TLS sont incorrects. Si vous utilisez des algorithmes/hachages non sécurisés ou une ancienne version SSL, vous pouvez être vulnérable aux attaques spécifiques SSL ( http://en.wikipedia.org/wiki/Transport_Layer_Security#Security ). N'oubliez pas d'utiliser SSL 3/TLS. De préférence TLS 1.2.
Oui! TLS est pas sécurisé - la substitution de certificat est extrêmement courante (la plupart des entreprises utilisent des appareils Edge d'inspection de contenu, la plupart des écoles et des unis, tous de bons pare-feu, et même plusieurs pays obligent tous les utilisateurs à installer leur propre autorité de certification pour pouvoir MitM et inspecter le trafic "crypté"). Tous les deux mois environ, une nouvelle autorité de certification est également compromise. Il existe également de nombreux logiciels malveillants qui installent leur propre autorité de certification sur les machines victimes.
L'utilisation de 2FA n'est pas une solution à ce problème. 2FA est une technologie d'authentification de 35 ans qui n'a absolument rien à voir avec la protection contre l'interception du trafic.
Si vous supposez que la clé privée a été compromise (le certificat est remis à chaque transaction, mais est inutile sans la clé privée), il aurait dû être à la banque. Si tel est le cas, tout autre mécanisme de sécurité fourni par la banque est également nul et non avenu.
Si vous supposez que le navigateur ou l'application dispose d'une autorité CA supplémentaire (comme cela est souvent fait par les employeurs), le client est essentiellement compromis. Si vous ne faites pas confiance à la liste des autorités de certification, pourquoi croiriez-vous que le navigateur n'a pas de hooks - ou d'ailleurs un enregistreur de frappe?
Si cela se fait à partir d'une application que vous écrivez, vous devriez pouvoir obtenir le certificat TLS pour votre connexion. Cela devrait être possible pour Java dans un navigateur, (mais apparemment pas à partir de Javascript). Vous êtes toujours, bien sûr, en supposant que l'application/le programme Java n'a pas été falsifié - il y a aucun moyen d'exécuter du code approuvé sur une plate-forme non approuvée.
Si vous disposez d'une connexion TLS utilisant Diffie-Hellman, il n'est pas possible de décrypter les données capturées, même avec la clé privée (citation: https://support.citrix.com/article/CTX116557 ).
Une attaque man-in-the-middle fonctionnera même pour un Diffie-Hellman (si l'attaquant a la clé privée et le certificat, ils ne peuvent pas être distingués du propriétaire légitime).
Mon opinion personnelle est que, si quelqu'un falsifie/essaie de falsifier mes données, je ne veux pas d'une autre couche de cryptage, je veux qu'on me le dise (et qu'on me refuse le service).
Remarque également: j'ai vu des certificats CA supplémentaires installés par un logiciel anti-programme malveillant, afin qu'il puisse rechercher les logiciels malveillants fournis par https.