Vlákno názorů k článku Šifrované SNI lepí díru do soukromí, jako první ho bude umět Firefox od MP - Zasifrovane SNI je cesta do pekel. Jak webserver pozna,...
-
MP (neregistrovaný)
Zasifrovane SNI je cesta do pekel.
Jak webserver pozna, ke ktere domene (a certifikatu) to ma sparovat?
Jak reverzni proxy pozna, ke ktere domene (a certifikatu) to ma sparovat?To budeme snad muset prejit na 1 IP per domena, 1 balancer per domena apod?? ...
Jedine reseni co vidim, je proste navazani sifrovaneho spojeni bez nutnosti manualni verifikace (viz defaultni overeni u ssh, oproti treba ssl u postgresql) s tim, ze certifikaty by byly volba navic servery, ne nutnost.
-
Filip JirsákStříbrný podporovatelDoporučuju přečíst si článek, který komentujete. Webserver i reverzní proxy to poznají tak, že ESNI prostě rozšifrují vlastním privátním klíčem. Veřejný klíč příslušný k tomu privátnímu klíči bude v DNS.
-
MP (neregistrovaný)
V tom pripade je ale certifikat uz zbytecnost pro vetsinu webu. Stacil by ten klic. Nebo budeme mit vicefazove rozsifrovavani klice za klice po certifikat (kdyz to prezenu, az se objevi dalsi dira).
Jak pisu, chtelo by to cely system zjednodusit podobne jako u postgresql:
1] zakladni sifrovani out of box
2] certifikat nadstavba pro ty, co ho potrebujiZmizela by tim veskera slozitost kolem DV certifikatu - javovske keystory, ruzny format pro kazdou app, apod.
A sitove debugovaci nastroje prestanou fungovat.
-
Filip JirsákStříbrný podporovatel
V tom pripade je ale certifikat uz zbytecnost pro vetsinu webu. Stacil by ten klic.
Ano, na to jsem narážel už ve svém včerejším komentáři na začátku diskuse.1] zakladni sifrovani out of box
2] certifikat nadstavba pro ty, co ho potrebuji
Když chcete šifrovat, musíte vědět, s kým komunikujete. Musíte tedy získat důvěryhodnou cestou veřejný klíč protistrany – dnes ho získáte z certifikátu, je možné ho získat i z DNS (zabezpečeného DNSSEC). -
j (neregistrovaný)
2MP ... kdysi davno (v pripade IPv6 nekdy v roce 1995) bylo napsano RFC, ktere predpokladalo (dokocne povine) ze soucasti Ipv6 je sifrovani ... prave IP protokolu.
Dokonce je to vymysleno tak, ze existujou dva rezimy - jeden, urceny prave pro libovolnou komunikaci kohokoli s kymkoli, a druhy, fungujici jako tunel, pri kterym sou zasifrovany ... i ty IPcka.
Cas z toho bylo nasledne backportovano i do IPv4 - samo s omezenima ktery Ipv4 ma.
Ale neni nad to vymejslet pro kazdej aplikaci protokol sifrovani zvlast, a zvlast pro kazdou jeho soucast.
-
MP (neregistrovaný)
Ohledne ipv6 to vim, ale je to i tak kostrbate.
Co se tyce sifrovani per app, tak vetsina pouziva stejne sifrovaci knihovny nad napr. openssl apod. A urcite je lepsi, kdyz kazda app ma svuj protokol, nebot jeden obecny nebude vyhovovat vetsine app - muzu se plest, ale pokud ani s ipv6 nevyuzivaji app schopnost ipv6 a sifrovani, tak k tomu nejaky duvod byt musi (krome prepsani casti kodu).
-
j (neregistrovaný)
Jakej vlastni protokol proboha ... pokud se sifruje komunikace na IP, tak je tomu uplne uprdele co pouzivas za protokol, jestli je to ftp nebo http, nebo sip nebo cokoli jinyho. Kdyz prijdes s vlastni aplikaci a vlastnim protokolem ... tak to proste bude samo od sebe sifrovat a nemusis nic resit.
Zato ted kazdej implementuje vlastni hovadiny a vlastni diry. Viz SNI ktery nikdy nemelo vzniknout nebo viz NAT kterej (mimo jiny) prave end to end sifrovani efektivne nabourava.
-
pb. (neregistrovaný)
Není to kostrbaté. Se zákazníky, jejichž sítě spravujeme a kde máme k dispozici iPv6 (většina), komunikujeme jedině tímto způsobem. Stejně tak se všemi vlastními servery. Pro admina je to jen trochu práce navíc. Pro uživatele je to zcela transparentní, nic nepoznají. Mezi sítěmi pak můžu používat třeba telnet, je to jedno. Zabezpečená je už IP vrstva. Nad tím pak běhají všechny ty ostatní protokoly (telnet, ssh, http, https....)
Neštěstí je, že člověk si s IPv4 kolikrát ani neuvědomuje, jak moc deformuje IPv4 jeho uvažování. S IPv4 by takové řešení nikoho nenapadlo, protože: - počítače na sebe navzájem nevidí - ISP mu nedal věřejnou IP - ISP mu mění veřejnou IP - IPS mu nenastavil nat - lokální správce neumí nastavit nat - nat mu shazuje stavová spojení - při použití vpn se sejde x desítek sítí 196.168.1.x a je složité nastavit nat na vpn přes nat - když nastavíte nat/vpn/nat, nesedí vám certifikáty na ip - ...cokoliv si vymyslíte buď nefunguje, nebo je to strašně kostrbaté.
-
Petr M (neregistrovaný)
Souhlasím. Šifrovat na IP vrstvě se dá - a IPSec to dělá - jenom dvěma způsoby.
První je šifrování paketu bez hlavičky, ale pokud se hlavička změní (třeba NATem - pravděpodobnost na IPv4 99,99%), nedešifruje to. V IPv6 není problém, zdroj a cíl se vidí a znají svou skutečnou IP adresu, se kterou se baví. V IPv4 neřešitelný mimo situace, kdy jsou na stejné LAN (takže maximálně jako ochrana WiFi).
Druhý způsob je vzít celý paket včetně hlavičky a přepravit ho. Jenomže pokud tam je NAT, tak klient vidí z DNS, že server je na 1.2.3.4 a komunikuje 192.168.1.25->1.2.3.4 Serveru s adresou 10.11.12.13 přijde paket od 100.110.120.130 a po dešifrování je v hlavičce 192.168.1.25->1.2.3.4. Takže to fakt bez rovnáků na ohybáky (= dohody, kdo s kým se vlastně baví stylem VPN a fejkování adres) taky fungovat nebude. Tím dohadováním a zdvojením hlaviček se akorát zvyšuje složitost, traffic a zátěž systému. A ani tohle nejde přes dva CGNATy.
No a proto se šifruje každý pšouk extra. IP vrstva předává binární blob (ale té je to jedno, obsah dat neřeší) a jak se popasuje s NATem je její problém. A vyzvoní se víc, než při IPsec - porty, služba,...
-
Petr M (neregistrovaný)
Security by obscurity není security. Pokud teda náhodou nejsi tak geniální, jak skupina odborníků, která se specializuje na kryptografii a neuděláš chybu (pravděpodobnost tak 0,5ppm).
I když použiješ standardní šifrovací knihovnu, útočník musí ještě pochopit význam dat - no a na to potřebuje vidět efekt paketu (odejde, pokud uživatel stiskne Enter nebo po příchodu přibude záznam v logu) a mít těch dešifrovaných paketů hodně (aby mohl konvolucí identifikovat při stejným chování, co je stejný).
-
Filip JirsákStříbrný podporovatel
Jaké všechny ostatní aplikace? SNI je určeno pro jedinou aplikaci, a to HTTPS server, který na základě něj vybere správný certifikát. Firewall ani proxy ta hlavička nemá zajímat – a pokud jí někdo někde zkoumá, je to právě důvod, proč jí šifrovat.
-
Firewall ani proxy ta hlavička nemá zajímat – a pokud jí někdo někde zkoumá, je to právě důvod, proč jí šifrovat.
S tím se nedá souhlasit. Jsou provozy, ve kterých chce zaměstnavatel umožnit omezený přístup na internet a inspekci potřebuje provádět. Buďto se to řeší na firewall/transparentní proxy s využitím SNI. Nebo se to řeší běžnou proxy, ale ta pak nahrazuje certifikát za vlastní, dovnitř důvěryhodný. Podle mě varianta s proxy je daleko kontroverznější, než provádět inspekci SNI.
-
Filip JirsákStříbrný podporovatel
Pro omezený přístup nepotřebuje provádět inspekci. Stačí běžná webová proxy (případně SOCKS proxy), která žádný certifikát nenahrazuje – prostě povolí metodou CONNECT přístup jenom na vybrané adresy. Prostě stačí používat věci k tomu, k čemu byly navrženy.
ČLÁNKY DO MAILU