it-swarm-eu.dev

Jaká zranitelnost může být způsobena zástupným certifikátem SSL?

V komentáři k tato odpověď , AviD říká:

"Existuje řada bezpečnostních problémů s zástupnými SSL certifikáty."

Jaké jsou tedy problémy? Chápu, že stejný soukromý klíč se používá ve více kontextech, ale vzhledem k tomu, že jsem mohl hostit všechny své aplikace pod stejným názvem hostitele, nevidím to jako „nový“ problém zavedený zástupnými certifikáty.

46
user185

„Zástupný certifikát“ je certifikát, který obsahuje jako možný název serveru název obsahující „* "znak. Podrobnosti jsou v RFC 2818, oddíl 3.1 . Sečteno a podtrženo: když certifikát serveru obsahuje *.example.com, bude přijato klienty jako platný certifikát pro jakýkoli server, jehož zjevné jméno odpovídá tomuto jménu.

V oblasti certifikace webových stránek existují čtyři hlavní aktéři:

  • Samotný server SSL.
  • Prodejce webového prohlížeče, který bude klient používat.
  • Lidský uživatel, který do určité míry řídí, co bude klientský prohlížeč dělat.
  • CA, který vydal certifikát serveru.

Zástupné certifikáty nenaznačují další zranitelnosti serveru SSL; SSL server opravdu nemá zájem na pohledu na svůj vlastní certifikát. Tento certifikát je ve prospěch klientů, aby je přesvědčil, že veřejný klíč obsažený v certifikátu je skutečně veřejným klíčem pravého serveru SSL. Server SSL zná vlastní pár veřejných/soukromých klíčů a nemusí o tom být přesvědčen.

Lidský uživatel netuší, co je veřejný klíč. Co vidí, je ikona visacího zámku a co je důležitější, zamýšlený název server: to je jméno napravo od "https:// "a před další" / ". Webový prohlížeč předpokládá zpracování technických údajů o ověření správnosti názvu, tj. Ověření certifikátu serveru a ověření, zda se název shoduje s názvem, který je zapíše-li se do uvedeného certifikátu. Pokud prohlížeč tuto úlohu neprovede, bude považován za nedbalý a nepřevezme svou roli, což může mít vážné obchodní důsledky, možná i legální. Obdobně je CA smluvně vázán dodržováním stanovených postupů pro identifikaci vlastníků SSL serverů, aby bylo pro útočníky obtížné získat falešné certifikáty (smlouva je mezi CA a jeho über-CA, rekurzivně, až na kořenovou CA, která je sama vázána paktem s OS nebo prodejcem prohlížeče, který přijato za účelem zahrnutí kořenového klíče CA do OS nebo prohlížeče za definovaných podmínek).

To znamená, že prohlížeč a [~ # ~] ca [~ # ~] musí v praxi , rozmazlovat uživatele procesem ověření. Jsou více či méně povinni (ze zákona nebo, ještě přísněji, z obchodních důvodů), aby zabránili podvodníkovi uživatele pomocí falešných stránek, které vypadají oprávněně. Hranice mezi úlohou uživatele a úlohou prohlížeče/CA není jasně definována a historicky se posunula. V Days of Yore, myslím asi před deseti lety, prohlížeče vytiskly pouze nezpracovanou URL a bylo na lidském uživateli, aby v něm našel název serveru. To vedlo kované operátory webů (tj. „Phishingové weby“) k použití URL, které jsou technicky platné, ale zavádějící, jako je tato:

https://www.Paypal.com:[email protected]/confirm.html

Vzhledem k tomu, že lidští uživatelé jsou lidé a většina z nich čte zleva doprava (nejbohatší a naivní podvodné cíle jsou stále v západních zemích), začnou na vlevo, viz www.Paypal.com, zastavte se u dvojtečky („příliš technické“) a buďte scammed.

V reakci na to dodavatelé prohlížečů uznali, že schopnosti lidských uživatelů analyzovat URL nejsou tak dobré, jak se původně předpokládalo, a proto poslední prohlížeče zvýrazňují část domény. Ve výše uvedeném případě by to bylo xcvhjvb.com a rozhodně ne nic s Paypal.com v tom. Nyní přichází část, kde zástupné certifikáty vstoupit do hry. Pokud majitel xcvhjvb.com koupí zástupný certifikát obsahující "*.xcvhjvb.com ", pak může nastavit phishingový web s názvem:

https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html

který bude prohlížečem přijat (odpovídá názvu zástupného znaku) a bude stále pravděpodobně zachycovat nežádoucí uživatele (a je jich mnoho ...). Toto jméno mohl útočník koupit , aniž by se uchýlil k zástupným znakům, ale pak by zaměstnanci CA viděli jméno se zjevným podvodným pokusem (dobrý CA do ověření platnosti každé žádosti o osvědčení člověkem nebo alespoň upozorňování na jména, která jsou velmi dlouhá a/nebo obsahují v nich známé názvy bank).

Proto zástupné certifikáty snižují účinnost opatření proti podvodům na straně CA. Je to jako prázdný podpis od CA. Pokud budou pokusy o phishing na základě zástupných znaků běžnější, lze očekávat, že bude existovat jedno nebo několik z následujících opatření:

  • Prohlížeče zvýrazňují pouze části názvu domény, které se shodují s prvky, které nejsou v zástupném znaku v certifikátu.
  • CA vyžadují těžší papírování a smlouvy pro zástupné certifikáty (a ty budou dražší).
  • Prohlížeče zcela deaktivují podporu pro zástupné certifikáty.

Ve skutečnosti očekávám, že všechna tři opatření budou použita v příštích letech. Mohl bych se o tom úplně mýlit (to je problém s předpovídáním budoucnosti), ale tohle je pořád můj pocit střeva.


Můžeme také zdůraznit, že zástupné certifikáty jsou užitečné pro sdílení stejného páru klíčů mezi různými názvy serverů , což zvyšuje pravděpodobnost, že soukromý klíč bude sdílen mezi různými servery. stroje . Cestování soukromými klíči je samo o sobě bezpečnostním rizikem; čím více soukromý klíč putuje, tím méně „soukromý“ zůstává.

35
Thomas Pornin

Je špatnou praxí šířit stejný soukromý klíč na více serverů poskytujících různé služby: Jakékoli zneužité bezpečnostní problémy v jakékoli službě odhalí soukromý klíč použitý pro všechno.

Je však běžné používat zástupné certifikáty k izolaci webového obsahu přispívaného uživateli do subdomén specifických pro uživatele, aby se využila stejná zásada původu. Stejný přístup se běžně používá k vykreslování nedůvěryhodných portletů. Je součástí Open Social "standard".

Na mém pracovišti vyvíjíme software, který obsahuje otevřenou sociální implementaci a používá nastavení zástupných znaků. Instalace zákazníků byla podrobena penetračním testům. Nastavení zástupných znaků nebylo kritizováno.

18

Nakonec mnoho zranitelností uvedených v těchto odpovědích pochází ze smíšené úrovně důvěry. Pokud ale chápete, jak zástupné znaky fungují, můžete tyto chyby zabezpečení u konkrétních případů použití zmírnit. Domnívám se, že podrobnější vysvětlení toho zlepší užitečnost této otázky a jejích odpovědí.

Pokud všechny systémy ve vaší doméně nemají stejnou úroveň důvěryhodnosti, je použití zástupného certifikátu pro pokrytí všech systémů pod vaší kontrolou špatný nápad. Subdomény DNS však můžete použít jako segmentační nástroj. Jak řekl Hendrik, protože zástupné znaky neprocházejí subdoménami, můžete certifikát s zástupnými znaky omezit na konkrétní jmenný prostor. Pokud jste například měli farmu CDN, mohli byste zástupné znaky pouze *.cdn.example.com. To udržuje hostitele v example.com sám (jako www.example.com) odděleně a mohli byste vydat samostatný certifikát pro www.example.com.

Jak AviD zmínil od OWASP: interní pracovní stanice, vývojové systémy atd. Patří do nižších úrovní důvěry. Hostitelé, jako jsou tito, by však přesto měli být ve vlastním interním doménovém prostoru (například prv.example.com). Protože zástupné znaky nepřecházejí subdomény, *.example.com cert nelze použít na prv.example.com hostitelé. (Tím by se oddělily veřejné a soukromé vlastnosti, ale zjevně se neoddělovaly soukromé vlastnosti od sebe. Mohly by se použít jiné zástupné znaky subdomény, mapované na odpovídající úroveň důvěryhodnosti).

Zatímco tento článek o eWeek uvádí, že soukromý klíč lze sdílet na více hostitelích, tento SSLShopper rebuttal říká, že někteří emitenti (jako DigiCert) vám umožňují generovat samostatné soukromé klíče pro každý zástupný hostitel. Tím se sníží část užitečnosti zástupných karet, ale rozhodně se tím sníží problém sdílených soukromých klíčů a za určitých okolností to může být užitečné. Jinak tento článek Entrust a whitepaper PDF, na který odkazuje diskutuje o osvědčených postupech správy soukromých klíčů při použití s ​​zástupnými znaky.

Nakonec se uchýlíme k argumentu autority ... pokud Google používá zástupné znaky pro některé ze svých vlastností , nesmí být všeobecně špatné:

Qualys SSL Labs screenshot for youtube.com cert

:-)

9
Royce Williams

V ideálním případě by měl být seznam služeb, pro které lze certifikát/klíč vydávat, stejný jako seznam služeb, pro které je certifikát/klíč určen.

Řekněme, že máte doménu example.com. V rámci této domény jste nastavili různá jména hostitelů www.example.com catpictures.example.com users.example.com. Všechny jsou hostovány na stejném serveru, takže získáte jeden certifikát, který je pokryje všechny.

Nyní řekněme, že jste nastavili secure.example.com na vysoce zabezpečeném serveru. Řekněme, že pro tento server získáte samostatný certifikát.

Nyní zvažte, co se stane, pokud se ukradne soukromý klíč odpovídající certifikátu na prvním serveru.

Pokud se jednalo o certifikát pro * .example.com (zástupný certifikát), mohou jej útočníci použít za zosobnění secure.example.com.

Pokud to byl certifikát pro www.example.com catpictures.example.com a users.example.com, pak jej útočníci nemohou použít k zosobnění zabezpečeného.example.com.

4
Peter Green