Voltei a isso depois de pensar por alguns dias e percebi que não é um problema. Aqui está o porquê:
Daemons habilitados para SSL ouvem em uma porta e esperam negociar a conexão SSL antes de fazer qualquer outra coisa. Se você se conectar e tentar fazer algo diferente de negociar SSL, dado onde você está no caminho do código, isso constitui um erro tão certo quanto se conectar a um servidor da Web e digitar MAIL FROM: [email protected]
. A conexão será simplesmente descartada. Tente conectar-se a um servidor da Web HTTPS na porta 443 e a emitir uma solicitação GET normal:
[madhatta@anni tmp]$ telnet www 443
Trying 193.219.118.100...
Connected to www.teaparty.net (193.219.118.100).
Escape character is '^]'.
GET /
[...]
<body>
<h1>Bad request!</h1>
<p>
Your browser (or proxy) sent a request that
this server could not understand.
E isso é bastante amigável, como os beijos SSL. Aqui está uma experiência semelhante com um servidor POP / S, na porta 995:
[madhatta@risby video]$ telnet www 995
Trying 193.219.118.100...
Connected to www.
Escape character is '^]'.
USER fred
Connection closed by foreign host.
Note que este é um comando POP totalmente legal; é só que nesse ponto da conversa, o daemon requer que eu construa uma conexão SSL primeiro, porque é isso que ele está configurado para fazer. Eu alimentei algo que não é SSL, e ele me deixou como uma batata leprosa.
Esta discussão não se aplica ao TLS, a propósito. O TLS, uma extensão dos protocolos SSL, permite explicitamente que uma conexão seja feita em texto não criptografado e, em seguida, negociada em uma conexão SSL por uma extremidade, tendo estabelecido que a outra extremidade é compatível com TLS.
Mas sua pergunta foi especificamente feita sobre o SSL, não sobre o TLS e, em qualquer caso, a solução é simples:
Execute um daemon na porta 12345 que exige o uso de SSL (isto é, não é compatível com TLS) e seu trabalho estará concluído.