Vlákno názorů k článku Šifrované SNI lepí díru do soukromí, jako první ho bude umět Firefox od Ondřej Novák - A nešlo by k zašifrování použít jen ECDH...

  • Článek je starý, nové názory již nelze přidávat.
  • 25. 9. 2018 15:13

    Ondřej Novák

    A nešlo by k zašifrování použít jen ECDH a adhoc klíče?

    - jo vlastně nešlo, man in the middle by mohl navázat takto zašifrovaný kanál se mnou a zároveň s cílem a tím by si přečetl to SNI.

    - no ale napadlo mě, že by si pak cíl a já po výměně certifikátů a navázání plnohodnotného zašifrovaného kanálu zkontrolovali shared secret toho dočasného kanálu a pokud by se lišilo tak by se tím odposlech prozradil.

  • 25. 9. 2018 21:59

    Clovek (neregistrovaný)

    Prave ze ten MITM ti to prelozi - prijde puvodni klic - > posle svuj -> dostane spravnou odpoved -> posle svoji
    Pokud se chces vyvarovat MITM, tak proste ta osoba uprotred nesmi mit moznost, jak se do komunikace dostat.

    Co rikas ty je catecne resitelne pres HPKP. Ale pokud ten spravny klic neznas, tak mas proste smulu.
    Ziskani klice pres DNS vlastne dela pekny side chanel pro vymenu/overeni tajemstvi. Vyhoda tam je, ze na portu 53 vzdycky bezi DNS, a protokol je jednoduchy, takze neni problem s vyssimi funkcemi, jako u HTTP.

    Spravcum firemnich siti doporucuju opet rozdat psaci stroje, kdyz tak neveri lidem. Tam maji celkem jistotu, ze se uz nebudou dale vyvijet a jejich technicke reseni zustane po dlouhe roky nemenne. Aplikaci na FB jsem na psacich strojich jeste nevidel, takze mozna budou i efektivnejsi ;)

    Ze maji bezpecnostni slozky smulu je jen prijemny bonus.

  • 25. 9. 2018 23:53

    jouda (neregistrovaný)

    Pokud to skončí předáním alespoň serverového certifikátu, tak HPKP nebo jiný postraní kanál opravdu netřeba (ten už vytvořila CA), pro detekci na klientu stačí když přihodí privátním klíčem podepsanej ten původní ECDH klíč.

    Konkrétně HPKP bych se opravdu nepokoušel reinkarnovat, do věčných lovišť odešel naprosto zaslouženě (dlouhodobý DoS po kompromitaci serveru je dost nehezká věc)

    DNS... v nějakém paralelním Vesmíru, kde mají plnohodnotný DNSSEC u všech domén, kde se DNSSEC ověřuje zásadně na klientu, tak by to mohlo nějak fungovat.

    ad správci kteří nevěří svým lidem - pokud by se lidem "dalo věřit", tak není ransomware jednou z největších kyberhrozeb dneška, a zprávy o správcích, kteří svým lidem věřili se dost často dostanou i do mainstreamové televize.
    V jiných oborech je naprosto běžné a každý chápe, že bezpečnost je třeba budovat komplexně, že lidé i technika dělají chyby a je třeba nejen minimalizovat samotné chyby, ale také jejich následky. (proč musí mít auta ESP, airbagy, proč se kolem silnic dávají svodidla... to tak nevěří řidičům? Přesto nikoho soudného nenapadne navrhnout Škodovce, aby místo aut prodávala vycházkové hole...
    Proč musí být kolem díry na stavbě zábradlí, to se tak nevěří dělníkům že tam nespadnou? příkladů jsou mraky).

    A že mají bezpečnostní složky smůlu je celkem naivní představa, i kdyby bylo na jednom IPčku těch webů několik desítek, tak nemyslím že bude nějaký větší problém s celkem obstojnou pravděpodobností odlišit kam kdo leze třeba jen na základě analýzy velikosti a timingu paketů.
    (a to i bez oblíbených 3rd party scriptů, které se tahají panbůvíodkud, nebo reklam)

  • 26. 9. 2018 1:42

    Atlasz (neregistrovaný)

    Obstojny sifrovaci kanal riesi problematiku statistckej analyzy dat. Obycajne HTTPS ma ale od toho daleko.

  • 26. 9. 2018 8:41

    Clovek (neregistrovaný)

    Pokud to skončí předáním alespoň serverového certifikátu, tak HPKP nebo jiný postraní kanál opravdu netřeba (ten už vytvořila CA), pro detekci na klientu stačí když přihodí privátním klíčem podepsanej ten původní ECDH klíč.

    --- Ziskanim certifikatu z DNS mi prijde lepsi nez HPKP. Ale pokud chytnes celou komunikaci, tak tam muzes i nahradit ten podepsany ECDH klic (priklad, kdy ti nekdo narve svoji CA do systemu/prohli­zece). Dobra odpoved je kontrola certifikatu pres ty podepisovaci sluzby, tahle to asi nahradi dobre (pokud se opet nestane problem s MiTM).

    ad spravci...
    --- Souhlasim, ze kdyz se bude jen cekat na katastrofu, tak proste prijde. Jen podle me neni reseni overhead v aplikacich na security, ale pristup a zodpovednost kazdeho jednotlivce. Pokud bereme premisu, ze v aplikaci je chyba, ktera jde zneuzit utocnikem -> jakou mame jistotu, ze chyba neni v antiviru/firewallu co tomu ma predchazet. Pokud se jedna o rychlost "obrany", souhlasim, ze by bylo rychlejsi to globalne rezat na FW. Kazdopadne dokud do toho nekdo bude moci cumet, nekomu to bude vadit a bude vymyslet, jak do toho necumet... To uz pak muzeme rovnou na vsech FW zakazat 443, aby byla komunikace open. Ze vetsina webu nepojede smula -> ale virus cestou odhalime a nestahneme..

    ad security:
    --- Jasne, zustavaji posledni 4 metadata (IP1, PORT1, IP2, PORT2) , ktere se jednoduse resi nejakou cibuli (proxy, vpn, atd)

  • 26. 9. 2018 12:54

    jouda (neregistrovaný)

    --- Ziskanim certifikatu z DNS mi prijde lepsi nez HPKP. Ale pokud chytnes celou komunikaci, tak tam muzes i nahradit ten podepsany ECDH klic (priklad, kdy ti nekdo narve svoji CA do systemu/prohli­zece). Dobra odpoved je kontrola certifikatu pres ty podepisovaci sluzby, tahle to asi nahradi dobre (pokud se opet nestane problem s MiTM).

    Souhlasil bych s tím DNS za jiné situace (rozepisuju to někde výše, ale zkráceně pokud běžně dnssec nevaliduje klient ale resolver a většina SoHo routerů v cestě je děravá).
    Když mi někdo může narvat CA do prohlížeče, tak to že někde po cestě může dělat MitM je to poslední co je potřeba řešit, takže tuhle možnost bych vůbec na úrovni protokolu neřešil.

    ad kontrola na firewallu - tak nejchybnovatější článek není software, ale uživatel. Dělat kontrolu (i) na firewallu je logické - jde tam většina trafficu, dá se tam pustit nějaká virtualizace ve které se příchodí balast prvně pustí, tím že je to na jednom místě stačí když se každej file vyhodnotí jen jednou a pak se jen porovná hash, pravděpodobnost úspěšného napadení firewallu je mnohem nižší než alespoň jedné z několika tisíc stanic, ... Čímž netvrdím, že endpoint security je k ničemu.

  • 26. 9. 2018 12:26

    Ondřej Novák

    K té původní myšlence, ano, dokud není šifrovací kanál sestaven pomocí certifikátu, tak MITM může do komunikace zasáhnout. Ale spíš šlo o to, že jakmile je šifrování sestaveno pomocí certifikátu - což MITM nemůže nijak ovlivnit, pokud nezmění certifikát po cestě, ten ale není důvěryhodný, že - tak pak v rámci plnohodnotně šifrovaného kanálu, do kterého už MITM nevidí, by došlo ke kontrole šifrovacího klíče z toho úvodu a je jasné, že obě strany musí mít stejný ten klíč, že jo. No a pokud nemají, tak je to minimálně detekce toho, že v cestě sedí MITM

    Adhoc šifrování eliminuje MITM, který pakety pasivně sleduje, ale proti aktivnímu přeposílání dat ne, ale, pokud MITM ví, že se přesto o jeho existenci strany dozví, tak to útok MITM přeposílání paketů efektivně eliminuje