À propos des ports et du chiffrement dans les serveurs de messagerie

Lors de la configuration du serveur de messagerie sortant sur le client de messagerie, vous voyez 3 options de cryptage - sans cryptage, SMTPS et STARTTLS, ainsi que 3 ports possibles - 25, 465, 587. Que choisir et pour quoi - comprenons.

Vidéo

Précédent < Modes de fonctionnement des serveurs de messagerie
Suivant> Enregistrements DNS pour les serveurs de messagerie


Lorsque vous envoyez un message à quelqu'un, votre client de messagerie utilise le protocole ESMTP pour envoyer ce message, puis votre serveur de messagerie utilise le même protocole s'il doit transférer ce message à un autre serveur. Et tandis que tout le monde parle et écrit SMTP, il s'agit généralement d'ESMTP - le même SMTP, mais avec un ensemble d'extensions, telles que l'autorisation et le cryptage. Oui, une fois que SMTP n'a même pas pris en charge l'autorisation.



Maintenant un peu sur SMTPS. Une fois Internet était si simple que tout y était transmis en texte clair. Viennent ensuite les protocoles de chiffrement cryptographiques, le même SSL. Et les services qui transmettaient auparavant des informations sous une forme ouverte, ont commencé à envelopper le trafic dans SSL.



Mais il n'a pas été facile de le faire sur les mêmes ports standard - le client et le serveur doivent s'entendre sur une méthode de cryptage, et pour qu'un service sur un port fonctionne simultanément pour certains avec cryptage, et pour d'autres sans - cela nécessiterait des modifications dans les protocoles. Et afin de ne pas tout compliquer, ils ont commencé à sculpter des ports séparés pour les connexions cryptées - c'est ainsi que 443 pour HTTPS et 465 pour SMTPS sont apparus. Mais nous l'avons réalisé en ce moment - il y a peu de ports dédiés, le nombre de services augmente, et si chacun d'entre eux utilisera plusieurs ports avec cryptage et sans cryptage à leurs fins - problème.



Et à la fin, ils ont décidé de modifier un peu les protocoles. Dans certains cas, cela n'a pas très bien fonctionné, par exemple pour HTTP, et dans le cas de SMTP, cela s'est avéré être une option parfaitement adaptée. Pour cela, l'extension STARTTLS a été ajoutée à SMTP. En général, l'extension STARTTLS n'est pas seulement utilisée pour SMTP, en général c'est une commande pour démarrer les négociations de chiffrement. Contrairement à SMTPS, qui utilise un port dédié 465 et crypte immédiatement la connexion, STARTTLS n'est qu'une extension pour SMTP, ce qui signifie que la session est lancée en tant que session SMTP standard. Les serveurs de messagerie se saluent, puis proposent de commencer le cryptage et de sélectionner les protocoles cryptographiques disponibles.



En conséquence, avec l'avènement de STARTTLS des normes, ils ont décidé de supprimer SMTPS sur le port 465 en tant que service distinct. Ils l'ont retiré des normes, mais le service est resté et est toujours utilisé. En ce qui concerne le cryptage, je ferai toujours un sujet distinct, mais pour l'instant parlons de STARTTLS.



J'ai dit plus tôt qu'avec STARTTLS, les serveurs de messagerie ou un client / serveur ouvraient une connexion sans cryptage, puis convenaient du cryptage. Ils utilisent le même SSL / TLS pour le chiffrement. Mais que se passe-t-il s'ils ne peuvent pas s'entendre? Il s'avère qu'ils communiqueront sous forme non cryptée? Sur Internet? Pendant ce temps, ils acceptent sans aucun cryptage, trompant ainsi facilement le serveur ou le client par le manque de méthodes de cryptage disponibles. Et à un moment donné, ils ont attrapé l'un des fournisseurs dans une telle attaque. Et puis vous avez besoin d'un tel cryptage, demandez-vous. Tout n'est pas si désespéré. En fait, l'administrateur peut désactiver la possibilité d'envoyer du courrier s'il n'est pas possible de s'entendre sur le chiffrement, et les clients de messagerie sont tenus d'avertir que le serveur ne prend pas en charge le chiffrement.



Et donc, nous avons compris qu'il y a SMTP qui fonctionne sur le port 25, il y a SMTPS qui fonctionne sur 465, mais il y a un autre port - 587, qui est également utilisé par le serveur de messagerie.



Comme vous l'avez remarqué, les clients de messagerie se connectent aux serveurs via SMTP. Et les serveurs de messagerie se connectent également via SMTP. J'ai également dit dans la dernière partie qu'il existe de tels serveurs - des hôtes relais qui transfèrent le courrier. Pour certaines raisons, principalement humaines, il existe des hôtes relais sur Internet qui permettent aux utilisateurs non autorisés de rediriger les messages depuis n'importe quelle adresse. Et ces hôtes apparaissent chaque fois qu'un administrateur négligent soulève le serveur de messagerie, et cela se produit souvent. En conséquence, les attaquants lèvent des serveurs temporaires ou infectent les ordinateurs des utilisateurs qui envoient du spam via ces relais à des hôtes sans autorisation.



Par conséquent, certains fournisseurs Internet bloquent toutes les connexions utilisateur au port 25.



Ce port est ouvert entre les serveurs sur Internet, mais ils ont créé un service distinct pour les utilisateurs - MSA (agent de soumission des messages - agent d'envoi), séparant ainsi les connexions utilisateur des connexions serveur qui communiquent toujours via MTA. En général, MSA fonctionne même sur le port 25, mais le port officiel est le 587. Qu'est-ce qui empêche les spammeurs d'utiliser ce port? Le fait que le MSA, en règle générale, nécessite une autorisation de l'utilisateur. Ce n'est pas la seule raison de l'existence de MSA - car il fonctionne avec les clients de messagerie, il est mieux optimisé pour le travail des clients - il avertit immédiatement de toute erreur dans les messages, par exemple, l'absence de l'adresse de domaine du destinataire.



Et enfin, suivons le processus d'envoi d'un e-mail. Pour ce faire, utilisez Wireshark, un client de messagerie et un compte Gmail. Tout commence par la négociation TCP standard, après quoi la session SMTP est lancée. Dans la session, le client de messagerie et le serveur se saluent, après quoi le client de messagerie propose de crypter la session, le serveur accepte, après quoi les clés sont échangées et la session TLSv1.3 commence, après quoi le client se connecte crypté et envoie un message qui n'est pas visible pour un intercepteur de trafic.