Certifikáty s SHA-1 ve Firefoxu zakázány a opět povoleny

Již v září 2014 Mozilla plánovala, že od 1. ledna 2016 budou ve Firefoxu https spojení založena na certifikátech s SHA-1 vydanými po 1. lednu 2016 považována za nedůvěryhodná. V říjnu 2015 byl plán potvrzen a od 1. ledna začal Firefox 43 certifikáty s SHA-1 vydanými po 1. lednu odmítat. Pro uživatele s přímým přístupem do internetu se nic nezměnilo. SHA-1 je na ústupu a nové certifikáty s SHA-1 se už běžně nevydávají. Problém ale měli uživatelé Firefoxu, na které byl prováděn MITM "útok" pomocí neaktualizovaných bezpečnostních skenerů, antivirových produktů a firewallů online generujících certifikáty s SHA-1. Mozilla problém (Bug 1236975, diskuse) vyřešila vydáním Firefoxu 43.0.4 (poznámky k vydání), ve kterém certifikáty s SHA-1 opět (dočasně) povolila. Více v příspěvku na blogu Mozilly věnovaném bezpečnosti.

Aktuálnímu dění kolem SHA-1 se podrobně věnoval Ryan Sleevi, vývojář v Google, v článcích A History of Hard Choices a Legacy Verified: Legacy Solutions publikovaných 27. prosince 2015 na Medium.

Poslední útok na SHA-1 pojmenovaný The SHAppening (Wikipedie) byl publikován 8. října 2015.

7.1.2016 13:42 | Ladislav Hagara | Komunita

Komentáře

[Harvie.CZ]

Takze jako antiviry na windows desifrujou HTTPS traffic a pak ho znova zasifrujou svym klicem a podepisou svoji CA, kterou vnuti do systemu? To je hnus...

[Martin Tůma]

Nejenom na Windows, dělá se to i na Linuxu nebo OS X. Pokuď se potřebuješ dostat k obsahu HTTPS spojení, tak je to ta nejobecnější metoda, která existuje.

Celé HTTPS je o víře ve vydavatele certifikátů. Můžeme s tím nesouhlasit, můžeme diskutovat jestli radši věřit výrobcům AV, nebo Čínské vládě, ale to je asi tak všechno co proti tomu můžeme dělat...

[Zopper]

Tak tak. Buď chci, aby mi antivirus kontroloval i HTTPS spojení, a pak musí dělat "MITM", nebo se mi přes HTTPS může dostat do pc cokoliv a musím doufat, že to antivirus zachytí při pokusu o zápisu na disk. Těžký výběr, protože přístup antiviru k té komunikaci mi nevadí, ale vadí mi, že v tu chvíli nemám možnost si zkontrolovat certifikát webu, nastavit si vlastní důvěryhodné autority a podobně.

[Martin Tůma]

Antiviry obecně používají systémový keychain/certstore, takže možnost nastavit si vlastní důvěryhodné autority je stejná jako bez AV. Co se týče kontroly certifikátu, tak opět většina AV "přepodepisuje" tak, že změní pouze vydavatele, zbytek certifikátu zkopíruje, takže základní info vidět je.

[Martin Tůma]

Tak tak. Buď chci, aby mi antivirus kontroloval i HTTPS spojení, a pak musí dělat "MITM"

Lze to i jinak. Většina prohlížečů například umožňuje "realtime" exportovat klíče SSL spojení, které může AV použít k dešifrování. Pokuď se upraví systémový "spuštěč" tak, že pro každý známý proces bude při spuštění přidávat potřebné parametry, lze sledovat HTTPS provoz i bez MITM. Má to ale samozřejmě také své nevýhody.

[pavele]

https mi připadá jako naše zákony + výjimky ze zákona...

[j]

Lepe receno, cele https je vohovne ...

Jinak se tohle celkem bezne dela v korporatu, kde se ovsem scanuje na nejaky GW/proxy ... i proto viz vejs...

Sranda na tom je predevsim to, ze se strasne rve, aby vse jelo pres https, vi se, jak tenhle problem vyresit, ale resit se to nechce.

[Petr Tomášek]

Hnus, velebnosti.

[Mintaka]

A neřešilo by tohle a kupu dalších problémů, kdyby šifrování bylo už v základech komunikace po Internetu? Pak by anitvir mohl stát mezi aplikací a datovým tokem v místě, kde už je rozšifrovaný a dělat svou práci.

Raději bych měl v kompu jednu specializovanou aplikaci, která bude šifrování řešit, než aby si to každá aplikace řešila tak trochu po svém.

[Petr Tomášek]

Hlavne by to resilo spoustu problemu pro hackery a smiraky, pro ktere by pak bylo jednodussi hacknout tuto jedinou aplikaci a poprdeli...

[Mintaka]

Nejsem zastáncem monokultur, ale v tomto případě bych volil raději "Secure by design" než "Security through obscurity". S tím "jedním programem" to nebyla vhodně zvolená slova. Mám na mysli spíše řešení na nižší úrovni (proto ten topic ISO/OSI), než na úrovni jednotlivých aplikací. Běžně v aplikaci neřešíte nízkoúrovňové věci typu balení dat do paketů a neprogramujete TCP/IP stack a sockety. Používáte už hotová a připravená řešení, stejně jako to dělá většina aplikací komunikujících po síti.

Pokud by si nějaká aplikace chtěla nad tímto šifrováním řešit ještě vlastní úroveň zabezpečení, klidně by mohla.

[Jendа]

Huh?

Jako že někdo získá možnost manipulovat s něčím ipsec-like, tedy hodně lowlevel věcí v systému, a z nějakého důvodu se odtamtud nedostane/nedokáže dostat k userspace procesu Firefoxu?

[Mintaka]

Re: ...někdo získá možnost...:

Kdo to je Někdo? Výrobce programu, který jsem nainstaloval do systému a de facto mu dal práva odvozená od práv uživatele, pod kterým je spouštěn a který vykonává svůj kód na mém CPU?

[Jendа]

Kdo to je Někdo?

Útočník, a je jedno, jak se tam dostal. Způsobů je dost; ve většině případů bych to dnes viděl na bezpečnostní díry v programech, případně nedůvěryhodné zdroje programů.

[Jendа]

Ano, řešilo. A 256 dalších problémů, například by si každý protokol nemusel specifikovat šifrování sám s vlastními chybami a každá aplikace by to nemusela dělat a nastavovat znova s vlastními chybami.

A já jako admin bych si netrhal vlasy při debugování aplikace, které komunikuje šifrovaně, a nenabízí žádnou možnost, jak ta data přečíst (typicky úplně všechny démony při použití forward secrecy - exportování session klíče je nepodporované v nich, ve Wiresharku, nebo je to alespoň strašná magie nastavit).