[tor-dev] When RFC 7686 and transparent proxies collide

[Alec Muffett]

Hi Shawn!

On Mon, 13 Nov 2023 at 15:54, Shawn Webb <shawn.webb at hardenedbsd.org>
wrote:

> I agree that infoleaks, especially of .onion DNS requests, is
> problematic. However, I disagree that prohibiting it in broadly
> monocultured libraries (libcurl) is an advisable approach.
>

If Curl is outright banning ".onion" at the level of the Curl source code,
I would not support that on the grounds that are described in bullet point
2 of section 2, here, which I will requote in full:


*https://datatracker.ietf.org/doc/html/rfc7686#section-2
<https://datatracker.ietf.org/doc/html/rfc7686#section-2>*

*2. Application Software: Applications (including proxies) that implement
> the Tor protocol MUST recognize .onion names as special by either accessing
> them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so.
> Applications that do not implement the Tor protocol SHOULD generate an
> error upon the use of .onion and SHOULD NOT perform a DNS lookup.*


...but I will also note that I have not (maybe I missed it?) seen bullet
point 3 being referenced in this thread:

*3. Name Resolution APIs and Libraries: Resolvers MUST either respond to
> requests for .onion names by resolving them according to [tor-rendezvous]
> or by responding with NXDOMAIN [RFC1035].*


I see Curl/LibCurl in the context of an application (§2) which makes calls
into name resolution apis (§3).  I regret that the text of §2 ("...that do
not implement the Tor protocol...") is ambiguous in its scope, and would
prefer something about the app being incapable of dealing with and unaware
of the existence of multiple possible name-resolution namespaces, instead.

Likewise I feel that *"Applications that do not implement the Tor protocol
SHOULD generate an error"* would benefit from being rewritten to
acknowledge that the desirable error *may* come passively as a consequence
of the name resolution libraries that are called, rather than via some
manner of "policing" invocation of the .onion domain.

tldr: I feel it should not be up to curl/libcurl to be policing the use of
".onion" ... but I am very content for its chosen DNS-based name resolution
backends to be doing do so.

However convenient it may be to attempt to bolt ".onion" onto the DNS for
mobile or Whonix or whatever development, there's no avoiding that in
several ways it is both risky and unspecified to do that. I can't fix that
for anyone, but I also cannot deny that it's pushing water uphill to
attempt it.

My personal sense has always been that at some point in the future
systems-level Tor onion access might need to be provided via a network
interface that presents and routes AF_ONION addresses; but until then (and
per the linked video) new directions in DNS provide us with a secondary
possible solution: Those (mobile?) people who cannot get the benefit of a
solution via /etc/nsswitch.conf should probably have their handsets
reconfigured to do "DNS" lookup via DNS-over-HTTPS[1] to a local HTTPS
service that both understands and treats-in-isolation, all ".onion" lookups.

Of course this does not solve apps which do their own DNS resolution, yadda
yadda, but then there is no way no NSS to solve them, either; also this
points to the importance of a TCB being curated with a "systems"
perspective (including NSS integration?) rather than trying to bolt stuff
together to get to a merely "functional" solution.

Overall: long-term continuing to shoehorn Onions into DNS for
transparent-proxy name resolution is relentlessly moving towards being
actively painful. I feel that now would be a good time to embrace a
different, ideally standards-compliant / more-futureproof approach.

    -a


[1] Fun reading on a related topic: https://github.com/alecmuffett/dohot









>
> While I can appreciate and understand the many nuances of this
> particular problem, it is one that is indeed difficult to solve.
>
> Are there other commonalities between "infoleaky" deployments that
> could be improved? It seems to me that outright prohibition should be
> a method of last resort. Are we already there?
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>


-- 
https://alecmuffett.com/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20231113/353fa6c0/attachment-0001.htm>