Netvrdím, že je FTP super protokol, ale v posledních letech jsem ho rozhodně občas potřeboval a možnost využít web browser často přišla vhod. Jako v nouzi zvládnu použít ftp dokonce i z příkazového řádku, ale je to pruda navíc.
Netuším, jaký bezpečnostní problém může FTP oproti HTTP působit, ale na internetu lze pořád na odkazy ftp:// narazit budu-li je muset nakonec kopírovat do jiné aplikace, těžko to něčemu prospěje.
Moje zkusenost s FTP je takova, ze jej zpravidla zablokuje firemni firewall. A pokud clovek nejaky soubor s FTP serveru fakt potrebuje, stejne musi spustit CLI klienta a zkusit nejake finty, pripadne soubor stahnou z domova. Nastesti to dnes jiz neni treba, protoze vetsina FTP serveru nabizi soubory i pres HTTP...
Co cakat od programatorov? Programatori su obecne velmi hlupa sorta ludi odtrhnutych od reality. Programatori vzdycky z ponukanych moznosti vyberu tu najvacsiu blbost. Napriklad nam vnutia nejaky podivny OS vsetko nam zahesluju, nanuutia prazvlastne bezpecnostne politiky a ked treba nieco spravit tak na to treba zavolat 5x admina. Vraj to je koli bezpecnosti (predtym vsetko fungovalo aj bez potreby bezpecnosti). Vysledok je taky ze rezia okolo bezpecnosti zaberie 10x viac casu ako samotna praca.
Rozdíl tam je.
Pokud chci autenticitu serveru, tak jsem závislý na DNSku (podvržení IP adresy) a ověření jeho certifikátu. Proto se zavádí DANE, DNSSEC a podobný opičárny.
Pokud chci mít jistotu, že přenesený soubor je autentický (= pochází z toho serveru, který chci navštívit), musím mít jistotu, že někdo neunesl spojení. A to už věcí protokolu je (výměna klíčů, podpis přenosu,...).
Pokud jde o FTP, je tak křišťálově průhledný, že si ISPík může upravit router a když se po něm bude něco stahovat z reklamního serveru (známá URL), naservírovat reklamy z fake serveru konkurence. Provozovatel webu ostrouhá, ISPík si přivydělá a čtenář nic nepozná. A to se vyplatí.
Ano .. na to aby som si stiahol subor, ktory lahko overim beznymi prostriedkami, ci je ten, ktora byt ma, si namiesto jednoducheho a rychleho ftp nastavim 10x tazsie a pomalsie nieco uplne zbytocne. A to sa naozaj vyplati :) .. hlavne pre ten pocit bezpecia, ktory je .. voala .. uplne marny :)
Pokial si neoverite autentickost a integritu suboru overenim jeho digitalneho podpisu od autora (nie servra) tak si mozete ten subor kludne stahovat aj cez FTP. Ten protokol ma minimalny overhead, lahko sa debuguje a jeho implementacia je tiez jednoducha. Stale ma rozumne vyuzitie a nielen na verejnej sieti. Chapem, ze su ludia, co by napchali aj DNS a ICMP do HTTP a nejake to *ML ale nie je kazdy trafeny. Oh, ze by jedno z toho uz aj napchali do HTTP?...
Mě se nad tím pozastavuje rozum. Když je FTP zastaralé, tak ať, ale co s tím má podpora v prohlížeči. Když je zastaralá nějaká norma na ukládání dat na CD, tak zruším podporu v cd přehrávači ? Vytlačit starý a nebezpečný protokol FTP se musí jiným způsobem, ne na straně prohlížečů. Zdá se mi, že se google staví do role web policajta, ale celkem nešťastným způsobem.
Ukládání dat != přenos dat
Ukládání dat třeba na CD nebo HDD je jejich přenos v čase, tj. za X let potřebuješ to, co máš dneska, aby sis data mohl vyzvednout. Odstranit můžeš maximálně zápis v tom formátu, čtení musí zůstat.
Přenos dat je přenos v prostoru z místa/stroje A do místa/stroje B jenom se zpožděním přenosovýho kanálu. Proběhne a konec. Pokud stahování začalo před 10 minutama a skonší za 20 minut, není nutno k tomu používat protokol x desítek let starý, pokud existuje lepší alternativa. A klidně vyhoví i hodinu starý protokol, od kterýho zítra smažeš zdojáky a dokumentaci.
No a vyhození FTP se nedivím. Pokud jde o download, není tam z pohledu browseru žádná výhoda:
- plaintext bez šifrování dovoluje MITM, chytání hesel, podvržení obsahu atd.
- soubory přenese i HTTP(S), takže FTP je duplicitní. Někdo se o ten kód musí starat, testovat ho,...
- adresáře dokáže s přehledem zobrazit i web server po HTTP(S), někdy i nechtěně.
- upload na server je lepší pomocí příkazu scp, už jenom proto, aby ten uploadovaný skript někdo cestou "neupgradoval" o nějaký dáreček pro zákazníky.
Takže ať FTP klidně umře.
Zas blabolis o vecech o kterych vis prdlajs? HTTP prenasi o 30% vic dat, protoze na prenosy souboru neni navrzeny. A pak je tu bambiliarda dalsich veci, ktery pres http bez webovy aplikace na strane serveru vubec delat nejdou, a na tu aplikaci je zaroven treba na strane klienta full browser vs primitivni ftp klient, kterej to umi bydefault.
ftp provozuje 100% vsech webhostingu, protoze neexistuje nic rozumnejsiho co by to mohlo nahradit.
"HTTP prenasi o 30% vic dat, protoze na prenosy souboru neni navrzeny."
No nekecej. Já žil v přesvědčení, že HTTP byl designován na přenos textovýho souboru (primárně html/xml) a prostě si nastavíš charset a jedeš. Pokud je to binárku, kopneš tam info o MIME a jedeš.
Režie navíc je v navázání spojení (stejně jako FTP) a pár parametrů v příkazu GET + vrácené hlavičce, je to docela podobný FTP. Kde bereš těch 30%? Při jaké záteži, při rozsekání jednoho CSSka na soubory po jednom pravidle?
"A pak je tu bambiliarda dalsich veci, ktery pres http bez webovy aplikace na strane serveru vubec delat nejdou, a na tu aplikaci je zaroven treba na strane klienta full browser vs primitivni ftp klient, kterej to umi bydefault."
Například?
"ftp provozuje 100% vsech webhostingu, protoze neexistuje nic rozumnejsiho co by to mohlo nahradit."
Existuje. Na Linuxu není problém naťukat jeden řádek na konzole
sshfs webadmin@mujserver:adresar /mnt/mujweb
a web je k dispozici v /mnt/mujweb. A lezeš na něho úplně stejně, jako na lokální disk. A když to nepotřebuješ, zadáš sudo unmount /mnt/mujweb
a odpojíš se. Kouzlo, co?
A co se FTP týká, když se přihlašuješ na ten slavjen hosting, každej vidí username + password v ftp komunikaci. Není problém půl hodiny počkat, použít ty samý přihlašovací údaje a přidat do nějakýho JavaScriptu sosnutí nějakýho překvápako ve stylu Etereum nebo Monero. Nebo něco ještě vychytanějšího. Jsem si jist, že to návštěvníky tvýho webu velmi potěší.
Ale dá, třeba na https://djangoeurope.com/ dostanete SSH přístup a ve svém $HOME si račte dělat co je libo.
Kua proč potřebuješ nastavovat systémový věci a zabezpečení z webu? To jako aby skript kiddie prostě někam injektoval chmod s RWX pro others a líp se mu úřadovalo? Nebo jakej je legitimní use case?
Pro webhostera platí, že dostaneš to, co si domluvíš a zaplatíš. Řekni mu, že si hosting koupíš pod podmínkou SSH a hotovo. Když to tak udělá víc lidí a pošle ho kvůli chybějícímu SSH do díry, tak tam prostě to SSH buďto mít bude, nebo nebude mít kšefty. To jsou jednoduchý počty.
Navíc nemusíš mít přímo webhosting, ono stačí mít pronajatou virtuálku, tam je SSH by default a instaluješ si, co je libo. Klidně Apache nebo NGINX. Prachy +/- stejný a nemusíš se dohadovat s jejich adminem, pokud to nutně potřebuješ nějak dodrbat a je to proti jejich bezpečnostním pravidlům.
Takže sorry, ale tyhle argumenty neberu.
Myy davame: https://rosti.cz
Zadnej rozumnej webhoster ti SSH nesebere. Pokud ho nemuze dat, pravdepodobne spoleha na nejake dnes obskurni technologie pro oddeleni uzivatelu.
Ukládání dat třeba na CD nebo HDD je jejich přenos v čase, tj. za X let potřebuješ to, co máš dneska, aby sis data mohl vyzvednout.
Tak se mi zdá, že tady někdo četl info příručku taru :))
Archive files are also used for long-term storage. You can think of this as transportation from the present into the future. (It is a science-fiction idiom that you can move through time as well as in space; the idea here is that tar can be used to move archives in all dimensions, even time!)
A aká je výhoda napríklad ftp://ftp.yandex.ru/ oproti https://ftp.yandex.ru/ ? Lepší vzhľad? Pokiaľ si niečo má človek pozerať v prehliadači súborov, tak je na to SFTP alebo WebDAVs. Síce webové prehliadače nepodporujú SFTP a prehliadače súborov nepodporujú HTTPS, existuje možnosť prezerať si tie isté súbory vo web. prehliadači cez https:// a v súb. prehliadači cez davs:// . WebDAV je len nadstavba HTTP.
Ale to prece vubec neni pravda. SFTP alias SSH File Transfer Protocol je jen nadstavba SSH, ktera pridava podporu prenosu souboru.
https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol
To uz vetsi smysl jako nahrada FTP dava FTPS, coz je FTP protokol s podporou TLS.
https://en.wikipedia.org/wiki/FTPS
jen nadstavba SSH, ktera pridava podporu prenosu souboru.
Přičemž výkon stojí úplně za píííp a jako bonus na tom stroji potřebuješ mít shell přístup (což se nanejvýš obchází přes rovnáky na vohejbák typu scponly/scponlyc shell, přičemž chrootovaná varianta navíc vyžaduje, aby ten shell byl setuid. To jsme tu bezpečnost ale zvýšili, že...
Výkon je implementační problém v OpenSSH, nedávno jsem to tu rozebíral v článku včetně řešení.
OpenSSH už dlouho obsahuje zabudovaný SFTP shell, který se dá velmi jednoduše použít k vynucení SFTP bez terminálového přístupu.
Výkon je implementační problém v OpenSSH, nedávno jsem to tu rozebíral v článku včetně řešení.
Ano, řešení "flákni na to third-party záplatu jako kráva a zkompiluj si to sám" je většině uživatelů na dvě věci. (I v Gentoo to je za trest, protože pokud je nějaká bezpečnostní díra v SSH, tak se prostě vydá nová verze bez toho HPN patche. Nevím, kolik lidí chce čekat na opravu díry u věci typu SSH do doby, než se upraví HPN patch.)
Ostatně vyjádření maintainerů z OpenBSD, že je výkon nezajímá, asi dost jasně napovídá, že tudy cesta k hledání náhrady za FTP zrovna nepovede.
Přestaň už blábolit, přečti si ten článek a najdi si nějaké benchmarky. Ten výkonnostní rozdíl je při nějaké "vyšší" latenci řádový. Krom toho se vůbec se nejedná o to, že je "jeden stroj ždímaný nadoraz", ale že prostě přes normální OpenSSH na lince s latencí v řádech desítek ms víc těch dat neprocpeš, ani když se postavíš na hlavu a u toho budeš nohama žonglovat s vajíčkama. Ta linka - při stejném workflow - prostě zůstane nevyužitá, abys ty data přenesl za stejnou dobu, musel bys je rozsekat a rozdělit tu práci na desítky současně probíhajících přenosů.
"Pokud na výkonu jednoho stroje (nebo několika strojích) ždímaným nadoraz stojí produkce, není ten velký problém ve výkonu SSHFS, ale někde trochu jinde. A až ten stroj jednou klekne, to teprve bude sranda."
Na produkci se vzdy zdimou stroje nadoraz kvuli optimalizaci nakladu. To ze stroj klekne neni vubec zadnej problem, protoze ma samozrejme redudanci a zalohy a na jeho misto relativne rychle nabehne nova VM klidne z uplne jinyho datacentra.
Připojení anonymních klientů k autentifikovatelnýmu serveru a přenos souborů umí HTTPS.
Problém s FTP je jenom o tom, že na web serveru to bylo kvůli uploadu a pár chytrolínů napadlo udělat tam ještě anonymní read only účet, aby mohl kdokoliv stahovat soubory i mimo web browser.
No já nevím.
Nikdy jsem ten boj proti FTP nepochopil.
Úplně stejně, jako potlačení HTTP na úkor HTTPS, je přece možné upřednostnit FTPS na úkor FTP.
https://cs.wikipedia.org/wiki/FTPS
Pak je celý přenos včetně autentizace šifrován, klidně stejným certifikátem, jako pro HTTPS.
FTP je starý protokol... no to je sice pravda, ale starý je třeba i SMTP, budeme ho proto taky rušit?
Sice to funguje a má to podporu úplně všude, ale je to staré, tak to zrušíme a dáme místo toho nějakou novou úžasnou technologii, která sice umí úplně to samé co ta stará, ale má cool nový název a aby to fungovalo, budu si muset nainstalovat X MB sraček.
Jedna věc je omezování nešifrovaného přenosu (schvaluji), druhá sebrat něčemu kompletně podporu jen z nějaké osobní averze. To mě fakt štve. On člověk nikdy neví, kdy se v nouzi bude potřebovat někam přes FTP(S) připojit a zrovna bude mít jako na potvoru k dispozici jen fríkůlinský browser :-(
Aha, o tomhle FTP jsem třeba nevěděl. Víte někdo o dalším?
Uznávám, že při použití klienta může být FTP pro anonymní stahování pohodlnější. Mám zajímavý tip: klient LFTP umí na řádce procházet directory listing v HTTPS stejně jako FTP.
FTP mirroru je podle me stale mnoho, napr. ftp.cvut.cz, ftp.muni.cz, pripadne: https://www.centos.org/download/mirrors/
Různé mirrory softwarových repozitářů jsou běžně přístupné přes FTP, třeba Cygwin při instalaci nabízí výběr z HTTP i FTP serverů s balíčky, mnohé univerzity mají taky veřejný FTP server (jen tak na pár pokusů jsem trefil ftp://ftp.cvut.cz/, ftp://ftp.muni.cz/, spousta dalších jistě bude v zahraničí).
FTP je zkrátka pořád velmi živý a vcelku hojně používaný protokol. Srovnejme to třeba s takovým gopherem, který jsem použil poprvé a naposledy snad v roce 1995, o kterém spousta mladších ajťáků v životě ani neslyšela a který byl z Firefoxu vyhozen v roce 2010, kdy se veřejně dostupné gopher servery nepočítaly už ani na stovky. FTP v tomhle stavu dnes ani vzdáleně není.
>> Víte o nějakém běžně používaném anonymním FTP?
Zkuste si stahnout Adobe Reader 2017 (nikoliv DC) odjinud nez z:
ftp://ftp.adobe.com/pub/adobe/reader/win/Acrobat2017/1700830051/AcroRdr20171700830051_MUI.exe
Skuste napr. ftp.dell.com
Cez toto ftp na anonymnom pripojeni Dell poskytuje updaty a instalacky firmware pre svoje serverove portfolio. Tieto je mozne aktualizovat aj priamo pocas fyzickej instalacie servera este pred samotnym nasadenim OS.
Mimoto v akomkolvek korporate je ovela jednoduchsie povolit cez firewall (prip. ziskat schvalenie povolenia) pre port 21 ako pri porte 22 na sftp.
Když už argumentuješ Wikipedií, tak si přečti, co dokazuješ:
"FTPS, FTP/SSL nebo FTP se SSL/TLS označuje v informatice různá rozšíření protokolu FTP, která zajišťují zabezpečený přenos citlivých informací přes počítačovou síť (přihlašovací jméno, heslo nebo i vlastní přenášená data)."
Kolik těch rozšíření je? Dvě? Pět? Deset? A který z nich mají za svoje peníze implementovat (předpokládejme, že teď tam není), udržovat a testovat? Který a proč reálně potřebuješ ve web browseru?
Varianty FTPS nech file managerům a modulům do FUSE. Web browser nech na stažení a zobrazení/uložení souborů po HTTP(S), to je jeho práce. Ten je v reálu FTP ani FTPS nepotřebuje.
To je nějaká nakažlivá nemoc tady v diskuzích na Rootu, že někteří jedinci musí mít za všech okolností pravdu, i za cenu blábolu?
S FTPS se to má úplně stejně, jako s šifrovaným SMTP. Taky existuje několik implementací, které dělají ve výsledku totéž a nikomu to evidentně nevadí. A ejhle, ony jsou to úplně ty samé, jako u FTPS (SSL, TLS)...
Nicméně o to tady přece vůbec nejde. Jde o to, že výrobci browserů plánují odstranění podpory FTP a argumentují tím, že je to nešifrované (není pravda, existuje FTPS a tudíž by měli tlačit na přechod z FTP na FTPS stejně, jako to bylo u HTTP->HTTPS), případně neexistující (naprostý nesmysl) nebo nešifrovanou (řeší FTPS) autentizací.
Navíc - jak je v článku jasně napsáno - v plánu je kompletní odstranění podpory. Tzn. časem si ani nic nestáhnu.
Proč ale? HTTP taky nechávají, jen varují. Proč tedy u FTP tak tvrdý přístup? Aha, kdyby natvrdo vypnuli HTTP, tak by jim to přestalo nějak celé fungovat. No tak se vyřádíme aspoň na FTP, aby všichni viděli, jací jsme borci, kteří ví nejlépe, co lidi potřebují. Hlavně, že bude fungovat JavaScript (úžasně bezpečný) a Facebook (používají přece HTTPS, tak kde je problém?).
Tak znovu:
- FTP je jiný protokol, než HTTP a HTTPS.
- O FTP se stará nějaký blok kódu, který není k ničemu jinýmu.
- O ten kus kódu se musíš starat a to stojí čas a peníze.
- FTP je bezpečnostní problém.
- Migrace na FTPS by byla jenom proto, aby se zabilo nešifrovaný FTP (= skončilo by tak jako tak) a zlepšila se bezpečnost.
- Překopat to na FTPS znamená upravit to pro několik variant. To znamená investovat do toho další čas vývojářů a tesťáků (a tím i prachy) do každé varianty.
- Investovat do přepsání funkcionality, kterou používá < 1% uživatelů na jinou variantu, která navíc není běžně na serverech, nedává ekonomicky smysl. Kolik uživatelů by ten nově přidaný protokol měl? Ty, co náhodou lezou na server se stejnou verzí FTPS jako browser?
- Když už tak jako tak odpadne klasický FTP a nemá smysl to upgradovat na FTPS, zbývá jediná možnost. Zabít to bez náhrady.
Tak znovu:
- HTTP(S) je jiný protokol, než FTP
- O HTTP(S) se stará nějaký blok kódu, který není k ničemu jinýmu.
- O ten kus kódu se musíš starat a to stojí čas a peníze.
- HTTP je bezpečnostní problém.
- Migrace na HTTPS by byla jenom proto, aby se zabilo nešifrovaný HTTP
- ...
Tedy - tímto směrem bych argumentaci opravdu nevedl...
- Nebe je modré
- Tráva je zelená
- Voda je tekutina a dá se v ní plavat
- FTP je bezpečnostní problém... Jaký přesně? Tisíckrát opakovaná lež se stala pravdou? Celý world wide web je bezpečnostní problém. Webové stránky jsou bezpečnostní problém. Facebook, Youtube, Google... jsou bezpečnostní problém. Myslíte si, že přechodem na HTTPS se to nějak zázračně vyřešilo? Nebo se to vyřeší odstraněním podpory FTP? To, že se kradla hesla k FTP je podle vás problém FTP protokolu? A k webům se snad hesla nekradou? Uložené kreditky se nekradou? Nebylo by teda rozumnější zrušit podporu pro SQL, když z těch databází můžou uniknout (a unikají) citlivá data?
- Ekonomický smysl vývoj browserů jako takových nedává tak jako tak. Peníze se z nich dají získat jen tím, že přitáhnu nové uživatele a ukrojím si svůj podíl z reklamy, nebo prodám jejich osobní data. Vypuštěním podpory nějakého protokolu nové uživatele nezískám, naopak jich čast (byť malou) ztratím. Takže ne, opravdu to nemá nic společného s ekonomickým smyslem, ať už to znamená cokoliv.
- upgradovat na FTPS samozřejmě smysl má. Přínosy použití FTP protokolu jsem popsal v příspěvku níže.
"FTP je bezpečnostní problém... Jaký přesně? Tisíckrát opakovaná lež se stala pravdou?"
[fakt]FTP je nešifrovaný[/fakt]
[fakt]Nešifrovaně se přenáší i přihlášení a další důvěrná komunikace[/fakt]
[fakt]Při MITM může kdokoliv vidět nebo modifikovat komunikaci a zneužít tak to získaný informace včetně loginu na server[/fakt]
[fakt]MITM na FTP dovoluje podstrčit cokoliv[/fakt]
[fakt]Ze stejných důvodů odepsali Telnet[/fakt]
[fakt]Je tak odlišný od HTTP/HTTPS, že musí být v prohlížečích implementovaný a testovaný extra - s rizikem dalších chyb[/fakt]
[fakt]V zabezpečení se riziko bere jako jako nepřijatelný, pokud existuje finančně přijatelný způsob, jak to riziko odstranit - a tady existuje, nepodporovat plaintext[/fakt]
"To, že se kradla hesla k FTP je podle vás problém FTP protokolu? A k webům se snad hesla nekradou? Uložené kreditky se nekradou? Nebylo by teda rozumnější zrušit podporu pro SQL, když z těch databází můžou uniknout (a unikají) citlivá data?"
Kradlo se a krást se bude. Na tom protokol nic nezmění. Konkrétně problém FTP je ten, že nic nedělá pro to, aby těm krádežím zabránil. Problém je, že zákazníci jsou zvyklí mít vchodový dveře z papundeklu bez klíče a když se stavební firma šprajcla, že odteď budou v ceně bytu zabezpečený vchodový dveře s cylindrickou vložkou, tak jsou lidi ještě naštvaní.
"Ekonomický smysl vývoj browserů jako takových nedává tak jako tak. Peníze se z nich dají získat jen tím, že přitáhnu nové uživatele a ukrojím si svůj podíl z reklamy, nebo prodám jejich osobní data. Vypuštěním podpory nějakého protokolu nové uživatele nezískám, naopak jich čast (byť malou) ztratím. Takže ne, opravdu to nemá nic společného s ekonomickým smyslem, ať už to znamená cokoliv."
Dejme tomu, že máš z uživatele 1$/měsíc. Mám 1M uživatelů. mám $1M/m
Vyhodím featuru, kterou používá 1% lidí. Polovina z nich se přeorientuje jinak (místo "stáhnout pomocí FTP" klikne na "stáhnout po HTTP"). Vypadne 5000 lidí a $5k/m
O featuru se stará nějaký člověk, kterýho musím platit, topit mu, svítit mu, a náklady na udržování té featury jsou $7k/m
Featuru zaříznu, chlapa převedu na jinou práci a jsem furt $2k v plusu.
"upgradovat na FTPS samozřejmě smysl má. Přínosy použití FTP protokolu jsem popsal v příspěvku níže"
Sorry, ale třeba práva k souborům bych na webu zrovna neřešil. Na straně serveru to smrdí nechtěnou eskalací práv (a to asi nechceš), na straně klienta taky (a to zase nechce návštěvník webu). Takovýhle výhody jsou poněkud sporný. Zbytek je použitelný snad jenom IPSEC tunelem.
Proboha. Srovnávat telnet a FTP...
Rada: nedělejte ze sebe vola a nemluvte o tom, čemu evidentně nerozumíte. Proti MITM vám nepomůže naprosto nic. Ani šifrování. Techniku MITM dneska používá např. každý antivirus. A zdá se vám, že by měly nějaký problém kontrolovat (tedy i možnost ovlivňovat) zašifrovanou komunikaci?
Končím debatu. Nemá to cenu.
Stejně tak pravděpodobně z vašeho počítače nikdo neukradne uložená hesla k FTP serverům.
Přece Petře dobře víte, co mám na mysli (*).
Pořád se dokola omílá nebezpečí používání FTP, ale v samotném protokolu přece není žádný problém.
Je úplně jedno, jestli mi někdo ukradne hesla k FTP serveru, do nějakého e-shopu nebo k e-mailu.
Nebo jestli se někde připojím k veřejné wifi a někdo bude chytat a číst mou komunikaci.
Problém není ani v jednom případě v použitém protokolu.
FTP je rozšířený, jednoduchý, robustní a široce podporovaný protokol pro přenos souborů a samozřejmě ho lze šifrovat. To vím já, víte to vy a ví to i ti tvůrci prohlížečů. To, co mi vadí je, že se někdo rozhodl, že se podpora pro FTP zruší, s odůvodněním, že "je to nebezpečné" a "nikdo to nepoužívá". Obojí není pravda. Bezpečné to může být stejně, jako vše, jde o přístup správce serveru a o přístup uživatele (tady spíše obecný, ne jen ve vztahu k FTP). Naopak, je to lety prověřený protokol. Stačí si přečíst, jaké neuvěřitelné průsery se objevují např. v GITu, který někteří chtějí prosazovat právě na úkor FTP. A uživatelů je v browserech málo, protože z funkcionality běžného FTP klienta je v nich implementováno asi tak 10%. Donutit webmastery, kteří v určitých situacích odkazují na FTP zcela úmyslně a logicky k tomu, aby svá data dali všanc na nejděravější platformě na světě, kterou je WWW, je prostě krok mimo, ať se na to budeme dívat z jaké strany chceme.
Běžný Franta si do svého počítače nainstaluje cokoliv, jen aby měl nové smajlíky nebo jiné téma pro prohlížeč a s tím si klidně může přidat důvěryhodnou certifikační autoritu, jako ty AV. O telefonech nemluvě, tam je stav ještě horší.
Vždy to bude jen o přístupu uživatelů k bezpečnosti a žádné technické řešení ani restriktivní přístup tvůrců software to nemůže vyřešit. Tím se jen zkomplikuje práce určité skupině lidí, kteří ve většině případů mají o bezpečnosti nějakou představu.
Souhlasím s tlakem začít používat šifrování, jako to bylo u HTTP. Nesouhlasím s bohorovným přístupem stylu "Seznali jsme, že je to nebezpečné a proto to vymažeme ze světa".
(*) Pokud budete sedět u počítače s Windows zařazenými do domény a zaměstnavatel (nebo útočník, nebo nasraný admin) se rozhodne, nainstaluje vám politikou CA jakou bude chtít. A bude si vesele číst, co se mu zamane. Nepamatuji si teď přesně, jestli to byl Juniper, F5 nebo Cisco, ale měl jsem před pár lety na stole jejich krabici, která přesně tohle umožňovala, stačilo ji zapojit na správné místo do síťové infrastruktury. Takže ano, váš osobně spravovaný Linux je (podle aktuálně známých informací) proti MITM v bezpečí. Ale takových počítačů je ve srovnání s těmi ostatnémi ve světě minimum, ať se nám to líbí nebo ne.
@TKL
"Stejně tak pravděpodobně z vašeho počítače nikdo neukradne uložená hesla k FTP serverům."
V počítači jsou v bezpečí, pokud je nepoužiješ. Jak se připojuješ na FTP, zveřejníš je sám(*)
"Pořád se dokola omílá nebezpečí používání FTP, ale v samotném protokolu přece není žádný problém."
Kromě toho, že umožňuje odposlechnout přihlášení a zopakovat ho útočníkovi, přenos dat je transparentní a odklonění je triviální prkotina nehodná středně pokročilýho script kiddie. Ale to jsou detaily, který nikoho nezajímají, že...
"Je úplně jedno, jestli mi někdo ukradne hesla k FTP serveru, do nějakého e-shopu nebo k e-mailu."
Možná tobě. v E-shopu uvidí maximálně historii objednávek, s mailem dostane možnost na sebe přesměrovat jiný služby, kde jsem se pomocí něho registroval (= krádež identity).
"Problém není ani v jednom případě v použitém protokolu."
Protokol je bezpečný, pokud odolá prolomení hrubou silou po dobu, kterou nechci údaje vyzradit. U Telnetu, FTP a HTTP je garance neprolomení 0s. Například u paywallu zadávám číslo karty, platnost karty je 5 let. Takže vyhoví protokol, který nelouskneš s dostupnou výpočetní kapacitou do 10 let (ať je rerzerva). Za 10 let ať si někdo klidě zkusí nakoupit na kartu, která je pět let neplatná.
"FTP je rozšířený, jednoduchý, robustní a široce podporovaný protokol pro přenos souborů a samozřejmě ho lze šifrovat. To vím já, víte to vy a ví to i ti tvůrci prohlížečů"
Jenomže na rozdíl od tebe ostatní ví, že šifrování je rozšíření, který musí stejně implementovat klient i server. A těch implementací je hodně a málo kdo používá aspoň některou z nich. Navíc v implementaci toho rozšíření se dá udělat plno chyb (výměna klíčů a pod.). Když musíš přidat ještě jednu vrstvu protokolu v několika variantách, jednoduchost a robustnost je ta tam.
Jediná možnost, jak ho spolehlivě šifrovat bez omezení jednoduchosti a robustnosti, je prohnat ho skrz IPSec tunel.
"To, co mi vadí je, že se někdo rozhodl, že se podpora pro FTP zruší, s odůvodněním, že "je to nebezpečné" a "nikdo to nepoužívá". Obojí není pravda."
Bezpečnost jsme, myslím, probrali. Věnujme se argumentu, že to "nikdo nepoužívá". V článku je statistika z telemetrie od Googlu. Takže nějaký číslo, který tvrdí opak. Máš nějakou statistiku nebo relevantní argument, potvrzující opak?
"Bezpečné to může být stejně, jako vše, jde o přístup správce serveru a o přístup uživatele (tady spíše obecný, ne jen ve vztahu k FTP)."
Přesně tak. Rozumný správce serveru nenasadí nic, co neoprávněné osobě nedovolí neautorizovaný přístup do systému. Přihlašování protokolem, který předává username a password v plaintextu, nemá další faktor ověření, dovoluje přepsat na serveru soubory a měnit jejich práva, nechme nezodpovědným hlupákům, co si na správce jenom hrají.
"Stačí si přečíst, jaké neuvěřitelné průsery se objevují např. v GITu, který někteří chtějí prosazovat právě na úkor FTP."
Průšvih může být se vším. Poslední průšvih, o kterám ohledně GITu vím, byla dostupnost adresáře .git v adresářích webu a pak párkrát nějaký vůl hodil privátní klíče do repozitáře. První případ je ekvivalent toho, když po FTP dovolíš stahování souborů, ke kterým nemá mít návštěvním přístup (PHP skripty,...), druhý odpovídá situaci, kdy hodíš privátní klíč hned vede index.html se stejnýma právama. Takže chyba mezi židlí a klávesnicí.
Pokud víš o problému s implementací, davaj link.
"A uživatelů je v browserech málo, protože z funkcionality běžného FTP klienta je v nich implementováno asi tak 10%. Donutit webmastery, kteří v určitých situacích odkazují na FTP zcela úmyslně a logicky k tomu, aby svá data dali všanc na nejděravější platformě na světě, kterou je WWW, je prostě krok mimo, ať se na to budeme dívat z jaké strany chceme."
Ok, mějme doménu podepsanou DNSSEC (v případě .cz ECDSAP256SHA256 nebo ECDSAP384SHA384). Ty se zeptáš na TLD, ověříš proti built-in podpisu odpověď na .cz resolver. Ten ti dá odpověď na L2 a podepíše ji. ty si podpis ověříš a zkontroluješ klíč serveru, na který se připojuješ. Připojíš se pomocí https se silným šifrováním a kontroluješ integritu dat.
Zkus tomu konkurovat s infrastrukturou, kde si můžeš udělat server s tím, že heslo ignoruješ, přesměrovat si na něho oběť někam cestou a dát jí pozměněný data. Nebo si poslechnout data. Nebo si poslechnout přihlášení a změnit ty data.
"Běžný Franta si do svého počítače nainstaluje cokoliv, jen aby měl nové smajlíky nebo jiné téma pro prohlížeč a s tím si klidně může přidat důvěryhodnou certifikační autoritu, jako ty AV. O telefonech nemluvě, tam je stav ještě horší."
Instalace takové autority je možná v případě, že se útočníkovi povede dostat tu instalačku do zařízení. To jde kompromitováním serveru (třeba tím, že odposlechne přihlášení admina po FTP), pozmění data během stahování (FTP, HTTP), nebo sociální inženýrství.
"Vždy to bude jen o přístupu uživatelů k bezpečnosti a žádné technické řešení ani restriktivní přístup tvůrců software to nemůže vyřešit. Tím se jen zkomplikuje práce určité skupině lidí, kteří ve většině případů mají o bezpečnosti nějakou představu."
To je sice pravda, ale proč to lumpům nezkomplikovat? Proč nechávat otevřeno, když můžu zavřít a donutit je vzít za kliku a nechat tam otisky prstů? Nebo rovnou nezamknout? Tím je minimálně zdržíš, většinu odradíš. Přece příležitost dělá zloděje.
"Nesouhlasím s bohorovným přístupem stylu "Seznali jsme, že je to nebezpečné a proto to vymažeme ze světa"."
Oni ale nemažou FTP ze světa. Oni to mažou jenom ze svýho produktu a uvedli pro to racionální důvody. Narozdíl od DropBoxu, který omezil filesystémy a neřekl proč.
*) přenosový kanál se z principu v security při analýze bere jako kompromitovaný do doby, než se prokáže opak
MITM má několik vektorů. Někde použije autentizace, jinde autorizace, jinde zase šifrování. A pokud jde o bezpečnost, 100% nedosáhneš nikdy, je vždycky o kompromisu mezi cenou a bezpečností. Že nemůžu mít 100% neznamená, že se nemůžu pokusit aspoň o 80%.
Za vyhovující zabezpečení se považuje stav, kdy šifrovaná zpráva odolá brute force nějakou definovanou dobu. u FTP je doba do prolomení přesně 0. I XORování 1kB blokem náhodnch čísel je na tom s odolností líp.
Víte, když implementace FTP v prohlížečích je cca 20 let za vopicema (šifrování - implicitní i explicitní, včetně volitelného šifrování datového kanálu - podporoval každý trochu slušný FTP klient a server už cca před těmi dvaceti lety), tak nemůžete seriozně argumentovat tím, že to je nebezpečné. To, že se "přestává (zvlášť v prohlížečích) používat" pak přesně odpovídá uživatelskému "komfortu" a kvalitě implementace v těch prohlížečích.
Tak prosímvás argumentujte tím, že "nás to nezajímá, nechceme žádné zabezpečené FTP implementovat a celkově na to úplně kašlem", a nementorujte o bezpečnosti.
Pravda je taková, že ve většině případů je nabízení souborů ke stažení přes FTP mnohem bezpečnější, než přes HTTP(S).
Protože FTP 1) umožňuje velmi jednoduše oddělit data, určená k uploadu nebo ke stažení, od struktury samotného webu, 2) disponuje (alespoň v případě proftpd) velmi pokročilým systémem práv (např. můžu ukládat, ale nemůžu mazat - nebo - můžu vidět obsah ale nemůžu stahovat atd...).
To, že se nyní FTP v browserech používá minimálně, není chybou protokolu, ale špatnou podporou v prohlížečích.
Tudíž namísto odstranění podpory by vývojáři měli napnout síly k jejímu vylepšení.
FTP totiž do browserů jednoznačně patří, protože manipulace se soubory přes FTP, integrovaná do webových stránek, je naprosto logickou a nedílnou součástí webu. Nehledě na mnohem vyšší reálné zabezpečení. Realita je totiž taková, že 99% webhostingů má nastavena práva pro zápis do celé adresářové struktury webu. To, že celý tenhle chaos běží přes HTTPS, situaci opravdu nezachrání.
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.
"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.
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š.
"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...
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.
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.
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
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...
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é.
- FTP měl dávno umřít
- SFTP není řešení, protože je to nadstavba nad SSH, což je určeno k něčemu jinému. Já jsem zastánce toho, že bezpečný nástroj UMÍ POUZE JEDNU VĚC a to tu k čemu je určen
- HTTPS nemá žádnou extra režii na přenos. V přenosovém pásmu tuplem ne, výkonovém maximálně šifrování, to by ale hrozilo i pro FTP over TSL. Při downloadu přes HTTPS stačí poslat krátkou hlavičku (stačí čtyři řádky - status, Content-Length a Content-Type a prázdný řádek) a dál už pokračuje stream 1:1 vlastního souboru. FTP potřebuje 2 konekce na vlastní provoz a tunu příkazů aby se vůbec něco stáhlo.
- HTTPS se hodí i na upload, pochopitelně.
- HTTPS umí virtuální servery, FTP ne
Obecně bych si dokázal představit plnohodnotný fileserver nad HTTPS/REST - že by WebDAV?
- HTTPS se hodí i na upload, pochopitelně.
- Obecně bych si dokázal představit plnohodnotný fileserver nad HTTPS/REST - že by WebDAV?
Tak určitě. Tak si prosímtě zkus zazálohovat pár set giga dat na WebDAV, nebo si cvičně nahoď do adresáře pár tisíc fotek a zkus si to zesynchronizovat třeba s Nextcloudem. A až tě za pár měsíců pustí z Bohnic, tak mám přijď povyprávět o tom výkonu a zážitku.
To především není vůbec problém klienta, ale zbytečné vysvětlovat někomu, kdo zjevně tu věc nikdy prakticky nezkoušel použít na něco krom hraní, ale zato cítil o to větší nutkavou potřebu si čutnout do FTP i při té příležitosti nahodit nějakou managorskou perlu typu "použijeme REST/HTTPS, vyřešeno".
Ještě mi to nedá:
- HTTPS umí virtuální servery, FTP ne
Neblábol.
- https://tools.ietf.org/html/rfc7151#page-4
- http://www.proftpd.org/docs/howto/Vhost.html
Problem tehle novych rozsireni je, ze pulka serveru i klientu je zacne podporovat mozna po mnoha letech, nebo taky vubec. Takze s trochou snahy se to da pouzivat pro vlastni potrebu, ale rozhodne se neda spolihat na to, ze to bez problemu pojede beznymu uzivateli s jeho oblibenym FTP klientem.
Cely FTP je uz hodne dlouho v takovym zombie stavu, funguje, ale nikam se neposouva. Pokud se nahodou neco deje, strasne to trva. Treba MLST/D, standardizovany vypisy adresaru, coz je naprosto kriticka vec pro nejakou rozumnou pouzitelnost, to od draftu k RFC trvalo deset let, nemluve o nasledny (ne)implementaci. EPSV/EPRT ma sice RFC uz dvacet let, ale vsichni na to kaslali dlouhy roky (i kdyz tam to bude v ramci obecnyho kaslani na IPv6). Dalsi uzitecny veci, napada me treba MFMT & friends nebo HASH, to na RFC ani nedotahly a tezko rict, jestli se to jeste zmeni. V diskusi zminovanymu sifrovani taky trvalo roky, nez se to dalo zacit pouzivat.
> SFTP není řešení, protože je to nadstavba nad SSH, což je určeno k něčemu jinému. Já jsem zastánce toho, že bezpečný nástroj UMÍ POUZE JEDNU VĚC a to tu k čemu je určen
SSH protokol umoznuje otevrit separatni kanaly v ramci SSH spojeni, kde napr. shell je jeden kanal a SFTP je jiny kanal. Tedy SFTP vyuziva SSH jen jako zabezpecenou session vrstvu a v principu by mohlo fungovat i pres jine takove vrstvy (napr. TLS).
FTP stále používám v domácí síti, protože nic jednoduššího na konfiguraci Windows Explorer neumí a nedávno jsem přes FTP stahoval Ubuntu ISO.
Příjemnější je pro mě použít WinSCP/FileZillu, ale u prohlížeče to právě bylo dobré proto, že když někde byl nějaký odkaz na FTP, tak stačilo klepnout a bylo to zobrazené. Žádné kopírování adres apod. nebylo nutné.
Škoda.
Velke mnozstvi firem jeste donedavna vystavovalo/vystavuje drivery pres FTP:
ftp://ftp.hp.com/pub/
ftp://ftp.supermicro.com/
ftp://ftp.dell.com/
ftp://ftp.panasonic.com/pub/panasonic/
...
etc.
"Je to bezpečnostní riziko... Ale co je komu do toho? Já "nemám na autě brzdy, já se rozplesknu. Nesnášim když mi někdo něco znemožňuje s odůvodněním že to se mnou myslí dobře."
Až na to, že tím autem můžeš rozplesknout i někoho jinýho. Stejně jako špatně zabezpečenou online službou můžeš uškodit někomu dalšímu.
Blabole. Presne to jsem chtel ted napsat ze tihle jako ty jsou nejhorsi varianta. Nejhorsi je kdyz ti nekdo zakazuje neco z duvodu pocitu vlastniho ohrozeni. Jasne. Takze zakazu sousedovi pouzivat a vlastnit kuchynske noze, protoze tim potencialne muze vyvrazdit pul baraku.
Opravdu nekteri lidi spadli z hodne vysoke visne na hlavu.
Já zase mám rád debily s přístupem "no a co, riskuju, je to jenom moje věc". Je, ale jenom po určitý mantinely. Zodpovídáš za svoje chování. Pokud jím způsobíš škodu okolí, tak ty sice neseš následky (= dostaneš třeba podmínku), ale přejetýho chodce to z vozíku nezvedne.
Hele, ať si ten tvůj soused klidně nožem vytírá zadek, jestli mu to přináší uspokojení. Ale ať se chová zodpovědně k okolí, ty nože necpe cizím dětem na hraní a nepřepadá s nima noční chodce.
Taky jsou docela na hlavu ti, co si mysli, ze ostatni jsou zcela jiste za vsech okolnosti nesvepravni. Treba ze FTP budou pouzivat primarne ke stahovani malware skodici jinym aniz by vedeli co delaji. Treba ze v aute budou lidi jezdit bez brzd za ucelem aby nekoho jineho zabili. Nebo ze kdokoliv, kdo ma v kuchyni noze me hned chce zapichnout. Tohle jsou opravdu iracionalni a posahani lide. Skoro az extremisti. Hledat ve vsem jen a pouze problem, negativa, vlastni ohrozeni, nesvepravnost jinych apod. je fakt na hlavu a zrale na nekolik navstev psychologa, nebo nejakeho terapeuta.
Petre nechci byt prilis konspiracni, ale kdyz si prectete nazor Petra M, zjistite ze on pouzivani nesifrovaneho FTP srovnava s jezdenim autem bez brzd. To je celkem problematicke. To ze se prohlizece rozhodly opustit podporu FTP je samozrejme jejich volba jako autoru toho kodu. Kdokoliv to preci muze forknout a podporu zase pridat, v tom nikomu nikdo nebrani. Jen se desim doby kdy me nekdo v extremu napraska ze pouzivam FTP a ze ohrozuju z kdo vi jakeho duvodu jeho bezpecnost. To psal Petr M, ze "Až na to, že tím autem můžeš rozplesknout i někoho jinýho. Stejně jako špatně zabezpečenou online službou můžeš uškodit někomu dalšímu." Dokazete si Petre predstavit, kdyby se treba takto smyslejici clovek dostal k moci, kam by jsme to dopracovali? No ja radeji nechci domyslet.
Klídek. Příměr k autu bez brzd byla reakce ne na FTP a jeho požívání, ale na konkrétní komentář:
https://www.root.cz/clanky/chrome-a-firefox-tlumi-podporu-ftp-a-planuji-ji-uplne-ukoncit/nazory/1007945/
Prostě nemám rád přístup, že já si budu klidně riskovat a na to, že tím můžu ohrozit ostatní (nebo jejich zájmy) kaká bílý tesák.
Btw, poslední takový, se kterým jsem se setkal, předjížděl z kopce na plné čáře, kde byla 70ka. Vyjelo mu ze zatáčky pod kopcem auto v protisměru, lekl se, strhl řízení a z kopce válel sudy po poli. V tom autě byli celkem čtyři lidi... Je to osobní věc toho řidiče, že riskoval a choval se jak blbec?
Kdo píše kód, ten rozhoduje...
To je zajímavý přístup.
Existuje nějaké prostředí, infrastruktura (world wide web), ve které se používají nějaké služby. Provozují ji milióny subjektů.
A někdo píše kód ke klientovi pro toto prostředí. A ten (jednotky subjektů) se rozhodne, že některá ze služeb infrastruktury je nebezpečná, čímž - z pozice moci, protože má de facto monopol - nutí provozovatele služeb ke změně infrastruktury, které by sám měl sloužit, protože bez ní by klient byl k ničemu. Nevím, prostě se mi to nelíbí. Příliš mi to připomíná doby před listopadem 1989, kdy moudrá Strana věděla nejlépe, co prostý lid potřebuje.
Jedna věc je odstranění podpory telnetu, čímž se tady někteří ohánějí, ke kterému dávno existovala lepší, podporovaná a otestovaná alternativa (SSH). Druhá je ale plánované ukončení podpory FTP, ke kterému plnohodnotná alternativa neexistuje a ještě to obhajují dost pofidérním způsobem.
Na každou věc se musí člověk dívat z nadhledu. Problém je, že v té masovosti prohlížečů se skrývá další rozměr a tím je charakter veřejné služby. Pokud omezují nějakou funkci, omezují tak globálně celý svět. Navíc to povede ke zvýšení nároků na výpočetní prostředky, protože servery přejdou z ftp na https a srovnejte si režii systému.
Tuto snahu o zpomalení výkonu od jistým způsobem postižených jedinců, kterými oplývá google i mozzila, sleduji už delší dobu, například googlem doporučované zapnutí komprese textů, když už vám to chodí v kompresi od https, tlačí k opuštění formátů JPG a GIF... A vysvětlujte to managorovi, když mává lejstrem od googlu že máte něco špatně.
HTTPS taky nebylo googlem protlačeno z důvodu bezpečnosti, ale snadné identifikace jedinců, kteří mají v oblibě chodit na web přes nějakou tajemnou proxy.
Navíc toto všechno vede k větší spotřebě výpočetních prostředků a prachy se rychleji točí. A to je zřejmě cílem.
To by sis ji mel poridit spis ty, protoze pise presne to k cemu to guugl pouziva. Proc myslis, ze tvuj browser pekne naprasi cert webu na kterej lezes ... komu jinymu nez guuglu (samozrejme ze pro "tvoji bezpecnost"), a co myslis, kolik sudomen asi tak potrebuju, abych byl schopnej jednoznacne (za pomoci hsts) identifikovat libovolnej browser ... chmm ... asi tak 32 ...
A neboj, on to guugl brzo vylepsi, pokud tvuj uzesnej browser nenaprasi guuglu vse co chce, tak se na web proste nedostanes. Nazdar.
hlavne se prehlizi fakt, ze s autem bez brzd se donedavna vetsinove jezdilo a nikdo se nad tim nepozastavoval, sifrovani se pouzivalo jen na kriticke aplikace, a taky se nic kdovijak zasadniho nestalo, internet fungoval atd ...
masivni nasazovani zabezpecenych sluzeb je zalezitosti pouze nekolika poslednich let z pohledu trvani internetu
Který auto se v posledních pár dekádách prodávalo z výroby bez brzd a jak procházelo homologací / STK?
Pokud jde o Internet, tak ten si prošel celkem velkým vývojem. Od ARPANETu, zapojení akademiků, přidání nadšenců až pro platformu pro masy, kde se točí prachy. Jak se někde točí prachy a data na prodej, musíš je chránit. Data, který mají pro markeťáky cenu, jsou i informace o tom, že sis minulý týden koupil vysavač té a té značky (a můžou ti začít nutit pytlíky do něj s úžasnou levou ze 120Kč na 180Kč). S pomocí Internetu dneska
- platíš - potřebuješ, aby se k tvé kartě a účtu nikdo nedostal,
- komunikuješ (i soukromý věci) - poskytovatel komunikační služby je vázaný legislativou ohledně listovního tajemství atd.,
- uzavíráš smlouvy (např. kupní v E-shopu) - potřebuješ, aby obě strany souhlasili s naprosto stejnýma podmínkama, ne že si tam cestou například k ceně někdo připíše nulu, nebo ji umaže.
- vyděláváš peníze prostřednictvím reklamy a nechceš, aby místo tvýho reklamního systému ke čtenáři dorazila reklama někoho jinýho
- a dostáváš informace pro svoje rozhodování.
Takže jsou na to jiný požadavky, než byly kdysi, kdy online bylo jenom pár kamarádů a kolegů.