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

[Shawn Webb]

On Sun, Nov 05, 2023 at 12:57:40AM +0000, kaizushi at cock.li wrote:
> They blatantly don't care and deny the issue, and don't care that it breaks
> a feature Tor has had for over a decade. They respond with fallacies and
> irrational garbage. They don't acknowledge that an environment variable
> would fix the issue and tacitly admit not to care.
> 
> Fortunately I run Gentoo and this stupid bit of code is very easy to fix on
> that distribution. I made this patch and used /etc/portage/patches to fix
> it, which is a page on the Gentoo Wiki: https://bpa.st/Q4VQc - I think this
> illustrates how simple this issue is as well as fixing it for all users.
> 
> However, the transproxy feature allows for people to idiot proof their
> systems and share with people which is supposed to be what open source is
> about. I hope as many people call out this kind of ignorant behavior for
> what it clearly is. You can see the depths of their stupidity and denial
> here...

The prohibition of .onion in libcurl presents a problem for existing
production HardenedBSD deployments in certain environments where
transparent proxying is used rather than SOCKS. Systems living in such
environments now cannot be updated, even to patch security
vulnerabilities.

HardenedBSD provides Tor Onion Service endpoints for all its
publicly-facing infrastructure. Users can go from zero to dev to prod
completely behind a fully Tor-ified network (via transparent
proxying).

But now that libcurl, which the HardenedBSD package manager uses,
prohibits .onion DNS record resolutions, our users are not able to
access our Tor Onion Endpoints, leaving them insecure and vulnerable
to exploitation by bad actors.

With the curl project's unwillingness to compromise, HardenedBSD is
now forced to maintain a patch to revert the prohibition. But that
only applies to HardenedBSD users. What about users of other operating
systems with similar transparent proxy deployments?

I would strongly suggest to officially clarify the RFC or strike the
relevant section altogether. Without doing so, the curl project seems
unwilling to make the prohibition a choice that can be made at runtime
by the user, even.

Please remember that these kinds of things have real and tangible
human consequences. Some of our users remain in harms way to this day
because of this.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20231111/cdb8455a/attachment.sig>