A Chromium fokozatosan kivezeti az FTP támogatást

HUP cikkturkáló

A Chrome 72 Beta-tól kezdve fokozatosan kivezeti az FTP támogatást. Jelen állapot szerint a struktúrát még megjeleníti, de az FTP-n található fájlokat már nem fogja betölteni megjelenítésre, hanem egyből letöltésre ajánlja fel őket.

A következő verzióktól kezdve pedig még jobban kivonja a támogatást, arra hivatkozva, hogy nem eléggé biztonságos a protokoll.

https://blog.chromium.org/2018/12/chrome-72-beta-public-class-fields-us…

  • 2348 megtekintés

( MGy v | 2018. 12. 19., sze – 11:08 )

Ezt most tényleg nem értem. Mennyivel kevésbé biztonságos az ftp mint az ssl nélküli http? Mennyivel vagyunk beljebb, ha a böngésző nem megjeleníti, hanem elmenti a tartalmat, a user úgyis rá fog kattintani a lemenett fájlra. Amúgy jó ötlet, hogy rögtön letölti és nem megjeleníti, hiszen az ftp file transfer protocoll, azaz úgyis fájlt akartam transzferelni :-).

Szerintem ebben benne van a valasz: https://www.kernel.org/shutting-down-ftp-services.html

- The protocol is inefficient and requires adding awkward kludges to firewalls and load balancing daemons
- FTP servers have no support for caching or accelerators, which has significant performance impacts
- Most software implementations have stagnated and see infrequent updates

Nem mintha bajom lenne az FTP-vel.

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

+1, kihalófélben van, és jó okkal.

Az Archive Team speciel három éve folyamatosan archiválgatja a publikus FTP site-okat, mert sorban zárnak be.

https://www.archiveteam.org/index.php?title=FTP

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

AZ OK, hogy az ftp-nek az az ötlete, hogy legyen külön adat és parancs tcp kapcsolat nem Nobel díjas ötlet és emiatt ki kell halnia ezzel semmi gond. A szerver oldalon szüntesse meg akinek útjában van, de miért a kliens korlátozza a supportot. Ennek csak egy racionális okát látom, hogy nem akarják a kliens oldali kódban az ismert biztonsági hibákat kijavítani inkább azt mondják, hogy a protokoll nem biztonságos, holott csak éppen kihalóban van.

Nem azért nem biztonságos, mert tele van ismert hibákkal az implementáció, hanem maga a koncepció nem biztonságos. Ha megváltoztatnák a koncepciót, akkor az már nem ftp lenne.

Ftp-t pedig még mindig rengeteg helyen lehet találni. Nem az a lényeg, hogy hol nem használják, hanem az, hogy ahol használják, ott a felhasználók által kényszerítsék a lecserélését.
Mert hiába van bármilyen újabb technológia, mindig a lustaság és a spórolás az első, hogy amíg működik, addig nem cserélik le a kiszolgálókon (a bajai ellenére).
De ha az ügyfelek elkezdenek panaszkodi, vagy várható, hogy az ügyfelek hamarosan elkezdenek panaszkodni, akkor nagy duzzogva csak nekifognak alternatíva keresésének.

Bizonyos szempontból ez a piaci részesedéssel való visszaélés. De vannak dolgok, amiben nem működik a demokrácia, hogy a leglustábbnak is ugyanannyit ér a szava. És mielőtt valaki kitalálja, hogy dehát ez plusz költséget okoz a kiszolgáló oldalon, hát az már régen el kellett volna költeni, csak tojtak a biztonságra.

Hol kevésbé biztonságos az ftp protokoll mint a http - mindkettőnek a titkosítás nélküli változatát nézzük.
Mindkettőnél titkosítatlan jelszavak utaznak tcp kapcsolatban. Az persze tény, hogy az ftp parancs és adatcsatorna szétválasztása ma már - nagy sávszélesség, nagy késleltetés kis csomagvesztés - nem hatékony, de nem is erre a hálózatra lett tervezve hanem egy kis sávszélességű nagy csomagvesztéses Internetre. Ha a megfelelő IP flageket bebillented és a routerek figyelembe veszik a két csatorna akár másfele is routolódhat pl. a parancs csatorna földi kis sávszélességű kis válaszidejű, de drága vonalon, míg az adatcsatorna műholdas erősen aszimmetrikus nagy késleltetésű hálózat felé.
Ma nyilván ezek nem relevánsak, tehát maradnak a hátrányai, azaz kihal, de ezt ne fogjuk a biztonságra.

A http visszaszorítása is céljuk
https://www.hwsw.hu/hirek/59129/http-google-biztonsag-chrome-bongeszo-s…

a többi meg csak összeesküvés elmélet. Egy hót primitív protokol imlementációja mögé ne képzeljünk már öszeesküvést, hogy nem akarják a biztonsági hibáit kezelni. Nem tudom mire gondolsz a csomagvesztéses internettel, azon felül, hogy a tcp réteg megpróbálja újrakérni a vesztett csomagokat a protokol nem valószínű, hogy támogat bármilyen extra csomagvesztés elleni védelmet.

Műholdas internetet sem sok ember látott akkoriban, amikor bármit számított volna ez, amit írsz. Bár akkor sem, hiszen a parancs csatornán csak pár bájtos utasítások mennek. Bár igaz, nem neteztem a dzsungelből műholdas betárcsázós internettel a 70es években, szóval nem tudhatom :D

A kihalással meg az a baj, hogy még nagy cégeknél sem feltétlen hal ki, amíg nincsenek rákényszerítve, mert sóher és lusta a management. Ez többet számít, mint a biztonság.

Arra akartam volna rámutatni, hogy a protokollnak nincsenek nagyobb beépített biztonsági hibái, mint a http-nek. Ha az a baj, hogy nem titkosított az ftp, a https-hez hasonlóan van tls-sel turbózott ftps is. Figyelmedbe ajánlom az IP differentiated services szolgáltatását (https://en.wikipedia.org/wiki/Differentiated_services) ami alapján a jobb routing protokollok (legegyszerűbb pl. az OSPF) különböző feszítőfákat tudnak az egyes típusú szolgáltatásokhoz készíteni, azaz a különböző típusú csomagok más úton közlekedhetnek. Okos dolog például a voip forgalmat és a bulk file letöltést nem ugyanarra küldeni, mert a file transfer esetén optimális nagy csomagméret egy sávszélességben szűk keresztmetszet esetében megöli a voip forgalom nagyon gyakori kicsi csomagjainak a késleltését (mielőtt valaki írná tudom, hogy a differentiated services sokat segít ezen,feltéve hogy olyan router van a szűk keresztmetszet két oldalán, ami figyelembe veszi). Tehát a hálózat teljes áteresztőképessége szempontjából az ftp egy jó protokoll. Az más kérdés, hogy ma egyre kevésbé fontos szempont ez, helyette fontossá vált a cache és reverse proxy használata aminek a szempontjából viszont az ftp nem jó. Az IPv4 elfogyása miatt orrba szájba NAT szempontjából az ftp szintén nagyon barátságtalan.
Ha le akarjuk építeni ám tegyük, de ne olyan indokkal, hogy nem biztonságos. A biztonsági hivatkozást egyes implementációk esetén tudom elfogadni. Ilyenkor lehet az is racionális gazdasági döntés, hogy nem javítjuk, hanem kidobjuk az egészet. Ezt is lehet, de akkor mondják ezt - bőven elegem van a politikusok esetében a hazudozásból - szerintem az IT szakma van annyira felnőtt, hogy kibírjuk az igazságot is.
Mellékszál: Lehet persze, hogy azért bosszant jobban a mellébeszélés, mert ehhez értek és emiatt átlátom a helyzetet és nem szeretem, ha hülyére vesznek. Belegondolni is rossz, hogy hányszor vesznek hülyére olyan dolgokban, amihez kevésbé értek.

( ncc1701 | 2018. 12. 19., sze – 16:34 )

Cégnél mai napig futtatunk ftp szervert, de ahogy nézem, még jó sokáig fogunk is. Total commander felcsap, és már lehet is használni.

<reklám on>
És még a MultiCommander is kezeli :))

A rövidneve pedig hasonlít a Midnight Commander-ére :))

Kiváltottam vele a nem teljesen legális 1-2-3 freeware Totalt kompromisszum nélkül.
Szerintem érdemtelenül nem ismert, bár az első beállítással
el lehet molyolni egy fél napot, mire kézreáll, utána viszont
kimásolva portableként még frissíthető is...
<reklám off>

Bocs az off-ért...

Mukk

Majd ha a tc-ben lesz by default sftp plugin, akkor. Most ctrl+f, és kész. És ez nem az én döntésem, hanem a kollegáké, akik használják.
Amúgy ja, elég komoly user adatok vannak nálunk, azt a 4 betűset meg magasról lesz@rjuk. Én még betarthatnám, de a kollegák úgyse fogják. User adat pedig csak átmenetileg van, ha valamit az adatbázisám tesztelni kell az irodába, utána kuka, ezt viszont betartjuk.

( sigellef | 2018. 12. 20., cs – 13:52 )

Minden jót tönkre kell tenni, miért lenne ez alól kivétel pont az ftp?
Azzal nincs baj, hogy egy hülye elkezd valami ökörséget, a baj majd akkor lesz, ha a többi is követi példáját.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Így van. A böngészők amúgy sem nagyon alkalmasak FTP kliensnek. Az FTP élni fog tovább, de tényleg elvárható, hogy public szolgáltatások ne használják. Én pl. LAN-on előszeretettel használok FTP-t, ha különböző OS-ek között nem akarok SMB megosztással és NFS-sel szívni, és csak egyszerű fájlelérés a cél, nem kell feltölteni meg ilyesmi. Az FTP egyszerű, fellövöm (pl. bftpd), a fogadó oldalon bármilyen OS alá szokott lenni kliens és elérem a fájlokat. Erre jó, de a nyilvános neten nem jó ötlet már 2018-ban FTP-vel szórakozni. Szép és jó volt az FTP, amíg nem volt torrent, meg ennyi https-ses, felhős, one click share oldal fájlmegosztásra.

No keyboard detected... Press F1 to run the SETUP

Pedig hasznos funkció volt, mert ha publikus ftp-re vitt egy link, akkor rögtön tudtam szemezgetni benne, hogy kell-e az ami benne van, vagy nem, szúrópróba szerűen letölthettem egy pár cuccot megnézésre.
A chrome böngészö engem amúgy sem érint, mert nem használom, csak tartok tőle, hogy előbb-utóbb a firefoxból is ki fogják hagyni.
Régen, amikor megjelent valamiből egy újabb verzió, biztosak lehettünk benne, hogy többet tudott mint az előző... kár, hogy a szoftverek fejlesztése abba az irányba tart, hogy az új verzióknál már attól kell félni, hogy vajon mit szüntetnek meg, vagy mit csesznek szét benne.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba