home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.privacy      Discussing privacy, laws, tinfoil hats      112,125 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 110,759 of 112,125   
   D to Timothy C. May   
   Fw: ISC will likely be shutting down FTP   
   29 Sep 24 13:16:46   
   
   From: noreply@mixmin.net   
      
   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  wrote:   
   >On Thu, 26 Sep 2024 22:17:36 +0000   
   >Dan Mahoney  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.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca