Message-Id: <20240929.040919.c3b01cec@remailer.frell.eu.org>
Date: Sun, 29 Sep 2024 04:09:19 +0200
References: <1f19a554-8a81-ce8c-8ac6-7ab1e053a632@isc.org>
 <20240928175855.53dO95Q78HGZ@sewer.dizum.com>
Subject: Re: ISC will likely be shutting down FTP access to ftp.isc.org soon
 (https will remain)
Content-Transfer-Encoding: 7bit
From: D <J@M>
Newsgroups: news.software.nntp
Path: ...!news.mixmin.net!news2.arglkargh.de!alphared!sewer!news.dizum.net!not-for-mail
Organization: dizum.com - The Internet Problem Provider
X-Abuse: abuse@dizum.com
Injection-Info: sewer.dizum.com - 2001::1/128
Bytes: 11368
Lines: 192

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
========== REMAINDER OF ARTICLE TRUNCATED ==========