On Sat, Nov 14, 2015 at 12:53:23PM +0000, Stuart Henderson wrote: > On 2015/11/14 00:50, Uwe Werler wrote: > > On Sat, Nov 14, 2015 at 12:35:32AM +0100, Stefan Sperling wrote: > > > On Sat, Nov 14, 2015 at 01:05:12AM +0100, Rafael Sadowski wrote: > > > > I prefer to enable by default: > > > > > > " Using Tor2web trades off security for convenience and usability." > > > https://tor2web.org/ > > > > > > Please don't. > > > > > From man: > > > > Tor2webMode 0|1 > > When this option is set, Tor connects to hidden services > > non-anonymously. This option also disables client connections to > > non-hidden-service hostnames through Tor. It must only be used > > when > > running a tor2web Hidden Service web proxy. To enable this option > > the compile time flag --enable-tor2webmode must be specified. > > (Default: 0) > > > > I think it shouldn't be turned on per default - even if it's not enabled > > per default in config. > > > > There are three scenarios therefore this mode is usefull: > > > > 1. You want to provide a http proxy which is able to connect to tor HS for > > clients (resolving onion domains). > > 2. You want to connect a reverse proxy to a HS. > > 3. You want to inter connect two (or more) machines within the tor network > > in client-server-mode. > > > > Regards Uwe > > > > -- > > >
Stuart, I fully agree - and thanks for the explanation. The last days I intensively tested tinc on top of tor in different scenarios (yeah - layer 2 via tor). With this mode enabled on the "client" machine one get's more throughput - increased by probably 40-50%. I measured rates up to 9,6 Mbps instead of max. 5 Mbps. > So we have to balance the possibility of users shooting themselves in > the foot by enabling the config option by mistake, with the possibility > that someone will build their own "--enable-tor2webmode" package and > either not update to a newer version when a security fix comes out > because packages aren't available, or that will accidentally update > to a version without this config option. > > So from what I've seen, I think that probably having this in a non- > default FLAVOR with a good but concise explanation in DESCR of what > it actually does is probably going to be the best idea. But the final > decision should rest with the maintainer. > --
