Názory k článku Bettercrypto.org: společně za lepší šifrování
Článek je starý, nové názory již nelze přidávat.
-
Nedavno som narazil na vycerpavajucu prirucku nastavenim SSH - Secure secure shell. Mozem iba odporucit.
-
"Je tak v podstatě vyloučeno na takovou stránku zaútočit útokem známým jako odstranění SSL."
Cože? Vždyť úplně stačí, když první připojení (nebo jakékoliv další po vypršení času) na danou stránku bude přes MITM, který tu HSTS hlavičku odstraní.
Pokud je potřeba tu komunikaci mít zabezpečenou, tak by server v první řadě vůbec neměl mít dostupné http a měl by poslouchat výhradně na https.
-
Ano, krásně jste shrnul podstatu TOFU přístupu − předpokládáme, že poprvé je všechno dobře. Ale i když není, dojde k uložení záznamu při nejbližší příležitosti. Udělat MITM útok a hlavičku odstranit je možné jen v případě, že jsme schopni provést nedetekovatelý MITM útok na TLS spojení. Pokud tohle někdo dokáže, pak samozřejmě žádné HSTS nemá smysl.
Doba života záznamu v tabulce důvěryhodných serverů se samozřejmě obnovuje, takže k vymazání dojde teprve v případě, že se k danému serveru nepřipojíme na delší dobu než
max-age, takže tady také velké riziko nehrozí. -
Spíš jde o to, jestli na místech, kde by někdo chtěl nasadit HSTS, rovnou místo toho nevypnout http.
Výsledek bude stejný (klienti pojednou na https a navíc vůbec nebude, ani teoreticky, hrozit riziko odstranění ssl). Podle mě je to lepší řešení právě proto, že se vyhne těm okrajovým podmínkám (např: co když už první přípojení bude přes MITM).
-
Tak, že uživatel napíše do prohlížeče http://adresa a místo automatického přesměrování na https, nebo – v případě nedostupného HTTP – odpovědi „Stránku nelze zobrazit, server odmítá spojení“ dostane požadovaný obsah, který by správně měl být dostupný jen pomocí https. To je podstata útoku známého jako odstranění SSL.
-
A ještě můžu dodat, že standard připouští i předinstalované položky v cache HSTS serverů. Ale samozřejmě, zase se dá argumentovat tím, že tyhle položky může útočník během instalace zachytit a pozměnit. Hlavně ale zatím nejspíš není cesta, jak by se provozovatelé webů mohli nechat na podobný seznam zapsat.
-
Tak DNSSEC v počítači je samozřejmě ideální stav, ale vzhledem k tomu, jak jsou OS konzervativní (stub resolver glibc je odstrašující příklad) a proti tomu jak se pružně zlepšují prohlížeče, vidím pravděpodobnější, že DNSSEC validace nejprve přijde do prohlížečů a teprve později se stane součástí operačních systémů.
Pro začátek by dost pomohlo, kdyby si co nejvíc lidí nainstalovalo TLSA a DNSSEC validátory jako rozšíření a hlásili případné problémy.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Proc? Nevyrabej atomovou bombu, chtej nejak zajistit zakladni bezpecnost => pouzijou vyhovujici reseni.
Mas doma dvere? Fabku? A viz ze kazdej zrucnej zamecnik/zlodej to zvladne bez poskozeni otevrit behem nekolika vterin? A kdyz na to prijde, tak to kazdej druhej kolemjdouci vykopne?
Nebo mas ocelovy osteni a v tom zaveseny pultunovy vrata?
-
Lael Ophir (neregistrovaný) ---.145.broadband14.iol.cz
Ad Mas doma dvere? Fabku? - to bydlíte v Unimo buňce? Dobrým standardem jsou bezpečnostní dveře s jisticími body (měly by zvenku vypadat obyčejně), kvalitně ukotvené zárubně vylité betonem, bezpečnostní zámek, a alarm s minimálně bezdrátovými čidly a napojením na PCO. V prvních dvou poschodích bych doporučil minimálně fólie na skla.
Navíc srovnání s internetem moc nesedí. Na netu totiž může bad guy zkusit z pohodlné židle minimálně stovky "dveří" za minutu, a navíc neriskuje že ho na místě pokouše pes nebo zastřelí majitel.
-
xor (neregistrovaný) ---.czechdata.cz
".. Bezpečnost koncových zařízení je však bohužel tak hrozně špatná, že NSA často dokáže najít cestu, jak šifrování obejít."
Takže autoři se soustředí tam, kde tomu asi rozumí, ale vůbec nepokrývají zranitelnost koncových zařízení. Jaké koncové zařízení bude pro univerzální použití (protože jednoúčelové ani poučený uživatel nechce) přijatelné? Další článek? Díky
-
- CUSTOMER SERVICE SENIOR ANALYST
- Perl / Python / Linux Developer
- SOFTWARE ENGINEER C++
- Programátor JAVA
- Programátor webových aplikací
- .NET Developer
-
- Prezentování v němčině
- Zkratky v online komunikaci
- Začínáme s fundraisingem
- Obsahová strategie IV: Strategie prakticky
- Osobní styl muže jako brána k úspěchu
- Pokročilejší grafy v Excel
-
- CUSTOMER SERVICE SENIOR ANALYST
- Programátor .NET aplikací
- Perl / Python / Linux Developer
- Programátor JAVA
- Programátor webových aplikací
- Windows administrátor se srdcem na správném místě
-
- Přecházíme na Mac
- Zkratky v online komunikaci
- Organizujte své poznámky s Evernote
- Začínáme s fundraisingem
- Osobní styl muže jako brána k úspěchu
- Pokročilejší grafy v Excel
2. 2. 2015 0:34
> Zajímavá je také zmínka o nevhodnosti použití DSA klíčů na strojích, kde se dá nedostatek entropie předpokládat. Na rozdíl od RSA totiž případné znovupoužití stejného klíče relace nevede jen k prozrazení obsahu šifrované komunikace, ale i ke kompromitaci DSA klíčů.
Minimálně tu kompromitaci řeší deterministické DSA (zjednodušeně řečeno jako náhodný vstup se použije hash zprávy, kterou podepisujeme). Upřímně řečeno mi není jasné, jak vůbec někoho mohlo napadnout používat nedeterministické.