Služba Let's Encrypt včera zablokovala validační metodu tls-sni-01. Podle věrohodného hlášení byla tato služba zneužitelná pro vystavení certifikátu neoprávněnou osobou. Dnes Josh Aas zveřejnil detaily zranitelnosti. Na problém upozornil Frans Rosén ze společnosti Detectify.
Jak funguje tls-sni-01
Validační metoda tls-sni-01
je vynálezem tvůrců projektu autority Let's Encrypt. Spočívá ve vystavení self-signed certifikátu na neexistující doménové jméno (například 773c7d.13445a.acme.invalid
), které obsahuje ověřovací kód. Certifikační autorita při ověřování naváže s daným doménovým jménem TLS spojení a do hlavičky SNI vloží toto speciální jméno. K úspěšnému ověření dojde, pokud server odpoví certifikátem vystaveným na dané speciální jméno.
Validační metodu tls-sni-01
používá především oficiální klient Certbot. Je výhodná pro automatizaci, protože vyžaduje minimální konfigurační zásahy do webserveru. Není ale jediná, Let's Encrypt podporuje také validaci http-01
spočívající ve vystavení souboru s určitým obsahem na určité cestě a dns-01
, kde k ověření dochází umístněním TXT záznamu na doméně _acme-challenge.<validované DNS jméno>
.
Zranitelnost sdílených hostingů
Podle zjištění Franse Roséna existují provozovatelé sdílených webhostingů, pro které ověření metodou tls-sni-01
umožňuje získat cizí certifikát:
- webhostingy různých zákazníků sdílí stejnou IP adresu
- uživatelům je povoleno nastavit doménové jméno webhostingu a nahrát vlastní TLS certifikát bez kontroly, zda je
vydán nadoménové jméno držené daným uživatelem
Kombinace těchto dvou okolností pak umožňuje získat TLS certifikát na libovolné doménové jméno hostované na stejné IP adrese. Mějme například dvojici webových prezentací, jednu na doméně legit.example
, druhou na doméně badguy.example
. První patří oběti, druhá útočníkovi, obě sdílí IP adresu. Útočník jednoduše požádá autoritu o certifikát na jméno legit.example
a na výzvu autority vyrobí self-signed certifikát na autoritou požadované jméno, který nahraje jako certifikát pro jím ovládaný hosting badguy.example
, který přejmenuje na požadované ověřovací jméno. Autorita se připojí na IP adresu oběti, která je shodná s IP adresou útočníka a požádá o speciální certifikát. Webserver ochotně vybere certifikát poskytnutý útočníkem, byť patří zcela jinému zákazníkovi.
Zranitelnost tedy postihuje výlučně sdílené hostingy, pro které jsou splněny výše uvedené podmínky. Přitom už nezáleží na žádných dalších okolnostech. Zranitelnost stejným způsobem funguje i pro inovovanou variantu ověření tls-sni-02
, která je součástí nového standardu protokolu ACME.
Reakce Let's Encrypt
V krátké době po zjištění incidentu byla validace metodou tls-sni-01
vypnuta. I přesto, že nejde o nejoblíbenější metodu validace (tou je http-01
), má své uživatele a velká část z nich nemůže zcela automaticky přejít na jiný druh validace. V plánu proto je validaci opět zprovoznit v momentě, kdy bude problém nějakým způsobem vyřešen nebo obejit.
Lidé z ISRG, organizace stojící za projektem Let's Encrypt, se domnívají, že problém je možné zmírnit implementací silnějších kontrol na straně provozovatale webhostingu, tak aby si zákazník nemohl nahrát libovolný certifikát. Postižení provozovatelé jsou v kontaktu s ISRG a takové opravy by měly být brzy dostupné.
Během následujících 48 hodin chce ISRG vytvořit seznam postižených webhostingů. Jakmile bude hotový, měla by být validace tls-sni-01
znovu zprovozněna, s tím, že pro IP adresy na seznamu bude zablokována.
Dalším krokem je pak vyvolání diskuze o budoucnosti validační metody v rámci komunity kolem Let's Encrypt a protokolu ACME. Je možné, že po zvážení všech pro a proti bude takováto validace prohlášena za zastaralou a její používání bude postupně utlumováno.
Správně implementovaní klienti jsou v bezpečí
Let's Encrypt má teď zhruba 30 dnů na to, aby na vzniklou situaci zareagoval. Podle doporučení provozovatelů by totiž každý uživatel měl obnovovat certifikáty 30 dnů před expirací. Ne všechny implementace ACME klientů se tak ale chovají, navíc některé mylně předpokládají, že proces vydání certifikátu vždycky skončí úspěchem. Typickým příkladem, jak by se to nemělo dělat, je postup:
$ acme-client --vydej example.com > example.com.crt ; httpd restart
V takovém případě při jakémkoli selhání klienta je soubor s certifikátem vyprázdněn, což webserveru znemožní nastartovat. Další častou chybou je nepříliš časté spouštění ACME klienta cronem, třeba jen jednou za dva měsíce. Správný ACME klient by měl sám ohlídat, zda je některý certifikát potřeba obnovit, proto není na škodu spouštět ho třeba dvakrát denně − tak zní oficiální doporučení pro Certbot.
Aktualizace 12. ledna: nebezpečná validace už nebude zprovozněna
Již během 10. ledna byla validační metoda dočasně povolena několika velkým uživatelům, kteří na ní byli závislí a zároveň netrpěli uvedenou zranitelností.
Po uplynutí 48 hodin vydal výkonný ředitel ISRG John Aas prohlášení, že vytvoření blacklistu zranitelných webhostingů je v podstatě nemožné, neboť jich je příliš mnoho. Byl proto zveřejněn plán postupného útlumu zranitelné metody.
Zcela zablokovaná bude pro nově vytvořené ACME účty. Pro stávající ACME účty bude po omezenou, zatím blíže neurčenou dobu podporována metoda tls-sni-01
pouze pro obnovování již vydaných certifikátů. Po krátkou až střední dobu zůstane též v provozu whitelist velkých poskytovatelů, u kterých je metoda používána a zároveň netrpí objevenou zranitelností. Za velkého je přitom považován poskytovatel s více než 10 tisíci aktivními certifikáty. John Aas ale upozorňuje, že tým ISRG nemá dostatečné personální kapacity pro udržování whitelistu, proto na něj nedoporučuje spoléhat.
Lidé z ISRG také spolupracují s tvůrci ACME klientů, kteří nebezpečnou validaci preferují, na vydání aktualizace, která metodu nahradí za http-01
. Oficiální klient Certbot by měl takovou aktualizaci získat během několika dnů.