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 pro
El día Saturday, November 16, 2013 a las 08:36:33PM -0500, Dave Thompson
escribió:
> > I was thinking more in a solution where the client reads the first 8
> > bytes from the socket and checks if the beginning of the GoodMorning
> > message is there in clear text (like "220 SLNP") and if not
> >
> From: owner-openssl-users On Behalf Of Matthias Apitz
> Sent: Friday, November 15, 2013 14:43
> El día Friday, November 15, 2013 a las 12:58:40PM -0500, Watson, Patrick
> escribió:
>
> > Traditionally, there are 2 methods that immediately come to mind. One
> way is to have the SSL version of th
> I was thinking more in a solution where the client reads the first 8 bytes
> from the socket and checks if the beginning of the GoodMorning message is
> there > in clear text (like "220 SLNP") and if not it should handover this
> buffer and the socket fd for further SSL handshake... Is this po
El día Friday, November 15, 2013 a las 12:58:40PM -0500, Watson, Patrick
escribió:
> Traditionally, there are 2 methods that immediately come to mind. One way is
> to have the SSL version of the server listen on a different port than the
> plain text version. Alternatively, your protocol could
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.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
OpenSSL Project
Traditionally, there are 2 methods that immediately come to mind. One way is to
have the SSL version of the server listen on a different port than the plain
text version. Alternatively, your protocol could include a "STARTTLS" like
command that indicates that the system wants to communicate secu
