Názory k článku
SSL.com je další certifikační autoritou podporující protokol ACME

Já se toho nebojím. Jenom mi jiný pohled na věc (na kterém je jediné podstatné opravdu jen to, že je jiný) mi totiž vůbec nic nepřináší. Asi mám větší fantazii, než bez přezdívky, ale takových jiných pohledů dokážu vygenerovat spoustu – je to omezené jenom tím, jak dlouho mne to bude bavit. Pokud vás tolik zajímají jiné pohledy, tady jich pár zcela zdarma máte. Myslím, že vám budou úplně k ničemu.

• 2+2 je -7.23
• Země má tvar pravidelného sedmnáctistěnu.
• Zítra se gravitační konstanta zvětší na dvaapůlnásobek.
• Mol je savec.
• Obyvatelé 4. oběžnice Vegy mluví staročeštinou.
• Rok na Zemi má ve skutečnosti 400 dní, těch chybějících 35 dní všichni lidé spí a vlády pořádají své nekalé rejdy.
• Lidská kost je pevnější než dřevo.

(To poslední tvrzení může být pravdivé - přijde na to, jaké dřevo.)
Ona ta hezká "konspirační teorie" vychází z přesvědčení, že nikdo nedělá nic, z čeho by nešlo zbohatnout - leda hlupák.A protože obchodní úspěch LE je mimo obvyklí jednoduché "cesty k bohatství", bude za tím nějaká čertovina, která to celé urychlí.
No - na vydávání certifikátů nikdo nezbohatne tolik, jako na výrobě operačních systémů či virtuální měně, úspěšném internetovém obchodě a podobně. A existují i tací, kteří dělají věci úplně zadarmo (třeba přispívají do Linuxu) - a vůbec nejsou hloupí.
Nicméně to není asi důvodem ten názor natolik zatracovat. Nechť tu tedy v klidu sbírá obyčejná odmítnutí, mírný nesouhlas či podiv.

To poslední tvrzení může být pravdivé - přijde na to, jaké dřevo.
Však také kdyby ta tvrzení byla jen nepravdivá, měla by alespoň nějakou hodnotu. Když jsou náhodná, tj. jsou mezi nimi i pravdivá nebo částečně pravdivá, jsou úplně k ničemu.

Pokud vás tolik zajímají jiné pohledy, tady jich pár zcela zdarma máte. Myslím, že vám budou úplně k ničemu.
(...)
Lidská kost je pevnější než dřevo.

Lidská kost, pevnost v tlaku asi 200 MPa.
Dřevo, pevnost v tlaku asi 25 MPa.

vis jak to boli baseballovou holi? :)

Je to sice OT, ale myslim ze bys byl u vetsiny drev dost prekvapeny. Tech 25MPa je spis pro mekky dreva, smrk a podobne.

Tako tohle mne rozsekalo :-D:
Rok na Zemi má ve skutečnosti 400 dní, těch chybějících 35 dní všichni lidé spí a vlády pořádají své nekalé rejdy.

Nastastie su aj ine prehliadace ako chrome. Ja osobne som ho mal do nedavna nainstalovany len koli niektorim webom s flash obsahom, pretoze ho nativne podporoval. Od chvile co umrel flash je mi chrome k nicomu.

Tym ze by chrome aktivne blokoval http1 bez tls by si len pod zadkom odpilil dalsiu vetvu...

Reálně ale jiné prohlížeče než Chrome, Edge, Safari a možná někde hluboko za tím Firefox relevantní nejsou. Může nás to zlobit, můžeme na to nadávat, ale nic na tom nezměníme.

Mimochodem cílem prohlížečů celkem očividně není udělat web použitelný třeba pro malého vývojáře webu nebo dokonce i pro firmu produkující prohlížeč samotnou. Jinak by např. Google Docs a Google Maps nepřecházely na rendering pomocí canvasu a dalších obezliček, které řeší to, že DOM je příšerně pomalý a zbugovaný, SVG je ještě horší a CSS se vlastně dá používat na řadě míst jen těžko, protože tam prostě chybí dost esenciální věci, které si místo toho lepí lidi sami na koleni. Na všechno do JavaScriptu se tahá modul, přitom spousta věcí mohla být prostě vyřešena přímo v prohlížeči a nemusela se tahat spousta knihoven při načítání webu. Místo toho, aby se zlepšil JavaScript se vymýšlí další komplexita typu WebAssembly apod.

Ano, ty nové technologie mají řadu výhod, ale i tu cenu další komplexity a vlastně chybějící robustnosti v řešení, které je všude etablované. Dalo se říct, takhle vypadá nějaký higher Intermediate Language (IL), který se JIT nebo dokonce AOT kompiluje do nějakého browser-specifického lower Intermediate Language pro vykonání. Buď můžete poslat JavaScript/ ECMAScript, který se za běhu bude kompilovat, nebo můžete poslat ten hIL (což je do určité míry dnes WebAssembly). Mělo to ale být tak, že ten JavaScript je implementovaný nad tím specifikovaným Intermediate Language a browser nebo serverová implementace může třeba dělat věci jako za běhu vyměňovat funkce podobně jako to dělá Clojure nad JVM. Mohlo to výrazně zjednodušit vývoj softwaru a zredukovat komplexitu. Místo toho se prostě všechno tak nějak lepí a minimálně to působí dost nekoncepčně.

Co se týče TLS (HTTPS) tak je to podobná katastrofa jako vývoj webu samotného. Hodně věcí se přeci jen za poslední roky zlepšilo, ale pořád je to dost tragické. Třeba rozjet pořádně (s certifikační autoritou) TLS ve vývojovém prostředí (třeba na localhostu) je docela porod. Potom člověk hned narazí, že třeba u mobilů přidat certifikační autoritu je taky zážitek, jsou tam další složitosti. Ano, každá je třeba na pár minut, ale je jich v součtu dost a ono se to posčítá. Např. Content Security Policy, HSTS, Secure attribut Cookies a různé další technologie může člověk reálně testovat jen pokud má TLS řádně rozjeté. Je to prostě celé dost neohrabané a default je stále používat při vývoji HTTP, takže nástroje pro vývojáře TLS a věci kolem, např. komfort vývoje řeší až sekundárně. Takže pro uživatele je asi TLS/ HTTPS na současném webu +- přínosem, ale pro vývojáře to je netriviální dávka práce navíc, pokud to chce dělat pořádně a většina toho (pokud browser nebude křičet) spadá do kategorie "nice to have" ale ne něčeho, za co by normální zákazník byl ochotný za službu zaplatit víc (nebo to bylo rozhodovací kritérium).
Všechno to je tak složité, že věci kolem toho řeší miliony řádků kódu, utápí se do toho člověkoroky práce a potom se i přes všechno testování a jakoby kritický provoz najdou bugy typu Heartbleed, ale to je jen špička ledovce. Přitom TLS a věci okolo by vlastně mělo být něco takového, čehož implementace se aktualizuje jednou za 5 let pro podporu nějakého na prolomení těžšího algoritmu nebo tak, ale ne protože tam jsou chyby. Všechno tohle začíná tím, že někdo navrhne jazyk s komplexní syntaxí, které je těžké parsovat nějak rozumně a tedy bezpečně. Místo toho se vymýšlí složité jazyky typu ASN.1, které už absencí kanonické implementace signalizují, že jde o projekt typu "vyžer si to radši sám". Potom se to ideálně narve do byrokratického výmyslu typu X.509 a psychosomatická oddělení mají o pacienty postaráno.

HTTPS pro vývoj se ovšem nemá řešit tak, že si místo nestandardního localhostu na HTTP zavedete nestandardní vlastní certifikační autoritu. Mnohem lepší je mít certifikáty od uznávané certifikační autority. Můžete je mít zdarma, nakonfigurujete to jen jednou a máte hotovo.

Děkuji za reakci. Ano, můžu do /etc/hosts resp. C:\Windows\Sys­tem32\Drivers\et­c\hosts přidat alias s nějakou doménou na localhost adresy a potom si vydat certifikát na tuto standardní doménu. Potom ale pořád ještě nemám ale certifikát, protože např. LetsEncrypt se na ten počítač prostě nepřipojí a tedy neověří vlastnictví.

Rád bych se poučil, jak byste to řešil pro 5 vývojářů, kteří každý jsou v jiné síti a chtějí z různých důvodů vyvíjet lokálně na svém počítači. (Třeba kvůli většímu komfortu.)

Myslím, že v dnešní době je minimálně při vývoji absolutně standardní provozovat nějaký HTTP server na localhostu, cokoliv jiného je myslím ve značné minoritě, ale i zde se rád nechám poučit.

ACME umožňuje certifikáty ověřovat přes DNS. Takže je úplně jedno, kde běží a odkud je dostupný váš vývojový HTTPS server.

Ano, ACME dns challange znám. Můžu samozřejmě odněkud plnit DNS a vystavovat potom certifikáty (takže infrastruktura navíc), potom to plnit do gitu v požadovaném formátu, aby se to dostalo až na počítače ke všem vývojářům a do konfigurace jejich lokálního serveru. To mi nezní náročností nějak bezvadně oproti skriptu, který jednou za rok pustím a třeba klidně i ručně ten certifikát nahraju...

Kdybych to své řešení neměl už hotové a plně funkční, dalo by se o Vámi navrhovaném řešení možná polemizovat. Přijde mi ale, že pro náš účel to má výrazně vyšší počet bodů, ve kterých se něco může pokazit. Obě řešení zákazníkovi nepřináší žádný užitek, protože se vlastně patláme v infrastruktuře, kterou on nikdy neuvidí a neocení. Vámi nastřelené řešení závisí na více aktivních komponentách a má tedy potenciál se spíše zhroutit, vyžadovat monitoring, updaty apod. a tedy zabít více jinak vývojového času a energie.

Mimochodem nemáte pravdu s tím, že je úplně jedno, kde ten HTTPS server může být. Možná vzhledem k CA. Pořád se musí domluvit (klidně i nepřímo) s DNS na tom, že se bude vytvářet nový certifikát, resp. musí nějak ten nový certifikát obdržet. Rozdíl je, že HTTPS server nemusí mluvit s LetsEncryptem (nebo jinou CA). Oproti lokálnímu skriptu, který se světem nepotřebuje komunikaci žádnou to je dost rozdíl - to vše pro pro vývoj diskutabilní výhody jakoby důvěryhodné certifikační autority.

Mimochodem posledně jsme tu měli docela košatou diskuzi na téma CSS a lepičů ze světa browserů a standardizačních uskupení. V OrgPadu už jsou animace předělané, zde je trochu detailní porovnání: https://www.youtube.com/watch?v=WcfdAnyOomM a zde je víc takový přehled: https://www.youtube.com/watch?v=y84YjYh_AoU

Z technického hlediska tam jsou tedy pružinové animace, které se spočítají diferenciálními rovnicemi live při každé akci. Rendering spojů je předělaný do canvasu, protože v browserech neumí udělat rychlý a nezbugovaný rendering SVG (což máme přímo od lidí, kteří o tom spolu s lidmi z rendering týmu Chromu píšou knížku). Na dost místech se obchází řada abstrakcí, protože prostě neúnosně žerou výkon. Výkon, použitelnost a dynamická estetika OrgPadu se těmito změnami dost podstatně zvedla. Ještě máme pár chybiček, které musíme opravit, ale stav, který je teď je v celku z našeho pohledu prostě mnohem lepší než bylo předtím, tak jsme to dali ven. Bylo to nakonec taky o dost víc práce, protože se sahalo na mnohem více věcí, než se původně předpokládalo.

Pokud se někdo živí vývojem webu, doménu snad má, takže nepotřebuje platit nic navíc. I pokud by chtěl použít jinou doménu a musel ji tedy platit navíc, je to zanedbatelná částka. Nevím, co chcete plnit do gitu a jaké problémy máte s infrastrukturou. Obnova certifikátů přes ACME se řeší automaticky, když to jednou zprovozníte, nemusíte na to sahat. Přičemž zprovoznění v nejjednodušších případech neznamená žádnou práci navíc – v případě moderních serverů prostě jen spustíte server a o zbytek už se postará sám. Problémy jsou (klasicky) s nedostatkem IPv4 adres – pro vývoj asi nebude používat veřejné IP adresy, takže pak musíte pro ten server ještě nakonfigurovat přístup do DNS (a musíte mít poskytovatele, který je serverem podporován).

Když si řešíte certifikační autoritu sám, musí s ní váš server také nějak komunikovat (byť to třeba znamená jen ruční zkopírování souboru). Ta vlastní certifikační autorita má ovšem tu nevýhodu, že její certifikát musíte dostat na všechna zařízení, která budou na váš server přistupovat. Vývojářské prohlížeče, mobilní telefony, testovací prostředí, prostředí uvnitř Dockerů apod. A pořád pak nemáte standardní prostředí – nebudete mít certifikáty na Certificate transparency listu, například. A otázka je, jak moc standardně budou vypadat vaše certifikáty a certifikát CA – třeba co se týče nastavení různých atributů. Aktuálně to sice většinou nehraje roli (až na SAN, hashovací algoritmus a platnost), ale to se může změnit.

Zkrátka používání vlastní CA je slepá vývojová větev, hodně svázaná s IPv4 – a je otázka, proč se jí sveřepě držet.

My nemáme problémy s infrastrukturou, nechceme jen zbytnou infrastrukturu navíc. Kód se spravuje v gitu, ostatní vývojáři asi chtějí nějak se k certifikátu dostat, aby jim chodilo HTTPS na jejich lokálním HTTP serveru provozovaném na localhostu. To funguje všude, když vypadne internet, když vypadne proud, pořád se dá na laptopu několik hodin dál vyvíjet. A není to hypotetická situace, za poslední 2 roky jsem ji zažil několikrát a bylo to během produktivních hodin.

Naše CA kromě OCSP a Certificate Transparency má zbytek absolutně standardně. Platnost na 10 let je asi úplně v pohodě, takže tohle opravdu řešíme jen při nastavení nového zařízení (případně hypoteticky při ztrátě/ krádeži, ale všechna jsou samozřejmě šifrovaná). Ke zbytku už jsem se vyjádřil. Prostě na současný stav techniky to bohatě stačí - je samozřejmě otázka, jaký další security theater a komplexitu si akademici okolo bezpečnostni navymýšlí někdy v budoucnu.

Vlastní CA samozřejmě není nikterak s IPv4 svázaná, nebo podle čeho to poznám, když je v SAN možné uvádět i IPv6 resp se převážně používají DNS záznamy?

Díky Clojure není potřeba Docker nebo jiné obezličky řešit - zase komplexita navíc, která se nám zatím nevyplatí. Postaví se .jar a prostě se nahraje přes SSH automatizovaně na server. Někdy v budoucnu třeba kontejnerizace bude menší zlo, ale teď to prostě potřeba není.
Prostě nemáme potřebu používat nějakou technologii, knihovnu apod., jenom protože se o ní hodně mluví a je jakoby nezbytná a strašně in. Pokud má pro nás jasný přínos a minimální negativa, rádi si ji osvojíme i když není třeba úplně nutná.

Pořád nevím, proč měl být certifikát a privátní klíč pro můj lokální server ve sdíleném gitu. Stejně tak nevím, proč by výpadek internetu měl nějak ovlivnit vývoj na lokálním počítači, kde mám uložené všechny potřebné soubory včetně privátního klíče a certifikátu.

Sám jste napsal, co má vaše CA nestandardně – a pravděpodobně toho je daleko víc.

Vlastní CA není svázaná s IPv4, ale je to důsledek lokálních domén, které jsou zase důsledkem nedostatku IPv4 adres. Kdyby byly všechny počítače standardně připojené do internetu, jak to bylo zpočátku zamýšleno, málokdo by měl potřebu komplikovat si život lokálními doménami a lokálními CA. Pravda, u těch CA byl dříve problém i v ceně, ale nějaké řešení by se pravděpodobně našlo, kdyby po tom byla poptávka.

Ohýbáte použité technologie a tvrdíte, že se vám to momentálně vyplatí víc, než je používat správně. To je vaše věc, jenom si dejte pozor na to, abyste nezaspali dobu. Vůbec nejde o používání technologií jen proto, že se o nich mluví. Jde o to vědět, co máte ohackované, uvědomovat si to a hlídat si, kdy vám ty hacky začnou způsobovat víc problémů, než kolik toho jimi vyřešíte.

:-D :-D :-D :-D :-D