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

[Bjarni Rúnar Einarsson <bre@xxxxxxxxxxxx>]

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/