Na právě probíhajícím setkání ICANN ve středoamerické Kostarice propagujeme další mítink, který se bude v červnu konat u nás v Praze. Součástí prezentace je obrázek notoricky známého panoramatu s Hradčany, na nějž mohou účastníci mítingu lepit pohlednice s atributy typickými pro Českou republiku. Mezi tyto „taháky“ patří třeba pivo, historické památky nebo krásné ženy. A právě ty se staly předmětem nedorozumění.
Poté, co si jeden účastník setkání stěžoval na údajný sexistický charakter těchto pohlednic, byly ze stánku na žádost ombudsmana organizace ICANN staženy. V pravidlech ICANN se píše, že všichni členové této komunity jsou si rovni a to nejen v otázkách pohlaví, ale i víry nebo rasy, s čímž naprosto souhlasíme.
Za CZ.NIC bych rád dodal, že diskriminace je v přímém rozporu s našimi hlavními firemními hodnotami. V žádném případě jsme neměli v úmyslu kohokoliv diskriminovat nebo urazit. Plně respektujeme pravidla organizace ICANN, a proto jsme ihned po předání stížnosti nálepky s motivem dívky z našeho stánku odstranili. Nicméně, dle našeho stále trvajícího přesvědčení není dívka na problematickém obrázku znázorněna ani náznakem v sexuálním kontextu. Ale jak je vidět, hranice politické korektnosti leží pro každého jinde, což se projevilo například i tím, že problém nastal až třetí den, a to poté, co tyto pohlednice řada účastníků vylepila na našem stánku. Do té doby se nikdo ani náznakem nezmínil, že by mu to nějak vadilo. Zajímavé také je, že po stažení těchto nálepek se na tabuli se vzkazy začalo objevovat i slovo HOLKY.
Vilém Sládek
Jak se rodil náš Knot DNS
Předminulý týden, při vydání první ostré verze autoritativního DNS serveru Knot DNS, jsme vám slíbili článek, který by přiblížil jeho vývoj od počátku až k finální verzi. Ten nám ale posléze narostl pod rukama do rozměrů už nevhodných pro publikaci na blogu, a tak vám zde nabídneme alespoň malou ochutnávku. Kde najdete více se pro jistotu dozvíte až na konci textu :-).
Opatrné začátky
Už je to téměř dva a půl roku, co začal v Laboratořích CZ.NIC pomalu vznikat nový autoritativní DNS server Knot DNS. Na podzim roku 2009 to začalo řadou experimentů a testů, zaměřených hlavně na výběr vhodné datové struktury pro ukládání zónových dat. Ta byla implementována jako první a kolem ní byl následně vystavěn první prototyp serveru s velmi jednoduchou síťovou vrstvou, který dočasně využíval knihovnu ldns pro ukládání dat specifických pro DNS.
Hlavní důraz byl kladen na modularitu návrhu tak, aby kteroukoliv část bylo možné kdykoliv nahradit lepší implementací. Velká část původního návrhu byla zachována i do finální verze. Na funkčním prototypu jsme si ověřili vhodnost zvolené datové struktury a také její potenciál pro vysokou rychlost vyhledání potřebných dat pro zodpovězení příchozího dotazu.
Jde do tuhého
Když na podzim roku 2010 přibyli do týmu další lidé, vývoj se výrazně rozhýbal. Knihovna ldns byla nahrazena vlastní DNS knihovnou, vznikla nová síťová vrstva a obsluha vláken. Během následujících měsíců byly některé části návrhu upraveny tak, aby nás co nejvíce přibližovaly našemu hlavnímu cíli – vyvinout vysoce výkonný DNS server. Při vývoji jsme však nezanedbali ani důkladné testování jak jednotlivých částí, tak celého serveru. Časem vznikl komplexní testovací framework integrující testy na různých úrovních, který je jednoduše rozšířitelný o další funkce a testovací scénáře.
Cílová rovinka (či spíš překážková dráha)
Po dvou letech vývoje, na podzim roku 2011, jsme si byli dostatečně jistí poskytovanou funkcionalitou, a proto jsme představili první veřejné vydání Knot DNS (verze označená jako 0.8). Již krátce po prezentaci na RIPE 63 ve Vídni, a také u nás na konferenci LinuxAlt v Brně, jsme začali dostávat první připomínky od uživatelů, které nám v následujících měsících pomohly vylepšit Knot DNS a opravit mnohé chyby, které jsme „nevychytali“ během předchozího vývoje. Verze 0.9 vydaná na začátku roku 2012 přinesla několik nových funkcí a oprav. Po ní jsme se intenzivně soustředili už jen na testování, hledání chyb a ladění, které nakonec vyústilo v první produkční verzi. Její Release Candidate byl zveřejněn na Valentýna a finální verze 1.0 pak byla vydána ve skutečně výjimečný den 29. února.
A jsme na konci tohoto blogpostu a tedy u toho, kde se o Knot DNS můžete dozvědět více. Jestli jsem vás navnadil, pokračujte v dalším čtení na Root.cz, pro který jsme připravili text skutečně mnohem obsáhlejší.
Ľuboš Slovák
Liberální nebo striktní? A co na to All Blacks?
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