Opened 3 years ago

Closed 11 months ago

#1850 closed defect (no response)

Block connections to the routerconsole from Tor hidden services, and document the reasons why

Reported by: str4d Owned by:
Priority: major Milestone: soon
Component: apps/console Version: 0.9.26
Keywords: privacy anonymity usability docs Cc:
Parent Tickets:

Description

Sarah Lewis discovered two I2P routers exposed as Tor hidden services (presumably via OnionScan). This is an incredibly dangerous setup, because while the user probably thinks they are getting even more anonymity by only configuring their I2P router over Tor, they are in fact completely compromising both their I2P and Tor location anonymity (because the I2P router and Tor client are very likely running on the same server). The fact that this affects both I2P and Tor makes it worse than accidentally configuring the I2P routerconsole to be publicly reachable on the clearnet.

This is a serious usability / documentation bug in both I2P and Tor, because some users are clearly not understanding the limits of these technologies. In particular, the users in question do not realise that Tor hidden services are publicly enumerable and accessible.

By default, the routerconsole only accepts connections from localhost, which prevents it accidentally becoming publicly reachable. But Tor hidden services are generally configured such that the Tor process forwards incoming .onion requests to a local server, which circumvents the protections we have in place.

We should attempt to block incoming connections to the routerconsole from Tor. We should figure out whether Tor's default hidden services configuration sets any user agent or HTTP header flags when proxying incoming .onion requests to the underlying server, that we might be able to use to distinguish localhost Tor connections from localhost browser connections.

At worst, we should consider blocking connections from Tor Browser. This would at least inform those users that this is a problem when they try to use the .onion, but does nothing to actually protect them from their misguided configuration. This could also cause significant usability issues for those users who have configured Tor Browser locally for both Tor and I2P traffic, and are using it to connect to the routerconsole.

We also need to document how users *can* safely make their I2P routers remotely accessible. Users should add a password to their routerconsole, and enable SSL if making the routerconsole publicly accessible over clearnet. If they want location anonymity, they should be using an I2P Destination with LeaseSet encryption.

Subtickets

Change History (8)

comment:1 Changed 3 years ago by zzz

Do you have any further information on how to do this?

comment:2 Changed 2 years ago by slumlord

Is it possible for the router console to detect if it is being accessed via a .onion URL? A message could be displayed informing the user about the potential danger of this kind of configuration, maybe with a strong suggestion to use a password on their router's console.

comment:3 Changed 19 months ago by zzz

  • Status changed from new to infoneeded_new

comment:4 Changed 15 months ago by aargh

  • Status changed from infoneeded_new to new

Blocking connections from Tor Browser seems a bit ambitious to me. Please pardon my naivety if this entirely misses the point, but as long as Tor still passes an unmangled Host: header, why not check incoming router console requests against the lowercase host header suffix of ".onion" in allowHost() @ apps/routerconsole/java/src/net/i2p/router/web/HostCheckHandler.java:102 to force those incoming requests to be explicitly allowed and otherwise return a 403 status code?

Would this denial strategy itself be de-anonymizing, is there a better way, or is this really just a documentation issue?

Trying to drum up conversation on this ticket.

comment:5 Changed 15 months ago by aargh

  • Status changed from new to infoneeded_new

comment:6 Changed 15 months ago by aargh

  • Status changed from infoneeded_new to new

Please disregard my earlier reply -- I should have tested things first. Maybe the work already completed to resist rebinding attacks predates this ticket. Regardless, I did some testing with a default installation of I2P 0.9.33 and pointed a "stock" Tor 0.3.0.10 hidden service running on port 80 directly to my I2P router console port. The error message from the Tor end via the .onion address, confirmed by a 3rd party tor2web proxy node, was:

HTTP ERROR: 403

Problem accessing /. Reason:

    Console request denied.
    To allow access using the hostname "xxxxxxxxxxxxxxxx.onion", add the line "routerconsole.allowedHosts=xxxxxxxxxxxxxxxx.onion" to advanced configuration and restart.

Powered by Jetty://

So, does that error message suffice and should this ticket be closed as fixed or does it need additional documentation?

comment:7 Changed 15 months ago by zzz

  • Status changed from new to infoneeded_new

Sadie declared this yesterday on twitter a "serious bug" but is it really?

Regarding comments 4 and 6 above, the DNS rebinding prevention was added in 0.9.32. It may have inadvertently fixed this as well.

If it's only a documentation issue, it isn't serious. And not clear if it is. And Tor docs are not our responsibility.

We could check for the X-I2P-DestHash? header added by the HTTP Server tunnel, to prevent the user from looping a server tunnel to the console.

Returning this 17-month-old ticket to the OP for more info or action. If it's that serious, what do we need to do. If it isn't, or isn't any more, please close, reduce priority, clarify, or fix the docs, as necessary.

comment:8 Changed 11 months ago by zzz

  • Resolution set to no response
  • Status changed from infoneeded_new to closed
Note: See TracTickets for help on using tickets.