Pourquoi le TLS peut ne pas suffire pour votre stratégie de chiffrement des e-mails

Pourquoi le TLS peut ne pas suffire pour votre stratégie de chiffrement des e-mails

L’ère numérique a révolutionné notre façon de vivre ainsi que le fonctionnement des entreprises. Aujourd’hui, les entreprises bénéficient d’un engagement beaucoup plus important avec leurs clients. Ces entreprises disposent également de beaucoup plus de données à leur disposition pour mieux comprendre leur activité. Ces données permettent aux entreprises de combler les lacunes d’efficacité, d’identifier les opportunités de croissance et de mieux servir leurs clients.

Ces données, sans surprise, sont incroyablement précieuses. Leur protection est donc devenue essentielle à la survie d’une entreprise dans un marché très concurrentiel. Lorsque les organisations protègent leurs informations personnelles identifiables (PII), informations médicales protégées (PHI), propriété intellectuelle (IP) ou autres informations confidentielles, elles assurent la continuité de l’entreprise, démontrent leur conformité aux réglementations sur la confidentialité des données et préservent leur réputation.

Les entreprises doivent protéger leurs informations sensibles, qu’elles soient stockées sur des serveurs ou partagées par e-mail ou autre canal de communication. La sécurité de la couche de transport (TLS) est devenue une partie importante de la stratégie de sécurité des e-mails de chaque organisation, car elles luttent pour se conformer à des réglementations telles que la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS), la loi sur la portabilité et la responsabilité de l’assurance maladie (HIPAA), et le Règlement général sur la protection des données de l’Union européenne (RGPD).

L’activation de TLS, cependant, ne garantit pas que vos e-mails sont à l’abri des regards indiscrets. En fait, de nombreuses organisations utilisent toujours mal TLS, ce qui rend leurs e-mails vulnérables à l’accès non autorisé et aux fuites de données.

Comment fonctionne TLS ?

Pour qu’un site web ou une application utilise TLS, il doit avoir un certificat TLS installé. Un certificat TLS est délivré à la personne ou à l’entreprise qui possède un domaine. Le certificat contient des informations importantes sur le propriétaire du domaine et la clé publique du serveur, qui sont importantes pour valider l’identité du serveur.

Une connexion TLS est initiée à l’aide d’une séquence connue sous le nom de poignée de main TLS. Lorsqu’une personne visite un site web qui utilise TLS, la poignée de main TLS commence entre l’appareil de l’utilisateur (également connu sous le nom d’appareil client) et le serveur web.

Pendant la poignée de main TLS, l’appareil de l’utilisateur et le serveur web :

  • Spécifient la version de TLS (TLS 1.0, 1.2, 1.3, etc.) à utiliser,
  • Décident des suites de chiffrement à utiliser,
  • Authentifient l’identité du serveur à l’aide du certificat TLS du serveur, et
  • Génèrent des clés de session pour chiffrer les messages entre l’appareil de l’utilisateur et le serveur web une fois la poignée de main terminée.

Qu’est-ce qu’une Autorité de Certification (CA) ?

Une autorité de certification (CA) est une organisation qui agit pour valider les identités des entités (par exemple, les sites web, les adresses e-mail, les entreprises ou les individus) et les lier à des clés cryptographiques en émettant des documents électroniques connus sous le nom de certificats numériques.

Un certificat numérique fournit les éléments suivants :

  • Authentification – sert de justificatif pour valider l’identité de l’entité à laquelle il a été délivré.
  • Chiffrement – pour une communication sécurisée sur des réseaux non sécurisés.
  • L’intégrité des documents signés avec le certificat de sorte qu’un tiers en transit ne puisse pas les modifier.

Quelle est la différence entre TLS et SSL ?

TLS a évolué à partir d’un protocole de chiffrement précédent appelé secure sockets layer (SSL), développé par Netscape. La version 1.0 de TLS a commencé à être développée comme la version 3.1 de SSL, mais le nom du protocole a été changé avant la publication pour indiquer qu’il n’était plus associé à Netscape. En conséquence, les termes TLS et SSL sont parfois utilisés de manière interchangeable.

Potentialités des vulnérabilités avec TLS

Bien que TLS et SSL forment sans aucun doute une base essentielle pour l’approche de toute entreprise en matière de sécurité des données, ils contiennent encore des vulnérabilités.

La principale faiblesse provient du manque de compréhension des entreprises en matière de chiffrement des e-mails, beaucoup croyant que le canal de transport, et donc l’e-mail, est entièrement sécurisé chaque fois que TLS est utilisé.

Les entreprises, cependant, doivent se rappeler que les messages électroniques voyagent entre le serveur de messagerie de l’expéditeur et du destinataire, un canal qui comprend des sauts en dehors de leur réseau. Un e-mail est uniquement protégé jusqu’au prochain saut de courrier, et il n’est pas possible de contrôler ce qui lui arrive une fois qu’il atteint le prochain saut du protocole de transfert de courrier simple (SMTP).

Un message confidentiel pourrait donc être exposé à l’intérieur du réseau de l’entreprise, car TLS ne fournit pas de chiffrement de bout en bout. TLS sécurise uniquement le canal de l’appareil de l’expéditeur au serveur de messagerie de l’entreprise. Mais les e-mails sont souvent transférés via des serveurs supplémentaires où le chiffrement ne peut être garanti.

Par exemple, dans le cas de la vérification antivirus et de l’analyse de contenu, les données peuvent être exposées à des administrateurs curieux ou à d’autres employés en cours de route.

Un autre risque de sécurité réside dans les certificats X.509 utilisés. De nombreuses entreprises ne parviennent pas à valider leurs certificats, laissant toutes leurs données sensibles exposées.

Les entreprises doivent s’assurer que les certificats ont été délivrés par une autorité de certification (CA) digne de confiance et réputée. C’est tout sauf trivial, car de nombreuses entreprises signent elles-mêmes leurs certificats.

Les entreprises doivent également vérifier si les certificats sont valides et si les algorithmes de chiffrement et les longueurs de clé sont actuels (lire : à la pointe de la technologie).

De nombreuses entreprises, en particulier celles qui utilisent OpenSSL, créent leurs propres certificats, car c’est pratique et plus économique que les certificats d’une CA appropriée. Oui, les certificats coûtent de l’argent. Ils doivent être achetés et renouvelés. Si les entreprises oublient de renouveler, le certificat est finalement révoqué et les entreprises doivent payer la CA (à nouveau) pour un nouveau certificat.

Les entreprises ignorent souvent également que si elles utilisent une version TLS incorrecte qui ne déploie pas la “confidentialité parfaite à l’avance”, les messages peuvent être déchiffrés par des utilisateurs non autorisés qui découvrent les clés.

Une autre limitation de TLS connue est la configuration du système “TLS optionnel”. Avec le “TLS obligatoire”, le système d’origine ne transférera un message électronique que si le prochain système de la chaîne prend en charge TLS ; le message ne sera pas transféré si ce système ne prend pas en charge TLS. Cependant, si un système utilise un “TLS optionnel”, il transférera quand même le message, laissant ainsi le canal non chiffré et le message exposé.

Voici quelques raisons supplémentaires pour lesquelles TLS peut être insuffisant pour sécuriser vos communications par e-mail.

TLS défend les e-mails contre certains types d’attaques, mais pas tous

TLS à lui seul n’est pas suffisant pour la sécurité des e-mails, car il ne protège que contre certaines formes d’attaques par e-mail. TLS est particulièrement efficace contre les attaques de l’homme du milieu et les attaques d’écoute, qui se produisent pendant que les données sont en transit. Si vous avez des informations sensibles stockées sur vos serveurs ou bases de données, vous devez utiliser un protocole de chiffrement supplémentaire comme Pretty Good Privacy (PGP) ou Secure/Multipurpose Internet Mail Extensions (S/MIME).

Ces protocoles de chiffrement garantiront que si un pirate accède au serveur, il ne pourra pas lire les données chiffrées. Et parce que ces protocoles ne dépendent pas de l’envoi de texte en clair sur le fil, ils sont moins susceptibles d’être analysés par le trafic et d’autres attaques par canal auxiliaire qui surveillent les flux de communication chiffrés.

TLS peut être vulnérable aux attaques de rétrogradation

TLS est généralement utilisé pour sécuriser les connexions entre votre ordinateur et un serveur, comme lorsque vous vous connectez à votre e-mail à l’aide d’un navigateur. Mais il peut également être utilisé pour d’autres connexions, comme l’envoi d’e-mails d’un serveur à un autre.

Le problème avec cette approche est que la connexion entière n’est pas chiffrée. Seules les données entre les serveurs d’envoi et de réception sont chiffrées – et ces serveurs peuvent ne pas avoir une sécurité forte. Une attaque de rétrogradation pourrait intercepter le trafic sur un lien non chiffré et lire les messages au fur et à mesure qu’ils passent. À moins que vous n’ayez un chiffrement de bout en bout, vous pourriez mettre vos données et votre organisation en danger.

TLS a besoin d’une poignée de main plus robuste

TLS est le protocole de chiffrement le plus couramment utilisé aujourd’hui, mais il a toujours des limites. Pour garantir que les e-mails de votre entreprise sont sécurisés et chiffrés dès le départ, utilisez STARTTLS avec des algorithmes de chiffrement tels que PGP ou S/MIME.

De cette façon, même si quelqu’un intercepte vos e-mails en transit, il ne pourra pas les lire sans votre clé privée. Cela rend également plus difficile une attaque de type homme-du-milieu en ajoutant une couche supplémentaire de chiffrement au-dessus de la poignée de main TLS initiale.

Si vous avez des informations confidentielles qui doivent être transmises de manière sécurisée, envisagez d’ajouter une autre couche de protection en chiffrant vos e-mails via un fournisseur de services tiers.

Kiteworks pour une sécurité et un chiffrement de bout en bout

Kiteworks est plus qu’un fournisseur d’e-mails sécurisés. Il sert de réseau de contenu privé (PCN) pour la gouvernance, la conformité et la sécurité liées à l’envoi et à la réception de contenu sensible au sein, à travers et en dehors d’une organisation.

Kiteworks fournit un chiffrement de niveau entreprise et des contrôles de sécurité uniformes via une passerelle de chiffrement d’e-mails et un plugin Microsoft Outlook, une application web, un plugin d’application d’entreprise ou une application mobile. Il offre également une automatisation des politiques basée sur les rôles pour garantir la sécurité et la conformité des informations les plus sensibles d’une organisation.

Programmez une démonstration personnalisée pour découvrir comment Kiteworks automatise l’envoi et la réception d’e-mails contenant des informations confidentielles, quel que soit le standard de chiffrement utilisé.

Ressources Supplémentaires

Get started.

It’s easy to start ensuring regulatory compliance and effectively managing risk with Kiteworks. Join the thousands of organizations who feel confident in their content communications platform today. Select an option below.

Lancez-vous.

Avec Kiteworks, se mettre en conformité règlementaire et bien gérer les risques devient un jeu d’enfant. Rejoignez dès maintenant les milliers de professionnels qui ont confiance en leur plateforme de communication de contenu. Cliquez sur une des options ci-dessous.

Jetzt loslegen.

Mit Kiteworks ist es einfach, die Einhaltung von Vorschriften zu gewährleisten und Risiken effektiv zu managen. Schließen Sie sich den Tausenden von Unternehmen an, die sich schon heute auf ihre Content-Kommunikationsplattform verlassen können. Wählen Sie unten eine Option.

Table of Content
Partagez
Tweetez
Partagez
Explore Kiteworks