xxx-draft-spec-for-TLS-normalization.txt

[Bjarni Rúnar Einarsson]

Hi all!

(Hopefully this threads correctly, I copy-pasted the subject from the web,
as I just subscribed and had no messages to reply to.)

I wanted to chime in and mention one advantage of using a non-random,
predictable name for the certificate in the TLS handshake: leveraging TLS
name-based virtual hosting to coexist with normal TLS-web servers.

Currently, the operator of a Tor entry node has to choose between running
Tor on port 443, or running a normal HTTPS server. If you make the TLS cert
name predictable (at least the name requested in the SNI header of the
incoming request), then it becomes possible to use name-based virtual
hosting tech to allow Tor and a regular HTTPS server to coexist on the same
IP and the same port.

Software supporting this already exists: my pagekite.py front-end
proxy/tunnel already does name-based proxying of TLS traffic (it doesn't
terminate the TLS tunnel, just routes the stream to a back-end based on the
SNI data in the handshake), the only reason I can't use it unmodified to
route Tor connections is because of the random certificate names. I tried to
start a discussion about the pros and cons of using Pagekite for this on
or-talk a few weeks ago, following up on a suggestion from Linus Nordberg at
FSCONS, but didn't get many takers. :-)

Presumably the main benefit of this would be to further hiding the Tor
traffic. Not only can the entry node look like an HTTPS web server, it can
*be* a normal HTTPS web server serving live web traffic. A secondary benefit
would be making all the boxes currently serving HTTPS traffic into potential
Tor entry nodes.

-- 
Bjarni R. Einarsson
The Beanstalks Project ehf.

Making personal web-pages fly: http://pagekite.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110202/81d5767d/attachment.htm>