OT: HTTPS certifikát, který servíruje váš webserver, má platnost do 21.6.2012 11:40:51. Momentálně je 14:30, takže prohlížeče už při přístupu nadávají...
Ma to reseni. Certifikaty, i self-signed, by sly kombinovat s web-of-trust podpisy pomoci napr. GnuPG. Detached signature certifikatu se pak ulozi na server se standardizovanym jmenem (napr. https://dome.na/sslsign.gpg). Browser extenze pak muze kontrolovat zda je certifikat gpg-podepsan nekym duveryhodnym, a zobrazovat pozici podpisu v web-of-trust jednotlivych klicu. Kontrola pres SSL pak muze byt provedena paralelne s kontrolou pres GnuPG.
V případě, kdy URL předáváš elektronicky, není problém s ní prostě předat i otisk veřejného klíče serveru na druhé straně. Takhle by šlo vygenerovat šíleně propletenou a ohromnou web of trust. Stačilo by to jenom nějak implementovat. E.g.:
<a href="https|BASE64encodedFINGERPRINT://kinderporno.cz/d/blah>Dětské porno zdarma ke stažení</a>
Vychází to z toho, že ten, kdo odkaz šíří, webu věří, resp. prvotní publikovatel odkazu to stejně musel dát do nějakého zabezpečeného média (jinak by nepomohla ani svěcená voda).
V případě papírového předání je to horší, ale řekněme, že já bych ten 20znakový řetězec klidně zkontroloval. Případně máme QR kódy.
Bylo pochopitelné, co jsem tím chtěl říct? Co si o tom myslíte?
20 znaků je málo, base64 má 6 bitů na znak a tak by byla síla hashe jen 120 bitů a to je dokonce míň než md5, tedy kolize! Radši aspoň 40 znaků :-D.
Jinak nápad předávat fingerprint v url je zajímavej, akorát by to lehko svádělo uživatele k opomenutí druhého potvrzovacího kanálu a útočníky k MITM útoku a pokusu o falšování všech fingerprintů.
Kolize v MD5 jsou způsobeny kryptografickými útoky, nikoli vyčerpávajícím hledáním. Podle mě 2^120 nespočítáš a ještě hodně dlouho nikdo nespočítá. Kdyby jo, tak můžeme zahodit všechny 128b symetrické šifry.
Jádro myšlenky bylo v tom, že pokud útočník může podvrhnout fingerprint v URL, může podvrhnout i URL samotnou - tj. v takovém případě by ti nepomohlo ani současné schéma s CA.
Internetoví poskytovatelé v Kazachstánu začali provádět Man-in-the-middle útok na všechna HTTPS spojení. Podle zdůvodnění „V souvislosti s častými případy krádeží osobních a pověřovacích údajů, jakož i penězi z bankovních účtů Kazachstánu bylo zavedeno bezpečnostní osvědčení, které se stane účinným nástrojem pro ochranu informačního prostoru země před hackery, internetovými podvodníky a dalšími typy kybernetických hrozeb. Zavedení bezpečnostního certifikátu přispěje k ochraně informačních systémů a dat ak identifikaci hackerských kybernetických útoků internetových podvodníků na informační systémy v zemi, soukromé, včetně bankovního sektoru, dříve, než mohou způsobit škody.“
Červnový pražský sraz spolku OpenAlt zahájí Jaroslav Tulach z Oracle Labs přednáškou na téma Úvod do GraalVM – nejrychlejšího virtuálního stroje na světě. Následovat bude neformální setkání a diskuse na téma GraalVM. Sraz se koná ve čtvrtek 20. června od 18:00 v Praze – místo ještě upřesníme. Akce je volně přístupná (i Go nebo Rust programátorům), ale z kapacitních důvodů prosíme, abyste nám dali vědět, že přijdete – e-mailem na graalvm-2019-06-20@openalt.org nebo zde na webu. (není to povinné, ale pokud by se nás sešlo moc, přednost budou mít ti, kteří se přihlásili včas)
Dubnový sraz spolku OpenAlt se koná ve čtvrtek 25. 4. 2019 v Pivovarském klubu od 18:00. Najdete jej kousek od metra Florenc na adrese Křižíkova 17°, Praha 8. Sejdeme se zase u dobrého piva a popovídáme si o tématech jako umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Březnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 21. 3. 2019 od 18:00 v Šenkýrně Hlubina (Lidická 37, Praha 5). Sejdeme se zase u dobrého piva a popovídáme si o tématech jako umění a technologie, IoT, CNC, svobodný software, hardware a další hračky. Pro zájemce budou tentokrát k dispozici i nějaké samolepky s GNU/Linuxovou tématikou.
V diskusi na AbcLinuxu byl oznámen zajímavý projekt Farma Trollí hnízdo. Má se jednat o diskusní fórum s (téměř) absolutní svobodou slova (zakázaná je jen pornografie a spam). Fórum je přístupné pouze v síti Tor a staví na svobodném softwaru Discourse. Pro přispívání je nutná registrace (číst lze i bez ní), ale nevyžaduje zadání žádných osobních údajů – diskutující tedy můžou zůstat v anonymitě.
Ondřej Závodský, náměstek MF pro hazard, autor cenzury internetu v ČR a člověk který nikdy v životě nešifroval se v rozhovoru pro DVTV nechal slyšet (12. minuta), že se bude snažit potrestat providery, kteří nechávají přístupné stránky s návody jak obejít blokaci. To samozřejmě nemá oporu v zákoně (zatím).
Nějak jsme vás zapomněli informovat o probíhající kauze „klekání na firmy“, tak to napravujeme: 1, 2, 3, 4, a finanční správa si z prohraných soudů dělá prdel. MEME: „Omlouvám se za zlikvidované firmy, ale peníze šly do státního rozpočtu, mají z toho prospěch všichni lidé.“ --Ivan Pilný.
Komentáře
Btw. ten odkaz "rozhodně není
Btw. ten odkaz "rozhodně není poprvé" - to je síla, co?
Jo. Ale je to jen v softwaru.
Jo. Ale je to jen v softwaru.
Certifikát
OT: HTTPS certifikát, který servíruje váš webserver, má platnost do 21.6.2012 11:40:51. Momentálně je 14:30, takže prohlížeče už při přístupu nadávají...
Řešení in progress, CA má
Řešení in progress, CA má nějaký problém s webem.
Stejně bych certifikátům od „důvěryhodných“ autorit nevěřil :)
SSL vs web-of-trust
Ma to reseni. Certifikaty, i self-signed, by sly kombinovat s web-of-trust podpisy pomoci napr. GnuPG. Detached signature certifikatu se pak ulozi na server se standardizovanym jmenem (napr. https://dome.na/sslsign.gpg). Browser extenze pak muze kontrolovat zda je certifikat gpg-podepsan nekym duveryhodnym, a zobrazovat pozici podpisu v web-of-trust jednotlivych klicu. Kontrola pres SSL pak muze byt provedena paralelne s kontrolou pres GnuPG.
Šel bych na to trošku
Šel bych na to trošku jinak.
V případě, kdy URL předáváš elektronicky, není problém s ní prostě předat i otisk veřejného klíče serveru na druhé straně. Takhle by šlo vygenerovat šíleně propletenou a ohromnou web of trust. Stačilo by to jenom nějak implementovat. E.g.:
<a href="https|BASE64encodedFINGERPRINT://kinderporno.cz/d/blah>Dětské porno zdarma ke stažení</a>
Vychází to z toho, že ten, kdo odkaz šíří, webu věří, resp. prvotní publikovatel odkazu to stejně musel dát do nějakého zabezpečeného média (jinak by nepomohla ani svěcená voda).
V případě papírového předání je to horší, ale řekněme, že já bych ten 20znakový řetězec klidně zkontroloval. Případně máme QR kódy.
Bylo pochopitelné, co jsem tím chtěl říct? Co si o tom myslíte?
20 znaků je málo, base64 má 6
20 znaků je málo, base64 má 6 bitů na znak a tak by byla síla hashe jen 120 bitů a to je dokonce míň než md5, tedy kolize! Radši aspoň 40 znaků :-D.
Jinak nápad předávat fingerprint v url je zajímavej, akorát by to lehko svádělo uživatele k opomenutí druhého potvrzovacího kanálu a útočníky k MITM útoku a pokusu o falšování všech fingerprintů.
Kolize v MD5 jsou způsobeny
Kolize v MD5 jsou způsobeny kryptografickými útoky, nikoli vyčerpávajícím hledáním. Podle mě 2^120 nespočítáš a ještě hodně dlouho nikdo nespočítá. Kdyby jo, tak můžeme zahodit všechny 128b symetrické šifry.
Jádro myšlenky bylo v tom, že pokud útočník může podvrhnout fingerprint v URL, může podvrhnout i URL samotnou - tj. v takovém případě by ti nepomohlo ani současné schéma s CA.
Jestli použiješ něco jinýho
Jestli použiješ něco jinýho než MD5 tak pak jo.