Discussion :

[Lola21]

Bonjour à tous,

Je suis plutôt néophite dans tous ce qui est protocoles de sécurité et de cryptage.

J'ai compris les grandes lignes pour ce qui est de SSL et TLS (évolutions), mais je n'arrive pas à comprendre comment fonctionne startTLS.

J'ai pas mal cherché sur le net (j'ai un peu de mal avec les termes en anglais), mais je n'arrive pas à bien voir quel est l'avantage de StartTLS par rapport à SS/TLS. J'ai l'impression que c'est une histoire de ports, mais je ne saisi pas bien le concept ...

Est-ce que quelqu'un pourrait me l'expliquer de façon simple, svp ?

Merci beaucoup d'avance !

[Neckara]

Bonjour,

Au lieu d'établir une socket SSL, on va établir une socket "normale" sur le port "habituel" et on va demander dire au service qui écoute sur ce port que le reste des échanges doit se faire en SSL.

Sans startTSL :

• port X pour les communications en clair ;
• port Y pour les communications SSL.
• Le client se connecte au port Y et l'échange se fait directement en SSL.

Avec startTSL :

• un seul port d'écoute : X
• Le client se connecte au port X. Il échange en clair quelques informations avec le serveur.
• Il demande ensuite de continuer la "discutions en SSL".

L'avantage est donc tout bête : on n'utilise qu'un seul port d'écoute au lieu de deux.

[Lola21]

Merci beaucoup Neckara pour ta réponse !

C'est très clair pour moi maintenant sur le fonctionnement avec ou sans startTLS.

Par contre, pour un utilisateur lombda, quel est l'avantage d'utiliser un seul port ?
Le nombre de port est limité ?

Autre question sur différents cas particuliers (j'essaye de comprendre ce qu'il se passe sur 3 différents scénarios) :

Cas 1 :
Un utilisateur configure son logiciel de mail. Il indique StartTLS. Mais le serveur de mail (externe) ne supporte pas des protocoles de sécurité. Il va donc recevoir une alerte de communication non sécurisée. Des modifications sont apportées sur le serveur
a : Le serveur désormais supporte TLS/SSL mais pas StartTLS.
Est-ce que la communication devient sécurisée automatiquement, ou l'utilisateur doit reconfigurer les paramètres de son logiciel de mails ?
b: Le serveur désormais supporte TLS/SSL et aussi StartTLS.
Est-ce que la communication devient sécurisée automatiquement, ou l'utilisateur doit reconfigurer les paramètres de son logiciel de mails ?

Cas 2 :
Un utilisateur configure son logiciel de mail. Il indique TLS/SSL. Mais le serveur de mail (externe) ne supporte pas des protocoles de sécurité. Il va donc recevoir une alerte de communication non sécurisée.
Des modifications sont apportées sur le serveur qui désormais supporte TLS/SSL
Est-ce que la communication devient sécurisée automatiquement, ou l'utilisateur doit reconfigurer les paramètres de son logiciel de mails ?

Merci encore pour les précisions.

[Neckara]

Par contre, pour un utilisateur lombda, quel est l'avantage d'utiliser un seul port ?

Pour le logiciel client, il n'y a plus qu'un seul port au lieu de deux à utiliser, c'est déjà légèrement plus simple.
Pour l'utilisateur, je ne pense pas que cela change grand chose.

Le nombre de port est limité ?

Oui, 65 536.
Mais si ton serveur est derrière un routeur (ou si ton service est dans un container/serveur virtuel), cela te fait qu'un seul port à rediriger au lieu de deux.
Après en réseau d'entreprise, d'université, etc. tous les ports ne sont pas ouvert, et si le port "normal" est ouvert mais pas le port "SSL" (no comment...) ceci "forcera" l'utilisateur à envoyer ses données en clair, ce qui n'est pas génial d'un point de vu sécurité.
Si on utilise le startTLS, soit le port est ouvert et on peut utiliser le service, soit il est fermé et on ne peut rien faire.


Je ne peux rien te dire car cela dépend du logiciel de messagerie utilisée.

Cas 1 :
a. Est-ce qu'après un échec StartTLS le client de messagerie tente de se connecter au "port SSL" ?
b. (et cas 2) Est-ce que le client de messagerie va retenter à chaque fois d'utiliser StartTLS ou va-t-il enregistrer une sorte de "préférence" pour utiliser directement le "port SSL" ?

[Lola21]

Merci encore Neckara !

si le port "normal" est ouvert mais pas le port "SSL" (no comment...) ceci "forcera" l'utilisateur à envoyer ses données en clair, ce qui n'est pas génial d'un point de vu sécurité.

Effectivement, ce n'est pas génial d'un point de vue sécurité ... Totalement d'accord !
Heureusement, cela va être très prochainement corrigé. Toute la question en ce moment est de savoir si les équipements doivent supporter ou non StartTLS, selon le bénéfice client.

Si on utilise le startTLS, soit le port est ouvert et on peut utiliser le service, soit il est fermé et on ne peut rien faire.

Est-ce que ça veut dire que la communication n'aura pas lieu ou qu'elle sera forcée à passer en clair ?

Je ne peux rien te dire car cela dépend du logiciel de messagerie utilisée.
Cas 1 :
a. Est-ce qu'après un échec StartTLS le client de messagerie tente de se connecter au "port SSL" ?
b. (et cas 2) Est-ce que le client de messagerie va retenter à chaque fois d'utiliser StartTLS ou va-t-il enregistrer une sorte de "préférence" pour utiliser directement le "port SSL" ?

Je comprends que cela va dépendre des logiciels de messagerie utilisés.
Je vais essayer de les tester et faire différents user cases sur les principales messageries existantes. Je ne connais absolument pas le comportement après un échec StartTLS ni les messages que peut recevoir un client quand il a ou pas StartTLS ...

Merci encore pour ton aide !

[Neckara]

Est-ce que ça veut dire que la communication n'aura pas lieu ou qu'elle sera forcée à passer en clair ?

Si le port est fermé, tu ne pourras faire aucune communication que ce soit en clair ou en SSL.

[Lola21]

Merci Neckara !

[abel.cain]

Quand on a déjà défini 2 ports standards pour distinguer "en clair" et "en SSL ou TLS", comme pour HTTP (ports 80, 443), alors aucun intérêt de changer quoi ce soit.

Mais la fixation de 2 ports standards différents pour chaque proto est un souci de surconsommation, donc à partir de maintenant on doit é-co-no-mi-ser!

[Lola21]

Merci pour vos retours.
En résumé, d'un point de vue utilisateur/client final, peu d'intérêt d'avoir du start TLS.

Je ferme la discussion.

Merci encore pour votre aide !

Bonne fin de journée !