Vlákno názorů k článku Chrome a Firefox tlumí podporu FTP a plánují ji úplně ukončit od Pavel Ruzicka - U FTP protokolu vidim nekolik vyhod: 1. Diky nepouziti...
-
U FTP protokolu vidim nekolik vyhod:
1. Diky nepouziti sifrovani je velmi vykonny i na slabem hardware. Napr. u starsich NAS, nebo nejakych "embedded" desek je propastny rozdil ve vykonu oproti sifrovanemu prenosu (napr. FTPS).
2. Ze stejnych duvodu ho lze pouzivat pro mereni realne prenosove rychlosti obema smery.
3. FTP protokol podporuje prenos primo mezi servery ovladany ze vzdaleneho klienta. Muzu tedy rychle presouvat data mezi servery z klienta na pomale lince. Musi to byt ovsem podporovano klientem. Tohle v prohlizeci urcite nebude.Osobne tedy nechapu likvidaci FTP protokolu na strane web prohlizece. Omezeni pouze na stahovani po kliknuti mi prijde OK. Naopak bych ocekaval podporu FTPS v prohlizeci, ale ja stejne na FTP prenosy pouzivam spis FTP klient typu Filezilla, nebo GFTP.
Take na strane serveru je casto z hlediska bezpecnosti vyhodnejsi pouzivat oddelene protokoly, pripadne uzivatele od tech systemovych. SFTP mne nikdy neoslovilo. Take nevim, jak si poradi se slozitejsimi vecmi typu zmena prav, nebo casu souboru.
FTP neni zdaleka idealni protokol hlavne z duvodu active/passive rezimu, dvou TCP spojeni a jejich slozitejsi implementaci do firewallu a NATu.
Jeho uplnou likvidaci z prohlizece povazuji za chybu.
-
Petr M (neregistrovaný)
"1. Diky nepouziti sifrovani je velmi vykonny i na slabem hardware. Napr. u starsich NAS, nebo nejakych "embedded" desek je propastny rozdil ve vykonu oproti sifrovanemu prenosu (napr. FTPS)."
Bavíme se o webovým browseru, tj. pokud tam máš HTTP server, tak ti to může nešifrovaně naservírovat on. Jestli FTP použiješ na něco jinýho s jinou aplikací, to snad na rozhodnutí Google nezávisí."2. Ze stejnych duvodu ho lze pouzivat pro mereni realne prenosove rychlosti obema smery."
Na to jde použít cokoliv, kde můžeš poslat velký balík dat na rychlosti, kterou pracuje síťovka."3. FTP protokol podporuje prenos primo mezi servery ovladany ze vzdaleneho klienta. Muzu tedy rychle presouvat data mezi servery z klienta na pomale lince. Musi to byt ovsem podporovano klientem. Tohle v prohlizeci urcite nebude."
Víš, že přesně tohle jsem před měsícem dělal po SSH? Rozvrtal jsem si nějak jeden kompl tak, že na něm nešlo v lokále nic dělat (zlikvidovaný ovladače klávesnice a byly tam nějaký data a nšifrovaným disku, který jsem ještě neměl zálohovaný), ale fungovalo SSH, takže jsem se noťasu (kde už nebylo místo na data) dostal na ten polomrtvej krám, namontoval si po SSHFS disk z jinýho komplu, kde bylo dost místa a zkopíroval data. FTP k tomu kupodivu vůbec potřeba nebylo. A nedělal jsem to komplikovaně z prohlížeče, ale jednoduše z BASHe.
No a pokud jde o "pomalou linku" - pokud zvládnu šifrovat 230Mbps a linka má 20Mbps, jak to zrychlí absence šifrování? Ono po těch 20Mbps proteče bez šifrování 50Mbps?
"Osobne tedy nechapu likvidaci FTP protokolu na strane web prohlizece."
Já zase jo.Neexistuje use case, mimo downloadu souborů ( kde je alternativa HTTP(S) s MIME ), k čemu by to v prohlížeči bylo dobrý.
" ja stejne na FTP prenosy pouzivam spis FTP klient typu Filezilla, nebo GFTP."
Víš, že já ani nevím, co na FTP použít? Naposledy jsem s tím něco dělal ještě v době, kdy jsem jel na podporovaných OEM Windows XP pro.
"SFTP mne nikdy neoslovilo. Take nevim, jak si poradi se slozitejsimi vecmi typu zmena prav, nebo casu souboru."
Montuju si to přes FUSE a chová se to, mimo rychlosti, jako normální filesystém včetně práv.
-
Lol Phirae (neregistrovaný)
Bavíme se o webovým browseru, tj. pokud tam máš HTTP server, tak ti to může nešifrovaně naservírovat on.
No jistě... než to HTTP v prohlížečích zrušíme, že...
Víš, že přesně tohle jsem před měsícem dělal po SSH? ... A nedělal jsem to komplikovaně z prohlížeče, ale jednoduše z BASHe.
Aaaano, to má - stejně jako "náhrada" SFTP - tu "drobnou" nevýhodu, že na obou strojích potřebuješ shell.
Neexistuje use case, mimo downloadu souborů ( kde je alternativa HTTP(S) s MIME ), k čemu by to v prohlížeči bylo dobrý
To je ale vopravdu divný, že use case File Transfer Protocol je - přenos souborů. Sakra, to je překvapení. A jinak samozřejmě prohlížeč ke stahování souborů nikdo zásadně, vůbec, vůbec nikdy nepoužívá. :-P Jo mimochodem, ty soubory se dají přes FTP i uploadovat. A je to - narozdíl od vymožeností typu WebDAV - dokonce i funkční. Mohou dosvědčit miliony uživatelů webhostingu. Vono tam totiž, i přes blábolení zdejších dobroserů, ty soubory v 99% případů jinak než přes FTP nedostaneš.
-
Petr M (neregistrovaný)
"No jistě... než to HTTP v prohlížečích zrušíme, že..."
Jo, proč ne. Proč nepoužít třeba NTP... Aha, to by nešlo z prohlížeče. Prohlížeč totiž musí dělat všechno, od prohlížení webu přes editaci obrázků až po syntézu FPGA. A když to neumí, je to špatně.
"Aaaano, to má - stejně jako "náhrada" SFTP - tu "drobnou" nevýhodu, že na obou strojích potřebuješ shell."
Kdežto u FTP nepotřebuješ vůbec nic, ani FTP server, ani FTP klienta... Když říkáš A, řekni i B.
Linuxový stroj bez shellu jsem ještě neviděl. FTP už není nativně ani v některých distrech."Vono tam totiž, i přes blábolení zdejších dobroserů, ty soubory v 99% případů jinak než přes FTP nedostaneš."
Jasně. ty máš na lokálním filesystému image webu a chceš ho dostat na server. A nemůžeš, chudáčku, protože autor prohlížeče je na tebe zlej a nedovoluje stahování z toho serveru po FTP. No ti jsou ale zlí.
A co kdybys měl koule na to, abys se přihlásil o jiný řešení u hostingové firmy? ty to platíš, ty poroučíš. Nebo přijdeš do hospody, čumíš jak puk a čekáš, co ti pingl ze své iniciativy nadělí? Nebo jdeš na hyeprlevnýho "hastrmana" (řezáno 80% tekutiny z přilehlýho rybníka)?
Možností je plno. SSH, sdílení filesystému, git deploy, skript v cronu s WGET/RSYNC z test serveru,... Jenom se zamyslet a nastudovat si to trochu. Že ti FTP chodí 47 let je hezký, ale neznamená to, že ti bude chodit do smrti a nemusíš se učit nic novýho...
-
Lol Phirae (neregistrovaný)
Možností je plno. SSH, sdílení filesystému, git deploy, skript v cronu s WGET/RSYNC z test serveru,...
Jojo, určitě je výhodné se drbat levou nohou za pravým uchem, proč to tam jednoduše nasypat protokolem k tomu určeným, že... to dělají jen blbci. Inteligenti sdílejí filesystémy a dělají deploy přes cron.
Další bláboly už ani nekomentuju, škoda času.
-
Petr M (neregistrovaný)
Normální deploy = otestuju na testovacím mirroru, uploaduju.
Z pohledu souborů je jedno, jestli si ten produkční stroj namontuju po NFS, SSHFS, SMB,..., naklopím to tam RSYNCem, FTP, SFTP, FTPS, WebDAV, nebo pomocí hooku na merge do protukčního banche v GITu uděláš automaticky upload na produkční stroj,... Tam jde o to dostat tam fyzicky soubory. Z toho pohledu jde o styl práce.
Z pohledu bezpečnosti (a legislativy) tam ty soubory potřebuješ dostat tak, aby je nikdo nezměnil ani cestou, ani pozděj bez schválenýho přístupu.
Co se týká změn cestou, šifrování je nutnost. Takže šifrovaný přenos, nebo nešifrovaný ve VPN. Tzn. bez VPN je FTP mimo hru z tohohle pohledu.
Co se týká změny potom, server musí dovolit nahrávání jenom tomu, kdo se mu autorizuje. U prostýho FTP je to kdokoliv, kdo má přístup ke komunikačnímu kanálu a jednou viděl začátek komunikace. U FTPS záleží na implementaci, mám pocit, že je i taková, která napřed naváže klasický FTP spojení a pak domlouvá šifrování jenom pro data. To je taky blbě.
U SSH/SSHFS/SFTP mám šifrování (= žádná změna během přenosu) + dvoufaktor (mám klíč, vím k němu PIN) a RSAčko je dost odolný, aby ho 99,999% nelousklo během desetiminutové komunikace se serverem. Takže znovu - jakou výhodu má FTP(*)?
(*) OpenSSH je pomalý, ale kolikrát denně děláš deploy webu a kolik TB tam ty JavaScripty/CSS mají?
WGET v CRONu je trochu extrém, ale je to ukázka, že obejít se dá cokoliv a udělat to jakkoliv, i absence rozumnýho protokolu ze strany poskytovatele webu nemusí být problém. Lepší je ale nevybírat si hosting levnější než nejlevnější garážovku, ale podle parametrů. Jeden z parametrů jsou možnosti správy a deploye.
-
Lol Phirae (neregistrovaný)
U FTPS záleží na implementaci, mám pocit, že je i taková, která napřed naváže klasický FTP spojení a pak domlouvá šifrování jenom pro data.
Tak si prosím tě místo pocitů něco nastuduj a přestaň mlít úplné nesmysly. https://en.wikipedia.org/wiki/FTPS
-
Petr M (neregistrovaný)
Neuč orla lítat. https://tools.ietf.org/html/rfc2228
Kapitola 2, odstavec 3: " With the FTP security extensions, authentication established using a security mechanism <b>may also be used</b> to make the authorization decision." = Je možné ji použít, ne je povinné ji použít.
kapitola 2, odst. 4: "Without the security extensions, authentication of the client, as this term is usually understood, never happens." - to jsem pochopil tak, že bez bezpečnostního rozšíření je tam fallback na FTP bez autentizace klienta - jenom tak mimochodem hned na několika místech se tvrdí, že fallback je možný, ale dá se zakázat. Tento fakt obecně bych u explicitní verze viděl jako dost velký riziko.
kapitola 3 začíná větou "The following commands are optional, but dependent on each other. They are extensions to the FTP Access Control Commands." Takže pokud tam není závislost na dalším příkazu, implementvat je nemusíš. A do toho padá "AUTHENTICATION/SECURITY MECHANISM (AUTH)"
Tímto příkazem se domlouvá na začátku, jaký šifrování se použije. V plain textu. Ještě si tak vygooglit, co znamená "downgrade attack"..."AUTHENTICATION/SECURITY DATA (ADAT)" je další příkaz.
"The argument field is a Telnet string representing base 64 encoded security data (see Section 9, "Base 64 Encoding"). If a reply code indicating success is returned, the server may also use a string of the form "ADAT=base64data" as the text part of the reply if it wishes to convey security data back to the client."
Dál se dočteme, že security data mají obsah podle toho, co je v AUTH. Takže výměna klíčů atd. probíhá skrz tohle. Takže standard sám nedefinuje zabezpečení, jenom říká, jak se na něm domlouvat. Takže na tohle pozor, pokud dá nějaký moula X-typ zabezpečení a vlastní BASE-64 strukturu bez nonce a hashe, tak je tam reuse loginu jak vyšitý.
A o kousek dál další perla: "DATA CHANNEL PROTECTION LEVEL (PROT)"
"The argument is a single Telnet character code specifying the data channel protection level... The default protection level if no other level is specified is Clear. The Clear protection level indicates that the data channel will carry the raw data of the file transfer, with no security applied." Takže by default nešifrujeme a neověřujeme data. No to se nedivím, že ho propaguješ, jak je super a rychlý.Sice o chlup z žaby lepší jak čistý FTP, ale už jsem viděl i bezpečnější věci, než bezpečnostní nástavbu, kde je autentizace dobrovolná, protokol se domlouvá v plain textu a by default nešifruje a neověřuje data. A k tomu přidej chyby v implementaci...
-
Lol Phirae (neregistrovaný)
Takových žvástů a stejně jsi to nepochopil... Prosímtě, nainstaluj si třeba proftpd, nainstaluj si nějakého použitelného FTP klienta, a vyzkoušej si to. Samozřejmě, pokud by věci implementoval debil jako ty, skončí to přesně tak, jak popisuješ. Mezitím si můžeš zahekat třeba nad tím, že u emailů je při použití STARTTLS je šifrování dobrovolné a domlouvá se v plaintextu a že je to hrozně nebezpečné.
