[tor-dev] Rewriting to e.as207960.net (was: When RFC 7686 and transparent proxies collide)
Matt Traudt
pastly at torproject.org
Sat Sep 28 19:37:29 UTC 2024
Your email client, I presume, is rewriting links to first go through
e.as207960.net.
I'm curious why that is.
Matt
On 9/25/24 04:23, Q Misell via tor-dev wrote:
> Moin,
>
> I've posted my thoughts on a potential solution to this in GitLab:
> https://gitlab.torproject.org/tpo/core/torspec/-/issues/202#note_3082599
> <https://e.as207960.net/w4bdyj/b4yUtwaLLRhQJViz>
> 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://e.as207960.net/w4bdyj/QNgv0XX1JAdkWwBw>, LEI
> 875500FXNCJPAPF3PD10. ICO register №: ZA782876
> <https://e.as207960.net/w4bdyj/5DC5LycGrOKNGfsl>. 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
> <mailto: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 <mailto: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://e.as207960.net/w4bdyj/IWBCUzE1g9eSaNb1>
> >
> >> _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
> <https://e.as207960.net/w4bdyj/Se5C9eJQNqnS5Q2E>
> >
> >> 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 <https://e.as207960.net/w4bdyj/vYCCJW75LbyqcEU4>
> >> _______________________________________________
> >> tor-dev mailing list
> >> tor-dev at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> <https://e.as207960.net/w4bdyj/bzSRc5SkhehEL5u8>
> >
> > --
> >
> > https://alecmuffett.com/about
> <https://e.as207960.net/w4bdyj/6SNz8GVVLxs4K8i8>
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> <https://e.as207960.net/w4bdyj/zr6q9PzRuKTSXztm>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> <https://e.as207960.net/w4bdyj/gDGxBMpi3EbfZqn3>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
More information about the tor-dev
mailing list