Re: Mix of TCP and TLS in draft-rosenberg-midcom-turn-07.txt

Remi Denis-Courmont <[email protected]> Wed, 13 Jul 2005 15:26:39 +0300
Newsgroups gmane.ietf.midcom
Organization Nokia-NRC/Helsinki
Message-ID <[email protected]>
	Hello,

On Wed, 2005-07-13 at 12:22, ext Eric Hsu wrote:
> To "discriminate between TLS traffic and non-TLS traffic", 
(...)
> . Turn server listens on a normal TCP port, say 12345
> . Turn client connects to that port over normal TCP
> . Turn client sends a 'STARTTLS' string to the server to begin tls negociation
> . Turn server receives the 'STARTTLS', then it sends a 'READY' string
> to the client and starts the TLS negociation with a server
> certification to the client
> . Once Turn client receives the 'READY' string, it should starts the
> TLS negociation too
> . Then everything is over TLS
(...)

They surely are technical solutions that do not involve using a
different port for raw TCP and TLS over TCP traffic, which is considered
bad practice.

One solution is indeed to send some kind of non-encrypted message that
ask for TLS explicitly, much like is already done for SMTP-TLS and
IMAP-TLS.

Another -ugly- solution is to peek the first byte from the TCP session
data stream, use TLS if it is 0x22 (the id for TLS Client Hello),
non-TLS if it is 0x00 and whatever otherwise. But it is ugly because it
makes assumptions on the ID used in future versions of TLS and TURN
respectively.

The point is : the TURN Internet draft needs to have one solution
defined, so that it is interoperable.

Regards,

-- 
Remi Denis-Courmont <[email protected]>
Nokia-NRC/Helsinki