Pourquoi quelqu'un "crypterait-il deux fois"?
Si j'ai un site Web ou une application mobile, qui parle au serveur via une connexion SSL/TLS sécurisée (c'est-à-dire HTTPS), et crypte également les messages envoyés et reçus entre l'utilisateur et le serveur en plus de la connexion déjà sécurisée, est-ce que je faire des mouvements inutiles? Ou le double cryptage est-il une méthode courante? Si oui, pourquoi?
Ce n'est pas rare, mais ce n'est peut-être pas nécessaire. De nombreux développeurs semblent oublier que le trafic HTTPS est déjà crypté - il suffit de regarder le nombre de questions sur la mise en œuvre du cryptage côté client sur ce site Web - ou de penser qu'il ne peut pas faire confiance en raison de problèmes bien connus tels que le - Lenovo SSL MitM mess .
Cependant, la plupart des gens n'ont pas été affectés par cela, et il n'y a pas d'attaques particulièrement viables contre TLSv1.2 pour le moment, donc cela n'ajoute pas vraiment grand-chose.
D'un autre côté, il existe des raisons légitimes de chiffrer les données avant leur transmission dans certains cas. Par exemple, si vous développez une application de stockage, vous souhaiterez peut-être chiffrer à l'aide d'une application côté client avec une clé connue uniquement de l'utilisateur - cela signifierait que le serveur ne serait pas du tout en mesure de déchiffrer les données, mais il pourrait encore le stocker. L'envoi via HTTPS signifierait qu'un attaquant ne devrait pas non plus être en mesure de récupérer les données chiffrées par le client, mais même s'ils le faisaient, cela n'aurait pas d'importance. Ce modèle est souvent utilisé par les gestionnaires de mots de passe basés sur le cloud.
Essentiellement, cela dépend de ce que vous défendez - si vous ne faites pas confiance à SSL/TLS, cependant, vous ne pouvez probablement pas non plus faire confiance au code de cryptage que vous envoyez (dans le cas de l'application Web)!
HTTPS ne fournit le cryptage que lorsque le message est en transit sur le réseau/Internet.
Si le message est stocké ou traité par un intermédiaire (par exemple une file d'attente de messages) à un moment donné entre le client et le serveur qui le traite finalement, il ne restera pas chiffré tant qu'il se trouvera dans l'intermédiaire.
De plus, si le TLS/SSL se termine au niveau des périmètres de service (par exemple sur un équilibreur de charge), il peut ne pas être crypté sur le réseau interne. Cela peut être un problème où une sécurité élevée est requise, par exemple dans certains environnements réglementés.
Dans ces deux cas, le chiffrement au niveau du message garantit que les données sont chiffrées à tous les points entre le client et le destinataire final.
Comme l'a dit @honze, cela s'appelle une défense en profondeur et vise à garantir que même si un système est partiellement compromis (par exemple, ils parviennent à faire une attaque de l'homme du milieu pour compromettre le SSL/TLS, ou à exploiter un vulnérabilité dans la file d'attente de messages pour accéder aux données au repos) l'attaquant ne peut pas accéder aux données protégées.
Je voudrais partager mon expérience sur la question du titre. Ce n'est pas vraiment lié à la question complète elle-même, mais cela répond à la question "pourquoi quelqu'un crypterait-il deux fois?"
Dans le passé, j'ai travaillé pour une organisation qui gère la communication entre les prestataires de soins (médecins, hôpitaux, etc.) et les organisations d'assurance (mutuelles). Nous avons en quelque sorte agi comme un routeur.
Le schéma était à peu près le suivant:
care provider 1 \ / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 / \ insuring organization 3
Nous avions la protection suivante:
- Cryptage de bout en bout: Le prestataire de soins 1 doit envoyer les informations du patient à l'organisation assureuse 1. Ces informations sont sensibles à la confidentialité et doivent donc être cryptées. À notre niveau, nous n'avons pas le droit de savoir quelles données sont envoyées à l'organisme assureur.
- Care-provider - router encryption: Le fournisseur de soins envoie des informations sous forme de métadonnées pour que nous puissions les gérer. Ces informations doivent être cryptées. Le contrat stipulait que les messages devaient encore être chiffrés, même à l'intérieur de notre réseau, de sorte qu'un seul de nos serveurs connaisse jamais les métadonnées des informations envoyées. Comme nous avons plusieurs canaux (équilibreurs de charge, pare-feu, etc.), le cryptage est également requis à ce niveau.
- HTTPS pour éviter les attaques MITM: Non seulement nos données devaient être protégées, mais les métadonnées HTTP devaient également être protégées, donc HTTPS.
J'espère que cela nous éclairera sur les raisons pour lesquelles plusieurs couches de cryptage peuvent être nécessaires.
Tu as raison. Il s'agit d'un concept de sécurité multicouche appelé défense en profondeur.
Les messages chiffrés sont susceptibles de traiter le chiffrement de bout en bout et le SSL/TLS traite le chiffrement des métadonnées. Il s'agit d'un modèle utile.
HTTPS est chiffré en transit et déchiffré aux extrémités. Donc, la situation évidente où vous voudrez peut-être double-chiffrer est où vous ne voulez pas une (ou peut-être les deux!) Des extrémités pour voir le effacer le texte.
Quelques situations auxquelles je peux penser du haut de ma tête:
e-mail crypté via les fournisseurs de messagerie Web. Si j'envoie un message crypté GPG via Gmail auquel j'accède via une connexion HTTPS, il est crypté deux fois. Parce que je ne veux pas que gmail en lise le contenu.
services de sauvegarde cryptés. Je veux utiliser HTTPS pour empêcher le vol de mes identifiants de connexion, mais je ne veux pas que le service de sauvegarde voie "à l'intérieur" les sauvegardes.
passerelles de paiement. Vous pourriez imaginer celui où un message chiffré est envoyé entre un jeton matériel de paiement sécurisé et une banque, via l'appareil non sécurisé d'un utilisateur et le site d'un marchand. Le lien au milieu devrait être HTTPS, mais ce n'est pas suffisant: il doit être chiffré sur le PC non sécurisé et le site Web du marchand moins sécurisé.
Notez que S/MIME prévoit un "triple enroulement" (signe/crypte/signe): https://tools.ietf.org/html/rfc2634 , donc si vous envisagez de signer ainsi que le chiffrement même plus de possibilités peuvent avoir du sens.
Je voulais donner une raison supplémentaire: la normalisation.
J'ai une application qui, pour des raisons de sécurité, toutes les données entrant et sortant doivent être cryptées. Comme il est déjà chiffré une fois, les données peuvent circuler sur les connexions http (héritées) et https (actuelles). Il est beaucoup plus logique de chiffrer deux fois que de créer une version de l'application qui s'exécute non chiffrée sur https et chiffrée sur http.
Il s'agit des meilleures pratiques lorsque vous traitez des informations très sensibles telles que des données financières, médicales, militaires ou psychologiques. L'idée de base des cryptages multiples est d'empêcher tout utilisateur non autorisé de récupérer les données. Supposons que les combinaisons initiales possibles pour la méthode de chiffrement étaient de 1 milliard. En appliquant une autre méthode de chiffrement par-dessus, nous pourrions multiplier les possibilités à 1b ^ 3. Cela nécessiterait qu'un utilisateur non autorisé prenne plus de temps pour déchiffrer les données. Bien que le cryptage ne soit toujours pas parfait, il vaut mieux.
Dans l'une des organisations dans lesquelles j'ai travaillé, nous avons utilisé plusieurs cryptages. Il s'agit d'une simplification du flux précédent:
- Auditer à la fois les périphériques et les composants client et serveur pour le dédouanement du logiciel
- Chiffrer les données sur le stockage
- Compresser les données
- Crypter les données avec un logiciel propriétaire
- Commencer la connexion avec le serveur
- Auditer à la fois les périphériques et composants clients et serveurs pour le dégagement sur la connexion
- Transmission de compression
- Envoyer des données via une connexion de chiffrement; Si la connexion est interrompue, redémarrez tout le processus.
- Une fois le dossier terminé, auditez les données pour en assurer la cohérence
Si vous ne traitez pas avec un environnement lourd en réseau avec des données sensibles, c'est exagéré.
La stratégie derrière cette méthode garantit que les périphériques, composants (MAC) et IP ont été authentifiés. Le chiffrement des données est une procédure standard, tout comme l'envoi via HTTPS. Certaines organisations vont au-delà de la sécurité de base et nécessitent également des réseaux de type darknet utilisant Freenet, I2P, IPsec/VPN ou Tor pour se connecter. Quel que soit le cryptage, la compression des données réduira les ressources de stockage et de réseau requises; cependant, cela compensera vos performances à RAM ou traitement. Enfin, la raison pour laquelle nous avons redémarré la connexion après une déconnexion est que nous avons découvert un moyen de détourner le flux de données via man-in-the-middle .
En fin de compte, il n'y a pas de moyen parfait pour crypter les données pour toujours, mais concentrez vos efforts sur le cryptage jusqu'à ce que les données ou les informations deviennent inutiles ou que vous produisiez un moyen supérieur de crypter les données.
Il existe un certain nombre de raisons pour envoyer des données chiffrées via une connexion chiffrée:
- même si le cryptage de la connexion est rompu (par exemple MitM, possible mais difficile avec HTTPS, et conduisant à l'interception de toutes les données transmises), les données sont toujours cryptées
- le serveur HTTPS peut ne pas être fiable et est responsable du relais des données vers un autre serveur
- de même, le serveur HTTPS peut relayer les données vers un autre serveur via une connexion non cryptée, et le fait que le client crypte les données avant la transmission réduit la charge sur le serveur HTTPS qui autrement devrait crypter les données de tous les clients au lieu de pouvoir les transmettre tout droit
Obfuscation de l'API
Même si toutes les communications sont cryptées via HTTPS, le client peut toujours avoir la possibilité de voir son trafic avant le cryptage avec divers outils de débogage. Surtout si vous utilisez un environnement de navigateur ou une application avec https fourni par un système sous-jacent.
Dans ce cas, vous pouvez crypter vos données avec une clé statique, afin que le client ne puisse pas facilement lire et manipuler le trafic. Bien sûr, ce n'est que de l'obscurcissement, car la clé doit être stockée quelque part sur la machine du client (au moins dans la RAM), mais avec le code source du logiciel, c'est toujours juste de l'obscurcissement. L'utilisateur devrait consacrer des efforts considérables à récupérer votre clé et à décrypter votre trafic pour lire et manipuler ses demandes.
Des exemples pourraient être un jeu basé sur le Web, qui soumet les joueurs au meilleur score.
Si j'ai bien compris, le réseau Tor fonctionne de cette façon:
Alice écrit une lettre à Dave et la chiffre trois fois: d'abord avec la clé de Dave, puis ajoute l'adresse de Dave, chiffre le paquet avec la clé de Craig, ajoute l'adresse de Craig et chiffre le paquet avec la clé de Bob.
Elle envoie ensuite la lettre à Bob, qui la déchiffre, trouve l'adresse de Craig et la lui transmet.
Craig la déchiffre, trouve l'adresse de Dave et la lui transmet. Dave le déchiffre et constate que la lettre est pour lui
Dans un monde parfait, personne, sauf Alice et Dave, ne pouvait désormais dire que Dave était bien le destinataire de cette lettre, car il POURRAIT ÊTRE qu'il avait trouvé l'adresse d'Emily dans l'enveloppe et l'avait transmise.
Une deuxième application serait de crypter un message avec à la fois votre clé privée et la clé publique du destinataire. Le destinataire déchiffre le message avec votre clé publique et sa clé privée, et peut ainsi obtenir l'information que le message est de vous et pour lui. Mais généralement, un HMAC est utilisé pour s'assurer que le message provient bien d'un certain expéditeur et n'a pas été falsifié.
La principale raison du chiffrement à plusieurs niveaux est la séparation des préoccupations.
Souvent, un ensemble de données peut être traité par plusieurs serveurs, éventuellement contrôlés par plusieurs organisations, qui ne font pas toutes entièrement confiance à l'ensemble des données. Dans la plupart des cas, la plupart de ces serveurs intermédiaires n'ont besoin d'agir que sur des parties des données, et donc s'ils n'ont pas besoin de voir certaines parties de données, cette partie peut être chiffrée. Vous donneriez l'accès intermédiaire aux données dont ils ont besoin pour voir chiffré dans une clé qu'ils ont et des blob chiffrés qu'ils peuvent transmettre à d'autres serveurs pour un traitement ultérieur.
L'exemple le plus simple est le courrier électronique avec cryptage GPG et TLS. La tâche principale d'un agent de transfert de courrier (relais de messagerie) est de transférer le courrier électronique d'un saut à l'autre. Ils doivent voir les informations de routage du courrier pour faire leur travail, mais ils ne devraient pas avoir besoin de voir les messages eux-mêmes. Ainsi, vous doublez la connexion de messagerie avec une clé que l'agent de transfert de courrier peut comprendre et le message avec une autre clé que seul le destinataire comprend.
Un autre exemple est le service de planification de calendrier/notification. Vous mettez des événements dans votre calendrier, pour être averti par votre application de calendrier que quelque chose se passe à un certain moment. Le calendrier n'avait pas besoin de savoir ce qu'est l'événement, qui est impliqué dans les événements, ni où se trouve l'événement.
Une raison secondaire du chiffrement multiple est une assurance au cas où l'une des couches de chiffrement serait rompue. OMI, c'est une raison beaucoup plus faible car vous devez considérer que chaque couche supplémentaire inutile augmente la complexité de la mise en œuvre et la complexité est l'ennemi de la sécurité.
Je ne vois pas cela mentionné ici, mais je pense que c'est un peu plus important qu'un commentaire. Ils pourraient le faire pour secret de transmission parfait . Un attaquant peut ne pas connaître la clé de votre connexion HTTPS, mais il peut enregistrer chaque octet et le stocker pendant des années. Ensuite, ils peuvent vous pirater sur la ligne, découvrir une vulnérabilité ou vous obliger à révéler la clé privée de votre serveur plus tard, puis revenir en arrière et décrypter vos messages. En ayant une clé éphémère temporaire chiffrant les messages sous la connexion HTTPS, l'attaquant serait toujours incapable de lire les messages, ou à tout le moins significativement retardé.
Pas exactement un problème HTTPS, mais un autre cas d'utilisation valide de double cryptage est couramment utilisé dans Tor au cas où "je ne crois pas le livreur et je veux rester anonyme en utilisant plus d'étapes".
Chaque "livreur" ne déchiffre que l'enveloppe pour découvrir l'autre livreur. Dans ce cas, la communication est encapsulée et chiffrée dans le proxy SOCKS.
Des failles dans les algorithmes et les implémentations existent probablement en ce moment, qui doivent encore être découvertes. Idéalement, ces défauts n'existeraient pas, mais ils existent.
Si vous chiffrez avec deux algorithmes différents et qu'un seul d'entre eux est défectueux, vous êtes toujours d'accord et vos données sont en sécurité. Si la première couche est cassée, un attaquant ne peut obtenir que du texte chiffré. Si la deuxième couche est cassée, un attaquant n'est pas en mesure de passer à travers la première couche.
Le double chiffrement (ou triple ou quadruple ou ..) peut être un bon moyen d'éviter de mettre tous vos œufs dans le même panier.
Pour éviter les problèmes de conformité PCI, lorsque le développeur souhaite utiliser une passerelle de paiement et confie la responsabilité de la conformité au tiers.
Les champs de la publication du formulaire peuvent être chiffrés côté client, de sorte que le développeur n'a pas de détails de carte non chiffrés qui transitent par leurs systèmes (donc un pas de plus que de ne pas les stocker).
Notamment, c'est au-dessus de HTTPS . Ainsi, le site Web ne voit même pas les données non cryptées, uniquement l'utilisateur et la passerelle de paiement.
Exemple avec la passerelle de paiement Brain Tree: https://www.braintreepayments.com/blog/client-side-encryption/