4 ms·

In a big company blog post like this, I wish they'd call them onion services instead of hidden services, especially since they are even using a v3 onion service

In a big company blog post like this, I wish they'd call them onion services instead of hidden services, especially since they are even using a v3 onion service. Also, curious if they wrote any code to support this since OnionBalance doesn't support v3 yet. I know they use Go a lot and I wrote a Tor control client myself recently [0]. 0 - https://github.com/cretz/bine https://github.com/cretz/bine

jgrahamc 8y ago
I've changed the blog post as you suggest.
- oger 8y ago
  Great work! Especially after Daniel (Stenberg) adding momentum to the DoH movement recently. Even though I wish you huge success let’s hope that many other ‚alternative‘ DNS providers jump on the bandwagon in order to make any (future) traffic correlation attacks less simple. Having just a single watering hole makes it too easy for predators to catch their prey - and I don’t assume cooperation from your side (as you already stated in other parts of this thread).
mahrud 8y ago
Thanks for the heads up, should be fixed now. I knew Tor Project has been shifting away from "hidden services" for a while but I missed the email where teor clarified things for blog posts and such in late April [0]. Also, I wanted to avoid using "onion resolver" as it would be a worse misnomer than "hidden resolver." Re. OnionBalance: we're working on a few ideas for this, but nothing conclusive yet. 0. https://lists.torproject.org/pipermail/tor-dev/2018-April/013104.html https://lists.torproject.org/pipermail/tor-dev/2018-April/01...
- kodablah 8y ago
  For OnionBalance, on the mailing list they mentioned that while it is more difficult on v3, they are implementing HSFETCH/HSPOST[0]. I'm not sure of any other load balancing approaches outside of this. In the meantime I figure y'all have this all going through one hidden service endpoint or maybe share some priv keys or wrote some custom code or something. 0 - https://lists.torproject.org/pipermail/tor-dev/2018-April/013128.html https://lists.torproject.org/pipermail/tor-dev/2018-April/01...
- manwithaplan 8y ago
  > I knew Tor Project has been shifting away from "hidden services" for a while I read the article after your correction, and on reading the `What are Tor onion services?` section, I thought “How nice, they’re using the new terminology to go with the new v3 service address”. But then, just below, I saw the https://blog.cloudflare.com/content/images/2018/05/image_3.png https://blog.cloudflare.com/content/images/2018/05/image_3.p... diagram still mention “hidden service” and thought “an old image slipped thru, tho” :) Also, wouldn’t a “1111dns4tor” prefix look better? :)
  - jgrahamc 8y ago
    > Also, wouldn’t a “1111dns4tor” prefix look better? :) Yes, it would but the .onion addresses use base32 and '1' isn't in the alphabet used: https://en.wikipedia.org/wiki/Base32 https://en.wikipedia.org/wiki/Base32
    - jedberg 8y ago
      You could have done IIIIdns4tor :)
      - kodablah 8y ago
        It would be iiiidns4tor because, while base-32 is commonly implemented with capital letters, the onion service ID is lower cased.
        mahrud 8y ago
        Also, farming an onion with that many fixed characters takes a good few hundreds or thousands of years.
        zaarn 8y ago
        This is a v3 onion service, it should be easier to find prefixes, plus CF (and other companies like FB) have done pretty long prefixes via brute force (they have a lot of computers)
baby 8y ago
Could you educate the rest of us on the difference :)?
- kodablah 8y ago
  From "hidden" to "onion" is just a terminology change. For the v2/v3 change, not sure there is an in-depth blog post on the differences except for comparing the specs of v2[0] vs v3[1]. There's a wiki page with a high-level overview [2]. 0 - https://github.com/torproject/torspec/blob/master/rend-spec-v2.txt https://github.com/torproject/torspec/blob/master/rend-spec-... 1 - https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt https://github.com/torproject/torspec/blob/master/rend-spec-... 2 - https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions https://trac.torproject.org/projects/tor/wiki/doc/NextGenOni...
rootsudo 8y ago
Shouldn't your first reference point be 1? :P

jgrahamc 8y ago

I've changed the blog post as you suggest.

oger 8y ago
Great work! Especially after Daniel (Stenberg) adding momentum to the DoH movement recently. Even though I wish you huge success let’s hope that many other ‚alternative‘ DNS providers jump on the bandwagon in order to make any (future) traffic correlation attacks less simple. Having just a single watering hole makes it too easy for predators to catch their prey - and I don’t assume cooperation from your side (as you already stated in other parts of this thread).

mahrud 8y ago

Thanks for the heads up, should be fixed now. I knew Tor Project has been shifting away from "hidden services" for a while but I missed the email where teor clarified things for blog posts and such in late April [0]. Also, I wanted to avoid using "onion resolver" as it would be a worse misnomer than "hidden resolver." Re. OnionBalance: we're working on a few ideas for this, but nothing conclusive yet. 0. https://lists.torproject.org/pipermail/tor-dev/2018-April/013104.html https://lists.torproject.org/pipermail/tor-dev/2018-April/01...

kodablah 8y ago
For OnionBalance, on the mailing list they mentioned that while it is more difficult on v3, they are implementing HSFETCH/HSPOST[0]. I'm not sure of any other load balancing approaches outside of this. In the meantime I figure y'all have this all going through one hidden service endpoint or maybe share some priv keys or wrote some custom code or something. 0 - https://lists.torproject.org/pipermail/tor-dev/2018-April/013128.html https://lists.torproject.org/pipermail/tor-dev/2018-April/01...
manwithaplan 8y ago
> I knew Tor Project has been shifting away from "hidden services" for a while I read the article after your correction, and on reading the `What are Tor onion services?` section, I thought “How nice, they’re using the new terminology to go with the new v3 service address”. But then, just below, I saw the https://blog.cloudflare.com/content/images/2018/05/image_3.png https://blog.cloudflare.com/content/images/2018/05/image_3.p... diagram still mention “hidden service” and thought “an old image slipped thru, tho” :) Also, wouldn’t a “1111dns4tor” prefix look better? :)
- jgrahamc 8y ago
  > Also, wouldn’t a “1111dns4tor” prefix look better? :) Yes, it would but the .onion addresses use base32 and '1' isn't in the alphabet used: https://en.wikipedia.org/wiki/Base32 https://en.wikipedia.org/wiki/Base32
  - jedberg 8y ago
    You could have done IIIIdns4tor :)
    - kodablah 8y ago
      It would be iiiidns4tor because, while base-32 is commonly implemented with capital letters, the onion service ID is lower cased.
      - mahrud 8y ago
        Also, farming an onion with that many fixed characters takes a good few hundreds or thousands of years.
        zaarn 8y ago
        This is a v3 onion service, it should be easier to find prefixes, plus CF (and other companies like FB) have done pretty long prefixes via brute force (they have a lot of computers)

baby 8y ago

Could you educate the rest of us on the difference :)?

kodablah 8y ago
From "hidden" to "onion" is just a terminology change. For the v2/v3 change, not sure there is an in-depth blog post on the differences except for comparing the specs of v2[0] vs v3[1]. There's a wiki page with a high-level overview [2]. 0 - https://github.com/torproject/torspec/blob/master/rend-spec-v2.txt https://github.com/torproject/torspec/blob/master/rend-spec-... 1 - https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt https://github.com/torproject/torspec/blob/master/rend-spec-... 2 - https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions https://trac.torproject.org/projects/tor/wiki/doc/NextGenOni...

rootsudo 8y ago

Shouldn't your first reference point be 1? :P