GlobaLeaks should only answer to it's own "hostname"

[fpietrosanti]

GlobaLeaks server should only answer to it's own hostname:

• Tor Hidden Service URL
• Public Site URL
• 127.0.0.1

Currently GlobaLeaks backend serve requests from any hostname.

To test and reproduce the issue edit /etc/hosts and add 127.0.0.1 bingobongo.com

then connect with the browser to http://bingobongo.com:8082 .

GlobaLeaks does server GLClient and answer to the hostname "bingobongo.com" .

[evilaliv3]

right, actually globaleaks does now listen on 0.0.0.0: netstat -nat | grep 8082 tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN

this is done because we of this call, where we add the API specification as a whole without specifying the virtualhost

GLBackendAPIFactory = web.Application(api.spec, debug=GLSetting.cyclone_debug)

first of all i think we must reduce the virtualhost by removing the ip possibility (due to overhead in processing time); this will be clear by further reading my response we will have three virtualhost:

• open web
• .onion
• tor2web

from what i've seen cyclone does not permit to configure virtualhosts globally but from what i've seen it forces the programmar to declare for each api the virtual host that it's responding. from line 1301 of cyclone:

1301 We support virtual hosts with the add_handlers method, which takes in 1302 a host regular expression as the first argument:: 1303 1304 application.add_handlers(r"www.myhost.com", [ 1305 (r"/article/([0-9]+)", ArticleHandler), 1306 ])

so to implement virtualhosting checks we have two possibilities:

• by using cyclone and instead of adding the API as a whole, for each API spec we need to add it by using a application.add_handlers adding the same resource for each virtualhost.
• by patching cyclone and adding a raw simple patch to _get_host_handlers(self, request) or def call(self, request) by inserting a simple matching function.

@fiorix can i ask you also what do you think about?

[vecna]

we may have different domain, present in static conf (127.0.0.1) settings, or database (hiddenservice). So I propose to implement this fix in GLBackend in the prepare function, implemented in our BaseHandler (inherit by Cyclone RequestHandler).

prepare is called before every request, and can be accept/deny with the right HTTP error code, performing all the required checks based on the HTTP Host header.

[fiorix]

I'd rather have different applications instead of virtual domains in the same application, for the sake of debugging, maintenance and ease of deployment. Keep in mind that you'll always need multiple instances of your servers (usually one per cpu core) and a load balancer like nginx in front of it.

[fpietrosanti]

A couple of consideration:

• We do not have any load balancer because GlobaLeaks is exposed directly with cyclone -Those "different domains" are the same application answering in the same way

[fiorix]

but the cyclone server is single threaded, and only scales well if you use a load balancer... if you plan to handle high loads on the server, it's better if you have one cyclone server per cpu core otherwise the server might slow down on mid/high loads (depending on what it does, and how, etc)

On 2013-03-14, at 12:44 PM, "Fabio (naif) Pietrosanti" notifications@github.com wrote:

A couple of consideration:

We do not have any load balancer because GlobaLeaks is exposed directly with cyclone -Those "different domains" are the same application answering in the same way — Reply to this email directly or view it on GitHub.

[vecna]

@fiorix GLBackend run in a Tor darknet, and plan very few active operations in the daily usage, so we do not treat performances as an issue.

[fiorix]

Cool, I didn't know that. Tor pwnz! :D

On 2013-03-14, at 4:40 PM, "Claudio A." notifications@github.com wrote:

@fiorix GLBackend run in a Tor darknet, and plan very few active operations in the daily usage, so we do not treat performances as an issue.

— Reply to this email directly or view it on GitHub.

[vecna]

The solution is easier than expected. in prepare function I just check that self.request.host is an hidden service or is 127.0.0.1, because:

• both tor2web and onion.to software, change the Host: header in the hidden service .onion, instead of the .tor2web.org host
• hidden service need to be handled by txtorcon, at the moment I'm just checking that hidden service format is correct, (22 bytes length and .onion in the end): https://github.com/globaleaks/GlobaLeaks/issues/70

Not handled cases under study:

• if an admin want expose GLBackend on a different interface, need to specify this parameter. I think to add a command line option, eg: --add-permit-host=192.168.1.1
• exposed web host ? if this is possible, need to be configured by command line (eg: startglobaleaks --add-permit-host=www.salaminchia.net ) or need to be configured by web gui ?

but, in short, why we're marking this enforcement ? for a security purpose or for waht ?

[vecna]

the last question is important, also because at the moment, prepare function can deny accesses only to REST connection, but not in the static files.

[vecna]

ok, the latest comment is solved: now also static files and redirect has the 'Host:' check.

[vecna]

Implemented skeleton of the validation and firsts checks, in: https://github.com/globaleaks/GLBackend/commit/afd420ac4d5850779de1b1c7e5fbbf576b968646

This ticked can be completed only after:

• specification of command line or admin UI
• issue #70

At the moment, in example, http://localhost:8082 return an error, because 'localhost' is not between the permitted host.

[evilaliv3]

ok vecna. the fix is needed mostly for correctness (as there are not really security issues different from abuses). sometimes XSS and others attacks use this kind of misbehaviours and also Spammers et similar for example to avoid somebody suggest to google antani.globaleaks.org; for example look on google at: site:w.globaleaks.org that is caused by a miscunfiguration in Apache usinge a default virtualhost.

for this reason i think that also static files need a patch for this. how are we manaing static files now? on tor2web i used to check all manually and loading files in RAM to handle some caching this could be probably interesteting for js css and jpg also for globaleaks?

[fpietrosanti]

The information about:

• torhs url
• public site (if present)

are already into the database and can be already configured from the admin interface.

So this ticket can be probably closed with no need for #70 or for any other options?

[vecna]

no @fpietrosanti my concern and suggestion of wait #70 was because:

• torhs url may not be configured by the admin (or almost, maybe difficult if configured in a remote server, access to the UI)

If hidden service need to be specified, then is better if a commant line option is used, otherwise the HS configuration trigger a loophole. and:

• public site, has been intended like the public interface of the organization, like a blog or like an organization page, but nothing related to the GLBackend server.

@evilaliv3 yes static file and redirect has been supported with few efforts, just now we're no more use a clean cyclone.web classes, but all the derived classed in handlers/base.py

[fpietrosanti]

If TorHS is not configured by the admin, then TorHS it's not configured, so it does not work. Like an email account, if not configured, notification will not work.

Regarding cmdline vs. db: We should never have in two different place, configurable in two different way, the same piece of information (the torhs url).

[fpietrosanti]

Regarding the public site, i always understood it's the Tor2web hostname (the hostname used to expose the TorHS to the internet). Then it maybe a private Tor2web hostname like perun.juznevesti.com or a public one like blahblah.tor2web.org on a specific domain.

[vecna]

The TorHS via command line i believe is required, to avoid an administration loophole. like:

• I'm an admin, "apt-get install tor" "git clone globaleaks" on my remote server
• ok, now everything is running.
• ouch, only 127.0.0.1 can be served, I can't setup my node.

an option like --add-permitted-host=PUBLIC.IP or --add-permitted-host=hiddenservice.org would solve without effort.

I understand the non duplication of the information, but in this case, it's a temporary code (in the near future, hiddenservice would not be specified by user, not in command line neither in GUI, because would be know by txtorcon, and communicated at the service startup).

[vecna]

This discussion was also in https://github.com/globaleaks/GLBackend/commit/afd420ac4d5850779de1b1c7e5fbbf576b968646#commitcomment-2819295 and recently I've commited a patch to permit a command line specification of the --accept-host, in: https://github.com/globaleaks/GLBackend/commit/546e4f89b1b4ff7da55bef9130294eca42ed4a0e

This is usable in service like dev.globaleaks.org.

at the moment, all the hidden service (and all the connection thru Tor2Web) are accepted (the Host: header is the same), and only with txtorcon would be implemented an HS validation.