Je suis revenu sur cela après y avoir réfléchi pendant quelques jours, et j'ai réalisé que ce n'était pas un problème. Voici pourquoi:
Les démons activés SSL écoutent sur un port et s'attendent à négocier la connexion SSL avant de faire quoi que ce soit d'autre. Si vous vous connectez et essayez de faire autre chose que de négocier SSL, étant donné où vous êtes dans le chemin du code, cela constitue une erreur aussi sûrement que de vous connecter à un serveur web et de taper MAIL FROM: fred@example.com
. La connexion sera simplement abandonnée. Essayez de vous connecter à un serveur web HTTPS sur le port 443 et d'émettre une requête GET normale:
[madhatta@anni tmp]$ telnet www 443
Trying 193.219.118.100...
Connected to www.teaparty.net (193.219.118.100).
Caractère d'échappement est '^]'.
GET /
[...]
Requête incorrecte!
Et c'est assez aimable, pour des rejets SSL. Voici une expérience similaire avec un serveur POP/S, sur le port 995:
[madhatta@risby video]$ telnet www 995
Trying 193.219.118.100...
Connected to www.
Caractère d'échappement est '^]'.
USER fred
Connexion fermée par l'hôte distant.
Remarquez, il s'agit d'une commande POP tout à fait légale; c'est juste qu'à ce moment-là dans la conversation, le démon exige que je construise d'abord une connexion SSL, car c'est ce qu'il a été configuré pour faire. Je lui ai donné quelque chose qui n'est pas SSL, et il m'a rejeté comme une pomme de terre lépreuse.
Cette discussion ne s'applique pas au TLS, d'ailleurs. Le TLS, une extension des protocoles SSL, permet explicitement à une connexion d'être établie en texte clair puis négociée jusqu'à une connexion SSL par une extrémité, cette extrémité ayant établi que l'autre extrémité est compatible avec le TLS.
Mais votre question portait spécifiquement sur la SSL, pas le TLS, et de toute façon la solution est simple:
Exécutez un démon sur le port 12345 qui exige l'utilisation de SSL (c'est-à-dire n'est pas compatible avec le TLS) et votre travail sera fait.