Hlavní navigace

Chrome bude připojení FTP označovat jako „Nezabezpečeno“

Sdílet

Petr Krčmář 18. 9. 2017

Google pokračuje ve své snaze o zvýraznění nezabezpečených internetových přenosů. Prohlížeč Chrome ve verzi 63 začne připojení pomocí protokolu FTP označovat jako „Nezabezpečeno“. Podobně to dělá teď u stránek, které používají nešifrované HTTP a zobrazují uživateli políčka pro vložení informace – například jména a hesla.

FTP znamená nezabezpečený přenos

Změna by se k uživatelům měla dostat během prosince letošního roku. Jak vysvětluje vývojář Mike West, v původním plánu upozornění na FTP nebylo, ale jeho bezpečnost je ještě horší než u HTTP. Vývojáři doporučují následovat příkladu správců Kernel.org, kteří před časem zrušili FTP a nabídli veřejné stahování zdrojových kódů už jen po HTTPS.

FTP je velmi starý protokol, který vznikl v 70. letech minulého století a data i hesla přenáší nešifrovaně. Později vzniklo jeho rozšíření FTPS, které přidává šifrování, ale to není příliš rozšířené a není podporováno v prohlížečích.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 18. 9. 2017 12:04

    Zero (neregistrovaný) 62.209.192.---

    Později vzniklo jeho rozšíření FTPS, které přidává šifrování, ale to není příliš rozšířené a není podporováno v prohlížečích.
    Aha, tak miesto toho aby sa pridala podpora a tym padom by sa mozno aj rozsirilo pouzivanie FTPS, tak radsej ostaneme pri terajsej situacii, len to oznacime ako nezabezpecene.

  • 18. 9. 2017 13:15

    Sten (neregistrovaný) ---.gate.parawide.net

    Který server podporuje šifrování přenášených dat? Je sice pěkné, že se FTP naučilo používat TLS, ale v naprosté většině případů funguje jen pro šifrování řídicího spojení, ne datového, protože pokud server povolí šifrování datového spojení, tak lze velmi snadno DOSovat.

  • 18. 9. 2017 13:09

    Sten (neregistrovaný) ---.gate.parawide.net

    FTPS v základu přidává šifrování na řídicí spojení, ale datové spojení zůstává nešifrované. Datový kanál lze šifrovat pomocí PROT, ale je to problematické (např. se znovu vyjednává TLS, je potřeba znovu ověřit certifikáty, …) a málokterý server to podporuje. Navíc FTPS je špatně navrženo a lze velmi snadno DOSovat, takže ho většinou nemají zapnuté ani servery. Kernel.org nepřešlo na HTTPS místo FTPS jen tak z rozmaru.

  • 18. 9. 2017 14:52

    Zero (neregistrovaný) 62.209.192.---

    Navíc FTPS je špatně navrženo a lze velmi snadno DOSovat, takže ho většinou nemají zapnuté ani servery.
    To ma celkom zaujalo... Aky DOS by sa dal urobit?

  • 18. 9. 2017 15:24

    Sten (neregistrovaný) ---.gate.parawide.net

    Opakovat PROT a CDC (zapnutí/vypnutí TLS na datovém kanálu). Server bude neustále dokola přegenerovávat TLS sezení, což je dost výkonově náročné, zatímco klientovi stačí posílat dokola tyhle dva příkazy. Dá se proti tomu trochu bránit throttlingem, ale klient prostě otevře víc spojení a bude útočit tak. Omezit PROT/ CDC nad více spojeními nejde, protože tím útočník snadno odřízne všechny klienty.

  • 19. 9. 2017 9:22

    Zero (neregistrovaný) 62.209.192.---

    Server bude neustále dokola přegenerovávat TLS sezení, což je dost výkonově náročné, ...
    Neviem ake je to presne vykonovo narocne (nemeral som) ale podla mna v dnesnej dobe pri tych CPU co sa davaju do servrov az tak narocne to nebude a navyse pri HTTPS sa robi (skoro) to iste

    Dá se proti tomu trochu bránit throttlingem,
    Neviem ci by sa dal pouzit nejaky load balancer...

    ale klient prostě otevře víc spojení a bude útočit tak
    To iste moze robit aj na HTTP(S).

    Který server podporuje šifrování přenášených dat?
    Ved prave ze momentalne ziadny... spravca FTP si povie ved naco nasadzovat FTPS (treba vygenerovat certifikaty nastavenie v DNS atd...) ked ho nemaju naimplementovane prehliadace. Kolko BFU pouxiva FTP managera na stahovanie?

    Podla mna ak by prehliadace to mali spravne implementovane a vynucovali to tak, ako sa teraz vynucuje HTTPS, tak by to bolo lepsie a mozno by sa FTPS rozsirilo. Alebo by sa to vsetko napchalo do HTTPS ( popravde sa mi nepaci stahovanie cez HTTP(S), tento protokol je na nieco ine... Na prenos suborov tu je prave FTP(S) )

  • 19. 9. 2017 18:55

    Sten (neregistrovaný) ---.gate.parawide.net

    Neviem ake je to presne vykonovo narocne (nemeral som) ale podla mna v dnesnej dobe pri tych CPU co sa davaju do servrov az tak narocne to nebude a navyse pri HTTPS sa robi (skoro) to iste

    S nedostatkem entropie je na serverech problém docela často.

    Neviem ci by sa dal pouzit nejaky load balancer

    Balancovat lze řídicí spojení, s datovými je docela problém.

    To iste moze robit aj na HTTP(S).

    Tam se to dá dobře řešit na úrovni firewallu (throttlingem spojení) či TLS akcelerátoru. HTTPS neumožňuje reinicializaci TLS uvnitř jednoho spojení.

    Ved prave ze momentalne ziadny... spravca FTP si povie ved naco nasadzovat FTPS (treba vygenerovat certifikaty nastavenie v DNS atd...) ked ho nemaju naimplementovane prehliadace. Kolko BFU pouxiva FTP managera na stahovanie?

    Kolik BFU používá FTP v prohlížeči? BFU použije tak možná Google Drive nebo OneDrive, samozřejmě přes HTTPS.

    Podla mna ak by prehliadace to mali spravne implementovane a vynucovali to tak, ako sa teraz vynucuje HTTPS, tak by to bolo lepsie a mozno by sa FTPS rozsirilo. Alebo by sa to vsetko napchalo do HTTPS ( popravde sa mi nepaci stahovanie cez HTTP(S), tento protokol je na nieco ine... Na prenos suborov tu je prave FTP(S) )

    FTP není dobrý protokol pro přenos souborů na Internetu. Ten protokol vznikl pro sítě založené na Network Control Program dvanáct let před nasazením TCP/IP a je to na něm hodně znát. HTTP se naučilo přenášet soubory o hodně lépe, než FTP kdy umělo (WebDAV). Je to vidět třeba na Gitu, který přes HTTPS funguje obousměrně, ale přes FTP umí jen stahovat a i to je často problematické (třeba kvůli firewallům).

  • 20. 9. 2017 11:07

    Filip Jirsák

    HTTPS neumožňuje reinicializaci TLS uvnitř jednoho spojení.
    Reinicializace je věcí přímo SSL/TLS vrstvy, podpora ze strany „vnitřního“ protokolu není potřeba. Např. Apache to umí využít k tomu, že přístup k některým adresám nevyžaduje přihlášení klientským certifikátem, ale když se pokusíte přistoupit k cestě, která ho vyžaduje, vyvolá reinicializaci TLS a v nových parametrech už vyžaduje klientský certifikát. Samozřejmě to nefunguje, pokud je reinicializace spojení zakázaná (což se nějakou dobu dělalo, protože v tom znovuvyjednávání byla chyba umožňující na spojení zaútočit).