Mohl by mi někdo technicky zdatný vysvětlit, jak je možné, že se tyto certifikáty vydávají zdarma, i když jsou s tím spojeny tak vysoké náklady?
Mě to připomíná Cloudflare, který je do velké části zdarma, ale za cenu skrytého šmírování, jelikož čte veškerý provoz (pokud se použije SSL od nich a Cloudflare slouží jako DNS). Od té doby, co jsem ten koncept Cloudflare pochopil, tak jsem vše od nich zrušil.
Máte na jejich stránkách v FAQ https://letsencrypt.org/docs/faq/#what-does-it-cost-to-use-let-s-encrypt-is-it-really-free
V podstatě dostávají dary od sponzorů. Sponzoři jsou obří firmy jako Google, Amazon, Cisco atp. https://www.abetterinternet.org/sponsors/
Díky. Asi jsem ale trochu paranoidní, protože ve FAQ je to pro mě jen taková částečná odpověď. Jaksi nechápu, co z toho sponzoři mají, hlavně Google, když sám je certifikační autoritou a vydává vlastní uznávané certifikáty. Škoda, že se prohlížeče od nějaké doby rozhodly ukazovat neuznávané certifikáty jako nebezpečné a stránku vůbec nezobrazí (místo aby byla třeba jen jiná ikonka vedle URL).
To varovani rozhodne skoda neni. Nic vam prece nebrani si pridat do seznamu duveryhodnych CA vlastni autoritu. Ikonky a zamecky moc nefunguji, timhle si uz historicky vyvoj prosel. A nejak signalizovat uzivateli, ze se deje neco potencialne nedobreho je potreba... to, jestli velke varovani zafunguje je vec jina. Ale porad je to lepsi, nez nedelat nic.
Jak se to vezme… Pokud jde jen o přenášený obsah, tak ano. Ale kdyby prohlížeče automaticky akceptovaly vadné certifikáty a jen zobrazily varování, umožnilo by to bez dalších opatření krást cookies, local storage, otrávit cache apod. Ano, šlo by to řešit, v zásadě by stránka načtená se špatným certifikátem musela mít separátní prostor (cookies, local storage, cache, same-origin policy…), pak by to mohlo být tak nějak bezpečné. Ale asi celkem komplikované na implementaci (=> riziko zavlečení zranitelností) a zároveň s minimálním přínosem (platný certifikát většinou admin zvládne vyřešit).
Zadne jak se to vezme ... selfsign cert je radove bezpecnejsi a neda se pomoci nej provoz smirovat. Coz je presne ten duvod proc to ty korporaty plati.
Zato DANE browsery neumi, protoze pres to se smirovat neda. Coz je opet ten duvod proc to browsery neumi.
Chroma zilla na to ma ostatne uz nejakych 25let nereseny bug. Ten se sice netyce primo dane ale souvisi s nim (jde o podporu srv zaznamu, coz taky neumi). Zato se za tu dobu nejmin 5x menilo logo ... a ITci jsou z toho tak nadseni, ze podil sel z 50% na 0.
Pokud vas tak moc trapi certificate transparency, nic vam nebrani pouzivat treba wildcard certifikaty (a nejakym toolingem vyresit interni distribuci), zeano :-) A jinak samozrejme co samotny browser naprasi neni vazane na to, jestli pouzivate self-signed certifikaty, ci nikoliv.
A pokud jste takovy echt paranoik pres soukromi, pak se divim, ze vubec pouzivate i DNS... :-) To se smiruje mnohem snaz... kdekoliv po ceste.
*puts on tinfoil hat*
Benefitů je určitě víc, ale masivní rozšíření https prakticky zabilo http proxies. Přenos mezi serverem a klientem je vždy 1:1 (neskončí to v nějaké cache po cestě), takže server může lépe sledovat chování (prokliky) a žádný filtr z toho např. neodstraní reklamu. Protože má většina uživatelů Chrome, Google má tímto zajištěnou autoritu nad celým webovým supply chainem. Poslední "problém" k vyřešení jsou adblockery v prohlížečích, ale na tom se taky pilně pracuje (Manifest V3 atd).
Když jsme u těch tinfoil hatů: hele co všichni při vydávání certifikátu schvalujeme:
3.10 Indemnification
You agree to indemnify and hold harmless ISRG and its directors, officers, employees, agents, and affiliates from any and all liabilities, claims, demands,
damages, losses, costs, and expenses, including attorneys’ fees, arising out of or related to: (i) any misrepresentation or omission of material fact by You to ISRG, irrespective of whether such misrepresentation or omission was intentional, (ii) your violation of this Agreement, (iii) any compromise or unauthorized use of Your Certificate or corresponding Private Key, or (iv) Your misuse of Your Certificate. If applicable law prohibits a party from providing indemnification for another party’s negligence or acts, such restriction, or any other restriction required by law for this indemnification provision to be enforceable, shall be deemed to be part of this indemnification provision.
To je tedy populární ustanovení u mnoha internetových služeb. Znamená to tedy, že se pak budete za někoho někde v USA soudit a platit mu právníky.
To je běžná praxe, takto vypadá prakticky každá webová aplikace: máte pár aplikačních serverů, server na statické soubory, a nakonec load balancer ve kterém je uzavřen TLS tunel ke klientovi (HTTPS k prohlížeči).
Těmi zabitými proxies jsem myslel hraniční proxy cache, kdy např. v podnikové síti byla jedna, u ISP další, atd. takže kdo mohl a chtěl, měl prohlížení webu mnohem rychlejší. Stačilo že jeden člověk v síti navštívil nějakou stránku, a všichni ostatní už to pak měli rychlejší, protože jejich požadavky k dalekému serveru vůbec nešly. V době kdy celá škola měla jednu duální ISDN to bylo nezbytné :-D
Dnes je každé spojení šifrované, takže proxy nemůže např. obrázky nebo videa podržet někde blíž, všechno jde až k primárnímu zdroji. Řeší se to CDN a datacentrem v každém koutě planety, ale to je v gesci provozovatele služby. Když mi Meta nedá blíž datacentrum, tak já jako ISP nemám jak svým ovečkám zrychlit odezvu instáče :-)
To není vůbec pravda, absolutní většina obsahu je plně statická, většina jsou totiž videa. Podíl všeho ostatního je zanedbatelný, a je jedno jestli je to statické HTML nebo dynamický server-side rendering. V HTTPS je každý stream šifrovaný s PFS, takže přestože se celá škola kouká na to stejné tiktok video, tak mi to tam jede pro každého zvlášť z venku.
Tohle skutečně řešíme v praxi: ZŠ a SŠ s 600 dětmi v krajském městě, o přestávkách nám saturují konektivitu a vidím jasně že to je několik set spojení do 1-2 CDN, každé spojení přenese jeden z několika identických počtů bajtů. Tj. v kterýkoliv moment se celá škola dívá třeba jen na 5 různých videí, ale nám to saturuje 10Gbit downlink. Keška by se mi prostě líbila, dává to smysl. Prostor je :-)
Data můžou být šifrovaná a/nebo podepsaná, ale PFS to rozbíjí. Nejde mít na hranici least-recently-used cache s bloby jako to dělají distribuované filesystemy (např. IPFS), všechno se musí tahat znovu a znovu z internetu.
5 ruznych videi a saturovany 10Gbps downlink? ;-) Ze by jeden bezny videostream mel 2 Gbps mi prijde jako... nejaka zjevna blbost.
Mimoto bych cekal, ze wifinu pro zacky mate oddelenou a tudiz samostatne riditelnou. A ono nemusite zackum dat celych 10Gbps, ze? Ono bezne veci jako youtube si ten bitrate bez problemu upravi.
3. 2. 2025, 09:57 editováno autorem komentáře
bych řekl, že je asi jedno, jestli to udělá 8Mb/s nebo 16Mb/s, protože v tom nemáš režiji, 10GbE downlink ti zpravidla také neposkytne 10Gb/s, že jo.
O tom právě Jakub Štech píše, kdyby mohl ten provoz cachovat, tak 5 videí není problém, ale když to každý uživatel stahuje ve vlastním streamu, dělá to obří provoz.
Ze zkušenosti bych ale řekl, že těch videí bude mnohem více a že ta lokální cache nemusí být pro tu vlnu na přestávách dostatečná. Ty videa bývají krátká.
Realita je takova, ze kdyz je tech cumilu moc - bez ohledu na kapacitu linky, tak prehravac si ten bitrate si snizi... aneb hledame problem, kde neni. Proste deckam se na te wifi "na blbiny" vyhradi nejaka kapacita, a at se o ni poperou. A samozrejme si necham dost na to, aby mi tu linku ven neucpali tema blbinama a vedle fungovaly veci opravdu potrebne pro vyuku.
V realu je i ten konstrukt o poctu videi neopreny o data - jak muze vedet, ze tech videi je fakt jen 5? A neni jich... no treba 300? :-) Vzdyt na kvalifikovane posouzeni by musel videt az na uroven URL... coz by videl mozna v casech "s proxy" (ktere jsme v tech casech umeli i transparentni, ze? ;-) ). Ono treba i automaticky generovany playlist bude fungovat obdobne, jako vyhledavani - kazdemu bude sypat jine personalizovane vystupy. I "obsahove" stejne video muzou byt v realu nezavisle videa, ze jeden "obsah" je tam nahrany nekolikrat taky neni nic neobvykleho.
"Ze zkušenosti bych ale řekl, že těch videí bude mnohem více"
Jenze ono je jedno jesli 5 nebo 10 nebo 50 ... furt je to radove lepsi dat do lokalni cache, protoze jak tu zaznelo, typicky to jedno video budou chtit videt vsichni. Jina vec samozrejme je, jestli ma skola delat ISP. Kdyby totez generovali na tu jednu BTSku na ktery visej, tak by jim to op/rodicove rychle zatrhli.
Jenže ani to video není tak úplně "statické", protože spousta těch přenosů stahuje video podle připojení v různé kvalitě. Plus tam může být i víc formátů, to video může mít další ochrany proti neoprávněnému přehrávání, takže každý stream může být unikátní, protože je nějakým způsobem ještě šifrován. Plus bych přidal, že spousta mladých lidí kouká na nějaké live streamy. Představa, že všichni koukají na stejný obsah je dosti naivní. To, že koukají jenom na 5 různých videí je jenom vaše představa a nemáte to nijak podložené. Ta cache by musela být dost velká, aby obsáhla ty videa a dávala nějaký smysl. Pak by bylo taky zajímavé, co by se tím vlastně ušetřilo a jestli by to vůbec, kvůli ušetření trochu trafficu, stálo za to.
Když mi Meta nedá blíž datacentrum, tak já jako ISP nemám jak svým ovečkám zrychlit odezvu instáče :-)
Tak to zrovna (pokud nejste uplne maly ISP) nemusi byt nutne pravda - da se domluvit peering, nebo ze cache pro FB CDN bude ve Vasi siti - kouknete sem https://partners.facebook.com/network/app/ - ostatni velci poskytovatele to nabizeji v nejake podobe take.
Vybavil se mi rack kdesi v usti jak pod nejakym vetrakem na hrebiku mezi mikrotikem a supersmejdcro je tam cache server od mety.
Uz schazi jen zvaro a mistni sberaci kovu ve vedlejsi ulici a kupky slamy valici se mezi snradem z chemicky.
Cesko je zeme malych ISP. Casto takyisp bez vlastni ASN.
Vlastni cache bez sance.
Já si myslím, že velkým technologickým firmám došla trpělivost s tím, jak se tady zacházelo s TLS certifikáty. Najednou to kvůli bezpečnosti začala být skoro povinnost pro weby a běžně se certifikáty vydávali ručně přes nějaké webové rozhraní, posílali se do emailu a váleli se všude možně, což zrovna není ta nejlepší cesta pro něco, co je klíčem k obsahu přenášených dat.
Několikrát se tohle téma nakouslo na usenix konferencích. Tipuji, že právě vznik lets encrypt pro dostupné a zdarma vydávání certifikátů je právě na to odpověď.
A co z toho mají? Jednodušší život pro sebe a své uživatele a tím i výrazně nižší náklady. Když se podíváš na ty sponzory, jsou to velké IT/online společnosti, ti potřebují aby jejich služby a internet by obecně penetrovaný úplně všude, což jde blbě, dokud to je pořád hodně nebezpečné prostředí (myslím technicky).
Aneb řečeno, na co ti je super nákupní centrum, když k němu nevede osvětlený bezpečný chodník... Tak zaplatíš a vymyslíš nový chodník...
Nie ze by som bol proti automatizacii, ktoru priniesol ACME, ale co presne je nebezpecne na certifikatoch v emailoch a valajucich sa kde tade?
Pointa certifikatu predsa je, ze je to verejna cast klucu. Ked je nasadeny, vie ho kazdy ziskat priamo z prislusneho weboveho serveru. To, ze bol povodne zaslany emailom jeho bezpecnost nijako neznizuje.
Bezpecnost by ohrozovalo, keby bol zasielany aj privatny kluc. Ten by ale po spravnosti CA nikdy ani nemala vidiet, mala by vidiet iba certificate signing request. (Ze ho CA umoznovali generovat na svojich webovych portaloch a potom stiahnut je uz na dalsiu debatu).
Platnost dva roky a válí se po emailu? Nemáš naprosto žádnou kontrolu nad tím, kde ten certifikát nakonec může skončit.
Do emailu se posílaly běžně právě i ty soukromé klíče a jen jen podepsaný certifikát. Ano, právě to generování klíčů u CA byla šílenost.
Ono ani na serverech to nebylo kdovíjak uklizené, jak to nikdo nemusel řešit, tak to neřešil, certifikáty rozkopírované všude možně, volně čitelné všemy procesy na serveru, zpravidla to byly nějaký SANy se spoustou domén pod sebou.
Prostě tomu oboru chyběla nějaká automatizace, aby se tohle mohlo vše pročistit. ACME je to automatizací a jde vidět, že se to dnes výrazně pročistilo i v místech, kde se na to běžně dlabalo. Myslím, že cíl byl splněn.
Cloudflare zdarma je myšlen pro měnší projekty, jako třeba mé webovky. Mají pěkné API a poskytne to DDoS ochranu + třeba offline cachovanou verzi. A o co přesně u mých webovek přijdu? Netečou tam supertajná data, ze kterých by byl Cloudflare nadšený. Jakýkoli placený plán potom už podporuje možnost, že není DNS správcem celé domény, ale dá se to dát jen pro subdomény.
A proc do jedne bramboracky michate gapps a cloudflare? ;-) Kdyz kazda vec ma jine uziti?
Faktoru, co duveru zakazniku snizi muze byt cela rada - treba i to, ze ten vas server neni vecne dostupny, protoze sebemensi pokus o DDoS tu vasi aplikaci proste polozi. Ano, bud vrazite sve prostredky do vlastniho reseni... a nebo za par dolaru to nechate udelat nekoho jineho, kdo se na to specializuje. A nebo neudelate nic, protoze na to nemate (know-how, penize)... budete se rigidne drzet svych zasad a zakaznici vam utecou nekam, kde jim to na hubu nepada ;-) Takze tak.