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