v2 onion service Tor2web would be easy for HSDirs to block, due to an implementation bug. We've chosen not to block it. But we haven't spent much time on fixing its bugs, either. As far as I am aware, no-one is writing Tor2web for v3 onion services. We have open tickets for protecting relays that handle onion service traffic from knowing both the client and service IP address. So if anyone does write v3 Tor2web, they will need to write it so it: * uses a 3-hop path for all descriptors, because otherwise that can be used for a selective denial of service; * uses a 3-hop path to connect to intro and rend when a descriptor has the single onion service flag; * retry using a 3-hop path on failure (internal reachability or actual connection failure) And I'm not sure whether we would merge this feature into core tor, due to the user security issues that David and others have mentioned. T |
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev