Názory k článku Let's Encrypt: jak funguje a co nabídne

Při použití s podporovanými webservery není nutné webserver vůbec zastavovat. Utilita ho pouze několikrát reloaduje.

Přijde mi, že autoři jsou tak trochu retardovaný - místo toho aby jako první udělali jednorázovou utilitu, která si na vlastním portu ověří doménu a vyplivne cert…
Přesně tohle utilita umí. Jen ten vlastní port je 443, případně 80. A je to tak naschvál, aby se skutečně ověřilo držení webserveru a ne nějaké jiné náhodné služby.

napsali to v nečem líp přenositelným než v pythonu
Co je lépe přenositelné než Python a proč?

Python 2.7 je také na každém slušném systému. Navíc má obsáhlou standardní knihovnu která se chová konzistentně na všech platformách. Shell by rozhodně nebyl dobrý jazyk pro takhle komplexní úlohu. Navíc by stejně musel volat spoustu externích utilit.

Čistý shell rozhodně není tak přenositelný, jak se lze naivně domnívat. V praxi to vůbec není standardizované a všude je to něco trochu jiného, včetně třeba jiných parametrů programů. Proto taky třeba autotools jsou takové děsné bukkake.

Speciálně na různých „lehčích“ systémech ala routery kolikrát nejsou ani zdaleka adekvátní sety programů. Například jako shell busybox s brutálně ořezanými programy jako grep, kolikrát tam není ani sed, chybí CURL a wget. To se pak hodně blbě pracuje s netem.

Oproti tomu python2.7, pokud je, tak je všude stejný. Pokud není, tak se dá doinstalovat jednodušeji, než amorfní cloud příkazů pro shell se správnými parametry.

takže musíte stávající server vypnout a pak ho zase zapnout
Ne, nemusíte. Záleží na možnostech serveru – pokud lze jeho konfiguraci změnit bez restartu, restartovat ho nemusíte. A to, jakým způsobem se mění konfigurace serveru, je záležitost autorů toho serveru, ne Let's Encrypt.

mohlo to bejt v binárce bez závislostí
Jo, binárka bez závislostí, která komunikuje přes HTTPS. Spouštěná pod rootem. To bychom si opravdu pomohli.

Ostatně ten proces se měl navrhnout tak aby šel naskriptovat i v shellu...
Proč? Jak v shellu naskriptujete bezpečnou komunikaci přes internet?

Mám nginx a ten plugin pro nginx jim ještě pořádně nefunguje a certifikáty se dají jednoduše generovat tak, že ukážete tady je webroot tohodle webu a utilita do adresáře $webroot/.well-know/ nasype handshake data pro ACME.

Jsem si docela jistý, že i na custom serverech umíte říct (příklad je nginx):

location ^~ /.well-known/ {
  root /var/lib/letsencrypt/$server_name/.well-known/
}

Protokol je otevřený, dá se tedy předpokládat, že někdo tu implementaci pro Windows brzy udělá. Technicky mu v tom nic nebrání.

Nevzpomínám si, že by v certifikační politice bylo nějaké omezení v tomto směru. Ale pokud jste firma a chcete se pomocí TLS autentizovat, rozhodně bystě měli sáhnout po nějakém komerčním certifikátu s úrovní ověření aspoň OV, aby vaše protistrany měly jasno, že mluví opravdu s vámi a ne jen s nějakým držitelem nějaké domény.

Co si přesně představujete pod pojmem „zapínat SNI“? Ještě nikdy jsem nikde takovou konfigurační volbu neviděl. A když se chcete zbavit ruční práce, tak se bez automatické změny konfigurace webserveru neobejdete.

Bohužel, stále nechápu, jak se dá u apache SNI vypnout a jak se v praxi liší apache se zapnutým SNI od apache vypnutým SNI.

Na začátku používání JEDNOU v konfiguraci nastavím vrácení správného MIME typu…
Ano, to je samozřejmě možné řešení. Problém je, že něco takového se těžko dělá automaticky, protože nakonfigurovat server, aby za všech okolností na určité cestě vracel obsah nějakého adresáře, je příliš komplexní úloha do které zasahují všemožné mod_rewrite a podobné, zatímco založení prázdného virtualhosta se správným SSL certifikátem je možné provést vždy bez nutnosti analýzy a úpravy stávající konfigurace, pouze se něco přidá.

Bohužel, stále nechápu, jak se dá u apache SNI vypnout

Třeba tak, že se nepoužije named based virtual hosts a definice vhosta není *:443 ale na konkrétní ip:port. Potom na každé unikátní kombinaci ip:port poslouchá jeden virtual host bez ohledu na server name.

a jak se v praxi liší apache se zapnutým SNI od apache vypnutým SNI

No celkem podstatně. Aby fungoval named based vhosts tak je nutné mít prohlížeč a protokol podporující SNI (což jsou teda dneska všechny aktuální), pokud toto nepodporuje, tak apache použije cert. z prvního (vyhovujícího) vhosta v konfiguraci, nebo zkrátka z vhosta na dané ip.

zatímco založení prázdného virtualhosta se správným SSL certifikátem je možné provést vždy bez nutnosti analýzy a úpravy stávající konfigurace, pouze se něco přidá

To ani omylem. Pokud se něco přidá na počátek, tak se rozbije konfigurace pro ne SNI klienty. Viz výše.

Ondra s Petrem to v článku píšou - existuje i manuální metoda, kde certifikáty generujete na jiném stroji, než pak poběží. Zatím jsem neměl potřebu to zkoušet, ale je to podporovaná metoda (i když to asi bude drbačka, která půjde špatně automatizovat).

Máte dvě možnosti – buď provést DNS důkaz, což je ruční práce, ale celkem snadná, nebo vystavit soubor na cestě /.well-known/acme-challenge/<nějaký hash>. Aby bylo jisté, že to děláte úmyslně, musí ten vystavený soubor vracet MIME typ Application/jo­se+json, což bude vyžadovat zásah do konfigurace webserveru.

Pokud vám takovou konfigurační volbu hosting umožní, neměl by být problém vygenerovat certifikáty třeba u sebe na druhém konci světa a na hosting je pouze nahrát. A samozřejmě celý postup opakovat nejdéle každé 3 měsíce (tedy přinejmenším to nahrání certifikátu; ta validace bude mít možná delší platnost).

Co jiného než právě kompletní open-source může sloužit jako záchytná síť před podobnými problémy? Velkou výhodou zde je, že to dokonce ani není binárka, ale skript v pythonu, takže je celkem snadné zkontrolovat, že se shoduje s oficiální verzí.

Takhle například vypadá generování klíče:

def make_key(bits):
    """Generate PEM encoded RSA key.
    :param int bits: Number of bits, at least 1024.
    :returns: new RSA key in PEM form with specified number of bits
    :rtype: str
    """
    assert bits >= 1024  # XXX
    key = OpenSSL.crypto.PKey()
    key.generate_key(OpenSSL.crypto.TYPE_RSA, bits)
    return OpenSSL.crypto.dump_privatekey(OpenSSL.crypto.FILETYPE_PEM, key)

Žádná magie, prostě volání OpenSSL funkcí.

Je paradoxní, že aby se vyřešil problém s mnoha autoritami, založí se nová. Ale jejich cílem je založit jednu a ukázat všem, jak to dělat pořádně.
Kdyby to chtěli dělat opravdu pořádně, tak nemůžou vydávat DV certifikáty. Protože v případě DV certifikátu se certifikační autoritu zaručuje, že vlastník privátního klíče je držitelem domény – za což se ve skutečnosti zaručit nemůže, protože i kdyby to vlastnictví domény ověřila opravdu bezpečně, stejně může majitel doménu vzápětí po vydání certifikátu prodat, nebo může expirovat, nebo mu může být odňata.

Mimochodem, jak se Let's Encrypt brání útokům na DNS? Ověřuje DNSSEC, pokud je k dispozici? Provádějí DNS dotazy z několika nezávislých lokalit a porovnávají odpovědi?

Bohužel, Rubicon už byl překročen, DV certifikáty se vydávají a klientské systémy jim důvěřují. Tohle už se asi nedá vzít zpět, tak je dobré to aspoň udělat pořádně a znesnadnit případná zneužití. Tedy ano, DNSSEC validují (ale podepsaná doména není podmínkou) a ano provádějí ověření z více lokalit. Také mají po vzoru ostatních autorit implementovaný blacklist na Alexa Top 1000 domén. Nejzajímavější je pro mě ale právě kontrola existujících certifikátů a požadavek na důkaz držení privátního klíče.

Podle mne ale „udělat to pořádně“ neznamená vytvořit další certifikační autoritu, která bude potvrzovat něco, co potvrdit nedokáže, ale implementovat do nějakého rozšířeného prohlížeče (asi do Firefoxu) podporu pro DANE.

To, co popisujete, není „udělat pořádně to, co se už dělá“, ale „vyrobit něco nového, co stávající systém nahradí a doufat, že na to lidé přejdou“.

Když bych to přirovnal k řešení problému nedostatku IP adres, tak vámi navrhované řešení je typu IPv6, zatímco Let's Encrypt představuje spíš něco jako NAT :)

Oficiálně nikde. Nicméně blacklist byl ještě nedávno součástí zdrojových kódů autority:
https://github.com/letsencrypt/boulder/blob/2b760ceee392228a2e3a90ae3c558edf5d42b9d5/policy/blacklist.go

Později byl odloučen do samostatné databáze, aby nebylo nutné při každé změně autoritu překompilovávat. Bohužel se ale od té doby ztratil z veřejného prostoru, můžeme jen věřit, že tam stále je :)

Tak akorát dnes mi dorazila do mailu pozvánka do closed beta. Utilitka je to celkem šílená, nainstalovala si hned po spuštění hromadu balastu, místa mám sice zatím dost, ale je to VPS s 20GB diskem, takže mě to trochu naštvalo.
Zkusil jsem jejich automatiku a první problém byl s virtualhostama na Apachi. Nelíbilo se tomu, že mám v jednom confu víc virtualhostů, jsem na to zvyklej, mám tam 5 domén a pod nima jsou věci jako www.domena.cz, mail.domena.cz atd, takže to mám vždy v jednom confu, ať v tom není zmatek. Po rozházení do samostatných konfiguráků to pěkně našlo všechny virtualhosty a zeptalo se to, pro které domény chci generovat certifikát, dokonce to vygenerovalo přesměrování http->https (zeptalo se to) a po skončení už https normálně funguje. Pouze zatím v rámci beta programu nevystavují důvěryhodné certifikáty, ale ověřovatel je "happy hacker fake CA".
No uvidíme, jak to bude, zatím mi to přijde takový trochu těžkopádný, nicméně nakonec to na Debianu udělalo, co mělo.

Gratuluji k pozvánce!

Pouze zatím v rámci beta programu nevystavují důvěryhodné certifikáty, ale ověřovatel je "happy hacker fake CA".
Tak v tom případě ale nemáte certifikát v rámci beta programu, ale veřejné demo, které takhle funguje už víc než rok. Nezapomněl jste na příkazové řádce nastavit správnou adresu produkční autority?

Ale oni už vystavují ostré důvěryhodné certifikáty – třeba deb.sury.org. Pravděpodobně jsi stáhl testovací verzi utility letsencrypt, která je k dispozici už dlouho všem, ale nechává si generovat certifikáty z testovacího prostředí a ty nejsou důvěryhodné.

Tak to děkuji za upozornění, asi nějaká chybka se přihodila, jdu to zkouknout znova :D

Tak přegenerováno znovu a lépe a ano, už je to podepsáno Lets encryptem, ještě jednou děkuji za upozornění, příšte musím víc číst, než se na to vrhnu, ale já se tak těšil... :D
Jinak jak jsem již psal, až na to, že si to samo bez dotazu začalo tahat hromadu balíků a potom drobný problém se stávající konfigurací Apache, tak vše proběhlo v pořádku, vyzkoušeno na doméně, která původně https nepoužívala vůbec a výsledek byl ihned funkční a dle ssllabs má rating A.

Projekt Let's Encrypt primárně řeší šifrovaný web, tedy ano. Nicméně nic vám nebrání použít získané X.509 certifikáty kdekoli je to možné, tedy například na službách typu IMAP a Submission. Nebudou však vydávány ani osobní, ani code signing certifikáty.

Co se týče šifrovaného předávání pošty mezi SMTP servery, tam se autoritou vydaný certifikát vůbec nevyplatí. Jediné, co tam funguje, je DNSSEC a DANE. Shodou okolností o tom budu povídat v neděli v Brně a příští čtvrtek v Karviné.

Pokud jde o samostatný mailserver, půjde to velmi snadno, stačí na něm nainstalovat a spustit utilitu. Ona má v sobě vestavěný webserver pro provedení důkazu, který na samostatném mailserveru nebude s ničím kolidovat, pak vám vypadne soubor s certifikátem a klíčem v cestě /etc/letsencrypt a vy musíte ručně nakonfigurovat SMTP server aby je použil. A při každé obnově certifikátu musíte ručně SMTP server reloadovat.

Pokud je mailserver kombinovaný s webserverem, máte možnost provést důkaz ve stávajícím webserveru, ale certifikát opět nainstalujete manuálně.

Na linuxových počítačích bývala možnost naslouchat na nízkých portech (menších než 1024) vyhrazena uživateli root. Webový server typicky k ničemu jinému rootovská práva nepotřeboval, proto obvykle fungoval tak, že se spustil s právy roota, začal poslouchat na portu 80 a 443, a pak se rootovských práv vzdal. Tedy tak jinak než pod rootem.

Ten web server toho nemá moc na práci, nemusí spouštět žádný cizí kód, takže nejspíš bude bezpečnější, než 99 % PHP webů.