Posuzování bezpečnosti webových aplikací jen dle testů SSL konfigurace?

Bohužel běžná praxe. Na internetu je možné nalézt spoustu studií porovnávajících bezpečnost webových aplikací dle SSL konfigurace, většinou s využitím nástroje od SSL Labs, který to umí i hezky oznámkovat (A až F nebo T).

Jenže jaké má toto hodnocení vypovídající hodnotu? Pojďme se krátce zamyslet, nad některými parametry SSL, které jsou příčinou horšího hodnocení ze strany výše uvedeného nástroje.

Poznámka: Sám tento nástroj rád používám, ale vím, že je to jen a pouze nástroj na prověření SSL konfigurace, a že je nutné prověřit mnoho dalších parametrů web. serveru a aplikace, které častokrát určují bezpečnost mnohem více. Nejednou jsem totiž při analýze malware viděl, jak webové prohlížeče nadšeně ukazují, jak je SSL/TLS spojení bezpečné, zatímco malware z tohoto „bezpečného“ spojení vesele kradl citlivé informace.

Web, který používá selfsigned certifikát je automaticky označen jako nedůvěryhodný.

Ano, útočník si může vydat svůj vlastní certifikát, a podepsat ho svojí vlastní certifikační autoritou, ale pokud si takový certifikát vydá např. banka nebo jiná organizace a distribuuje ho bezpečným způsobem svým klientům, tak může být paradoxně web opatřený takovým certifikátem považován za důvěryhodnější než web opatřený certifikátem od důvěryhodné kořenové certifikační autority.

Kauzy DigiNotar nebo WoSign nám jasně ukázaly, že ani důvěryhodná certifikační autorita není zárukou bezpečnosti, neboť může být kompromitována stejně jako jakákoliv jiná organizace.

V rámci certifikačního řetězce má kořenový certifikát certifikační autority slabou hashovací funkci SHA1, přestože ostatní certifikáty mají SHA256.

To přeci není problém pokud selfsigned kořenový certifikát použil sám pro sebe slabý hashovací algoritmus. Problém je, když certifikační autorita vydává (podepisuje) certifikáty se slabým hashovacím algoritmem. Možná to někoho překvapí, ale falešný certifikát zneužívající kolize hashů skutečně nevznikne tak, že si vezmu jeden certifikát a nějak spočítám ten druhý falešný, protože jedna věc je stejný hash a druhá věc je zašifrování hashe privátním klíčem CA (to je ten podpis certifikátu danou CA). Pokud by to takto chtěl útočník udělat, musel by získat nebo spočítat privátní klíč CA a pokud by se mu to podařilo, tak proč by ještě potřeboval řešit nějaké kolize, když si může generovat certifikáty dle libosti. Při vytváření falešného certifikátu nehledáme obyčejné kolize hashů mezi 2 soubory dat, ale mezi skupinami dat, kde jsou již některé části dané a nelze je měnit (kolizní útok se zvoleným prefixem). Pro více informací doporučuji přečíst názornou prezentaci, kde je demonstrováno vytvoření falešné certifikační autority zneužitím MD5 kolize.

A přesto ještě před pár měsíci Google Chrome zobrazoval v tomto případě (např. u GlobalSign Root CA) červeně přeškrtnutý zámeček, tedy že jde o nedůvěryhodné spojení, stejně jako by právě probíhal na uživatele útok MiTM. Naštěstí je to už opraveno, ale určitě to nemálo uživatelů vystrašilo.

Podpora slabších šifrovacích algoritmů, kdy důsledkem jejich použití může být možnost realizovat tzv. downgrade útok?

Při tomto útoku vnutí útočník web. serveru a  prohlížeči slabý šifrovací algoritmus kvůli následnému snazšímu dešifrování zachycených dat. Za úmyslně oslabenými šifrovacími algoritmy stojí státní moc, a bohužel to, co v daném čase bylo počítačově prolomitelné pouze movitým státním organizacím, bývá po pár letech možné i méně movitým nestátním a po 10-15 letech už komukoliv.

Ale nepropadejme hned panice, pokud server podporuje i nějaké slabší šifrovací algoritmy. Nejsou tam proto, že by daná organizace byla neschopná, ale nejspíš proto, že má ještě spoustu klientů, kteří používají starší verze OS a prohlížečů. Vy ostatní se  můžete poměrně snadno bránit zásahem do konfigurace webového prohlížeče a slabé algoritmy zakázat.

A co dnes tak často uváděný HSTS (HTTP Strict Transport Security) mechanismus popsaný v RFC6797, který do hlavičky odcházející ze serveru, přidává záznam, že daný server je dostupný pouze přes HTTPS protokol?

Klient si tuto informaci uloží a příště již ví, že daný server je dostupný pouze přes HTTPS. Druhou ještě bezpečnější možností je, že daný server je uveden v tzv. pre-load listu webového prohlížeče.

Až potud to vypadá jen dobře, ale je potřeba si uvědomit, že jakmile je server v HSTS seznamu, pak už se jinak než zabezpečeně na daný server nepřipojíte. Obecně ale asi není důvod HSTS nepoužívat. Použití HSTS je potřeba dobře promyslet, zda se na web bude připojovat pouze přes HTTPS, protože pokud web přidáte do pre-load listu, tak může být problém ho zase rychle odebrat.

A pak tu máme ještě nejrůznější útoky na zranitelnosti v šifrovacích protokolech.

Za zmínku ještě stojí tzv. „forward secrecy (FS)“, což označuje vlastnost, že prozrazení soukromého klíče neumožní kompromitaci dřívější zachycené zabezpečené komunikace. Ale opět ne vše, co má nálepku FS, je bezpečnostně dostatečné. Např. takový Logjam útok (ohrožené jsou všechny servery s podporou DHE_EXPORT = jinými slovy exportní oslabené šifry), detailnější popis i s návodem jak to správně nastavit je zde.

Tyhle útoky jsou však v praxi využívány k útokům na webové aplikace minimálně, což ale neznamená, že by neměly být příslušné zranitelnosti co nejdříve odstraněny.

Posouzení bezpečnosti webových aplikací je složitější než se nám snaží namluvit někteří bezpečnostní experti ve svých zjednodušujících studiích, ale s použitím zdravého selského rozumu, lze potřebnou úroveň bezpečnosti webové aplikace posoudit a zajistit správnou kombinací opatření na více vrstvách.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.