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

Wed Sep 25 09:23:07 UTC 2024

Moin,

I've posted my thoughts on a potential solution to this in GitLab:
https://e.as207960.net/w4bdyj/9xhwJKBpklMvCk1U
It'd be great to hear some of your views on this.

Q
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.

On Mon, 15 Jan 2024 at 09:31, <kaizushi at cock.li> wrote:

> The thing with this issue, and their ignorant attitude to it, is that it
> is this easy to patch. The if statement that does this could simply be
> nested in another that checks for an environment variable, giving users
> an option to enable .onion resolution.
>
> diff --git a/lib/hostip.c b/lib/hostip.c
> index e7c318a..c0e2583 100644
> --- a/lib/hostip.c
> +++ b/lib/hostip.c
> @@ -693,12 +693,12 @@ enum resolve_t Curl_resolv(struct Curl_easy *data,
>     struct connectdata *conn = data->conn;
>     /* We should intentionally error and not resolve .onion TLDs */
>     size_t hostname_len = strlen(hostname);
> -  if(hostname_len >= 7 &&
> -     (curl_strequal(&hostname[hostname_len - 6], ".onion") ||
> -      curl_strequal(&hostname[hostname_len - 7], ".onion."))) {
> -    failf(data, "Not resolving .onion address (RFC 7686)");
> -    return CURLRESOLV_ERROR;
> -  }
> +//   if(hostname_len >= 7 &&
> +//     (curl_strequal(&hostname[hostname_len - 6], ".onion") ||
> +//      curl_strequal(&hostname[hostname_len - 7], ".onion."))) {
> +//    failf(data, "Not resolving .onion address (RFC 7686)");
> +//    return CURLRESOLV_ERROR;
> +//  }
>     *entry = NULL;
>   #ifndef CURL_DISABLE_DOH
>     conn->bits.doh = FALSE; /* default is not */
>
> On 2023-11-13 16:34, Alec Muffett wrote:
> > 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://e.as207960.net/w4bdyj/IsIm9uMjppFq16LY
> >
> >> _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://e.as207960.net/w4bdyj/2RnRltBZFAbcwajS
> >
> >> 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://e.as207960.net/w4bdyj/Z0daSoNo4acUxsuA
> >> _______________________________________________
> >> tor-dev mailing list
> >> tor-dev at lists.torproject.org
> >> https://e.as207960.net/w4bdyj/CDOLRn01siVeossp
> >
> > --
> >
> > https://e.as207960.net/w4bdyj/Mc1ds6nVWzOmCdfN
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://e.as207960.net/w4bdyj/L5mZffCQAo9FS4RO
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://e.as207960.net/w4bdyj/IJr5dU66PARagjnn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240925/ceca968d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4640 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240925/ceca968d/attachment-0001.bin>