Názory k článku ACME.sh: snadná cesta k certifikátu od Let's Encrypt
-
Ondřej CaletkaZlatý podporovatelA co na něm zkontrolujete? A ten vlastní skript
acme.shtaky kontrolujete řádek po řádku, než ho spustíte?Pokud to děláte jak je psáno v samostatném uživatelském účtu, a stahujete přes HTTPS z adresy, kterou jste se dozvěděli na stránce projektu, nepředstavuje to žádné přidané bezpečnostní riziko.
-
Ja (neregistrovaný)
Používám https://github.com/diafygi/acme-tiny a dle požadavku autora jsem ho řádek po řádku zkontroloval.
-
Ondřej CaletkaZlatý podporovatel
A opravil jste při té přiležitosti tu -závadu- vlastnost spočívající v neobnovování mezilehlých certifikátů? Tohle, resp. neochota autora uznat, že to je problém a zabývat se tím, mě od používání
acme_tiny, potažmoletsencrypt-nosudoodradila. -
Finch (neregistrovaný)
Pokiaľ som správne pochopil tak acme-tiny vôbec nerieši intermediate certifikáta a a je potreba ho ztiahnuť zvlášť a pripojiť k certu vygenerovaným acne-tiny. Napísal som skript pre cron, ktorý obnovuje certifikáty a v prípade zmeny intermediate certifikátu stačí zmeniť url pre wget. Raz už došlo k zmene z x1 na x3. Nie je to automatické, ale dá sa tým žiť. Neviem ako to rieši ACME.sh.
Spomínaný script:
https://gist.github.com/mauron85/63adcc13b9d43134fc67 -
Ondřej CaletkaZlatý podporovatel
Nie je to automatické, ale dá sa tým žiť.
Bohuzel, tohle je právě zásadní problém. Ke změně mezilehlého certifikátů může dojít kdykoli bez předchozího upozornění – ostatně mají jako horkou zálohu certifikát X4.
To už je lepší použít wrapper, který k nalezení mezilehlého certifikátu volá službu třetí strany https://whatsmychaincert.com/ nebo jej sám zjišťuje z X.509 metadat jako mkcertchain.
Nejlepší je ale použít ACME klienta, jehož autor neignoruje fundamentální principy PKI.
-
Ondřej CaletkaZlatý podporovatel
Ano, je to přesně tak. Jen pozor, pokud používáte samostatný systémový účet, je třeba přesměrovat poštu od cronu někam, kde ji budete číst ;)
Mně se třeba stalo, že po upgradu
acme.shna novou verzi se rozbil můj vlastní skript pro správu DNS záznamů. Denně mi chodil e-mail s textem „It seems that your api file is not correct, it must have a function named: dns-oskarzones_add“ do schránky, kterou nikdo nečetl ;)Teprve až po zjištění, že Nebezi.cz nešifruje jsem zavedl přesměrování pošty a zařídil nagios sondu
check_http, aby kontrolovala čerstvost všech certifikátů. -
Finch (neregistrovaný)
Ano o neprečítaných mailov o chybe by som mohol napísať samostatný článok. :-) Keď už som pritom ako riešite posielanie mailov len pri chybe? CRON totiž od nepämati posiela maily pri akomkoľvek výstupe zo skript. Existuje pekný bash skript cronic - http://habilis.net/cronic/, ktorý pracuje na princípe odchýtavanie error výstupu a chybový kódu a teda email sa pošle len v prípade chyby. Avšak neumožnuje zároveň ukladania výstupov do súboru. Asi by to šlo "o hackovať" cez nejaký multiplex výstupov (tee), ale nič s čím by som bol spokojný. Ako to riešite vy?
-
Ondřej CaletkaZlatý podporovatel
Já to řeším tak, že moje cronjoby neprodukují žádný výstup, když je všechno v pořádku. Ale taky to není ideální, může se stát, že se cron zasekne, nebo se zasekne úloha (cron ji znovu nespustí, pokud ještě běží) a člověk se to nedozví.
Na tohle je asi nejlepší kombinovat to se správně zvolenými pluginy v Nagiosu.
-
Spider (neregistrovaný)
> A co na něm zkontrolujete? A ten vlastní skript acme.sh taky kontrolujete řádek po řádku, než ho spustíte?
Jo, skriptiky/utilitky psane v Bash/C/Perl/Python/Ruby/... kontroluju. Uz jenom pro ten procit. Ale ne, fakt nekontroluju kazdej zdrojak co se ke mne dostane.> Pokud to děláte jak je psáno v samostatném uživatelském účtu, a stahujete přes HTTPS z adresy, kterou jste se dozvěděli na stránce projektu, nepředstavuje to žádné přidané bezpečnostní riziko.
Jo, to si myslelo hodne lidi predtim, nez si stahli nakazeny ISO Mintu.Ja nerikam, ze zrovna v tomhle pripade je to nebezpecne, ale stejnou prasarnu jsem videl na webech/blozich a instalovaly se tim cele stacky :-(
-
lol (neregistrovaný)
Zrovna u breachu ako u Mintu ste nemali sancu nic zistit. Museli by ste kontrolovat PGP signatury... co mozete kontrolovat aj u veci ktore curlnete z https a prepipujete do shellu.
Tazko doverovat aplikacii, ked nedoverujem jej instalatoru - co vznasa otazku: preco ju vlastne instalujem?
-
Crow (neregistrovaný)
Omlouvám se, chtěl jsem pouze poukázat na možné problémy a dát podnět k možné diskuzi - podle reakcí některých kolegů se zdá že marně.
"A co na něm zkontrolujete?"
- vždy kontroluji alespoň instalační skript - je většinou na pár řádků a stejně chci znát prováděné změny
- bohužel samotný kód není úplně v lidských silách možné projít a nezbývá tak než se spolehnout na serióznost přispěvatelů repizitáře."... nepředstavuje to žádné přidané bezpečnostní riziko..."
- to velice záleží na vašem vnímání bezpečnostního rizika a jak moc je člověk paranoidní ;-)
- např. odkaz v mém původním komentáři popisuje timing atack, kde webserver může rozpoznat právě přesměrování do shellu a podle toho naservírovat patřičně upravený, nebo úplně jiný, soubor (Toto předpokládá aby útočník ovládal doménu i s certifikátem - opět záleží na člověku jak moc je paranoidní - v tomto případě asi dost :-D). -
Ondřej CaletkaZlatý podporovatel
to velice záleží na vašem vnímání bezpečnostního rizika
Ne. Pokud je instalační skript od stejného autora jako instalovaný program, a vy instalovanému programu důvěřujete (protože nemáte kapacitu/čas/sílu na to celý ho auditovat), pak vám kontrola pár řádkového instalačního skriptu nemůže žádným způsobem zvýšit bezpečnost. Když vám bude chtít autor ublížit, určitě to nebude dělat okatě v pár řádkovém skriptu, ale udělá to někde v 3000 řádcích instalovaného programu.
-
Lol Phirae (neregistrovaný)
Když vám bude chtít autor ublížit, určitě to nebude dělat okatě v pár řádkovém skriptu, ale udělá to někde v 3000 řádcích instalovaného programu
Tys ještě asi nikdy neudělal debilní botu ve skriptu, viď.
-
Ondřej CaletkaZlatý podporovatel
Nevím jak souvisí odkaz na zmíněnou chybu v 600řádkovém skriptu. Možná tím chcete jen podpořit moje tvrzení, že pokud nekontrolujete ten velký skript, tak to důkladnou kontrolou toho malého nezachráníte.
-
Lol Phirae (neregistrovaný)
Ale nijak, přeci. Tahat něco z webu a přes trubku to spouštět je děsně chytré, kontrolovat to je zbytečné. Hlavně v případě, když to není ani balíček, ale něco, v čem se lidi permanentně vrtaj a co chvíli se to mění, jako např. skript na Githubu. Každá trubka svého štěstí strůjcem, no.
-
Petr (neregistrovaný)
Používám https://github.com/lukas2511/letsencrypt.sh - taky jenom shell
-
Cx (neregistrovaný)
Já používám acmetool:
https://github.com/hlandau/acme
Umí to samé, možná dokonce víc a je napsán v normálním jazyku.
-
dakujem za velmi konstruktivnu odpoved, ktora neriesi moj problem, ale nieco uplne ine, zachvilu tu zacne niekto riesit gramatiku...
fajn dkim nevyzaduje podpisany certifikat, nevyzaduje ho teoreticky ani ssl pri zasielani mailov, staci selfsigned vsade, tak to mam teraz a takmer vsade su maily ok, ale najdu sa experti ako hotmail co z nejakeho dovodu zahadzuju vsetky atachementy z mojej domeny a pritom gmail to nerobi. Chcem ist tento krat na totalne maximum. Kazda drobnost ti zvysi doverihodnost, obcas mi tie filtre na roznych mailovych sluzbach pripadaju jak google page rank, aby som posielal uz aj fotokopiu obcianky prilozenu k mailu aby boli ochotne mail zaradit medzi riadne prijatu postu a nezasuvat do spam adresara
-
Filip JirsákStříbrný podporovatelV DKIM se certifikáty vůbec nepoužívají, pouze veřejný klíč. Pokud váš poštovní server odesílá e-mail, je v roli klienta a certifikát vašeho serveru se také nepoužije. Certifikát vašeho poštovního serveru se použije v okamžiku, kdy je v roli serveru a e-mail přijímá – mělo by se podle něj ověřit, že se e-mail předává tomu správnému serveru a ne nějakému podvodníkovi.
-
odbieha sa ale od temy, problem bol ako ziskat a obnovovat certifikaty na serveri ktory nema pristupny port 80
je to spravitelne cez skripty a pomocou http serveru na inom stroji, ide mi len o to ci je tu aj nejaka 3. standardna cesta priamo z toho servera.
aby tu vsetci prestali riesit dkim a mail server tak povedzme ze priklad je nejake raspberry pi s http serverom co zobrazuje nejaku statistiku a je potrebne https z nejakeho dovodu a chceme doverihodny certifikat aby nas browser furt nebuzeroval, je to doma kde nemame verejnu ip, kde sme za nejakym domacim routrom, dufam ze tu nikto teraz nezacne riesit praktickost takehoto riesenia alebo ako by sa to dalo spravit inak, prosim rieste iba sposob ako ziskat certifikat
-
Filip JirsákStříbrný podporovatel
Vůbec nezáleží na tom, kde je ten web server umístěný, klidně může být na druhé straně zeměkoule. Podstatné je, aby v době kontroly údajů pro certifikát byly HTTP požadavky na jméno, které chcete mít v certifikátu, směrovány na tento server a ten je uměl správně obsloužit. Nebo-li
AneboCNAMEzáznam pro dané jméno musí vést na tento váš webserver.Případně nemusíte k ověřování vůbec používat web server, můžete použít ověření čistě přes DNS.
-
Ondřej CaletkaZlatý podporovatel
Chápu správně, že ten webserver sdílí veřejnou IPv4 adresu s tím Mailserverem? Pak se to dá vyřešit třeba připojením ověřovacího webrootu z webserveru na mailserver třeba pomocí sshfs.
Pokud mají oba servery každý samostatnou IPv4 adresu, je nejjednodušší otevřít port 80 na firewallu.
Jako třetí možnost je zprovoznit si nějakým způsobem automatizovanou úpravu DNS a používat ověření pomocí DNS.
-
maestrx (neregistrovaný)
Zdravim,
dekuji za super clanek. Presto bych rekl ze je v nem chyba. Konfigurace httpd mi nefungovala protoze tam chybi jeden podadresar v aliasu. Po oprave je vse funkcni a konfigurace vypada takto:
Alias /.well-known/ /home/letsencrypt/webroot/.well-known/ <Directory /home/letsencrypt/webroot/> AllowOverride None Require all granted Satisfy Any </Directory>
