Když John Postel v roce 1980 definoval pravidlo robustnosti (známé také jako Postelův zákon), tak se zdálo být rozumné jej definovat jako: „Buď liberální v tom, co přijímáš, ale buď striktní v tom, co vysíláš.“ O pár let později bylo toto pravidlo rozšířeno v RFC 1122 o požadavek nejen přežít divoké prostředí špatně naformátovaných paketů, ale také nadále spolupracovat a komunikovat s implementacemi, které se takto neslušně chovají. Internet byl ve svých počátcích a bylo těžké odhadovat, jaká všechna zařízení budou do sítě připojena a jak dobře nebo špatně budou naprogramována.
Nicméně zpátky k návrhu internetových protokolů. Již o deset let později v roce 2001 popisuje Marshall Rose v RFC 3117 problémy, které přináší aplikace principu robustnosti do interoperability aplikací. Představte si, že máme dvě implementace:
- implementaci Locke, kterou psal hodně šikovný programátor a docela si s ní vyhrál, takže je velmi liberální a dokáže přijmout a zpracovat libovolně naformátovaný paket a…
- implementaci Demosthenes, kterou psal programátor hodně ve spěchu a posílá takové pakety, ze kterých se dělá trochu špatně i směrovačům po cestě.
Locke si s Démosthenem v klidu dokáží povídat. Locke se sice občas diví, co to Démosthenés říká, ale vcelku dobře si rozumějí a komunikace volně plyne. To se ovšem radikálně mění ve chvíli, kdy na scénu přichází implementace Rochester, kde byl programátor velmi striktní a naprogramoval Rochestera tak, že přesně odpovídá specifikaci protokolu a odmítá jakékoli odchylky od standardu, zatímco si Locke s Rochesterem může bez problému popovídat (ostatně jsou oba dva angličané). Dokonce pro Lockeho je komunikace s Rochesterem jednodušší, protože oba dva při komunikaci dodržují správný komunikační protokol. Naopak Démosthenés má se svou antickou řečtinou najednou problém. Démosthenés se může snažit mluvit s Rochesterem jak chce, ale ten mu prostě nemůže rozumět, protože nemluví společným jazykem.
A co by na to řekli All Blacks? Kdyby se o Postelově zákonu dozvěděli v půlce prosince minulého roku, tak by asi zareagovali takto:
Proč? Správci novozélandské domény .NZ v půlce prosince dokončili proces implementace DNSSEC, vypublikovali správný klíč a poslali jej do kořenové zóny. Následně byli upozorněni, že jejich klíč má nezvyklou sekvenci znaků v místě, kde je uveden RSA exponent. Pro srovnání si tento rozdíl pojďme ukázat konkrétně.
Klíč pro doménu .CZ vypadá takto:
cz. IN DNSKEY 257 3 10 ( AwEAAaVU8EMQrZ6Tix2zBaAmizMQ7W0m94qSJUXV4eVW S9ZpXh9t1uj8U/B5Nnqge4G0Te0/NJIqflihZKXs8Hyh JqjF852RKnvNWPu2wMujYjHP0T4lIhu4rTym9+sPNsfi oqvMyyDeqyhVPx21nvLW5oaKjaLd3XJxijRbDTddRU97 mJVVS50PKdDmh5n/4KdRKV7ifR2Ap8L1bvUiCOxl4GAq LoXft+L896bkVj6mefdCSyYaCbgsDc2+10ZBOSF1t89N J6O1yO+y5/7vS3dYKEqj+p4ygaCY0spvrhZxncUeASix g224bNYZM5TLk2/YoKgAEjaIoCwu7SAXB5iUvLU= ) ; key id = 14568
Pokud rozkódujeme prvních pár znaků, dostaneme následující výstup:
$ dig dnskey cz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd -l 12 -b
0000000: 00000011 00000001 00000000 00000001 10100101 01010100 .....T
0000006: 11110000 01000011 00010000 10101101 10011110 10010011 .C....
Délka exponentu je uvedena na prvním místě (00000011), tj. exponent je dlouhý tři bajty. Exponent je v tomto případě 65537 (00000001 00000000 00000001).
DNSSEC klíč pro novozélandskou doménu vypadal takto:
nz. IN DNSKEY 257 3 8 (
BAABAAGwfTiEoh71o6S55+Mdy1qqVRnpKY1VHznrv+wx
rPfvRGB5VivFFPFN+33fsaTxJQTceOtOna7IKxTffj6p
bBG4a9vtk2FqF551IwXomKWJnzRVKqYzuAx+Os/5gLIN
BH7+qRWAkJwCdQXIaJGyGmshkO5Ci5Ex5Cm3EZCeVrie
0fLI03Ufjuhi6IJ7gLzjEWw84faLIxWHEj8w0UVcXfaI
2VL0oUC/R+9RaO7BJKv93ZqoZhTOSg9nH51qfubbK6FM
svOWEyVcUNE6NESYEbuCiUByKfxanvzzYUUCzmm+JwV7
7Ebj3XZSBnWnA2ylLXQ4+HD84rnqb1SgGXu9HZYn
) ; key id = 2517
Opět rozkódujeme prvních pár bajtů:
dig dnskey nz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd
-l 12 -b
0000000: 00000100 00000000 00000001 00000000 00000001 10110000 ......
0000006: 01111101 00111000 10000100 10100010 00011110 11110101 }8....
Již na první pohled je vidět, že exponent je v tomto případě delší (00000100), tj. 4 bajty. Nicméně hodnota exponentu (00000000 00000001 00000000 00000001) zůstává stejná, tedy rovna 65537.
V čem je tedy zádrhel? Dle standardu RFC 3110, který definuje kódování RSA klíčů pro použití v DNS, jsou počáteční nuly v exponentu zakázány. A nyní se dostáváme zpátky k počátečnímu sporu Postel vs Rose.
Správci novozélandské domény samozřejmě nasazení DNSSEC klíče pečlivě otestovali a vše správně fungovalo. Jinými slovy Démosthenés si při testování povídal s Lockem. Nakonec se bohužel ukázalo, že na scéně se skrýval Rochester v podobě implementace rekurzivního resolveru od firmy Nominum, která je při dekódování exponentu velmi striktní a po přijetí klíče novozélandské domény selhala při DNSSEC validaci. Toto nakonec vedlo k tomu, že bylo zapotřebí klíč novozélandské domény opravit a do kořenové zóny poslat klíč ve správném kódování.
Jaké z toho nakonec plyne poučení? Druhá část pravidla robustnosti stále platí, je zapotřebí být velmi striktní při implementaci protokolu, aby byla zajištěna dobrá interoperabilita. Nicméně je jistě ke zvážení, jestli nebýt striktní také při implementaci přijímací části, aby bylo možné odhalit chyby včas již při testování.
A co si myslíte vy? Je lepší být v implementaci striktní nebo liberální?
Ondřej Surý
P.S. Tento článek, respektive odkaz na něj, zahajuje naši komunikaci na Google Plus. Pokud tedy tuto sociální síť využíváte a chcete být informováni o našich projektech a aktivitách, přidejte si nás do svých kruhů.
O jednom řešení, které sedí
Jak jsme se nedávno dozvěděli z novin a televizí, naši mladí (čti nezletilí) lámou rekordy, snad i celoevropské, v pití alkoholu. Tyto informace nenechaly nečinnými zaměstnance společnosti dTest, kteří vyzkoušeli 12 českých eshopů věnujících se i prodeji alkoholických nápojů. Výsledek nepotěší a taky nepřekvapí: 10 z 12 online obchodů umožňuje prodej alkoholu osobám mladším 18 let. Zbývající dva z toho vyšly bez ztráty kytičky, a to proto, že mají propracovanou distribuci, na jejímž konci je fyzické ověření odběratele zboží při jejím předávání.
Co si z toho vzít? Alkohol je mezi mladými stále velkým fenoménem. Ten jak vidíme pomáhají svým způsobem posilovat i někteří provozovatelé elektronických obchodů. Dobrá zpráva je, že tu jsou ale i takoví, kteří se drží zákona. A kromě jednoho již aplikovaného řešení se nabízí doslova na míru ušitá služba umožňující vyžadovat při objednání některé, v tomto případě podstatné osobní údaje. Na jejich základě by potom bylo zájemci o alkohol povoleno nebo nepovoleno toto zboží získat.
Snad se časem najdou další a další příklady z praxe, které povedou po té správné cestě, ať už je zvolený způsob ověření věku jakýkoliv. Za jak dlouho se tak stane, kdo ví.
VS
Teredo pod drobnohledem
Sdružení CZ.NIC provozuje již přes půl roku vlastní teredo relay, čímž umožňuje rychlejší a komfortnější užívání této služby pro české uživatele. Rozhodli jsme se tedy podívat, jak využívaná a potenciálně užitečná tato služba je.
Uživatelé operačních systémů firmy Microsoft mají teredo v základním stavu povoleno a pokud jim nebrání v cestě restriktivní firewall nebo problematický NAT, můžou využívat veškeré výhody, které IPv6 nabízí. Získání IPv6 adresy (nejen) pomocí terada přináší jednu nespornou výhodu, a to přímou adresovatelnost. Obnovuje se tak jeden ze základních principů internetu, kterým je možnost přímé komunikace každého s každým. Při tomto konstatování se již lidem začnou vybavovat p2p služby jako například bittorrent. O oblibě této kombinace svědčí i návody a rady na zprovoznění tereda, které lze nalézt na fórech věnovaných právě bittorrentu.
Bohužel není úplně snadné určit, co je a není bittorrent. Dříve byl pro tyto služby vyhrazen rozsah portů 6881 – 6999, ovšem takový provoz považuje mnoho ISP za nežádoucí a omezování na základě čísla portu bylo tou nejsnazší variantou. Začala se proto měnit čísla portů a dnes si již většina klientů volí náhodný port pro komunikaci při každém startu. Zkusili jsme se podívat alespoň na výše zmíněné staré porty a další zajímavé statistiky.
Data pocházejí ze dne 1. února 2012. Za tento den „proteklo“ teredo servery 350,7 GB dat, což se rovná průměrnému datovému toku 32,4 Mb/s. Servery zpracovaly data od 5,3 milionů unikátních IP adres. 500 IP adres s nejvíce přenesenými daty vytvořilo 126,7 GB přenesených dat (36,13 %). Jedná se o zdrojové IP adresy; není již rozlišeno, zda data byla z této adresy stahována nebo zda je tento uzel nahrával na vzdálený server.
Rozdělení zdrojových adres dle zemí ukazuje následující graf.
Protokoly TCP a UDP jsou zastoupeny rovnoměrně a každý tvoří přibližně 49 % provozu, zbytek je převážně ICMPv6.
Z cílových portů vyčnívá port 35691, data směřující na tento port tvoří 3,3 % veškerého provozu. Další v pořadí, port 43997, už tvoří pouze 0,9 %. 20 nejvytíženějších portů tvoří 13,09 % procent veškerého provozu, zastoupení jednotlivých portů je vidět na následujícím grafu.
Webový provoz (port 80 a 443) se na celkovém objemu podílel 220,6 MB (cca 0,06 %). Oproti tomu provoz na „dobře známých“ torrentových portech byl 11,1 GB (3,17 %). Jak již bylo uvedeno výše, nelze určit, zda se jedná opravdu o torrenty, ani zda se torrenty neskrývají za jinými porty, ovšem port 6881 se objevuje i ve výše uvedeném grafu…
Petr Černohouz
Na 8. března nepřipadá jen MDŽ
Pokud vám 8. března přestane fungovat „internetové připojení“, můžete být jednou z obětí trojského koně zvaného DNSChanger. Jedná se o trojského koně, který provádí změnu DNS serverů v operačním systému. Místo vámi nastaveného DNS serveru nastaví jednu z předem daných IP adres.
Odhaduje se, že po celém světě mohou být napadeny asi čtyři milióny počítačů. Tento trojan napadá jak počítače s OS Windows, tak i počítače s MacOS. FBI odkryla síť podvodných DNS serverů, používaných tímto trojským koněm již v listopadu 2011; v té době získala povolení soudu k dalšímu provozování této sítě. Toto povolení však končí právě 8. března. Pokud FBI nezíská další soudní povolení, bude provoz těchto DNS serverů ukončen. To znamená, že počítače napadené tímto zákeřným trojanem nebudou schopné resolvovat doménová jména na IP adresy. Podle FBI je velmi pravděpodobné, že počítače nakažené tímto malware budou napadené i dalšími viry. Možná tedy toto „vypnutí“ napadených počítačů pomůže i k vyčištění těchto strojů, když už jejich majitelé zjistí, že mají nějaký problém.
Zda je Váš OS napaden si můžete ověřit na adrese www.dns-ok.de. A pokud zjistíte, že jste jednou z obětí, použijte k nápravě tento nástroj. Další programy určené i pro MacOS najdete například na adrese www.dnschanger.com.
Pavel Bašta
Máme se bát operace Global blackout?
Na pastebin.com se nedávno objevila zpráva, která slibuje, že 31. 3. 2012 proběhne masivní DDoS útok na DNS root servery v rámci tak zvané operace Global Blackout. Čtenářům našeho blogu je asi zbytečné připomínat, že znefunkčnění všech root serverů by znamenalo výpadek DNS a tím i de facto vypnutí Internetu. Tak jako u všech zpráv tohoto druhu je pochopitelně těžké určit, jak moc vážně se tím mají bezpečnostní týmy zabývat. O neuchopitelnosti Anonymous již bylo napsáno mnoho. Každopádně se tomuto možnému útoku věnovala některá poměrně čtená média a zdá se, že i DNS operátoři berou hrozbu částečně vážně; problém byl poměrně důkladně diskutován v uzavřených operátorských bezpečnostních listech. K tomuto oznámení se sluší odpovědět následující otázky:
- Jak těmto útokům čelit?
- Jakou mají vůbec šanci?
- Proběhne vůbec nějaký útok, je tato zpráva hodnověrná?
Jak útoku čelit
Především stojí za to ve stručnosti zmínit, jak vlastně tento útok funguje. Jde o takzvaný DNS amplification attack. Principem tohoto útoku je, že útočník posílá podvržené dotazy na DNS resolvery. Jako zdrojovou adresu dotazu podvrhne IP adresu cíle, na který chce útočit. Díky jednoduché vlastnosti DNS, že odpověď je vždy větší než dotaz, dosáhne zesílení svého útoku. Vhodně zvolenými typy dotazu lze i z domácího připojení vygenerovat poměrně slušný tok dat. Takto vygenerovaný datový tok od více útočníků, pak může zahltit DNS server(y) či přístupové linky k nim. Z principu útoku je zřejmé, že útočník potřebuje ke své činnosti otevřené DNS resolvery, ale je bohužel smutnou skutečností, že těch je v současném Internetu více než dost, ačkoliv na toto téma byla vydána celá řada varování.
Metod, jak útoku čelit, je celá řada. Především by velice pomohlo, kdyby koncoví ISP dodržovali doporučení z BCP-38 nebo-li kdyby filtrovali odchozí packety, které nemají ve zdrojové adrese IP z jejich rozsahu. Tím by zabránili svým uživatelům podvrhovat IP adresy.
Druhou, mnohem problematičtější možností, je filtrovat všechny DNS dotazy z root serverů. Tyto servery nemají důvod se nijak ptát. Problémem tohoto řešení je, že je šité na míru pouze tomuto jednotlivému útoku a změna cíle útoku by znamenala další konfigurace. Navíc i IP adresy root serverů se čas od času změní a je šance, že aplikace této obrany napáchá více škody než užitku.
No a samozřejmě nejpřirozenější je neinstalovat zbytečně otevřené DNS resolvery. Většina existuje bohužel jen jaksi „omylem“, někteří správci bohužel nejsou příliš pečliví a s konfigurací DNS resolverů si tolik hlavu nelámou.
Šance takového útoku
Ačkoliv se pořád hovoří o 13 root serverech, již to dávno není tak, že 13 počítačů drží kořenovou zónu. Naopak velká většina těchto serverů má zrcadla všude po světě. Rekordmanem v počtu kopií je písmeno J, jež spravovuje Verisign, a které je na 70 místech. Samozřejmě i v každém z těch míst není jeden počítač, ale farma serverů. Abychom i my, sdružení CZ.NIC, přispěli k bezpečnosti, financujeme provoz dvou zrcadel v Praze, a to serverů F a L. Jak už to bývá, technologicky pozadu jsou, alespoň v tomto směru, servery spravované státními institucemi. Anycasting nevyužívají servery spravované ISI, NASA a University of Maryland. Pouze dvě kopie má i server spravovaný americkou armádou. Je možné, že skutečně masivní útok by mohl vyřadit z provozu právě tyto servery s malým počtem zrcadel, ale je velice obtížné shodit službu, jež má desítky dobře spravovaných kopií. Nemyslím si tedy, že by Anonymous měli v tomto příliš velkou šanci. Shodit DNS systém je mnohem větší oříšek než útočit na webové servery. Mimochodem, v minulosti již několik masivních útoků na root servery proběhlo a zatím se nikomu nepodařilo shodit všech 13.
Bude útok?
Především s ohledem na předchozí informace si myslím, že 31. března se může stát hodně věcí, ale rozhodně to nebude útok na DNS. Celé toto prohlášení vnímám spíše jako hoax, může jít klidně o odpoutání pozornosti. Ani Anonymous se jistě nebudou pouštět do akcí, u kterých je v podstatě mizivá šance na úspěch. Navíc tento útok by byl poněkud v rozporu s jejich dosavadní snahou o „svobodný Internet“.
Každopádně pozitivní na tomto „hoaxu“ je, že trochu přitáhl pozornost směrem k nastavení filteringu podvržených zdrojových adres a k nastavení DNS resolverů. Správná konfigurace obou těchto věcí může obecně pomoci při zvýšení bezpečnosti Internetu. Schválně se zkuste zamyslet, jestli v tomto nemůžete něco vylepšit ve vlastní síti.
Ondřej Filip
Slabý generátor náhodných čísel umožňuje faktorizovať RSA moduly
Akoby nestačilo napadnutie certifikačných autorít v roku 2011 a nedávne priznanie Trustwave, že vydávala certifikáty na korporátne man-in-the-middle útoky, našla sa ďalšia trhlina spôsobená nesprávnou implementáciou generátora náhodných čísel (kauza s debianími slabými kľúčami bola podobne spôsobená chybou v náhodnom generátore).
Tým výskumníkov vedený A. Lenstrom z EPFL našiel v databáze certifikátov z SSL Observatory a iných zdrojoch ďalšie páry kľúčov, ktoré zdieľajú v RSA module prvočíslo. To znamená, že použitím obyčajného vyše 2000 rokov starého Euklidovho algoritmu je možné niektoré RSA moduly faktorizovať. Z ich výsledkov vyplýva, že zhruba 2 z 1000 kľúčov idú týmto spôsobom faktorizovať. Testovali celkovo 11.7 milióna RSA, ElGamal, DSA a ECDSA kľúčov, z toho šlo uvedenou metódou prelomiť cca 27000 RSA kľúčov.
DSA a ElGamal kľúče nevykazovali žiadne podobné štatistické anomálie, ECDSA kľúč bol len jeden. Z uvedeného sa dá usudzovať, že PGP a GnuPG slabým generátorom netrpia (pretože väčšina testovaných ne-RSA kľúčov bola vygenerovaná jedným z týchto softwarov). Zatiaľ sa nevie, ktoré implementácie vygenerovali zmienené slabé RSA kľúče.
V diskrétnom grafe použitom na modelovanie zdieľaných prvočísiel a modulov je prvočíslo reprezentované vrcholom, hrana spája dve prvočísla patriace k modulu (moduly s viacerými prvočíslami neboli nájdené). V ideálnom prípade by vrcholov malo byť dvakrát toľko čo hrán, tj. žiadny pár RSA modulov nezdieľa prvočíslo. V Lenstrových výsledkoch sa ale nachádza 1995 nesúvislých komponent s tromi a viac vrcholmi.
Preložené do „nematematičtiny“: existuje 1995 skupín po niekoľkých RSA kľúčoch, kde keď poznáte prvočísla aspoň jedného z vrcholov, môžete faktorizovať ostatné. Rovnako znalosť dvoch modulov z rovnakej skupiny umožňuje použiť Euklidov algoritmus na zistenie jedného z prvočísiel a teda faktorizovanie oboch modulov.
Lenstra tiež zmieňuje dlhšie známy fakt o zdieľaní RSA modulov v X.509 SSL/TLS certifikátoch. Podľa jeho údajov 4 % kľúčov sú zdieľané, často medzi nesúvisejúcimi organizáciami alebo jedincami. Časť „s nesúvisejúcimi organizáciami“ ale treba brať trocha s rezervou.
O zdieľaní kľúčov v certifikátoch som mal pár debát s rôznymi výskumníkmi, napríklad s Ralphom Holzom, ktorého práca SSL Landscape je spomínaná v Lenstrovom príspevku. Obaja sme našli rôzne kľúče zdieľané medzi zdanlivo nesúvisejúcimi stranami, ale keď sa človek do toho začal vŕtať viac, tak zistil, že nejak prepojené sú (ale to treba robiť ručne prehliadaním obchodných registrov, atp.). Napriek tomu existujú kľúče ktoré sú zdieľané medzi organizáciami bez toho, aby to bolo úmyselné (napríklad niekto nezmení na VPS hostingu SSH/SSL kľúče, ktoré sa nakopírujú z inštalačného obrazu).
Podľa iného článku sa problém týka hlavne embedded zariadení, ktoré majú pri generovaní kľúčov malý zdroj entropie, takže netreba až tak moc panikáriť. Linkovaný článok obsahuje veľa technických podrobností, hlavná pointa je, že najskôr sa to netýka internetového bankovníctva a iných vysoko citlivých aplikácií.
Záujemcov o podrobnosti odkážem na pôvodný príspevok od Lenstra, et al publikovaný na eCrypt archíve (pdf).
Ondrej Mikle
Kolik bude nových TLD?
Už je to více než měsíc od chvíle, kdy ICANN nastartoval proces vzniku nových generických domén. Sám ICANN svůj proces designoval na 500 nových domén. Pokud bude žádostí více, plánuje ICANN, že jejich posuzování rozloží do více bloků – první o velikosti 500 a další po 400. Aby bylo možné žádost o doménu podat, je nutné nejdříve zaregistrovat žadatele. Ten pak má možnost požádat o přidělení slotů pro maximálně 50 domén. Za vytvoření každého slotu pak musí žadatel složit minimálně 5 000 USD.
ICANN nedávno oznámil, že počet registrovaných uživatelů překročil 100. Jsme teprve na začátku druhé třetiny časové periody, takže těžko odhadovat, jak se situace vyvine, ale zatím to není nijak omračující číslo. Nedá se předpokládat, že všichni registrovaní uživatelé nakonec požádají o domény, ani že ti aktivní zažádají vzhledem k ceně o nějaké velké počty domén. Nicméně do 29. března je ještě čas pro registrace uživatelů. Do 12. dubna poté budou muset podat všechny své žádosti. Zcela jasno tedy bude až pár dnů po tomto datu.
Kolik odhadujete, že jich nakonec bude? A bude nakonec nějaká doména z Česka?
Ondřej Filip
Další linie v obraně internetu v ČR – ACTIVE24-CSIRT
Tento měsíc došlo k významné události na poli bezpečnostních týmů v ČR. Společnost ACTIVE 24 ustavila svůj vlastní CSIRT tým, který je navíc nově registrován u úřadu Trusted Introducer působícím v rámci evropské organizace Terena. Tento úřad sdružuje bezpečnostní týmy ze všech oblastí, tedy jak národní a vládní, tak i například CSIRT týmy provozovatelů internetového připojení, poskytovatelů služeb, výrobců hardware, bank nebo týmy působící v akademickém prostředí.
Aby CSIRT tým mohl získat staus listed, musí nejdříve splnit určité požadavky, jako například definovat oblasti, ve kterých je způsobilý konat, a jasně a veřejně zpřístupnit kontaktní informace o týmu, jeho složení a další nezbytné údaje. Dále pak musí jeho žádost o zařazení do statusu listed podpořit dva již akreditované týmy. Toto vše zaručuje, že ACTIVE24-CSIRT splňuje všechna základní kritéria nezbytná pro správné fungování týmu typu CSIRT.
Za nás, tedy za členy bezpečnostních týmů CZ.NIC-CSIRT a CSIRT.CZ, mohu říci, že tuto iniciativu společnosti ACTIVE 24 velice vítáme. Funkční a dobře vytvořená infrastruktura CSIRT týmů totiž pomáhá při rychlejší reakci na bezpečnostní incidenty a snižuje tak zároveň závažnost jejich dopadu. Navíc se v tomto případě jedná o první vlaštovku mezi společnostmi z komerční sféry v ČR. Více podrobností najdete v oficiální tiskové zprávě.
Bezpečnostnímu týmu ACTIVE24-CSIRT bych rád popřál, ať se mu daří naplňovat jeho poslání, a nám všem, aby se našlo více společností, které budou jejich příkladu následovat.
Pavel Bašta
Digitální identity a nové dítko na poli standardů – OpenID Connect
Přestože je téma digitální identity (a souvisejících distribuovaných „single sign-on“ přihlašovacích mechanismů) staré možná jako internet sám, troufám si tvrdit, že jeho největší okamžiky teprve přijdou. Po úspěších centrální správy identit, které v současnosti ukazují veřejné služby jako Facebook, nebo Google+, přirozeně pokukují propagátoři různých forem e-governmentu. V něm mohou některé mechanismy fungovat na podobných principech, přičemž přidaná hodnota je určitě validita údajů identit, které veřejné služby mohou jen těžko dosáhnout. Nesmělé náznaky v podobě elektronických občanek u nás, připravované rozhraní k datovým schránkám, ale i aktivity vlád v celém světě (německý projekt de-ident, americká strategie pro důvěryhodné identity v kyberprostoru NSTIC, nebo projekt evropské identity STORK) naznačují, že tato oblast v blízké době zažije velké změny. Bylo by jistě užitečné, kdyby jednotlivé implementace místo proprietárních řešení vycházely z konsensuálních standardů, které i v této oblasti existují a není jich málo.
Jednou z platforem, na které kooperují autoři těchto standardů, je například Internet Identity Workshop. V rámci pravidelných konferencí této platformy, které se konají dvakrát ročně si zástupci nejrůznějších standardizačních organizací vyměňují informace o novinkách ve svých produktech. Na následujících řádcích bych rád shrnul nejvýznamnější standardy na tomto poli a upozornil na nejnovější aktivitu, která se objevila v průběhu minulého roku.
Asi nejstarším zástupcem protokolů této kategorie je SAML. Jeho první verze pochází z roku 2002 a zatím poslední verze z roku 2005. Za tento, na jazyku XML založený, protokol nese odpovědnost standardizační organizace OASIS, známá svými dalšími „XML aktivitami“ jako Docbook nebo DITA. SAML se poměrně pevně usadil v akademickém světě. Například u nás je to protokol, na kterém funguje Česká akademická federace identit známá pod zkratkou EduID, provozovaná sdružením CESNET. Takže pokud máte účet v systému své vysoké školy, s velkou pravděpodobností můžete používat SAML pro přihlašování u systémů poskytovatelů služeb, které jej podporují. Těch bohužel není mnoho a zejména jsou to opět akademické instituce. Jedním z těchto poskytovatelů služeb by, alespoň podle dokumentace, měly být i GoogleApps.
V roce 2005 se na poli standardů objevil protokol OpenID. Jeho jádro prošlo vývojem a ustálilo se na verzi 2.0 z konce roku 2007. V průběhu dalších zhruba tří let si získal velkou popularitu a podporovali ho i velcí hráči jako Google nebo Microsoft. Za účelem rozvoje tohoto standardu vznikla organizace OpenID Foundation, která sdružuje jak zástupce poskytovatelů identit, tak poskytovatelů služeb. U nás byl dlouho jediným větším průkopníkem této technologie Seznam.cz. Předloni jsme si OpenID jako komunikační protokol zvolili i my s naší službou ověřených identit mojeID. Důležitou vlastností tohoto protokolu je možnost standardizované výměny atributů identity.
Při práci na implementaci OpenID do služby Twitter vznikla další významná technologie pojmenovaná OAuth. Na rozdíl od OpenID má tato technologie jako cíl umožnit poskytovatelům služeb zabezpečený přístup k nějaké obecně libovolné sadě funkcí, kterou jiná služba nabízí. První draft byl publikován v roce 2007 a jeho vývoj se v průběhu roku 2010 přesunul na půdu asi nejvýznamnější internetové standardizační organizace IETF. V této době probíhá práce na dokončení verze 2.0 standardu, jehož finální vydání ve formě RFC je „snad“ otázkou příštích několika týdnů. Po Twitteru přijal tuto technologii za vlastní také Facebook a nakonec ji do repertoáru svých autentizačních mechanismů přidal i Google.
Co se týká srovnáni OAuth a OpenID tak OAuth sice nabízí asi jen polovinu vlastností které má OpenID, ale na druhou stranu to dělá mnohem lépe. Vzhledem k tomu vzniklo v průběhu posledních dvou let několik pokusů, jak zkombinovat to nejlepší z nich do ideálního výsledku. Těchto několik pokusů se nakonec spojilo dohromady a v polovině roku 2011 byl prezentován výsledek v podobě specifikace nazvané OpenID Connect. Toto řešení ve své „spodní“ části využívá OAuth 2.0 a obaluje ho vlastnostmi specifickými pro OpenID. Zajímavou změnou je i následování trendu a nahrazení jazyka XML na příslučných místech jazykem JSON. Od prosince je návrh standardu v připomínkovém řízení a pokud vše půjde hladce, mohli bychom se už letos dočkat jeho finální verze. Za touto specifikací stojí všichni velcí hráči jako Facebook, Google i Microsoft což jí dává poměrně dobré vyhlídky na její budoucí rozšíření.
Jak je vidět, ve světě digitálních identit je hodně živo a my věříme, že minimálně u nás nechá služba mojeID v této diskuzi viditelný otisk. Rodina použitelných specifikací je široká a rozhodně neumírá. Nové generace těží ze zkušeností svých předchůdců a většinou přidávají nové pohledy a nové myšlenky. Z pohledu mojeID samozřejmě nepřestáváme sledovat aktuální vývoj. Charakter této služby nijak nebrání tomu použít několik přístupových technologií paralelně a tím nabídnout poskytovatelům služeb větší výběr možností implementace. Pokud zjistíme vzrůstající poptávku po některém ze zmiňovaných protokolů, pokusíme se této poptávce vyhovět.
Jaromír Talíř
Statistika DNSSEC resolverů
Jako správce české domény máme poměrně dobrý přehled o tom, kolik existuje zabezpečených domén s koncovkou .CZ. Jak to ale vypadá na druhé straně?
Samotné měření toho, kolik je validujících resolverů, není bohužel jednoduchá záležitost. Žádný resolver nehlásí autoritativnímu serveru „já jsem validující“, takže pro detekci lze použít nepřímé techniky, které využívají znalost toho, jakým způsobem validující resolver žádá o DNS záznamy. Asi nejkomplexnější metodu měření navrhl Olafur Gudmundsson a Steve Crocker na konferenci SATIN 2011; popsanou ji najdete v článku Guðmundsson, Crocker: Observing DNSSEC validation in the wild. Tuto metodiku jsme použili pro naše měření. Kromě toho, že nemá smysl znovu vynalézat kolo, je jednotná metodika také důležitá pro srovnání s ostatními registry. V případě, že by každý registr vynalézal znovu a znovu metodiku měření validujících resolverů, bylo by následné porovnávání výsledků příslovečným porovnáváním jablek s hruškami.
Stručné shrnutí metodiky:
Pro zjednodušení bereme jednu IP adresu za jeden resolver, i když ve skutečnosti se za jednou IP adresou může v případě NATu skrývat více resolverů.
Pro detekci validujících resolverů se metodika snaží hledat odlišnosti mezi chováním „zastaralých“, tedy nevalidujících resolverů, a těch validujících. Ty se liší především dotazy na DS a DNSKEY záznamy:
- dotaz na DS záznam – resolver označíme jako určitě validující
- opakovaný dotaz na DNSKEY záznam v časových intervalech odpovídající době platnosti (TTL) tohoto záznamu – resolver také označíme jako určitě validující
- samostatný dotaz na DNSKEY záznam – resolver označíme jako pravděpodobně validující
Z charakteru protokolu DNS vyplývá, že není možné, aby byla tato metodika absolutně spolehlivá. K jistému zjednodušení dochází proto, protože na straně autoritativního serveru není možné poznat, zda-li položený dotaz na DS nebo DNSKEY záznam vznikl na základě požadavku na validaci nebo jej vznesl nějaký testovací nebo monitorovací skript. Ke zkreslení výsledků přispívají i lidé, kteří prostými dotazy pomocí různých DNS nástrojů mohou způsobit zařazení IP adresy do jedné z výše uvedených kategorií. Podrobnější diskuzi nad použitou metodikou lze nalézt ve výše zmíněném článku.
Nejprve uvedeme výsledky měření z dubna 2011 a pak pro porovnání z prosince 2011. Měření se provádělo vždy tři pracovní dny na stejných autoritativních serverech.
Data z dubna 2011
Dle popsané metodiky jsme v našich DNS datech našli 6767 určitě a 727 pravděpodobně validujících resolverů. Vzhledem k tomu, že většina provozovatelů DNS serverů nemá ve svých sítích pouze jeden server, tak jsme získané IP adresy následně museli ručně agregovat na základě vlastníka IP adresy serveru. Toto seskupení představuje další zjednodušení, které ovšem v případě resolverů s největším provozem můžeme zanedbat.
V následující tabulce naleznete top 10 českých společností jejichž sítě provozují validující resolvery (podle počtu DNSKEY dotazů zaslaných z validujících resolverů).
#DNSKEY ISP 5320 Casablanca 4224 České Radiokomunikace 3024 Telefónica O2 2089 GTS NOVERA 1624 UPL Telecom 1338 NFX 710 OMEGA tech 537 Dial Telecom 513 Ignum 441 VUT Brno
Data z prosince 2011
Počet validujících resolverů se zvýšil: evidujeme 11403 určitě a 1201 pravděpodobně validujících resolverů.
Pořadí top 10 českých společností počtu DNSKEY dotazů z validujících resolverů se mírně promíchalo:
#DNSKEY ISP 7894 Telefónica O2 6309 Vodafone 4342 ACTIVE 24 3441 UPC 3285 GTS NOVERA 3075 RIOMEDIA 2712 2 connect 2029 T-Mobile 1946 Casablanca 1737 CESNET
Pokud by vás zajímalo, zda váš ISP validuje, podívejte se na www.dnssec.cz, kde najdete jednoduchý a průkazný test. V komentářích nám potom můžete napsat, jak jste uspěli či neuspěli, kdo má nebo nemá zájem na větším bezpečí svých zákazníků.
Ondřej Mikle