> Důvodem ukončení podpory jsou problémy s bezpečností starého protokolu, který nepoužívá šifrování
Tohle moc nechápu. Jak jako starý protokol nepoužívá šifrování?
Všechny mé FTP servery mají zapnuté vynucené šifrování, bez něj se vůbec nedá přihlásit.
To už by mohli rovnou zahodit HTTP. Taky je to starý protokol nepoužívající šifrování...
HTTPS je vlastně "to samé", co FTPS.
Mohli.
Ale zrovna tady se pokaždé objeví vášnivé diskuse, že DV certifikáty jsou na bačkoru, a už vůbec by certifikáty neměly být bezplatné.
Takže byste skočil u toho, že každá pitomá domácí krabička musí mít certifikát, ale protože ani nemá veřejné jméno ani IP adresu, tak může mít jedině self-signed, na což ovšem (oprávněně) prohlížeče nahlížejí nelibě.
A máme začarovaný kruh.
FTP má ovšem i jiné mouchy, než jen to nešifrování (to samo o sobě je řešitelné).
Vezměte to z druhého konce: na download je FTP zbytečné, HTTP(S) ho nahradí bez problémů; na upload není bezpečné - ale to stejně prohlížeče nedělají.
Závěr: v prohlížeči FTP nutné skutečně není.
Tato zarizeni by spise mela byt pouzita ve spojeni s neaky hubem ktery je agreguje a umoznuje pristup skrze sifrovane spojeni.
Vetsina kutilu co ma doma v siti arduino a esp ma take v siti nejake vykonejsi zarizeni napr RPI. ESP zvlada mqtt skrze SSL. Sifrovani u arduina je problem kvuli jeho vykonu a pameti ale verim ze pocet arduin postavenych na atmegach ktere jsou pripojeny k siti je minimalni.
Pokud bych uz pouzival arduino jako jednoduchou teplnotni sondu/sitove rele tak tam pouziju SNMP misto HTTP.
20. 3. 2020, 10:57 editováno autorem komentáře
FTP nikdo nezakazuje, jen v prohlížečích je využíván zcela okrajově. Historicky tam byl kvůli stahování souborů, ale to dnes obsluhuje HTTP.
FTP má několik zajímavých vlastností, např. přenos přímo mezi dvěma servery. Klient se připojí od sebe ke dvěma serverům a dá překopírovat soubor. Spojení se pak naváže přímo mezi servery a data netečou tam a zpět. Jenže to je vlastnost, která je využívaná ve zlomečku případů, sám jsem se s tím od devadesátých let setkal dvakrát.
Na druhou stranu strašlivou nevýhodou FTP jsou dvě spojení. Právě kvůli funkci, kterou jsem popsal, jsou nejlepší aktivní spojení. Jenže ty narážejí na IPv4 NAT, conntrack helpery to neumějí 100% zachránit. Pasivní spojení to supluje, ale zlobí to v různých situacích; v obou případech je potřeba otevírat spoustu portů; na klientské straně to lze dynamicky, na serverové straně se musí většinou staticky.
Operátoři (např. u nás O2) FTP prohánějí přes transparentní proxy. Tím vyblokovávají některé příkazy, např. na O2 nelze (nebo aspoň ještě nedávno nešlo) započít přenos mezi dvěma servery. Prostě příkaz nepropustí. (Obejít to lze posazením FTP na jiný port než 21)
Díky tomu, že v rámci spojení se nepřenáší informace o hostovi, neexistuje rozumný způsob, jak samočinně ověřovat certifikáty. Kdokoliv může provést MITM útok pomocí transparentní proxy a odhalit se to dá jedině, pokud na klientské straně explicitně ověříte certifikát serveru (což je zase překážka, musíte distribuovat informaci o platných certifikátech, nebo mít vlastní CA, nebo důveryhodnou CA + ověřovat DN a SAN proti seznamu).
FTP je prostě velmi překonaný protokol, který neslouží tak, jak by měl (mohl) a ještě k tomu trpí spoustou problémů. Kde se mu dá vyhnout, je vždy lepší používat něco jiného.