Názor k článku Chrome a Firefox tlumí podporu FTP a plánují ji úplně ukončit od Petr M - Neuč orla lítat. https://tools.ietf.org/html/rfc2228 Kapitola 2, odstavec 3: "...
-
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...
ČLÁNKY DO MAILU