Postfix, etc. : Quels ports péférer ?

Support Debian
#1

Sur l’utilisation et donc l’autorisation des ports utilisés par un serveur de courrier, on lit sur le web des tas d’avis qui doivent être plus ou moins fondés.
J’aimerais trier le vrai du faux, ou de l’obsolète.
réception des mails : 25 vs 587 ou 465 ?
relevé des mails POP : 110, autres ?
relevé des mails IMAP : 143, autres ?
relevé des mails IMPAP SSL : 993, 995 ?
(J’ai lu, entre-autres, que 993 était “déprécated”)

Il y a certainement des erreurs dans mes appellations .

L’avis des connaisseurs m’intéresse, pour mener à bien mes essais de serveur pour mon fils.

#2

Je vais prendre le cas de SMTP mais c’est la même chose pour POP3 et IMAP.

A l’origine, SMTP utilise le port 25. Mais le protocole n’était pas sécurisé, la communication était en clair. On a donc créé une variante sécurisée sur le modèle de HTTPS, avec chiffrement implicite. On intercale une couche SSL entre la connexion TCP et le dialogue SMTP. Le chiffrement SSL est dit implicite car le client et le serveur savent que la communication va être sécurisée, et commence par un dialogue SSL. Une fois la négociation SSL effectuée, le dialogue SMTP s’effectue.
Avantage : pas de modification du protocole SMTP.
Inconvénient : il a fallu définir un port différent car un serveur écoutant sur le port 25 ne s’attend pas à un dialogue SSL. Le port choisi est le 465, désigné SMTPS.

Plus tard on a créé une nouvelle variante sécurisée par TLS avec chiffrement explicite : le dialogue SMTP commence en clair puis le client demande au serveur de passer en TLS pour sécuriser la communication. Une fois la négociation TLS effectuée, le dialogue SMTP peut continuer.
Avantage : pas besoin de définir un autre port, on peut réutiliser le port 25 puisque le dialogue SMTP commence de façon non sécurisée.
Inconvénient : il a fallu modifier le protocole SMTP pour ajouter les commandes TLS (STARTTLS).

POP3 et IMAP ont suivi le même chemin.
Le port 110 est utilisé par POP3 en clair ou avec chiffrement TLS explicite.
Le port 995 est utilisé par POP3S avec chiffrement SSL implicite.
Le port 143 est utilisé par IMAP en clair ou avec chiffrement TLS explicite.
Le port 993 est utilisé par IMAPS avec chiffrement SSL implicite.

Ensuite, les variantes avec chiffrement SSL implicite et les ports correspondants ont été déclarées “deprecated” (obsolètes et déconseillées) au profit des variantes avec chiffrement TLS explicite. Mais rien ne t’empêche de les utiliser si tes serveurs et tes clients les supportent.

PS : le port 587 est réservé au protocole “Submission” qui est un sous-ensemble de SMTP utilisé entre un client et un serveur relais sortant (alors que SMTP est normalement utilisé entre deux serveurs).

3 J'aime
#3

Wahoooooooo !
Je ne regrette pas d’avoir posé ma question, là, au moins, je sais à quoi m’en tenir.
Je n’ai pas encore tout digéré mais en relisant plusieurs fois, je crois que j’arriverai à savoir ce qui convient le mieux dans mon cas.
Mon fils vient à la maison demain, j’en profiterai pour lui demander quels sont ses habitudes de mails.
merci
@+

#4

Si j’ai bien ingurgité, il est plus pratique d’utiliser les ports
25, 110 et 143 … à condition de chiffrer avec STARTTLS et non SSL/TLS.
Question subsidiaire :
j’ai eu du mal à comprendre comment générer clefs/autocertification pour que ça fonctionne en SSL/TLS, mais j’y suis parvenu quand même.
Devrais-je refaire cette opération de clef/certification pour passer à STARTTLS ?

EDIT :
Il semble que ça fonctionne, après acceptation du certif, bien sûr.
Essais effectués entre mon serveur distant et mon serveur d’essai.

#5

Plus pratique, bof. Ça permet d’utiliser le même port en clair ou en sécurisé si le serveur le supporte et si le client le demande. Le risque, c’est que la connexion soit en clair si on a mal configuré le client alors qu’on veut qu’elle soit sécurisée.

STARTTLS est juste la commande qu’envoie le client pour demander le passage en TLS.

C’est toujours le problème avec les certificats auto-signés. Mais si les postes clients sont peu nombreux et connus, il est possible d’installer le certificat sur chacun d’eux. Le risque d’accepter un certificat non validé lors de la première connexion, c’est qu’il est impossible de vérifier qu’on dialogue avec le bon serveur et non avec un usurpateur qui va intercepter la communication et voir tout le contenu en clair.

#6

[quote=“PascalHambourg, post:5, topic:68848”]…
Le risque, c’est que la connexion soit en clair si on a mal configuré le client alors qu’on veut qu’elle soit sécurisée.[/quote]
Ça répond à la question que je voulais te poser :
J’ai testé en envoyant un mail à chacun de mes trois enfants, qui ont des boites différentes.
N°1 = yahoo.fr, il a reçu mais il ne m’a pas précisé s’il avait eu une alerte. Je viens de lui demander cette précision.
N°2 = Gmail.com, mail refusé à l’envoi
N°3 = Cegetel.net, reçu mais sans message d’alerte.

Peut-on savoir si de mon côté l’envoi est bien effectué de façon chiffrée ?

[quote=“PascalHambourg, post:5, topic:68848”]…
Le risque d’accepter un certificat non validé lors de la première connexion, c’est qu’il est impossible de vérifier qu’on dialogue avec le bon serveur et non avec un usurpateur qui va intercepter la communication et voir tout le contenu en clair.
[/quote]
Les envois suivants ce premier, susceptible d’être intercepté par un malveillant, sont-ils sûrs ou ledit malveillant peut-il les lire ?

#7

Si j’ai bien compris ce que tu avais écrit dans un sujet précédent, ton courrier sortant est envoyé directement au relais sortant (smarthost) du FAI, sans passer par ton serveur. Si ton client n’a pas de logs contenant cette information, le seul moyen consiste à faire une capture de trafic complète de la communication entre le client et le serveur, par exemple avec wireshark, pour vérifier que le contenu est chiffré.

Pour les messages entrants reçus par ton serveur, il faut regarder ses logs.

Le malveillant bien placé peut intercepter tous les envois. Une fois que le client a accepté le certificat du malveillant, il n’affichera plus d’alerte. Il est donc très important lors de la première connexion de vérifier qu’on s’adresse au bon serveur.

1 J'aime
#8

@PascalHambourg: Tu es une sacré bible de l’informatique quand même … et c’est vraiment appréciable d’avoir sous la main une telle connaissance, qui se fait référence, aussi.

J’aimerais avoir une précision, parce que ce que tu écris sur :

Et, idem pour les autres services … m’interpelle.

En effet, mes paramétrages MUA - Thunderbird - sont à l’écoute de ces ports …
Or, il est écrit “SSL/TLS”, autant pour le SMTP, que l’IMAP correspondant

Donc, la question qui vient : es-tu sûr que le service IMAPS, écoutant sur le port 993 ne discute qu’avec le chiffrement SSL, et non pas aussi du TLS ?
Est-ce un abus d’écriture ?

#9

Ben c’est bien sûr, je n’avais pas réfléchi que le malveillant (M) avait substitué mon certificat au sien. Donc, si je comprends bien le processus, à chaque fois que je crois envoyer un mail à toto, M intercepte mon mail, le modifie à sa convenance et l’envoie à toto avec mon entête. Ce dernier croit recevoir un mail de ricardo et en fait, il reçoit un mail de M.
S’il répond en “reply”, M reçoit la réponse, peut la modifier et me faire parvenir sa prose. je suis donc, à mon tour, victime de M.
Ai-je assez bien traduit en mode “pour les nuls” ?

D’où, ptet, l’intérêt de ne pas répondre en “reply”, mais avec un nouvel envoi initial ?

Question qui fait suite :
Le mode ‘implicite’ avec SSL, à condition qu’il soit accepté par le receveur, serait le plus sécurisant, voire sécurisé ?

#10

Pour moi, oui … si et seulement si, ce sont bien les chiffrements TLS qui sont utilisés …
C’est le même propos que pour les serveurs web ; il n’est pas recommand(é|able) d’utiliser les chiffrements SSL. Pour l’instant, on ne connaît pas de faille sur les chiffrements TLS.

D’où plutôt l’intérêt de rajouter une “surcouche” logicielle … l’usage de mail chiffré par gpg, et donc de bien utiliser les clés de chiffrage, par exemple ne pas se tromper entre clé privée et clée publique :stuck_out_tongue:, etc, etc…
Pour moi, c’est une réponse … mais est-ce que c’est forcèment la bonne !?!

#11

Oui, un peu. SSL est le prédécesseur de TLS (TLS 1.0 ressemble beaucoup à SSL 3.0), et les deux sont plus ou moins synonymes dans le langage courant.

#12

Donc, si je comprends bien ton propos :
Je “m’achète” des certificats auprès de n’importe quel CA, je configure correctement IMAP, et SMTP pour fonctionner avec lesdits certificats, en excluant les chiffrements SSL pour n’utiliser que TLS - tout comme je le fais/ferais pour HTTP - je ne pourrais pas me connecter sur les ports dits sécurisés, correspondant à IMAPS, SMTPS, qui eux ne fonctionnent qu’avec les chiffrements SSL … puisque pour la gestion TLS, cela passe (obligatoirement ?!) par le mode STARTTLS.
Est-ce bien cela ?

#13

Non, tu n’as pas compris. TLS est aussi utilisable sur les ports sécurisés avec chiffrement implicite.
Partout où il y a écrit SSL, tu peux mettre TLS à la place.

2 J'aime
#14

Ça ne marche pas tout-à-fait comme ça. TLS/SSL intervient sur la connexion TCP qui sert à transmettre le mail (ou n’importe quel autre contenu), pas sur le mail lui-même. Le mail est un cas particulier car il peut être retransmis plusieurs fois de serveur en serveur, sur des connexions distinctes, avant d’atteindre son destinataire. L’émetteur ne maîtrise la sécurité que de la connexion SMTP initiale, et le destinataire ne maîtrise la sécurité que de la connexion POP ou IMAP de relève de sa boîte.

Non, pas forcément, en tout cas ce n’est pas une conséquence de ce qui précède. Du point de vue des connexions SMTP, POP ou IMAP il n’y a pas de lien entre un mail et sa réponse et il n’y a aucune différence entre un mail initial et un mail de réponse.

Plus sécurisant seulement dans le sens où cela protège contre des erreurs de configuration qui laisseraient les communications en clair sur le port standard. Sur le port sécurisé, c’est forcément chiffré. Mais il faut souligner que le chiffrement implicite pour SMTP, POP ou IMAP n’est plus standard et que l’affectation des ports sécurisés pour ces protocoles a été révoquée.

#15

Donc, si je comprends mieux, il n’y a rien de (presque) parfait, sinon se déplacer et parler de bouche à oreilles avec son correspondant, et encore, à condition de se trouver, tous les deux seuls, au milieu du désert de Gobi, en attendant que les satellites soient de l’autre côté de la terre.

Cherchons donc le “moins mauvais”, quel est-il ?

#16

Perso, chiffrement implicite + GPG si le correspondant le v(e|a)ut bien ! :stuck_out_tongue: