Mozilla schakelt ftp-ondersteuning standaard uit in Firefox 77

Mozilla gaat in versie 77 van Firefox, die in juni uit moet komen, de ftp-functionaliteit van de browser standaard uitschakelen. Begin 2021 moet ftp-ondersteuning er volledig uit zijn. Volgens Mozilla is ftp niet veilig en wordt het niet vaak genoeg gebruikt om te onderhouden.

Ftp zal volgens Mozilla nog wel standaard ingeschakeld zijn in de extended support release van Firefox 78, maar dat is ook het laatste wat Mozilla voor ftp doet. Daarna zal Firefox naar het besturingssysteem refereren voor het afhandelen van url's die beginnen met ftp://. Sinds versie 60 uit 2018 heeft Firefox al een flag in about:config voor het in- of uitschakelen van ftp-ondersteuning.

Google loopt ietwat voor op Mozilla op dit vlak. Vorig jaar werd al bekendgemaakt dat het einde in zicht is voor ftp-ondersteuning in Chrome. Daar wordt de functie met ingang van versie 78 afgebouwd. De stable branch van Chrome zit nu op versie 80. In versie 82 zal ftp er volledig uit zijn. Chrome-updates staan nu echter op pauze wegens het coronavirus, dus deze zet is vertraagd.

De Mozilla-dev van de posting bestempelt ftp als 'onveilig, oud en moeilijk te onderhouden'. Het inbouwen van ondersteuning voor veiligere varianten als sftp is een optie, maar daar lijkt Mozilla niet aan te gaan. "Er is geen reden om ftp te prefereren in plaats van https bij het downloaden", stelt hij. In Googles motivatie om ftp uit te faseren stelde het dat slechts 0,1 procent van gebruikers nog ftp gebruikte.

Reacties (94)

Ergens jammer dat de functie eruit gaat. Aan de andere kant; mensen die wel FTP gebruiken, doen dat (in mijn ervaring) toch vooral al met speciale FTP clients zoals bijvoorbeeld FileZilla. En inderdaad, een FTP verbinding is niet veilig, er zit dan geen versleuteling op, maar voor SFTP (FTP over SSH) of FTPS (FTP verbinding met TLS) heeft de browser ook weer geen ondersteuning voor.

De functie is daardoor een beetje een soort van dood gebloed denk ik. Maar aan de andere kant zijn er ook de clouddiensten zoals Google Drive, Dropbox en OneDrive, maar ook bijvoorbeeld WeTransfer, Stack en (vanuit Mozilla) natuurlijk Firefox Send, waardoor de noodzaak voor een FTP functie binnen Firefox eigenlijk ook een beetje gigantisch overbodig is geworden.

maar voor SFTP (FTP over SSH)

SFTP is niet FTP over SSH

SFTP is letterlijk SSH File Transfer Protocol. Wat het doet is: file transfer using SSH.

Dat het gebruikte protocol in niets lijkt op FTP is wellicht waar. Maar gezien de rotzooi die de bedenkers van FTP er (uiteindelijk) van gemaakt hebben kun je het TransIP niet kwalijk nemen dat ze proberen wat duidelijkheid te scheppen.

En met rotzooi bedoel ik twee verschillende connectie vormen: passief, actief die elk in combinatie met FTP, implicit FTPS, explicit FTPS dat zijn dus 6 verschillende overdrachtsmanieren die allemaal op hun eigen manier en met andere firewall eisen werken. Om helemaal gestoord van te worden.

SFTP is dan de minst erge van deze opties maar inderdaad niet echt FTP. Ze hadden het dan ook nooit SFTP mogen noemen wat mij betreft. Maar ook SFTP is niet ideaal aangezien je voor iedereen een unix user aan moet maken en is de server config relatief complex.

Letterlijk gezien niet nee, maar in de praktijk is het een implementatie van FTP binnen SSH2, dus toch wel FTP over SSH.

Sorry? Zou TransIP er naast zitten dan?

Ja. SFTP is onderdeel van SSH 2.

FTP en SFTP zijn 2 heel verschillende dingen met hetzelfde doel.

https://www.2brightsparks...er-protocol-explained.pdf

Ook de opmerking

zo lang je bijvoorbeeld je SSH-poort verandert

is onzinnig in het verhaal van Transip. Poort veranderen maakt helemaal niets veiliger.

[Reactie gewijzigd door daemonix op 21 maart 2020 16:47]

Poort veranderen maakt helemaal niets veiliger.

Volgens mijn logs houdt het wel een heleboel hackbots tegen.

Het is echter maar schijnveiligheid; de linker deur is niet open, maar de rechter. Iemand die een beetje handig is, prikt daar zo doorheen, door bijvoorbeeld eerst een poortscanner te draaien, dan weet hij al welke deuren er open staan en is hij al halverwege.

Ja tuurlijk, maar het is beter dan alles op defaults te laten staan.

Mwa, met een goede beveiliging er tussen is een boel ook goed af te vangen, schijnbeveiliging is echt niet meer nodig meer. Bovendien ook erg verwarrend voor bijvoorbeeld applicaties; veel hebben een standaard poort toegewezen gekregen immers. Ik heb ook geen zin om voor elke website die ik bezoek een ander poortnummer te moeten gebruiken, bijvoorbeeld.

[Reactie gewijzigd door CH4OS op 22 maart 2020 02:04]

Het is geen vervanging van beveiliging, dat is toch altijd relatief aan hoe gemotiveerd de aanvaller is. Iemand die echt per se naar binnen wil die vindt uiteindelijk wel een manier. Maar naar mijn mening moet je wel voor het maximaal haalbare gaan om het risico op inbraak zo klein mogelijk te houden. Voor de publieke poorten is het inderdaad niet handig om ze te veranderen, voor sommige zelfs onmogelijk zoals inbound mail. Daar is je IDS voor, maar ook dat is software met fouten. SSH is echter bedoelt voor beheer of hosting klanten, een heel select publiek. Naast de IDS en eventueel IP whitelist of zelfs een vpn, kan je met alternatieve poorten wel een hoop 'lucky bastards' wegsturen. Het is ook zonde van de cpu tijd en audit logs om dat aan hen te besteden.

Het verschuiven van de ingang, terwijl je de ingang goed beveiligd wilt hebben, is gewoon geen goede beveiliging. Het is nu echt een peulenschil om rond scheinbeveiliging heen te gaan, het kost niemand meer moeite om direct op het juiste doel af te gaan.

SSHGuard of Fail2Ban zijn betere oplossingen.

Met een andere poort krijg je weliswaar minder probes die langs komen. Maar je hoeft er maar 1 te hebben die wel andere poorten controleert en je hebt een brute force attack aan je broek.

Ik gebruik idd fail2ban op al mijn servers. SSH staat open op de standaardpoort maar zonder password auth (alléén key-based). Binnen een dag heb je een paar duizend pogingen en iedereen die over de threshold gaat komt mooi op mijn blacklist.

Andere poorten gebruiken is inderdaad niet per definitie veiliger, draagt wel bij aan de security through obscurity.

Je ziet het nog wel met enige regelmaat gebruikt worden bij bedrijven en opleidingsinstituten die verwijzen naar een FTP locatie om informatie te downloaden.
Maar goed ik snap dat commerciële browsers er voor kiezen om hun kosten laag te houden en deze functionaliteit te schrappen, als ze dat nou ook eens deden met de overige troep zoals allerlei brakke bestandsviewers, dan waren ze ten minste echt goed bezig.
Ik hoop overigens dat er gewoon een plugin via bijvoorbeeld Filezilla uitkomt zodat je alsnog SFTP e.d. kunt doen in Firefox en Chrome.

Maar goed ik snap dat commerciële browsers er voor kiezen om hun kosten laag te houden en deze functionaliteit te schrappen, als ze dat nou ook eens deden met de overige troep zoals allerlei brakke bestandsviewers, dan waren ze ten minste echt goed bezig.

Ik zou er echt geen nacht minder om slapen en zou het totaal niet missen, aangezien ik meestal FileZilla gebruik voor (S)FTP(S) file transfers.

Ik hoop overigens dat er gewoon een plugin via bijvoorbeeld Filezilla uitkomt zodat je alsnog SFTP e.d. kunt doen in Firefox en Chrome.

Er zijn volgens mij zat plugins die dat doen, maar aan de andere kant zie ik ook niet waarom je niet gewoon FileZilla zou gebruiken, dat is gewoon een gratis FTP client.

Effe snel 1 bestand downloaden is wel fijn via browser, maar inderdaad ook ik gebruik een (s)ftp(s) client.

Ik heb een vraag: van Firefox Send had ik nog niet eerder gehoord, maar is er een reden om die te prefereren boven Wetransfer? Maakt het bijvoorbeeld iets uit op het gebied van privacy?

Mozilla maakt namelijk nogal een punt van de nadruk leggen op privacy. Dat merk ik behoorlijk sinds ik sinds kort van Chrome ben overgestapt naar Firefox (en van Google.com naar Duckduckgo).

Send is E2E encrypted. De sleutel staat in de URL, na de #, maar dat stuk van de URL wordt door de browser niet naar de server gestuurd. Nog steeds is het een kwestie van vertrouwen, want de code voor het versleutelen komt immers ook van Mozilla...

Voor mij is het vooral een privacy dingetje inderdaad, waar dat bij send.firefox.com beter gegarandeerd is dan bij WeTransfer.

privacy en met account 2.5gb max geloof ik, wetransfer max 2gb. tenzij je betaald, firefox send is altijd gratis met of zonder account.

[Reactie gewijzigd door t link op 21 maart 2020 15:53]

Firefox Send en Mega zijn mijn favorieten om bestanden af te sturen.

https://mega.nz/about/main

MEGA werd gelanceerd op 20 januari 2013 - precies een jaar na de beruchte vernietiging van Megaupload door de Amerikaanse regering. Het werd opgericht door dezelfde mensen die Megaupload hadden gemaakt, waaronder Kim Dotcom, Mathias Ortmann en Bram van der Kolk.

Dat wekt bij mij geen vertrouwen.

Dan houd ik het wel bij Firefox Send.

[Reactie gewijzigd door Uruk-Hai op 23 maart 2020 10:23]

Wat is er mis met die 3 mensen? Hun zijn juist voor encryptie, en privacy.

[Reactie gewijzigd door Bjorn89 op 25 maart 2020 12:22]

Kim Dotcom staat nu niet bepaald bekend om zijn integriteit...

Als het vanuit veiligheid wordt uitgefaseerd en we nemen de voorbeelden die jij aandraagt als vervanging, dan denk en weet ik dat veiligheid behoorlijk subjectief is.

Als FTP niet veilig is dan is HTTP ook niet veilig. Ik zie het echter niet zo snel gebeuren dat dit uitgeschakeld gaat worden

Inderdaad. Ik downloadde gisteren nog een (nieuwe) driver van HP via hun ftp verbinding. Ze kunnen beter wat anders verzinnen voor ftp verbindingen met een wachtwoord.

Als de gegevens publiekelijk beschikbaar zijn maakt het toch niet uit of dit encrypted is of niet

Dus je vind het niet belangrijk dat als je wat download dit ook daadwerkelijk is wat je verwacht? Het gaat er niet om dat iets versleuteld is maar wel dat je weet dat wat je download ook daadwerkelijk zuivere koffie is. Met plain HTTP kan iemand via een MITM je data manipuleren en heb je een driver met backdoor/worm etc. te pakken.

Daarvoor heb je MD5 hashes.

Daarvoor heb je MD5 hashes.

Nee? Dat is er voor om de integriteit te waarborgen. Dus dat wat je download over gekomen is zonder fouten. Een MITM staat het vrij om die hash aan te passen omdat je niet kan valideren dat die md5 van de oorspronkelijke eigenaar is.

Je gebruikt dan eerder GPG signatures waarbij je dat dus wel kan.

Hoe dan ook moet je gebruik maken van een authenticatie algoritme waardoor je met een sleutel kan valideren of er mee geknutseld is.

Die sleutel overdracht kan offline vooraf zijn gedaan of via een ander veilig online medium of via een key exchange protocol zoals Diffie-Helman (zoals met TLE/HTTPS).

Dit kan allemaal onversleuteld maar wordt vaak samen gedaan met encryptie. Eerst wordt de authenticatie toegevoegd (de hash) en dan wordt dat versleuteld, ofwel authenticated encryption.

[Reactie gewijzigd door Ventieldopje op 21 maart 2020 18:07]

Als de hash verschillend is, is er geknoeid met het bestand, tijdens de transfer
Als ik bij het downloaden van een publiek bestand als een linux-iso, mij meer vragen moet stellen dan gaat SFTP/FTPS ook niet voldoende zijn, want wie verzekert me dat het het bestand zelf al niet vervuild is.
Dan is MITM wel het minste van mijn mogelijke problemen.

Dus neem nu, ik ga naar ftp.belnet.be, hoe gaat dit MITM attack dan volgens jou in zijn werk ??

[Reactie gewijzigd door klakkie.57th op 21 maart 2020 19:10]

Snap niet dat je een -1 krijgt want je hebt gewoon gelijk: hashes zijn er om te zien of je daadwerkelijk hetzelfde bestand hebt ontvangen als dat je verwacht, dat kan of zijn garbled data in transmissie, ofwel een malicious source met een aangepaste file. Nou is md5 niet het meest secure, maar andere crypto hashes dienen zeker dit doel.

Hoe je die hash secure binnen krijgt is een tweede, maar via een SSL website met een certificate van een trusted source is bv een manier.

Ten derde, MITM, sure, hoe vaak komt dat nou voor. Dat er iemand tussen m'n vaste verbinding op het ziggo netwerk zit en een switch gekaapt heben... ja, het kan, en als ik militaire geheimen zou willen downloaden zou ik geen ftp gebruiken, maar voor die printer driver.... tsja

En dan als laatste, ok nu is het helemaal secure, sftp, ssl, DH key exchange, en download je ultra secure je printer drivers van https://hpdriver.com, en hengel je een geinfecteerde driver binnen, want oops, dat was niet HP. Wel secure transfers!

En dat laatste toont dus ook aan waarom je transfer security geen hol uitmaakt als je toch al je source moet verifieren. Dan heb je toch al een crypto secure hash en kan je het volstrekt onveilig transferen: mits je het ok vindt dat men (read-only) ziet wat je download

[Reactie gewijzigd door Zoijar op 21 maart 2020 19:28]

Precies, dat bedoel ik.
Als je al onderhevig bent aan MITM , dan heb je werkelijk heel andere dingen om je zorgen over te maken dan de verbinding naar een ftp server

Snap niet dat je een -1 krijgt want je hebt gewoon gelijk: hashes zijn er om te zien of je daadwerkelijk hetzelfde bestand hebt ontvangen als dat je verwacht, dat kan of zijn garbled data in transmissie, ofwel een malicious source met een aangepaste file. Nou is md5 niet het meest secure, maar andere crypto hashes dienen zeker dit doel.

Hoe je die hash secure binnen krijgt is een tweede, maar via een SSL website met een certificate van een trusted source is bv een manier.

[...]

Dus authenticatie is tóch ineens wel belangrijk nu? Je wil namelijk wel zeker weten of de MD5/SHA hash die je binnen hengelt wél betrouwbaar is want anders had je die ook gewoon net zo goed via http/ftp binnen kunnen trekken.

Nogmaals een MD5/SHA hash zijn er alleen voor de verificatie van de data en hebben alleen zin als je de hash kan vertrouwen.

Ik laat jou bestand A downloaden via mijn FTP server maar geef jou face-to-face de SHA hash voor bestand A. Je kan er nu vrij zeker van zijn dat als je het bestand verifieert met die hash dat het ook klopt. Laat ik je vervolgens bestand B downloaden (of een hele rits bestanden), dan moet ik jou voor elk bestand face-to-face een hash geven. Enorm veel werk dus.

Daarom bestaan er dus authenticatie algoritmen waarmee je één keer veilig een sleutel uitdeelt waarmee je vervolgens een hele bult bestanden mee kan verifiëren én authenticeren.

[...]

Ten derde, MITM, sure, hoe vaak komt dat nou voor. Dat er iemand tussen m'n vaste verbinding op het ziggo netwerk zit en een switch gekaapt heben... ja, het kan, en als ik militaire geheimen zou willen downloaden zou ik geen ftp gebruiken, maar voor die printer driver.... tsja

[...]

Die reactie verwachtte ik al. Waarom zou ik mijn auto op slot doen, ik woon in een veilige buurt. Waarom zou ik geld op de bank zetten, zo veel heb ik niet en wie gaat er nou in mijn huis inbreken. Ga zo maar door.

Hier is het misschien een ver van je bed show maar in heel veel landen is dat niet het geval en dan heb ik het niet over verweggistan.

Overigens... publieke WiFi?

En dan als laatste, ok nu is het helemaal secure, sftp, ssl, DH key exchange, en download je ultra secure je printer drivers van https://hpdriver.com, en hengel je een geinfecteerde driver binnen, want oops, dat was niet HP. Wel secure transfers!

En dat laatste toont dus ook aan waarom je transfer security geen hol uitmaakt als je toch al je source moet verifieren. Dan heb je toch al een crypto secure hash en kan je het volstrekt onveilig transferen: mits je het ok vindt dat men (read-only) ziet wat je download

Het gaat allemaal op basis van vertrouwen. Met veilige verbindingen (public key cryptography) heb je een certificaat van een vertrouwde partij ontvangen (een Certificate Authority, CA). Normale simpele certificaten bieden niet veel hulp in het kunnen verifiëren wie het certificaat aangevraagd heeft, alleen dat de gene die het aangevraagd heeft eigenaar is van het domein. Daarom zijn er ook OV en EV certificaten welke duurder zijn maar meer informatie geven over de partij aan wie het certificaat is verstrekt en daarvoor zijn strengere eisen. De CA zorgt er voor dat ze de checks doen en de aanvraag dus aan de eisen voldoet dus je moet de CA vertrouwen wat in de meeste gevallen niet zo'n probleem is, maar soms gaat het wel eens mis.

Dat je de driver van een malafide website download die bijvoorbeeld doormiddel van phishing jouw aandacht heeft getrokken is gewoon je eigen schuld heel simpel gezegd. Ik krijg al een melding in mijn browser als ik die site open bijvoorbeeld en het lijkt mij stug dat zij een OV/EV certificaat hebben van HP, iets wat je zelf kan en ook dient te controleren.

Veel sites hebben echter ook een Let's Encrypt certificaat wat alleen simpele geautomatiseerde checks uitvoert op certificaten, Tweakers heeft er bijvoorbeeld ook een. Wat niet erg is want persoonlijk acht ik de kans klein dat iemand het domein tweakers.net in handen krijgt zonder dat we het allemaal door hebben. Het is dus een persoonlijke afweging en tsja welkom bij de IT, niet alles is even makkelijk altijd en daar hoort een stukje scholing bij.

Er zit een wezenlijk verschil in FTP en HTTP; bij FTP is het de bedoeling dat je inlogt op een server in een beschermde omgeving. Die informatie wordt dus als platte tekst over het web gestuurd. Daarnaast is HTTP nog nodig voor verschillende toepassingen, al kan je als ontwikkelaar bijvoorbeeld ook lokaal redelijk makkelijk over op HTTPS. Over 10 jaar kunnen we misschien HTTP de deur uit doen voor gebruik in de browser, maar het gebruik van HTTP is nog totaal niet waar FTP nu is.

Er zit een wezenlijk verschil in FTP en HTTP; bij FTP is het de bedoeling dat je inlogt op een server in een beschermde omgeving. Die informatie wordt dus als platte tekst over het web gestuurd. Daarnaast is HTTP nog nodig voor verschillende toepassingen, al kan je als ontwikkelaar bijvoorbeeld ook lokaal redelijk makkelijk over op HTTPS. Over 10 jaar kunnen we misschien HTTP de deur uit doen voor gebruik in de browser, maar het gebruik van HTTP is nog totaal niet waar FTP nu is.

Laten we wel appels met appels vergelijken, en geen publieke HTTP-sites vergelijken met private FTP-sites. De meeste FTP-servers zijn publiek toegankelijk. Strict genomen log je wel in, maar de hele wereld gebruikt dezelfde algemeen bekende account, als het wachtwoord uberhaupt al gecontroleerd wordt.
FTP is net zo veilig of onveilig als HTTP. We moeten van allebei af, maar er zit geen wezenlijk verschil in de veiligheid.

[Reactie gewijzigd door CAPSLOCK2000 op 21 maart 2020 13:18]

Dat klopt, de meestgebruikte FTP sites zonder encryptie zijn downloadsites en die zijn anoniem/publiekelijk. Een voordeel van FTP is, dat het mogelijk is om meerdere bestanden en mappen te selecteren en die in een keer te downloaden.

Verder begrijp ik niet precies wat ze bedoelen met "moeilijk te onderhouden". Het protocol is in de basis al vrij simpel en is dit millennium niet meer veranderd...

[Reactie gewijzigd door Ablaze op 21 maart 2020 13:34]

Verder begrijp ik niet precies wat ze bedoelen met "moeilijk te onderhouden". Het protocol is in de basis al vrij simpel en in dit millennium niet meer veranderd...

Ik vrees dat ze bedoelen dat het geen HTTP is. Er is een steeds grotere groep mensen die denken dat HTTP het enige protocol op internet zou moeten zijn. Deels wordt dat in praktijk gesteund door strenge netwerken en firewalls die de facto niks anders dan http(s) doorlaten. Het voelt vaak als "als je alleen een hamer kent, ziet alles er als een spijker uit".
Hierdoor worden steeds meer protocollen herschreven/afgeschaft of vervangen door een variant die eigenlijk niks toevoegt anders dan dat er HTTP als transportprotocol gebruikt wordt. Voorstanders schermen er mee dat het veiliger is omdat je HTTPS kan gebruiken (en dat is op zich waar) of dat het niet geblokkeerd kan worden (en dat is en stuk minder waar).
De nadelen zijn echter dat je de overhead van HTTP er bij krijgt, dat andere systemen een stuk complexer worden, dat de veiligheid maar relatief is omdat verouderde/verkeerde certificaten nog zo gewoon zijn dat je het niet streng kan afdwingen als je de gebruiker niet om uitzonderingen kan vragen en dat we steeds meer van HTTP verwachten wat het gevaar van feature creep met zich meebrengt.
Daarnaast is het voor beheerders erg lastig dat alle verkeer opgaat in dezelfde grijze brij waar niet meer voor te optimaliseren valt omdat de doelen behoeftes zo verschillend zin. Vanuit privacy oogpunt kun je dat als voordeel zien, maar slechts een vrij klein voordeel want HTTPS lekt nog genoeg informatie dat het voor een slimme beheerder toch wel duidelijk is wat je doet, alleen het automatiseren wordt lastiger.

Het klopt dat ftp een login nodig heeft. Daarom hebben ze op 'dag 2' van het ftp protocol (ruim voor http) al 'anonymous ftp' ingevoerd: De gemiddelde ftp-server is open voor het 'account' "anonymous" met als wachtwoord een email-adres (alles waar een @ in zit). De diverse ftp-servers hebben daar strengere en minder strenge implementaties van, tot controleren van het werken van het email adres aan toe: toenmalige 2-factor-authenticatie bij anonymous ftp-en.

Daar zal het wel naar toe gaan. Diverse browsers (iig Chrome) geven al heel duidelijk aan dat het onveilig is als je een site via HTTP bezoekt. Volgende stap is verbieden met de mogelijkheid tot een uitzondering maken (net als je nu een HTTPS site bezoekt met ongeldig certificaat). Volgende stap zal het uitschakelen zijn.

En dan zullen hotels en andere gast netwerken wereldwijd een ander systeem moeten vinden om je om te leiden naar een pagina met voorwaarden alvorens je het internet mag gebruiken.

FTP zal voorlopig nog wel blijven bestaan, maar voor cruciale toepassingen is SFTP de beste oplossing.
Er zijn zelfs enkele hostings die enkel SFTP enkel toestaan en FTP in de ban hebben gedaan. Waaronder XS4ALL voor de homepages van hun gebruikers.

Je moet er gewoon op bedacht zijn dat op onveilige of ongecontroleerde netwerken je FTP-verkeer afgeluisterd kan worden.

[Reactie gewijzigd door AW_Bos op 21 maart 2020 12:46]

Behalve dan dat bij het echte oude FTP er nogal eens vaak onversleutelde credentials over de lijn gaan, waarbij je bij de meeste HTTP toepassingen, er geen credentials benodigd zijn (uitzonderingen daargelaten).

FTP is gewoon een kutprotocol omdat data en command streams over verschillende poorten lopen waarbij de datastream dynamisch toegewezen wordt, hetzij met een server die verbindt met de client (active), hetzij een random poort op de server zelf (passive). Voor firewalls is FTP gewoon een ramp.

Kan je dat uitleggen waarom dat een ramp is?
Bij een 'antieke' firewall zet je 20 en 21 open en je bent klaar....
Bij een next-gen firewall kies je eenvoudig voor FTP als applicatie.. hoezo is dit een ramp?

Bij een antieke firewall zet je 21 open en 1024-65536 voor de passieve poorten (en daar zitten vervolgens een paar RPC poorten van windows tussen en je server wordt gehackt). Bij de iets minder antieke firewall laad je een FTP module in en ben je klaar voor FTP servers op poort 21. Bij moderne firewalls moet je FTP verkeer pecifiek omleiden naar die module, want helper modules worden niet meer automatisch geactiveerd vanwege veiligheid.

Beste oplossing vind ik dan nog pf op BSD: weg met dat gekloot met helper modules in kernelspace, proxy ertussen die dynamisch de benodigde poorten opent in de firewall.

[Reactie gewijzigd door _JGC_ op 22 maart 2020 12:41]

Voordat iedereen zich hard tegen ftp afzet: ftp is 'veiliger' dan http. Bij ftp heb je namelijke toegangscontrole. Het is aan de ftp-server hoe dat ondersteund wordt. http is naar mijn inzicht een afgezwakte versie van anonymous ftp. Maar dat is geschiedenis.

Het grote voordeel van ftp is dat het veel meer is dan alleen maar bestanden overhalen. In de standaard kan je net zo makkelijk uploaden en zelfs van server naar server overzetten. Dat uploaden is ook de grote reden dat de huidige browsers nog steeds ftp ondersteunen.

Naar mijn bescheiden mening zou ik het liefst zien dat ik het ftp protocol in de browser gecontroleerd aan kan laten. Bijvoorbeeld alleen op de lokaal aangesloten netwerken. Daarmee kan het ook door vpn-tunnels (en ssl/ssh tunnels) naar andere sites, omdat de vpn tunnel in de regel ook een lokaal netwerk is. Het verkeer over het grote boze internet is dan wel versleuteld.

Voordat iedereen zich hard tegen ftp afzet: ftp is 'veiliger' dan http. Bij ftp heb je namelijke toegangscontrole. Het is aan de ftp-server hoe dat ondersteund wordt. http is naar mijn inzicht een afgezwakte versie van anonymous ftp. Maar dat is geschiedenis.

Ben benieuwd waar je dit op baseerd? Een FTP kun je ook gewoon zonder toegangscontrole hebben (althans, voor de eindgebruiker) en bij HTTP kun je ook gewoon een basic AUTH toevoegen (en dus toegangscontrole hebben), dus ik begrijp jouw punt even niet.

[Reactie gewijzigd door CH4OS op 21 maart 2020 15:00]

Zowel ftp als http gaan zonder versleuteling of wat dan ook over de lijn. Het zijn beide transport protocollen. In die tijd ging men er van uit dat de versleuteling op een ander niveau (andere osi laag of encapsulation) zou gebeuren.
Het grote verschil is dat ftp een 'out of band' protocol is: 1 pad (lees: poort) voor de commando's en 1 pad voor de gegevens. Waar http de commando's en de gegevens over het zelfde pad stuurt.
De extra veiligheid van ftp boven http is dat er bij ftp een inlog-procedure is: Bij het opzetten van de verbinding moet een account en wachtwoord worden gegeven. In deze is 'anonymus' ook een account met volgens de nettiquette jou email adres het wachtwoord. Zonder account naam lukt niet. Een lege account naam wordt vaak gekoppeld aan anonymus.
We zien dat in de loop der tijd beide protocollen naar elkaar toe gegroeid zijn. Maar dat zijn aan beide kanten alleen maar lapmiddelen.

In de jaren '80 van de vorige eeuw was er nog het idee dat we het iso-osi model zouden volgen. De protocollen zouden doen wat ze moeten doen op hun eigen iso-osi laag. Routering en versleuteling op een andere laag dan het transport protocol. Dat zie je nu gebeuren door een tunnel (vpn, tor) op te bouwen en dan daarbinnen de gegevens te versturen. De ontwikkelingen gaan nu een beetje anders maar toch zie je de lagen steeds weer terug komen. Als je ze maar herkent.

Is Basic authenticatie een grap voor je? Nee maar serieus, ik heb geen idee hoe je een +2 krijgt want HTTP lijkt in de verste verte op FTP en ook HTTP heeft authenticatie.

Waarom je tegenwoordig nog FTP zou gebruiken (m.u.v. legacy redenen) is mij een raadsel, zelfs over een VPN. Gewoon SFTP gebruiken.

Mijn grootste reden om ftp te gebruiken naast de legacy redenen is dat ik met ftp veel meer kan dan alleen maar bestanden overhalen. Met ftp heb je ook een zekere controle over de machine/service/filesysteem aan de andere kant. Dat wil zeggen: Binnen het protocol. Dus eenvoudig te scripten en dergelijke.

Dat uploaden is ook de grote reden dat de huidige browsers nog steeds ftp ondersteunen.

Klopt ik heb wel eens voor mensen met een simpel kapperswebsiteje gewoon een snelkoppeling op het bureaublad gezet naar hun hosting FTP in Internet Explorer, konden ze met kladblok even de prijzen aanpassen en weer opslaan.

FTP wel uitzetten en het onveilige TLS 1.0 /1.1 wel weer opnieuw aanzetten?
Hoezo krom wacht daar dan ook mee tot na de crisis.

Bron> nieuws: Mozilla schakelt ondersteuning voor verouderde tls 1.0 en 1.1 weer in...

[Reactie gewijzigd door mr_evil08 op 21 maart 2020 12:56]

FTP wel uitzetten en het onveilige TLS 1.0 /1.1 wel weer opnieuw aanzetten?
Hoezo krom wacht daar dan ook mee tot na de crisis.

Bron> nieuws: Mozilla schakelt ondersteuning voor verouderde tls 1.0 en 1.1 weer in...

Het voelt inderdaad een beetje tegenstrijdig, al gaat het herinschakelen van TLS 1.0 over FF74 en het uitschakelen van FTP komt pas in FF77. Niettemin ben ik met je eens dat het tegenstrijdig is. Deze veranderingen zullen wel in verschillende trajecten zitten. Ik verwacht dat ze het nog wel gaan veranderen en het uitschakelen van FTP nog wat uitstellen tot na de crisis.

Niets krom aan.

Jij vergelijkt onveilig met onveilig. Als de ene weer aangaat, dan mag de andere ook niet uit.

Zij willen niet dat overheidssites onbereikbaar worden tijdens de crisis, daarom zetten ze TLS 1.0/1.1 weer aan.

FTP wordt nauwelijks gebruik, is bewezen onveilig en er verdwijnt niet opeens informatie als je het uitzet.

Iets volstrekt anders dus.

Bovendien wordt het in juni pas standaard uitgezet. Het is dus helemaal niet uit Firefox, het staat gewoon standaard uit. Wat verstandig is omdat 99% van de mensen het dus toch al niet gebruikt.

[Reactie gewijzigd door White Feather op 21 maart 2020 13:29]

FTP wel uitzetten en het onveilige TLS 1.0 /1.1 wel weer opnieuw aanzetten?
Hoezo krom wacht daar dan ook mee tot na de crisis.

Bron> nieuws: Mozilla schakelt ondersteuning voor verouderde tls 1.0 en 1.1 weer in...

"Begin 2021 moet ftp-ondersteuning er volledig uit zijn.

Laat ons hopen we tegen dan er vanaf zijn? De crisis weliswaar ...

Nou vaak is nog wel oud spul op ftp sites te vinden. Vaak deed ik dus een search over alle geindexeeerde ftp servers en kon zo het oude bestand dan nog vandaan plukken.
Tja als dat nu afgebouwd gaat worden.

Die servers zullen gewoon blijven bestaan. Alleen kan je ze dadelijk met Firefox niet meer benaderen. En dat is maar goed ook.

En waarom is dat goed?

Omdat niet encrypted internet verkeer stilletjes aan maar eens afgebouwd moest worden.

Waarom heb ik encryptie nodig als ik een driver of willekeurig iets anders nodig heb. 99% van de gevallen is encryptie niet nodig.

Maar waarom dan via FTP doen,, ipv gewoon over http(s)

Omdat die zooi vaak alleen nog op de oude ftp sites staan?

Lichter protocol.
Past kn hetzelfde rijtje als, optimaliseren onze code niet meer geef maar gewoon extra ram

Want? Encryptie is lang niet altijd vereist.

Hoe zit het eigenlijk met direct FTP downloads zoals voor drivers, ISO's (Linux distributies, Windows, ..) en ander spul?

Ik dacht altijd dat voor deze zaken vaak FTP wordt gebruikt omdat je daarmee niet de webserver hoeft te belasten, voor resume support en deze vaak sneller waren/zijn dan HTTP(S)? Voor publieke zaken lijkt me dan nog altijd FTP wel handig, al mist je wel versleuteling en certificaat support zonder SFTP.

Overigens raakt het mij niet (meer). Grote bestanden download ik bijvoorbeeld via torrents, een cloud oplossing of via een download manager.

[Reactie gewijzigd door foxgamer2019 op 21 maart 2020 12:56]

Je wilt waarschijnlijk een aparte downloadserver, helemaal los van je gewone website, maar het protocol lijkt me daarbij eerder van ondergeschikt belang. (En het zou me niets verbazen als HTTP het juist net iets beter doet, maar dat terzijde.)

Hmm, dan mag oa HP ook aan de slag. volgens mij hebben die al hun drivers etc op een FTP staan.

Klopt en leveranciers ook. Gelukkig weet ik wel hoe filezilla, winscp werkt maar Henk en Ingrid die hebben geen idee waarom de links straks niet meer werken

Googles motivatie om ftp uit te faseren stelde het dat slechts 0,1 procent van gebruikers nog ftp gebruikte.

Dat lijkt mij eigenlijk best veel, 1 / 1000.

Dacht ik ook, maar dan anders.
Hoeveel miljoen gebruikers heeft FF?
stel 4 miljoen = 4000x die dit blijkbaar obscure protocol gebruiken ?

Denk dat het minder dan 0,1% zal zijn.

Ik snap het wel, maar vind het wat overdreven. FTP wordt idd. weinig gebruikt, maar dus ook weinig misbruikt.

Voor het delen van grotere bestanden is, met name voor het uploaden een FTP-server wel makkelijk. En voor het downloaden kunnen mensen dan de browser gebruiken. Hoef je niet los een http-server in te richten (en te beveiligen).

Aan de andere kant, zo moeilijk is het downloaden en gebruiken van een losse ftp-cliënt ook weer niet.

(voor alle duidelijkheid: waar ik ftp zeg, bedoel ik 100% sftp. niet-beveiligde ftp-verbindingen heb ik al tijden niet meer gezien)

[Reactie gewijzigd door Keypunchie op 21 maart 2020 13:53]

Wat was in de tijd voor Web 2.0 (tijd van de Super International Information Super Highway, Infobahn, BBS, weetikveel hoe het toen heette) de reden om FTP boven HTTP te prefereren? Ook toen al had je met TCP/80 gemak en met TCP/21 ongemakken, toch?

[Reactie gewijzigd door Trommelrem op 21 maart 2020 22:27]