Byly publikovány informace o 4 kritických bezpečnostních chybách v CUPS (Common UNIX Printing System): CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 a CVE-2024-47177. Vzdálený neověřený útočník může tiše nahradit adresy IPP stávajících tiskáren (nebo nainstalovat nové) za zlovolné, což může mít za následek spuštění libovolného příkazu (RCE) při spuštění tiskové úlohy.
Tcl/Tk, tj. programovací jazyk Tcl (Tool Command Language) a související GUI toolkit Tk, bylo vydáno v nové major verzi 9.0.0. Po 27 letech od vydání 8.0.0.
Mastodon CZ Sraz 2024, tj. druhý ročník srazu uživatelů Mastodonu a Fediverse proběhne 11. října 2024 v Praze.
Projekty Tor a Tails se spojují. Tails bude začleněn do struktury projektu Tor pro snazší spolupráci, lepší udržitelnost, snížení režie, rozšiřování povědomí o větším počtu digitálních hrozeb a lepší ochranu před sledováním a cenzurováním.
Společnost System76 vydala druhou alfa verzi desktopového prostředí COSMIC Epoch 1 společně s alfa verzí Pop!_OS 24.04 LTS.
Byl vydán PostgreSQL 17. Přehled novinek v poznámkách k vydání.
Společnost Meta Platforms na své dvoudenní konferenci Meta Connect 2024 představuje novinky: brýle Orion (původně Project Nazare) pro rozšířenou realitu (AR, Augmented Reality), nový VR headset Meta Quest 3S, vylepšené chytré brýle Ray-Ban Meta nebo Llama 3.2, tj. nejnovější verzi svého velkého jazykového modelu.
Počítačová hra XBill (Wikipedie) oslavila v létě 30 let. V devadesátkách Linuxáci poctivě bránili Billovi v instalaci Windows. Bohužel hry XSteve a XSatya nevznikly. A nemáme ani hru XTim. Proto není Linux na desktopu tak rozšířený ☺. Mimochodem, po 25 letech byl aktualizován XBill pro PalmOS.
Počítačová hra Elite (Wikipedie), 3D vesmírní simulátor, byla vydána před 40 lety, 20. září 1984. Při té příležitosti byly zveřejněny další zdrojové kódy Elite pro platformy Apple, Atari, C64, NES a SNES a nedokončené Elite II pro BBC Micro.
V květnu bylo oznámeno, že dnes budou zveřejněny zdrojové kódy přehrávače Winamp. Stalo se tak (𝕏). Zdrojové kódy jsou k dispozici na GitHubu. Nejedná se ale o svobodný a otevřený software (licence).
Aneb typek co se snazi prizivit na aktualni situaci. Podle me je to zm*d, protoze to mel zverejnit uz davno.
Firewall to považuje za HTTPS, takže pokud to chce pustit ven, musí to pustit rovnou, protože nemůže do SSL zasahovat (transparent proxy/cache/filter). Takže je úplně jedno, že uvnitř toho SSL žádné HTTP neběžíV naprosté většině případů tomu tak skutečně je.
Firewall to považuje za HTTPS, takže pokud to chce pustit ven, musí to pustit rovnou, protože nemůže do SSL zasahovat (transparent proxy/cache/filter). Takže je úplně jedno, že uvnitř toho SSL žádné HTTP neběží
Tím už si dnes bohužel nikdo nemůže být jist, protože se rozšiřují krabičky, které umějí udělat MITM na https. Někde už berou jako standard mít na všechno aplikační proxy (už jsem viděl i na ssh, zasahovala do možností autentizace).
Používají certifikáty, které jsou podepsané od nějaké certifikační autority, běžně přítomné v prohlížeči?
Ano.
Pokud ano, tak je to další důvod proč u HTTPS kotrolovat certifikát i pokud prohlížeč nic nehlásí.
Tak to by měl být u SSL základ, ovšem jsou servery, které se tomu důkladně brání. Doporučuji nainstalovat rozšíření Certificate Patrol a potom jít třeba na Google. Co server, to jiný certifikát. V takovém prostředí se toho moc ověřit nedá.
Ale u OpenVPN by takový MITM téměř určitě nefungoval, vhledem k mechanismu handshake, který je velmi odlišný od HTTP.Vzhledem k mechanismu handshake? To bych si nechal vysvětlit :).
P_DATA
) i binární řídící sekvence trochu podobné těm u TCP protokolu (typy P_CONTROL*
a P_ACK
). Jenže aby mohl hadshake proběhout, musí "MITM krabička" na jednom konci (směrem ks serveru) hrát OpenVPN klienta a na druhém (směrem ke klientovi) zas OpenVPN server, což naprosto jiná úloha než transparentní HTTP proxy. Pokud by ona krabička neuměla OpenVPN protokol a neměla příslušné klíče, bude jí pozměněná komunikace hned ze začátku ukončena jako chybná a zahozena.
Linuxový IPsec a vlastní policy table bez virtuálních rozhraní je rovněž docela hezký nápad, ale musí se s tím člověk chvilku smiřovat :).Na druhou stranu není problém si v případě potřeby virtuální rozhraní nad tím IPSecem udělat (ipip, sit, gre...) a tlačit provoz přes něj. Mimochodem, pokud se nepletu, virtuální rozhraní není nutně potřeba ani ve Windows, ne, tam se také nechají nastavovat politiky samostatně...
Ale jo, o tom žádná... spíš mi vadí, že tam je pořád v principu nějaký prasohack, který nějakým způsobem obchází standardní IP routing stack (viz KPTD)Rád bych tě upozornil, že slovo prasohack může být jen vyjádřením toho, že něčemu nerozumíš nebo že se ti to z nějakého důvodu nelíbí, a tudíž nemá žádný technický význam a neříká nic o vhodnosti či nevhodnosti daného architekturního rozhodnutí.
Když si vezmete KPTD (což údajně ještě není kompletní obrázek), odkud se přesně ty pakety mají "správně" ztrácet resp. kde se mají objevovat?Dobrá poznámka. Zdá se, že KPTD něco chybí :).
Správně podle mého tam taková věc nepatří.Musím říct, že tvůj názor naprosto chápu a že můj první dojem byl stejný. Nicméně při bližším zkoumání architektury IPsec jsem ho docela rád pozměnil.
Pokud ji tam někdo dodělá, musí to kamsi nějakým nestandardním způsobem naprasit.Toto už bych si dovolil označit za mlácení prázdné slámy, protože takový výrok můžu říct očemkoli, co se kdy v kernelu přidá. Navíc si člověk sejme ideologickou čapku a podívá se na síťování v kernelu, tak si musí nutně uvědomit, že většina věcí je v síťovém stacku nějakým způsobem doprasená a velká část z nich ještě špatně. A právě kvůli zmíněné stabilitě chování (API/ABI jsou v tomhle případě zbytečně detailní pojmy) ty věci často špatně musejí i zůstat.
ten paket nemůže mít žádnou košer interní historii v rámci kernelu... a dost, už vařím z vody.Přitom zde není z vody vařit potřeba. Stačí se podívat třeba na iptables a na to jaké atributy paketů iptables nabízejí ke kontrole či úpravě a můžeš identifikovat, které z nich ti připadají z hlediska IPsec podezřelé a od nich se dá to vyjasňování začít. Další možnost je provnat celou situaci s userspace VPN pomocí tun/tap rozhraní, kde se pakety podobným způsobem z pohledu kernelu „ztrácejí“ a „objevují“ (konec konců podobně funguje i reálný síťový hardware). Nakonec ti z toho vypadne úplně jiná otázka a to, kdy se paket objevuje zapouzdřený a kdy nezapouzdřený (popřípadě kdy se ti objeví obě verze paketů, což umí krásně prozradit tcpdump). Pak má smysl hodnotit sprasenost konkrétní implementace a stejně tak i samotná možnost rozumné implementace tohoto modelu. A je dobré nezapomínat na IPsec transport mode.
Navíc si člověk sejme ideologickou čapku a podívá se na síťování v kernelu, tak si musí nutně uvědomit, že většina věcí je v síťovém stacku nějakým způsobem doprasená a velká část z nich ještě špatně.To jste mi potvrdil jeden můj dost častý dojem Když se občas do zdrojáků kernelu ze studijních důvodů ponořím, nalézám věci v tomto duchu. Ale zatím jsem se díval jenom na pár velice úzkých a okrajových oblastí.
Další možnost je provnat celou situaci s userspace VPN pomocí tun/tap rozhraní, kde se pakety podobným způsobem z pohledu kernelu „ztrácejí“ a „objevují“ (konec konců podobně funguje i reálný síťový hardware).Tohle jsem asi nepochopil. Tady mi to právě přijde, že tun/tap je dobře definovaný a stabilní způsob, jak si vytvořit síťové rozhraní. Virtuální, ale jinak po všech stránkách košer. Transport mezi tímto rozhraním a "protějším koncem" na jiném stroji je implementovaný nějakým automagickým démonem v user space, který mne z hlediska čistoty a elegance KPTD (já vím, "ehm ehm") nijak neuráží. V user space ať si páchá kdo chce co chce. Navíc se OpenVPN v tomto případě vůči kernelu tváří jako vcelku konzervativní subnet resp. L2 médium (konfigurovatelně point to point nebo multi-exit).
A je dobré nezapomínat na IPsec transport mode.Ano, to je taky dobrý parazit. Tady uhnu od tématu: je to jedna z věcí, proč mám instinktivně smíšené pocity z příchodu IPv6 (jakožto správný IPv4 zpátečník). Ale pokud se v rámci IPv6 povede zařídit bezvadnou interoperabilitu IPSecu mezi implementacemi, tak proč ne... vlatně o tu mi jde především. Opravdu už mluvím dost z cesty, vynáším subjektivní soudy a nemám to podložené studiem zdrojáků. Děkuju za zajímavou debatu
Tohle jsem asi nepochopil. Tady mi to právě přijde, že tun/tap je dobře definovaný a stabilní způsob, jak si vytvořit síťové rozhraní.Kernelový kód až tak nutně tun/tap nepotřebuje, ty existují především kvůli zpřístupnění userspace implementací.
V user space ať si páchá kdo chce co chce.To, že IPsec je dobře implementovatelný v kernelu bych viděl rovněž jako výhodu. Z userspace se to celé nakonfiguruje a udržuje, o balení a šifrování se postará kernel. Podobný model se aplikuje na mnohé další věci.
Ano, to je taky dobrý parazit.Transport mode mi přijde na celém IPsec nejgeniálnější část. Tunelový mód, to je prostě další implementace šifrovaného propojení sítí (VPN), ale transport mode je skutečným krokem kupředu, byť zatím nedoceněným, protože umožňuje řešit zabezpečení na optimální úrovni, tedy v rámci operačního systému a pod transportními protokoly.
Ale pokud se v rámci IPv6 povede zařídit bezvadnou interoperabilitu IPSecu mezi implementacemi, tak proč ne... vlatně o tu mi jde především.Jenže interoperabilita vyžaduje mnohem víc snahy a přemýšlení než splácat jen tak nějakou implementaci ;). V praxi je IPsec v tomto ohledu značně nedospělý. Na druhou stranu OpenVPN není směrem ven interoperabilní prakticky vůbec.
Protože je to projekt oddělený od kernelu (běží v user space), běží tatáž verze napříč platformami.Nekernelová implementace má své nesporné výhody (a stejnětak i nevýhody, stačí si uvědomit, že TCP/IP by mohlo být rovněž implementováno v userspace).
Popravdě se taky opatrně těším na utopickou ideální budoucnost na podvozku IPv6, kde nebude NAT, a půjde telefonovat "každý s každým" bez potřeby supernodů apod.Ono je lepší si mimo laboratoř nestavět utopické scénáře, pokud se chceš internetem nějak vážně zabývat.
Na jedné straně šifrování v transportním režimu sice skryje o čem se dva spolu baví, ale neskryje samotný fakt, že dvě konkrétní koncové stanice se spolu baví (neexistují privátní adresy). Jasně, security by obscurity...Interpretovat tuto vlastnost (na které mimochodem přepnutí na tunelový režim nic nemění) jako security by obscurity, to zavání, že se diskuze začíná zvrhávat ve snůšku nepromyšlených a nepodložených keců a to bych nerad.
Na druhé straně jste mi tu právě vysvětlili, že opravdu pedantský proxy firewall se neštítí provádět MITM na SSL relacích. Čili zabezpečené firemní LANky nám tu komunistickou utopii stejně trpět nebudou.Zde už se to skutečně zvrhává ve žvásty™.
Pokud clovek chce skutecny tunel, tak je GRE ci IPIP chraneny IPSec transport modem asi optimalni volba.+1 A při dekompozici nakonec dojde k tomu, že ten paket i vypadá tak, jak vypadat má.
Tiskni Sdílej: