Názory k článku Caddy: web server s Let's Encrypt v základní výbavě

Přiznám se, že mě celkem zaujal. Na IF jsem letos bohužel nebyl ale sjel jsem videa.

Celkem by se mi hodil nějaký lehký webserver na dobnosti, kde je třeba NGINX zbytečný. Když jsem v sekci Download zahlédl možnost výběru feature, zajásal jsem.

Tedy pouze do okamžiku, než jsem zjistil že třeba let's encrypt je zadrátovaný přímo do core.. Proboha proč? Proč by jedna konkrétní autorita měla být součástí webserveru? Proč nejde o modul jako git, nebo jsonp?

Použití bez TLS certifikátu si samozřejmě neumím představit, ale autorit zde máme hromadu a každý z různých důvodů nějakou preferuje. Pro mě LE důvěryhodná není a nechci nic, co s tím může komunikovat.

Pokud by se jednalo opravdu o rychlý a lehký webserver, určitě bych využití našel, ale s přístupem že když je něco zrovna "in", tak to narvem všem to skončí stejným bastlem jako Apache. Dělat toho co nejvíc, ale nic dobře. Škoda nadějného projektu..

Rychlý a lehký webserver je např. Nginx. Caddy má úplně jiný účel – je to webserver, který už má „všechno potřebné“ hotové a nakonfigurované, stačí jenom web server spustit a o nic se nestarat, rovnou začnete vytvářet webové stránky. Caddy není určen pro lidi, kteří chtějí něco konfigurovat – právě naopak, je určen pro lidi, kteří vytvářejí webové stránky, a potřebují „jenom“ ty stránky někam umístit.

Nejsou, protože ty (zatím) nemají ty funkce, že by server sám „vytvářel“ obsah – že by třeba stačilo nahrát na server Markdown soubor, server by to sám rozpoznal a převedl do HTML.

Podle dokumentace je možné snadno dodat vlastní certfikát a klíč. Použít LE jako výchozí autority je mnohem lepší výchozí hodnota než použití selfsigned „SnakeOil“ certifikátů, jak je obvyklé třeba pro Apache v Debianu.

V případě 64bitového Linuxu má binárka velikost téměř 23 MB. Pro srovnání: balíček nginx-full v Debian Jessie sice zabírá po rozbalení jen lehce přes 1 MB, pokud jej však instalujete na minimální systém, vyvolá stažení dalších závislostí, které si řeknou o dalších 62 MB.

Snažíte se naznačit, že si nginx do paměti po startu natáhne i veškerý obsah /usr/share/doc? Místo na disku, které zabírají balíčky, je veličina, která je opravdu nezajímavá z libovolného úhlu pohledu
Co je zajímavé, je spotřebovaná paměť per nakonfigurovaný web, per spojení, atp. Sdílené knihovny zabírají v paměti místo jenom jednou (zjednodušeně řečeno).

Aneb fakt mě na závodní dráze nezajímá, že má trabant opravdu ale opravdu lehkou karosérii...

A osobně si myslím, že Go se svým statickým linkováním je security nightmare. CVE-2015-8618, které Vás donutí překompilovat veškerý Go kód používající TLS (resp. RSA klíče) je fakt bezva.

Taky zbožňuji instalaci náhodných binárek z náhodných webových serverů, kde není zjevné, s čím a jak bylo co zkompilováno. Přijde mi to jen o úroveň horší než `wget foo | sudo bash`. Bavíme se tady o kontrole kontrolních součtů a tady není ani vidět jaké verze knihoven výsledná binárka používá. Řekněme, že je v miekově DNS knihovně v nějaké verzi bezpečnostní chyba, tak a teď mi řekněte, jestli jsem v bezpečí nebo ne? Těžko říct, co? GH/miek/dns je jenom git repozitář, který zatím nemá ani jeden release, tj. se při každém sestavení použije aktuální verze z gitu? A mám vlastně správnou verzi z webu, když autor nevystavuje podepsané kontrolní součty, nebo už mám na serveru nějakou pěknou čínsko-rusko-americkou binárku, a tajné služby se přetahují, kdo rychleji stáhne obsah mého disku? No bezva, půlka bezpečnostního týmu právě podala výpověď a druhá půlka se preventivně opila do němoty...

Na takové to domácí hraní, kde to na klik nasadím v throw-away kontejneru, je to dobrý, ale pro seriózní použití směrem ven do Internetu, kde jsou zapotřebí nějaké garance, bych raději pouvažoval o projektu, který bezpečnost bere vážněji.

Kde to mám podepsat? :-) To srovnání oproti systémovému balíku bylo opravdu zbytečné, nicméně jinak je článek pěkný, taky mě ten software zaujal (na takovéto "domácí webserverování").

Pamatujete na DLL-hell? Pak na JAR-hell? Teď máme Go-hell... Jako občasný balíčkář jsem se s tím už potkal a je to hodně špatně řešitelná situace, pokud se upstream k tomu bude stavět a nadále chladně. Ono to do sebe "zapadá" - kontejner plný CVEček, v něm běží mega-statická binárka s další várkou CVEček a přes to všechno se odesílá spam, dolují bitcoiny a DDoSuje zatímco autor rajdí na skateboardu a na zádech v batohu MacOS.

Snažíte se naznačit, že si nginx do paměti po startu natáhne i veškerý obsah /usr/share/doc? Místo na disku, které zabírají balíčky, je veličina, která je opravdu nezajímavá z libovolného úhlu pohledu
Co je zajímavé, je spotřebovaná paměť per nakonfigurovaný web, per spojení, atp. Sdílené knihovny zabírají v paměti místo jenom jednou (zjednodušeně řečeno).

Aneb fakt mě na závodní dráze nezajímá, že má trabant opravdu ale opravdu lehkou karosérii...

Děkuji za váš názor. Natahování /usr/share/doc do paměti při normálním použití je samozřejmě nesmysl. Pokud podle vás toto vyplývá z některé části článku, tak se omlouvám, nebyl to záměr. Pokus o srovnání velikosti s nginx je zde zmíněn z toho důvodu, že jsem se s otázkami ohledně přiměřenosti velikosti binárky již několikrát setkal. Proto jsem se snažil číslo zasadit do kontextu pro porovnání.

Spotřeba paměti samozřejmě je zajímavý údaj, nicméně se tady snažíte o zařazení Caddy serveru do kategorie, do které nemíří. Jeho hlavním cílem není rychlost nebo nenáročnost na prostředky, ale jednoduchost nasazení a konfigurace. Vaše přirovnání se závodní dráhou je tedy stejně zcestné, jako byste samořídící automobil od Google hodnotil podle výsledku na oné závodní dráze.

Bezpečnost, kontrolní součty, a komplikace s reprodukovatelností sestavení jsou samozřejmě nezanedbatelná kriteria, ale jsou dána použitým jazykem, a nikoliv projektem či konceptem jako takovým.

S tím srovnáváním jste začal Vy v článku. Jen tak mimochodem, nginx(-full) binárka a všechny sdílené knihovny, což je přibližně[*] tento seznam:

14544 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
14664 /lib/x86_64-linux-gnu/libdl-2.19.so
20648 /usr/lib/x86_64-linux-gnu/libXdmcp.so­.6.0.0
35176 /lib/x86_64-linux-gnu/libcrypt-2.19.so
62376 /usr/lib/x86_64-linux-gnu/libjbig.so.0
64024 /lib/x86_64-linux-gnu/libpam.so­.0.83.1
72136 /lib/x86_64-linux-gnu/libgpg-error.so.0.13.0
72904 /usr/lib/x86_64-linux-gnu/libXpm.so­.4.11.0
87912 /usr/lib/x86_64-linux-gnu/libexslt.so­.0.8.17
109144 /lib/x86_64-linux-gnu/libz.so.1.2.8
113024 /lib/x86_64-linux-gnu/libaudit.so­.1.0.0
137440 /lib/x86_64-linux-gnu/libpthread-2.19.so
138016 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
141752 /lib/x86_64-linux-gnu/liblzma.so­.5.0.0
158616 /lib/x86_64-linux-gnu/libpng12.so­.0.50.0
165864 /lib/x86_64-linux-gnu/libexpat.so­.1.6.0
195616 /usr/lib/x86_64-linux-gnu/libGeoIP.so­.1.6.2
248816 /usr/lib/x86_64-linux-gnu/libfontcon­fig.so.1.8.0
256144 /usr/lib/x86_64-linux-gnu/libxslt.so­.1.1.28
289464 /usr/lib/x86_64-linux-gnu/libjpeg.so­.62.1.0
392312 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
426216 /usr/lib/x86_64-linux-gnu/libgd.so.3.0.0
448440 /lib/x86_64-linux-gnu/libpcre.so­.3.13.1
479528 /usr/lib/x86_64-linux-gnu/libtiff.so­.5.2.0
696008 /usr/lib/x86_64-linux-gnu/libfreety­pe.so.6.11.1
924096 /lib/x86_64-linux-gnu/libgcrypt­.so.20.0.3
1051056 /lib/x86_64-linux-gnu/libm-2.19.so
1215032 /usr/sbin/nginx
1319088 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
1465816 /usr/lib/x86_64-linux-gnu/libxml2.so­.2.9.1
1738176 /lib/x86_64-linux-gnu/libc-2.19.so
1776592 /usr/lib/x86_64-linux-gnu/libvpx.so.1.3.0
2062720 /usr/lib/x86_64-linux-gnu/libcrypto­.so.1.0.0

zabírají celkem cca 15MB.

* - přibližně, protože některé z knihoven můžou do paměti natahovat nějaké kousky dynamicky.

Z toho minimálně dva největší kousky (libc a libcrypto) jsou už natažené do paměti kvůli něčemu jinému.

Kdyby to Vaše srovnání nebylo takový do očí bijící nesmysl, tak bych nad tím asi i mávl rukou.

> nikoliv projektem či konceptem jako takovým.

Nepodepsané binárky bez kontrolních součtů na web dal taky onen jazyk? Aha, to je pekelná potvora to Go... No tak to jó.

"Bezpečnost, kontrolní součty, a komplikace s reprodukovatelností sestavení jsou samozřejmě nezanedbatelná kriteria, ale jsou dána použitým jazykem, a nikoliv projektem či konceptem jako takovým."

I kdyby to byla pravda (jakože není), tak:

1. Je mi asi celkem jedno, jestli mám děravý server kvůli jazyku, kvůli standardní knihovně, kvůli samotnému projektu webserveru, nebo kvůli distribuci. Prostě mám děravý server a otázkou potom jsou rizika, možnosti řešení atd.
2. Volba jazyka atd. je taky záležitostí autorů, to není volba, která by jim byla vnucena zvenku...

https://caddy.halenka.eu/ v chrome:

Vaše připojení není soukromé

Útočníci se mohou pokusit ukrást vaše údaje na webu caddy.halenka.eu (například hesla, zprávy nebo informace o platebních kartách). NET::ERR_CERT_IN­VALID

Problém je ale na vaší straně.Za prvé to nemá vůbec nic společného s prohlížečem, ale s tím, jaký certifikát prohlížeč posílá a jakým certifikátům vy důvěřujete. Nenapsal jste, jaký certifikát prohlížeč obdržel, takže můžeme jen hádat. každopádně teď ten web má certifikát podepsaný certifikační autoritou Let's Encrypt se sériovým číslem ‎ 01 71 3c 6d 81 5f f6 2a a4 ea ed 25 3b 71 4f 12 ad 41. Takže jsou tři možnosti:

1. při vaší návštěvě server předložil jiný certifikát, než posílá teď,
2. nebo na vaši komunikaci někdo zaútočil a vy jste ve skutečnosti komunikoval s jiným serverem,
3. nebo certifikační autoritě Let's Encrypt nedůvěřujete.

Kvůli bodům 2 a 3 tu certifikáty a certifikační autority jsou, takže já myslím, že to funguje dobře.