Comment atténuer STARTTLS MITM (dégradation et certificates falsifiés) entre les servers de messagerie?

Je ne suis pas aussi techniquement incliné que la plupart sur ce site, alors gardez cela à l'esprit. Je voulais en savoir plus sur la security des e-mails, donc j'ai fait des searchs et tout est conforme à ma compréhension, alors, corrigez-moi, le cas échéant. La connection entre le client et le server (MSA / MTA?) Peut être chiffrée, mais le encryption entre server vers server (MTA vers MTA?) Dépend de chaque server prenant en charge les STARTTLS. Les STARTTLS peuvent également être implémentés entre le client et le server.

La seule faiblesse de STARTTLS que j'ai rencontré est que la connection peut être acceptée sur le encryption ou en text clair, de sorte qu'il rend une attaque MITM prétendument banale où le encryption peut être dégradé en text brut. De plus, je comprends qu'il y a un problème avec les certificates falsifiés, même si je ne sais pas si cela est directement lié au MITM.

J'ai lu que c'est un problème avec la mise en œuvre plutôt que le protocole lui-même. Certaines solutions auxquelles j'ai rencontré ont impliqué la configuration du client pour avertir quand la connection ne se produit pas sur SSL / TLS ou pour supprimer complètement la connection. Existe-t-il une façon appropriée de mettre en œuvre les STARTTLS afin que MITM ne soit pas possible (plutôt que de réagir quand cela se produit, si cela a du sens) et où cela se produirait-il? Ces corrections sont-elles destinées à couvrir la connection server à server ou simplement le client au server? J'aimerais également savoir un peu plus sur le problème avec de faux certificates, comment cette faiblesse est possible et comment l'aborder, soit par la mise en œuvre, soit par d'autres moyens.

Je suis surtout intéressé par la security entre le server au server car le server au client semble être less grave et déjà pris en charge par la plupart des ESP. Existe-t-il une meilleure alternative à STARTTLS? Comme je l'ai mentionné, je suis nouveau sur tout cela et j'aurai besoin d'une instruction complète sur la plupart des choses, y compris la façon de mettre en œuvre / configurer. Si personne ne peut fournir cela ici, j'apprécierais tout point dans la bonne direction en ce qui concerne les ressources d'apprentissage.

SUR LE SIDE … Je suis également intéressé à apprendre des attaques / exploits réels et je me demandais si le type de MITM (server à server) mentionné ci-dessus est quelque chose qui peut être ciblé sur une connection spécifique (adresse email de destination?) ou est plus proche de saisir tout ce qui se passe chez passby.

Il y a plusieurs problèmes avec le transport de courrier électronique de manière sécurisée et ces questions peuvent être mieux posées à security.stackexchange.com. Le courrier peut être intercepté à différentes étapes:

  • TLS explicite (STARTTLS) et TLS implicite (SMTPS) fournissent la security hop-by-hop et pas de bout en bout, c'est-à-dire que chaque server de messagerie entre les deux a access au courrier non crypté.
  • Le prochain bond pour un courrier est déterminé en recherchant l'logging MX via DNS. Cela peut être falsifié à less que DNSSec ne soit utilisé, ce qui n'est généralement pas le cas. Si elle est falsifiée, même une vérification correcte des certificates dans la poignée de main TLS ne sera pas utile, car elle vérifiera que la connection au mauvais MTA est correcte.
  • MX est uniquement défini pour utiliser le server au port 25, c'est-à-dire avec TLS explicite (STARTTLS). Étant donné qu'il n'y a aucun moyen pour le MTA d'envoi de savoir si le MTA de réception supporte même les STARTTLS, la connection peut être réduite à l'aide d'un attaquant man-in-the-middle en modifiant la list de l'extension prise en charge dans la réponse à la command EHLO ou en refusant la command STARTTLS. Et même un pirate n'ayant aucun moyen d'intercepter directement la connection, il pourrait être possible d'injecter des packages TCP RST au début de la poignée de main TLS afin que le client pense qu'il y a des problèmes d'utilisation de TLS et returnnera en text brut. Étant donné qu'il existe en fait assez de problèmes réels avec le handshake TLS, le client pourrait ne pas se méfier.
  • Et dans la poignée de main TLS, souvent, aucune validation correcte n'est effectuée. Parfois, aucun certificate n'est vérifié, parfois seulement la string, mais pas si le nom d'hôte correspond, etc. Mais encore une fois, si MX est déjà falsifié, la validation peut être effectuée contre le mauvais server de toute façon 🙁

Ce qui signifie que le encryption hop-by-hop peut être suffisamment sécurisé, vous devez append des corrections non sortingviales à plusieurs endroits et la plupart d'entre eux ne contrôlent pas un MTA d'envoi.

Pour se renseigner sur les questions des commentaires:

1.) STARTTLS est-il normalement implémenté entre les servers ou commence-t-il à partir du server client et procède de hop to hop?

Les STARTTLS doivent être implémentés sur chaque saut (MTA). Il peut être utilisé uniquement si le MTA de réception prend en charge STARTTLS et le MTA d'envoi peut le faire. Cela ne dépend pas de la façon dont le courrier a été livré au démarrage initial (MTA) du client. Généralement, TLS avec SMTP ne crypte que la connection entre les sauts, de sorte qu'il peut être lu en clair sur chaque saut s'il n'est pas crypté de bout en bout aussi bien (avec PGP ou S / MIME).

2.) Le courrier chiffré par PGP ou S / MIME peut-il encore être redirigé par spoofing MX?

Oui, il peut encore être redirigé. Mais le courrier lui-même ne peut être décrypté que par le destinataire réel, c'est-à-dire le propriétaire de la key cible.

3.) DNSSEC doit-t-il être adopté à grande échelle pour être utile ou est-ce quelque chose dont un individu peut bénéficier en configurant sur son propre server de messagerie?

Chaque bit aide, mais seulement un peu. Et notez que cela ne nécessite pas seulement les loggings DNSSec, mais le MTA de transmission doit effectivement utiliser DNSSec. La plupart des MTA ne font probablement que le DNS et ne se rendent pas count s'ils obtiennent un logging MX falsifié.

4.) Vous devez vous soucier de l'injection TCP RST pour les tl implicites ou tout simplement explicite?

Le TLS implicite n'est utilisé que du client au MTA, c'est-à-dire au saut initial. Il s'agit de l'étape la plus sécurisée car elle contrôle effectivement le client et le client utilise habituellement un server SMTP fixe avec des parameters TLS fixes, donc pas de problème avec la falsification MX et les déclassments de connection. Si le client est configuré pour utiliser TLS uniquement si disponible, l'attaque pourrait également fonctionner contre TLS implicite.

5.) Vous ne pouvez pas configurer le server / MTA pour supprimer la connection (courrier électronique de rebond) si un autre MTA n'est pas compatible TLS, c'est-à-dire passer d'opportuniste à nécessaire ou est-ce quelque chose que vous ne pouvez faire que sur le client (comme Thunderbird) pour connection client-server?

La plupart des servers peuvent être configurés de cette façon, mais la plupart des servers doivent parler à une variété de servers et ils ne savent pas à l'avance si le server prend en charge TLS. Mais sendmail par exemple peut être configuré pour parler uniquement TLS à des servers spécifiques ou ne pas parler TLS à d'autres servers spécifiques. Ainsi, cette configuration peut être durcie pour les servers connus, mais cela doit se faire manuellement.

6.) Si le # 5 est possible et le courrier électronique rebondit, l'expéditeur recevra-t-il un avis "échoué à envoyer"?

Oui, c'est généralement le cas, comme avec toutes les erreurs de livraison. Mais comme la plupart des autres erreurs de livraison, les personnes susceptibles de répondre techniquement peuvent comprendre ces messages d'erreur.

7.) En ce qui concerne les certificates qui ne sont pas contrôlés, c'est quelque chose qui peut être corrigé avec une configuration / implémentation appropriée. J'ai lu que l'une des questions était que beaucoup de certificates sont auto-signés et que la plupart des MTA les acceptent par défaut afin qu'ils puissent restr compatibles avec d'autres MTA. Est-ce que cela fait partie de ce dont vous parlez?

Cela dépend du server. L'heure de Lat que j'ai regardé Postfix était bien mais sendmail ne pouvait pas vérifier correctement le nom d'hôte contre le certificate. Et oui, auto-signé est un problème et l'autre problème principal manque des certificates intermédiaires. Mais puisque la livraison de courrier fonctionne de toute façon (puisque les erreurs de certificate sont ignorées par l'expéditeur), la plupart des administrateurs ne réalisent pas la mauvaise configuration ou ne se soucient pas.

8.) Enfin, disons que tous les correctifs non sortingviaux ont été mis en place, et je comprends que l'autre MTA / client est hors de mon contrôle. Est-ce que ces attaques MITM et d'injection ciblent des connections spécifiques allant vers et depuis mon adresse email? Dans cette situation, ils n'ont pas brisé dans mon server et ils n'ont aucune expérience préalable avec mes contacts.

Encore une fois, ce n'est que le chiffrement hop-by-hop et le courrier est disponible en clair pour la lecture et la modification de chacun des sauts. Ainsi, un attaquant sur l'un des sauts impliqués dans le transfert (habituellement au less deux, l'un sur l'expéditeur et l'autre au site des destinataires) peut intercepter et modifier également les mails et peut évidemment se limiter à traiter uniquement les mails sélectionnés. La seule protection est le chiffrement de bout en bout à l'aide de PGP ou S / MIME.