
Debian and Tor Services Available as Onion Services - ashitlerferad
https://bits.debian.org/2016/08/debian-and-tor-services-available-as-onion-services.html
======
kefka
Normally, you need the apt module for Tor transport... But what if you wanted
to be able to run .onion addresses from any program?

I wrote this:
[https://trac.torproject.org/projects/tor/wiki/doc/LinuxDNSre...](https://trac.torproject.org/projects/tor/wiki/doc/LinuxDNSresolverForOnions)

I wanted to be able to send data to Tor onion endpoints within my code, mixed
with regular IP or DNS addresses. This modification allows the Linux system
resolver handle Onions as it would any other address.

~~~
zrm
Be careful with this if you're expecting anonymity though. The Tor browser
does a lot of work trying to prevent identifying information from being sent
to the other side. If you run an arbitrary protocol over Tor without any of
that, it's much easier for the server to fingerprint the client.

~~~
kefka
Absolutely. I highlighted this as one of the warnings in the Howto I made. Any
protocol you use _must_ be vetted for security and privacy, if you intend to
use Tor for those purposes.

My purpose is very different. I wanted to communicate with any machine I
owned. Every machine has an Onion hidden service, and every machine can talk
to Onions seamlessly.

What this allows is I can code against a [hash].onion, and know that the data
goes where I want it. I can run Mosquitto (MQTT database) on one node, and
other nodes can publish data to it. It matters not where they are, what
networks they reside on, or if I get the "DynDNS, firewall holes, dynamic-
static internal IP", and the rest of that junk set up right.

I also use Node-Red, and can use .onion addresses as valid services elsewhere.
It allows me the ultimate network flexibility. I think of .onion addresses as
being on a "Really Long Ethernet Hub" that only listens to the machine talked
to.

EDIT:

> If you run an arbitrary protocol over Tor without any of that, it's much
> easier for the server to fingerprint the client.

Agreed. I control both endpoints.

~~~
SXX
Still not sure why would you want to use it like that.

OnionCat with virtual domain names would be better IMHO.

------
akerro
I wish more systems went this way, Arch, Gentoo, Fedora and all BSDs.

------
raverbashing
I wonder if Debian volunteers searching a more friendly tor address?

~~~
akerro
There is very little benefit from such addresses
[http://news.netcraft.com/archives/2014/06/25/steam-
phishing-...](http://news.netcraft.com/archives/2014/06/25/steam-phishing-
attacks-exploiting-look-alike-domain-names.html)

~~~
raverbashing
I disagree

Domain squatting is even harder on tor, but how am I supposed to know the real
Debian is on xyabdjfhkj1345 or xvhdjakeueg12567?

~~~
throwaway7767
If debian generated an onion address like debiandebxwnjx6t.onion (just made
that up), how would that help you determine that the .onion address is owned
by debian?

All it proves is that someone ran a vanity key/address generator on his GPU
for a couple of days to get a nice-looking prefix. I could do the same thing
at home and get a different address with the same prefix, and you wouldn't be
able to tell the difference without comparing the whole address.

~~~
raverbashing
You're right, by itself it doesn't

However, with several Debian volunteers they can get a more friendly-looking
address. One person alone with a GPU can't compete with that

It's a proof of work (just like bitcoin)

~~~
wcummings
One person with a botnet can compete

------
bedros
I wonder why I2P service/protocol is not as popular as Tor?

Why would debian not host their sites on I2P

~~~
SXX
It's less popular for several reasons:

* Tor heavily used to get some anonymity in big internet.

* Tor have bundle browser solution that anyone can use.

* I2P is Java and not everyone know there is C++ client.

* I2P also audited less have more undergoing changes.

While I2P can be used to do exactly same things as Tor it's just not goal of
project.

------
catuskoti
We also need reproducible build to finally cover most of debian ...

~~~
leni536
[https://tests.reproducible-
builds.org/debian/reproducible.ht...](https://tests.reproducible-
builds.org/debian/reproducible.html)

Isn't >80% most of Debian?

~~~
ashitlerferad
80% is misleading, since there are still variations that are missing, like
user shells, build paths and filesystems (disorderfs isn't used yet).

[https://tests.reproducible-
builds.org/index_variations.html](https://tests.reproducible-
builds.org/index_variations.html)

~~~
leni536
Sure, but variations are there so the reproducible builds are more robust and
can be done natively. It doesn't mean that you can't reproduce these packages,
just stick to the standard build paths, filesystems, etc...

Also, I see that user login shell is varied.

