Názor k článku Postřehy z bezpečnosti: všechny prohlížeče opět pokořeny od Vít Šesták - Souhlasím, že špatné šifrování může být lepší než...

Souhlasím, že špatné šifrování může být lepší než žádné šifrování a jsou scénáře (např. zpětně zjištěné heslo k Wi-Fi), kdy útočník může pasivně poslouchat, ale nemůže provést MITM.

Nesouhlasím ale s touto aplikací na web. Hlášku o neplatném certifikátu až tak často nepotkávám (ledaže se pokusím to „s“ do adresy přidat ručně a autor webu s HTTPS nepočítal – to ale není případ BFU), naproti tomu by to přineslo spoustu problémů (a určitě tu bude něco, na co jsem nepomyslel):

1. Když zadám adresu s „https://“, očekávám, že v plaintextu bude putovat maximálně jméno domény (via DNS a SNI). Pokud bych měl nějaké tajemství v adrese (což není nereálné – share via link apod.), mohl by ho útočník snadno zjistit.
2. U dobrého webu očekávám, že když ho zadám s „https://“, tak pojede na HTTPS celou dobu.
3. Analogicky k 2. – pokud si chci stáhnout nějaký soubor a mít jistotu že ho nikdo nepozměnil, pak mi „https://“ v adrese nic nezaručí.
4. Při špatném certifikátu by se neměly posílat cookies, muselo by se dávat bacha na autocomplete hesel i na cross-origin policy. Nechtěl bych tady ověřovat, jestli se na něco nezapomnělo…
5. Co když se HTML načte dobře, ale bude obsahovat skripty, u jejichž stažení dojde k chybě s certifikátem? Pak je určitě nemohu spustit (fakticky bych k tomu měl přistupovat nejméně jako k mixed content, možná ale ještě o něco přísněji, protože tuto chybu může vyvolat jakýkoli útočník na síti). Řešení s neposláním cookies neprojde, HTML jsem už začal načítat a cookies jsem už poslal…
6. A celé mixed content není zrovna problém řešitelný touto cestou…

Nemyslím si, že by varování u špatného certifikátu u Firefoxu a Chrome udělali bez přemýšlení. Ale i kdyby, myslím si, že šli správnou cestou.

Varování u plain HTTP se minimálně zvažuje u Chrome, pak to bude konzistentní.