Evropská komise obvinila provozovatele čínské platformy TikTok z porušování pravidel EU kvůli netransparentnosti v reklamě. Komise, která v EU plní i funkci antimonopolního úřadu, to dnes uvedla v tiskové zprávě. TikTok, který patří čínské firmě ByteDance, se může k předběžnému nálezu vyjádřit. Pokud ale podezření komise nevyvrátí, hrozí mu pokuta až do šesti procent z ročního globálního obratu.
Sovereign Tech Agency (Wikipedie), tj. agentura zabezpečující financování svobodného a otevřeného softwaru německou vládou, podpoří GFortran částkou 360 000 eur.
Microsoft hodlá zrušit zhruba tři procenta pracovních míst. Microsoft na konci loňského června zaměstnával kolem 228.000 lidí. Tři procenta z tohoto počtu představují téměř 7000 pracovních míst.
V říjnu loňského roku provedl Úřad pro ochranu hospodářské soutěže (ÚOHS) místní šetření u společnosti Seznam.cz. Krajský soud v Brně tento týden konstatoval, že toto šetření bylo nezákonné.
Branch Privilege Injection (CVE-2024-45332, Paper) je nejnovější bezpečnostní problém procesorů Intel. Intel jej řeší ve včerejším opravném vydání 20250512 mikrokódů pro své procesory. Neprivilegovaný uživatel si například může přečíst /etc/shadow (YouTube).
Dle plánu byl vývoj Firefoxu přesunut z Mercurialu na Git. Oficiální repozitář se zdrojovými kódy je na GitHubu.
V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Na konferenci BlackHat, která tento týden proběhla v USA, bylo odhaleno více informací ohledně útoku na DNS, se kterým první přišel Dan Kaminsky. Nezáplatované servery jsou vážně ohroženy a ani ty záplatované nejsou stoprocentně bezpečné. V současné době je jediným řešením, které chrání před útoky typu otrávení vyrovnávací paměti DNS, DNSSEC. Pokud jste to ještě neudělali, tak rychle instalujte aktualizace DNS serveru. Více informací naleznete na firemním blogu CZ.NICu: DNS útok podle Kaminského.
Tiskni
Sdílej:
Kdybyste jsi zprávu prošel pořádně, tak byste věděl na co je naráženo. Třeba na to, že DJBDNS má/mělo jiné chyby.To snad nikdo nepopira, ostatne chyby jsou v kazdem slozitejsim programu. Ale je zajimave to zminovat zrovna v souvislosti s chybou, proti ktere bylo
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
djbdns imunni vyrazne vice, nez ostatni programy. To, ze po aplikaci patchu se ostatni programy dostaly na stejnou uroven, jako ma djbdns od zacatku, bych nevidel jako duvod, proc prehodnocovat volbu djbdns.
djbdns jsem pochopil -- proste jenom nemate rad DJB. Zatimco DJB udelal neco proti tomuto typu utoku hned pri psani djbdns, autori treba bindu se tim zacali zabyvat teprve ted. To je prece jasny duvod, proc si zvolit bind...
Nevim, z ceho usuzujete, ze djbdns nebude upraveno v pripade, ze se najde nejaky lepsi zpusob, jak se tomuto typu utoku branit. Jestli z toho, ze ted vsichni vydavaji velke patche, a djbdns ne (protoze tu nejhorsi diru, kterou ty patche lepi, ma zalepenou odjakziva), pak pouzivate nejakou zvlastni logiku.
Mimochodem, co vadi ISP na nahodnem portu odchozich odpovedi?
Nevim, z ceho usuzujete, ze djbdns nebude upraveno v pripade, ze se najde nejaky lepsi zpusob, jak se tomuto typu utoku branit.Protoze nepamatuju, ze by DJB pripustil, ze nekdy udelal chybu. Maximalne vysledek prohlasi za "nelze dosahnout v realnem svete". Neverim, ze po letech hrabne do DJBDNS. A tak to zase, tak jako v jinych pripadech, budou resit patche treti strany... Co vadi ISP? No, srovnejte si jeden konkretni port a 63k portu a co to vse prinasi do infrastruktury a monitoringu. Nemluve o tom, ze jak Kaminsky zminuje, nemalo z nich ma "derandomizacni" NAT pred temi DNS servery.
Co vadi ISP? No, srovnejte si jeden konkretni port a 63k portu a co to vse prinasi do infrastruktury a monitoringu. Nemluve o tom, ze jak Kaminsky zminuje, nemalo z nich ma "derandomizacni" NAT pred temi DNS servery.Mohl bych poprosit o vysvetleni, jak nejake sluzbe vadi, ze se ji klienti dotazuji s ruznymi zdrojovymi porty? Velky DNS server neprovozuji a rad bych si rozsiril obzory.
Nejde o to, ze se nejake sluzbe nelibi, ze se ji klienti dotazuji s ruznymi zdrojovymi porty. Jde o to, ze DNSka od ISPcek ted uzivaji pro komunikaci ruzne zdrojove porty.
Tak si predstavte, ze dosud jste filtroval trafik i podle zdrojoveho UDP portu. Ted se muzete jit s tim klouzat. To se mnohym nelibi.
Za druhe, z pohledu implementace - je radove implementacne a vykonnove snazsi monitorovat aktivitu na 1 portu vs. 63k portu. V pripade Bindu se prvotni implementace rozhodne nepovedla, nasledne vylepseni je o kus lepsi a snad to, co je ted v beta verzi, bude rozumne dobre.
Nemluve o tom, ze proste generovani dalsich nahodnych cisel stoji nejaky vypocetni cas. Coz nektere DNS servery na nekterych platformach dokazou prenest do specializovaneho HW, ale malokdo tohle uziva a v tomto pripade by to bylo prilis drahe.
Takže bych problém nastavení firewallu viděl spíše jako teoretický problém, a využití nenáhodnosti portu při nastavení firewallu bylo podle mne pouze okrajovou nevýznamnou záležitostí.Verte nebo ne, prislusna ISP, ktera se timto problemem zabyvala, nepatri mezi okrajova ISP
Tech DNS serveru, ktere maji potencial prekrocit stin DJBDNS je dnes nekolik.To je dobre. A ktere to jsou? A jenom maji potencial, nebo je realne, ze v historicky kratke dobe ten stin oparvdu prekroci?
Protoze nepamatuju, ze by DJB pripustil, ze nekdy udelal chybu. Maximalne vysledek prohlasi za "nelze dosahnout v realnem svete". Neverim, ze po letech hrabne do DJBDNS. A tak to zase, tak jako v jinych pripadech, budou resit patche treti strany...Rekl bych, ze minimalne cislo verze
1.05 svedci o tom, ze nejake chyby priznal. No a ze neverite, ze by po letech hrabnul do djbdns - verit tomu nemusite. Ovsem stale se bavime o tom, jak to mozna bude v budoucnosti -- ja zatim nevidim zadnz duvod, pro od djbdns prechazet nekam jinam. Az bude nejaky DNS server, ktery budu povazovat za lepsi, nez djbdns, nedela mi problem prejit.
Co vadi ISP? No, srovnejte si jeden konkretni port a 63k portu a co to vse prinasi do infrastruktury a monitoringu.Treba takova TCP/IP spojeni, kterzch je urcite vic, nes DNS odpovedi, maji take nahodne zdrojove porty. Nevypada to, ze by se z toho ISP hroutili...
Ktere to jsou? Zkuste se podivat po sveteTech DNS serveru, ktere maji potencial prekrocit stin DJBDNS je dnes nekolik.To je dobre. A ktere to jsou? A jenom maji potencial, nebo je realne, ze v historicky kratke dobe ten stin oparvdu prekroci?
Prekroci? Tezko rici, vetsinou jsou mezi nami prilis kratce, ale minimalne 2 se zdaji byt potencialne dobre. A aspon jeden ma sanci casem dotahnout se i trosku k Bindu.
Nepsal jsem na zacatku " Jen doufam, ze si Kaminskyho prezentaci projdou vasnivi obdivovatele DJB a zamysli se nad uzivanim DJBDNS..." ? A mi nezbyva doufat, ze o problemech DJBDNS jeho uzivatele vedi.Protoze nepamatuju, ze by DJB pripustil, ze nekdy udelal chybu. Maximalne vysledek prohlasi za "nelze dosahnout v realnem svete". Neverim, ze po letech hrabne do DJBDNS. A tak to zase, tak jako v jinych pripadech, budou resit patche treti strany...Rekl bych, ze minimalne cislo verze1.05svedci o tom, ze nejake chyby priznal. No a ze neverite, ze by po letech hrabnul dodjbdns- verit tomu nemusite. Ovsem stale se bavime o tom, jak to mozna bude v budoucnosti -- ja zatim nevidim zadnz duvod, pro oddjbdnsprechazet nekam jinam. Az bude nejaky DNS server, ktery budu povazovat za lepsi, nezdjbdns, nedela mi problem prejit.
Opet jste nepochopil, o cem mluvim. Tak si zkuste promyslet ty dusledky trosku vice. Rozhodne nejde o klasicky trafik.Co vadi ISP? No, srovnejte si jeden konkretni port a 63k portu a co to vse prinasi do infrastruktury a monitoringu.Treba takova TCP/IP spojeni, kterzch je urcite vic, nes DNS odpovedi, maji take nahodne zdrojove porty. Nevypada to, ze by se z toho ISP hroutili...
Tezko rici, vetsinou jsou mezi nami prilis kratce, ale minimalne 2 se zdaji byt potencialne dobre. A aspon jeden ma sanci casem dotahnout se i trosku k Bindu.Prave proto mi pripada predcasne se zatim porozhlizet jinde. Az tady ty servery budou nejakou dobu, bude o nich znamo, jak se chovaji, jak se chovaji jejich autori, jake maji silne a slabe stranky, bude cas uvazovat o prechodu. Zatim k tomu nevidim duvod.
A mi nezbyva doufat, ze o problemech DJBDNS jeho uzivatele vedi.Ale jiste ze vedi. Ale zatim je to pro jednoduchy DNS server to nejlepsi, co je k dispozici.
Opet jste nepochopil, o cem mluvim. Tak si zkuste promyslet ty dusledky trosku vice. Rozhodne nejde o klasicky trafik.Nemuzete aspon naznacit? Nevidim duvod, proc by ISP sledoval DNS provoz klientu, jedine co ho muze zajimat je ochrana vlastnich DNS serveru -- takze filtrovat na vstupu prichozi provoz na port 53.
Unbound pro rDNS, NSD pro aDNS. V menších instalacích bych se nebál ani PowerDNS.Tech DNS serveru, ktere maji potencial prekrocit stin DJBDNS je dnes nekolik.To je dobre. A ktere to jsou? A jenom maji potencial, nebo je realne, ze v historicky kratke dobe ten stin opravdu prekroci?
Já myslím, že to není otázka víry. On do toho nehrábne, to je prověřeno léty.Protoze nepamatuju, ze by DJB pripustil, ze nekdy udelal chybu. Maximalne vysledek prohlasi za "nelze dosahnout v realnem svete". Neverim, ze po letech hrabne do DJBDNS. A tak to zase, tak jako v jinych pripadech, budou resit patche treti strany...Rekl bych, ze minimalne cislo verze1.05svedci o tom, ze nejake chyby priznal. No a ze neverite, ze by po letech hrabnul dodjbdns- verit tomu nemusite.
Ovsem stale se bavime o tom, jak to mozna bude v budoucnosti -- ja zatim nevidim zadny duvod, pro odPokud vám to pro vaše potřeby stačí, tak si u djbdns zůstaňte. Nicméně doporučuji sledovat, co bude teď, protože jak už jsem říkal, tak čistě náhodný zdrojový port možná nebude stačit.djbdnsprechazet nekam jinam. Az bude nejaky DNS server, ktery budu povazovat za lepsi, nezdjbdns, nedela mi problem prejit.
Unbound pro rDNS, NSD pro aDNS. V menších instalacích bych se nebál ani PowerDNS.Doufam, ze se objevi i nejake dalsi, jeste jednodussi. Jednoducha konfigurace a udrzba zonoveho souboru je podle mne velke plus pro
djbdns.
Nicméně doporučuji sledovat, co bude teď, protože jak už jsem říkal, tak čistě náhodný zdrojový port možná nebude stačit.Sledovat to bude asi kazdy, kdo ma s nejakym DNS serverem neco spolecneho. Ale otazka je, zda pujde ten problem dal nejak resit upravou serveru, nebo zda bude nutne udelat neco se samotnym protokolem (at uz by to bylo masovejsi prosazeni nejake existujici nadstavby, nebo vytvoreni nejake nove nadstavby).
Co byste na tom chtěl ještě zjednodušovat? Unbound v základní instalaci funguje a nemusí se nijak speciálně nastavovat. A konfigurační soubor NSD není o moc složitější.Unbound pro rDNS, NSD pro aDNS. V menších instalacích bych se nebál ani PowerDNS.Doufam, ze se objevi i nejake dalsi, jeste jednodussi.
Jednoducha konfigurace a udrzba zonoveho souboru je podle mne velke plus pro djbdns.
Myslíte formát, který je úplně jiný než běžně používaný standard, takže je pro většinu lidí nečitelný? A konfigurace djbdns není o mnoho jednodušší než konfigurace Unboundu nebo NSD. Dokonce si troufám tvrdit, že ani konfigurace Bindu není rocket-science.
Pokud vím, tak některé návrhy, které jsou ve hře, mohou vylepšit odolnost proti poisoningu úpravou serveru, resp. úpravou způsobu, jak se server chová k odpovědím.Nicméně doporučuji sledovat, co bude teď, protože jak už jsem říkal, tak čistě náhodný zdrojový port možná nebude stačit.Sledovat to bude asi kazdy, kdo ma s nejakym DNS serverem neco spolecneho. Ale otazka je, zda pujde ten problem dal nejak resit upravou serveru
nebo zda bude nutne udelat neco se samotnym protokolemDNSSEC - v současné době se začala hýbat situace okolo nástrojů, které nasazení DNSSECu výrazně zjednodušují. Podle mě je zapotřebí obojí a to první jen oddaluje problém.
Myslíte formát, který je úplně jiný než běžně používaný standard, takže je pro většinu lidí nečitelný?Ano, presne ten. Sice je ten format nestandardni, ale podle me dava mnohem vetsi smysl, nez ten "bezne pouzivany standard".
Pokud vím, tak některé návrhy, které jsou ve hře, mohou vylepšit odolnost proti poisoningu úpravou serveru, resp. úpravou způsobu, jak se server chová k odpovědím.Uvidime, zda takove upravy udela i DJB. Pokud ne, teprve to bude pro
djbdns problem...
DNSSEC - v současné době se začala hýbat situace okolo nástrojů, které nasazení DNSSECu výrazně zjednodušují.Uvidime, zda DJB uz bude povazovat DNSSEC za "stable, sensible" a zda bude existovat "detailed, concrete, credible plan for central DNSSEC deployment"
Proč by měl? Už jsem psal, že k nasazení DNSSECu to není potřeba. Prostě si z důvěryhodného místa stáhnete klíč pro např. .cz, ten vložíte do konfiguráku a zapnete DNSSEC. Navíce existují mechanismy (například DLV), jak tuto potřebu obejít. Ale chápu vás. Já jsem měl taky období, kdy jsem DJB "žral", protože píše fakt pěkný kód. Kdyby se nechoval jako Sheldon (hint: shlédněte The Big Bang Theory), tak by to mohl být fajn člověk.DNSSEC - v současné době se začala hýbat situace okolo nástrojů, které nasazení DNSSECu výrazně zjednodušují.Uvidime, zda DJB uz bude povazovat DNSSEC za "stable, sensible" a zda bude existovat "detailed, concrete, credible plan for central DNSSEC deployment"
To co bylo v uvozovkach jsou citace DJB, proc neni vProč by měl? Už jsem psal, že k nasazení DNSSECu to není potřeba. Prostě si z důvěryhodného místa stáhnete klíč pro např. .cz, ten vložíte do konfiguráku a zapnete DNSSEC. Navíce existují mechanismy (například DLV), jak tuto potřebu obejít.DNSSEC - v současné době se začala hýbat situace okolo nástrojů, které nasazení DNSSECu výrazně zjednodušují.Uvidime, zda DJB uz bude povazovat DNSSEC za "stable, sensible" a zda bude existovat "detailed, concrete, credible plan for central DNSSEC deployment"
djbdns implementovano DNSSEC...
Ale chápu vás. Já jsem měl taky období, kdy jsem DJB "žral", protože píše fakt pěkný kód. Kdyby se nechoval jako Sheldon (hint: shlédněte The Big Bang Theory), tak by to mohl být fajn člověk.Vite, ze mne je uplne jedno, ze je
djbdns zrovna od DJB? Mne vyhovuje proto, ze je bezpecny, jednoduchy a snadno se konfiguruje. Vadi mi jenom to, ze nekdo zacne psat o tom, ze by bylo dobre vymenit djbdns jenom proto, ze se mozna v budoucnosti najde chyba, na kterou mozna DJB nezareaguje. Vzhledem k tomu, ze djbdns mel tento pripad davno osetreny daleko lepe nez vetsina ostatnich serveru, zaslouzi si myslim jeho autor spis pochvalu, nez hned vyrukovat s tim, ze priste uz to urcite nezvladne.
Hlavně, když používáte typy RR záznamů, které djbdns nepodporuje... to je pak dává velmi smysl. Ač se to z pohledu běžného uživatele nezdá, tak protokol DNS se vyvíjí a djb na djbdns od té doby ani nešáhnul. EDNS0, nové typy RR záznamů... DNSSECbis raději ani nezmiňuji... Ale o vaší iluzi, že se o software není potřeba starat, takže je chování djb jako autora v pořádku, vám brát nebudu. Časem na to přijdete sám.Myslíte formát, který je úplně jiný než běžně používaný standard, takže je pro většinu lidí nečitelný?Ano, presne ten. Sice je ten format nestandardni, ale podle me dava mnohem vetsi smysl, nez ten "bezne pouzivany standard".
djbdns odumre. Ale zatim se tak nestalo ani s DNSSEC ani s IPv6, ktere k tomu maji naslapnuto asi nejlepe. Az se tak stane, bude odsuzovani djbdns na miste - ale odsuzovat jej ted za to, ze nekdy v budoucnosti asi nebude implementovana nejaka dulezita funkce? To je trochu predcasne...
Uvidime, zda DJB uz bude povazovat DNSSEC za "stable, sensible" a zda bude existovat "detailed, concrete, credible plan for central DNSSEC deployment"A ano, tady přichází překvapení... moment, ono to vlastně žádné překvapení není... konstruktivní přístup jako vždy: Tisková zpráva UIC:
DNS still vulnerable, Bernstein says CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so, beware: recent Internet patches don't stop determined attackers. Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure. "Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched," said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago. Bernstein's DJBDNS software introduced source-port randomization in 1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year. Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was "at best a speed bump for blind attackers" and "an extremely poor substitute for proper cryptographic protection." DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance. "We need to stop wasting time on breakable patches," Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet. Press contact: Daniel J. Bernstein <press-20080807@box.cr.yp.to>
Pokud to nejaky program udelal uz davno a jine to delaji az ted, vnimam to ten program jako plus - proc to vy vnimate se zapornym znamenkem stale nechapu.On to nekdo vnima se zapornym znamenkem?
Dalsi otazka je, jak se zachova DJBDNS pri tom druhem typu utoku, kdy se utocnik zepta na jine jmeno a pak serveru podvrhne v GLUE IP adresu pro uplne jiny server.Nevim, jak je to v tomto konkretnim pripade, ale obecne si
djbdns hlida, aby se zabyval pouze odpovedi na to, na co se ptal.
Výše zmiňovaný útok je údajně o náhodě, jak uhádnout jedno číslo z cca 4 miliard možných, se šifrováním je to podobné, jen bývá počet možností vyšší.
Navíc útok na koncového uživatele je nezajímavý, mnohem zajímavější je útok na rDNS nějakého velkého (nebo i menšího) ISP.jaky by ten utok na rDNS nejakeho ISP mel jiny smysl nez utok na mnoho koncovych uzivatelu? Pokud budu mit botnet rozprostreny po sitich koncovych uzivatelu a automaticke nastroje na utok pouzivajici lokalni DNS utok, tak muzu utocit na velke mnozstvi koncovych uzivatelu podobne snadno jako pres rDNS nejakeho ISP.
No nic, jdu si uzit vikend. A budu doufat, ze prislusne autority se o DNSSEC budou vice a vice zasazovat. Ja vim, nic prijemneho, ale nuda pomalicku konci
DNS protokol je v dnesni dobe az moc klicovyJako by kdy nebyl ...
A dusledky jsou neprijemne (Kaminsky je docela pekne rozebira).Prave ty dusledky se v mnoha clancich extremne prehaneji - vyznamne veci dneska uz snad bezi pres SSL, takze nanejvys jde o formu DoSu. Prumerny bezpecnostni bug (vedouci k spusteni kodu na klientovi) v IE nebo Mozille povazuju za mnohem vetsi riziko. Napriklad v odkazovanem clanku:
8.8.2008 18:16
* Read other people's e-mail
* Use fake websites to obtain passwords, access codes or payment card data etc. (known as phishing)
* Bypass anti-spam protection in DNS and spread spam
* Counterfeit messages and information displayed on websites
* Redirect or wiretap on phone calls routed through Internet
Ale uz nezmini, ze vsechny tyto veci jde delat mnoha jinyma zpusobama bez ohledu na tenhle problem, akorat mozna ne tak univerzalne.
Prave ty dusledky se v mnoha clancich extremne prehaneji - vyznamne veci dneska uz snad bezi pres SSL, takze nanejvys jde o formu DoSu. Prumerny bezpecnostni bug (vedouci k spusteni kodu na klientovi) v IE nebo Mozille povazuju za mnohem vetsi riziko.SSL? Myslíte to SSL, které je vydáváno na základě: a) informací ve WHOIS (DNS!) b) posláním emailu (DNS!) c) nahlédnutím na www stránky (DNS!) Stačí drobný útok na rDNS certifikační autority a certifikát je váš. Naštěstí se zdá, že CA zareagovaly poměrně rychle.
Napriklad v odkazovanem clanku: * Read other people's e-mailJako například číst veškerou firemní poštu? Napadnete firmu A a přesměrujete u ní MX záznamy firmy B k sobě.
* Use fake websites to obtain passwords, access codes or payment card data etc. (known as phishing)Důležitý je dopad, kdy můžete tímto zasáhnout mnoho uživatelů zároveň, a nezjistitelnost takového útoku na koncové stanici.
* Redirect or wiretap on phone calls routed through InternetNapříklad jak napadnete HW telefony, telefonní ústředny, atp.?
Ale uz nezmini, ze vsechny tyto veci jde delat mnoha jinyma zpusobama bez ohledu na tenhle problem, akorat mozna ne tak univerzalne.Nejedná se jen o univerzálnost, ale také o relativní "levnost" takového útoku, dopad i na uživatele, které by jinak nebyli zasažitelní a další věci. Pokud by se nezáplatovalo, tak celkový dopad je obrovský.
SSL? Myslíte to SSL, které je vydáváno na základě: a) informací ve WHOIS (DNS!) b) posláním emailu (DNS!) c) nahlédnutím na www stránky (DNS!)Ne, myslim SSL, kde uzivatel explicitne kontroluje fingerprinty certifikatu (napriklad KB je uvadi ve smlouve o elektronickem bankovnictvi). IMHO koncept CA jako 'obchodu s duverou', jak je casto vyuzivan v koncovem software (webove prohlizece) stylem 'je podepsany od CA -> automaticky duverujeme' obecne bezpecnost dost narusuje a strategii pouzivanou SSHckem 'pri zmene klice druhe strany vzdycky varovat' povazuju za mnohem lepsi.
Jako například číst veškerou firemní poštu?Treba odposlechnutim POP3 komunikace pomoci nakazeneho PC s Windows uvnitr firmy, poslechnutim nezabezpecene radiove komunikace mezi firmou a ISP (nemusi jit zrovna o wifi, kde uz sifrovani casto je, ale treba o 'profi' 10.5 GHz pojitko) nebo treba kdyz jsem ISP poskytujici dane firme konektivitu (a SMTP server).
Například jak napadnete HW telefony,Tohle je riziko - hromada hardwaru vyrabeneho ve velkych seriich podle referencniho designu od dokumentovanych chipu, takze se muze dost vyplatit v jejich firmware hledat buffer overflows. Urcite jich tam budou tuny. A prevazna vetsina z techto telefonu ma nikdy neupdatovany firmware. Tipuji, ze v mnohych techto telefonech bude spousta veci rizena ciste softwarove, takze po napadnuti takoveho telefonu bude mozne odposlouchavat zvuk v mistnosti, i kdyz bude telefon 'zavesen'. Z bezpecnosti VoIP je to vubec bida. Nejenom ze spousta hw telefonu nema implementovane SRTP (i kdyz treba pouzity hardware ma hw podporu pro sifrovani), ale navic soucasne praktiky VoIP operatoru routovat RTP streamy pres sebe, i kdyz to je casto zcela zbytecne, nasazeni SRTP dost brani.
Jestli opravdu před každým přihlášením internetového bankovnictví kontrolujete fingerprint certifikátu, tak tedy smekám klobouk...Proc pred kazdym? Proste v prohlizeci nemam certifikaty CA, ale jen ty, ktere jsem uz zkontroloval.
Jasně, takže když banka jednou za rok změní certifikát, tak voláte na infolinku? A kde vezmete číslo? Na webu? (DNS!)Jestli opravdu před každým přihlášením internetového bankovnictví kontrolujete fingerprint certifikátu, tak tedy smekám klobouk...Proc pred kazdym? Proste v prohlizeci nemam certifikaty CA, ale jen ty, ktere jsem uz zkontroloval.
I vás by se dalo napadnout. Teda pokud si fingerprint nechodíte ověřovat na pobočku a banka fingerprint na pobočky šíří nějakým bezpečným mechanismem (bez DNS ;)).
Bez DNS se v dnešním internetu neobejdu.Maily se daji sifrovat, VoIP se da sifrovat, prakticky vsechny protokoly se daji sifrovat treba pomoci IPsec - Bez velke (*) duvery v kryptograficky neoverene protokoly se v dnesnim internetu vesele obejdeme. (*) mala duvera (kdyz to utocnik napadne, nebude to fungovat, ale nedojde k podvrzeni) je snad pripustna.
Možná vy ano, ale řekl bych, že jste docela v menšině.Tipuji, ze kdokoliv zajimajici se o bezpecnost je docela v mensine. Znacna cast ma ty zavirovane windows nebo nezabezpecena pojitka.
Nicméně mi vysvětlete, jak budete šifrovat maily a VoIP, když nedůvěřujete CA?Pokud neni prilezitost explicitne overit certifikat, pak je rozumne pouzivat stejnou strategii jako u ssh - poprve duverovat, akceptovat a ulozit a pri dalsich spojenich testovat proti ulozenemu. Samozrejme to neni zcela bezpecne, ale pripadny utok by vyzadoval dlouhodobeho a velmi odhodlaneho utocnika, jinak se utok brzy odhali.
Např. router ISP toho, kdo takový paket posílá. Nemalá část z nich totiž zákazníkům nepustí "ven" pakety, které mají zdrojovou adresu mimo příslušný rozsah. Bohužel takový postup často škodí i rozumným věcem - kdyby to nedělali, byl by např. populární návod, jak řešit připojení přes dva ISP pomocí směrovacích pravidel, úplně zbytečný.
Na druhou stranu ale samozřejmě nejde spoléhat na to, že se takto budou chovat všichni ISP.
(pokud si sedne k isp, ktery takoveho neco dela (at uz je to vetsina nebo ne), tak se o nem asi nikdo nedozvi 
)