Tento článek je částí 3 ze tří v mé sérii o šifrování SSL/TLS. Část 1 pokrývá základy dobře známých konceptů šifrování. Část 2 poskytuje stručný úvod do OpenSSL a PKI. Tato část se zabývá problematikou slabosti PKI a představuje dvě protiopatření.
Nejprve bych rád představil termín spoléhající se strana . Spoléhající se strana je webový prohlížeč, e-mailový klient, chatovací aplikace atd., která se pokouší ověřit x.509 certifikát. Spoléhající se strana toho většinou dosáhne tím, že zkontroluje, zda certifikát podepsala certifikační autorita v jejích důvěryhodných kotvách.
[ Také by se vám mohlo líbit: Jak spravovat více párů klíčů SSH ]
Exkurze:Chraňte svůj soukromý klíč
Jak možná víte z části 1, soukromý klíč je ten, který musíte chránit. To začíná vytvořením, které by mělo probíhat na důvěryhodném počítači.
Nyní se můžete zeptat:„Co je to důvěryhodný stroj?“
No, online služba provozovaná někým, koho neznáte, rozhodně není důvěryhodná. Nikdy nesmíte vytvořit svůj soukromý klíč pomocí nějaké webové služby ve vašem prohlížeči, protože jednoduše nevíte, zda poskytovatel služby uchovává kopii vytvořeného klíče. Abyste tomu zabránili, můžete místo toho použít offline počítač.
Uchovávejte svůj soukromý klíč pouze tam, kde ho potřebujete, a uchovávejte jej v bezpečí. Adresář na nějakém anonymním FTP serveru rozhodně není bezpečné místo. Sdílení v síti, kam mají přístup pouze privilegovaní uživatelé, nebo správce hesel, který umožňuje ukládat přílohy, je určitě lepší místo.
V případě, že jste nechráněný soukromý klíč omylem zkopírovali do nějaké sdílené síťové složky nebo veřejného úložiště Git, stačí jej zahodit a vytvořit nový. Nemůžete si být jisti, že nebyl kompromitován. I když jej okamžitě smažete, nemůžete si být jisti, že jej nějaký mechanismus snímku již neuložil.
Slabé stránky PKI
Co je to PKI a jak funguje, bylo probráno v části 2 této série. V případě, že nevíte, přečtěte si nejprve tuto část.
Stručně řečeno, celý důvod, proč se zabýváme tímto nepořádkem s certifikáty, je ten, že chceme spoléhající se straně pomoci zajistit, aby komunikovala se správným serverem a ne nějaký podvod. Takže dostaneme certifikát podepsaný nějakou CA, které spoléhající strana důvěřuje, a jsme všichni šťastní, že?
No, mohli bychom být, kdyby v PKI nebyla vážná konstrukční chyba.
Existuje několik stovek CA, které mají důvěru naší spoléhající strany na internetu. Některé z těchto CA mají dokonce Sub CA schopné podepisovat certifikáty a mající důvěru spoléhající se strany. A všechny tyto CA mohou vydat certifikát pro jakýkoli platný název domény.
Obecně tedy platí, že certifikát pro vaši doménu by mohla vydat jakákoliv CA a vy byste o tom ani nevěděli. Tento certifikát by mohl být použit pro útoky typu man-in-the-middle na vaši doménu, protože spoléhající strana by tomuto certifikátu důvěřovala, protože byl podepsán důvěryhodnou CA.
A to není teoretická hrozba. V březnu 2015 se některé neautorizované certifikáty vydané CNNIC používaly k dešifrování provozu procházejícího přes Great Firewall. V roce 2012 bezpečnostní společnost přiznala, že vydala alespoň jeden certifikát soukromé společnosti, která jej používala ke špehování svých zaměstnanců. A v roce 2011 jedna certifikační autorita zažila zničující hack, kdy byly ukradeny některé jejich podpisové certifikáty.
Možná protiopatření
Tři výše uvedené příklady vám ukazují, co je na PKI v jeho jádru špatného. Design je vadný. Jak to tedy opravit? Následují dvě techniky, které by mohly pomoci tento problém zmírnit.
Povolení certifikační autority (CAA)
Z abstraktu záznamu o prostředku autorizace certifikační autority (CAA) DNS v RFC 8659:„Záznam prostředku DNS autorizace certifikační autority (CAA) umožňuje držiteli názvu domény DNS určit jednu nebo více certifikačních autorit (CA) oprávněných vydávat certifikáty pro daný účel. název domény. Záznamy prostředků CAA umožňují veřejné certifikační autoritě implementovat další kontroly ke snížení rizika neúmyslného chybného vydání certifikátu."
No, lépe bych to nevysvětlil. CAA umožňuje držitelům doménových jmen určit, které CA mohou vydávat certifikáty pro naši doménu, a samotné CA nám slibují, že budeme respektovat naše záznamy CAA. RFC 8659 definuje následující tři vlastnosti:
- vydání obsahuje jako hodnotu doménu CA, která je podle záznamu CAA oprávněna vydávat certifikáty pro určitou doménu.
- issuewild je v podstatě stejný jako issue, ale pro certifikáty se zástupnými znaky. Pokud není nastaveno žádné issuewild, použije se místo toho hodnota z issue.
- iodef obsahuje kontaktní informace, které se mají použít v případě jakýchkoli problémů týkajících se zásad CAA.
Podívejme se na následující příklady záznamů:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" První řádek z výše uvedeného příkladu znamená, že pouze CA Let's Encrypt bude moci vydávat certifikáty pro libovolného hostitele v doméně example.com. Jakákoli jiná CA NESMÍ vydávat certifikáty pro tuto doménu. Na druhém řádku je uvedena e-mailová adresa, na kterou se můžete obrátit v případě jakýchkoli problémů.
Vzhledem k tomu, že DNS je hierarchicky organizován, platí výše uvedený záznam CAA pro web.example.com i pro hostitele.web.example.com a host.sub.web.example.com. Podívejme se na další příklad:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" Zde může pouze CA example-pki.org vydávat certifikáty pro např. host.sub.web.example.com. Záznam ve třetím řádku přepíše zásadu z example.com. Myslím, že máte nápad.
Záznamy prostředků CAA by samozřejmě nezabránily nevyhovujícím CA ve vydávání certifikátů pro domény, pro které nemají oprávnění. Ale riskovali by, že budou odstraněni z vestavěných ukotvení důvěry, což by ve většině případů znamenalo ukončení podnikání.
A stále existuje možnost, že autorizovaná CA může chybně vydat certifikát někomu, kdo není oprávněn jej používat. Vyberte si CA, které důvěřujete, a vybírejte moudře.
Jak vidíte, CAA nepřináší 100% zabezpečení, ale je snadné jej implementovat a snižuje riziko chybného vydání certifikátu.
Certificate Transparency (CT)
Certificate Transparency je „...experimentální protokol pro veřejné protokolování existence certifikátů Transport Layer Security (TLS) tak, jak jsou vydávány nebo dodržovány, způsobem, který umožňuje komukoli auditovat činnost certifikační autority (CA) a všimnout si vydání podezřelých. certifikáty a také k auditu samotných protokolů certifikátů. Záměrem je, že nakonec by klienti odmítli respektovat certifikáty, které se v protokolu neobjevují, což by ve skutečnosti nutilo certifikační autority, aby do protokolů přidaly všechny vydané certifikáty." (Abstrakt RFC 6962)
CT nabízí formu účtování certifikátů TLS a umožňuje vám prozkoumat, které certifikáty vydané CA pro vaše doménová jména. Chcete-li tak učinit, můžete použít služby jako Cert Spotter od sslmate, které jsou k dispozici také jako místní verze. Kdysi jsem spouštěl místní verzi na svém virtuálním soukromém serveru, ale kvůli nárůstu protokolů za poslední dva roky se zdá nemožné procházet protokoly od začátku do konce. Práce běžela týdny a neskončila; bylo přerušeno, když jsem potřeboval restartovat hostitele, abych dokončil aktualizace.
Dnes není žádná CA nucena přidávat vydané certifikáty do protokolů CT, ale nárůst protokolů naznačuje, že mnoho z nich již své certifikáty přidává. Podle mého názoru je jen otázkou času, kdy velké prohlížeče začnou důvěřovat pouze certifikátům se záznamem protokolu CT a učiní je povinnými.
[ Získejte tuto bezplatnou e-knihu:Správa clusterů Kubernetes pro figuríny. ]
Koneckonců
Původní design PKI je chybný a již není příliš důvěryhodný. S RFC 8659 a RFC 6962 se nabízejí dvě metody, jak znovu získat důvěru a pomoci držitelům doménových jmen sledovat, kdo vydal certifikáty pro jejich domény.
Takže od nynějška mějte na paměti, že budete chránit své soukromé klíče, nastavte záznamy prostředků CAA pro své domény a začněte sledovat protokoly CT.