Tento článek byl původně publikován dne Blog uživatele Scott Helme a zde je s jeho dovolením přetištěn.
Máme na internetu malý problém a můžu vidět, že se stává to čím dál tím větší starostí: stále více stránek získává certifikáty, životně důležité dokumenty potřebné k nasazení protokolu HTTPS, ale nemůžeme se chránit, když jsme věci se pokazí.
Certifikáty
V současné době vidíme trochu zlatého ruchu pro certifikáty na webu, protože stále více webů používá HTTPS. Kromě zjevných výhod HTTPS v oblasti zabezpečení a ochrany osobních údajů existuje několik důvodů, proč byste měli zvážit přechod na zabezpečené připojení, které jsem popsal v článku Stále si myslíte, že HTTPS nepotřebujete?. Širší internet, který se běžně označuje jako „SSL certifikáty“ nebo „HTTPS certifikáty“, je získává rychlostí, jakou jsme nikdy v historii webu neviděli. Každý den procházím jeden milion nejlepších webů na webu a analyzuji různé aspekty jejich zabezpečení a každých 6 měsíců zveřejňuji zprávu. Můžete vidět zprávy zde, ale hlavní výsledek, na který se teď soustředíte, je přijetí protokolu HTTPS.
Nejen, že pokračujeme v nasazení HTTPS, ale také se zvyšuje míra, jakou to děláme. Takto vypadá skutečný pokrok. Proces získání certifikátu se postupem času a nyní díky úžasu stal stále jednodušším Zašifrujeme, je také zdarma je získat. Jednoduše řečeno, zašleme žádost o podepsání certifikátu (CSR) certifikační autoritě (CA) a CA nás vyzve, abychom prokázali naše vlastnictví domény. Obvykle se to provádí nastavením záznamu DNS TXT nebo hostováním kódu výzvy někde na náhodné cestě v naší doméně. Jakmile je tato výzva splněna, CA vydá certifikát a my jej můžeme prezentovat do prohlížečů návštěvníků a do adresního řádku dostat zelený zámek a „HTTPS“.
Mám několik výukových lekcí, které vám pomohou s tímto procesem, včetně toho, jak začít, jak nastavit inteligentní obnovu, a jak používat duální certifikáty. To je vše skvělé. Co je za problém?
Problém je, když věci nejdou podle plánu a máte špatný den.
"Byli jsme hacknuti!"
Nikdo tato slova nikdy nechce slyšet, ale smutnou realitou je, že to děláme - častěji, než by si kdokoli z nás přál. Hackeři mohou jít po libovolném počtu věcí, když získají přístup k našim serverům, a často jednou z věcí, ke které mají přístup, je náš soukromý klíč. Certifikáty, které používáme pro HTTPS, jsou veřejné dokumenty - zasíláme je každému, kdo se připojuje k našemu webu - ale to, co ostatním lidem brání používat náš certifikát, je to, že nemají náš soukromý klíč. Když prohlížeč naváže zabezpečené připojení k webu, zkontroluje, zda server má soukromý klíč pro certifikát, který se pokouší použít, a proto náš certifikát nemůže použít nikdo jiný než my. Pokud však útočník získá náš soukromý klíč, věci se změní.
Nyní, když se útočníkovi podařilo získat náš soukromý klíč, může pomocí našeho certifikátu prokázat, že jsme my. Řekněme to znovu: pokud je váš klíč odcizen, znamená to, že na internetu je někdo, kdo je né ty, kteří dokážou, že oni jsou vy. To je skutečný problém a než si myslíte, že „se mi to nikdy nestane“, měli byste si vzpomenout heartbleed. Tato malá chyba v knihovně OpenSSL umožnila útočníkům ukrást soukromé klíče a nemuseli jste dělat nic špatného, aby se to stalo. Kromě toho existuje nespočet způsobů, jak jsou soukromé klíče vystaveny nehodě nebo nedbalosti. Jednoduchá pravda je, že my umět ztrácejí naše soukromé klíče a když k tomu dojde, potřebujeme způsob, jak zabránit útočníkovi používat náš certifikát. Potřebujeme odvolat certifikát.
Odvolání
V kompromisním scénáři odvoláváme náš certifikát, aby jej útočník nemohl zneužít. Jakmile je certifikát označen jako „zrušený“, webové prohlížeče ho nebudou věřit, přestože je certifikát platný. Majitel požádal o zrušení a žádný klient by jej neměl přijmout.
Jakmile víme, že jsme měli kompromis, kontaktujeme CA a požádáme ho, aby zrušili náš certifikát. Potřebujeme prokázat vlastnictví daného certifikátu a jakmile to uděláme, CA označí certifikát jako zrušený. Nyní, když je certifikát odvolán, potřebujeme způsob, jak toto odvolání sdělit každému klientovi, který by mohl tyto informace vyžadovat. Bezprostředně po odvolání o tom prohlížeče návštěvníků o tom nevědí - a to je samozřejmě problém. K zpřístupnění těchto informací můžeme použít dva mechanismy: Seznam zneplatněných certifikátů (CRL) nebo Online Status Status Protocol (OCSP).
Seznamy zrušených certifikátů
CRL je opravdu jednoduchý koncept a je doslova jen seznam všech certifikátů, které CA označil jako zrušené. Klient může kontaktovat server CRL a stáhnout kopii seznamu. Ozbrojený s kopií seznamu může prohlížeč zkontrolovat, jestli je certifikát, který byl poskytnut, uveden v seznamu. Pokud je certifikát is v seznamu prohlížeč nyní ví, že je certifikát špatný a nemělo by být důvěryhodné. Prohlížeč by měl vyvolat chybu a ukončit připojení. Pokud certifikát není na seznamu, pak je vše v pořádku a prohlížeč může pokračovat v připojení.
Problém s seznamem CRL spočívá v tom, že obsahují mnoho zrušených certifikátů od konkrétní CA, která je udržuje. Aniž by se dostaly do přílišných podrobností, jsou rozděleny podle každého přechodného certifikátu, který má CA, a CA může rozdělit seznamy na menší kousky. Bez ohledu na to, jak se to rozdělí, bod, který chci učinit, zůstává stejný: seznam CRL obvykle není zanedbatelný. Druhým problémem je, že pokud klient nemá novou kopii seznamu CRL, musí si jednu stáhnout během počátečního připojení k vašemu webu - což může způsobit, že váš web bude vypadat mnohem pomaleji, než ve skutečnosti je.
Nezní to zvlášť skvěle - tak co kdybychom se podívali na OCSP?
Online protokol o stavu certifikátu
OCSP poskytuje mnohem hezčí řešení problému a má významnou výhodu oproti přístupu CRL. Se službou OCSP požádáme CA o stav jediného certifikátu. To znamená, že vše, co CA musí dělat, je odpovědět na dobrou / zrušenou odpověď, která je značně menší než CRL. Skvělé věci!
Je pravda, že OCSP nabízí významnou výhodu ve výkonu oproti načtení seznamu CRL, ale tato výhoda výkonu je spojena s cenou (pokud to tak nenávidíte, nenávidíte?). Náklady jsou také velmi významné: vaše soukromí.
Když přemýšlíme o tom, co je požadavek OCSP - žádost o status velmi konkrétního jediného certifikátu - můžete si začít uvědomovat, že vám unikají některé informace. Když odešlete požadavek OCSP, v zásadě se ptáte CA:
Je platný certifikát pro pornhub.com?
Takže ne úplně ideální scénář. Nyní inzerujete svou historii prohlížení nějaké třetí straně, o které jste ani nevěděli, a to vše ve jménu HTTPS - která se rozhodla poskytnout nám větší zabezpečení a soukromí. Něco ironického, co?
Těžko selhání
Ale počkejte: je tu ještě něco jiného. Mluvil jsem o odpovědích CRL a OCSP výše, o dvou mechanismech, které prohlížeč může použít ke kontrole, zda je certifikát odvolán. Vypadají takto.
Po obdržení certifikátu se prohlížeč přesune na jednu z těchto služeb a provede potřebný dotaz, aby nakonec zjistil stav certifikátu. Co když vaše CA má špatný den a infrastruktura je offline? Co když to vypadá takto?
Prohlížeč má zde pouze dvě možnosti. Může odmítnout přijmout certifikát, protože nemůže zkontrolovat stav odvolání, nebo může riskovat a přijmout certifikát bez znalosti stavu odvolání. Obě tyto možnosti mají své výhody a nevýhody. Pokud prohlížeč odmítne certifikát přijmout, pak pokaždé, když má váš CA špatný den a jeho infrastruktura přejde do režimu offline, vaše stránky se také přepnou do režimu offline. Pokud prohlížeč pokračuje a přijme certifikát, riskuje použití certifikátu, který mohl být odcizen, a vystavuje uživatele souvisejícím rizikům.
Je to tvrdé volání - ale právě teď, dnes se nic z toho neděje.