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@xxxxxxx
<mailto:kaizushi@xxxxxxx>> 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@xxxxxxxxxxxxxxx <mailto:shawn.webb@xxxxxxxxxxxxxxx>>
> 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@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
<https://e.as207960.net/w4bdyj/zr6q9PzRuKTSXztm>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx>
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
<https://e.as207960.net/w4bdyj/gDGxBMpi3EbfZqn3>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev