Salz, Rich wrote:
The common practice is for clients to connect in the clear, then issue a command to turn
on TLS, such as the SMTP "STARTTLS" command.
It is only common practice for a small number of well known protocols.
This doesn't mean it is the best solution.
If you have a bespoke protocol then another option is to always issue a
plain-text banner. The banner information contains information as to
what is expected next.
This could be indicated by the status code number or by a keyword in the
banner information.
All clients should then decode a single line plain text banner, even if
they use SSL.
This also has the advantage of reducing an extra round trip, to issue a
plaintext command to upgrade the connection to SSL, then get a server
response. If the bespoke protocol server is enforcing SSL for all
connections.
This has the added advantage that all clients can check the banner
exists and is correct for the service and offer feedback to application
when it connected by nothing happened. This helps diagnostics knowing
you are connected to the correct service.
The problem is you can not actually send the banner inside the SSL
tunnel, until the SSL session is setup and to do that requires and
exchange of control data, before the payload data (the banner / greeting
message).
The client usualy initiates the SSL hello control message and the server
usualy wait patiently for SSL control data to start.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
