Vlákno názorů k článku Let's Encrypt: jak funguje a co nabídne od Dafuq - WTF?! Je jistě jednoduší dynamicky měnit konfiguraci x webserverů,...
-
Ondřej CaletkaZlatý podporovatelCo 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.
-
Dafuq (neregistrovaný)
Ale no tak. Jistě víš co prakticky dělá v apache volba "NameVirtualHost *:443" a že pro klienty kteří neumí SNI je důležité pořadí virtualhostů v konfiguráku.
Bez automatické změny se obejdu velmi jednoduše, jestli tedy platí to co píšeš níže. Na začátku používání JEDNOU v konfiguraci nastavím vrácení správného MIME typu pro /.well-known/acme-challenge/* a při výměně certifikátu už na konfiguraci sahat nemusím, skript si požádá o certifikát, udělá ten hash v cestě, nakopíruje certifikát a udělá graceful. To vše automaticky a bez pravidelného blbnutí s konfigurací se zakládáním virtuálního webu s blbým certifikátem a jménem.
Jestli to takhle půjde tak jsem spokojen a tohle měl být default.
-
Ondřej CaletkaZlatý podporovatel
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.
-
Ondřej CaletkaZlatý podporovatel
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.
Takže už asi chápu, že jako „vypnuté SNI“ označujete stav, kdy je pro daný soket nakonfigurován jen jeden certifikát, přestože chování webserveru je stále stejné. Moc nechápu, k čemu je dobré takové stavy rozlišovat.To ani omylem. Pokud se něco přidá na počátek, tak se rozbije konfigurace pro ne SNI klienty. Viz výše.
A proč myslíte, že by se ta utilita o něco takového pokoušela? Připadá mi, jako byste za každou cenu hledal důvod, proč to nemůže fungovat, i když to funguje. -
Filip JirsákStříbrný podporovatelUpřímně řečeno, utilita, která se pokouší měnit konfiguraci, je dost odvážné řešení, které samozřejmě má potenciál konfiguraci rozbít. Osobně bych nic takového na serveru nikdy nespustil. Pokládám to ale za nouzové řešení do doby, než budou mít ACME integrované příslušné nástroje v sobě (tj. např. distribuční konfigurační skripty pro Apache).
-
A proč myslíte, že by se ta utilita o něco takového pokoušela?
Já si především nic takového nemyslím a ani jsem nic takového nepsal.
Reagoval jsem na:
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á.
Což zjevně není pravda, protože v reálu se používají i takové konfigurace, které na "pouze se něco přidá" nezareagují úplně dobře.
Co dělá nebo nedělá utilitka, ke které jsem se vůbec nevyjadřoval, nevím a očekávám, že půjde použít i v čistě manuálním režimu, kdy veškeré požadované kroky k dokončení procesu vydání crt udělá admin. (Což by třeba u mě zahrnovalo i vytvoření csr a uložení klíče mimo dosah této utilitky.)
-
Ondřej CaletkaZlatý podporovatel
Budete spokojenější, když v původním prohlášení nahradíte slovo „přidá“ za slova „přidá na konec“? Protože to jsem měl namysli když jsem to psal a implicitně to tak předpokládal.
Co dělá nebo nedělá utilitka, ke které jsem se vůbec nevyjadřoval, nevím a očekávám, že půjde použít i v čistě manuálním režimu, kdy veškeré požadované kroky k dokončení procesu vydání crt udělá admin. (Což by třeba u mě zahrnovalo i vytvoření csr a uložení klíče mimo dosah této utilitky.)
Patches are welcome :)
Můžete si také posílat JSONy ručně Curlem ;) -
Patches are welcome :)
Aha. Tak to jo. Vedle probíhá flame na téma Snowden, NSA a vůbec; jedním ze základních pravidel počítačové bezpečnosti je pouštět vše s minimálními právy, PKI se vymyslelo tak, aby soukromý klíč zůstal skutečně soukromý ... a tady se diskutuje o utilitce, která běží s právy roota a sama si generuje klíč a na požadavek na vlastní CSR (což je snad základ, už jen z důvodu toho, že soukromý klíč může být nevydolovatelný na HW) je odpovědí smajlík...
-
Ondřej CaletkaZlatý podporovatel
Cílem té utility je zpřístupnit rozumně bezpečné HTTPS běžným správcům. Není to všelék na všechny problémy světa. Pokud máte privátní klíč v HSM, tak k němu určitě nechcete DV certifikát zadarmo, to je jako lít technický benzín do Rolls Royce.
A pokud to přesto tak chcete, musíte počítat s tím, že pro to budete muset něco udělat. Což je naštěstí možné, neboť jak klient, tak protokol je zcela otevřený. -
Ano, to je jistě chválihodné, ale způsob, jakým se to dělá (jako root spustě ... a o nic se nestarejte) dříve nebo později přinese další problémy (stejně jako v minulosti), kterým by se dalo předejít jiným přístupem. Už jen proto, že ty správce učí chování, které je silně nebezpečné.
Takže na jedné straně bude víc serverů na https (což je dobře), na druhé straně bude víc správců s přístupem "práva neřeším, root stačí; znalosti neřeším, stačí 5x enter; a vůbec ono se to celé samo".
Tedy jeden problém se možná vyřeší, další dva vzniknou.
-
Přes https (SSL2) nebylo původně možné vůbec hostname odeslat, proto se dodělala podpora SNI.
Bez zapnutého SNI se komunikace chová jinak. Proto ještě relativně nedávno na každou https doménu musela být extra IP adresa.
Pokud klient neumí SNI připojí se, ale dokáže načíst jen jednu doménu (obvykle první v konfiguraci). Ovšem spojení probíhá odlišně podle staré specifikace.
Pokud se nepletu, webový server nemusí mít zkompilovanou podporu SNI. Pak samozřejmě to nebude fungovat. Nejedná se tedy jen o konfiguraci.Takže už asi chápu, že jako „vypnuté SNI“ označujete stav, kdy je pro daný soket nakonfigurován jen jeden certifikát, přestože chování webserveru je stále stejné. Moc nechápu, k čemu je dobré takové stavy rozlišovat.
-
Filip JirsákStříbrný podporovatel
SNI je nekritické rozšíření SSL, další údaj, který se posílá v nešifrované části komunikace. Takže pokud SNI neumí klient, prostě daný údaj nepošle. Pokud jej neumí server, daný údaj je pro něj neznámý, a protože je označen jako nekritický, jednoduše jej přeskočí. Vypnuté SNI by pak asi znamenalo, že server tomu rozšíření rozumí, načte ho, ale nijak ho nepoužije a zahodí ho. Netuším, k čemu by takové chování bylo dobré a nevím o serveru, který by něco takového uměl.
