Byla vydána nová verze 1.4 svobodného multiplatformního vektorového grafického editoru Inkscape. Podrobný přehled novinek i s náhledy a animovanými gify v poznámkách k vydání.
Softwarový KVM Input Leap (dříve Barrier) byl vydán ve verzi 3.0.0 (a následně pár opravných). Přidává podporu Waylandu a Qt6. Jde o první vydání od přesunu z projektu Barrier v roce 2021. Barrier vznikl jako fork Synergy, jehož verze 2 byla částečně proprietární a její bezplatná open-source verze měla umělá omezení.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Přímý přenos (YouTube) z konference LinuxDays 2024, jež probíhá tento víkend v Praze v prostorách Fakulty informačních technologií Českého vysokého učení v Praze (FIT ČVUT). Na programu je spousta zajímavých přednášek.
Elon Musk na akci We, Robot (YouTube, 𝕏) představil Robotaxi, Robovan a vylepšeného Tesla Bota (Optimus).
Internet Archive je offline (𝕏, Bluesky, Mastodon). Unikly údaje 31 milionů uživatelů. Probíhal / probíhá na něj DDoS útok.
Alyssa Rosenzweig se v příspěvku na svém blogu rozepsala o hraní AAA her na Asahi Linuxu. Na YouTube je záznam její včerejší přednášky na XDC 2024 (X.Org Developer's Conference).
Vláda schválila Národní polovodičovou strategii: Česká republika má velký potenciál stát se významným hráčem v oblasti výroby čipů, zejména v evropském měřítku. Využít tento potenciál je cílem Národní polovodičové strategie, kterou připravilo Ministerstvo průmyslu a obchodu ve spolupráci s experty, a která navazuje na evropský Akt o čipech.
V lete vyšiel Aeonwave 4.0, ktorý niekoľkonásobne menej vyťažuje procesor pri interpretácií priestorového zvuku než OpenAL Soft. Autor hľadá prispievateľov do knižnice libaaxopenal za účelom pridania ALC_EXT_EFX rozšírení využívaných napr. v hre Doom 3 cez port Dhewm3 v Linuxe.
Linuxová distribuce Ubuntu 24.10 „Oracular Oriole“ byla vydána. Jde o průběžné vydání s podporou 9 měsíců. Obsahuje mj. Linux 6.11 či GNOME 47 s několika odkazy na první vydání Ubuntu (4.10 „Warty Warthog“) před 20 lety. K dispozici jsou také oficiální deriváty s odlišnými výchozími desktopovými prostředími anebo balíky aplikací.
Řešení dotazu:
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.
2.8.2012 11:20
pavlix | skóre: 54
| blog: pavlix
Je tam sice i nějaké pole na účel, ale takhle jemně se to nerozlišujebych 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...
(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.
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).
Tím jsem reagoval na: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é.
Otázka je, nakolik je závazná ta "TLS WWW" částK 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ě.
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".
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
SRV (MX) záznamy.
2.8.2012 11:22
pavlix | skóre: 54
| blog: 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.
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.
2.8.2012 11:26
pavlix | skóre: 54
| blog: pavlix
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].
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.
2.8.2012 11:49
pavlix | skóre: 54
| blog: pavlix
IPSec je povinnou součástí implementace IPv6Jak 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 tunnelNa 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 DNSObě 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žitouNaopak, 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í.
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ímIPSec je povinnou součástí implementace IPv6Jak jsem psal někde výše, už není.
).
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é?
Souhlas, ale na dělání VPN existuje spousta jiných toolů, proto mě tohle využití tolik nezajímá.Vcelku použitelné to bude pro udělání VPN - režim tunnelNa IPv4 zcela běžně používané, není důvod si myslet, že by tomu bylo na IPv6 jinak.
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...Jinak řečeno, kromě použití na administrativně moje tunely,To je hlavní použití.
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...
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 diskutovatkdyž 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í.
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ě.
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.
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".
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ěžší :(
3.8.2012 01:50
pavlix | skóre: 54
| blog: 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.
3.8.2012 01:44
pavlix | skóre: 54
| blog: 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.
3.8.2012 09:56
pavlix | skóre: 54
| blog: 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.
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).
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.
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...
3.8.2012 01:53
pavlix | skóre: 54
| blog: pavlix
No ta důvěra je přesně k tomu, že věřím, že ta adresa je ta adresaTo 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.
3.8.2012 01:41
pavlix | skóre: 54
| blog: pavlix
Moje informace vycházela z knížky pana Satrapy aktualizované ke konci roku 2011V 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 NICMá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í :).
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...
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...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ží.
3.8.2012 10:12
pavlix | skóre: 54
| blog: 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 IEAle 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ánkyNemá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.
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).
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.
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í).
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.
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
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.
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.
za vystavení certifikátu navíc u akreditované CA půjdu bručetVazne? Na zaklade jakeho bodu trestniho zakoniku?
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.
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
4.8.2012 00:46
pavlix | skóre: 54
| blog: 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ší“.
Přeju to samé ohledně postoje „právníci vše vyřeší“.Zcela očividně jsi to nepochopil...
4.8.2012 00:57
pavlix | skóre: 54
| blog: pavlix
4.8.2012 00:43
pavlix | skóre: 54
| blog: 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ě.
4.8.2012 00:41
pavlix | skóre: 54
| blog: 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 :).
Já si myslím, že se CZ.NIC šestým RIRem nestane.A kdo říká, že se NIC má stát RIRem?
4.8.2012 00:58
pavlix | skóre: 54
| blog: pavlix
Vcelku použitelné to bude pro udělání VPN - režim tunnelTady 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.
3.8.2012 01:58
pavlix | skóre: 54
| blog: pavlix
BTW, IPSec tunnel mode je co ze tyce formatu paketu naprosto shodny s IPIP v IPSec transport mode, tedy alespon na IPv4Díky za odpověď :).
3.8.2012 01:57
pavlix | skóre: 54
| blog: pavlix
Tiskni
Sdílej:
