it-swarm-eu.dev

Jak proveditelné je napadení CA? Které výchozí důvěryhodné kořenové certifikáty bych měl odebrat?

Tato otázka byla od původní verze významně revidována a objasněna.

Pokud se podíváme na každý důvěryhodný certifikát v mém důvěryhodném kořenovém obchodě, jak moc bych jim měl věřit?

Jaké faktory je třeba vzít v úvahu, když hodnotím důvěru každého kořenového CA pro případné odstranění z mého místního obchodu?

Další informace:
Pokud CA vydá certifikát nesprávně ověřené straně, způsobí to, že všechny počítače, které důvěřují této CA, jsou zranitelné vůči útokům MITM. Výsledkem je, že všechny CA přísně ověřují žadatele dané žádosti o certifikát SSL, aby zajistily integritu jejich řetězce CS.

Velká část tohoto procesu ověřování CA však podléhá lidskému zásahu a poskytuje příležitosti k vydání certifikátu nesprávné straně. To může být způsobeno chybou operátora CA, vládními požadavky nebo snad donucením (úplatkem) operátora CA.

Chtěl bych se dozvědět více o tom, které výchozí CA pravděpodobně vydávají certifikáty nesprávné straně. Mám v úmyslu tyto informace použít k tomu, abych uživatelům doporučil odebrat tento CA z jejich Trusted Cert Store

Příklady:
Předpokládejme, že vláda ovládající konkrétní CA chce převzít identitu Microsoft.com a požaduje výjimku z procesu ověřování CA. Tato vláda pak také vyžaduje zachování tajemství této výjimky. Generovaný pár klíčů by pak byl použit při útoku MITM.

Výchozí důvěryhodnost systému Windows Azure

Windows Azure podporuje 275 CA, jak je uvedeno v následující odkaz . V závislosti na použití konkrétního CA mohou některé z těchto CA zvětšit povrchovou plochu konkrétního útoku. Ve skutečnosti to může být technicky vyžadováno, aby některé aplikace fungovaly správně.

Amazon Default Trust

(není k dispozici) Prosím sdílejte odkazy na výchozí seznam CA Amazon, Google a VMWare, pokud se s nimi setkáte.

Mozilla

K dispozici je seznam všech certifikátů a auditních prohlášení .

Apple iOS

Seznam všech kořenové certifikáty iPhone , jak je uvedeno v toto # WWDC2017. Video

84

Aktualizace 5 Kořenovým problémem (heh) u modelu CA je to, že v obecné praxi může kterýkoli CA vydávat certifikáty pro jakoukoli doménu, takže jste zranitelní na nejslabší článek. Pokud jde o to, komu můžete věřit, pochybuji, že seznam je vůbec dlouhý, protože sázky jsou vysoké a bezpečnost je tvrdá. Doporučuji příspěvek Christophera Soghoiana k tomuto tématu, který objasňuje různé přístupy, které vlády po celém světě používají k získání přístupu k soukromým uživatelským datům - ať už přímým požadováním od společností, které provozují cloudové služby, prostřednictvím odposlechu, nebo stále více prostřednictvím nátlaku CA or hacks: slabá paranoia: Síly, které vedly k hacknutí DigiNotar .

Zde uvádím některá specifika a končí odkazy na některé potenciální opravy.

V roce 2009 společnost Etisalat (60% vlastněná vládou Spojených arabských emirátů) představila neškodně vypadající opravu BlackBerry, která do zařízení RIM vložila spyware, což umožnilo monitorování e-mailů, takže ji lze jen stěží považovat za důvěryhodnou. Je to však v mnoha důvěryhodných seznamech CA: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Aktualizace 1 Viz také příklad úspěšného útoku, údajně íránského jménem ComodoHacker , proti Comodo: Rogue SSL certifikáty ("case comodogate") - F-Secure Weblog . F-Secure bere na vědomí, že Mozilla zahrnuje certifikáty vydané CA v Číně, Izraeli, Bermudě, Jižní Africe, Estonsku, Rumunsku, Slovensku, Španělsku, Norsku, Kolumbii, Francii, Tchaj-wanu, Velké Británii, Nizozemsku, Turecku, USA, Hongkongu, Japonsku , Maďarsko, Německo a Švýcarsko.

Tunisko je další zemí, která provozuje široce důvěryhodnou certifikační autoritu, a existuje také dobrá dokumentace opatření jejich vlády k invazi do soukromí: Vnitřní příběh o tom, jak Facebook reagoval na tuniské hacky - Alexis Madrigal - Technologie - Atlantik

Mozilla zaznamenává další sporný postup, na který si dejte pozor: CA, které umožňují partnerovi RA vydávat certs přímo z kořenového adresáře, spíše než prostřednictvím zprostředkovatele: Vydání certifikátu Comodo - pokračování na blogu Mozilla Security .
Viz také podrobnější informace, včetně spekulací o nároku na zodpovědnost osamělého íránského hackera Webové prohlížeče a Comodo zveřejňují úspěšný útok certifikační autority, snad od Íránu | Svoboda Tinker

Aktualizace 3 : Další úspěšný útok zdánlivě také ComodoHackerem byl proti DigiNotar CA. Jejich web byl od roku 2009 kompromitován, ale to nebylo zaznamenáno, dokud DigiNotar nebyl v roce 2011 v Íránu použit k podepisování falešných certifikátů pro weby Google, Yahoo !, Mozilla WordPress a Projekt Tor. DigiNotar neodhalil své znalosti o vniknutí na své stránky déle než měsíc. Více na DigiNotar Hack upozorňuje na kritická selhání našeho SSL modelu webové bezpečnosti | Svoboda Tinker .

Hádal bych, že rozsah zranitelnosti různých CA je velmi různý, stejně jako jejich užitečnost. Takže bych navrhl přeorientovat vaši strategii. Když ji můžete zúžit na konkrétní aktiva, která se pokoušíte chránit, stačí smazat všechny CA, s výjimkou těch, které jsou nezbytné pro použití těchto aktiv. V opačném případě zvažte vyloučení certifikačních autorit, které považujete za nejzranitelnější vůči těm, kteří se zajímají o vaše aktiva, nebo o nejméně populární, jen kvůli redukci povrchu útoku. Přijměte však skutečnost, že budete i nadále náchylní k sofistikovaným útokům i proti nejoblíbenějším a nejpečlivějším CA.

Aktualizace 2 : Existuje skvělý příspěvek o tom, jak opravit naši nebezpečnou infrastrukturu CA ve společnosti Freedom to Tinker: Budování lepší infrastruktury CA

Hovoří o těchto inovacích:

Aktualizace 4 Jeden z našich blogů o bezpečnosti IT v srpnu 2011 zahrnuje také případ přechodu na server DNSSEC: Pohled na opravu zaměřený na rizika problém s certifikační autoritou "Stack Exchange Security Blog

Aktualizace 6 Několik certifikačních autorit bylo chyceno v rozporu s pravidly. To zahrnuje francouzskou agenturu pro kybernetickou energii (ANSSI) a společnost Trustwave, z nichž každá byla spojená se spoofingem digitálních certifikátů .

Aktualizace 7 Ještě další sada „nesprávně vydaných certifikátů“ prostřednictvím indického kontrolóra certifikačních orgánů (Indie CCA) v roce 2014: Google Online Security Blog: Zachování zabezpečení digitálních certifikátů

Viz také otázka Transparentnost certifikát , která vypadá jako užitečný přístup k objevování špatných certifikátů a porušování zásad dříve.

64
nealmcb

Jak Matt Blaze jednou napsal, CA vás chrání před kýmkoli, od koho nejsou ochotni brát peníze. To by vám mělo říci něco o tom, kde leží pobídky CA, a o některých potenciálních rizicích v dohodě.

38
D.W.

Obávám se, že krátkou odpovědí na tuto otázku je, že je nemožné vědět, pokud to vidím. Ve většině běžných prohlížečů je instalováno velké množství výchozích certifikačních autorit a je obtížné posoudit, jak je pravděpodobné, že budou „důvěryhodné“, pokud jde o rozdávání certifikátů vládním nebo jiným organizacím.

Pokud by se CA stal nedůvěryhodným, pravděpodobně by byl odstraněn z výchozích instalačních seznamů prohlížečů (za @ xce níže je Diginotar dobrým příkladem a také Digicert)

Kromě organizace, která certifikáty poskytuje dobrovolně, existuje riziko, že mohou certifikáty poskytovat, aniž by provedly příslušné bezpečnostní kontroly na žadateli. V Defconu před pár lety bylo na toto téma několik prezentací, jak získat certifikáty bez oprávnění.

Pokud se jedná o závažný problém, jediným způsobem, o kterém si mohu vzpomenout, by bylo vytvoření bílého seznamu CA, které jste zkontrolovali a jsou pohodlné s poskytnutým zabezpečením. To by samozřejmě nefungovalo pro přístup k obecnému internetu, protože byste pravděpodobně skončili odstraněním CA, které mají problémy Certs, na weby, které chcete použít.

18
Rory McCune

2 příklady, které jdou do jádra toho, co potřebujete vědět, ale ne to, co se výslovně ptáte:

  • Před několika lety (2006 nebo možná koncem roku 2005) došlo k velmi dobře zveřejněnému incidentu s phishingem SSL - falešná webová stránka banky získala legitimní certifikát SSL (myslím, od společnosti GeoTrust) za chybné napsání stránky regionální banky. (Aktualizace: nalezeno tento historický odkaz - adresa byla místo zkráceného zkratky úplným jménem banky). Od té doby došlo k dalším případům phishingu SSL .... Je možné získat certifikát, aniž by se uchýlili k „nátlaku“.
  • Nedávná Stuxnet novela spoléhala mimo jiné na ukradené certifikáty. Tito lidé byli „půjčováni“ od výrobců ovladačů třetích stran a jelikož byli „důvěryhodní“, mohli být zneužiti, aby mohli škodlivý software zasadit.

Pak samozřejmě existují softwarové scénáře, ve kterých není CA vůbec použito - např. s silnými klienty, kteří volají webové služby, které se neobtěžují ověřováním certifikátu serveru ....

Mám na mysli, že pokud se obáváte o MITM přes SSL, častěji než ne, to by vás nemělo dělat vládní donucení. Obvykle existují jednodušší a dostupnější způsoby.
Dokonce protestuji proti tomu, že se "Důvěryhodné Certs" jmenuje "Důvěryhodné" ... Jen proto, že vím, kdo jste, neznamená to, že bych vám měl věřit ... a to neznamená, že bych měl věřit, že víte, kdo někdo jinde je.

Nemluvě o tom, že pokud z důvěryhodného obchodu odstraníte standardní kořenové ořechy, nebude fungovat mnoho webů podle očekávání.

Na druhou stranu, pokud jednáte se serverem/zařízením, které nepotřebuje obecné možnosti procházení, ale komunikuje s konkrétním serverem (nebo sada serverů), určitě odstraňte [~ # ~] všechny [~ # ~] kořenové certy, kromě whitelistu těch, které potřebujete.
A pokud půjdete s vlastním interním CA, ještě lépe ....

11
AviD

Každá certifikační autorita zveřejňuje prohlášení o praxi certifikátů, které popisuje, jak chrání své vlastní klíče, a před vydáním certifikátů ověřuje žádosti o certifikáty. Adresa URL umístění tohoto dokumentu je obvykle součástí každého certifikátu vydaného CA. Za předpokladu, že dotyčný certifikační úřad skutečně dodržuje tento dokument o zásadách, měl by vám poskytnout informace o délce, za kterou se mají ujistit o platnosti subjektu žádajícího o osvědčení. Hledejte prohlášení, že chrání své podpisové klíče CA pomocí hardwarových bezpečnostních modulů nebo kryptografických modulů, které chrání podpisovací klíče, vícefaktorovou autentizaci a autorizaci k podpisu certifikátů založenou na kvora atd. Tyto metody ochrany jsou mnohem obtížnější a dražší pro nepoctivou třetí stranu, která ukradne podpisové klíče.

Obrovský seznam důvěryhodných CA (můj Mac System Roots Keychain má 175) je tu pro vaše pohodlí, aby byl HTTPS systém použitelný pro vás a pro všechny na planetě, kteří se na tyto otázky neptají. Samozřejmě byste mohli vyhodit všechny CA z tohoto seznamu, pokud jste jejich postupy osobně auditovali. U uzavřeného systému, kde ovládáte všechny koncové body a máte omezený počet důvěryhodných stran, je to možné. Systém pro správu verzí Subversion neobsahuje žádné důvěryhodné kořenové certifikáty, ale můžete přidat svůj vlastní ke každému klientovi. Pro web jako celek je jediným možným způsobem, jak jej učinit použitelným, mít důvěryhodnou stranu mimo společnost (společnost, která dodává váš operační systém nebo prohlížeč, ať už si na ně pomyslíte), seznam důvěryhodných certifikáty, které vám umožní připojit se téměř k jakémukoli serveru s podporou SSL na světě.

Opravdu potřebujete všechny tyto certifikáty ve vašem seznamu důvěryhodných? Asi ne. Prodejce operačního systému/prohlížeče však nemůže předvídat (a neměl by ovládat), s kým chcete obchodovat, takže zahrnují všechny. Problém s velkým seznamem je v tom, že máte CA všech peří, se všemi druhy ověřovacích metod ze všech jurisdikcí, zacházeno úplně stejně. Ne každý CA jedná stejně: viděli jsme případy kompromitovaných přihlašovacích údajů distributora a dokonce i kompromitovaných klíčů CA. Některé certifikační autority vyžadují osvědčení o začlenění a slib svého prvorozeného, ​​jiné pouze ověřují, že můžete dostávat e-maily v doméně, pro kterou žádáte o osvědčení. A přesto váš prohlížeč zachází s každou CA přesně stejně.

Obrana proti nečestným certifikátům pro stejný Common Name by spočívala v mezipaměti původního certifikátu na klientovi: pokud se najednou objeví jiný certifikát od jiného CA, mělo by to být důvodem k obavám. Nevím, jak se dnešní prohlížeče zabývají tímto případem, a jsem příliš líný, abych to zjistil.

9
Sander Temme

Tento druh diskuse mi vždy připomíná tato chyba Mozilly požadující zahrnutí nového CA. Docela veselý, ale docela bystrý.

4
Steve Dispensa

Při zkoumání certifikátu, který chcete odebrat v počítači se systémem Windows, byste se nejprve měli ujistit, že neodstraňujete systémové certifikáty. Pokud se o to pokusíte, zobrazí se následující chybová zpráva

error- you're deleting a system cert!!

Toto je adresa URL se seznamem certs, které nesmí být nikdy odstraněny ze systému Windows http://support.Microsoft.com/?id=293781

Dále byste měli zvážit odebrání (testování odstranění) přechodných certifikátů, protože existují pouze " čistě ze starších důvodů ".

Při hodnocení odstraňování všech zbývajících certifikátů zvažte, že Microsoft Root Certificate Program vyžaduje, aby certifikační úřad splnil jeden z těchto standardů auditu:

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust pro CA
  • Audity připravenosti WebTrust EV
  • ISO 21188 (Poznámka: nepřijímají ISO 27001)

Pokud odstraňujete Certs z prohlížeče mimo MSFT (IE), možná budete chtít přečtěte si tyto pokyny pro kvalitu CA .

Omezení

Program má také další audity, které se týkají toho, co je klíčové použití. Použití klíče je omezeno na následující:

  • Ověření serveru (SSL) = 1.3.6.1.5.5.7.3.1

  • Ověření klienta (SSL) = 1.3.6.1.5.5.7.3.2

  • Zabezpečený e-mail (SMIME) EKU = 1.3.6.1.5.5.7.3.4

  • Podpis kódu EKU = 1.3.6.1.5.5.7.3.3

  • Časové razítko EKU = 1.3.6.1.5.5.7.3.8

  • OCSP EKU = 1.3.6.1.5.5.7.3.9

  • Systém šifrování souborů EKU = 1.3.6.1.4.1.311.10.3.4

  • IPSec (Tunnel, User) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Zakázaná klíčová použití

Program zakazuje následující klíčová použití:

  • Přihlášení pomocí karty Smart Card Toto je scénář pouze pro podniky, protože je vyžadováno nasazení služby Active Directory a kořen musí být přidán do úložiště NTAuth ve službě Active Directory. Podrobnosti naleznete v následujícím článku KB. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245

  • Digitální práva Toto EKU je zastaralé. Windows Media DRM používá svůj vlastní formát XML pro licence a nepoužívá X.509.

  • Kvalifikovaná podřízenost Tento EKU je zastaralý a Windows jej ignoruje.

  • Klíčový scénář zotavení Enterprise CA.

  • Obnova souboru Tento EKU je zastaralý a systém Windows Encrypting File System (EFS) jej ignoruje.

  • Všechny aplikační zásady Nemůžeme udělit „všechna použití“, protože to nutně připouští podnikové a jiné nepřijatelné EKU.

  • Scénář e-mailové replikace adresářové služby

  • Agent žádosti o certifikát

  • Scénář podnikové CA

  • Scénář agenta obnovení podnikového CA

  • Šifrovací certifikát CA

  • Scénář podnikové CA

Kritéria přijetí

Před přidáním obecného účelu nebo vládního CA do kořenového adresáře musí být splněna následující kritéria:

  1. Příslušný orgán musí poskytnout níže požadované informace (viz Krok 1. Kontaktujte společnost Microsoft ) a získat předběžný souhlas s členstvím v Programu.

  2. Pro účely testování musí CA poskytnout testovací certifikát vydaný z kořenového certifikátu CA. CA může společnosti Microsoft poskytnout URL URL veřejně přístupného serveru, na kterém lze ověřit certifikáty vydané z jejich kořenového certifikátu. (Viz FAQ FAQ)

  3. CA musí dokončit smlouvu Microsoft CA. Smlouva bude poskytnuta až poté, co dokončíte první krok procesu žádosti a obdržíte předběžné schválení vaší žádosti.

  4. Kořenové certifikáty musí splňovat níže uvedené technické požadavky. Zejména požadujeme minimální velikost krypto klíčů modulu RSA 2048 bitů pro všechny kořenové a všechny vydávající certifikační autority. Společnost Microsoft již nepřijme kořenové certifikáty s 1024bitovým modulem RSA po vypršení platnosti. Upřednostňujeme, aby nové kořeny byly platné nejméně 8 let od data podání, ale vyprší před rokem 2030, zejména pokud mají modul RSA 2048 bitů.

  5. Certifikáty vydané z kořenového certifikátu musí podporovat rozšíření distribučního bodu CRL. Distribuční bod CRL by měl ukazovat na veřejně přístupné místo.

  6. Certifikační úřad musí mít zdokumentovanou politiku odvolání a certifikační úřad by měl být schopen zrušit jakýkoli certifikát, který vydají.

  7. Certifikační úřad musí provést audit a výsledky auditu zaslat společnosti Microsoft každých dvanáct (12) měsíců. Audit musí zahrnovat úplnou hierarchii PKI, kterou společnost Microsoft povolí přidělením rozšířených klíčových použití (EKU). Všechna použití certifikátů, která povolujeme, musí být pravidelně auditována. Zpráva o auditu musí dokumentovat plný rozsah hierarchie PKI, včetně všech podřízených certifikačních orgánů, které vydávají určitý typ certifikátu, na který se vztahuje audit. Způsobilé audity zahrnují:

Toto jsou v současnosti akceptované audity pro nevládní úřady. Vyhrazujeme si právo v budoucnu změnit výše uvedené audity a/nebo přijmout další srovnatelné audity.

Technické požadavky

Nové kořenové certifikáty musí splňovat následující technické požadavky:

  • Kořenové certifikáty musí být certifikáty x.509 v3.

  • Název subjektu musí obsahovat smysluplný název CA (např. Nemůže být „Root“ nebo „CA1“).

  • Rozšíření základních omezení: cA = true

  • Použití klíče (pokud je k dispozici): keyCertSign a cRLSign

  • Požadavky na velikost kořenových klíčů jsou založeny na NIST SP 800-57:

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • Algoritmus hash musí být alespoň SHA1. Nebyly přijaty žádné hashovací metody MD2, MD4 nebo MD5.

  • Pro velikost kořenového klíče větší nebo rovnou modulu RSA 2048 bitů nesmí platnost kořenového certifikátu vypršet dříve než 8 let po odeslání a nejpozději do roku 2030. U větších velikostí kořenových klíčů může být poskytnuta delší doba platnosti.

  • Mezitímní certifikáty CA jsou vyloučeny z programu Root CA (Další informace viz Časté otázky)

  • CA nebude vydávat certifikáty podřízených nebo koncových entit MD2, MD4 nebo MD5 z jakéhokoli kořenového certifikátu distribuovaného programem s účinností od 15. ledna 2009.

  • Stávající („starší“) 1024bitové kořenové certifikáty RSA mohou být v programu distribuovány až do termínu NIST 31. prosince 2010, s výjimkou případů poskytnutých společností Microsoft.

  • CA může vydávat 1024bitové certifikáty RSA z kořenových certifikátů distribuovaných programem do termínu NIST 31. prosince 2010.

3

Věřím, že americká vláda se před několika lety pokusila schválit právní předpisy, které jim dávají právo donutit certifikační autoritu, aby vytvořila platný certifikát třetí strany pro odposlouchávání a co ne. Nemohl jsem o tom najít důkazy, takže si možná vzpomínám na něco v souladu s rozhovory DefCon, které Rory zmínil.

3
Steve

Předpokládejme, že některá špatná vláda chtěla vidět provoz zařízení SSL pomocí protokolu SSL. Jak je možné, aby byly výchozí certifikační autority donuceny k vydání nového certifikátu?

Predikát a otázka nesouvisí. Nezáleží na tom, jak snadno nebo často může být certifikační autorita donucena k vydání nového certifikátu - budoucí odposlouchávač nemohl vidět vaše data, pokud nemají soukromý klíč z certifikátu, který jste již nainstalovali. IIRC (ale doporučil bych to zkontrolovat) CSR nezahrnuje soukromý klíč - takže CA to tak nemůže získat. Nemohou změnit, jaké klíče používají vaše stroje.

Je však možné, že nepoctivý CA může vydat padělaný certifikát - a pak existuje potenciál pro útok MITM na váš web. Nedávné problémy s formát MD5 a Etisalat naznačují, že to není nemožné.

3
symcbean

Snažím se soustředit na druhou otázku.

Vydání "Které výchozí důvěryhodné kořenové certifikáty bych měl odebrat" " záleží v podstatě na tom, s kým se vypořádáte.

Budete muset „pouze“ důvěřovat všem CA, které podepisují kterýkoli z webů, ke kterým se připojujete.

Pro uživatele babičky typu, který vždy navštěvuje stejné stránky, bude stačit několik hrstek CA, zatímco seznam nebude tak rychle narůstat * pro těžkého uživatele internetu.

Proč ne tak rychle ? Naopak, některé CA jsou často používány (včetně těch, které jsou příliš velké na to, aby selhaly), zatímco jiné se na internetu používají jen stěží, jako některé téměř geografické.

Nástroj SSLCop z securitybydefault může pomoci blokovat ze zemí, kterým nedůvěřujete/je nepravděpodobné, že je budete potřebovat (např. Neočekáváte přístup na web od vlády Brobdingnag, která stane se hlavním uživatelem této CA): http://www.security-projects.com/?SSLCop

Pokud však nedůvěřujete příliš velkému počtu CA, nakonec nebudete schopni získat důvěru k webům, které uživatelé potřebují (a budou k nim přistupovat i přes bezpečnostní varování), což je stejně špatné.

1
Ángel

Ukázka vytvoření nepoctivého CA pomocí slabých stránek MD5:

1
Bradley Kreider

Od 12. června 2012 společnost Microsoft vydala nový aktualizátor, který zakáže nedůvěryhodné kořenové certifikáty a všechny ostatní certifikáty, které jsou společnosti Microsoft hlášeny jako nedůvěryhodné.

Aktualizace je k dispozici zde a nejsem si jistá, zda byla tato aktualizace již distribuována prostřednictvím služby Windows Update nebo zda se jedná o aktualizaci mimo pásmo.

http://support.Microsoft.com/kb/267707

0