Automatic "Onionification" of existing websites
Hello, i've been considering that nowLetsencrypt let you automate setup of TLS certificate, for existing websites that does not have HTTPS. What's about thinking about "automations" and "improvement to existing webserver software" to facilitate the automatic "Onionification" of existing websites?
From a "sysadmin point of view" it would be a cool thing, if it's somehow easy and automated to do.
It shall be a mod_tor of apache2 or something similar. I'm just firing the discussion, but if we want thousands of onion sites, then we need to facilitate the deployment on the existing configured websites, without requiring a sysadmin to do a lot of hackish stuff. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi
On 31 Jan 2016 10:17 a.m., "Fabio Pietrosanti (naif) - lists" < lists@infosecurity.ch> wrote:
I'm just firing the discussion, but if we want thousands of onion sites, then we need to facilitate the deployment on the existing configured websites, without requiring a sysadmin to do a lot of hackish stuff.
Woop! :-) I'd recommend targeting a few platforms (debian + ubuntu + centos ?) with a set of tools to set up a couple of webservers (apache, nginx) and CMSes (wordpress, ...?): - platform hardening - tor daemon and setup - web-server config - cms config ...then put it all up on GitHub for review.
From past experience* a modular approach, treating each of these tasks separately, works best.
On 1/31/16 11:27 AM, Alec Muffett wrote:
I'd recommend targeting a few platforms (debian + ubuntu + centos ?) with a set of tools to set up a couple of webservers (apache, nginx) and CMSes (wordpress, ...?):
- platform hardening - tor daemon and setup
Regarding Tor, it can be config-less following the implementation of https://trac.torproject.org/projects/tor/ticket/6411 in Tor 0.2.7 . That way it's possible to avoid dumping to filesystem the TorHS descriptors or having to modify the torrc, with all those logic to be possibly handled by the webserver modules supporting "onionification" . Regarding massive scale deployment, there is this limit actually https://trac.torproject.org/projects/tor/ticket/15251 that we encountered when thinking about "OnionFlare" https://github.com/globaleaks/Tor2web/issues/228 as a way to easily "Onionize" an existing HTTPS website, by putting that feature into Tor2web.
- web-server config
I feel that on Apache there should be an application module, like mod_tor, that once enabled will allow to do something like "OnionService on" in the <VirtualHost> directive, having the rest happening in a auto-magic way.
- cms config
...then put it all up on GitHub for review.
From past experience* a modular approach, treating each of these tasks separately, works best.
-a
* http://www.securityfocus.com/tools/1774
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
-- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi
On 31 Jan 2016 11:07 a.m., "Fabio Pietrosanti (naif) - lists" < lists@infosecurity.ch> wrote:
Regarding massive scale deployment, there is this limit actually <https://trac.torproject.org/projects/tor/ticket/15251>https <https://trac.torproject.org/projects/tor/ticket/15251>:// <https://trac.torproject.org/projects/tor/ticket/15251>trac.torproject.org <https://trac.torproject.org/projects/tor/ticket/15251>/projects/ <https://trac.torproject.org/projects/tor/ticket/15251>tor <https://trac.torproject.org/projects/tor/ticket/15251>/ticket/15251 <https://trac.torproject.org/projects/tor/ticket/15251>
That's a really interesting issue. I have not considered a use-case where a single daemon would have possibly many hundreds, if not thousands, of Onion addresses. I can't see a short or medium-term use-case for a single daemon serving 1000s of Onions (compare: how many servers with thousands of specific, enumerated IPv4 addresses?) but with Prop224 and changes in use-case (messaging gateways) certainly it can't be ruled out. The model I'm most interested in is simpler: a modest number of high-throughput addresses, perhaps each served by an independent daemon, publishing a shared address with OnionBalance. This is quite similar to popular DSR (Direct Server Return) loadbalancing architectures. Especially if tvdw's work in rendezvous-handoff works out okay, then this seems a good medium-perhaps-long-term strategy for web service deployment on Onions. Likely OnionBalance on its own would suffice for a year or more. -a
- web-server config
I feel that on Apache there should be an application module, like mod_tor, that once enabled will allow to do something like "OnionService on" in the <VirtualHost> directive, having the rest happening in a auto-magic way.
That's awesome! I look forward to seeing it. -a
Seconding (thirding?) this. As someone who has no idea how to do what Fabio, Alec, and Jason advised doing, it would be extremely helpful. On 31 Jan 2016 10:17 a.m., "Fabio Pietrosanti (naif) - lists"
lists@infosecurity.ch> wrote:
I'm just firing the discussion, but if we want thousands of onion sites, then we need to facilitate the deployment on the existing configured websites, without requiring a sysadmin to do a lot of hackish stuff.
Woop! :-)
I'd recommend targeting a few platforms (debian + ubuntu + centos ?) with a set of tools to set up a couple of webservers (apache, nginx) and CMSes (wordpress, ...?):
- platform hardening - tor daemon and setup - web-server config - cms config
...then put it all up on GitHub for review.
From past experience* a modular approach, treating each of these tasks separately, works best.
-a
On 31 Jan 2016, at 21:17, Fabio Pietrosanti (naif) - lists <lists@infosecurity.ch> wrote:
I'm just firing the discussion, but if we want thousands of onion sites, then we need to facilitate the deployment on the existing configured websites, without requiring a sysadmin to do a lot of hackish stuff.
Cryptographic verification would be good here too, otherwise people can set up fake .onion sites and harvest credentials. But I think that's a bigger issue with no easy solution at this point. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (4)
-
Alec Muffett -
Fabio Pietrosanti (naif) - lists -
Tim Wilson-Brown - teor -
Wilton Gorske