La réponse dépend dans une certaine mesure de ce que vous entendez par "sans danger".
Premièrement, votre résumé ne rend pas vraiment compte de la différence entre SSL / TLS et STARTTLS.
- Avec SSL / TLS, le client ouvre une connexion TCP sur le "port SSL" attribué au protocole d'application qu'il souhaite utiliser et commence à parler immédiatement à TLS.
- Avec STARTTLS, le client ouvre une connexion TCP sur le "port en texte clair" associé au protocole d'application qu'il souhaite utiliser, puis demande au serveur "quelles extensions de protocole prenez-vous en charge?". Le serveur répond ensuite avec une liste d'extensions. Si l'une de ces extensions est "STARTTLS", le client peut alors dire "d'accord, utilisons TLS" et les deux personnes commencent à parler TLS.
Si le client est configuré pour exiger TLS, les deux approches sont plus ou moins sécurisées. Mais il y a quelques subtilités sur la façon dont STARTTLS doit être utilisé pour le rendre sûr, et il est un peu plus difficile pour l'implémentation de STARTTLS d'obtenir ces détails correctement.
Par ailleurs, si le client est configuré pour utiliser TLS uniquement lorsque ce dernier est disponible, et en texte clair lorsque TLS n’est pas disponible, le client peut commencer par essayer de se connecter au port SSL utilisé par le protocole. échoue, puis connectez-vous au port en texte clair et essayez d’utiliser STARTTLS, puis retenez-vous en texte clair si TLS n’est pas disponible dans les deux cas. Il est relativement facile pour un attaquant de faire échouer la connexion du port SSL (il suffit simplement de quelques paquets RST TCP bien synchronisés ou du blocage du port SSL). C'est un peu plus difficile - mais seulement un peu - qu'un attaquant vaince la négociation STARTTLS et fasse en sorte que le trafic reste en clair. Et ensuite, l'attaquant non seulement lira votre courrier électronique, mais capturera également votre nom d'utilisateur / mot de passe pour une utilisation ultérieure.
La réponse simple est donc que si vous vous connectez à un serveur dont vous savez déjà qu'il prend en charge le protocole TLS (comme cela devrait être le cas lorsque vous envoyez ou lisez du courrier électronique), vous devez utiliser SSL / TLS. Si la connexion est attaquée, la tentative de connexion échouera, mais votre mot de passe et votre courrier électronique ne seront pas compromis.
D'autre part, si vous vous connectez à un service dont vous ne savez pas s'il prend en charge TLS, STARTTLS peut être légèrement meilleur.
Lorsque STARTTLS a été inventé, les attaques "passives" utilisant uniquement l'écoute étaient très courantes, les attaques "actives" dans lesquelles l'attaquant injectait du trafic pour tenter de réduire la sécurité étaient moins courantes. Depuis environ 20 ans, les attaques actives sont devenues plus réalisables et plus courantes.
Par exemple, si vous essayez d'utiliser un ordinateur portable dans un aéroport ou un autre lieu public et essayez de lire votre courrier via le réseau wifi fourni, vous ne savez pas du tout ce que le réseau wifi fait avec votre trafic. Il est très courant que les réseaux wifi acheminent certains types de trafic vers des "mandataires" qui s'interposent entre vos applications clientes et les serveurs auxquels ils tentent de parler. Il est facile pour ces mandataires de désactiver STARTTLS et "essayer un port puis un autre" pour tenter de faire revenir votre client en texte en clair. Oui, cela se produit, et ce n'est qu'un exemple de la façon dont votre trafic peut être espionné par un réseau. Et de telles attaques ne se limitent pas aux agences à trois lettres soutenues par l'État,