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, <kaizu...@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.w...@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@lists.torproject.org > >> https://e.as207960.net/w4bdyj/CDOLRn01siVeossp > > > > -- > > > > https://e.as207960.net/w4bdyj/Mc1ds6nVWzOmCdfN > > _______________________________________________ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://e.as207960.net/w4bdyj/L5mZffCQAo9FS4RO > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://e.as207960.net/w4bdyj/IJr5dU66PARagjnn >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
