John Gilmore: příklady sabotáže bezpečnosti lidmi z NSA

John Gilmore analyzoval a zveřejnil situace, kdy lidé z NSA přímo sabotovali bezpečnost navrhovaných protokolů nebo standardů. Ve své zprávě se zaměřil obzvláště na IPSEC, které je vinou NSA příliš složité, potenciálně náchylné k útokům a chybí v něm drobnosti zlepšující bezpečnost kvůli návrhům na "zjednodušení", které přišly od NSA. Dále pak poukazuje na lhaní lidí z NSA, pomocí kterého sabotovali vznik účinného standardu pro end-to-end šifrované hovory v mobilní síti.

8.9.2013 12:46 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[bugme]

Aneb typek co se snazi prizivit na aktualni situaci. Podle me je to zm*d, protoze to mel zverejnit uz davno.

[not]

+1

IMHO je to lhar snazici se zviditelnit, NSA by takovou blbost tezko udelala, cele je to nesmysl

[kolmejdouci]

Cetli jste to vy dva? Nahodou to presne dava smysl, vse to krasne zapada. Vase komentare obsahuji jen spinave argumentacni praktiky, prinaseji nulovy prinos. Take by me zajimalo pro koho pracujete.

[xm]

Obvious troll is obvious.

Btw. kdybyste to náhodou nevěděl, tak John Gilmore je zakladatel EFF, ten se fakt zviditelňovat nepotřebuje Nebýt EFF, tak je USA dnes ještě v mnohem větší prdeli (totalitě) než dnes.

[b4aa9]

Nepracujes nahodou pro NSA?

[asdfadsfadsf]

Nejses nahodou debil?

[kolmejdouci]

oh

[b4aa9]

Ne, ty?

[Petr Tomášek]

Nepracuješ náhodou pro Putina?

[gg]

Svet neni cerveno modry, tomasku

[b4aa9]

Primo pro Putina ne.

[frdrx]

Ale fuj.

[Luk]

Jsem si říkal, proč je SELinux tak neskutečně složitý...

[bronie]

Asi už si toho všimli: http://fedora.cz/nove-bezpecnostni-vlastnosti-ve-fedore-20-cast-1-setroubleshoot-integrace-s-journald/ . I když pokud to neni vyhánění bláta louží, nebo jak se to řiká.

[Lol Phirae]

Vypnout SELinux je furt ještě univerzální řešení, které je nutno zkusit jako první. No nic, o "bezpečnost" od NSA jsem stejně nikdy zájem neměl.

[pavlix]

Už jsem to psal dříve, ale IPsec mi jako sada základních protokolů připadá až vzácně jednoduchý. Jsou to reálné implementace jednotlivých částí, které mi připadají často zbytečně komplikované, pak různá rozšíření z dílny Cisco a přílišná univerzálnost ISAKPM, kterou podle mě dobře řeší IKEv2.

[pavlix]

*ISAKMP

[frr]

Byl jsem v průběhu let několikrát nadřízenými přinucen zabývat se IPSecem (nakonfigurovat a rozchodit, žádná složitá teorie nebo bezpečnostní rozbory) a podle mých praktických uživatelských zkušeností jsou jednotlivé konkrétní implementace nejen navzájem obvykle nekompatibilní, ale často mají ohavné bugy (obecně nahnilost) i v homogenním prostředí = často to nefunguje použitelně ani "samo se sebou", tzn. shodný software ve shodné verzi na obou koncích. Po pár pokusech jsem odmítl s tím dále ztrácet čas a pokud chce někdo stabilní a konfigurovatelnou VPNku, doporučuji OpenVPN. Dosud jsem tuto mizernou použitelnost IPSecu přičítal obecně "designed by a committee", viz. např. obvyklá absence virtuálních rozhraní zakončujících tunel (fuj! jak jde tohle dohromady se základními principy vrstveného síťování? Není divu, že se to blbě implementuje do konkrétních OS a je to náchylné na rozbití při updatech síťového stacku hostitelského OS.) Teď mám o důvod víc, chápavě se usmívat, nebo spíš pošklebovat

[pavlix]

Popravdě řečeno, ač se v mnohém shodujeme, bych část problémů spíše přisoudil nezájmu (některých) implementátorů o interoperabilitu, korekce a další vývoj protokolů. To je typické pro relativně volně navržené protokoly, kde hlavními implementátory jsou komerční subjekty, které nejsou nijak tlačeny k interoperabilitě.

Návrhově se mi dnešní IPsec líbí stokrát více než nějaká OpenVPN, což ovšem neznamená, že není co zlepšovat. Prakticky za současného stavu OpenVPN používám, ale chtěl bych se ji ve prospěch IPsecu zbavit.

[R]

Skusenosti mam podobne. OpenVPN sa jednoducho nastavi a funguje. K IPSecu existuje milion implementacii, pricom jedna je horsia ako druha. Takze si jednu vyberiem, rozchodim a nejako to funguje. Potom zistim, ze to raz za tyzden vypadava a nevie to nikto vyriesit...

[melkors]

Plny souhlas, s IPSec prachbidne vysledky, s OpenVPN jen nejlepsi zkusenosti - proste funguje (tedy do doby, kdy nejaky matlak po ceste zakaze strasne nebezpecne UDP pakety ...)

[frr]

Mezi pobočkami (LANkami) co mají veřejně číslovaná venkovní rozhraní na mých routerech jedu UDP, ale remote klienty obsluhuji přes TCP. A pokud se na straně remote klienta vyskytne nějaká důkladněji zabezpečená LANka ve smyslu "least privilege" i směrem ven, která pustí třeba jenom maily a HTTP/HTTPS, tak docela dobrý způsob průchodu firewallem je posadit OpenVPN "server" na port 443. Firewall to považuje za HTTPS, takže pokud to chce pustit ven, musí to pustit rovnou, protože nemůže do SSL zasahovat (transparent proxy/cache/filter). Takže je úplně jedno, že uvnitř toho SSL žádné HTTP neběží

[pavlix]

Firewall to považuje za HTTPS, takže pokud to chce pustit ven, musí to pustit rovnou, protože nemůže do SSL zasahovat (transparent proxy/cache/filter). Takže je úplně jedno, že uvnitř toho SSL žádné HTTP neběží

V naprosté většině případů tomu tak skutečně je.

[Heron]

Firewall to považuje za HTTPS, takže pokud to chce pustit ven, musí to pustit rovnou, protože nemůže do SSL zasahovat (transparent proxy/cache/filter). Takže je úplně jedno, že uvnitř toho SSL žádné HTTP neběží

Tím už si dnes bohužel nikdo nemůže být jist, protože se rozšiřují krabičky, které umějí udělat MITM na https. Někde už berou jako standard mít na všechno aplikační proxy (už jsem viděl i na ssh, zasahovala do možností autentizace).

[frr]

Ale no fuj... je vidět, že jsem delší dobu mimo obor...

[Kvakor]

Používají certifikáty, které jsou podepsané od nějaké certifikační autority, běžně přítomné v prohlížeči? Pokud ano, tak je to další důvod proč u HTTPS kotrolovat certifikát i pokud prohlížeč nic nehlásí.

Ale u OpenVPN by takový MITM téměř určitě nefungoval, vhledem k mechanismu handshake, který je velmi odlišný od HTTP.

[Heron]

Používají certifikáty, které jsou podepsané od nějaké certifikační autority, běžně přítomné v prohlížeči?

Ano.

Pokud ano, tak je to další důvod proč u HTTPS kotrolovat certifikát i pokud prohlížeč nic nehlásí.

Tak to by měl být u SSL základ, ovšem jsou servery, které se tomu důkladně brání. Doporučuji nainstalovat rozšíření Certificate Patrol a potom jít třeba na Google. Co server, to jiný certifikát. V takovém prostředí se toho moc ověřit nedá.

[pavlix]

Ale u OpenVPN by takový MITM téměř určitě nefungoval, vhledem k mechanismu handshake, který je velmi odlišný od HTTP.

Vzhledem k mechanismu handshake? To bych si nechal vysvětlit :).

[Kvakor]

Zatímco HTTPS je obyčejné bezstavové HTTP zabalené do SSL/TLS, tak komunikační protokol u OpenVPN posílá kromně datových paketů (typ P_DATA) i binární řídící sekvence trochu podobné těm u TCP protokolu (typy P_CONTROL* a P_ACK). Jenže aby mohl hadshake proběhout, musí "MITM krabička" na jednom konci (směrem ks serveru) hrát OpenVPN klienta a na druhém (směrem ke klientovi) zas OpenVPN server, což naprosto jiná úloha než transparentní HTTP proxy. Pokud by ona krabička neuměla OpenVPN protokol a neměla příslušné klíče, bude jí pozměněná komunikace hned ze začátku ukončena jako chybná a zahozena.

[pavlix]

Díky za vysvětlení. Nicméně mi přijde, že teď zaměňuješ téměř určitě nefungoval a dělalo by se to mírně odlišně (první z toho je tvůj výrok, to druhé je mé shrnutí tvého předchozího komentáře).

[frr]

Děkuji za zajímavý a zasvěcený komentář

[Juraj]

Nie je to nahodou tak ze OpenVPN pouziva vlastny certifikat "certifikacnej autority" ktory musite bezpecne rozdistribuovat po klientoch? Bez tohto certifikatu MITM neprichadza do uvahy, lebo na rozdiel od HTTPS nemozno pouzit nejaku inu CA zo zoznamu "doveryhodnych".

[frr]

Popravdě používám automaticky self-signed CA certifikát, takže jsem ho přesně jak popisujete musel rozkopírovat na klienty. Měl jsem pocit, že by to mělo chodit i přes veřejně dostupné a uznávané CA (protože to jede nad OpenSSL, měl jsem dojem, že PKI je tímto použitelné) ale nijak jsem to nezkoumal/nezkoušel.

Pokud chcete používat certifikáty podepsané nějakou veřejnou CA, to by mělo chodit, ne? Potřebujete kořenové certifikáty autorit, kterým chcete důvěřovat - ty se dají pořídit. Počkat... nemohu najít žádný example, kde by instance OpenVPN vzala víc kořenových certifikátů. No a pak musí mít server svůj privátní klíč a certifikáty všech klientů, a jednotliví klienti musí mít každý svůj privátní klíč a certifikát serveru. Ono vůbec to rozlišení klient/server je u OpenVPN dost umělé, krypto-střeva jsou spíš peer to peer (rozhodně na UDP), záleží na faktickém uspořádání provozu a konkrétních vedlejších konfiguračních opšnách (které činí život v client/server uspořádání snesitelnějším). Prostě každá strana potřebuje znát svůj privátní klíč a od protistrany mít certifikát (= její veřejný klíč podepsaný oboustranně uznávanou CA) aby asymetrická šifra mohla frčet.

Popravdě jsem našel jednu nebo dvě hlášky na "cizích" webech, že veřejné CA se k tomuto nedají používat, ale popravdě moc nevidím důvod... Je fakt, že všecky tutorialy k OpenVPN obsahují popis, jak nakonfigurovat svou vlastní CA, ale nikde tam není informace, že by se nedala použít některá veřejná autorita, pokud Vám stojí za to nechat si vystavit certifikáty na všechny svoje veřejné IP adresy (nebo na co vlastně).

Těžko se do toho může svévolně připojit nějaký cizí "klient", pokud náš "server" nemá v konfiguraci certifikát tohoto klienta... A těžko může někdo napodobit některého nakonfigurovaného klienta, pokud nezná jeho privátní klíč.

Že to nikdo nepoužívá, to ještě neznamená, že to technicky nejde

[Ivan]

I IPSECu jsem narazil, kdyz jsem se chtel pripojit z Linuxu. Uz si nepamatuju na detaily, ale problem byl v tom, ze vytvareni tunelu ma tri faze a je castecne "volitelne" co se v prvni fazi stane. Nas VPN koncentrator odmital spojeni, ktera v te prvni fazi delala "neco". To "neco" co se pozdeji ukazalo jako bezpecnostni problem v navrhu protokolu.

Navic cely hyperslozity IPSEC byl primarne nazvren k tomu aby se navzajem propojovaly site. Uzivatele se k VPN muzou prihlasovat heslem pres RADIUS a Cisco k tomu pridalo svoje proprietarni rozsireni, ktere umoznuje navic pridat autentizaci pres X509 certifikaty.

PS: Cisco IPSEC client ma v Linuxu vlastni virtualni inteface, bohuzel se jeho modul da jen velice tezko prelozit s aktualnium kernelem. Ta vec "navtrdo" prepise jeden pointer na funkci primo v kernelu a tim si zajisti, ze zacne "krast" packety svemu nadrazenemu eth rozhani. Kdyz zjisti, ze danny packet neobsahuje IPSEC data tak zavola "dorucovaci" funkci eth interface, jinak packet zpracuje sama. Navic ta vec uplne umyslne ignoruje routovaci tabulku.

[pavlix]

U IPsec je potřeba rozlišovat konkrétní protokoly a jejich verze, jinak to dopadne tak, že deset lidí bude každý tvrdit něco jiného a všichni budou mít pravdu ;).

Linuxový IPsec a vlastní policy table bez virtuálních rozhraní je rovněž docela hezký nápad, ale musí se s tím člověk chvilku smiřovat :).

[Honza Jaroš]

Linuxový IPsec a vlastní policy table bez virtuálních rozhraní je rovněž docela hezký nápad, ale musí se s tím člověk chvilku smiřovat :).

Na druhou stranu není problém si v případě potřeby virtuální rozhraní nad tím IPSecem udělat (ipip, sit, gre...) a tlačit provoz přes něj. Mimochodem, pokud se nepletu, virtuální rozhraní není nutně potřeba ani ve Windows, ne, tam se také nechají nastavovat politiky samostatně...

[Honza Jaroš]

Oprava: ...ani ve Windows, ne? Tam...

[frr]

Ano. Někdy v roce 2001 jsem absolvoval "necertifikované" školení na IPSec od Cisca u Alefu a tohle byla "doporučovaná best practice" = natáhnout si GRE tunely a ty zašifrovat IPSecem.

[Honza Jaroš]

A to je špatně? Když si člověk může zvolit typ zapouzdření a to, jestli vůbec je zapotřebí?

Jak už psal pavlix, problémy s IPSecem, které jsem řešil, byly vždycky v nekompatibilitách mezi implementacemi. Virtuální rozhraní mi v tomto kontextu přijde jako trivialita, kdo ho potřebuje, ten si ho nastaví...

[frr]

Ale jo, o tom žádná... spíš mi vadí, že tam je pořád v principu nějaký prasohack, který nějakým způsobem obchází standardní IP routing stack (viz KPTD), tzn. popírá logiku forwardování provozu mezi rozhraními. Když si vezmete KPTD (což údajně ještě není kompletní obrázek), odkud se přesně ty pakety mají "správně" ztrácet resp. kde se mají objevovat? Kde u lokálně zakončeného provozu, a kde u procházejícího provozu? Správně podle mého tam taková věc nepatří. Pokud ji tam někdo dodělá, musí to kamsi nějakým nestandardním způsobem naprasit. Jak moc je tahle prasárna stabilní v proudu příštího vývoje kernelu... (a to nemusíme mluvit zrovna o Linuxu). Je tu nějaké vnější ABI, které se lidi od kernelu snaží držet stabilní. Pak je tu řada interních kernel API, která jsou taky jakž takž neměnná. Ale tohle snad nemůže respektovat ani interní API. Pravda je, že už jsem IPSec třeba zrovna v Linuxu dlouho nezkoumal, a třeba zrovna v Linuxu by se nějaký háček dal napsat jako modul do Netfiltru... ale zase: jak si netfilter poradí s paketem, který se objeví "odnikud"? Kde je nějaká stateful inspection, kde je nějaké zdrojové rozhraní... ten paket nemůže mít žádnou košer interní historii v rámci kernelu... a dost, už vařím z vody.

[pavlix]

Ale jo, o tom žádná... spíš mi vadí, že tam je pořád v principu nějaký prasohack, který nějakým způsobem obchází standardní IP routing stack (viz KPTD)

Rád bych tě upozornil, že slovo prasohack může být jen vyjádřením toho, že něčemu nerozumíš nebo že se ti to z nějakého důvodu nelíbí, a tudíž nemá žádný technický význam a neříká nic o vhodnosti či nevhodnosti daného architekturního rozhodnutí.

Když si vezmete KPTD (což údajně ještě není kompletní obrázek), odkud se přesně ty pakety mají "správně" ztrácet resp. kde se mají objevovat?

Dobrá poznámka. Zdá se, že KPTD něco chybí :).

Správně podle mého tam taková věc nepatří.

Musím říct, že tvůj názor naprosto chápu a že můj první dojem byl stejný. Nicméně při bližším zkoumání architektury IPsec jsem ho docela rád pozměnil.

Pokud ji tam někdo dodělá, musí to kamsi nějakým nestandardním způsobem naprasit.

Toto už bych si dovolil označit za mlácení prázdné slámy, protože takový výrok můžu říct očemkoli, co se kdy v kernelu přidá.

Navíc si člověk sejme ideologickou čapku a podívá se na síťování v kernelu, tak si musí nutně uvědomit, že většina věcí je v síťovém stacku nějakým způsobem doprasená a velká část z nich ještě špatně. A právě kvůli zmíněné stabilitě chování (API/ABI jsou v tomhle případě zbytečně detailní pojmy) ty věci často špatně musejí i zůstat.

ten paket nemůže mít žádnou košer interní historii v rámci kernelu... a dost, už vařím z vody.

Přitom zde není z vody vařit potřeba. Stačí se podívat třeba na iptables a na to jaké atributy paketů iptables nabízejí ke kontrole či úpravě a můžeš identifikovat, které z nich ti připadají z hlediska IPsec podezřelé a od nich se dá to vyjasňování začít.

Další možnost je provnat celou situaci s userspace VPN pomocí tun/tap rozhraní, kde se pakety podobným způsobem z pohledu kernelu „ztrácejí“ a „objevují“ (konec konců podobně funguje i reálný síťový hardware).

Nakonec ti z toho vypadne úplně jiná otázka a to, kdy se paket objevuje zapouzdřený a kdy nezapouzdřený (popřípadě kdy se ti objeví obě verze paketů, což umí krásně prozradit tcpdump). Pak má smysl hodnotit sprasenost konkrétní implementace a stejně tak i samotná možnost rozumné implementace tohoto modelu.

A je dobré nezapomínat na IPsec transport mode.

[frr]

Navíc si člověk sejme ideologickou čapku a podívá se na síťování v kernelu, tak si musí nutně uvědomit, že většina věcí je v síťovém stacku nějakým způsobem doprasená a velká část z nich ještě špatně.

To jste mi potvrdil jeden můj dost častý dojem Když se občas do zdrojáků kernelu ze studijních důvodů ponořím, nalézám věci v tomto duchu. Ale zatím jsem se díval jenom na pár velice úzkých a okrajových oblastí.

Další možnost je provnat celou situaci s userspace VPN pomocí tun/tap rozhraní, kde se pakety podobným způsobem z pohledu kernelu „ztrácejí“ a „objevují“ (konec konců podobně funguje i reálný síťový hardware).

Tohle jsem asi nepochopil. Tady mi to právě přijde, že tun/tap je dobře definovaný a stabilní způsob, jak si vytvořit síťové rozhraní. Virtuální, ale jinak po všech stránkách košer. Transport mezi tímto rozhraním a "protějším koncem" na jiném stroji je implementovaný nějakým automagickým démonem v user space, který mne z hlediska čistoty a elegance KPTD (já vím, "ehm ehm") nijak neuráží. V user space ať si páchá kdo chce co chce. Navíc se OpenVPN v tomto případě vůči kernelu tváří jako vcelku konzervativní subnet resp. L2 médium (konfigurovatelně point to point nebo multi-exit).

A je dobré nezapomínat na IPsec transport mode.

Ano, to je taky dobrý parazit. Tady uhnu od tématu: je to jedna z věcí, proč mám instinktivně smíšené pocity z příchodu IPv6 (jakožto správný IPv4 zpátečník). Ale pokud se v rámci IPv6 povede zařídit bezvadnou interoperabilitu IPSecu mezi implementacemi, tak proč ne... vlatně o tu mi jde především.

Opravdu už mluvím dost z cesty, vynáším subjektivní soudy a nemám to podložené studiem zdrojáků. Děkuju za zajímavou debatu

[pavlix]

Tohle jsem asi nepochopil. Tady mi to právě přijde, že tun/tap je dobře definovaný a stabilní způsob, jak si vytvořit síťové rozhraní.

Kernelový kód až tak nutně tun/tap nepotřebuje, ty existují především kvůli zpřístupnění userspace implementací.

V user space ať si páchá kdo chce co chce.

To, že IPsec je dobře implementovatelný v kernelu bych viděl rovněž jako výhodu. Z userspace se to celé nakonfiguruje a udržuje, o balení a šifrování se postará kernel. Podobný model se aplikuje na mnohé další věci.

Ano, to je taky dobrý parazit.

Transport mode mi přijde na celém IPsec nejgeniálnější část. Tunelový mód, to je prostě další implementace šifrovaného propojení sítí (VPN), ale transport mode je skutečným krokem kupředu, byť zatím nedoceněným, protože umožňuje řešit zabezpečení na optimální úrovni, tedy v rámci operačního systému a pod transportními protokoly.

Ale pokud se v rámci IPv6 povede zařídit bezvadnou interoperabilitu IPSecu mezi implementacemi, tak proč ne... vlatně o tu mi jde především.

Jenže interoperabilita vyžaduje mnohem víc snahy a přemýšlení než splácat jen tak nějakou implementaci ;). V praxi je IPsec v tomto ohledu značně nedospělý. Na druhou stranu OpenVPN není směrem ven interoperabilní prakticky vůbec.

[frr]

Máte pravdu, že OpenVPN je kompatibilní "jenom sama se sebou". Zato je ale snadno dostupná vedle Linuxu taky pod Windows, MacOS, FreeBSD/OpenBSD, snad jsou i nějaké další porty. Protože je to projekt oddělený od kernelu (běží v user space), běží tatáž verze napříč platformami. A co mě překvapilo nejvíc, moje staré jednoduché konfigurace z verze 2.0.9 jsou kompatibilní se všemi novějšími verzemi (aspoň v tuto chvíli - nejnovější je tuším 2.3.2) a běžící instance OpenVPN různých verzí jsou s těmito konfiguracemi kompatibilní navzájem provozně.

Popravdě se taky opatrně těším na utopickou ideální budoucnost na podvozku IPv6, kde nebude NAT, a půjde telefonovat "každý s každým" bez potřeby supernodů apod. Nevím, jestli se toho dožiju. Na jedné straně šifrování v transportním režimu sice skryje o čem se dva spolu baví, ale neskryje samotný fakt, že dvě konkrétní koncové stanice se spolu baví (neexistují privátní adresy). Jasně, security by obscurity... Na druhé straně jste mi tu právě vysvětlili, že opravdu pedantský proxy firewall se neštítí provádět MITM na SSL relacích. Čili zabezpečené firemní LANky nám tu komunistickou utopii stejně trpět nebudou. Cannot have your cake and eat it too. Telefonování "každého s každým" si můžeme provozovat na drobné individuální konektivitě doma nebo na mobilech, pokud nám to operátoři dopřejí.

[pavlix]

Protože je to projekt oddělený od kernelu (běží v user space), běží tatáž verze napříč platformami.

Nekernelová implementace má své nesporné výhody (a stejnětak i nevýhody, stačí si uvědomit, že TCP/IP by mohlo být rovněž implementováno v userspace).

Popravdě se taky opatrně těším na utopickou ideální budoucnost na podvozku IPv6, kde nebude NAT, a půjde telefonovat "každý s každým" bez potřeby supernodů apod.

Ono je lepší si mimo laboratoř nestavět utopické scénáře, pokud se chceš internetem nějak vážně zabývat.

Na jedné straně šifrování v transportním režimu sice skryje o čem se dva spolu baví, ale neskryje samotný fakt, že dvě konkrétní koncové stanice se spolu baví (neexistují privátní adresy). Jasně, security by obscurity...

Interpretovat tuto vlastnost (na které mimochodem přepnutí na tunelový režim nic nemění) jako security by obscurity, to zavání, že se diskuze začíná zvrhávat ve snůšku nepromyšlených a nepodložených keců a to bych nerad.

Na druhé straně jste mi tu právě vysvětlili, že opravdu pedantský proxy firewall se neštítí provádět MITM na SSL relacích. Čili zabezpečené firemní LANky nám tu komunistickou utopii stejně trpět nebudou.

Zde už se to skutečně zvrhává ve žvásty™.

[Petr Bravenec]

Nevím, jestli pojmem "prasohack" narážíte na fakt, že se rozšifrované pakety vaší "vnitřní" sítě objevují na "vnějším" síťovém rozhraní a vám se to v iptables špatně rozeznává. Taky jsem s tím měl problémy, než jsem pochopil, proč to tak je. Mějme dvě přes internet propojené sítě:

Síť X - Router A ==== internet ==== Router B - Síť Y

Vás, jako IPv4 zpátečníka samozřejmě napadne adresovací schéma takto:

10.20.1.0/24 - Router A ==== internet ==== Router B - 10.30.1.0/24

Jenomže to obvykle nepropojujete dvě sítě, to snažíte se znásilnit IPSEC na propojení dvou sítí, které na sebe nevidí.

Ono to má být totiž správně třeba takto: 2001:aaaa:aaaa:aaaa/64 - Router A ==== internet ==== Router B - 2001:bbbb:bbbb:bbbb/64

Výše uvedené schéma funguje bez IPSEC i s IPSEC a IPSEC je tam skutečně k tomu, k čemu je určeno - k zabezpečení přenosu mezi body A a body B. Politikou v IPSEC řeknete prostě jen to, že mezi A a B se má šifrovat.

Opravte si své uvažování a namalujte si toto jednoduché schéma podle skutečnosti: 10.20.1.0/24 - NAT A ==== internet ==== NAT B - 10.30.1.0/24

A teď se poctivě zeptejte sám sebe, která část je prasohack.

[frr]

Souhlas, díky za vysvětlení

[Ondrej 'SanTiago' Zajicek]

Ono je v tom hlavne terminologicke zmateni, kdy IPSec tunnel mod nedela (a ani neni zamyslen delat) to, co lide ocekavaji od l2 ci l3 tunelu (napr. GRE ci IPIP ci zminovane OpenVPN) - tedy plne virtualni a logicky oddelenou 'trubku'. Pokud clovek chce skutecny tunel, tak je GRE ci IPIP chraneny IPSec transport modem asi optimalni volba.

BTW, jsou i jine duvody, kdy je treba nasadit l2 ci l3 tunely, nez jen vyuziti privatnich adres - napr. kvuli agregaci rout v globalnim Internetu.

[pavlix]

Pokud clovek chce skutecny tunel, tak je GRE ci IPIP chraneny IPSec transport modem asi optimalni volba.

+1

A při dekompozici nakonec dojde k tomu, že ten paket i vypadá tak, jak vypadat má.

[SKK]

Myslíte si, že seriál Gilmorova děvčata byl podle skutečných událostí, které teprve mají nastat a pan Gilmore je John Gilmore?