.bit and Tor

https://www.namecoin.org/dot-bit/
Post Reply
domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

.bit and Tor

Post by domob »

I've been experimenting with .bit and Tor hidden services a bit lately, and want to share just some random results. I believe that .bit and Tor hidden services are yet another excellent match! Not just because of the potential anonymity provided by hidden services, but also because it enables to host content on your home computer or so without needing to think about dynamic IPs or firewalls. Just run the Tor client, configure the .bit -> .onion translation, and your content is reachable without a dedicated server as long as your computer is running. Really simple! (In principle. Maybe I should write a wiki page somewhere with a complete how-to for setting up a webserver, Tor hidden service and configuring the .bit domain appropriately.)

The first experience is: FreeSpeechMe works great with Tor, and it was also much easier to set up a hidden service than I thought! domob.bit and nameid.bit are both now accessible via Tor resolution, too (and as plain hidden services, obviously). Some things where I'd appreciate input:
  • How to configure subdomains (in particular "www") with .onion addresses? I'm currently just using the "tor" field, but then nmcontrol only resolves getOnion for the domain without "www". Is it possible to resolve every subdomain via the same .onion, just like the "map *" thing for IP4?
  • What about adding some way to FreeSpeechMe to see how the current page was resolved? One can extract it from the debug logs printed, but it would be cool for testing to just have a "Resolved by ..." tooltip or dialog or something somewhere. (But one can test by disabling non-Tor resolvers temporarily for now.)
  • HTTPS and Tor do not work together when using FreeSpeechMe. I think this was pointed out already by biolizard89 some time ago and of course, TLS is redundant when using Tor, but in combination with .bit it seems not too unnecessary. I want that https://nameid.bit/ works also when using Tor resolution, and it at least ensures the user that their connection is encrypted without having to know that Tor was used and that also HTTP alone is secure.
For the last point, when using TLS with Tor-resolved .bit domains (note that https://6tu4hqziyjly7fns.onion/ alone works fine!), Apache errors with the following message:

Code: Select all

[error] Hostname 6tu4hqziyjly7fns.onion provided via SNI and hostname nameid.bit provided via HTTP are different
The problem is understandable. biolizard89, do you know whether there is the possibility to force the SNI hostname sent when redirecting the socket to the onion address? Or at least disable SNI for this connection? (Presumably there's no SNI information sent when the IP4 resolver is used and the connection redirected to the IP address, right?)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: .bit and Tor

Post by biolizard89 »

domob wrote:I've been experimenting with .bit and Tor hidden services a bit lately, and want to share just some random results. I believe that .bit and Tor hidden services are yet another excellent match! Not just because of the potential anonymity provided by hidden services, but also because it enables to host content on your home computer or so without needing to think about dynamic IPs or firewalls. Just run the Tor client, configure the .bit -> .onion translation, and your content is reachable without a dedicated server as long as your computer is running. Really simple! (In principle. Maybe I should write a wiki page somewhere with a complete how-to for setting up a webserver, Tor hidden service and configuring the .bit domain appropriately.)

The first experience is: FreeSpeechMe works great with Tor, and it was also much easier to set up a hidden service than I thought! domob.bit and nameid.bit are both now accessible via Tor resolution, too (and as plain hidden services, obviously). Some things where I'd appreciate input:
  • How to configure subdomains (in particular "www") with .onion addresses? I'm currently just using the "tor" field, but then nmcontrol only resolves getOnion for the domain without "www". Is it possible to resolve every subdomain via the same .onion, just like the "map *" thing for IP4?
  • What about adding some way to FreeSpeechMe to see how the current page was resolved? One can extract it from the debug logs printed, but it would be cool for testing to just have a "Resolved by ..." tooltip or dialog or something somewhere. (But one can test by disabling non-Tor resolvers temporarily for now.)
  • HTTPS and Tor do not work together when using FreeSpeechMe. I think this was pointed out already by biolizard89 some time ago and of course, TLS is redundant when using Tor, but in combination with .bit it seems not too unnecessary. I want that https://nameid.bit/ works also when using Tor resolution, and it at least ensures the user that their connection is encrypted without having to know that Tor was used and that also HTTP alone is secure.
For the last point, when using TLS with Tor-resolved .bit domains (note that https://6tu4hqziyjly7fns.onion/ alone works fine!), Apache errors with the following message:

Code: Select all

[error] Hostname 6tu4hqziyjly7fns.onion provided via SNI and hostname nameid.bit provided via HTTP are different
The problem is understandable. biolizard89, do you know whether there is the possibility to force the SNI hostname sent when redirecting the socket to the onion address? Or at least disable SNI for this connection? (Presumably there's no SNI information sent when the IP4 resolver is used and the connection redirected to the IP address, right?)
The "map" field isn't just for IPv4. You can give an "ip" field and a "tor" field as subfields of "map".

Making it visible to the user which resolver was used is a good idea. I'll see if there's a good way of doing this. Do you have suggestions for what Firefox UI element would be good for this?

That's certainly an interesting observation regarding SNI... you're correct; SNI is disabled for IPv4/IPv6 by sending the connection directly to the IP, but I guess .onion and .b32.i2p break this. The right way to fix this is to revert Mike Kazantsev's commit that enables SNI at all. I'll play around with this when I have a moment.... Thanks for the bug report! :-)
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply