[Twisted-Python] Could I serve normal TCP and TLS services on the same port?

[Justin Warren]

On Fri, 2005-06-10 at 16:14 +0800, Eric Hsu wrote:
> Hi Justin,
> 
> Thank you for you quick reply :)
> 
> > What is the problem you are trying to solve here?
> > 
> > I mean, in theory, yes, you could do what you're proposing. Why do you
> > want to, though?
> 
> I'm trying to write a TURN server:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-07.txt
> 
> The TURN client which is behind a NAT will ask the TURN server (with
> public address) to allocate a public transport address for it to
> receive data from outside.
> 
> There're two requests while the client trying to allocate a public
> transport address from the TURN server:
>  * Share Secret Request: over TLS; to obtain a one-time username and
> passwd and keep the passwd as the share secret of both side (the
> server and the client)
>  * Allocate Request: to allocate a public transport address from the server
> 
> As the draft said:
> 
> "A TURN server MUST be prepared to receive  Binding (should be
> Allocate - eric) Requests over TCP and UDP." (P10)
> 
> "The Allocate Request MUST be sent to the same IP address and port as the Shared
> Secret Request. This is because one time passwords are expected to be
> host-specific." (P20)
> 
> That means both the Share Secret Request (over TLS) and Allocate
> Request will be sent to the same IP and port of the server.
> 
> Then, the draft said:
> 
> "The client SHOULD close its connection when it has completed
> allocating username and passwords." (P19)

Ok, so you shut down the session here.

> So, while the client sends the Allocate Request to the server over
> TCP, the process would look like this (assuming the server is
> listening on port 12345 for TLS connection):
> 
> * the client sends the Share Secret Request to server:12345 _over TLS_
> and obtains a one-time username and passwd
> * the client closes the TLS connection
> * the client sends the Allocate Request to server:12345 _again_ to
> allocate a public transport address...

My reading of this (without having read the actual RFC) would result in
this kind of sequence:

C: connect to server via TCP
S: accept connection
C/S: start TLS
-- TLS negotiation happens --
C: Share Secret Request
S: gives out one time username/password
C: cool! thanks!
S: close connection

So the TCP session actually gets shut down here. The client then does
the Allocate Request, presumably using the username/password combo it
got before.

C: connect to server via TCP
S: accept connection
C: Allocate request
... and so on.

> It seems that I have to implement what I've mentioned in my previous mail?
> I'm not a native English speaker, and TURN is only a draft, maybe I've
> misunderstood something?

So you SHOULD be closing the connection after doing the username and
password allocation, which I'm reading as being within the TLS session.
This means the shutdown of TLS happens when the TCP connection is ended.
The next connection will be standard bare TCP.

This means all you have to do is work out how to turn TLS *on* when you
get a TCP connection. You don't have to work out how to turn it off
within the same TCP session, because you actually end the session and
reconnect. Much easier. :)

-- 
Justin Warren <daedalus at eigenmagic.com>