GNU bug report logs - #53941
27.2; socks + tor dont work with https

Previous Next

Full log

View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Christopher Howard <christopher <at> librehacker.com>, Robert Pluim <rpluim <at> gmail.com>, 53941 <at> debbugs.gnu.org, larsi <at> gnus.org, Eli Zaretskii <eliz <at> gnu.org>, gnuhacker <at> member.fsf.org
Subject: bug#53941: 27.2; socks + tor dont work with https
Date: Sun, 15 Sep 2024 18:59:10 -0700

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Christopher Howard <christopher <at> librehacker.com> writes:
>
>> Hello all. I don't pretend to track most of what is going on in this bug
>> thread, but I was wanting to draw more attention to the specific issue of
>> proxies and certs. I use Emacs Elpher for gemini browsing. As a privacy
>> minded individual, I want to by default route everything, including DNS,
>> through my local TOR proxy (localhost:9050). But I also want to be able to
>> check and approve capsule certs and, especially, cert changes. But in
>> Elpher, I have to pick one or the other, since turning on the proxy disables
>> the cert checks. As it has been explained to me, this is due to the current
>> situation with nsm, where you can't have `nsm' checks without also leaking
>> DNS.
>
> Is there an open bug report for leaking DNS with a tor proxy+nsm?

Not that I'm aware of.

>
> If not, would you be willing to report one (including all the details)?

In a sense, the issue only exists in the context of trying to integrate
`socks' with other libraries like `nsm' and `url' (this bug). As such,
there's currently no high-level way (I can think of) to demonstrate its
presence. For that, you'd need an app like Elpher to support connecting
to TLS-terminated endpoints through a SOCKS proxy while verifying them
with `nsm' checks. And you'd need to eavesdrop on it doing so in a
controlled environment where DNS lookups are well understood.

To see how something nearer to a proper (though limited) integration
_could_ work, you can try the demo in the log message of the last of the
attached PoC patches (0004). While it "works," it's quite brittle in the
sense that any unsupported but otherwise normal config patterns (e.g.,
:nowait t) or any related but undetected change to an affected library
(or the underlying networking stack) could render the whole thing bunk.

As I've struggled to explain up thread, the DNS leakage issue is larger
than any prospective integration, `nsm' or otherwise. But, for the sake
of discussion, if we were to zoom in on that library in particular, the
reason for the leakage should be pretty clear. AFAICT, the function
`nsm-should-check' always performs a lookup in order to support the
`nsm-trust-local-network' feature (original author Robert Cc'd). One
possible workaround might be to rework the function slightly to prevent
that, as shown in the first of the attached patches (0001).

Anyway, to truly tackle this issue, I still contend we'd need to
intercept calls to any glibc GAI-related functions and gate them with
some kind of async-friendly mechanism (perhaps a process property) that
suppresses their invocation for the lifetime of the process. The API
could be as simple as:

  (make-network-process ... :nolookup t ...)

But for this, we'd surely need help from someone familiar with that part
of Emacs.

Thanks.

[0000-v6-v7.diff (text/x-patch, attachment)]

[0001-Only-conditionally-resolve-hosts-in-nsm-should-check.patch (text/x-patch, attachment)]

[0002-POC-Support-SOCKS-resolve-extension.patch (text/x-patch, attachment)]

[0003-POC-Simplify-network-stream-openers-in-socks.el.patch (text/x-patch, attachment)]

[0004-POC-Integrate-the-socks-and-url-libraries.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.