Názory k článku Certifikáty pro HTTPS zkrátí postupně do roku 2029 svou životnost na 47 dní

Jeden certifikát v naší firmě = 8 € (cena za schválení a podepsání). Jen tam, kam vidím já, je takových 22, což při dosavadní roční rotaci dělá nějakých 176 € (cca 4.500 Kč) nákladů.
Při zkrácení na 47 dní ty náklady vzrostou na osminásobek, a pokud připočítám, že změna musí být dříve, než pár minut před vypršením, tak minimálně na desetinásobek. Což znamená odhadem 50 000 Kč jen za certifikáty každý rok (plus práce těch, kteří to udržují).

A nesmím zapomenout, že každý zásah je spojen s rizikem, že se ta výměna nějak nepovede a něco se rozbije.
Dlouhodobě máme tenhle typ chybovosti někde kolem jednoho procenta, což dávalo jednu chybu za cca 5 let.
Ale pokud se něco rozbije každých pár měsíců, těžko budeme managementu vysvětlovat, že spolehlivost našich služeb je závislá na automatických scriptech a od dob ručního zpracování klesla.

Tak třeba někdo u vás už dojde k tomu, že 50 000 Kč ročně za certifikáty je moc a proces se změní. A bude vás to stát v průměru třeba 10 Kč ročně. A nebo ne a budete to dělat dál za těch padesát tisíc – to je ale váš problém.

Zajímalo by mne, jaké máte zkušenosti s korporátním prostředím. ;-D

Spíš očekávám argument: náklady stouply a protože to nemusíte dělat ručně, propustíte někoho z teamu.
Navíc píšu jen o té (malé) části systému, kterou vidím. Ve skutečnosti těch certifikátů bude násobně více - a stále jich přibývá, jak roste složitost a propojování systémů s různými cloudy a AI funkcemi.
Ono samotné vygenerování nebude tak složitý problém, jako (bezpečná) distribuce a nasazení. Drtivá část těch systémů není zvenku dostupná a ani nemá na internet přístup.
(A to píšu jen o těch externích certifikátech, počty těch interně vydaných jsou mnohonásobně vyšší.)

Jak "externí" tak i interní certifikáty jdou přece generovat a nasazovat automaticky? V našem "korporátním prostředí" takhle řešíme stovky domén a to napříč všemožnými technologiemi. Co je překážkou u vás?

15. 4. 2025, 09:02 editováno autorem komentáře

Byrokracie a centrálně řízené procesy.

" jdou přece generovat a nasazovat automaticky"

Fakt? Okamzite si te najimam ale pocitej s tim, ze jestli tohle nezvladnes, budu pozadovat smluvni pokuty v 8mi cifrach.

Tak ale komu se chce ručně měnit certifikáty. To je nějaký masochismus?

Určitě je to v náročném prostředí, které popisujete náročné všechno udělat správně a bezpečně. A teď to celé automatizovat vyvolává frustraci. Na druhou stranu myslíte, že ruční distribuce a vyřizování certifikátů má přidanou hodnotu pro firmu?

"Na druhou stranu myslíte, že ruční distribuce a vyřizování certifikátů má přidanou hodnotu pro firmu"

To mi rekni, japa automaticky zjistis, ze ten system, co je slozenej z 10 ruznych serveru (databaze, weby, ...) a stovek servis ... po restartu vseho kvuli vymene certifikatu ... taky jeste aspon nejak funguje.

hlásím se k tomu, že jsem už v několika korporátech (ještě spadající pod ZoKB) tenhle problém vyřešil či jeho řešení navrh (a pak si realizovali sami).

Veřejné SSL certifikáty nemají co dělat v interní infrastruktuře, tam dominuje interní CA s vlastními pravidly. Veřejné SSL zůstanou pak jen na nějakých hraničních F5 a zbytek sítě o nich neví, v F5 jejich aktualizace je levná.

A pokud jde o bezpečné propojování těch hromady divných zvířátek na zemi, ve vzduchu a ve vodě, tak opět, SDN, tunelování, brány a balení komunikace do transportní vrstvy. I to se dá dělat transparentně v korporátním prostředí.

Co je ale důležité, tohle málokdy dokážeš prosadit interně, potřebuješ externí společnost, která je najata ne governance/au­dit/security a tyhle pravidla prosadí navzdory střednímu managementu. Což s příchodem NIS2 se to daří poměrně široce implementovat a ty zatuché vody vylepšovat.

Spousta ruznych uzasnych frikulynskych aplikaci vyzaduje "duveryhodny" certifikat === ten verejny. Interni do nich bud nedostanes nijak, nebo rozhodne ne nijak automaticky, pokud to vubec jde, je treba to vsemozne hackovat.

Zkus si jen udrzovat v provozu takovou pitomost jako pristup k mailum ze schnilych jablek ... kazdej pulrok to prestane fungovat a prave to ze se tomu z nejakyho duvodu znelibi certifikat je jeden z duvodu.

Zajímalo by mne, jaké máte zkušenosti s korporátním prostředím. ;-D

Už vám někdy někdo řekl, že tam nemusíte pracovat? Tyhle otázky typu: "jaké máte zkušenosti s X" mě fascinují od chvíle, kdy jsem v roce 2006 vyšel z Univerzity Palackého.

V první firmě jsme ve 3 lidech (ne 300, ne 300tis) za 14 měsíců připojili na tehdy začínající internet v ČR. Jeden expert na sítě, já jako expert na linux schopen nastavit celou síť jen díky dokumentaci toho experta a k tomu skvělej kluk z učnáku, který uměl perfektně vrtat do betonu klidně metr široký a protáhnout tím 10x UTP cat5e kabely.

Z každého klienta jsme měli čistý zisk 200Kč měsíčně. Za 16 měsíců x 400 klientů to znamená 1.280.000Kč čistého zisku pro tři zaměstnance! Průměrné náklady na instalaci: cca 500Kč, klient zaplatil 2000Kč. Na počátku se koupila jedna pořádná vrtačka, několik beden CAT5e kabelů (takže třeba 5km kabelů na našem skladu). Tedy 50 000Kč na počátku a bez problémů to vydrželo na 5 let. Ta vrtačka vrtá dodnes (19 let!). Vrtáky se kupují za pár stovek a vydrží rok. Takže průběžné náklady max 10 tis ročně.

Potom jsem ve 4 lidech dělal weby. Naučil jsem se PostgreSQL, linux a sítě jsem uměl. Potom jsem se naučil WordPress. Instalace serveru pro web pro klienta hotová ručně za 20minut. Včetně https (od roku 2012 standard, pro nás). Grafik nafotil pěkné obrázky, učitelka češtiny připravila článek a web byl za jeden den na světě. Zákazník (firma), ráda zaplatila třeba 50tis. Takže čistý zisk pro firmu o 4 lidech při 20 webech do měsíce 1 milion měsíčně.

Takže na co korporát? V úplně nejhorším případně potřebuješ 5 lidí na vše. Elektrikáře s platným certifikátem od TIČR, SSL certifikáty jsou zadarmo (už před vznikem LetsEncrypt), naskriptovaná instalace virtuálky nebo potom kontejneru (LXC, Systemd nspawn, nebo klidně i free verze Virtual Box nebo vmware) hotova do 5 minut. Klonování existující template mašiny nebo prostě Ansible, klidně i vyladěný bash skript to umí. A externí OSVČ účetní, který dělá účetního po emailech pro 50 firem.

Jestli si někdo v roce 2025 stěžuje na to, že v korporátu do nejde, tak celý můj profesní život od roku 2006 dokazuje, že korporát není potřeba vůbec na nic. Ale jestli chcete za certifikáty platit 50tis. a musí to trvat 3 měsíce, tak to klidně plaťte a čekejte měsíce na cokoliv.

20. 4. 2025, 20:11 editováno autorem komentáře

Budeme to delat za 50kkc jeste 10 let nez vyprsi smlouva. A nebude pak vanocni vecirek.
Nebo bude. Ale u ohne, s poezii v ruce a rozladenou opalenou kytarou misto zive kapely.
Svede se to na IT ze neumi byt efektivni i kdyz oni nerozhodovali o vydavajici CA.
To rozhodli CISO s CIO a jejich "novymi kamarady" na golfovem hristi za Dubaji.
A jake mate vy zkusenosti s korporatem?

15. 4. 2025, 12:50 editováno autorem komentáře

Proč by jste měl ročně platit 50 000? Jak to chápu já tak po stránce financování nebudou větší změny.

Certifikační autority už delší dobu přechází na model "Subskripce" (Jak to má například ZeroSSL) nebo předplacení certifikátů - koncák si koupí certifikát na určité období jak tomu bylo doteď, jen si ho musí pravidelně obnovovat. Koneckonců to jde vidět i dneska, když si otevřete kteroukoliv certifikační autoritu, uvidíte možnost si koupit certifikát i na delší dobu než 1 rok, většinou až na 5 let - to neznamená že vám CA vystaví certifikát na 5 let, ale že máte na dalších 5 let zaplacenou obnovu certifikátu.

15. 4. 2025, 08:40 editováno autorem komentáře

Co si náš zahraniční vlastník vybral, to používáme... Ale třeba na tu subskripci taky dojde - za těch cca 10 let je to stihnutelné.
Nicméně větší problém vidím té automatizaci. To není za současných (bezpečáckých) podmínek vůbec možné.
Navíc těch certifikátů dost přibývá, a hrozí, že jedna chyba rozbije pořádný kus sytému.
Už vidím, jak budu každou chvíli vyplňovat NIS2 hlášení, že kus kritické infrastruktury zase nešel, protože jakýsi script, který nemám pod kontrolou, nestihl ověřit organizaci při obnově certifikátů, takže se nestihla distribuce a rozpadla komunikace...

tak to budú musieť prehodnotiť prístup aj bezpečáci. Preto sa ohlásila táto zmena dopredu, aby sa o tom vo firmách začalo hovoriť. Vašou úlohou je len posunúť túto infomráciu ďalej na vyššie miesta aby sa o probléme začalo čo najskôr hovoriť a jeho riešenie sa zaradilo do plánu. Jasné v korporáte sú postupy pomalé a komplikované, ale ak ide o peniaze tak vrcholový menežment na to počuje a bude riešiť ako zvýšiť efektivitu.
A že prestane dávať zmysel jedna pozícia čo celý rok robí len výmenu certifikátov je prirodzený vývoj. Buď sa nájdu iné úlohy ktoré prinesú firme ešte vyšší zisk alebo jednu pozíciu zrušia, to už záleží na kondícii spoločnosti. Svet je proste taký

Dokud je to ta výměna jednou do roka, je to prkotina, která stojí pár mandayů za rok. Tady to půjde směrem: přibude práce, ale až se to zautomatizuje, tak vám jednoho sebereme.

Zacalo hovorit ... se zacne hovorit? Odkdy se neco udela na bazi "se zacne hovorit?"
Budto nekdo neco udela protoze dostane ukol nebo ne.
Tim ze "se zacne hovorit" se nic neudela.
Pak jeste funguje PDD. Pruser Driven Development.

Nedelame oba dva pro stejny korporat? Nebo nemely nase korporaty stejne bezpecnostni konzultanty?

Jasně, a proč je předpoklad, že placení certifikátu zůstane stejné?

Je pravděpodobné, že se bude platit ročně, podobně jako u jiných produktů. Možná ale nepůjde o roční, ale o měsíční platbu. Takže ano, dá se očekávat zdražení, ale nemyslím si, že by bylo tak katastrofické, jak zmiňuješ.

Predpoklad je ze to nebude napriklad pomerna mesicni cast treba z rocni castky ale kdyz to sectete bude to trochu vice.
A jeste muzete zaokrouhlovat centy :-)))
Protoze to zvysi load systemu, auditoru, nakladu na vyvoj a komunikaci supportu ktery bude resit vetsi naval proc XY na prodluzovani zas nejde.

Pak musite jeste zamestnat tymy konzultantu kteri za nejake vsimne pomohou zakosum s migraci - tj. vyrobili jsme na schuzi problem a my vam s tim pomuzeme za vyhodnou cenu.

Je mi lito, ale k tomuto tematu nemam co bych technicky dodal. Je to jen politika a valky prohlizecu.

Chceme-li to vyresit tak oprasme myslenku DNSSEC+DANE.

15. 4. 2025, 15:30 editováno autorem komentáře

"oprasme myslenku ...DANE"

To by neslo, pres to se smirovat vazne neda.

Jasne, takze to ze to neumis a bude te to stat prachy je logicke. Ale rozhodne za to nemuze cena certifikatu...

Ta cena za rok zustane stejna, neboj. Jen budes mit 9 certu.

Trochu se bojím toho, že se tak z LE stane ještě víc single point of failure pro slušnou část internetu. Ne že by nebyl už teď, ale času na řešení případných problémů když spadne/změní obchodní podmínky bude daleko méně.

A jaký je vlastně scope, v nadpisu je HTTPS, pak v textu TLS - hádám že z toho nevyklouznu s tím že cert chci pro ne-http server (i když proč ne? konzumery jsou v té organizaci jen výrobci browserů), ale týká se to i vydavatelů klientských certů (ICA, Postsignum)?

To bude velká redakční zkratka. U tls certifkátů pro jiné služby než https bude záležet na chování klienta. Ono pro hodně klientů je vrchol bezpečnosti už to, že ověří vydavatele certifikátu. :) Takže tam bych žádné velké změny nečekal. Osobní certifikáty jsou úplně něco jiného (jiný účel).

K monopolizaci LE -- stačí když vznikne jiná entita podporující ACME protokol (ten je otevřený) a přechod k ní je pak jen otázka konfigurace.

Jiné certifikační autority s podporou ACME samozřejmě existují, například Buypass a ZeroSSL.

Existují, což o to, ale jaký mají tržní podíl, a zvládly by migraci půlky zákazniků LE k sobě během toho cca měsíce?

LE není jediná autorita, která podporuje ACME protokol, a není ani jediná, která vydává certifikáty zdarma. Ta doba platnosti je dohoda CA/Browser Fóra, takže „závazné“ je to jen pro webové prohlížeče. Ostatní se tomu mohou přizpůsobit, ale nemusí.

Každopádně se to týká jen serverových certifikátů pro TLS, potvrzujících vlastnictví domény (nebo IP adresy). Jiných typů certifikátů (např. osobní) se to netýká.

Ostatní se tomu mohou přizpůsobit, ale nemusí.

Pokud ty certifikáty prostě budou mít takhle krátkou platnost - a jiné vám CA nevystaví - tak jediným možným přizpůsobením může být tu dobu platnosti prostě ignorovat.
A to mi rozhodně nepřijde rozumné.

Bude nutne ;-) ... no ja to vyresil self signet certifikatu na 10 let tolik k bude muset ;-)

btw. ta sranda, nektere certifiklaty vyzaduji opravdove prasarny a mame na to profil v AD !!! ano az tak, jinak neprojde ;-)

A ted ta prdel, ma to management server, kde to funguje - ten jsme ale zrusili, nebot uz neplatime support ;-) ale diskove pole ma svoji spravu - jo tak ta podepsany certifikat ani nevezme ...

BTW ten managemnet server mel tez svuj certifikat, kdyz jsme se pidil proc --- tak procedura je vedela, nebot se to dela rucne v konsoli, kde ale nemate vsude pristup, nebot je to omezeny shell, a ty certifikaty se tam buldili primo do nejakych java balicku ;-) -- toi ze ma neco hodne prikazu z mnoha parametry vubec nevadi, dalo by se to nejak scriptovat - i kdyz je to nepdorovane a vlastne tim ztracite zartuku, ale u scriptu navic by asi nikdo neprostestoval - no jenze je to prece HPE enterprise resenio ;-)) ... takze to nefunguje a musi se tam veci opakovat a resit rucne, cekat a overovat ze uz neco dobehlo ... nebot vas command dobehl ... ale na pozadi se pak dely dalsi veci ... a zadani dlasiho prikazu z dokumnetace to mohlo zhroutit ... zato generace self signed cert. kupodivu fungovala ;-)

Jo co takhle WSAPI pro vmware ;-) - tam mame tez 10 let silef signed - proc ? protoze se to taky muze seknout a pak se musi restarovat cely vcenter ;-) ... a mezi tim nespustrite, nepridate zadnou VM - ty co bezi bezi - ale expiruje certifikat a je honec ... nakonec to vmware vyresil - jo ja taky zrusiol jsme vsechny vvol a presel zpet na ciste FC a ne ze to ma sice FC ale dela si tam sparvu pres vvol ... cili je snazsi prijmout rucne certifikat, nez to kazdy rok obnovovat ... jo a ta prdel tahle sluba na poli jako jedian vyzaduje po zmene certifikatu restart ... i kdyz tvrdili, ze uz jej pouziva, CURL nam rekl teda neco jineho ... dokumnmetace taky nerikal, ze je treba sluzbu restartovat - no coz uz, restart je rychly a nic neovlivni ... jo a pri vymene cert nadikovem poli je treba vzdy refresh i ve vmware ;-) je kurna jedno, ze je podesana, je treba refresh ... no a byla tam chyba, ze refresh nemuzel probehnopu a bylo treba to smazat a vytvoruit znova a kdyz nepomohlo ani to, tak reboot VC ... chyba ze se to opravovalo v postgreesql databazi uz jsem s tim nezazil, ale i to v dokumentaci vmware bylo ... to jen tak, ze takovy certifikat je vsude snadne vymenit a jako to budete automatizovat a jak vymenim diskove pole za 600.000 EURO -- to spise nakopu Apple nekam , a s rozbehem ;-) - konec koncu v AD a na svoji cert. autorite si muzu delat co chci - jen doufam ze security tym neprijde a tak jako nam zakazal vlastni autoritu,, nema nezakaze 1 a 2 rocni cert v AD - pak totiz zacneme ignorovat security ... v kubernetes si konec koncu delaji cert. vlastni a duveruji sami sobe ...

Ale u aplikaci, ktere jedou pro klienty a jsou nekde venku to problem nebude, tam uz je to vyresene davno o tom zadna - tam je to na profi urovni.

Jo a pro opravdu stare enterprise veci mam stary firefox - uz sec., rvali ze musim smazat starou javu - poslal bych je dopr* nebot neni nainstalovana ale je v te portable apce ;-)) ... ale uz ji nepotrebuji, uz jste nekdy videli diskove pole EMC VNX ? ... tak tam bezi windows ... jako ze fakt, proto jsme nikdy nechtel EMC a nikdy nedovolil jeho nasazeni - no zde jsem to zdedil ;-) ... a k te je je jen javaws konsole, ano to co podporuje jen stara java, nova ne a jen stary firefox - ktery ten stary plugin podporuje - to same certifikace - stare cert. jsou preskocit jen ve stare verzi FF ... nastesti uz to nepotrebuji, nebot vse stare uz jsme zmigrovali - ne ze by nas trapily tyhle veci, ale support uz by stal fakt balik a spolehlivost by se uz taky nezlepsovala ;-) ... jasne produkce byla uz davno zmigrovana, ale na devops se setri a je to tak vlastne spravne

"ja to vyresil self"

Ma to jen takovou drobnou potiz, ze aplikace ti s tim nebudou fungovat a zhorsuje se to den ode dne.

Co je to za HPE vec? Tak treba hpe ilom zvlada renewal pres SCEP.
Ale admini maji pohackovane leccos. Prakticky neexistuje pro IT oddeleni 'bezpecna" konfigurace.
WSAPI je naprosty hnuj dekuji nechci a VMware umre zrejme vlastni "cenovou" vahou.
Bezne mi ale chodi reporty kolik lidi ma starou javou nebo kde vsude bezi dedikovane terminal win servery s IE a activex na izolovane siti.

17. 4. 2025, 09:00 editováno autorem komentáře

Vmware se vratil s free ESXi ... duvod je jasny, vsichni mali zmigrovali k Proxmox - tim padem se tam objevuji i placeni zakaznici, Proxmox ma vice penez na vyvoj a hrozi, ze to zdokonali tak, ze vmware bude mit konkurenci ;-) ... nemaji podporu vice clusteru - tak uz delaji datacenter manager - ale jen to 0.1-Alpha ... pokud vyresi poradne zdileny FC storage, tak ma vmware vazny problem ;-) ... podle, me by tam mohli dat gfs2 nebo jeho klon z Oracle ... a Vmware uz nam i zdelil, ze planuji zlevnit ...

Mi jim totiz rekli, ze od nich asi neodejdem, ale ze je omezime na maximum, tedy dockery pujdou na zelezo, obsluzne servery na KVM - na 3 servery s tiom, ze nebudem resit migrujici storage - tyhle ridici nody je mozno vypinat pri maint. ... pody/dockery nezjimaji nikoho, ty se spusti znova ... a male site mozna pujdou na neco jineho

Kdyz na to tak koukam treba jeste nastane renesance DANE :-)

DANE je pouze pro SMTP

DANE je navrženo jako obecný mechanismus pro TLS. Také jeho DNS záznam se jmenuje TLSA, což je zkratka pro TLS Association. DANE se zatím výrazněji prosadilo jen u předávání pošty, to je pravda. Ale vůbec to neznamená, že je vázané jen na poštu a že se nemůže prosadit i na dalších místech, kde se používá TLS, což je třeba i HTTPS.

Poprosil bych jmenovat jeden browser ktery to umi? ...

V bugzille foxe je na to tema nereseny bug stary 25+ let. Ten sice neni specificky o dane, ale o srv, coz je exaktne totez.

Prostudujte si prosim co znamena pojem "renesance". Doplnte pojmy "politika" a "ekonomie"
DANE is odpiskaly firmy a organizace ktere stoji za browsery a CA businessem. Tezko lze ocekavat ze by si pod sebou podrizly vetev.

Pokud podporu DANE do browseru bude vymyslet CA/B forum, tak bych se celkem bal, aby se pak nemusel kazdy tyden menit KSK a ZSK, aby to browser akceptoval ;-)

DANE je mrtvé, to se už nikdy nechytí

DANE je bohužel závislé na funkčním DNSSEC. Což lze na straně autoritativních serverů zajistit docela dobře, ale na straně klientů je to velký problém. Spousta koncových sítí je rozbitých a ty DNS záznamy prostě nedostanete. Naději dává trochu DNS-over-HTTPS, kde si potřebné informace prohlížeč vyzvedne někde v internetu sám a vyhne se problémovému lokálnímu resolveru, ale je otázka, jestli to tvůrci prohlížečů dotáhnou ke stoprocentní spolehlivosti, aby to bylo použitelné jako plnohodnotná náhrada za PKI, které funguje všude.

" závislé na funkčním DNSSEC"

ne, neni.

ma to jen dva problemy ...

1. bez DNSSEC nebude duveryhodne
2. bez DNSSEC nebude duveryhodne

Je to sice jedna vec ale tak dulezita, ze jsem si to dovolil zminit dvakrat

Ale je, přímo v prvním odstavci RFC 7671 je napsáno: DANE relies on the DNS Security Extensions (DNSSEC). Právě pomocí DNSSEC je zajištěno podepsané předání veřejného klíče v záznamu typu TLSA. Podpis autority v certifikátu nahrazuje právě DNSSEC. Bez něj je to jen textový záznam o veřejném klíči, který je možné libovolně po cestě podvrhnout.

DNS v koncovych sietach je z pohladu DNSSEC "rozbitych", pretoze kopec DNS software stale DNSSEC nepodporuje. Od Samby v AD mode po he.net DNS.

Preskakovat/ig­norovat lokalny resolver vo vybranych aplikaciach je cesta do pekiel; rozbije viac, ako pomoze.

No, ale když se ale podíváte mimo naší českou kotlinu, tak je rozšířenost DNSSEC naprosto tragická. Tam ani DoH nepomůže (a to, navíc, má docela nehezké privacy implikace...)

Je to tak, to jsou právě hlavní nevýhody DANE, které není možné přehlížet. Ono to vypadá jako velmi dobrý nápad, ale ta závislost na DNSSEC to sráží do nepoužitelna. Na tomhle nikdo příčetný nechce postavit třeba bezpečnost bankovních aplikací. Mrzí mě to, taky by se mi něco takového líbilo.

Ma nekdo moznost vyzkouset treba posledni Safari prohlizec v kombinaci s internim certifikatem, ktery ma platnost 825+ dni a byl vytvoren alespon 2023/2024? Viz treba https://support.apple.com/en-us/103769.

Imho ja v tom zadnou vyssii bezpecnost nevidim - spise naopak - pokud nekdo bude chtit napadnout distribuci privatniho klice, bude vedet, ze to bude pravidelne, takhle by musel cekat 1 rok - cele je to ukazkova stupidita a buzerace.

To me taky takhle jednou otravoval vyrobce SW az jsem presel na cracklou verzi - a uz me neotravuje ... jo a mam to fakt koupene ;-)

Ja bych se SW nebal, staci jim otevirat na tyhle veci tikety, ze to nefunguje a amji to opravit a oni uz na to udelaji workaround, ala duveruj tomuto certifikatu a overuj si jej lokalne, nebo uprava min. firefoxu - kde to daji jako feture - neco jako kdyz nejkakou *** napadlo odstratnit z firefoxu zakazani strance odebrat pravy klik a ridit mys ... no tak si to zase kazdy zapne a uz na to jsou i rozsireni

Zakazal google rozirenil, co umi stahnoiut neco z YT ? - nauzil jsme vsechny YT-DLP ... a nebo jdownloader atd. - vsechno jde, kdyz se chce ;-)

Co se cert. tyce tam zalezi, zda jde jen o otravovani zakazniku a vytriskavani penez ... kdo rika ze nevznikne rozsireni, co bude podprovat cert. autoritu, co vydava cert. na 2 roky ;-) ... a nebo vsichni pujdou na free autority a vyresi si automatizaci

Postup napadení distribuce privátního klíče:

1. Zařídit, aby dotyčný takový nesmysl jako distribuci privátního klíče začal provádět.
2. Na ten vlastně nikdy nedojde.

kdo rika ze nevznikne rozsireni, co bude podprovat cert. autoritu, co vydava cert. na 2 roky ;-)
Já to říkám. TLS je totiž o několik úrovní jinde, než kam mohou rozšíření prohlížeče.