Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
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:
