Hi Wolfgang,
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!?"
I've been working for several large companies that are legally required
to carry out annual audits of their IT infrastucture, both internal and
outsourced, and had to deal with external auditors from PWC, KPMG and
E&Y, to name just a few, and I know that it's absolutely impossible to
argue with external auditors and your customers' management if you care
about your mental health. They will drag you down to their level and
beat you with experience, so ISC is not to blame, IMHO.
You are doing well to remind that. I also regularly see external audits
on some critical systems used for the public transport in Paris where I
work, and we are just asked to follow the recommendations, not to >counter-argument them.
For the most vital systems, a certification is needed by the ANSSI in
France. I think it is a bit like the NSA in the USA or the BSI in
Germany. Quoting Wikipedia: "The French National Agency for the
Security of Information Systems is a French service created on 7 July
2009 with responsibility for computer security. ANSSI reports to the >Secretariat-General for National Defence and Security (SGDSN) to assist
the Prime Minister in exercising his responsibilities for defence and >national security. The agency ensures the mission of national authority >security of information systems. As such it is responsible for
proposing rules for the protection of state information systems and
verify the implementation of measures adopted. In the field of cyber >defence, it provides a monitor, detect, alert and reaction to computer >attacks, especially on the networks of the State."
be nice if ISC offered rsync for selected IP addresses. This would allow
us to continue to operate mirrors that can then be accessed via FTP and HTTPS.
Heiko
. . .
As far as INN is concerned, I'll soon provide an updated version of
actsyncd which currently can only synchronize the active file from FTP
and NNTP external sources. I'll add support for HTTP(S).
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.
On 26.09.2024 um 22:17 Uhr Dan Mahoney wrote:
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!?"
Why is that a problem for your customers?
FTP is unencrypted, but the stuff on the ftp server is public.
I know that some people hate this protocol and want everybody to use
HTTPS, but HTTPS has some vast disadvantages compared to FTP.
We also no longer live in the world where a copy of curl/wget that
supports modern ciphers is not available everywhere.
ftp supports a standardized directory listing. HTTP doesn't. One big
reason for not using HTTP.
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. As a benefit, this also allows us to use the CDN provider we
already use for downloads.isc.org.
Is there that much traffic that a CDN is needed?
I like the distributed concept of the internet and I see a big
disadvantage in sourcing that out to only a small amount of CDN
operators.
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.
This will most likely break many usenet servers because I don't think
every newsmaster will have a look at such stuff that often.
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.
Might be true, but be aware that most systems run on operating systems
that don't always have the latest upstream packages. Systems like
Debian have package versions that are sometimes older than 1 or 2 years
with security backports.
If there are objections or considerations, please feel free to reply
here or contact me directly.
I don't see a real reason to shut down the ftp server. If some of your >customers don't like the FTP protocol, they don't need to use it.
...[end quoted excerpt]
https://archive.org > post > 240921 > ftp-read-access-is-going-away
Internet Archive Forums: FTP read-access is going away >https://archive.org/post/240921/ftp-read-access-is-going-away
Apr 8, 2009 10:53am. Forum: etree. Subject: FTP read-access is going away. >The Archive will continue to support FTP uploading for some time, but we
are phasing out FTP read access in favor of HTTP (web) access. FTP is
pretty ancient and makes it hard for us to support well. We hope this
will not be a major . . .
["Followup-To:" header set to news.software.nntp.]
On Thu, 26 Sep 2024 22:56:19 -0000 (UTC), Adam H. Kerman wrote:
Dan Mahoney <dmahoney@isc.org> wrote:
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. >>>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).
Switching to https is not so simple. Those of us who use it regularly
want to see directory listings. I get these automatically using an ftp
client but not when I use a browser. With a browser, subdirectories are
listed but Russ's README is not (I think there are three of them).
Every single directory, then, requires a frequently regenerated
index.html file that's literally a directory listing, both files and
subdirectories.
I've been running HTTP/HTTPS servers for several decades now, including >really obscure ones embedded on microcontrollers and I can't think of a >single one -- much less one you would consider using today that doesn't
have a built-in facility to dynamically generate a directory listing at
the time of requeste. One does not need to (re-)generate index.html
files, the server will synthetically do that if configured properly.
I certainly will be sad to see FTP go away, but this is unlikely to
be a persuasive argument to anyone configuring or maintaining the
HTTP/HTTPS server.
--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh
The days of hosting mirrors of other FTP sites seem to belong to a bygone era, [...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:09:33 |
| Calls: | 9,820 |
| Calls today: | 8 |
| Files: | 13,757 |
| Messages: | 6,190,102 |