Názory k článku Google chce omezit platnost certifikátů na 90 dnů, změna zřejmě přijde brzy
-
Neviem, mozno sa na to zle pozeram ale nevidim dovod extremne skracovat platnost certifikatov. 10 rokov bolo vela ale aj tych 10 rocnych sa dalo zbavit pdoobne ako to urobil Apple so Safari. Plus nikto pricetny necakal 10 rokov na ani jeden strane. Bud ich prestal akceptovat alebo vymenil za nieco novsie. To sa aj dialo.
Ak pride nejaka horzba, tak nikto nebude cakat kym automat nepoziada o tyzden novy certifikat. Plus, ci ten automat bude k niecomu, lebo dana sluzba/zariadenie nemusi zvladat novy typ certfikatu.
Z mojo pohladu vidim potencialne rizko pri extremne kratkych certifkatov. Co ak sa nieco udeje so systemom vydavani certfikatov? Extremen kratkymi certifikatmi si vieme podpilit konar pod sebou.
Plus co usetrime na revokaciach to pridame na zvysenom objeme vydavani certfikatov a automatizacii.Vlastne co tym vyriesime? Mame tu Let's Encrypt a 90 dnove certfikaty ale ved od nich si viem ziskat certifikat bez problemov na v podstate cokolvek rychlo a jednoducho. Vdak nim asi kazdy sifruje ale to je tak vsetko.
-
DannyStříbrný podporovatelPrecitajte si to znovu :-) Ne, zbavit se jich jednoduche neni. A ani Apple neni takovy buldozer, ktery by na hulvata zrusil platnost drive vydanych - lec stale platnych - certifikatu. Nova omezeni se vzdy zavadela pro nove vydane certifikaty...
Co za riziko tam je? Jestli jsou to tri mesice nebo ctrnact dni je uz vlastne z pohledu obnovy fuk, to stejne resi automat. Muzete mit klidne paralelne dve nezavisle CA, ze kterych si ten certifikat ziskate, kdyz chcete byt opravdu paranoik.
Revokacni seznamy moc nefunguji, to je proste fakt. Mate jine reseni? Od CRL se udelal pokus smerem k OSCP, ale v srpnu 2023 z toho CA/B vycouvalo a pokorne se k CRL vratilo. I pres jeho zname mouchy...
Ano, ucelem je vyresit sifrovani - protoze nic "navic" realne take nefunguje... zelene zamecky se jmenem firmy u EV certifikatu? Hahaha, to BFU stejne nezkouma. Co vic nez zasifrovani transportu tam od toho certifikatu cekate?
-
> Co vic nez zasifrovani transportu tam od toho certifikatu cekate?
No ja som povodne od certifikatov ocakaval ze skutocne certifikuju kto so mnou komunikuje takze minimalne ked som na nejakom webe banky alebo platobnej brany tak sa tam pozriem a certifikacna autorita naozaj oznaci ze majitelom je banka X alebo skutocna platobna brana nie nejaky fake web. -
DannyStříbrný podporovatel
A to je presne ta vec, co nikdy poradne nefungovala ;-) Jako byste to z praxe neznal, lidi ochotne odklikaj i neplatnej certifikat, jen aby se nekam dostali a je jim to fuk. To, ze jsou nakonec jinde nez chteli zjisti az pote, co se fakt stane nejaky pr*s*r... no a ze si to par geeku opravdu zkontroluje to nevytrhne.
-
Je rozdíl, když tam někdo kliká z neznalosti a někdo s vědomím že si nutně chce třeba přečíst blogový zápisek a nebude tam zadávat žádné informace.
Otázka zabludišťáka:
co byste si vybral kdyby bylo na výběr:
1. HTTP
2. https s neplatným certifkátem (expired)
3. totéž ale certifikát na generické jméno hostingu
4: totéž ale na zjevně divné jméno certifikátu (TLD jako .click,.store,...)
5. totéž ale https s špatnými šiframi(případně jen volba 1 vs 2-5)
-
Filip JirsákStříbrný podporovatelJe rozdíl, když tam někdo kliká z neznalosti a někdo s vědomím že si nutně chce třeba přečíst blogový zápisek a nebude tam zadávat žádné informace.
To není rozdíl, to je v obou případech neznalost.Něco jiného by bylo, kdyby si někdo nutně potřeboval přečíst cokoli, co někdo může podvrhnout na adrese blogového zápisku. V takovém případě ale zase není potřeba řešit neplatný certifikát a stačí si přečíst něco z
/dev/random. -
Smazaný profil
tak jasně, budu si chtít přečíst blogísek o vaření, ale s neplatným certifikátem nebo přes http jsem ohrožen podvrženým receptem, který mě speciální vražednou kombinací mouky, másla a tří vajec otráví a s ohledem na osobní bezpečnost raději vygeneruju mnohem bezpečnější recept podle /dev/random....
13. 9. 2024, 08:35 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
To, že upečete sraženou buchtu údajně podle receptu uznávaného šéfkuchaře, je ten menší problém. On to ale může být také blog uznávané osobnosti o tom, zda investovat či neinvestovat do bitcoinu, do čeho jiného investovat, jak danit příjmy z bitcoinu, jak se vyvíjí válka na Ukrajině, že nějaký politik udělal nějaký přešlap. Že jsou to drobnosti? Ano, jsou, ale když se těch drobností sejde spousta… Proč asi Rusko podporuje lidi, kteří šíří bludy o ploché Zemi, chemtrails, o neexistenci globální změny klimatu, proti Green Dealu? Protože jim jde především o to vytvořit chaos, aby lidé nedůvěřovali institucím ani sami sobě navzájem.
-
Smazaný profil
vy se tu snažíte tvrdit, že nedostatečně zabezpečený přenos je nepřekonatelný problém za všech okolností, tak jsem vám ukázal, že fakt neni. Šířit bludy můžete i na webu, který aktualizuje certifikát každou hodinu. Motat do diskuze o certifikátech plochou zemi a chemtrails už je na návštěvu odborníka.
-
Filip JirsákStříbrný podporovatel
Ne, pokud vám na přenášeném obsahu nezáleží, pak nezabezpečený přenos problém není. Akorát je pak otázka, proč chcete přenášet něco, na čem vám vůbec nezáleží.
Šířit bludy samozřejmě může i web, který má zabezpečený přenos. To ale nevyvrací, že by web, který bludy nešíří, měl používat zabezpečený přenos, protože jinak informacím na webu uvedeným nemůžete věřit.
Vy jste komentář do této diskuse také psal s předpokladem, že ostatní uvidí právě to, co jste napsal, a ne něco jiného.
-
Když by browsery podporovaly DANE, tak by revokaci mohl udělat vlastník certifikátu odstraněním záznamu v DNS. Pro takové certifikáty by se pak klidně mohla zachovat dlouhá platnost.
Ostatně tenhle princip se používá u SMTP, viz RFC 7678
SMTP servers cannot expect broad Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) support from SMTP clients. As outlined above, with DANE, compromised server or trust anchor keys can be "revoked" by removing them from the DNS without the need for client-side support for OCSP or CRLs.
-
DannyStříbrný podporovatel
No, ano... ale to by si kaprici (CA/B) vypustili svuj rybnik a to bohda nedopusti :-) Protoze v ten moment by nebyly potreba komercni CA... s DANE si muze kazdej provozovat vlastni... to uz holt s technikou nic spolecneho nema (reseni je uz dlouho), to je uz jenom politika (nektere zajmove skupiny o takove reseni nestoji).
-
No, takže máme problém, nechceme ho opravdu řešit, tak vymyslíme pseudořešení s postupným zkracováním platnosti v principu nevyhovujícího systému. Takže dneska na 90 dní, za půl roku na 60 dní, za rok na 30 a nakonec budeme obnovovat certifikáty po 60 sekundách...
A pak teda možná přejdeme na online ověřování s tím, že stejně budou existovat CA, které vydají doménový certifikát komukoliv, kdo má kontrolu nad kořenem webové prezentace, takže budeme mít zcela důvěrnou komunikaci se zcela nedůvěryhodným podvodníkem (podobně jako když Google odmítá ze svých služeb odstranit zjevně podvodné reklamy na investování s ČEZem, protože "jejich podmínky" inzerent prý neporušuje).
No nevím, jestli je tohle opravdu řešení problému, nebo spíš typické "papírově něco děláme, aby to vypadalo, že chceme problém řešit, což reálně nechceme, ale vytvořením dalších byrokratických překážek to aspoň skrýváme". V reálu si myslím, že Google jen testuje svou sílu a vliv na globální internet.
11. 9. 2024, 08:10 editováno autorem komentáře
-
No taky to tak vidím...
OK - deset let platnost certifikátů je blbost, roční je ideální. Tam, kde je vysoké riziko zneužití ať si to stáhnou klidně na 21 dní nebo 10...
Ale netuším proč musím co 90 dní měnit certifikáty, kam mi ve výsledku stejně leze jen dodavatel... Ta logika mi prostě uniká... Zbytečně to věci komplikuje, přestože není třeba tam mít tak "ostré" lokty. Možná by se měli zamyslet k čemu ten certifikát ten uživatel vlastně potřebuje a podle toho dělat délky platností,,,
-
Filip JirsákStříbrný podporovatel
Pokud se nainstaluje certifikát té CA jako důvěryhodný (do systému nebo do prohlížeče, podle toho, odkud je prohlížeč bere), tak ne. Bude důvěřovat té autoritě, a na certifikáty od lokálních autorit (těch, které si doinstalujete sám) se ta pravidla o platnosti certifikátů nevztahují. Podobně byla dlouho výjimka na SHA-1 certifikáty – certifikáty vydávané oficiálními autoritami už nesměly používat SHA-1, ale certifikáty vydávané lokálními autoritami mohly SHA-1 dál používat.
-
Filip JirsákStříbrný podporovatel
Apple tvrdí něco jiného:
This change will not affect certificates issued from user-added or administrator-added Root CAs.
-
Filip JirsákStříbrný podporovatel
To bola az druha zmena, to pisu o skrateni platnosti na 398 dni. To sa netyka prvej zmeny, nastavenia limitu 825 dni, ten stale plati.
Ano, bavíme se o té lhůtě 398 dní. Pardon, pokud jsem to napsal nejasně – není to tak, že by pro interní certifikáty neplatila žádná pravidla, ale ta pravidla nejsou tak přísná, jako pro veřejné autority. Respektive ta pravidla se nejprve vynucují u veřejných autorit (přes CA/Browser Forum), teprve později se začnou uplatňovat i u interních autorit. -
Filip JirsákStříbrný podporovatel
toto znie ako use-case pre vlastnu CA
Není. Za prvé tím přiděláte práci i dodavateli, musí dostat váš certifikát mezi důvěryhodné certifikáty na svých zařízeních. V jednodušším případě do systémových úložišť, ve složitějším přímo do aplikací.Co je ale důležitější, bezpečák dodavatele by měl instalaci certifikátů vaší autority odmítnout. Protože v praxi se nepoužívá omezení, pro které domény může která CA vydávat certifikáty. Nebo-li když dostanete certifikát své CA jako důvěryhodný do nějakého systému dodavatele, můžete pak tím certifikátem podepsat třeba doménu google.com, a systém dodavatele tomu certifikátu bude věřit. Nevím, jestli máte s dodavatelem tak dobré vztahy, aby vám až takhle věřil…
-
Filip JirsákStříbrný podporovatel
Já těch 90 dnů považuju za dolní hranici toho, co dává v současné podobě smysl. Protože certifikát je z principu něco, co stvrzuje stav v nějakém okamžiku a předpokládá se, že to bude platit i nějakou dobu v budoucnosti.
Pokud je potřeba záruka, že provozovatel webu je oprávněným držitelem domény právě teď, nedává smysl spoléhat se na certifikáty s delší dobou platnosti, ale je potřeba ty informace přenášet přes DNS, aby byly stejně aktuální, jako DNS. Tj. použít protokol DANE. Protože z tohohle pohledu je 14 dní stejně dlouhá doba, jako 90 dní. Pokud se chci na HTTPS certifikáty absolutně spolehnout a řešit i případy, že někdo prodá doménu nebo unikne privátní klíč certifikátu, pak je mi jedno, jestli se někdo bude moci prokazovat neplatným certifikátem 14 dnů nebo 90 dnů – i těch 14 dnů je dost na to, aby mohl napáchat škody.
-
poté přišel Apple a svou vlastní silou rozhodl, že od 1. září 2020 nebude jeho prohlížeč Safari důvěřovat certifikátům vystaveným na dobu delší než 398 dnů
Je to jen nešťastná formulace nebo opravdu šli tak daleko, že by odmítli třeba i týden starý certifikát jen proto, že má "příliš dlouhou" platnost? To by totiž bylo ještě nesmyslnější než to svévolné omezení platnosti na 90 dnů.
-
DannyStříbrný podporovatel
Ze by se konecne nasadilo IPv6? ;-) Na zabiti argumentu "neni verejna IP" to je relevantni argument - i kdyz samozrejme vim ze v ceste budou dalsi prekazky, pocinaje firewallem na tom routeru.
-
Ok, teoreticky by mohl prohlížeč udělat sken síťových zařízení, vytáhnout si routy a porovnat co kam směřuje. Ale už to není tak jednoduché jako 10/8, 192.168/16, 172.16...
Krom toho, třeba Vodafone (ex-UPC) přiděluje IPv6 pomocí DHCPv6. Ale nejspíš to bude mít podobný vzor.
Každopádně se ta logika komplikuje.
-
Dost by mě zajímalo, jestli někdo mysli na domácí uživatele.
Dovolím si kacířskou myšlenku: skutečným motivem podobných opatření vůbec není bezpečnost, to je spíš záminka a PR. Ve skutečnosti je to spíš snaha o větší "industrializaci" oboru, tedy potlačení DIY řešení a malých hráčů. Ideálem je dosáhnout podobného stavu, jaký už v podstatě máme u e-mailu, kde provozovat vlastní MTA je jen pro silné nátury a pro malou firmu je to pořád ještě zatraceně těžké, aby to nějak ekonomicky fungovalo, takže je skoro každý nucen koupit nebo pronajmout komerční řešení od velkých hráčů. Teď je tu holt snaha dosáhnout téhož i u webu.
A co se týká těch domácích krabiček, tam už to stejně delší dobu směřuje k tomu, že místo toho, aby se s nimi komunikovalo přímo, krabička i vy se připojíte na nějaký server výrobce, jakkoli je to absudní, když jste ve stejné lokální síti. (A nezřídka to ani nejde ovládat přes webové rozhraní, jen přes "apku".)
11. 9. 2024, 08:35 editováno autorem komentáře
-
...místo toho, aby se s nimi komunikovalo přímo, krabička i vy se připojíte na nějaký server...
Tak tohle je presne ten duvod, proc u kazdeho access pointu menime firmware. Kvuli tomu jsme museli opustit TP link, protoze ty od jiste verze nesly preflashovat. Nastesti Ubiquiti jde preflashovat, takze jsme presli na Ubiquiti. -
Michal ŠmucrBronzový podporovatel
Přesně to mě taky hned napadlo. Hlavně u tohoto typu zařízení, kde výrobce třeba zapomene na nějaký rozumný fallback mechanismus pro alternativní přístup k administraci, pokud vyprší platnost certifikátu. Například když zařízení bude z jakéhokoliv důvodu offline (ať už úmyslně, nebo nějakou špatnou konfigurací) a prostě se nepovedou aktualizace.
Věřím, že nějaký zkušenější uživatel s tím třeba poradí, dostane se tam browserem, kde to půjde ignorovat atp. Ale když vidím okolo sebe uživatele, kteří ani nemají počítač a vše řeší hybrid appkami na tabletu a telefonu, které používají nějaké integrované web view ze systému. Těm se v horším případě nestane nic, v lepším případě tam bude někde půlmilimetrovým písmem hláška ERR_CERT_INVALID.Ne že by tam už teď nemohl tenhle problém nastat (už jsem něco podobného viděl), ale s navrhovaným zkrácením platnosti se může výskyt ještě násobit.
Navíc mi to obecně přijde v tomhle typu zařízení jako další zbytečný time bomb a jen to zvýší závislost na podpoře od výrobce, případně zkrátí životnost toho zařízení, pokud už poskytovaná nebude. -
Filip JirsákStříbrný podporovatel
Tohle ovšem není chyba certifikačních autorit, nýbrž tvůrců routerů (a ISP). Podle mne by každý domácí router měl mít funkcionalitu ACME proxy, tj. měl by umět protokolem ACME zajistit vystavení certifikátů pro zařízení ve vnitřní síti (zařízení by komunikovalo ACME protokolem s routerem, ten by ACME protokolem zajistil vystavení certifikátu u zvolené CA).
K tomu by to ještě chtělo, aby ISP delegoval svým zákazníkům nějakou doménu 3. či 4. řádu, kterou by obhospodařoval právě ten domácí router. Takže uživatel by doma používal tyto DNS názvy (typicky jen hostname, zbytek by doplnil router). Je smutné, že se v roce 2024 pořád považuje za normální, že domácí uživatel bude používat IP adresy pro přístup ke svým zařízením.
Dříve takhle ISP poskytovali e-mailovou schránku nebo malý prostor na webhosting, takže poskytovat takhle doménu by nebyla zas až taková novinka a bylo by to užitečné.
-
Filip JirsákStříbrný podporovatel
Zkuste komentář, na který reagujete, dočíst až do konce. Nebudete se pak ptát na věci, které jsou tam vyřešené.
-
DannyStříbrný podporovatel
Nemate, viz komentar nize ;-) To je teoreticke plkani, ktere by v praxi nefungovalo. Nebo fungovalo stejne dobre, jako CRL.
-
DannyStříbrný podporovatel
A jinak to s DNS je absolutni blbost, to fakt nikdo delat nebude. A buhvi jak by to fungovalo. Ono staci vzpomenout, jake problemy dost casto maji i jen blbe interni resolvery - a to i u velkych ISP. Predstava, ze budou provozovat rozumne fungujici infrastrukturu s rozumne bezpecne fungujicimi dynamickymi updaty.... je detinska ;-) Ale nic vam nebrani takoveho ISP provozovat a svetu predvest, ze to jde...
-
Filip JirsákStříbrný podporovatel
Mohl byste používat jen hostname (bez celé domény) a nechat DNS resolver doplňovat název domácí domény. Navíc na domácích zařízeních asi moc odkazů v interních konfiguracích nemáte. Pokud má někdo složitější domácí síť, použil by svou doménu (kterou takoví lidé obvykle stejně mají).
-
DannyStříbrný podporovatel
No, to vam nebude fungovat ani v tom prohlizeci. Kdyz tam zadate jedno slovo (aka hostname), tak vas to instantne prehodi na vyhledavac 🤣 Ach tyhle teorie....
-
Filip JirsákStříbrný podporovatel
Příště si to radši nejdřív vyzkoušejte, ať nepíšete takové nesmysly.
-
DannyStříbrný podporovatel
Ja to vyzkousene mam. Chrome i Firefox minimalne na Linuxu instantne provede presmerovani na preferovany search engine a o DNS lookup se ani nepokusi. Pletete si prohlizec s prikazovou radkou - tam to funguje, ale tu bezny franta uzivatel nepouziva, ze? :-)
-
Filip JirsákStříbrný podporovatel
Mně Vivaldi na Windows posílá normálně dotaz na DNS server, i když do adresního řádku zadám jen hostname, bez domény.
-
DannyStříbrný podporovatel
Fajn, takze jste si nasel prohlizec se statisticky zanedbatelnym poctem uzivatelu (a to i proti Firefoxu, ktery je na tom bidne, ale zdaleka ne tolik) a tim argumentujete 🤣
-
V desktopovém Firefoxu jdou takovýhle věci přepnout na původní chování:
https://www.reddit.com/r/firefox/comments/re99w3/what_is_with_firefox_war_on_intranetslocal_domains/Bohužel Firefox pro Android už odstranil about:config, takže je na pokročilejší věci nepoužitelný a lidi přechodem na majoritní Chrome o nic nepřijdou :'-(
-
Jirsak ma pravdu, ale chce to splnit bud vypnut vyhladavanie pre adresny riadok, alebo zadat http(s)://hostname pretoze inak browser nevie o tom ze ma ist na hostname, rovno to da vyhladavacu. Ano pouzivam vivaldi a vyskusal som si to aj vo firefoxe a nedalo mi nainstaloval som si aj chrome a spravanie je rovnake ....
-
Tohle není pravda.
Já mám v práci na PC nastavený v resolv.conf "search" a v prohlížečích Firefox i Chrome mi jednoslovné názvy krásně fungují.
Dokonce jsem si to kdysi zkoušel odchytávat: prvně DNS dotaz na jednoslovný název, pak dotaz na název s připojenou search částí a teprve potom Google či jiný search engine.
-
Názor zajímavý, ale co provedení?
http01 asi nepůjde, protože NAT, a jak docílit vystavení výzvy přes dns01? Navíc na nějaké .local doméně, která je rezervovaná s tím, že se nesmí objevit na internetu, podobně jako jisté rozsahy IP adres...
Domácí router s ACME proxy by musel mít buď veřejnou IP (kvůli http01) nebo přístup k modifikaci DNS nějakého poskytovatele, což asi úplně běžně nechce žádný poskytovatel, snad kromě dynamicDNS systémů...
-
Filip JirsákStříbrný podporovatel
Právě že by to nebyla žádná .local doména, ale normální veřejná doména. Pokud někdo nemá svojí, dostal by nějakou doménu třetího či čtvrtého řádu od svého ISP. A tuhle doménu by ISP delegoval celou klientovi, takže ten by si tam pak mohl vytvářet záznamy dle libosti. Dělal by to skrze domácí router – když by připojil nové zařízení, na routeru by mu dal název a router by to vypropagoval do té domény. Ať už pomocí DDNS nebo nějakým nově vzniklým protokolem.
-
DannyStříbrný podporovatel
S temi certifikaty by to porad nefungovalo, Protoze certifikat je na FQDN a cele hostname s domenou 3/4 radu by fakt nikdo nevypisoval. Plus je tam problem s tim vyresit funkcni (a bezpecne) delegace... zrovna DDNS udelat bezpecne v "large scale" fakt zadna legrace neni. Predpokladam ze s tim jen teoretizujete ;-)
-
DannyStříbrný podporovatel
Ano, ja vim ze protokol existuje... ale udelat to bezpecne - tak aby jeden klient treba nemohl menit zaznamy jineho klienta uz zas tak trivialni neni - krom jineho to chce TSIG nebo TLS klic pro kazdeho klienta (router) a prislusne omezit prava, kam ktery klic muze zapisovat... a tam uz jen vyreseni jejich distribuce nebude uplna stouracka v nose ;-) Ono u podobnych vykriku se na bezpecnost rado zapomina...
-
Filip JirsákStříbrný podporovatel
Omezit to, aby uživatel mohl aktualizovat jen své DNS zóny, umí každý poskytovatel DNS služeb. Zas taková věda to není.
A co se týče autentizace – ISP musí vědět, kterého klienta do své sítě pustit a kterého ne, kterému povolit jakou rychlost, komu má účtovat přenášená data. Takže identifikovat klienta umí ISP také docela dobře.
Technicky to není žádná raketová věda. Dalo by se to ohackovat se současnými protokoly, dá se pro to navrhnout nový protokol (třeba pro tu aktualizaci DNS z routeru by se asi hodilo vytvořit něco založené na HTTPS, než to řešit skrze DNS protokol).
Jediný problém je v tom, že by bylo potřeba, aby to začali podporovat ISP (alespoň nějaké kritické množství) a výrobci routerů (alespoň nějaké kritické množství).
Na druhou stranu, současný stav, kdy se tváříme, že mají uživatelé doma normálně používat IPv4 adresy, je ostuda. A s rozšířením IPv6 to bude ještě horší, protože na jednu stranu se (správně) říká, že není potřeba používat IPv6 adresy, protože máme DNS – pak ale musíme dát uživatelům nástroj, jak to DNS opravdu používat (i v SOHO sítích).
Mimochodem, pokud se toho nechytnou výrobci routerů a ISP, chytnou se toho Google a Apple, zakomponují to do svých zařízení pro chytrou domácnost – a pak zase všichni budou brečet, že Google a Apple mají všechno, jdou přes ně všechna data a jsou na nich všichni závislí.
-
DannyStříbrný podporovatel
TL;DR mnoho "teorii" a nulova provozni praxe... mozna byste mel zacit uz u toho, jak ISP "overuji" ty klienty...
-
Filip JirsákStříbrný podporovatel
Pro domácího uživatele by to mělo ten přínos, že by používal normální názvy, kterým rozumí, ne nějaké divné IP adresy. Na NAS by se připojil pomocí https://nas, na tiskárnu přes https://tiskarna apod.
Certifikát zajistí to, že nebudete muset v prohlížeči potvrzovat varování, kterým nerozumíte. Do budoucna to, že se s prohlížečem vůbec na domácí zařízení dostanete.
-
DannyStříbrný podporovatel
Tohle v prohlizeci take failne, certifikat se SubjectAltName bez FQDN vam nikdo nevyda. A prohlizec (kdyz uz teda uzivatel vypise cele URL vc. toho https://, coz ale fakt bezne delat nebude) opet vyhlasi chybu, ze domena nesedi...
-
Filip JirsákStříbrný podporovatel
Ano, to máte pravdu, že prohlížeč se celé jméno nedozví, takže přes SNI posílá jen tu část, co zadal uživatel, a bude proti tomu validovat certifikát. Takže v současné podobě by to nefungovalo. Nicméně i to by bylo technicky řešitelné, aby prohlížeč znal tu lokální doménu a doplňoval ji sám.
-
DannyStříbrný podporovatel
Technicky resitelne je i DANE. Ale to se za tech cca devet let jaksi take nezvladlo. Tak kolik davate tomuto? ;-)
-
DLNA je pro TV a chytré krabičky, pokrývá video, hudbu a fotky. Pokud chcete soubory obecně, tak s těmi pracujete pravděpodobně na chytřejších zařízeních, kde máte více možností. Např PC - na mobilech se stejně nedá moc pracovat se soubory, i na Androidu zlobí asociace a "otevřít v app", o iOS nemluvě.
11. 9. 2024, 12:47 editováno autorem komentáře
-
https://www.root.cz/zpravicky/od-1-zari-se-zkracuje-platnost-https-certifikatu-na-jeden-rok/
1. 9. 2020 9:37
czechsys
Stale jsem nikde nedohledal, zda to plati i pro interni CA ????1. 9. 2020 13:22
Filip Jirsák
Stříbrný podporovatel
Neplatí. Pouze pro ty všeobecně uznávané CA, jejichž seznam se distribuuje s OS nebo s prohlížečem.Toliko k diskuzi "co domaci uzivatel?" ...
-
DannyStříbrný podporovatel
No, provozovat domaci CA nebude asi neco, co by zvladnul kazdy domaci uzivatel :-)
-
DannyStříbrný podporovatel
Diskuze je ale o domaci infrastrukture, ktera do internetu vystrcena typicky neni. Self-signed certifikaty tam jsou uz dnes, problem je jejich (ne)duveryhodnost z pohledu browseru.
-
Filip JirsákStříbrný podporovatel
Málokdo má doma jenom jeden počítač a nic jiného. Většina lidí má mobil či mobily, a dostat tam self-signed certifikát není snadné. Navíc těch certifikátů asi bude víc než jeden, některé aplikace nepoužívají systémové certifikáty ale mají nějakou vlastní sadu důvěryhodných certifikátů…
-
Typicky mi v tom brani dane zariadenie, alebo aplikacia na tom zariadeni.
Napriklad Android na mobiloch a tabletoch ma store pre uzivatelske CA. Google vsak zmenil, ako sa pouziva a niektore aplikacie dodnes maju problem s CA, ktora nie je systemova. Existuje kopec postupov pre rootnute telefony, ako to napravit (v podstate nastavit vlastny CA bundle), ale pre pouzivatela s nerootnutnym telefonom je to konecna.
Dalsia kapitola je Android TV. Tam sa vlastna CA neda naimportovat vobec. Vid vlakna na stackoverflow, kde je to "vyriesene" rootom a adb v emulatore :facepalm.
No a uplna konecna je chromecast. Chcem si pozriet foto a video z vlastneho NAS na TV cez chromecast? No, blbe, mas mat verejnu domenu a verejny cerfikat.
-
Ja tam teda takovy problem nevidim. Pokud chci doma koukat na televizi na film z NASu, tak na domaci siti by nesifrovany provoz vadit nemel. Pokud chci sifrovat filmy i na interni siti, tak bud verejna domena + letsencrypt, nebo selfsigned + raspberry pi.
Pokud nekomu ani jedno z techto 3 reseni nevyhovuje a radsi kazdy rok manualne obnovuje certifikat od verejne CA na NASu, tak mi ho zas tak lito neni, ze to ted bude muset delat 4x. -
To teda je problém. Celkem dost lidí už klasické PC nemá. Celkem dost lidí navíc nejsou IT experti (a přesto mají krabičky .. dneska má web snad i pračka).
Považuju to za problém a názor nezměním jen proto, že já to zrovna umím většinou obejít. Ale takové HP iLO s HTML5+js konzolí už v linksu nezobrazím.
-
Pozeranie foto, domacich videi - napr. Synology Photos - http, https.
Pozeranie filmov - Jellyfin, Plex - http, https.
Vlastna kniznica - napr. calibre-web - http, https.
Na http browsery prskaju. Https je zase nepouzitelne na mobilnych zariadeniach - konkretne jellyfin sa mi takto nikdy nepodaril rozhodit na AndroidTV; aspon Kodi s Jellyfin pluginom ma sposob, ako podhodit vlastnu CA.
Synology Photos (vystup na Chromecast, na navsteve cez VPN) sa mi nepodarilo rozbehat nikdy. Podarilo sa cez Synology Quickconnect - pretoze ten vytvorit verejny dns zaznam v domene Synology , k nemu Let's Encrypt certifikat a dokonca aj relay cez nat; co je zase zbytocna zavislost na cloudovej sluzbe.
-
Filip JirsákStříbrný podporovatel
na domaci siti by nesifrovany provoz vadit nemel
Nejde o to, jestli to někde vadí nebo nevadí. Uživatel to v drtivé většině případů neumí rozhodnout (jak je vidět i v této diskusi – doma to může vypadat jako bezpečné, ale pak vám dojde, že mobil hosta na vaší WiFi vám může ukrást heslo k routeru). Prohlížeč to také neumí rozhodnout. Tím pádem se musí šifrovaný provoz používat všude – protože abyste mohl chránit ten provoz, kde je šifrování potřeba, musí prohlížeč vyžadovat a kontrolovat šifrování při jakékoli komunikaci. Jakmile povolíte uživateli schválit nějakou výjimku, bude tohle nejslabší místo. -
Ale o to jde a jestli to uzivatel neumi rozhodnout, tak by se do toho nemel poustet, jinak to smrdi dobroserskym "ochranime vas i proti vasi vuli".
Pokud nekdo nema rozsegmentovanou sit a necha pripojit nezname zarizeni (mobil hosta na moji wifi) do interni site, tak ma v bezpecnosti velky problem a sifrovani castecne mitiguje nasledky, ale neresi pricinu.
Jinak ja proti sifrovani i zbytecnosti jako filmy nic nemam, jen si myslim, ze to neni treba za kazdou cenu vynucovat.
-
Filip JirsákStříbrný podporovatel
Ale o to jde a jestli to uzivatel neumi rozhodnout, tak by se do toho nemel poustet,
Ano, uživatel to neumí (v drtivé většině uživatelů) rozhodnout, takže ho do toho nikdo nemá pouštět a tím pádem je potřeba veškerou komunikaci z prohlížeče považovat za takovou, která musí být šifrována (je potřeba se přiklonit k bezpečnější variantě).Uživatelé, kteří to rozhodnout umí, si umí poradit i s tím, aby tam byl certifikát, kterému prohlížeč důvěřuje.
Pokud nekdo nema rozsegmentovanou sit a necha pripojit nezname zarizeni (mobil hosta na moji wifi) do interni site, tak ma v bezpecnosti velky problem a sifrovani castecne mitiguje nasledky, ale neresi pricinu.
Za prvé, takhle to má 99 % uživatelů, a ani netuší, co jsou to segmenty sítě. A někteří to rozsegmentované mají, protože jim to tak někdo nastavil, a ani o tom nevědí.Za druhé, myslet si, že když máte domácí segment sítě, kam pustíte jen známá zařízení, že je tento segment bezpečný, to je také dost „odvážné“.
Jinak ja proti sifrovani i zbytecnosti jako filmy nic nemam, jen si myslim, ze to neni treba za kazdou cenu vynucovat.
Jak jsem psal, pokud to nevynutíte, nejslabším místem bude právě ta uživatelova možnost volby. Jakmile uživatel narazí na chybovou zprávu, že je nějaký problém s certifikátem, hledá jenom kde to má odmáčknout, aby se dostal na web – a na bezpečnost nemyslí. A nic s tím neuděláte, takové chování je přirozené. (Ze stejného důvodu vjede řidič na blikající přejezd před přijíždějící vlak – když lidé z tohoto důvodu riskují život, těžko je přesvědčíte, že to dělat nemají kvůli takové banalitě, jako je nějaká webová stránka, třeba internetové bankovnictví.) Navíc až na ten web dotyčný půjde příště, tak už se ho prohlížeč ptát nebude, protože už přece jednou schválil bezpečnostní výjimku pro tento web. -
Ja netvrdim, ze rozsegmentovana sit = bezpecna, jen resit siforvani bez segmentace je trochu staveni domecku od strechy.
Ano, 99% uzivatelu to tak ma a ma to spatne, ale neni to dobry argument proc omezovat pouzivani nesifrovane komunikace, je to dobry argument treba dat do defaultniho nastaveni routeru guest wlan. Nastesti to pro 98,999% uzivatelu neni problem, protoze tohle neni bezny vektor utoku. Kdyz uz se nekomu podari nainstalovat skodlivy software do telefonu, tak se daji delat lepsi veci nez odposlouchavat hesla do ip kamer nebo lednicek v siti.Jen nevim jestli jsme se ted tematicky neposunuli uz nekam zbytecne daleko, ja s vami v podstate souhlasim, za me spis jen - Default ano, Forced ne.
-
Filip JirsákStříbrný podporovatel
Ja netvrdim, ze rozsegmentovana sit = bezpecna, jen resit siforvani bez segmentace je trochu staveni domecku od strechy.
To si nemyslím, i v domácí síti řeší šifrování spoustu potenciálních problémů, segmentovaná síť je spíš třešnička na dortu.za me spis jen - Default ano, Forced ne
Jenže to bohužel v praxi nefunguje. Jakmile dáte uživatelům na výběr, je pro útočníka nejjednodušší zaútočit na to, aby si uživatel sám vybral, že bezpečnost vypne. -
Filip JirsákStříbrný podporovatel
Certifikát s platností 14 dnů je na můj vkus dost málo, poněkud to popírá princip certifikátů. Zejména když jediný důvod, proč se platnost certifikátů tak zkracuje, je ten, že prohlížeče odmítají implementovat DANE.
-
Ok, síťové prvky, management konzole, tiskárny a podobná zařízení neřeším - tam mi stačí lokální CA a kořenový certifikát lokální CA nahraný do browseru či browser který akceptuje http či neplatné certifikáty a trocha umu...
Pro mne je ale problém tam, kde se certifikát nevydává bro browsery ale pro jiné účely.
Dozvěděl jsem se ale od certifikačních autorit, od kterých používáme komerční certifikáty, že z uvedených důvodů přestanou vydávat roční certifikát, které dnes používáme.Řeším totiž mailovy server, předražený antispamovy mailgateway a například LDAP server a podobné a to především u aplikaci které nejsou až tak (moc) opensource.
Doménový MX server má DANE a je to nějaký Cisco Ironport, kde se automatizace nahrání certifikátu fakt nedá a zkoušeli jsme to dlouho.
Ok, koukám že DANE pro SMTP server by asi možná - nevím - šlo vyřešit lokálně vydaným certifikátem bez nějaké certifikační autority. Webové rozhraní antispamoveho filtru by to sice zabilo včetně webových stránek karanteny, ale což. Můžu tak udělat třeba https -> https reverzní proxy či se na to nějak vykašlu... Takže tady možná řešení je s lokálním certifikátem. Musel bych totiž změnit i DNS server který také automatickou změnu (DANE) záznamů triviálně nepodporuje.Horší to bude s vnitřním mail serverem. U Zimbry je situace složitější a automatizace výměny certifikátu fakt zatím nedopadla a nevím o tom, že by to někdo z komunity měl vyřešené. Přechod na jiný mailovy server bude samozřejmě opruz. Certifikát je jak pro webové rozhraní tak pro bezpečné SMTP, IMAP a POP3 protokoly.
V neposlední řadě myslím třeba na lokální LDAP server který certifikát používá nejen pro zabezpečenou LDAP komunikaci ale i pro webové rozhraní pro změnu hesla atd... LDAPS je dnes nutnost v různých knihovnách například PHP pokud je potřeba i zápis a dává to smysl. A to opět bude oříšek, protože tenhle directory server opravdu nepodporuje automatickou výměnu certifikátů a lokální autorita mi tu nepomůže....
Nějaké nápady?
11. 9. 2024, 09:41 editováno autorem komentáře
-
Je vlastně správně retrospektivně nebo retroaktivně? V článku to slovo bylo použité a ani jedno mi oči netrhá.
Co když dojde k zpoplatnění generování certifikátů? + platba za certifikát? Zvykli jsme si na LEt's encrypt.
Není to spíš snaha o větší šmírování (častější přísun dat) do pro certificate transparencz?
-
DannyStříbrný podporovatel
Nic vam prece porad nebrani si vygenerovat wildcard a zautomatizovat jeho deployment uvnitr sve infrastruktury, jste-li tak paranoidni... z hvezdicky toho moc nevysmirujete :-)
-
DannyStříbrný podporovatel
Co presne je tady za problem? Pokud se neco po*ere, pak i den nekorektniho fungovani uz je problem...
-
DannyStříbrný podporovatel
No tak jasne, pokud nemate adekvatni monitoring, tak na problem prijdete az v momente, kdy certifikat vyprsi. Monitoring by mel na takove veci umet upozornit v predstihu - ostatne ani dnes se s ACME/LE nemeni certifikaty na posledni chvili, ze? To je ale fail na strane dotycneho admina... ze nema monitoring.
-
Přesně tak. A proto pokud selže aktualizace certifikátu, tak to není konec světa jak jste naznačoval(nebo tak jsem to aspoň pochopil z vašeho komentáře). A abych se vrátil ke komentáři od Glasny na který jste původně reagoval, tak právě v tomhle bodě, kdy aktualizace selhala, může být rozdíl v tom kolik je na opravu času. Při čtrnácti dnech(a méně) to už bude bezmála krizová situace. Zejména pokud na to nemáte žádný plán a vyhrazeného vývojáře.
Při devadesáti dnech to už nejspíš můžete v klidu naplánovat, opravit a otestovat i kdyby se musel vyměnit třeba celý acme klient a já nevím co ještě. -
Co přesně je tady za problém? No když mám certifikát na rok, tak ten problém může nastat jednou za rok, když na 90 dní, tak 4x za rok a když na 14 dní, tak 26x.
A kam až chcete to zkracování dohnat? Výměna certifikátu v poštovním serveru (a mnoha jiných službách) znamená restart služby, restart znamená (byť krátký) výpadek a riziko, že se něco podělá.
-
DannyStříbrný podporovatel
Omyl, spouste sluzeb ve skutecnosti staci reload... a i ten restart samozrejme muzete naplanovat do doby s mensim provozem, nemusite to pachat v ranni spicce, zejo. Honite uptime? ;-) No to je tuplem cesta do pekla...
-
Ale já o uptime nic nepíši, stejně tak o času restartu/reload - zase si vytváříš vlastní závěry, a pak s nimi polemizuješ?
Omyl je předpokládat, že spoustě služeb stačí reload, už protože to v principu nic nevyřeší. Jak reload vyřeší to, že se certifikát aktualizací rozbil? To jsem řešil - obnova certifikátu byla „úspěšná“, ale nový certifikát byl nefunkční, protože se něco tiše rozbilo... Neřeš teď co, není to podstatné.
A není nic lepšího, než ve tři ráno vstávat kvůli výpadkům (když už jsme u té ranní špičky), protože se něco rozbilo. Případně fakt miluji ty noční aktualizace, aby se to nedotklo uživatelů.
-
DannyStříbrný podporovatel
Tak chcete-li byt echt paranoidni, muzete pred reloadem sluzeb zkontrolovat i validitu (konzistenci) tech novych certifikatu, ze? ;-) Kvuli tomu fakt neni potreba zrestartovat sluzbu, abych overil, ze to co mam v ruce, resp. tedy na disku v realu neni funkcni kombinace klice a k nemu naleziciho certifikatu. A i tohle muzete zautomatizovat, ze?
Ach tyhle snahy o hledani problemu tam, kde reseni je naprosto banalni... :-)
-
DannyStříbrný podporovatel
Neni nutne pravda. Castejsi vymena vede k drillu, automatizaci, systemovemu reseni... zatimco cinnost konana jednou za rok, dva, tri... vas tolik nenuti mig ten system spravne nastaveny a odladeny, protoze holt za ten rok, dva, tri to nejak na kolene slikujete... ze? ;-)
-
Filip JirsákStříbrný podporovatel
Vhodnější by asi bylo retroaktivně.
Certifikáty jsou pořád zpoplatněné, většina certifikačních autorit vydává certifikáty za peníze. CA, které vám vydají certifikát „zdarma“, jsou myslím tři – Let's Encrypt je sponzorovaná, ZeroSSL i Buypass to pravděpodobně křížově financují z vydávání jiných certifikátů.
Není to spíš snaha o větší šmírování (častější přísun dat) do pro certificate transparencz?
Ne.11. 9. 2024, 10:08 editováno autorem komentáře
-
No, pokud to projde, tak jsem v prekerni situaci. Ja proste neumim spolehlivou automatizaci na vymenu crt do nasi infrastruktiru naprogramovat, zejmena, pokud dany certifikat pouzivam na vice serverech (redundance).
A temi misty mam na mysli v tuto chvili jen verejne pristupne webove sluzby...
V pripade, ze certifikat je na jednom serveru, tak na to mi ruzne acme utility fungovaly v pohode (overovani pres lokalni klic). Ale propagace (=rekonfigurace ze source of truth) treba wildcard crt vsemoznych sluzeb...jejda jejda.
-
Filip JirsákStříbrný podporovatel
Myslím, že ten tlak je v tuto chvíli zaměřen právě na to, aby dodavatelé těchto různých enterprise řešení konečně začali ACME podporovat. Ale jsem zvědav na ten termín – protože životnost těchto řešení se počítá v letech (a to spíš pět a více než dva roky), takže i kdyby Fortinet, F5 a další začali ve všech svých produktech podporovat ACME dnes, bude to rozšířené za pět deset let.
-
Treba fortinet acme podporuje, ale co jsem cetl diskuze, tak to "moc nefunguje". A treba nase aktualni firewally acme nepodporuji.
Ja hlavne mam problem i s tou automatizaci. Pokud je u nas hostovana domena zakaznika, tak nelze provest dns validaci, ale je nutna https validace. To implikuje vytvoreni centralniho bodu, na ktery se nasmeruji veskere verejne body, kterymi ta sluzba muze projit. No a pak to narvat do gitu apod., jinak by konfiguracni sluzby musely sahat do jineho centralniho bodu pro crt. Zejmena chutovka, kdyz ten crt pro novou domenu neexistuje.
-
Filip JirsákStříbrný podporovatel
Předpokládám, že tam stejně máte nějaké loadbalancery, které mají stejnou konfiguraci. Tak akorát do té konfigurace doplníte, že požadavky na /.well-known/acme-challenge/ má přesměrovávat na server, který vyřizuje vystavení certifikátů, ne? Nebo je tam něco složitějšího?
Třeba Caddy si umí pro certifikát sáhnout do různých úložišť. Ono je dost rozdíl, jestli se ta podpora doimplementovává do něčeho existujícího, nebo se to staví rovnou s tím, že to má podporovat ACME. Zrovna na Caddy serveru je to dobře vidět – ten je HTTPS by default, takže základní konfigurace HTTPS spočívá v tom, že podporu HTTPS nevypnete :-) Což je samozřejmě úplně něco jiného, než když podporu ACME přidáváte nějakou externí utilitou do Nginxu nebo Apache.
-
Ok, odpovídám si i sám na svůj předchozí příspěvek.
Řešením bude asi všechny tyhle jiné protokoly než https tj. imaps pop3s smtps ldaps a jiné protáhnout taky přes reverzní proxy (u nás centrální nginx teda vlastně OpenResty) jako tzv. stream. Kde acme funguje perfektně.
Akorát to mi furt neřeší DANE a automatizaci updatu DNS záznamů třeba pro SMTP....
Před několika dny mi po výměně certifikátu neproběhla automaticka změna hashe v DNS a to zabolí, protože příchozí pošta je prostě nenávratně ztracena kvůli odmítnutí odeslání ze strany odesílatele. Snad jedině krok zpět a zrušit celé DANE, které stejně tenhle koncept certifikátů nějak odmítá...Vidím to správně?
-
Ano, v drtive vetsine tam mam balancery. Ja ten problem rozdeluji na 2 body.
1] ziskani certifikatu - https validace "jednodussi", dns "validace lepsi, ale slozitejsi"
2] propagace certifikatuA ten bod 2] je ten vetsi problem. Ta sluzba, co v 1] ziskava certifikat, nema tuseni, kde vsude je pouzit. Pokud ma clovek puppet a podobne pull orchestrace, je to jendodussi. Ale v pripade push orchestrace, tam je nutne spustit rekonfiguraci vsech typu sluzeb, ktere jsou verejne. Jinak by to vyzadovalo zase nejakou slozitou programatorinu zjistit, kde je ten crt vlastne nasazeny, aby se rekonfigurace spustily na podmnozine sluzeb. Treba, kdyz konfigurace nejsou v databazi, jak zjistit, kde vsude je ten crt nasazen? No...
Ja bych nejradsi certifikaty zrusil (je s tim cim dal vcetsi oser) a radeji bych se treba tou DANE cestou...
-
Filip JirsákStříbrný podporovatel
Na propagaci certifikátu mi připadá nejuniverzálnější použít přímo ACME s konfigurací „bez verifikace domény“. Ta aplikace, která certifikát potřebuje, by jím stejně měla umět komunikovat. Akorát o vystavení certifikátu (přesněji o ověření domény) nepožádá nějakou veřejnou autoritu, ale vašeho interního poskytovatele ACME. V druhé fázi si klient vybere, jakým způsobem chce doménu ověřit – v tomto případě by klient zvolil „nulový“ způsob, že se vlastnictví domény vůbec ověřovat nebude (protože to vlastnictví nebude prokazovat tento klient, ale váš poskytovatel ACME). No a pak se klient opakovaně ptá, zda už je k dispozici nový certifikát, a když ano, stáhne si ho a použije. No a to by bylo zase stejné, jenom by interní poskytovatel ACME nevydával ten certifikát sám, ale zase přes ACME by ho vyžádal od nějaké důvěryhodné autority.
Na tom interním ACME poskytovateli by pak mělo jít nakonfigurovat, jak dlouho bude vystavené certifikáty kešovat. Tj. první klient si řekne o certifikát, tak ho interní ACME provider zajistí. Když si pak za pár hodin vzpomene další klient, že chce taky certifikát, dostane ten z keše. A třeba teprve za 14 dní ten interní poskytovatel ten certifikát v cache zneplatní, a když ho bude chtít někdo další, nechá vystavit zase nový.
-
Filip JirsákStříbrný podporovatel
Typy pro interní acme poskytovatel, který umí požádat dál případně vyřešit některé sám jako interní CA?
Měl by to umět Caddy server. -
Co čtvrt roku absolvuji martyrium při výměně certifikátů (LE) na e-mailovém serveru - to sice udělá poskytovatel, ale následně musím ve všech zařízeních v Thunderbirdu potvrdit, že opravdu věřím certifikátu, který je vystavený pro jinou doménu, než ze které odesílám poštu. (Musím používat SMTP server poskytovatele, ale ten není ve stejné doméně, ze které odesílám e-maily.)
Představa, že tohle budu absolvovat co dva týdny... Za tak krátkou dobu to stihnu sotva potvrdit na všech strojích! -
Ondřej CaletkaZlatý podporovatelTo vypadá, že máte špatně nastavené jméno SMTP serveru - to je totiž to, co Thunderbird kontroluje proti obsahu SAN v certifikátu. Podívejte se tedy do toho certifikátu na doménová jména uvedená jako SAN a nastavte jméno svého SMTP serveru na jedno z nich. Z jaké domény odesíláte poštu nehraje žádnou roli.
-
V tomhle máte pravdu, přesně v tom je ten problém: abych mohl poslat e-mail, musím se hlásit na server pod jménem, které v tom certifikátu není uvedené.
Problém je, že když změním jméno serveru, aby odpovídalo certifikátu, odmítne mne. Podle podpory je řešením: dát tam předepsané jméno serveru a povolit explicitně výjimku...
Ze své strany moc nezmůžu a měnit poskytovatele služby se mi kvůli tomu nechtělo (nechce) - jednou za čtvrtrok to nebylo tak hrozné... -
DannyStříbrný podporovatel
Takovy scenar zni dost nepravdepodobne - ze by se i hostname nejak vynucoval a pritom k tomu neexistoval validni certifikat. Co se podelit o vice detailu, treba alespon jmeno toho poskytovatele? A co na to jejich technicka podpora?
-
Nepravděpodobně... - poskytovatelé služeb jsou schopni mít nastavena různá zvěrstva, zejména v případě, kdy větší ryba sežrala menší, která to podědila po úplně malé společnosti, u které jsem to zařizoval před mnoha lety. Jak to postupně migrují na svá řešení, tak se ty konfigurace všelijak kazí.
Řešením by (prý) bylo ty schránky úplně zrušit a znova založit na jejich novém serveru, ale do toho se mi nechce, je tam dost historie a archivů,, profilů...
(Jmenovat je záměrně nebudu - radši hledámsmírné řešení
, než veřejněpranýřuju
.) -
DannyStříbrný podporovatel
Aha, takze jste si prisel zanadavat na neco, kde prava pricina ve skutecnosti neni to, ze se certifikaty obmenuji s vetsi periodicitou - na co nadavate jsou jen nasledky vasich vlastnich rozhodnuti ;-)
-
Fuj.
Šlo mi spíše o to, že certifikáty (a jejich výměna) se zdaleka netýkají jen webovek.
Z jiného soudku: máme v práci aplikaci, která na veřejných certifikátech stojí, ale výměna je proces na cca dva týdny (tři dny jen zrychlené schválení žádosti v rámci firmy, jeden den na získání certifikátu, předání dodavateli/protistraně další den, nasazení a kontrola na obou koncích - to celé dvakrát, pro testovací a produkční prostředí...).
Jednou do roka se to dá v pohodě zvládnout, ale pokud by platnost byla pouhé dva týdny... -
DannyStříbrný podporovatel
Za nevhodny design aplikace fakt X.509 nemuze... ano, samotna moznost vystavovat mnohalete certifikaty v kombinaci se chticem dodavatele byt jaksi nepostradatelnym vedla ke vzniku vselimoznych bastlu. Vsak dodavateli platite, ne? Tak at to udela poradne, ne? Nebo si zvolte jine reseni, kterym vzpupneho dodavatele jednoduse odstavite od jeho penezovodu. Tady se bavime o hlasovani penezenkou a ne o realnych technickych problemech...
-
Tady nejde o
chyby X.509
, ale o to, že firemní proces nepočítá s tak rychlou obměnou - a ten certifikát (který nelze jednoduše nahradit LE) není zadarmo, ale za pár €. Takže nákup musí někdo schválit a rozhodně není žádoucí, aby si o to požádal každý technik na konci firemního potravního řetězce, natož, aby to dělal automat. Pak by, pokud by se cena nezměnila, stouply náklady zhruba pětadvacetinásobně.
Schválit nákup čehokoliv prostě ve velké firmě chvíli trvá - a ty tři dny jsou ještě poměrně dost svižné tempo!
(Takový nákup sluchátek, to je teprve ta správná atrakce - k tomu se chce vyjádřit úplně každý manažer, protože každý manažer moc dobře ví, jak vypadají sluchátka, a dokáže si představit, kolik by tak mohla stát. Naproti tomu serverovému certifikátu nerozumí z managorů nikdo, to je příliš abstraktní komodita. Takže dokud to není moc často, tak to prostě bez ptaní schválí...) -
My zas v našom korporáte problém s platbou za certifikáty nemáme, a na vystavovanie verejných certifikátov od DigiCertu je poloautomatický proces, ale máme jednu enterprise aplikáciu, ktorá tie certifikáty (potrebujeme od verejnej CA, lebo pár ľudí od zákazníka sa potrebuje pripájať na webové UI toho molocha, a majú nejaké prísne vlastné pravidlá na prístup k HTTPS) používa aj na nejakú vnútornú komunikáciu a vyžaduje (odskúšané) kompletný downtime (bežne stačí vypnúť jeden node z dvoch a nastavovať po jednom) na ich výmenu. Pol hodinky, keď sa darí.
Keď to malo byť raz za rok, to sa ešte dá zniesť, ale 90 dní je už povážlivo nepríjemné. Asi to budú vendorovi otrieskávať o hlavu viacerí, ale neviem, či bude postup tej výmeny vedieť zmeniť len tak nejako jednoducho... -
Filip JirsákStříbrný podporovatel
Šlo mi spíše o to, že certifikáty (a jejich výměna) se zdaleka netýkají jen webovek.
Ale web v tom není nijak speciální. Pořád to znamená, že klient chce komunikovat se serverem s nějakým DNS názvem, dostane od něj certifikát prokazující, že server tento DNS název může používat a ověří, zda se jedná o důvěryhodný certifikát a odpovídá danému jménu. A server musí takový certifikát mít i s privátním klíčem, přičemž vydání a nahrazení certifikátu je vhodné zautomatizovat.máme v práci aplikaci, která na veřejných certifikátech stojí,
Záleží na tom, co je to za certifikáty. Jestli certifikáty prokazující DNS název, fyzickou osobu, právnickou osobu, aplikaci… -
Filip JirsákStříbrný podporovatel
To je ale problém chybné konfigurace, buď serveru nebo klienta (nebo obojího). Ale to by bylo potřeba znát přesný popis chyby – to, co jste napsal, je poněkud zmatené.
-
Ondřej CaletkaZlatý podporovatel
Je hezké, jak se všichni ohánějí automatizací, ale pak vám někdo vyvine standard, který vyžaduje IP adresu v SAN. K tomu sice existuje rozšíření ACME, ale najít někoho, kdo ho implementuje, se mi nepodařilo.
Ono ostatně jen najít autoritu, která bude schopná ověřit držení IPv6 adresy byl netriviální úkol.
-
DannyStříbrný podporovatel
Tak to RFC je celkem mlade... a na dost specificky use-case. To fakt neni ani prvni, ani posledni pripad situace, kdy nejaky cas trva, nez se na papire napsany standard skutecne uvede do praxe.
Ale nabehl sis na vidle - ono i tvuj chlebodarce (RIPE) a standardy... ;-) Ehm... nejaky chytrak tam vymyslel, ze emailova adresa delsi jak 80 znaku je "pry problem". Prestoze podle RFC jde mit rozhodne delsi adresu, ze? Kdyz uz tady brecis nad novymi standardy, tak mozna bys mohl kopnout do svych kolegu, aby neignorovaly standardy starsi, co plati uz fakt dlouho...
-
Jděte s tím zkracováním do pr*ele - starám se o certifikáty webového serveru pro informační systém naší školy, certifikát přegenerovávám už 1x ročně ručně (a vzpomínám na doby, kdy to stačilo 1x za -3 roky), a vzhledem k tomu, že je to cca 1% mé pracovní náplně, tak fakt nechci věnovat x hodin zkoumání, jak nastavit nějaký automatický obnovování a nechápu, čemu vadí obnovování po 1, 2, nebo klidně i 10 letech :-((. Pro mě je to jenom spousta práce navíc s něčím, co reálně není k ničemu jinému, než ke zvyšování zisku vydavatelů certifikátů. Hnus ...
-
Filip JirsákStříbrný podporovatel
Tak před to dejte třeba Cloudflare a nemusíte se o to starat vůbec. Nebo pokud zvládnete nainstalovat webový server, dejte před to Caddy, a po instalaci a triviální konfiguraci se o to nebudete muset vůbec starat.
To, že je to spousta práce pro někoho, kdo tomu nerozumí, fakt není argument.
-
DannyStříbrný podporovatel
Ano, ono je obcas dobre prestat byt otrokem minulosti a opustit postupy zazite pred 10-20 lety. Proc to neautomatizujete? Aha, nechcete... ale to jste si zvolil spatny obor, IT se proste vyviji... :-) Vzdyt je na to hromada hotovych nastroju. Nabizi se i podotazka - a proc za ty certifikaty vubec platite? Vzdyt dneska se daji poridit zadarmo a nemusite u toho vykrikovat, jak si nekdo snazi zvysit svuj zisk.
-
Aha, nechcete... Dobré věštění. Ve svém příspěvku píše, jak, ale ne proč. Zase... polemizuješ sám se sebou.
... a proc za ty certifikaty vubec platite? To je dobrá otázka a je na ní jen špatná odpověď - protože školství. Tam logiku nehledejte, může to být důsledek nějakého šlendriánu, který koncový IT nemohl ovlivnit a jen si to vyžírá. (Zástupkyně ředitele, učitelka češtiny a dějepisu dostala za úkol sepsat výběrové řízení, slyšela od učitelky IT, že je potřeba certifikát a první odkaz v google ji ukázal nějakou komerční CA, přečetla si „Důvody proč si vybrat nás“ a bylo... Nebo dodavatel systému má nasmlouvané tyto certifikáty a basta.)
Proc to neautomatizujete? Třeba to nejde, viz předchozí odpověď.
-
Filip JirsákStříbrný podporovatel
Třeba to nejde, viz předchozí odpověď.
Že by to byl webserver, před který nejde dát reverzní proxy? To se mi zdá u informačního systému školy dost nepravděpodobné. Jediné, co by tomu podle mne mohlo zabránit (při nedostatečné implementaci na straně IS), by bylo přihlašování klientskými certifikáty. (To se pak řeší tak, že reverzní proxy certifikát klienta ověří a uloží ho do nějaké hlavičky, za které si ho musí backend server vyzvednout – to je ta implementace navíc, která musí být na straně IS.) Ale nemyslím si, že by to nějaký školní IS používal (protože pokud ano, ta čtvrtletní výměna serverového certifikátu by byla ten nejmenší problém, který by se s certifikáty řešil). -
Filipe, na jakékoliv posuzování situace máme málo informací. Ten systém může být naprosto cokoliv zbastlené naprosto jakkoliv - je to školství. A ano, může v tom být neschopnost se učit nové věci a/nebo neschopnost aplikovat nějaké řešení (reverzní proxy/automatizace/výměna CA/cokoliv...).
Nechtěl jsem obhajovat autora za každou cenu, jen nastínit možný pohled na situaci druhé strany, nic víc.
-
Filip JirsákStříbrný podporovatel
Jde o webový server. Takže pravděpodobnost, že by před něj nešlo dát reverzní proxy (která by řešila certifikáty), je opravdu nízká.
-
DannyStříbrný podporovatel
No ja bych spis hledal slendrian primo na strane toho IT. Se skolnim prostredim ku vasi smule nejakou zkusenost z pozice administratora mam. Pohadku o ucitelce IT si nechte od cesty... takova ucitelka by ani nepoznala, ze ten realny certifikat je vlastne jiny... ;-) Do takovych low-level detailu vedeni skoly nekeca, protoze jim ani nerozumi.
-
Docela by mne zajímaly zdroje těch informací že to bude vyhlášeno během měsíce a že termín je znám.
Google toto na CAB prezentoval přesně před rokem:
1. Immediate Focus:
Support for automation.
Term limits for root certificates. (leden '24)
2. Exploring Next:
Establish minimum expectations for linting.
Phasing out “multi-purpose” root certificates.
Phasing out client authentication use cases.
3. Long-Term Goal:
Strengthen domain validation.
Shorten the validity period for sub-CAs.
Shorten the validity period for leaf certificates.Aktuálně jsme ve 2. fázi. Zkracování je long term goal.
Tím neříkám, že mohou navrhnout že budou chtít o zkrácení v 2025 hlasovat. CAB fórum by měl mít nyní meeting v Seattlu.Co se týká odkazů na články autorit, všechny články jsou prakticky jen reakcí na to vyhlášení Google a nepřináší žádné jiné informace.
Informace o povinnosti mlčenlivosti ve mne vyvolává úsměv, ale možná pan Studený opravdu něco ví :)Tímto nechci tvrdit, že ke zkracování nedojde. To asi určitě ano. Ale podle mne to nebude tak horké jak se píše a dříve jak podzim 2025 to asi nebude.
PS: Info z CAB - Microsoft plans to propose a ballot that will change validity of Code Signing Certificates to 15 months, effective April 30, 2025.
-
DannyStříbrný podporovatel
To sledujete hodne spatne. Na mnoha mistech, gov.cz nevyjimaje certifikaty vystavovane pomoci ACME naleznete uz dnes.
