From Newsgroup: alt.privacy

In article message-id: <20240928175855.53dO95Q78HGZ@sewer.dizum.com>,
(x-posted to alt.cypherpunks, news.admin.hierarchies, news.software.nntp)
on Sat 28 Sep 2024 17:58:55 -0000, Timothy C. May <tcmay@netcom.com> wrote: >On Thu, 26 Sep 2024 22:17:36 +0000

Dan Mahoney <dmahoney@isc.org> wrote:

All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For
largely historical reasons, ISC also works with those same authors to
publish a canonical list of newsgroups over at ftp.isc.org.

Keep being historical. This is Usenet, after all. First if you abandon FTP, how
long will it be before we see a similar letter from you abandoning NNTP in favor
of Mastodon or some other newfangled, censorship-friendly, rent-seeking protocol
because of misguided client security concerns?

However, as ISC also offers support contracts for BIND and Kea, and those >> customers have their own due diligence policies, we are often subject to >> scrutiny and audits about how our network runs, and even for a venerable >> URL like ftp.isc.org, we get questions from auditors like "did you know
you have a public FTP server on your network! Why!?"

It's not your fault they don't understand how FTP works. And I am skeptical of
this explanation for reasons I will elaborate below.

FTP is also unencrypted, (ftps really never gained any traction as a url
scheme), and in the modern internet, a push for SSL everywhere feels
reasonable as well. The days of hosting mirrors of other FTP sites seem
to belong to a bygone era, and I've disabled the generation of old-school >> files like MIRRORED.BY and ls-lr.gz.

It doesn't need to be a bygone era. You could make the same argument for NNTP >and Usenet. You might as well just pull the plug now and abolish the Big 8. The
Big 8 and Usenet are from the bygone era FTP hails from, so why not just drop it
all at once and enjoy the advertising-driven modern web with its HTTPS cabal >tightening the noose around everything? If the rationale is that FTP is >outdated, then the same logic should apply to the Big 8 and all of Usenet, the C
programming language, the Perl programming language, and canvas sneakers.

We also no longer live in the world where a copy of curl/wget that
supports modern ciphers is not available everywhere.

This is comparing apples and oranges. Curl and wget don't facilitate directory
browsing and FTP/SFTP uploading, downloading, and batch commands in the simple
and interactive way facilitated by FTP.

Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.

Simple, it may be. But is it necessary or optimal? That depends on where the >censorship goblins embed their controls and peddle pullers in the HTTPS >ecosystem. Because that _is_ a thing right now.

As a benefit, this also allows us to use the CDN provider we already use >> for downloads.isc.org. The url would remain ftp.isc.org, and the pathing
would remain the same. We'd still sync the data from Russ as we already >> do).

Better yet, why not demand the CDN support unauthenticated FTP? It would >probably take one of their programmers about three hours to have a working alpha
implementation.

We do not have a specific date yet (this depends on specific feedback from >> the community), but on the order of a month or two sounds reasonable. If >> any software, such as INN, ships with the "ftp" protocol baked-in, this
gives enough time for people to put out new releases and docs that point >> at the change, or at least add the change to their README's, and the like.

Perhaps you might be referring to 'simpleftp' or 'actsync' used with INN? This
speaks to my point above about outdating being ubiquitious rather than >selective. FTP is part of NNTP management and this has been so for decades. >Slicing out FTP is like amputating a hand or foot from the ecosystem.

If/when this happens I'd likely also make a quick post to a few other
network operator places, and suggestions as to where to do so are welcome. >> If there are objections or considerations, please feel free to reply here >> or contact me directly.

You could proxy the HTTPS site to a external FTP server that just translates >the requests. This would move the FTP target off your network. Anyone trying to
call it a security risk would be admitting that every browser connection to your
HTTPS site is also a security risk.

Regards,
-Dan

I have more thoughts on why FTP is actually not outdated but is actually being
underrated in favor of centralized control schemes that are highly overrated and
present massive attack surfaces and censorship mechanisms (looking at you, HTTPS
cabal).

One can serve digitally signed and even encrypted files via ftp, removing the
need for SSL and certificate authorities. Encryption can be handled on user, >event, and file basis rather than connection streams negotiated with certificate
lookups. It is actually simpler and leaves both sysop and client in control of
their mutual interactions. Cryptography and authentication then occurs on a per-
object basis rather than a per-connection basis. The 3rd party certificate >authority in the middle _is_ the proverbial 'man-in-the-middle'.

The push for SSL, TLS, and HTTPS on everything is a push to give certificate >authorities defacto control over accessibility to all networked hosts, including
a centralized veto. I dont't trust the rationales given for this. Had people >understood the power being ceded to these scheming Poindexters and their pocket-
protector clout companies, they likely would have called for heads and pounds of
flesh.

It looks like the censorship infrastructure is being pushed via centralized >control of cryptography, specifically signatures and authentication.

Step 1: Force everyone to use SSL.

- Require certificate authorities.
- Require browser pre-configuration.
- Require exploitable attack surface in server and browser handshakes.

Result: defacto 3rd party power to blacklist resources or insert backdoors.

Step 2: Force everyone to use 2FA and passkeys.

- Your SMS number is blacklisted, you can't connect.
- Your SMS number is linked to a bad social credit score and so you are
punished.
- Your passkeys are identifiable and revokable by 3rd parties.

Result: defacto blacklisting ability of user authentication.

Step 3: Require active monitoring of dissidents based upon installed or >registered certificates and passkeys.

- Down-chain subkey signing can be used to insert cipher keys that
allow transparent MITM proxying.
- The government or corporations can then substitute man-in-the middle
certificates for selected connections.
- The government or corporations can then block individual connections
and authentication.
- The user is completely oblivious if being monitored.
- The user is completely helpless without remedy if being censored or
blocked.

Use the The Onion Network as a syllogism for this. It would not be much work to
alter the TOR protocol from a mixnet to a key-based authentication network. >Currently TOR is open. With subtle changes, it can be converted to a access >control ecosystem. Whoever then registers and verifies the keys then has the >power to grant or deny access. Extapolate that to the larger Internet for >comparison.

If the files on a FTP server are digitally signed with the downloader verifying
signatures then the connection is technically secure even if plaintext. None of
these hazards presented by certificate authorities exist in the simpler scheme
of per-object cryptography. The government would need to cut the pipe at the ISP
and the affected parties would know immediately and have recourse. Certificate
schemes offer sneakier ways to fiddle around with these liberties.

Moreover, authenticated FTP can present unique cipher keys for encryption and
decryption based on user and server preferences, and plug in any algorithm >desired or allowed by the mutual parties. It's not really outdated. It is just
under-used, underrated, and not fully explored in its potential.

In other words, the only substantial thing SSL / TLS / HTTPS do that FTP >doesn't do is farm out control over user cryptography to 3rd parties. Thus the
security protocol can be remotely transformed into the censorship protocol with
the flip of a switch or click of a mouse. Many a hacker working on the source >code would unflinchingly accept a bribe to insert a back door bug. Any >government can secretly mandate insertion of backdoor bugs or MITM keys with gag
orders. What is being done with 'security' is contrary to the stated purposes of
the Internet--free and open access to information while retaining privacy of the
user and data.

Don't bore me with lame arguments that the bean counters don't realize this is
the infrustructure being layered over the data. That is what it is. It is >centralized, fragile, exploitable and unnecessary. The pocket-protector >praetorians are solving every problem we didn't know we had, making things >vastly more complex and exploitable in the process. At least all this complexity
boondoggle keeps racking up the billable hours, right?

Simpler schemes would have been more fitting while allowing control to remain >exclusively between the negotiating parties. If it were up to me I would let the
banks and online shoppers use their certificate authorities, and let everyone
else alone with better alternatives instead of trying to shoehorn the whole >world into a Chinese finger puzzle buried in a jello mold. This way the CA only
has power to try censoring those with deep pockets, who would then get into the
CA pockets to teach them a lesson.

Theoretically, dropping FTP would allow CAs to shut down or inconvenience a >Usenet peer. Although not likely now, circumstances and motives have a way of
changing quickly so that less likely becomes actuality.

The cypherpunk ideals included users controlling their own cryptography rather
than being forced to farm out authentication and confidentiality to third-party
interlopers. The true aims of the HTTPS cabal are obvious. The HTTPS ecosystem
is building a censorship and surveillance jail, not a digital frontier.

very +1

--- Synchronet 3.21e-Win32 NewsLink 1.2