Seznam dělá každé úterý odstávku svého datacentra a simuluje tak správnost jejich HA řešení. Dnes se ovšem něco pokazilo a má kompletní výpadek. Nejdou webové služby, mapy apod. Kdo by rád věděl něco více o tom, na čem Seznam běží, tak nelze nepřipomenout LinuxDays 2023: Podvozek Seznamu - od cloudu až po Datacentrum (Michal Toužín, Miroslav Bezdička).
Na stránkách konference Den IPv6 2024, jež proběhla 6. června v Praze, byly zveřejněny prezentace a videozáznamy.
Kyberkriminální skupina LockBit se prý nabourala do Federálního rezervního systému (FED) [Security Affairs].
Zakladatel WikiLeaks Julian Assange je na svobodě (𝕏, 𝕏).
V neděli 30. června skončí (EOL) podpora CentOS Linux 7.
David Tschumperlé a Garry Osgood v obšírném článku se spoustou náhledů shrnují vývoj multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie) za poslední rok.
Andrew S. Tanenbaum byl oceněn 2023 ACM Software System Award (Wikipedie) za operační systém MINIX.
Celkový počet stažení aplikací z Flathubu překročil 2 miliardy. Aktuální Statistiky Flathubu: Celkový počet stažení 2 002 793 783. Celkem desktopových aplikací 2 636.
Byla vydána nová verze 4.8.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 142 (pdf) a HackSpace 79 (pdf).
John Gilmore analyzoval a zveřejnil situace, kdy lidé z NSA přímo sabotovali bezpečnost navrhovaných protokolů nebo standardů. Ve své zprávě se zaměřil obzvláště na IPSEC, které je vinou NSA příliš složité, potenciálně náchylné k útokům a chybí v něm drobnosti zlepšující bezpečnost kvůli návrhům na "zjednodušení", které přišly od NSA. Dále pak poukazuje na lhaní lidí z NSA, pomocí kterého sabotovali vznik účinného standardu pro end-to-end šifrované hovory v mobilní síti.
Tiskni Sdílej:
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á.