Certifikační autorita Let's Encrypt měla být revolucí v bezpečnosti na internetu. Jejím cílem bylo zpřístupnit snadné šifrování pro všechny a udělat to bezpečněji, než je stávající praxe. Zatímco první cíl se zajisté splnit povedlo, z druhého vidíme po čase spíše ústupky směrem ke snazší použitelnosti za cenu nižší bezpečnosti.
Domain Control Validation – validace, která moc nevaliduje
Z reakcí na předchozí články a přednášky o Let's Encrypt pozoruji, že spousta lidí až do příchodu Let's Encrypt měla jen velmi zkreslenou představu o tom, jak málo stačí k vydání důvěryhodného certifikátu pro webový (i jiný) server. Zřejmě i na základě samotného pojmu často mylně usuzují, že k jeho získání je potřeba nějaká certifikace. Když se pak dozví, že stačí vystavit správný soubor na webovém serveru, často neskrývají zděšení.
Tato nejnižší forma validace je přitom k dispozici již mnoho let a podporuje ji naprostá většina veřejných certifikačních autorit. O žádnou certifikaci ve smyslu ověření totožnosti držitele ale nejde. Autorita jen potvrdí, že v nějaké době před vystavením certifikátu ovládal doménové jméno ten, kdo o certifikát požádal. Pokud od té doby doména změnila majitele, nebo byla IP adresa přidělena jinému zákazníkovi, nebo někdo po cestě odklonil provoz, může se snadno stát, že certifikát ve skutečnosti nepatří držiteli doménového jména, ale někomu jinému. Jinými slovy, ani ten základní a jediný účel, pro který certifikáty existují, tedy prokázání identity komunikujících stran, DV certifikát řádně nesplňuje.
Nízké důvěryhodnosti si samozřejmě jsou vědomi i lidé ze Let's Encrypt, na druhou stranu je to jediný způsob validace, který je možné plně automatizovat. Proto přišli s vlastními nápady, jak validaci držitele domény co nejvíce zabezpečit proti případnému zneužití.
Ochrana před náhodným vystavením autentizační výzvy
Jedním z nejběžnějších způsobů validace držení doménového jména je vystavení určitého souboru na webserveru, který běží na daném doménovém jméně. Funguje takto:
- klient požádá autoritu o vystavení certifikátu
- autorita požádá klienta, aby vystavil konkrétní soubor na konkrétní cestě
- klient vystaví soubor a požádá o validaci
- autorita soubor zkontroluje a vystaví certifikát
Jedním z problémů, ke kterému zde může dojít, je vystavení autentizační výzvy někým jiným, než držitelem příslušného doménového jména. Jde-li o webový server, na který nahrávají data v nějaké formě uživatelé (např. diskuzní fórum, cloudové uložiště a pod.), může nepříjemnou shodou okolností dojít k tomu, že se autentizační soubor podaří uložit některému z uživatelů.
Původní implementace Let's Encrypt proti tomuto bojovala nejen speciální cestou /.well-known/acme-challenge/, ale i požadavkem na vystavení ověřovacího souboru se speciálním MIME typem application/jose+json. Vzhledem k tomu, že validační soubor nemá žádnou příponu, bylo nutné tohoto docílit zásahem do konfigurace webserveru, což sloužilo jako dostatečný důkaz toho, že soubor skutečně vystavuje administrátor webserveru a nikoli náhodný uživatel webové služby.
Tento požadavek byl z ostré verze Let's Encrypt odstraněn ještě před spuštěním beta programu. Podle všeho bylo takový požadavek příliš složité splnit na IIS. Má se za to, že ochrana umístěním ověřovacích souborů do podadresáře .well-known plní účel dostatečně.
Ochrana před manipulací s DNS
Specifikace protokolu ACME v tomto ohledu požadovala a stále požaduje, aby autorita prováděla validaci DNSSEC dat. To skutečně také dělá, jak jsem se přesvědčil při pokusu ověřit doménové jméno se záměrně rozbitým DNSSEC podpisem:
Verifying:www.rhybar.cz
www.rhybar.cz:Verify error:DNS problem: SERVFAIL looking up A for www.rhybar.cz Ovšem, i tady je prostor ke zlepšení. Když jsem stejným způsobem požádal o vystavení certifikátu pro doménové jméno se záměrně rozbitým DNSSEC podpisem používajícím ECDSA algoritmus, certifikát jsem dostal. Jedná se zřejmě o zastaralý software DNSSEC validátoru, který ECDSA algoritmům dosud nerozumí. Problém jsem nahlásil bezpečnostnímu týmu ISRG, přislíbili, že se jím budou zabývat.
Ochrana před únosem adres
Další riziko, kterému DV validace čelí, je únos IP provozu na cestě mezi autoritou a serverem domény, která žádá o certifikát. K řešení tohoto problému se vyjadřoval Peter Eckersley na loňském DebConfu. Přislíbil dva základní prostředky snížení rizika.
Prvním má být ověřování validačních výzev z více pozorovacích bodů. Jsou-li body dostatečně síťově vzdálené, je pro případného útočníka obtížnější unést provoz mezi autoritou a klientem – útočník pak musí být buď na společné části cesty, nebo musí ovládat všechny cesty k danému klientovi. Na stejném principu ostatně funguje třeba známé rozšíření Firefoxu Perspectives, které pomocí skupiny notářských serverů po celém světě ověřuje, zda vidí všichni stejný certifikát.
Jaká je realita ostrého Let's Encrypt? Podle logu webserveru byly všechny mé validační výzvy kontrolovány pouze jednou a to z IP adresy 66.133.109.36 (doménové jméno outbound1.letsencrypt.org). Pohled na traceroute ukazuje, že kritická cesta, na které se kdekoli může vyskytovat útočník, je opravdu velmi dlouhá:
traceroute to 66.133.109.36 (66.133.109.36), 30 hops max, 60 byte packets
1 cat58-gw.cesnet.cz (195.113.134.129) 0.482 ms 0.521 ms 0.606 ms
2 195.113.179.141 (195.113.179.141) 1.931 ms 1.939 ms 1.939 ms
3 195.113.235.109 (195.113.235.109) 5.309 ms 5.337 ms 5.318 ms
4 prag-b3-pos4-0.telia.net (213.248.77.117) 1.993 ms 2.290 ms 2.247 ms
5 win-bb2-link.telia.net (62.115.117.100) 7.643 ms 7.782 ms 7.782 ms
6 ffm-bb2-link.telia.net (62.115.113.108) 20.126 ms 18.862 ms 18.852 ms
7 ash-bb4-link.telia.net (80.91.246.62) 115.515 ms prs-bb2-link.telia.net (62.115.143.81) 31.927 ms hbg-bb4-link.telia.net (62.115.112.47) 26.704 ms
8 ash-b1-link.telia.net (62.115.115.154) 118.382 ms ash-b1-link.telia.net (62.115.113.213) 116.098 ms ash-bb4-link.telia.net (80.91.251.247) 110.192 ms
9 206.111.0.225.ptr.us.xo.net (206.111.0.225) 116.656 ms 117.380 ms 117.374 ms
10 206.111.0.225.ptr.us.xo.net (206.111.0.225) 111.686 ms 111.445 ms 116.614 ms
11 207.88.14.162.ptr.us.xo.net (207.88.14.162) 178.180 ms 171.673 ms vb6.rar3.chicago-il.us.xo.net (207.88.12.33) 173.453 ms
12 te-4-1-0.rar3.denver-co.us.xo.net (207.88.12.22) 169.670 ms 173.880 ms vb6.rar3.chicago-il.us.xo.net (207.88.12.33) 185.601 ms
13 ae0d0.mcr1.saltlake-ut.us.xo.net (216.156.0.2) 169.649 ms 169.179 ms 169.169 ms
14 ip65-46-61-22.z61-46-65.customer.algx.net (65.46.61.22) 173.020 ms ae0d0.mcr1.saltlake-ut.us.xo.net (216.156.0.2) 164.528 ms ip65-46-61-22.z61-46-65.customer.algx.net (65.46.61.22) 172.705 ms
15 ip65-46-61-22.z61-46-65.customer.algx.net (65.46.61.22) 183.939 ms teng-04-02.crrt02.slc07.viawest.net (66.51.2.169) 174.316 ms 174.453 ms
16 66.133.111.222 (66.133.111.222) 250.284 ms teng-04-02.crrt02.slc07.viawest.net (66.51.2.169) 169.295 ms 66.133.111.222 (66.133.111.222) 228.521 ms
17 66.133.111.222 (66.133.111.222) 228.496 ms outbound1.letsencrypt.org (66.133.109.36) 172.651 ms 66.133.111.222 (66.133.111.222) 342.482 ms 
Vizualiace cesty k autoritě Let's Encrypt pomocí systému RIPE Atlas.
Nerealizovaný důkaz držení předchozího klíče
Druhá pojistka proti zneužití DV validace měla být zároveň bezpečnostní killer feature projektu Let's Encrypt. Myšlenka byla taková, že žádá-li kdokoli o vydání certifikátu na doménové jméno, pro které již existuje vydaný a platný certifikát některé veřejné certifikační autority (tato skutečnost se dá dohledat například v databázi SSL Observatory, nebo Certificate Transparency), je třeba pro úspěšné ověření provést také důkaz držení privátního klíče k původnímu certifikátu. Takový důkaz může proběhnout například tak, že se privátní klíč použije k podpisu autoritou předepsané zprávy.
Tímto způsobem by bylo možné elegantně eliminovat zneužití autority odkloněním provozu, neboť samotný fakt disponování doménovým jménem by v tomto případě nestačil. Bohužel, ani tento bezpečnostní mechanizmus nebyl implementován a pravděpodobně tomu tak ani v dohledné době nebude. Tiket k dané funkci byl těsně před koncem beta období uzavřen. Osobně se domnívám, že k jeho realizaci nedojde také proto, že spoustu klientů a řešení, které už Let's Encrypt rutinně používají, by bylo nutné zásadním způsobem změnit.
Transparentnost s trhlinami
Další oblast, ve které se autorita Let's Encrypt měla odlišovat od konkurence, byla naprostá transparentnost procesu. V praxi to mělo být zajištěno:
- sekvenčním číslováním sériových číslel certifikátů
- posíláním všech certifikátů do veřejných logů Certificate Transparency
- zveřejňováním záznamů ACME komunikace
- veřejným blacklistem doménových jmen
Ze všech těchto bodů zůstalo v platnosti pouze posílání certifikátu do Certificate Transparency. Sekvenční číslování bylo zrušeno ještě před veřejnou betou s odůvodněním, že výrazným způsobem komplikuje kód autority boulder a přitom jen nedokonale provádí totéž co Certificate Transparency.
Zveřejnění ACME logů by mohlo představovat dobrý důkazní materiál pro vyšetřování případného zneužití. Bylo by možné prozkoumat, jakým způsobem validace proběhla, jakou IP adresu server měl v době validace a další důležité podrobnosti. Podle vyjádření z listopadu 2015 je funkce stále plánována, avšak nebyl čas ji zprovoznit do zahájení beta programu. S odstupem času můžeme říct, že se to bohužel nepovedlo ani do ukončení beta programu.
A konečně, Let's Encrypt používá, ve shodě s jinými autoritami, blacklist speciálních a/nebo hodnotných doménových jmen, pro která certifikát za žádných okolností nevydává. V průběhu vývoje byl tento seznam součástí otevřených zdrojových kódů autority. Od té doby však došlo k refaktoringu, kdy byl blacklist přesunut nejprve do databáze a později do samostatných datových souborů. Tyto však již nejsou hostovány na GitHubu, takže není možné snadno zkontrolovat, která doména na blacklistu je a která ne.
Rate-limiting stále v akci
Koncem března byly drobně uvolněny rate limity. Nyní je možné v rámci jednoho doménového jména vystavit:
- 20 různých certifikátů týdně
- 5 certifikátů s totožnou sadou jmen týdně
- neomezené množství obnovených certifikátů (se stejnou sadou jmen, jako již vydaný certifikát)
I když se limity zdají být velkorysé, jsou pro některé účely hluboce nedostačující. Příkladem mohou být nejrůznější bezplatné DNS hostingy, kde pod jedním doménovým jménem existují tisíce samostaných uživatelů, kteří by rádi měli každý svůj certifikát. Stejný problém trápí také třeba velké univerzity, které mají pod společným doménovým jménem mnoho fakult a také třeba kolejní sítě.
Předčasně ukončená beta
Autoritě Let's Encrypt se toho povedlo opravdu hodně, o tom není pochyb. Více než půl druhého milionu platných certifikátů během půlročního provozu svědčí o tom, že projekt má smysl a zájem o podobně fungující autoritu je. Bohužel, z plánovaných bezpečnostních vlastností, které měly DV certifikáty od Let's Encrypt odlišovat od obyčejných DV certifikátů ostatních autorit postupně sešlo. Teď, když už autorita ztratila označení beta, se nedá očekávat, že by byly v dohledné době doplněny.
Pozitivní však je, že nástup Let's Encrypt rozhýbal trh komerčních certifikačních autorit. Známá autorita StartSSL například převlékla svůj web do trošku modernějšího kabátu a uvolnila limit počtu doménových jmen v bezplatném certifikátu. Symantec zase oznámil program Encryption Everywhere, který je v zásadě klonem Let's Encrypt, ale zaměřeným na provozovatele webhostingů místo na koncové uživatele. Obchod The SSL Store zase vysvětluje, jaká má Let's Encrypt omezení a proč se tedy v určitých případech stále vyplatí zakoupit si certifikát od nich.
Tradiční certifikační autority své místo na trhu nepochybně mají, ale jejich místo je především v provádění řádné validace, tak aby vystavené certifikáty zaručovaly aspoň nějakou úroveň jistoty, že patří, komu patřit mají. DV certifikát je sice mnohonásobně lepší než nešifrovaný přístup, rozhodně se ale nehodí pro službu, která jakýmkoli způsobem zpracovává například osobní nebo platební údaje uživatelů.
ČLÁNKY DO MAILU