Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
(...), protože se USA nechtějí vzdát toho, že budou jediné, kdo k nim bude mít přístupNo jo, to by nebyli voni, ti kluci americký vykutálený
rejpDík, opraveno.
Docela mě článek zaujal... chci se zeptat co se bude dít se záznamy, které nebudou podepsané? .
Odhaduju, že se to bude řešit nějak komplexně... resolver pošle info a tím je z obliga... software bude buď otravovat uživatele, že se mu něco nezdá, nebo je otravovat nebude a bude mít větší podíl na trhu (uživatele nechtějí aby je software obtěžoval, natož je stavěl svévolně před rozhodovací problémy) .Teprve až všichni přejdou tak začně aplikovat zabezpečení. Tady bude asi kámen úrazu, kdy výrobce SW určí, že už přešli všichni, jsou dvě varianty.. buď "přejdou všichni uživatele k němu", nebo "všichni ostatní výrobci už uživatele otravují a vypadá to že můj podíl na trhu už dál neporoste". (tím co bylo napsáno se nesnažím ukázat na žádného konkrétního výrobce softwaru)... je ten odhad správný?
Je můj odhad správný?
Aplikace to netusi a nemusi tusit. Resolver overi podpis a to co je dobre podepsane pusti. To co vubec neni podepsane pusti taky. Pouze pokud je podpis spatne - t.j. nekdo se snazi neco nekaleho udelat na podepsane domene, tak resolver odpovi ze doslo k chybe. Aplikace se tak nedozvi zadnou odpoved a nevleze napr. na podvodny web.
Vladki to napsal zcela spravne. Pokud je nektery zaznam nepodepsany, tak i z nadrazene zony vite, ze je nepodepsany a naopak. Takze pokud utocnik podvrhne nepodepsany zaznam a Vy vite, ze mel byt podepsany, tak jej odmitnete.
Analogie s HTTPS zde proste nefunguje, pokud nesedi podpis, je zaznam odmitnut. U DNS nemate moznost nejak klikat a nastavovat vyjimky.
Původně byl můj příspěvek delší, ale nakonec jsem jej redukoval... myslím že o http a https to tak úplně není, služby založené na vizuální reprezentaci jsou no s trochou nadsázky "ty méně náročné na otravování"... ale s příchodem ipv6 bude hooodně důležité DNS. To se myslím všichni shodneme. Že to zrovna prohlížeč může vyřešit při surfování je jedna věc...
pozor Internet není a nebude jenom o http.. telefonie, jabber, mail, přenos souborů, dynamicky tvořené bezpečné tunely, prostě přenos všeho možného... to všechno může být závislé na dns ... a přesvědčovat telefon že opravdu s tím člověkem na druhém konci chci mluvit, že opravdu jsem si jistý že to není podvodník se ani mě moc chtít nebude ..a to vůbec neuvažuju eventualitu že by mi telefon odmítl spojení celkově.
No nechám se překvapit jak to nakonec bude... Naštěstí mě uklidnila zpráva, že certifikáty ke kořenovým serverům chtějí držet Američani... kolébka spamu a útoků :D Aby nevznikla horká diskuse, opírám se o tyto články:
http://www.usatoday.com/tech/news/computersecurity/infotheft/2007-03-19-attacks-us_N.htm
http://news.cnet.com/U.S.-cooks-up-most-spam/2100-1024_3-5322803.html
Analogie s HTTPS zde proste nefunguje, pokud nesedi podpis, je zaznam odmitnut.Pro uživatele může být užitečná i informace, zda záznam nebyl nalezen nebo zda byl nalezen záznam bez podpisu / se špatným podpisem. A analogie s HTTP vs. HTTPS zde funguje – pořád je důležité vědět, zda záznam byl podepsán nebo nebyl. To, že je v TLD
.cz
možnost podepsat záznamy nijak nezvyšuje mojí důvěru v nepodepsaný záznam example.cz
. Je to stejné, jako kdyby vás prohlížeč nepustil na stránku s neplatným HTTPS certifikátem, ale neměl byste žádnou kontrolu nad tím, zda se připojujete přes HTTP nebo HTTPS.
U DNS nemate moznost nejak klikat a nastavovat vyjimky.Zajímavé, že se všude popisuje, jak si nastavit takovou výjimku pro TLD
.cz
a říci resolveru, že tato doména je podepsaná tím a tím certifikátem, ačkoli kořenová doména podepsaná není. Alespoň tohle je to, co já si pod výjimkou v DNSSEC představuji – řeknu resolveru, ať nehledí nalevo napravo a jako certifikát pro danou doménu bere tenhle certifikát.
Bohuzel, vychazite ze spatneho predpokladu, ze DNS pouzivaji pouze aplikace urcene pro zive uzivatele. Ale jak byste chtel zpracovavat stav, kdy resolver dostane spatne podepsanou odpoved na dotaz, ktery si vyzadal treba automaticky zalohovaci system? Obdobne, co by melo delat MTA? Proste spatne podepsany zaznam se zahazuje, protoze je to pravdepodobne utok.
Vyjimky nejdou ve smyslu weboveho prohlizece a HTTPS protokolu. Neni mozne nastavit, ze A zaznam bad.example.cz mam akceptovat i se spatnym podpisem. A rozhodne to nejde v aplikaci.
Kazdopadne pokud jste s DNSSEC nespokojeny, nic Vam nebrani dat do IETF navrh. Jinak se obavam, ze se nic nestane, protoze lide, kteri DNS provozuji, jsou s tim soucasnym stavem vice ci mene spokojeni.
Bohuzel, vychazite ze spatneho predpokladu, ze DNS pouzivaji pouze aplikace urcene pro zive uzivatele.Nevycházím, já nic takového nepředpokládám.
Ale jak byste chtel zpracovavat stav, kdy resolver dostane spatne podepsanou odpoved na dotaz, ktery si vyzadal treba automaticky zalohovaci system? Obdobne, co by melo delat MTA? Proste spatne podepsany zaznam se zahazuje, protoze je to pravdepodobne utok.Automatický zálohovací systém i MTA by se zachovaly přesně tak, jak by je nakonfiguroval jejich správce. Špatně podepsaný záznam je pravděpodobně útok, ale já tady píšu hlavně o (správně, záměrně) nepodepsaných záznamech. Co uděláte, když vás e-shop přesměruje na platební bránu, bude chtít zadat údaje o platební kartě a vy uvidíte, že jde o protokol HTTP? poklepete si na čelo, a údaje zadávat nebudete, protože víte, že to není bezpečné. Ale nepodepsané DNS odpovědi klidně věřit budete, protože to přece není špatně podepsaný záznam (bavíme se o nepodepsané odpovědi, kdy správce nepoužívá DNSSEC a nepodepsaná odpověď je tedy správně). U protokolu HTTPS je to zrovna zbytečné, protože tam se ověřuje i identita, a DNSSEC je tedy zbytečné. Ale internet není jen web, jsou i jiné protokoly, které mohou zajišťovat ochranu před únosem spojení, ale nemusí zajišťovat ověření identity druhé strany. V takovém případě by byl užitečný mechanizmus ověření identity skrze DNS – jenže k tomu potřebuju umět rozeznat stav, kdy je identita zaručena, od stavu, kdy nevím. DNSSEC bez úprav resolveru ale umí indikovat jenom dva stavy – nevím a nenalezeno/útok. Tedy záruka žádná.
Kazdopadne pokud jste s DNSSEC nespokojeny, nic Vam nebrani dat do IETF navrh.Změna není potřeba na úrovni protokolu DNS, ale na úrovni resolveru. „Stačí“ doplnit funkce
socket()
a bind()
o návratový příznak „DNS odpověď ověřena“. bez toho je DNSSEC vhodné k nasazení na servery, ale vůbec nic nepřináší klientům. Protože pro klienta bez úpravy resolveru nepřináší DNSSEC žádný rozdíl – pořád musí odpovědi DNS považovat za nedůvěryhodné.
> doplnit funkce socket()
a bind()
o návratový příznak
Funkce socket() a bind() s DNS vubec nepracuji. Bezne programy pouzivaji variantu gethostbyname().
Bohuzel uz nemam cas na delsi diskusi, kazdopadne - Zvlastni je, ze to neduveryhodne DNS ted pouzivate a na celo si neklepete. Srovnavat HTTPS a DNSSEC dost dobre nejde. Jedno podepisuje, druhe sifruje.
S modifikaci funkci resolveru Vam preji hodne stesti, kazdopadne to uz neni o DNSSEC.
Zvlastni je, ze to neduveryhodne DNS ted pouzivate a na celo si neklepete.A v tom je právě problém. K čemu je dobré DNSSEC, když pro mne jako pro uživatele budou DNS odpovědi stejně nedůvěryhodné,jako dosud? Jsou s tím jen náklady na zavedení, ale přínos pro klienta žádný.
Srovnavat HTTPS a DNSSEC dost dobre nejde. Jedno podepisuje, druhe sifruje.DNSSEC by mohlo sloužit k ověření identity, HTTPS se dnes používá také zejména k ověření identity.
> K čemu je dobré DNSSEC, když pro mne jako pro uživatele budou DNS odpovědi stejně nedůvěryhodné,jako dosud?
Jako ochranu pred DOS utokem - pokud resolveru prijdou dve odpovedi (falesna a korektni), nema resolver informace k tomu, aby urcil, ktera z nich je ta spravna. A tak musi si jednu vybrat a tu predat dal. Pokud vybere tu spatnou, tak na to sice treba WWW prohlizec pomoci HTTPS prijde, ale uz neni moznost pak ziskat pak tu spravnou. Takze se na cilovou adresu nedostane (a tedy to jde povazovat za DOS utok).
Je pravda, ze u koncoveho resolveru by to slo resit i jednoduseji, ale u rekurzivniho DNS serveru tezko.
Výborný nápad, založte ho do trezoru naspodok aby ho nikto nenašiel.
Ne snad primo pomoci DNSSEC, ale pomoci DNS rozhodne. Podobne to uz funguje u SSH - zaznam SSHFP. Na tomto standardu se uz pracuje a nezustavame jen u webu. Pojednavala o tom jedna z prednasek na IT09.
Predevsim domena Madarska podepsana neni.
Nechapu, jak se pomoci DNSSEC ovlada Internet. DNSSEC v soucasnem modelu delegace domen nejvyssi urovne nic nemeni. O vzniku a zaniku domen proste rozhoduje ICANN ve spolupraci s DoC a technicky pak zonu tvori Verisign. S prichodem DNSSECu se na tomto nic nemeni.
Kde jste cerpal informaci, ze dalsi spravci cekaji na rozsireni NSEC3? Vetsina spravcu ceka na podpis root zony. Mimochodem .GOV a .ORG jsou podepsane pomoci NSEC3.
Proc myslite, ze pri kompromitaci klicu korenove zony by byl DNSSEC na par let u ledu?
Tiskni
Sdílej: