Úvod
Když uživatel navštíví váš web HTTPS, musí reagovat funkční veřejný klíča platný certifikát SSL spojující klíč s vaší identitou, buď jako osoba, společnost nebo organizace. Certifikáty jsou vždy vydávány s předdefinovaným datem expirace, které je součástí samotného podepsaného certifikátu, a prohlížeče vždy kontrolují datum vypršení platnosti a odmítnou jakýkoli certifikát, jehož platnost vypršela.
V některých případech však musí být certifikát označen jako neplatný (a důvěra v tyto certifikáty musí být zrušeno) před vyprší. Mezi běžné příklady patří vlastník serveru, který má důkaz (nebo jen podezření), že jeho soukromý klíč byl ohrožen (tj. Byl ztracen, odcizen nebo zničen), protože třetí strana, která drží tento soukromý klíč, může v zásadě obejít všechny ovládací prvky zabezpečení sítě prohlížeče.
V důsledku toho vyžadovali prodejci prohlížečů veřejně důvěryhodné certifikační autority (CA.) implementovat alespoň jednu metodu, jak zrušit problematické certifikáty, a upozornit prohlížeče, aby odmítnuté certifikáty odmítly.
Stručná historie kontroly problémů
V prvních dnech SSL bylo použitou metodou CA zveřejnění stavu odvolání certifikátu ve veřejně přístupných dokumentech nazvaných seznamy odvolání certifikátů (C.R.L.). Seznam CRL je prostě seznam všech certifikátů, které certifikační autorita kdy zrušila před vypršením platnosti. Příslušné úřady pravidelně publikovaly nejnovější verzi svých seznamů CRL, s nimiž byly prohlížeče povinny konzultovat před každé připojení HTTPS.
Přirozeně, jako HTTPS (a SSL /TLS) přijetí se v průběhu let zvyšovalo, stejně tak se zvětšovala velikost publikovaných CRL. Požadavek na stažení a analýzu velkého seznamu CRL před každým připojením vyžadoval stále rostoucí režii sítě. Rychle vyšlo najevo, že metoda CRL neměla dobré měřítko.
Pro zmírnění těchto problémů s škálováním prohlížeče a CA vytvořily a implementovaly Online protokol o stavu certifikátu (OCSP). Veřejně důvěryhodné CA, jako např SSL.com, nyní udržujte jednoduché HTTP servery s názvem OCSP respondenti. Prohlížeče nyní mohou kontaktovat respondenta a požádat o zrušení stavu jediného certifikátu vydaného CA, namísto toho, aby museli získat a zpracovat celý seznam CRL.
Respondenti OCSP podepisují své odpovědi soukromým podpisovým klíčem CA a prohlížeče mohou ověřit, že stav odvolání, který obdrželi, byl skutečně vygenerován skutečným CA.
Bohužel, ačkoli se OCSP zpočátku zdálo jako efektivní řešení, nový protokol prokázal určité praktické problémy s výkonem, zabezpečením a ochranou soukromí.
Problémy s výkonem
Kontaktování respondenta pro každý certifikát, se kterým prohlížeč narazí, znamená, že prohlížeče musí pro každý nový HTTPS připojení provést další požadavek HTTP. Tato režie v síti byla pro uživatele znatelná, zejména na stránkách obsahujících obsah třetích stran uložený na vzdálených serverech pro distribuci obsahu (na nichž každý může mít jeden nebo více certifikátů).
Citlivost je základní princip dobrého návrhu uživatelského rozhraní. Dlouhá zpoždění mohou být hlavní příčinou frustrace uživatelů a mohou vést uživatele k přesvědčení, že váš web nefunguje nebo že jejich vstupní gesto bylo ignorováno.
A co víc, mnoho studie v minulosti spojily rychlou rychlost načítání a odezvu stránek se zlepšeným SEO a zvýšeným konverzním poměrem. Ve skutečnosti Amazon spočítal, že zpoždění v délce jedné sekundy je může stát $1.6 miliarda roční.
(Více podrobností o tom, jak rychlost načítání stránky ovlivňuje váš web a navrhovaných optimalizacích, najdete na naší stránce článek popisující, jak odstranění smíšeného obsahu z vašeho webu zlepší jeho výkon.)
Bezpečnostní otázky
Existují také důležité bezpečnostní obavy týkající se OCSP. Skutečnost, že většina praktických implementací OCSP nebyla dostatečně spolehlivá (buď kvůli zpoždění v síti nebo kvůli chybám konfigurace nebo aplikace), motivovala prohlížeče a další klientský software k implementaci kontroly OCSP v měkké selhání mode.
To znamená, že pokud server OCSP nemůže být dosažen nebo vyprší časový limit při odpovědi, prohlížeče ano považujte certifikát za platný a pokračovat s připojením HTTPS.
Důvodem je to, že protože server OCSP může potenciálně obsluhovat miliony webových stránek a je možné, že server OCSP v kterémkoli okamžiku selže, přerušení připojení při každé poruše protokolu OCSP by narušilo zážitek z prohlížení milionů uživatelů. I když je server OCSP v provozu, ale jeho odpověď trvá dlouho, zvyšuje se to vnímané zpoždění a frustrace uživatelů.
Muž ve středu (MITM) bylo známo, že útočníci zneužívají toto chování blokováním všechno připojení k respondérům OCSP, což ve skutečnosti znamená, že mohou použít ukradený certifikát a pár klíčů pro škodlivý web bez ohledu na stav odvolání certifikátu.
Problémy se soukromím
Nakonec, protože certifikát je propojen s klíčem a názvem domény a prohlížeče požadují stav odvolání před každým novým připojením HTTPS, znamená to, že v prohlížečích uniká významná část webové historie jejich uživatelů respondentům OCSP.
Veřejně důvěryhodné certifikační autority samozřejmě nejsou škodlivými organizacemi, které se snaží narušit soukromí uživatelů. (Renomované certifikační autority se vždy aktivně snaží chránit zabezpečení a soukromí jejich uživatelů.) V případě ohrožení respondenta OCSP CA by však data vyměněná s tímto nedůvěryhodným serverem mohla vést ke zveřejnění citlivých a soukromých informací.
OCSP Sešívání na záchranu
Pro zmírnění těchto problémů přišly prohlížeče a CA s novou metodou určování stavu certifikátu, tzv Sešívání OCSP. Sešívání OCSP umožňuje webovým serverům (namísto prohlížečů) získat podepsané odpovědi OCSP pro jejich certifikáty, které lze ukládat do mezipaměti až na 7 dní.
Servery zahrnují (nebo sešít) odpověď OCSP v mezipaměti ve svých odpovědích HTTPS spolu se samotným certifikátem SSL. Prohlížeče tak mohou ověřovat podpis certifikačních autorit v odpovědi OCSP a být zajištěny, že certifikát nebyl odvolán, a to před navázáním zabezpečeného připojení a bez nutnosti provádět drahý dodatečný požadavek na samotný server OCSP.
Sešívání OCSP je jednoduché, ale velmi efektivní řešení výše uvedených problémů. Servery mohou načíst odpovědi OCSP v mezipaměti ve svém vlastním čase, což odstraňuje režijní náklady uložené CRL a OCSP, jakož i související obavy o ochranu soukromí.
Samotné sešívání OCSP však zcela nevyřeší problém zabezpečení soft-fail OCSP. Vzhledem k tomu, že sešívání je na serveru implementováno, prohlížeče nemohou vědět, zda server skutečně sešívání podporuje nebo ne.
V důsledku toho mohou útočníci MITM s odcizeným (ale zrušeným) certifikátem provést útok na downgrade poskytnutím certifikátu bez sešívání OCSP. Prohlížeč oběti není schopen potvrdit, zda server skutečně podporuje sešívání, a pokračovat v dotazu na respondér OCSP jako obvykle.
Útočníci MITM pak mohou jednoduše zablokovat tento dotaz OCSP a efektivně přinutit prohlížeče, aby certifikát akceptovali jako platný.
OCSP Musí sešívat
Tento útok motivoval certifikační autority a dodavatele prohlížečů k zavedení rozšíření pro certifikáty SSL definované v RFC 7633, běžně nazývané OCSP Musí se sešívat (ačkoli RFC sám tento název nezmiňuje, což může způsobit určité nejasnosti.) Toto jednoduše nařizuje OCSP sešívání certifikátu. Pokud prohlížeč narazí na certifikát s touto příponou, který se používá bez sešívání OCSP, bude odmítnut. OCSP Must-Staple zmírňuje výše zmíněný útok na downgrade a také snižuje zbytečný provoz na OCSP respondéry CA, což může také pomoci zlepšit celkový výkon OCSP.
Pokud máte zájem o povolení rozšíření OCSP Must-Staple ve svých certifikátech, kontaktujte některého z našich agentů podpory na support@ssl.com pro více informací.
Povolte na serveru sešívání OCSP
Abychom vám ušetřili potíže s vyhledáváním, obsahují následující části pokyny, jak povolit sešívání OCSP ve vašem počítači Apache a Nginx prostředí:
Apache
Chcete-li povolit sešívání OCSP ve vašem Apache přidejte následující řádky do konfiguračního souboru serveru.
# OCSP Sešívání, pouze v httpd 2.3.3 a novějším SSLUseStapling na SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderOrrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
Nginx
Chcete-li povolit sešívání OCSP ve vašem Nginx přidejte následující text do konfiguračního souboru serveru.
# OCSP Stapling --- # načtení záznamů OCSP z URL v ssl_certificate a jejich uložení do mezipaměti ssl_stapling; ssl_stapling_verify on;
Proč investovat do čističky vzduchu?
Web je složitá síť vzájemně závislých komponent, všechny (obvykle) pracují v souladu a poskytují plynulé prohlížení. Stále se zvyšující složitost tohoto systému však vytváří stále se rozšiřující povrch útoku a umožňuje vymýšlet a provádět nové síťové útoky.
Pouhý počet komponent přirozeně zvyšuje latenci a způsobuje zpoždění, což znamená, že podniky musí najít způsoby, jak zlepšit zabezpečení, aniž by to ovlivnilo uživatelský dojem. Aktivace sešívání OCSP vám poskytne vzácnou příležitost ke zlepšení zabezpečení a výkon vašeho webu současně.
Jako vždy vám rádi zodpovíme vaše dotazy týkající se sešívání OCSP nebo jiných problémů - stačí nám napište e-mailem na support@ssl.com.
