Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Nelíbí se mi poskytovat gigantům typu google, facebook či twitter ještě další informace a proto jsem hledal něco decentralizovanějšího.OpenID jde používat tak decentralizovaně, jak si sám zvolíš. Tím nechci říct, že by na kryptografické autentizaci pomocí (třeba) GnuPG bylo něco špatného, právě naopak! Ale dokud nebude použití kryptografických klíčů pro uživatele běžnější než autentizace bez ní, tak je zde velký prostor pro obojí. Ale radši se nejdřív podívej, jak pozvolná je adopce tak jednoduché technologie jako OpenID, než začneš doufat v rozšíření čehokoli složitějšího.
Jak to potom tedy vysvětlíme nějakému nezkušenému uživateli?S bicem v ruce.
trusted ca v klasické PKI půzobí plošněViz RFC 2459 z roku 1999 a Name Constraints:
The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path shall be located. Restrictions may apply to the subject distinguished name or subject alternative names.Je zajímavé, kolik věcí už bylo vynalezeno a stačí je pouze začít používat
CA v DNSSEC mají vymezené pole působnostiCož na druhé straně ale také znamená, že jsou monopolními CA pro danou doménu (neříkám, že je to vyloženě špatně – ono to spíš jinak nejde). Tím nechci říct, že je používání DNSSEC špatné, naopak – když se někam připojuji (a je jedno, jestli je to HTTPS, SSH nebo cokoli jiného) a najdu tam samopodepsaný certifkát, jehož otisk se nachází i v DNSSEC TXT záznamech, tak je to důvěryhodnější, než samopodepsaný/nepodepsaný certifikát bez ověření otisku přes DNSSEC. Ale beru to jako takovou pomůcku, která lehce zvýší bezpečnost, něco jako druhý zámek na dveřích vedle toho hlavního…
To není chyba PKI, ale chyba lidí, kteří důvěřují nedůvěryhodným certifikačním autoritám. A nakonec se na ty CA můžeš vykašlat a používat tu technologii (HTTPS + klientské certifikáty) stejným stylem, jako se používají SSH klíče.Pokud to budu používat stylem, jak se používají SSH klíče, tak z PKI nepoužívám zhola nic. Sice občas lidi předstírají, že self-signed certifikát je něco více než jen veřejný klíč, ale za to já nemůžu.
Ty CA je potřeba brát jako něco, co ti může ulehčit a zpříjemnit práci (případně snížit bezpečnost za určitých okolností – ale za jiných zase zvýšit*), ale co nemusíš nutně používat.Já PKI beru jako něco, co můžu a nemusím používat, tedy do jisté míry.
Tzn. není to o volbě technologie (SSL vs. GPG vs. SSH), ale spíš o způsobu, jakým ji používáš.Já o voze a ty o koze.
Ale prd. GPG (original) nemel system duvery...Dál nemusím číst, protože zřejmě každý píšeme o něčem jiném.
A prihlasovani certifikatem v prohlizeci i serveru (alespon apachi) uz existuje.To už pokud vím docela dlouho :).
Ano i ne. Premyslis o PGP/GPG jako o mechanizmu autentizace pro Weby.Ale prd. GPG (original) nemel system duvery...Dál nemusím číst, protože zřejmě každý píšeme o něčem jiném.
gpgAuth is an authentication mechanism which uses Public/Private (cryptographic) keys (such as GnuPG, PGP) to authenticate users to a web-page or service.Pricemz potrebujes implementaci v php a djangu, nejaky navody pro Chrome. Pritom GPG/PGP je pouze jako SW (nevidel jsem dosud zadny HW token, mozna taky existuje), ale pritom PKI je o hodne vic rozsirene a podporovane. Takze proc hledat reseni pro GPG, kdyz uz existuje pro PKI? Pricemz certifikat x509 muzes pouzivat uplne stejne jako GPG a mas k tomu navic moznost pouzit nejake verejne CA, cili duverovat certifikatum podepsanym jednim subjektem. Takze do ankety bych doplnil - "Podle me to sanci nema, pokud nekdo nezainvestuje do vyvoje podpory v klientech, serverech, HW tokenech a do reklamy, protoze to vsechno uz PKI ma a funguje to a pouziva se to".
jak si vygenerovat PKI klíč a jak ho narvat do firefoxu? resp.: to narvání do firefoxu vím jak se dělá. Horší je to s generováním klíčůV HTML formuláři může být značka keygen a prohlížeč při odeslání vygeneruje soukromý klíč (ten si uloží) a veřejný pošle na server společně se zbytkem formuláře. Jednodušší už to snad být nemůže.
Pritom GPG/PGP je pouze jako SW (nevidel jsem dosud zadny HW token, mozna taky existuje)Samozřejmě, že existuje – např. OpenPGP card.
ale pritom PKI je o hodne vic rozsirene a podporovane.Souhlas (alespoň pokud se bavíme o webu/https).
Takze proc hledat reseni pro GPG, kdyz uz existuje pro PKI?Snad jen proto, že v GPG můžeš mít svůj klíč podepsaný několika různými subjekty, zatímco u x509 máš vždy jen jednu CA. Jenže k čemu je na webu to dobré? Smysl to má snad leda při ověřování identity serverů (např. si stanovím pravidlo, že když danému klíči serveru věří tři moji důvěryhodní známí, budu mu věřit taky – tzn. věřit, že ten klíč patří k dané doméně), jenže tenhle blog je o ověřování klientů – a tady nic takového potřeba není – stačí mi jednoduše při registraci uživatele spárovat jeho veřejný klíč s jeho účtem, což můžu klidně dělat v x509 (viz #12) a není potřeba kvůli tomu zavádět novou technologii.
SSL_CLIENT_CERT (to platí pro Apache, jinde to bude podobné) a podle toho identifikuješ uživatele (při registraci nebude zadávat jméno a heslo, ale svůj certifikát resp. veřejný klíč).
Support for authentication using both X.509 and OpenPGP certificates.
Takový drobný problém je, že zřejmě neexistuje HTTP server, který by používal GnuTLS.Apache:
a2enmod gnutls
což jsem jednu dobu i používal, akorát ne s PGP – ale mělo by ho to umět:
Support for RFC 5081bis OpenPGP certificate authentication.Horší mi to přijde spíš na straně klientů, www prohlížečů.
* GPG nema(?) HW tokeny (resp. asi by se dal HW token donutit, aby sifroval i pro GPG, ale do tohohle nevidim tak presne)
Má. Referenční implementaci prodává firma, za kterou stojí pan Koch. Existují i konkurenční výrobci. Ono v podstatě jde jen o označení typu souboru v šifrovacím zařízením. Zařízení s otevřenými ovladači obvykle PGP klíče podporují.
* GPG nema(?) komercni/"komercni" duveryhodne objekty, jejich klice/certifikaty by byly distribuovany v klientech/serverech
Protože to je vlastnost. Ostatně i PKI má s tímto problém. Alespoň tady v Česku. Naproti tomu PGP má něco, co PKI nemá – klíčové servery. To je ta věc, proč nemusíte tahat celou databázi do vašeho počítače jako s PKI a čekat, až jeho výrobce vám dodá novou verzi. Popravdě řečeno vrcholová úroveň kvalifikovaných autorit v EU je také jenom seznam bez nějaké relace důvěry.
Tiskni
Sdílej: