Byla vydána nová verze 0.4.15 (𝕏) svobodného operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows. Přehled novinek i s náhledy v oznámení o vydání.
Byl představen rpi-image-gen, tj. oficiální nástroj pro vytváření vlastních softwarových obrazů pro zařízení Raspberry Pi.
Byla vydána nová major verze 8.0, aktuálně 8.0.1, softwaru pro správu elektronických knih Calibre (Wikipedie). Přehled novinek v poznámkách k vydání. Vypíchnuta je lepší podpora Kobo KEPUB formátu nebo integrovaný lokálně běžící engine Piper pro převod textu na řeč používaný pro čtení nahlas (již od verze 7.18).
Společnost OpenAI rozšířila své API o nové audio modely. Nový model pro převod textu na řeč (text-to-speech model) lze bez přihlašování vyzkoušet na stránce OpenAI.fm.
Příspěvek Bezpečnost paměti pro webové fonty na blogu Chrome pro vývojáře rozebírá, proč se pro zpracování webových fontů v Chrome místo FreeType nově používá v Rustu napsaná Skrifa z Fontations.
V pátek 21. a v sobotu 22. března proběhnou Arduino Days 2025, tj. každoroční „narozeninová oslava“ platformy Arduino. Na programu je řada zajímavých přednášek. Sledovat je bude možné na YouTube. Zúčastnit se lze i lokálních akcí. V sobotu v Praze na Matfyzu.
Komunitná konferencia Bratislava OpenCamp, ktorá sa uskutoční už o tri týždne 5. 4. 2025 na FIIT STU pozná svoj program – návštevníkom ponúkne 3 paralelné behy prednášok a workshopov na rôzne témy týkajúce sa otvoreného softvéru či otvorených technológií.
Časopis MagPi od nakladatelství Raspberry Pi se s číslem 151 přejmenoval na Raspberry Pi Official Magazine. I pod novým názvem zůstává nadále ve formátu pdf zdarma ke čtení.
Japonská SoftBank Group kupuje firmu Ampere Computing za 6,5 miliardy dolarů. Ampere Computing vyrábí 32-128jádrové procesory Ampere Altra a 192jádrové procesory AmpereOne.
Byla vydána (𝕏) nová verze 2025.1a linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek v oficiálním oznámení na blogu.
Hlavně nesmíte pustit útočníka ke kabelu, ve kterém tečou rámce z dotčené VLAN. Pamatujte, že VLAN je jenom o označkování ethernetových rámců, nic se nikde nešifruje.
A vzhledem k tomu, že uhlídat víc jak metr drátu je nemožné, silně doporučuji zavést šifrování.
O SHA-1 se říká, že „brzy“ bude „prolomen“. Nicméně v případě IPsecu se dočasné klíče mění celkem rychle (záleží jakou máte nastavenou periodu, ale rozhodně to nejsou měsíce nebo roky, které budou pro SHA-1 nebezpečné).
O blowfish moc nevím. Snad jen že jeho následník twofish má v Linuxu implementaci přímo v assembleru, takže by mohl být rychlejší při stejném stupni zabezpečení.
Nastudujte si, jak IPsec funguje, mnoho problémů se vám vyjasní.
IPsec sám o sobě používá neměnné klíče a oba konce musí mít stejnou konfiguraci (výběr kryptografických algoritmů). Protože to je nebezpečné a obtížné, používá se na dohodnutí parametrů a periodickou výměnu šifrovacích klíčů IKE protokol a odpovídající user space démon (UDP port 500). V Linuxu a BSD to bývá démon Racoon.
Racoon podle security policies dohodne s druhou stranou vyhovujcí algoritmy, pomocí klíčů/certifikátů ze své konfigurace (nikoliv setkey.conf) se vzájemně oba konce autentizují a dohodnou dočasné šifrovací klíče a do jádra zavedou security association (transportní adresy, IPsec režim, AH nebo ESP, dočasné šifrovací klíče), které pak jádro použije pro vytvoření IPsec hlaviček a zašifrování dat.
V setkey.conf pak jsou uvedeny jen politiky definující, jaký provoz se může/musí autentizovat nebo šifrovat a jestli má jít přímo nebo přes tunel.
Funguje to tak, že jádro když jádro má odeslat packet, tak když packet vyhovuje politice, zkusí najít asociaci. Když neexistuje, tak jádro zavolá IKE démona, ať se urychleně dohodne s druhou stranou, démon to udělá, jádru vrátí asociaci a jádro ji použije pro zašifrování packetu, který následně odešle.
Takže to není míň nebezpečný, jen pracnější?
PSK je samozřejmě méně bezpečný než použití asymetrické kryptografie, hlavní důvody jsem se pokoušel naznačit.
klíč nikdy nevyprší narozdíl od certifikátů
Pokud si generujete své vlastní certifikáty, je čistě na vás, jakou jim nastavíte platnost. Ale na vašem místě bych se zamyslel nad tím, jestli časově omezená platnost certifikátů nemá svůj důvod.
Takže jen PSK se použije jen jednou při autentizaci protistran a pak už to běží jen po dohodnutých dynamických klíčích?
Ne jen jednou, používá se při výměně klíčů. Ale pořád je to automatický režim, takže se PSK nepoužívá pro šifrování vlastní komunikace, to je rozdíl oproti manuálnímu režimu, kdy definujete přímo SA.
Takže z toho vyplývá, že pokud bezpečně nastavím PSK na obou stranách(+ nastavím na soubor chmod 400), je to vy výsledku stejně bezpečné jako certifikáty?
Už jsem vám napsal že ne a napsal jsem i proč ne.
A když se PSK používá při výměně klíčů, tak se posílá přes síť přímo získaný hash nebo je to v rámci už vytvořené šifrované komunikace? Protože pokud ne tak to může přeci leckdo odposlouchat.
Používá se Diffie-Hellmanův algoritmus výměny klíčů. Pre-shared key slouží k tomu, abyste měl jistotu, že si klíč vyměňujeteo opravdu s tím, s kým si myslíte. Což lze ale snáze - a bezpečněji - zajistit pomocí asymetrické kryptografie.
Můj názor je, že jediná situace, kdy má smysl použít PSK, je ta, když je na jedné straně zařízení, které jinou metodu autentizace neumí (což je případ některých embedded implementací).
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ping -c 1' do startovacího skriptu racoon.
Packet pozdržený v jádře kvůli čekání na asociaci, blokuje volání jádra, takže pokud aplikace používá blokující operace, tak se prostě uspí. (Samozřejmě je tam časový limit na získání asociace, když IKE nefunguje, tak po nějaké době vrátí systém chybu (s docela podivným názvem, na který si teď nevzpomenu)).
Pokud aplikace používá neblokující operace, tak záleží, jak má nastavené časové limity. Obecně si ale myslím, že několik sekund, kolik trvá zavedení asociace i na poměrně starých strojích, by měly aplikace pojmout. Pokud tomu tak není, pak stojí za otázku, zda jsou vaše aplikace vhodně nastavené.
Pokud vám aplikace vůbec nenaběhnou, protože jsou špatně napsané a nesnesou větší zpoždění, tak si je opravte nebo zasáhněte do startovacích závislostí startovacích skriptů. (Stejný problém se stejně musí řešit při čekání na potvrzení použitelnosti IPv6 adresy rozhraní nebo náběh linkové vrstvy rádiových rozhraní. Takže blbě napsaná aplikace se projeví i tak.)
Žádný udržovací ping není třeba, neboť asociace se drží v jádře velmi dlouho a ustanovení nových klíčů probíhá asynchronně (racoon si to hlídá a vymění je dříve, než starým vyprší platnost). Samozřejmě pokud byste měl stroj s tisíci asociacemi, pak by asi začaly vypadávat z paměti, ale u pár záznamů se nic takového neděje.
Prakticky vzato po prvním pokusu o spojení, které trvá déle, vše pak funguje hladce. Aspoň to jsou moje zkušenosti. Vyzkoušejte poslední verzi racoonu a nastavte si rozumnou životnost dočasných šifrovacích klíčů v racoonu. (Já mám ipsec-tools-0.7.3 a lifetime time 1 hour.)
U SHA-1 se očekává nanejvýš nalezení kolizí. Že by ji někdo byl schopen v dohledné době prolomit v tom smyslu, že by bylo nebezpečné ji použít pro zabezpečení komunikace, je krajně nepravděpodobné, to zatím nikdo neumí ani pro MD5, pro kterou už je dnes hledání kolizí rychlou a nenáročnou záležitostí.
Nechci samozřejmě bagatelizovat otázku důvěryhodnosti MD5 a SHA-1, ale na druhou stranu není důvod k panice a představám, že jak použijete MD5, okamžitě se vám tam někdo nabourá.
Tiskni
Sdílej:
