Dotaz: IPv6 a IPSec prakticky - jak na to a k čemu to?

[Radek Hladik]

Zdravím, zajímalo by mně, jak je na tom v současné chvíli IPSec (jako součást IPv6), k čemu se to prakticky dá použít a jaký je cca stav tak nějak obecně. Přečetl jsem adekvátní kapitolu v knížce pana Satrapy a udělal jsem si cca takovéto závěry:

• IPSec je povinnou součástí implementace IPv6, takže kterýkoliv rozumně nový linuxový server by neměl mít s IPsec problém.
• Na nejnižší (síťové) úrovni je potřeba mít nastavené SA (Security Associations) a pravidla pro filtrování (t.j. kde IPSec použít, kde ne, kde ho očekávat a kde vyžadovat).
• V současné době je zajímavá jen varianta ESP.
• Pro nastavení SA je potřeba separátní démon.
• Vcelku použitelné to bude pro udělání VPN - režim tunnel

Celé nastavování by nemělo být moc složité s vyjímkou nastavení autentizace. Jinak řečeno, pokud démon vyhodnotí příchozí požadavek OK po stránce ověření zdroje, pak už jde jen o "pár drobností" ve stylu zvolit šifrovací algoritmy, nějaké doby platnosti (očekával bych rozumné defaulty) a pravidla, pro které adresy je to IPSec povinný. Démon nahodí nějaké SA (de facto klíče a metodiku jejich použití) a kernel spokojeně bude (de)šifrovat, podepisovat a verifikovat.

Ale co by mě nejvíc zajímalo, jsem v knížce ani při googlování nenašel. Právě to ověření autentičnosti zdroje - v knížce je nakousnuto, že je možno použít certifikáty, že se nově pracuje na ukládání věcí do DNS, ale nebylo tam moc podrobností. Spíš než o vytvoření nějaké VPN (tedy vlastní CA nebo něco bez PKI) mi jde o problém, který IPSec slibuje řešit už od prvopočátku: ověření IP adresy komunikujícího partnera. Řekněme tedy, že mám pokusný server, kde bych chtěl nastavit IPSec tak, aby se kdokoliv, kdo se bude připojovat mohl ujistit, že komunikuje právě s tím serverem a s nikým jiným.

Existuje nějaká CA, která mi vydá certifikát pro mojí IP? Jak ověří, že jsem vlastníkem té IP? Bude to mít dostatečnou váhu? Přestože se okolo CA a PKI docela pohybuju, nezaregistorval jsem nějaké takové nabídky. Nebo se vyplatí počkat, až se udělá standard na ukládání do DNS a pak si nacpat do reverzní zóny informace?

Jinak řečeno, kromě použití na administrativně moje tunely, je to nějak prakticky použitelná technologie z globálního hlediska? Navíc se mi to zdá degradované tím, že se jedná sice o povinnou vlastnost implementace IPv6, ale téměř nikde nepoužitou - jak budu úspěšný, když u každé IPv6 komunikace nejprve ověřím, zda je cílová strana mi ochotna poskytnout (alespoň) nějaký certifikát?

---

---

Odpovědi

[petr_p]

Načrtl jste ideální stav. Skutečnost je, že PKI neexistuje, takže se IPsec používá jen pro vnitřní potřebu. A jinak si z vaší rovnice můžete IPv6 vypustit, protože se IPsec podařilo přidat to IPv4 dříve, než se nám rozšířilo IPv6.

[Michal Kubeček]

PKI v zásadě existuje. Problém je IMHO spíš v tom, že místo původní představy, že IPsec umožní komunikovat komukoli s kýmkoli autentizovaně (tj. vím spolehlivě, s kým se bavím) a šifrovaně (takže si to nepřečte nikdo třetí), aniž by to znamenalo, že si navzájem důvěřujeme, se praktické nasazení IPsec redukuje na klasické VPN (ať už síť - síť nebo jedined - síť), případně dvoubodové zabezpečené kanály. Potom to typicky znamená, že tomu, s kým se bavím bezpečně pomocí IPsec, zároveň automaticky důvěřuji a pustím ho ke svým službám; v takové koncepci si ale ověření musím dělat sám (přinejhorším pomocí vlasní CA) a není tam prostor pro nějaké nezávislé CA nebo dokonce opportunistic encryption.

[Radek Hladik]

Nu já měl na mysli právě něco jako je PKI pro SSL. Tedy že bych v systému měl předinstalované nějaké CA a od těch bych si mohl sehnat certifikát. Sice se mi takové řešení moc nelíbí, ale alespoň funguje. Proto jsem se i pídíl o možnosti si pro server pořídit nějaký certifikát, abych alespoň mohl autentizovat server vůči jeho klientům.

A já bych se nějaké CA nebál, pokud k ní budu mít důvěru. Třeba v Čechách takové komerční certifikáty jsou docela dost silná věc a pokud by CA měly nějaký inteligetní postup, jak ověřit IP... Ale to by opravdu fungovalo jen z pohledu serveru, těžko si budu vystavovat certifikát na mojí dialup adresu

[Michal Kubeček]

Nu já měl na mysli právě něco jako je PKI pro SSL. Tedy že bych v systému měl předinstalované nějaké CA a od těch bych si mohl sehnat certifikát.

Ale to samozřejmě můžete, dokonce i přesně ty samé. Jednou z možností ověření protistrany je i to, že máte seznam certifikátů autorit a za ověřeného považujete toho, kdo se prokáže certifikátem podepsaným některou z nich.

[Radek Hladik]

To že můžu, to vím. Ale směřoval jsem otázku tak trochu i k tomu, jestli to má smysl. Například Verisign nabízí de facto jen SSL, codesigning a trial certifikáty. Při googlování "IPSec Certificates" nenajdu jediný odkaz, který by na první pohled evokoval možnost si takový certifikát koupit. Takže tak nějak předpokládám, že i kdybych nějaký sehnal, tak ta CA nebude dostatečně rozšířeně důvěřovaná.

[Michal Kubeček]

Není žádný "SSL certifikát" nebo "IPsec certifikát". Oboje je prostě X.509 certifikát a je jen na vás, co s ním budete ověřovat. Je tam sice i nějaké pole na účel, ale takhle jemně se to nerozlišuje.

[pavlix]

Přesně tak, to celé o neexistenci PKI je nesmysl hned dvakrát. Jednou tím, že to není pravda, podruhé tím, že je dobré svěřit veškeré ověřování skupině ne zrovna důvěryhodných firem po celém světě.

[Radek Hladik]

S tím

Je tam sice i nějaké pole na účel, ale takhle jemně se to nerozlišuje

bych si dovolil silně nesouhlasit. Právě to pole jednoznačně určuje, za jakým účelem byl certifikát vydán. Klient je povinen odmítnout certifikát, který byl vydán pro jiný účel, než pro který certifikát ověřuje. Viz např. RFC:

If the extension is present, then the certificate MUST only be used for one of the purposes indicated.

konec konců i certifikát abclinuxu má nastaveno pouze:

Autentizace TLS webového serveru (1.3.6.1.5.5.7.3.1) Autentizace TLS webového klienta (1.3.6.1.5.5.7.3.2)

A ono je to logické, že vydavatel omezí použití certifikátu jen na něco. A to je to, co jsem měl na mysli tím, že jsem psal SSL certifikát, tedy "X509v3 certifkát s rozšířením pro použití pro SSL server". Ono totiž druhá stránka věci je, že technologicky můžou být ty certifikáty stejné, ale administrativní procedura ověření se může hodně lišit a to byl i důvod, proč jsem psal, že verisign nabízí jen SSL certifikáty a codesigning certifikáty, protože z heldiska použití i ověřování identity žadatele se jedná o různé certifikáty...

[Michal Kubeček]

Otázka je, nakolik je závazná ta "TLS WWW" část, tím spíš že (1) tam žádné jiná varianta pro autentizaci serveru není, (2) ty certifikáty se používají i k autentizaci jiných služeb než WWW a i pro SSLv3, nejen TLS. Takže jsem to vždycky bral spíš jako obecné ověření identity serveru.

[Radek Hladik]

Závazná je tak, že web browser připojujícíc se na https server by měl odmítnout certifikát, pokud v něm toto rozšíření není.

Co se týče toho ostantího tak pozor, jsou tu dvě důležité věci:

1) podstatné je, že tohle rozšíření (Extended Key Usage) vzniklo právě z důvodu, že původní Key Usage mělo jen předem definovaných pár bitů. Zatímco tady je to naprosto volné a v tom odkazovaném RFC jsou jen některé použití. Naopak vám nic nebrání si použití přidat vlastní, jako to například udělal IPSec, viz RFC:

(iso.org.dod.internet.security.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2) identifies an IPSec Usage Certificate for an end system.

(iso.org.dod.internet.security.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2) identifies an IPSec Usage Certificate for an intermediate system.

(o tom, kolik si jich přidal třeba micorosoft netřeba rozepisovat )

2) to rozšíření může být označneo jako kritické, pokud tak označené je, pak ho klient musí umět zpracovat se vším všudy nebo musí certifikát odmítnout. Takže pokud bude v použití neznámé OID a bude to označené critical, tak klient musí zahlásit chybu a certifikát odmítnout.

[Michal Kubeček]

Závazná je tak, že web browser připojujícíc se na https server by měl odmítnout certifikát, pokud v něm toto rozšíření není.

To je ale z hlediska toho, zda jsou ty certifikáty použitelné pro ověření identity protistrany u IKE, nezajímavé.

Pokud je ale už registrováno i specifické "key usage" výhradně pro IPsec, pak ho lze samozřejmě vzít do úvahy. Osobně mi ale rozlišování certifikátů pro web, pro IPsec a pro kdo ví kolik dalších služeb připadá silně kontraproduktivní. Tedy z pohledu uživatele nebo systémáka, z pohledu provozovatele CA je to samozřejmě vítaný zdroj příjmů (což je dost možná důvod, proč se taková věc zavedla).

[Radek Hladik]

Závazná je tak, že web browser připojujícíc se na https server by měl odmítnout certifikát, pokud v něm toto rozšíření není.

To je ale z hlediska toho, zda jsou ty certifikáty použitelné pro ověření identity protistrany u IKE, nezajímavé.

Tím jsem reagoval na:

Otázka je, nakolik je závazná ta "TLS WWW" část

K tomu:

Osobně mi ale rozlišování certifikátů pro web, pro IPsec a pro kdo ví kolik dalších služeb připadá silně kontraproduktivní. Tedy z pohledu uživatele nebo systémáka,...

Z hlediska uživatele vás netrápí, že někdo, kdo dostal certifkát, že vlastní doménu abclinuxu.cz se snaží vydávat za IP adresu 1.2.3.4? Je potřeba si uvědomit, že CA má (minimálně u nás) specifické, auditované a akreditované postupy, jak ověřovat komu co vydává. Proto se naprosto zásadně liší certifikát pro web server a třeba IPSec gateway, ikdyby na krásně měly shodné CN jméno. To že je to pro CA vítaný zdroj práce (=přijmů) je jasné, ale tak to v komerční společnosti chodí, něco za něco... Koneckonců pokud bude tržní tlak silný, je možné, aby CA vydala certifikát s více použitími současně.

[Michal Kubeček]

Z hlediska uživatele vás netrápí, že někdo, kdo dostal certifkát, že vlastní doménu abclinuxu.cz se snaží vydávat za IP adresu 1.2.3.4?

Jak jste na to, proboha, přišel? To je přece něco jiného. Z pohledu uživatele mi ale vadí, pokud pro svůj server budu muset platit extra certifikát pro každou (zabezpečenou) službu, kterou na něm budu chtít provozovat, přestože u všech půjde o ověření skutečnosti, že "je to server ten a ten".

[Radek Hladik]

platit extra certifikát pro každou (zabezpečenou) službu, kterou na něm budu chtít provozovat, přestože u všech půjde o ověření skutečnosti, že "je to server ten a ten".

Ale tady pozor, tady nejde o ověření, že je to server ten a ten... Tady jde přesně o ověření, že ten server má právo vystupovat v roli třeba webserveru pro tu a tu doménu. Což neznamená, že má právo přijímat poštu pro tu doménu nebo dělat IPSec koncentrátor nebo podepisovat kód pro danou doménu. Který konkrétní server tu službu dělá je poměrně nudný detail, stačí že se umí prokázat, že na to má nárok.

[Michal Kubeček]

Je mi líto, ale pořád v tom rozlišování nevidím žádnou zásadní výhodu. Tím spíš, že dokud budeme požadovat, aby CN certifikátu souhlasilo s FQDN serveru, tak to tak, jak tvrdíte, obecně ani fungovat nemůže. K tomu by se daleko spíš hodily podepsané SRV (MX) záznamy.

[Radek Hladik]

To je tím, že na to koukáte moc ze síťového hlediska. Ty certifikáty se vydávají na všechno možné a teoreticky je ta vazba na FQDN zbytečná. Resp. když se připojíte na web banky, který bude sice na jiném FDQN, ale bude mít správně vyplněné jméno banky pomocí Extended Validation, tak by to pro vás mělo být důvěryhodnější, protože víte, že získat EV není žádná legrace...

Ale plně rozumím tomu, co říkáte, je to rozhodně validní názor, ale jak jsem někde četl, prostě v realitě to šlo trochu jinak, než se možná původně zamýšlelo

[Pindal]

Současný prohlížeč ale pěkně zařve, když FQDN nesouhlasí (a dělá dobře). Je blbost platit třetí straně (notabene samopasované do role autority) za ověření toho kdo sem a co mohu dělat, když je tu možnost (DNSSEC) si to zajistit sám a zadarmo. A věřím, že tudy půjde vývoj (u toho IPsecu určitě) a celé dnešní PKI půjde do pekel (ale asi to bude dlouhá cesta).

A k tomu EV, kdo mi zaručí že získání EV všech CA co jsou defaultně v prohlížeči není ta žádná legrace? Asi nikdo, že. Takže jsme opět kde jsme byli. Zkušený uživatel si nechá/doplní jen ty kterým důvěřuje a ten 99.9% zbytek si nechá default. PKI implementované v DNSSECu by i neznalým uživatelům přineslo větší bezpečnost než mají doteď a provozovatelům služeb úspory.

[Ivan]

Ten ucel se rozlisuje minimalne na fakture od CA. Serverove certifikaty jsou mnohem drazsi nez osobni.

[Radek Hladik]

Vím, že IPSec je i u IPv4, ale přeci jen někdo může namítat, že původně je to IPv6 technologie, do IPv4 byla jen backportována, že celé IPv4 je tak prolezlé NATy, že by to nemělo smysl, atd... Proto jsem specifikoval ten protokol jako IPv6, protože tam je situace "čistější", takže může být pozice IPSecu lepší.

[pavlix]

že celé IPv4 je tak prolezlé NATy, že by to nemělo smysl, atd...

Naopak, v rámci toho backportování se řešil právě prakticky jenom ten NAT.

Proto jsem specifikoval ten protokol jako IPv6, protože tam je situace "čistější", takže může být pozice IPSecu lepší.

Na veřejných adresách je IPsec mnohem čistší, protože se řeší nezávisle adresace a zabezpečení, to je fakt.

[Radek Hladik]

Tomu rozumím, jen jsem vysvětloval, proč jsem se v dotazu omezil jen na IPv6 - právě proto, abych se vyhnul odbočce diskuze z "jak principelně IPSec" do problematiky "jak byl IPSec ohýbán, aby se vypořádal se všemi IPv4only problémy"

[pepazdepa]

IPSec je povinnou součástí implementace IPv6, takže kterýkoliv rozumně nový linuxový server by neměl mít s IPsec problém.

tady to nekdo nepochopil. ipsec je povinnout soucasti ipv6 paketu.

[Michal Kubeček]

Ne, to rozhodně není. Výraz "povinnou součástí implementace IPv6" znamená jen to, že každá plnohodnotná implementace IPv6 musí povinně podporovat i IPv6, tj. umožnit ho používat, ne že se používat musí.

[pavlix]

Nehledě na to, že povinnou součástí implementace už není.

Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently, the default automated key management protocol to implement is IKEv2 [RFC5996].

[Radek Hladik]

Za tím si stojím. Packety bez IPSecu chodit můžou (naprostá většina chodí) a IPSec je povinný u implementace, pokud chce získat certifikaci. Jestli si jí ale koncový uživatel zapne nebo ne, je čistě na něm. A většina to neudělá.

[Michal Kubeček]

Koneckonců se stačí podívat do RFC 2460:

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet.

A pokud by to snad pořád ještě nebylo jasné, hned o kousek níž je nakreslený jako první příklad paket, který nemá žádné rozšiřující hlavičky.

[pavlix]

Tak...

http://fedora.cz/ipsec-implementace-v-kernelu/

http://fedora.cz/ipsec-ike-demony-ve-fedore/

http://fedora.cz/strongswan-5-0-0-nova-verze-implementace-ipsec/

IPSec je povinnou součástí implementace IPv6

Jak jsem psal někde výše, už není.

takže kterýkoliv rozumně nový linuxový server by neměl mít s IPsec problém.

IPsec je implementován v kernelu už bůhví jak dlouho, není to žádná novinka, a to jak pro IPv4, tak pro IPv6, tak pro hybridní tunely.

V současné době je zajímavá jen varianta ESP.

Potvrzuju.

Pro nastavení SA je potřeba separátní démon.

Experimentovat jde čistě s příkazem ip bez jakýchkoli démonů, viz první z odkázaných článků.

Vcelku použitelné to bude pro udělání VPN - režim tunnel

Na IPv4 zcela běžně používané, není důvod si myslet, že by tomu bylo na IPv6 jinak.

Celé nastavování by nemělo být moc složité s vyjímkou nastavení autentizace.

Mnohem jednodušší než popisuješ, pokud má démon rozumné výchozí hodnoty, stačí ti zadat jen několik údajů plus autentizaci. Není problém na autentizaci použít PSK, ale obecně se doporučuje PSK generovat, jak skončíš s bezpečností na úrovni každé druhé domácí wifi.

v knížce je nakousnuto, že je možno použít certifikáty, že se nově pracuje na ukládání věcí do DNS

Obě strany se můžou autentizovat pomocí certifikátů. Buď musíš znát certifikát předem, nebo ho musíš ověřit pomocí CA, nebo ho můžeš získat z DNS, pokud mu věříš. Proto se to kombinuje s DNSSEC, kde je systém důvěry hierarchický, narozdíl od veřejných CA, kde je systém důvěry „věřím každému blbečkovi, kdo dotáhl svoji CA na seznam podporovaných“. Co z toho je lepší, nechť posoudí každý sám.

Existuje nějaká CA, která mi vydá certifikát pro mojí IP? Jak ověří, že jsem vlastníkem té IP? Bude to mít dostatečnou váhu?

Já osobně doufám, že se pro IPsec nikdy systém veřejných CA používat nebude, stejně jako se nepoužívá na jiné věci, kde na bezpečnosti alespoň trochu záleží.

Jinak řečeno, kromě použití na administrativně moje tunely,

To je hlavní použití.

je to nějak prakticky použitelná technologie z globálního hlediska?

Tak konfigurované zabezpečené přístupy s autentizací obou stran jsou velice globální hledisko. Ale jestli se ptáš, je to technicky schopné nahradit TLS, tak ano. Jestli se ptáš, jestli ho to nahradí, tak křišťálovou kouli. V nejbližší době určitě ne, nejsou na to ani nadefinovaná API, pokud vím.

že se jedná sice o povinnou vlastnost implementace IPv6, ale téměř nikde nepoužitou

Naopak, jako VPN řešení to používají skoro všichni. Nicméně běžná implementace IPsec často vůbec nevyužívá, proto to bylo taky zrevidování a povinnou součástí už to není. Nicméně to v nějaké míře umějí všechny OS, co nějak běžně potkávám.

když u každé IPv6 komunikace nejprve ověřím, zda je cílová strana mi ochotna poskytnout (alespoň) nějaký certifikát?

A jak jinak by to mělo být? Myslím, že DNS dotaz na tohle bude ideální.

[Radek Hladik]

IPSec je povinnou součástí implementace IPv6

Jak jsem psal někde výše, už není.

Moje informace vycházela z knížky pana Satrapy aktualizované ke konci roku 2011, ale pokud je tomu už jinak, tak to asi nijak moc nevadí, jen si to chce dát pozor a vybírat implementace, které IPSec mají, pokud ho budu požadovat... A dokonce si i odpustím si poznámku, že IPv6 mění vnitřnosti jak politici názory (no dobře, úplně neodpustím ).

IPsec je implementován v kernelu už bůhví jak dlouho, není to žádná novinka, a to jak pro IPv4, tak pro IPv6, tak pro hybridní tunely.

Tak nějak jsem ten svůj bod myslel, prostě přijdu k Fedoře 7 a bude to tam...

Experimentovat jde čistě s příkazem ip bez jakýchkoli démonů, viz první z odkázaných článků.

A je to možné použít i v nějaké malé míře rozumně produkčně nebo opravdu jen na experimenty? Tedy, existuje nějaké rozumné produkční scenario (fuj slovo), kde to takhle bude stačit a bude to smysluplné?

Vcelku použitelné to bude pro udělání VPN - režim tunnel

Na IPv4 zcela běžně používané, není důvod si myslet, že by tomu bylo na IPv6 jinak.

Souhlas, ale na dělání VPN existuje spousta jiných toolů, proto mě tohle využití tolik nezajímá.

Jinak řečeno, kromě použití na administrativně moje tunely,

To je hlavní použití.

To už je podle mně dost subjektivní názor. Osobně IPSec chápu jako možnost, jak obecně ověřit protistranu, tedy přijde spojení z IP adresy x::y, já jí v životě neviděl, ale budu schopen věřit, že je to ta adresa. Pokud tohle IPSec nedovede zajistit, tak se u mně dostává plus/mínus na úroveň OpenVPN. Možná lepší, možná horší, ale pořád ve stejné kategorii...

Obě strany se můžou autentizovat pomocí certifikátů. Buď musíš znát certifikát předem, nebo ho musíš ověřit pomocí CA, nebo ho můžeš získat z DNS, pokud mu věříš. Proto se to kombinuje s DNSSEC, kde je systém důvěry hierarchický, narozdíl od veřejných CA, kde je systém důvěry „věřím každému blbečkovi, kdo dotáhl svoji CA na seznam podporovaných“. Co z toho je lepší, nechť posoudí každý sám.

Tohle je samozřejmě dobrá otázka. Přiznám se, že nevím, jak je to s podepisováním reverzních zón, takže DNSSEC jako technologie ano, ale mám pocit, že použití v této oblasti zatím není (ale jak řikám, můžu se mýlit). Co se týče přístupu s blbečkem, co něco někam dotáhl... No jak to říct, docela by mi zatím stačilo, kdyby to fungovalo v rámci ČR a v rámci ČR máme akreditované CA, které když něco podělají, tak rovnou dotáhnou automatickou pokutu 5-10 mega. A ještě je ta důvěryhodnost podložena v zákonech ČR, imho je to docela silné... Ve srovnání s třeba NIC (nic proti NIC ), který v případě podepisování reverzních zón zcela určitě nebude mít takhle silné základy...

když u každé IPv6 komunikace nejprve ověřím, zda je cílová strana mi ochotna poskytnout (alespoň) nějaký certifikát?

A jak jinak by to mělo být? Myslím, že DNS dotaz na tohle bude ideální.

To jsem myslel trochu jinak. Jakou cca budu mít v současné době úspěšnost, když všechny IPv6 adresy, na které normálně lezu, nejdřív požádám o certifikát (zatím řekněme úplně jakýkoliv)?

Ostatní věci buď souhlasím nebo jsou naopak v kategorii subjektivních názorů, na kterých se my dva neshodneme a nemá cenu o nich diskutovat

[Michal Kubeček]

A je to možné použít i v nějaké malé míře rozumně produkčně nebo opravdu jen na experimenty? Tedy, existuje nějaké rozumné produkční scenario (fuj slovo), kde to takhle bude stačit a bude to smysluplné?

Pokud se omezíte na manuální režim, můžete SA vytvářet ručně, ať už pomocí (dostatečně nového) ip nebo pomocí setkey. Pro produkční nasazení bych ale jednoznačně doporučil spíš automatický režim (tj. IKE, ať už pomocí démona racoon nebo pomocí jiné implementace).

na dělání VPN existuje spousta jiných toolů, proto mě tohle využití tolik nezajímá. … Osobně IPSec chápu jako možnost, jak obecně ověřit protistranu, tedy přijde spojení z IP adresy x::y, já jí v životě neviděl, ale budu schopen věřit, že je to ta adresa.

Podle mých zkušeností jste v tomto ohledu ve výrazné menšině.

[Radek Hladik]

Pokud se omezíte na manuální režim, můžete SA vytvářet ručně, ať už pomocí (dostatečně nového) ip nebo pomocí setkey. Pro produkční nasazení bych ale jednoznačně doporučil spíš automatický režim (tj. IKE, ať už pomocí démona racoon nebo pomocí jiné implementace).

O to mi právě šlo, že je to supr na experimentování to chápu. Ale šlo mi o to, zda mi neuniká nějaké základní použití, kde by to stačilo...

Podle mých zkušeností jste v tomto ohledu ve výrazné menšině.

Což je dle mně chyba, protože IPSec má/měl možnost toho dosáhnout. A nebyl bych si tak jistý, že ta menšina je výrazná, třeba v RFC o IPSecu v sekci goals se slovo VPN nevyskytuje ani jednou, za to je tam:

IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality.

[Michal Kubeček]

Nemyslím si, že sekce goals v RFC je nejvhodnější zdroj informací o tom, co se v praxi reálně používá… Koneckonců jsem to psal už ve své první (?) odpovědi: protokol vznikal s určitou představou, o tom, jak a k čemu by se měl používat, ale většina uživatelů ho (zatím?) používá k něčemu trochu jinému. V tom ostatně IPsec není až tak výjimečný, to se stalo spoustě jiných služeb a protokolů.

[Radek Hladik]

Plně souhlasím, ač částečně lituju, že IPSec potkalo zrovna tohle Ale chtěl jsem jen ukázat, že moje myšlenka není úplně exotická ale samozřejmě vím, že použití IPSecu na VPN je tolik, že je to v současné době naprosto majoritní věc... Ale co není může být, vzpomeňme kde byl Internet Explorer před 10ti lety a jak se to "poměrně rychle" "zvrtlo".

[Michal Kubeček]

Je samozřejmě možné, že masovější rozšíření IPsec v tom ne-VPN smyslu skutečně jednou přijde. IMHO je ale téměř vyloučené, že by k tomu došlo dřív, než bude používání IPv6 na Internetu výrazně převažovat nad IPv4. A ani to zatím nevypadá, že by bylo na pořadu dne…

[petr_p]

Proto jsem psal, že (použitelná) PKI neexistuje.

Nejbližší je DNSsec, jenže ten zas trpí řadou implementačních a organizačních problémů. Zkuste si k záznamu pro vaši IP adresu přiřadit autentizační klíč pro IKE, tak abyste mohl klidně spát, že vám některý mezičlánek neunese identitu.

Bezpečnější se mi jeví PKI certifikačních autorit. Ale i když pominu, že se nejedná o strom (tazatel je dokonce se ochotný omezit jen na Českou republiku), tak bohužel není autorita, která by certifikáty vydávala. Třeba jediná použitelná politika Postsigna jsou komerční systémové cerifikáty a tam jediná vhodná místa jsou: CanonicalName a OtherName. Oba jsou ale typu řetězec. Do něho se IP adresa špatně ukládá. Nehledě na to, že Postsignum platnost těchto záznamů nijak (až na jedinečnost) neověřuje.

Jako třetí PKI můžeme zvážit síť důvěry PGP, jenže když i tam máme problém ověřit lidi, přestože se prý s každým známe do šesti hopů, tak s ověřováním asociálních mašin to bude ještě těžší :(

[pavlix]

Proto jsem psal, že (použitelná) PKI neexistuje.

Zde nevidím naprosto žádnou souvislost.

Nejbližší je DNSsec, jenže ten zas trpí řadou implementačních a organizačních problémů. Zkuste si k záznamu pro vaši IP adresu přiřadit autentizační klíč pro IKE, tak abyste mohl klidně spát, že vám některý mezičlánek neunese identitu.

Budu spát klidněji než při použití veřejných certifikačních autorit, kde mi ji může ukrást prakticky kdokoli.

To už si radši doplním DNSSEC o zakotvení konkrétních zón na konkrétní klíče.

Do něho se IP adresa špatně ukládá. Nehledě na to, že Postsignum platnost těchto záznamů nijak (až na jedinečnost) neověřuje.

Identifikace IP adresou mi přijde dost slabá. To DNS jméno mi přijde jak rozumnější identifikátor. Vždyť to uživatel naprosto nemá šanci ověřit, leda že by si ty IP adresy pamatoval.

[pavlix]

Pro produkční nasazení bych ale jednoznačně doporučil spíš automatický režim (tj. IKE, ať už pomocí démona racoon nebo pomocí jiné implementace).

Racoon je beznadějně zastaralý a jeho konfigurace na cokoli víc než statický tunel je stejně beznadějně složitá. A i ten statický tunel se konfiguruje složitěji než kdekoli jinde.

[Michal Kubeček]

To je věc názoru. Ale i pokud tento postulát přijmu, pořád to nemění nic na podstatě toho, o čem jsem psal: že manuální režim s ručně nastavenými fixními SA není vhodný pro ostré nasazení a že je potřeba použít automatický.

[Michal Kubeček]

Ještě poznámka: přijde mi hodně zvláštní navážet se do racoona a pak opakovaně jako příklad uvádět Strongswan. Za sebe můžu říct, že když jsem byl okolnostmi donucen z FreeS/WAN přejít na ipsec-tools, bylo sice nejdřív těžké zvyknout si na dost odlišnou filosofii, ale zpětně jsem ocenil, že u ipsec-tools konfiguruji to, co se opravdu v IPsec nastavuje a utility mi to neskrývají za svou vlastní abstrakční vrstvu a "slovníček", jako tomu bylo u FreeS/WAN. Vzhledem k tomu, že projekt Strongswan obecně nic podstatného nepřinesl (kromě toho, že do FreeS/WAN naházel patche, které už tak jako tak byly k dispozici a většina distribucí je používala), pochybuji, že se konfigurace nějak zásadně změnila.

[pavlix]

Ještě poznámka: přijde mi hodně zvláštní navážet se do racoona a pak opakovaně jako příklad uvádět Strongswan.

Není to nijak zvláštní, ten software je v porovnání se Strongswanem prakticky nepoužitelný, neaktuální a ještě je extrémně komplikovaný. Když jsem ho testoval, zjistil jsem, že kromě toho, že neumí aktuální protokol, tak neumí bez skriptování ani jiné základní věci jako třeba road warrior. Strongswan je úplně jiná liga.

Za sebe můžu říct, že když jsem byl okolnostmi donucen z FreeS/WAN přejít na ipsec-tools,

Já jsem FreeS/WAN nikdy nepoužíval a je otázka, jestli má nějaký smysl posuzovat aktuální Strongswan podle nějakého starého projektu, ze kterého kdysi vycházel.

Vzhledem k tomu, že projekt Strongswan obecně nic podstatného nepřinesl (kromě toho, že do FreeS/WAN naházel patche, které už tak jako tak byly k dispozici a většina distribucí je používala)

Je otázka, jestli Strongswan vůbec používá nějaké netriviální množství původního kódu.

Pokud bych chtěl vše nastavovat od podlahy, použil bych možná ještě Racoon2. Jenže ten je opět jako projekt spíše neaktivní navíc i zabalit o pro Fedoru bylo docela PITA oproti třeba tomu Strongswanu.

[Michal Kubeček]

Moje zkušenosti s obojím jsou prostě přesně opačné.

[Ondrej 'SanTiago' Zajicek]

To už je podle mně dost subjektivní názor. Osobně IPSec chápu jako možnost, jak obecně ověřit protistranu, tedy přijde spojení z IP adresy x::y, já jí v životě neviděl, ale budu schopen věřit, že je to ta adresa.

Otazka je k cemu je takova duvera. Pokud o te IP adrese nic nevim, tak stejne na tom asi zadnou rozumnou authentizaci nepostavim. Moznou aplikaci tu vidim, kdyz se na takto delany IPSec nekoukam jako na autentizaci, ale jako na ochranu pred man-in-the-middle utokem. Pak by asi uplne stacily klice v revreznich DNS zaznamech.

Tohle je samozřejmě dobrá otázka. Přiznám se, že nevím, jak je to s podepisováním reverzních zón, takže DNSSEC jako technologie ano, ale mám pocit, že použití v této oblasti zatím není (ale jak řikám, můžu se mýlit). Co se týče přístupu s blbečkem, co něco někam dotáhl... No jak to říct, docela by mi zatím stačilo, kdyby to fungovalo v rámci ČR a v rámci ČR máme akreditované CA, které když něco podělají, tak rovnou dotáhnou automatickou pokutu 5-10 mega. A ještě je ta důvěryhodnost podložena v zákonech ČR, imho je to docela silné...

Problem s CA v kombinaci s IPSec je v tom, ze vlastne neni jasne, co by ta CA vubec mela prokazovat. Zatimco domenu 'vlastnim', IP adresy jsou mi jen docasne prideleny, typicky po dobu smlouvy o pripojeni s ISP. Takova smlouva ma vypovedni lhutu (treba mesic) a v nekterych pripadech muze byt vypovezena okamzite (a adresy prideleny nekomu jinemu), treti strana (CA) nema sanci vystavit certifikat, ktery by tohle smysluplne postihnul (a jeho platnost neprekracovala dobu, kdy mi ty adresy jsou skutecne pridelene). Takze asi jedine rozumne reseni pro to je mit tu infrastrukturu konzistentni s delegaci rozsahu IP adres (RIR->LIR->user).

[Michal Kubeček]

Zatimco domenu 'vlastnim', IP adresy jsou mi jen docasne prideleny, typicky po dobu smlouvy o pripojeni s ISP.

I doména je přidělena jen dočasně a pokud přestanu platit poplatky nebo smlouvu zruším, registraci mi zruší a bude si ji moci zaregistrovat někdo jiné. Rozdíl je jen v tom, že mám poměrně velkou šanci, že pokud budu řádně plnit své závazky, nehrozí, že mi jen tak doménu vymění za jinou.

[Radek Hladik]

Otazka je k cemu je takova duvera. Pokud o te IP adrese nic nevim, tak stejne na tom asi zadnou rozumnou authentizaci nepostavim. Moznou aplikaci tu vidim, kdyz se na takto delany IPSec nekoukam jako na autentizaci, ale jako na ochranu pred man-in-the-middle utokem. Pak by asi uplne stacily klice v revreznich DNS zaznamech.

No ta důvěra je přesně k tomu, že věřím, že ta adresa je ta adresa, nic víc nic méně. To jak tu informaci použiju dál, je věc další. Například si můžu jít stěžovat k ISP, můžu nevyžadovat heslo do nějaké méně důležité aplikace, můžu otevřít firewall pro definované adresy... Ano, některé věci bych si na takové důvěře postavit netroufl, některé ano.

Problem s CA v kombinaci s IPSec je v tom, ze vlastne neni jasne, co by ta CA vubec mela prokazovat. Zatimco domenu 'vlastnim', IP adresy jsou mi jen docasne prideleny, typicky po dobu smlouvy o pripojeni s ISP. Takova smlouva ma vypovedni lhutu (treba mesic) a v nekterych pripadech muze byt vypovezena okamzite (a adresy prideleny nekomu jinemu), treti strana (CA) nema sanci vystavit certifikat, ktery by tohle smysluplne postihnul (a jeho platnost neprekracovala dobu, kdy mi ty adresy jsou skutecne pridelene). Takze asi jedine rozumne reseni pro to je mit tu infrastrukturu konzistentni s delegaci rozsahu IP adres (RIR->LIR->user).

Ano, pak by možná bylo nutné udělat koncept vlastnění IP adresy (nebo rozsahu), třeba alespoň v rámci poskytovatelů obsahu. U IPv6 je přeci tolik adres, že není potřeba IP adresy znovu přidělovat a je možné počkat, až certifikát vyprší... A u residenčních klientů může IPSec dělat ISP, nemusí to být koncový klient...

[pavlix]

No ta důvěra je přesně k tomu, že věřím, že ta adresa je ta adresa

To mi nepřijde úplně užitečné ani z hlediska zapamatování ani z hlediska zabezpečení, že se připojuju tam, kam se chci připojovat.

Já se totiž obvykle nechci připojovat na IP adresu, ale na konkrétní službu (bez ohledu na to, zda je na stejné IP jako před měsícem). IP není dobrý identifikátor služby, zůstal bych u toho, že je to technický identifikátor.

[pavlix]

Moje informace vycházela z knížky pana Satrapy aktualizované ke konci roku 2011

V hlavičce toho RFC se píše Decenber 2011. Já jsem o tom nevěděl ještě v červnu :). Takže na IPv6 day na to Pavel upozornil a já jsem měl přednášku později a už jsem to ani neupravoval ve slajdech :).

Tak nějak jsem ten svůj bod myslel, prostě přijdu k Fedoře 7 a bude to tam...

V kernelu už je dlouho, ale přesnou historii neznám. Horší to bylo s userspace, do nedávna nic uspokojivého ve Fedoře nebylo a třeba v Debianu stable je Strongswan starší verze a s IPv6 mi to nějak nechtělo jet.

A je to možné použít i v nějaké malé míře rozumně produkčně nebo opravdu jen na experimenty? Tedy, existuje nějaké rozumné produkční scenario (fuj slovo), kde to takhle bude stačit a bude to smysluplné?

Přijdeš tím o automatickou výměnu klíčů a všechny ty dynamické featury. Nevidím v tom smysl, když je mnohem jednodušší zkonfigurovat Strongswan a jet.

Souhlas, ale na dělání VPN existuje spousta jiných toolů, proto mě tohle využití tolik nezajímá.

Tak v enterprise sféře je IPsec řekl bych zcela dominantní. Takže záleží jesti děláš sám sobě VPN nebo se chceš k nějaké připojit.

To už je podle mně dost subjektivní názor.

To je realita okolního světa.

Osobně IPSec chápu jako možnost, jak obecně ověřit protistranu, tedy přijde spojení z IP adresy x::y, já jí v životě neviděl, ale budu schopen věřit, že je to ta adresa.

Tohle je právě ideál, se kterým se už hodně let experimentuje, ale běžně to tak lidi nepoužívají.

A ještě je ta důvěryhodnost podložena v zákonech ČR, imho je to docela silné...

Silnější než v Holandsku? Používáš výhradně české akreditované veřejné CA?

Ve srovnání s třeba NIC (nic proti NIC ), který v případě podepisování reverzních zón zcela určitě nebude mít takhle silné základy...

Mám takové podezření, že CZ.NIC asi v reverzních zónách nebude mít vůbec co pohledávat. Nehledě na to, že jsou z tohoto pohledu zcela nezajímavé. Nebo mi něco uniklo?

To jsem myslel trochu jinak. Jakou cca budu mít v současné době úspěšnost, když všechny IPv6 adresy, na které normálně lezu, nejdřív požádám o certifikát (zatím řekněme úplně jakýkoliv)?

Řekl bych, že když pár lidí ukecáš, ať to s tebou otestují, tak se šance řádově zvýší :).

Ostatní věci buď souhlasím nebo jsou naopak v kategorii subjektivních názorů, na kterých se my dva neshodneme a nemá cenu o nich diskutovat

Zrovna v tomto příspěvku je subjektivní věc snad jen jedna:

Já osobně doufám, že se pro IPsec nikdy systém veřejných CA používat nebude, stejně jako se nepoužívá na jiné věci, kde na bezpečnosti alespoň trochu záleží.

Na tvrzení, že naprosto převažuje použití IPsec jako VPN nic subjektivního není :).

[Radek Hladik]

Přijdeš tím o automatickou výměnu klíčů a všechny ty dynamické featury. Nevidím v tom smysl, když je mnohem jednodušší zkonfigurovat Strongswan a jet.

To je mi jasné, jen jsem se ptal, esli mi neuniká nějaké použití, kde by bylo jednodušší mít pevně dané SA a neřešit démona navíc.

To je realita okolního světa.

Na téma vnímání reality už jsme se jednou bavili, nemíním v tom pokračovat. Protože věc jako je "cíl technologie" je prostě subjektivní názor. To, že se v současné době masivně používá IPSec pro VPN neznamená, že to je jeho hlavní cíl. Jak už jsem zmiňoval výše, to že měl IE 90% zastoupení taky neznamenalo, že hlavním cílem webu byl obsah pro IE

Silnější než v Holandsku?

Neznám přesně situaci v Holandsku (právní), ale řekl bych, že je to u nás lepší (celkově). To, že se dá zaútočit na každou CA, to je jasná věc, lidi jsou pořád jen lidi...

Používáš výhradně české akreditované veřejné CA?

Kupodivu, páč na tom stojí část mého živobití, tak tam, kde je to potřeba, tam ano.

Mám takové podezření, že CZ.NIC asi v reverzních zónách nebude mít vůbec co pohledávat. Nehledě na to, že jsou z tohoto pohledu zcela nezajímavé. Nebo mi něco uniklo?

No pokud jde o vazbu IP->podpis, tak se musí v DNS dohledávat přes reverzní záznamy a hiearchicky podepsané. De facto stejné, jako pro dopředné záznamy. A protože ty u nás zajišťuje NIC a dost se u nás o podobné věci zasluhuje, přišlo mi, že by byl ideální garant i pro reverzní záznamy. Ale pokud to dobře chápu, tak pracovní skupina pracuje, takže uvidíme, s čím přijdou...

Zrovna v tomto příspěvku je subjektivní věc snad jen jedna:

Já osobně doufám, že se pro IPsec nikdy systém veřejných CA používat nebude, stejně jako se nepoužívá na jiné věci, kde na bezpečnosti alespoň trochu záleží.

No to je přesně ta věc, kterou jsem se snažil taktně mlčky přejít. Protože to tvoje tvrzení není moc přesné. Resp záleží, co si představuješ pod pojmem veřejná CA. Znám naopak hodně řešení, kde se právě kvůli bezpečnosti používá systém akreditovaných CA, jmenujme například elektronický podpis, datové schránky, elektronické recepty a mnoho dalšího. Pokud si pod veřejnou CA představuješ nějakou ušmudlanou podivnou CA někde v banánistánu, tak by se o tom tvrzení dalo uvažovat...

[pavlix]

To je mi jasné, jen jsem se ptal, esli mi neuniká nějaké použití, kde by bylo jednodušší mít pevně dané SA a neřešit démona navíc.

To si musíš posoudit sám nebo se zeptat někoho od kryptografie. Ale obecně se výměna klíčů považuje za důležitou a démon nijak nepřekáží.

Na téma vnímání reality už jsme se jednou bavili, nemíním v tom pokračovat. Protože věc jako je "cíl technologie" je prostě subjektivní názor.

Přesně tak. Proto není vhodné zaměňovat cíl technologie a její reálné současné většinové uplatnění.

Ale když už jsme u osobních názorů, tak ten můj je, že cílem IPsec je pokrýt obojí plus ještě něco navíc.

Jak už jsem zmiňoval výše, to že měl IE 90% zastoupení taky neznamenalo, že hlavním cílem webu byl obsah pro IE

Ale znamenalo to, že reálně prakticky všechny weby (připouštím méně než promili) dostupné pro IE a pokud někde fungovaly správně, tak minimálně v IE.

Nicméně, jestliže IE mělo 90%, pak alternativy měly 10%, což suhrnně vzato je podstatá menšina, vníž ještě často dominuje něco konkrétního. V tomto případě ale ta menšina nedosáhne ani na jednotky procent, ať už to posuzuješ jakkoli kromě čtení teorie.

A protože ty u nás zajišťuje NIC a dost se u nás o podobné věci zasluhuje, přišlo mi, že by byl ideální garant i pro reverzní záznamy.

Jenže NIC přiděluje domény a (běžně) veřejně nepřiděluje adresy.

Kupodivu, páč na tom stojí část mého živobití, tak tam, kde je to potřeba, tam ano.

To je o dost lepší situace než třeba u webu, kde můžou certifikát falšovat desítky až stovky subjektů.

datové schránky

Nemám osobně pocit, že by datové schránky byly případem technicky dobrého a bezpečného řešení, ale budiž. Mně šlo v podstatě hlavně o to oddělit fakta (a případně je opravut) a osobní názor, který je spíš na diskuzi v hospodě…

Pokud si pod veřejnou CA představuješ nějakou ušmudlanou podivnou CA někde v banánistánu, tak by se o tom tvrzení dalo uvažovat...

Prozatím si pod veřejnou CA představuju kteroukoli ze seznamu v prohlížečí, protože web je jediný systém, kde veřejné PKI používám. Všude jinde používám privátní PKI, protože do interní komunikace nemá stát ani akreditovaná firma co mluvit.

[Pindal]

Tak, tak. Celý dnešní systém PKI s předinstalovanými "důvěryhodnými" CA je na pytel. Dovedu si představit, že CA by dělal stát a certifikát by člověk dostal s občankou, živnostník a firmy se zápisem od rejstříku. Brr hrozná představa pak mít povinnost to na internetu používat

[Radek Hladik]

Jenže NIC přiděluje domény a (běžně) veřejně nepřiděluje adresy.

To já vím. Ale zároveň se NIC angažuje ve spoustě dalších věcí na (nejen) českém Internetu (a díky mu za to) a byl by vhodným kandidátem pro správu takovéhoto systému.

Nemám osobně pocit, že by datové schránky byly případem technicky dobrého a bezpečného řešení, ale budiž.

Taky nemám pocit, že by DS byly nějaké skvostné řešení, ale na druhou stranu bych řekl, že jsou poměrně slušně udělané a to i včetně zabezpečení. Neříkám, že tam nejsou nějaké problémy, ale je třeba si uvědomit, kolik uživatelů ten systém má. Ale to jsme trochu odbočili...

Všude jinde používám privátní PKI, protože do interní komunikace nemá stát ani akreditovaná firma co mluvit.

Tohle vypadá, jako bys nechápal princip fungování CA a asymetrické kryptografie vůbec. CA v žádném případě nemluví do jakékoliv komunikace. Pouze podle definované procedury ověření vydává různé certifikáty. V žádném případě ale nemůže pracovat s komunikací, ke které se ty certifikáty používají. Naše akreditované CA mají ze zákona povinnost vyhýbat se privátnímu klíči žadatele (a je tam opět pokuta v řádu 5-10 mil Kč a možnost odebrání akreditace) - je tam vyjímka při generování, kterou tady nebudu pro přehlednost rozebírát.

Privátní CA totiž naráží ve chvíli, kdy není možné všechny potřebné subjekty svázat nějakým vztahem (třeba zaměstnaneckým poměrem). Proto se dost často využívá služeb takovéto akreditované CA, která právě udělá přesně to "ten s kým komunikujete se prokázal jako pan X.Y. a my jsme to postupem běžným v ČR (typicky občankou) ověřili". To že to někdo může obejít (falešná občanka) je jasné, ale to už je normální podvod (trestný čin) a je to problém mezi ním a CA. Druhá věc je, že si za to CA nechává platit, ale to už je na posouzení každého, zda mu ta cena za to stojí nebo ne. Ale ze zkušenosti můžu říct, že u systémů, kde jsou uživatelé z víc jak jedné firmy se provozovatelé dost často uchylují právě k použití těchto CA (pokud je smysluplné požadovat po uživatelích zakoupení certifikátu).

[Michal Kubeček]

Tohle vypadá, jako bys nechápal princip fungování CA a asymetrické kryptografie vůbec.

Ale on to chápe. Problém je, že vy se pořád podvědomě zabýváte myšlenkou na použití IPsec k zabezpečení komunikace dvou subjektů, které "se neznají" (a tudíž potřebují důvěryhodného prostředníka), zatímco pavlix má primárně na mysli to, co se dnes opravdu reálně používá. A v okamžiku, kdy konfiguruji VPN mezi dvěma (či více) firemními pobočkami v různých městech nebo přístup stovky "road warriors" do firemní sítě, je naprostý nesmysl používat k ověření certifikáty podepsané nějakou externí autoritou, i kdyby třeba měla glejt osobně podepsaný samotným Václavem Klausem. V prvním případě tam narvu přímo certifikáty protistran, ve druhém si udělám vlastní autoritu.

[Radek Hladik]

Z toho

Všude jinde používám privátní PKI, protože do interní komunikace nemá stát ani akreditovaná firma co mluvit.

to vypadalo, jako by si myslel, že CA mu bude mluvit přímo do obsahu té komunikace, proto jsem chtěl zdůraznit, že to není možné a i proto jsem to uvedl "tohle vypadá", protože si myslím, že to Pavlix chápe, jen se špatně vyjádříl.

... přístup stovky "road warriors" do firemní sítě, je naprostý nesmysl používat k ověření certifikáty podepsané nějakou externí autoritou, i kdyby třeba měla glejt osobně podepsaný samotným Václavem Klausem.

Tady pozor, naprostý nesmysl to není. Je to krajní a drahá možnost, ale právě ta právní váha může být důležitý faktor při rozhodování. Protože i při připojování stovky road warriors do firemní sítě můžu potřebovat větší právní jistotu než interní CA (uvědomte si, že ve státní správě je jakýkoliv interní předpis postižitelný maximálně vyhazovem a cca 4násobkem měsíčního platu, soukromé firmy si na zaměstnancích taky moc nevemou, pokud to nemají přímo v pracovní smlouvě). Osobně vím o jednom projektu, kde se právě nasazení akreditovaných certifikátů zvažovalo i na VPN prvky, ale nakonec se kvůli ceně použily jen u koncových uživatelů - a jednalo se přesně o připojení x tisíc uživatelů do vnitřní sítě a nabízení jedné služby. A při jiném případě jsem viděl nasazení akreditovaných certifikátů do interního systému právě proto, že jsou právně podložené (ale tam se jednalo jen o desítky lidí).

[Michal Kubeček]

jako by si myslel, že CA mu bude mluvit přímo do obsahu té komunikace, proto jsem chtěl zdůraznit, že to není možné

To bohužel není tak úplně pravda. Přinejmenším může (ať už vědomě nebo nevědomky) vystavit falešný certifikát, kterému každý, kdo ji má nastavenou mezi důvěryhodnými, bude automaticky věřit. To už stačí, aby se vydávala za jednu stranu komunikace. Když to provedete na obě strany, máte z toho plnohodnotný man-in-the-middle útok. Že je něco takového nemožné, protože CA si to přísně hlídají a musejí splňovat velmi přísná pravidla? Bohužel není, protože už se to několikrát stalo, a to i těm, které jsou všeobecně považovány za špičku.

S tím druhým odstavcem naprosto nesouhlasím (a u té části o postižitelnosti zaměstnancům mi zcela uniká souvislost). Vlastní CA, která je plně pod mou kontrolou, je vždy a priori bezpečnější než když k těm interním zaměstancům, kteří mohou bezpečnost narušit, navíc (ano, k nim navíc, ne místo nich) přidám ještě nějaký cizí subjekt zcela mimo mou kontrolu.

[Radek Hladik]

Bohužel není, protože už se to několikrát stalo, a to i těm, které jsou všeobecně považovány za špičku.

Samozřejmě, že se to stalo, pokud znáte nějaký systém, jak tomu zabránit, budete velmi bohatý člověk Ale privátní CA jím rozhodně není. Privátní CA totiž deleguje právo vydávat certifikáty několika zaměstnancům (a většinou stačí kterýkoliv z nich) a to podle nějakých interních směrnic. Když takový zaměstnanec tohle poruší, tak ho firma maximálně vyhodí a může se snažit vymáhat vzniklou škodu, což je díky malé právní váze takového certifikátu dost problém. Ostatně to, že někdo neoprávněně vystavil certifikát "jen" na přístup do VPN přece takový prohřešek není, že... Neříkám, že privátní CA nemají smysl, ale jako u všeho je to nástroj, který má určité vlastnosti a jeho konkrétní použití záleží na požadavcích.

Co se týče toho zbytku, tak příklady, o kterých jsem mluvil jsou z praxe a nejedná se o žádné malé garážové firmičky

[Michal Kubeček]

Stejně jako si může zaměstnanec firmy (který má práva k CA) neoprávněně vystavit nějaký certifikát navíc, může si zaměstnanec firmy (který má práva podávat requesty na externí CA) nechat vystavit nějaký certifikát navíc. Takže problém, kterého se bojíte, neodstraníte, pouze přidáte jeden navíc (externí subjekt zcela mimo vaši kontrolu).

Pokud má mít tato debata smysl, přestaňte, prosím, uvažovat jako právník a začněte uvažovat jako systémák.

[Radek Hladik]

Až na to, že za vystavení certifikátu navíc u akreditované CA půjdu bručet, v případě interní půjdu maximálně na pracák.

Pokud má mít tato debata smysl, přestaňte, prosím, uvažovat jako právník a začněte uvažovat jako systémák.

Probůh proč? Copak jsme jako systémáci něco tak extra, že se nás jiné obory netýkají? Z technického hlediska tato debata smysl nemá, protože "používáme 100% důvěryhodné certifikáty", technicky je všecko naprosto jasné. Ale právě to zajištění důvěryhodnosti necháváme na ostatních a byla by chyba nic o tom nevědět.

[Ondrej 'SanTiago' Zajicek]

za vystavení certifikátu navíc u akreditované CA půjdu bručet

Vazne? Na zaklade jakeho bodu trestniho zakoniku?

[Radek Hladik]

Šikovný právník na to naroubuje obecný podvod a/nebo padělání veřejné listiny, podklady se dají najít například v Zákon č. 227/2000 Sb., o elektronickém podpisu .

[Käyttäjä 11133]

§ 206? Avšak ta faktura od CA by musela být alespoň 500k v Českých, aby to byla značná škoda :)

[Michal Kubeček]

Probůh proč?

Protože pokud své systémy hodláte chránit metodou "nesmí se to a pokud to někdo udělá, zažalujeme ho", pak se nemáme o čem bavit. To je téma, které jde mimo mne a kterým se tu zabývat nehodlám.

[Radek Hladik]

Tenhle přístup mě občas docela překvapuje. Čím je naše povolání tak vyjímečné, že nemusíme interagovat s ostatními obory? Předpokládám, že až vám server někdo fyzicky ukradne, tak ho nezažalujete? Nebo to nespadá do "nesmí se to a pokud to někdo udělá, zažalujeme ho"?

Je přeci naproto normální provést nějakou rozumnou míru odporu proti negativní události (server mít v zamčené mistnosti/ nasadit technologii certifikátů) a v případě, že někdo se dostane i přes tuto úroveň a udělá něco, co nesmí, tak to s ním řešit soudně. A nasadit kvalitu zabezpečení podle míry možné škody (použít bezpečnostní vložky/ použít akreditované certifikáty).

Je samozřejmě možné říct "To je téma, které jde mimo mne a kterým se tu zabývat nehodlám" a nechat někoho jiného, ať to řeší za mně, ale myslím, že dostatečně znalý odborník v oboru byl měl mít základní znalosti z navazujících oborů.

[Michal Kubeček]

Je tak těžké pochopit, že jsou témata, která mne zajímají a o kterých jsem ochoten se tu bavit, a jiná témata, která mne nebaví natolik, abych věnoval svůj čas tomu, že je tu s vámi budu probírat?

Přestavte si, že to bude opačně. Že třeba pocítím neodolatelnou touhu od problematiky IPsec a X.509 certifikátů přejít k problematice odposlechu vyzařování z nestíněných vodičů* (což také svým způsobem souvisí s bezpečností). Vy mi řeknete, že se touto problematikou nezabýváte a že se mnou tudíž o ní diskutovat nebudete. Jak se budete tvářit na to, když do vás začnu hustit, jak je to krátkozraké se takhle izolovat, a že byste se měl zajímat i o navazující obory?

---

* - jen příklad; pokud vás zrovna tohle zajímá, předpokládejme pro jednoduchost, že už jsem navrhl dvacet dalších témat a našel nějaké, o kterém se bavit nechcete nebo nemůžete

[Radek Hladik]

Pominu to, že zrovna vyzařování z nestíněných vodiců z hlediska bezpečnosti by mě zajímat mohlo, alespoň do "laické" úrovně, tedy kolik se toho a jak složitě dá odposlechnout.

Já samozřejmě nemám problém s něčím ve stylu "to mně nezajímají natolik, abych investoval svůj čas do diskuse na toto téma", ale zatím jste ve svých příspěvcích vždy vyjadřoval nějaký (většinou nesouhlasný) názor na mé názory a proto se snažím diskutovat, protože si obecně myslím, že diskuse je prospěšná.

A upřímně řečeno, snažím se docela zajímat o všechny přímo navazující obory, alespoň do té "laické" úrovně, takže pokud byste nějaké takové našel, rozhodně ho neodmítnu

[Michal Kubeček]

Tak ještě jednou a naposledy: nejsem právník (ani amatérský) a nechci jím být. Proto dám přednost řešení, kde nemusím svou vlastní bezpečnost zbytečně svěřovat do rukou třetí strany jen proto, abych se mohl utěšovat tím, že když to někdo zneužije a čirou náhodou se ho podaří usvědčit a odsoudit, dostane větší trest. Víc k tomu nemám co říct a právní otázky tu řešit nehodlám. Tečka. Je to dostatečně jasné a srozumitelné?

[Radek Hladik]

Je to jasné i srozumitelné. A zároveň i značně překroucené. Ale opravdu nemá smysl se o tom bavit a nezbývá mi, než vám popřát, abyste se profesně nedostal do situace, kdy si tento postoj nebudte moci dovolit :)

[pavlix]

Ale opravdu nemá smysl se o tom bavit a nezbývá mi, než vám popřát, abyste se profesně nedostal do situace, kdy si tento postoj nebudte moci dovolit :)

Přeju to samé ohledně postoje „právníci vše vyřeší“.

[Radek Hladik]

Přeju to samé ohledně postoje „právníci vše vyřeší“.

Zcela očividně jsi to nepochopil...

[pavlix]

Což se bohužel dá říci stejně i o tobě a navíc nevidím důvod zakládat dotaz v poradně, abych se pod tím dotazem choval konfliktně. Od toho jsou když už tak diskuze pod blogy.

[pavlix]

protože si myslím, že to Pavlix chápe, jen se špatně vyjádříl.

Dokonce jsem se ani špatně nevyjádřil, naopak jsem se vyjádřil zcela přesně.

[owl]

Úředníci zřejmě hodlají poslat kvalifikované CA dříve či později do kytek. Před pár dny vyměnilo MV původní (kvalifikovaný ve smyslu příslušného zákona) SSL certifikát web serveru datovek za komerční (byť EV) certifikát, navíc ještě zahraniční (tuším Geotrust). Aby měli lidi zelený proužek v prohlížeči. Tím - obávám se - předchozí debata zčásti ztrácí smysl.

[petr_p]

On ani ten předchozí certifikát nebyl kvalifikovaný, neb kvalifikovaný lze použít jen a pouze pro vytvoření zaručeného podpisu nebo značky, nikoliv pro ověření totožnosti v TLS. V terminologii dané autority se jednalo o komerční certifikát.

[pavlix]

To já vím. Ale zároveň se NIC angažuje ve spoustě dalších věcí na (nejen) českém Internetu (a díky mu za to) a byl by vhodným kandidátem pro správu takovéhoto systému.

Já si myslím, že se CZ.NIC šestým RIRem nestane.

Tohle vypadá, jako bys nechápal princip fungování CA a asymetrické kryptografie vůbec.

To vynášíš hodně odvážné soudy :).

[Radek Hladik]

Já si myslím, že se CZ.NIC šestým RIRem nestane.

A kdo říká, že se NIC má stát RIRem?

[pavlix]

Ten, kdo tvrdí, že by měl dělat reverzní delegaci.

[Radek Hladik]

To je tak sáhodlouhá zkratka, která předpokládá tolik věcí, že jí snad ani nemá smysl komentovat...

[pavlix]

Tak ji nekomentuj :).

[Ondrej 'SanTiago' Zajicek]

Vcelku použitelné to bude pro udělání VPN - režim tunnel

Tady si je treba dat pozor - IPSec tunnel mode neni uplne to, co si lide obvykle predstavuji pod VPN ci tunelem. Zatimco normalni tunel (at uz sifrovany ci nesifrovany) 'tuneluje vsechno' a tvari se jako skutecny virtualni ptp spoj, IPSec se chova jako tunel jen z hlediska siftovani/autentizace, zatimco z ostatnich hledisek (napr. routovani) se chova jako by tam tunel nebyl. Proto je pro skutecne sifrovane tunely v mnoha pripadech vhodnejsi pouzit nesifrovany tunel (IPIP ci GRE) v kombinaci s IPSec transport mode.

[Radek Hladik]

Ano to vím, dokonce jsem se díval přímo do té knížky, abych napsal správný název toho režimu

[Michal Kubeček]

Jestli jsem dobře pochopil, co máte na mysli, tak to ale není vlastnost IPsec jako takového, ale jen (lokální) chování konkrétní implementace z linuxového jádra řady 2.6/3. Třeba FreeS/WAN na jádrech řady 2.4 fungoval tím "obvyklým" způsobem (tj. virtuální interface a routing místo security policies).

[Ondrej 'SanTiago' Zajicek]

AFAIK je toto chovani vicemene pozadovano prislusnymi RFC, viz napr. Security Policy Database v RFC 4301, takze FreeS/WAN nejspis byl v tomto ohledu nestandardni.

Ale je pravda, ze to je v podstate otazka interniho chovani koncovych bodu tech tunelu, neni neco co by plynulo napr. z IPSec hlavicek (BTW, IPSec tunnel mode je co ze tyce formatu paketu naprosto shodny s IPIP v IPSec transport mode, tedy alespon na IPv4).

[pavlix]

BTW, IPSec tunnel mode je co ze tyce formatu paketu naprosto shodny s IPIP v IPSec transport mode, tedy alespon na IPv4

Díky za odpověď :).

[pavlix]

To jednak tak tuším není ve všech implementacích. A navíc, když jsem to testoval, tak mi přišlo mnohem účelnější se naučit pracovat s tím nástrojem tak jak je, než ho doplňovat o další vrstvu.

Ale jinak proč ne, klidně ipip v transport mode. Teď přemýšlím, jestli se to zapouzdření vůbec nějak liší.