A Safari nem fog megbízni a 13 hónapnál régebbi tanúsítványokban

Apple

A múlt héten Pozsonyban tartott CA/Browser (CA/B) konferencián az Apple bejelentette, hogy a 2020. szeptember 1. után újonnan kiadott, nyilvánosan használt TLS tanúsítványok érvényessége számára nem (lesz) több mint 398 nap. Ez azután történt, hogy a CA/B Forum közösség tagjai régóta dolgoznak azon, hogy a tanúsítványok élettartamának csökkentésével növeljék a biztonságot. Az Apple nem adott még ki róla hivatalos bejelentést, úgyhogy ez még változhat.

A 2020. szeptember 1. előtt kiadott tanúsítványokat az Apple még nem tervezi szankcionálni:

It should be noted that Apple has not released a Knowledge Base article on this subject, so things could change pending their official announcement. Assuming, however, that the change is implemented, what does this mean for certificate users? For your website to be trusted by Safari, you will no longer be able to issue publicly trusted TLS certificates with validities longer than 398 days after Aug. 30, 2020. Any certificates issued before Sept. 1, 2020 will still be valid, regardless of the validity period (up to 825 days). Certificates that are not publicly trusted can still be recognized, up to a maximum validity of 825 days.

Részletek itt.

( trey | 2020. 02. 25., k – 06:48 )

Szerkesztve: 2020. 02. 25., k – 06:50

Magyarul: hiába vesz valaki a weboldalára 2020. szeptember 1. után egy két évre (730 nap) szóló pl. domain ellenőrzött Netlock tanúsítványt, azt a Safari el fogja dobni 398 nap után.

trey @ gépház

Ó, ezt is ismerjük. :) Még nem döntöttem el, hogy annak a kezét kéne inkább eltörni, aki ez leimplementálta, ráadásul úgy, hogy nincs leszarom gomb (ami egy általános kliensnél teljes mellélövés, igen is legyen meg a lehetősége, hogy "értettem, hogy ez szerinted rettenetes, de csináld, lábon akarom lőni magam), vagy az emberét a dellnél, aki szerint jó ötlet valami ilyen összeakadó certeket kopipasztálni az idracekbe. Ezzel együtt ez még mindig olyan, hogy működésre visszavezethető: azért nem fogadom el, mert ezen a kliensen láttam már ilyen serialt, és ennek nem szabadna így lennie, valami baj van. És ez egyébként igaz is, mégha elég broken is itt az egész PKI, de  ez még mindig nem az "érvénytelen, mert a fejlesztő cégnek nem tetszik" kategória.

( sanyex | 2020. 02. 25., k – 08:20 )

Ha esetleg érti valaki, hogy egy TLS 1.3 cert mitől biztonságosabb a 398. napon, mint mondjuk a 514.-en, akkor az kérem fejtse ki. Én ehhez sötét vagyok, viszont kimennék a fényre.

Én per pill. úgy látom, hogy ez kis lépés az emberiségnek, de hatalmas szívás nagyon sok embernek.

Miért írják rá a sörre, hogy április 10-ig jó, ha utána 3 héttel is ugyanolyan jó?

Azért mert húzni kell valahol egy határt. A szabályokat sokszor azért csináljuk, hogy később egyáltalán tudjuk, hogy mitől terünk el.

Roses are red
Violets are blue
Unexpected '}' on line 32

Csak itt nem élelmiszer-egészségügyi problémáról van szó, ahol az ezredik lejárt sör fog májfunkció leállást okozni, hanem egy általánosan használt szoftver alapvető funkciójáról, ami olyat próbál megoldani, hogy a legrosszabb esetet nézve is életben maradsz. A rengeteg belső, 10-20 évre szól self signed certektől kezdve az ilo, idrac stb certekig sok helyen lesz ez nagy szívás, ha a többi böngésző is követni fogja. Leginkább az az érthetetlen, hogyha a cert kiállítója beírt lejárati egy dátumot, akkor azt miért bírálja felül? Hol, és miért nő itt a biztonság? Úgy érzem, hogy vmi olyantól akarnak megvédeni, amit vagy nagyon nem értek, vagy nem érdekem, és nem az igényekhez kreálnak megoldást, hanem fordítva.

belső, 10-20 évre szól self signed certek

Ugy erted, amiket eddig is kivetellistara kellett rakni? :)

a cert kiállítója beírt lejárati egy dátumot, akkor azt miért bírálja felül?

Nem biralja felul, ha jol ertem a szoveget. Nem lesz az, hogy a 2 eves cert 1 ev utan lejartnak latszik, hanem a 2 eves certet nem fogadja el (by default? gondolom lehet kiveteleket adni itt is)

No még egyszer fuss neki:

- én mint a cert előállítója / megrendelője, azt kérem, hogy 2 évig fogadja el tőlem.

- Ő, mint a cert elfogadója ezt nem teszi meg.

 

Erre te azt mondod, hogy nem bírálja felül a certben beállított adatokat. Hanem?

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( bajnokk | 2020. 02. 25., k – 08:45 )

Az a baj, hogy egy tanúsítvány megbízható visszavonása a gyakorlatban nem működik. Ezért most az a security trend, hogy használjunk minél rövidebb tanúsítvány élettartamokat automatizált kiállítással, hogy ne legyünk arra utalva, hogy a kliensek foglalkoznak-e CRL vagy OCSP ellenőrzéssel. Ha esetleg implementáltál ilyet, akkor tudod, hogy visszavonás-ellenőrzést vagy biztonságosra, vagy hibatűrőre lehet megcsinálni, és nagyon nagy a csábítás, hogy a biztonságosságot félretegyük. (Például azért, mert az ügyfelek nem értékelik, hogy megáll a biztonságos rendszerük, mint a szög, ha egy CRL-t - az ügyfél által befolyásolhatatlan okokból - nem lehet letölteni.)

Ha jósolhatok, akkor én arra számítok, hogy ez a 398 nap még a 2020-as években 8 nap lesz.

Biztonság jelszó alatt ?? Közben a rendszerek meg lyukasak, az apple nem rakott annó jelszó limitet az icloud-ba stb, én úgy érzékelem hogy nem a cert-ek időlimit-jénél van a probléma, hanem ez csupán egy átlátszó marketing húzás, mellyel elterelik a figyelmet és csilloghatnak - ugyanezt gondolnám minden oprendszer esetén, ha a gyártó ezt teszi.

Az automatizálás és a rövid élettartam teljesen ok, amíg a letsencrypt környékén maradunk. Ezzel nincs is baj.

Ellenben ha a kommerciális, sokszor igen drágán megvásárolt tanúsítványokat nézem, ahol majdnem DNS mintát is kérnek a hitelesítéshez, ráadásul pont a biztonság miatt nincsenek automatizált folyamatok, akkor nem vagyok barátja annak, hogy egy böngésző önkényesen ebbe a dologba beleszóljon. Ne a farok csóválja a kutyát.

ahol mi vesszunk a certeket, ott az elofizetesi idoszak alatt barmennyiszer lehet ujrakerni a certet. igaz ez nem "uzleti" cert, "a tenyleg mi vagyunk a tulajdonos"-hoz meg eleg egy dns rekord vagy egy fajl a webserveren.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( gelei v | 2020. 02. 25., k – 10:08 )

Szerkesztve: 2020. 02. 25., k – 10:09

Remelem, hogy a Chrome is atveszi, hadd terjedjen el - szegeny Safari nem eleg ahhoz, hogy onkenyesen "szabvanyokat" hozzon letre.

ezen itt jól látszik, hogy az agyatlan apple haterek szerint ha az apple csinál valamit az gáz, szar. ha teljesen ugyanazt teszik a többiek akkor az meg nagyon is oké. :D grat!

trejcsike is átírhatná a cikket, de kapzsiság rulez, így több kattintást / pénzt hoz. :D

De itt a hír nem arról szól, hogy a böngészők gyártói közösen megállapodtak ebben, hanem arról, hogy az Apple ezt már az idei év folyamán meg is lépi, tehát ő az első aki ezt bejelentette. Lehet, hogy később bejelentik a többiek ugyanezt még idénre, vagy jövőre bevezetik, de az Apple tette ezt meg először.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com 

nem arról szól a cikk valóban, azért szól így és erről a cikk, mert így lehet fikázni. :) 

Ez tök jó. Ezt az "externalize costs" kifejezést az aktív szókincsem részévé kell tennem. :)

A kereskedelmi CA-k többsége érthető okok miatt nem támogatta, az összes böngésző támogatta, így lett 35%-os, ergo sikertelen a javaslat. És a Safari volt az első, aki nekiállt erőből mégiscsak átnyomni. Vicces hely lehet ez a CABforum. El tudom képzelni, ahogyan a Google, az Apple meg a Microsoft képviselői hallgatják a CA-k érveit egy enyhe fölényes mosollyal az arcukon...

Ha megnézed a névsort, azért CA oldalon ott van egy Amazon is, akik yes-t nyomtak.

Amúgy lehet csak megint én vagyok értetlen, de ez miért NEM biznisz a CA-nak, hogy évente adhat el cert-et? Nem tudják a sokéves certek árát mesterségesen g.cidrágán tartani mostantól? 

Mondjuk rájuk jár a rúd mióta az Extended Validation lehúzást a gugli chrome-ban szépen fokozatosan önhatalmúlag kinyírta. Így azért se lehet már extrát elkérni az ügyfelektől. Pedig láttam árlistában Entrust-nál, Digicert-nél, kb. duplázta az amúgy is drága SAN cert-ek árát.

Érdekes volt látni, h. a de facto megbízhatóságba vetett hit hogyan párolgott el szép lassan ebből az iparágból (is). Kb 10 éve voltunk MS-el lobbizni egy banknál, h. OCS-t rakjunk le. Annak része volt az Edge szerver (windows 2008-on futott az application proxy) amit ki kellett rakni direktbe az internetre (DMZ, workgroup mode nem AD), public IP-n! Magyaráztuk h. Mutual-TLS így, meg Secure RTP úgy. Az ephemeral port range (UDP 50.000->59.999) is csak arra a remote IP-ra van kinyitva, amelyiket előtte az ICE protokol leegyeztette a távoli féllel, nem pedig az egész világra hiába úgy tűnik a tűzfal nyitott portok listáján stb. A security-s mérnök meg csak csóválta a fejét, hogy az a certificate meg TLS nem lesz oda elég, bármikor meg tudná ő is törni ha akarja. Aztán csak lett belőle pilot felsőbb nyomásra. Ugyebár a biznic... :)

Mai fejjel azért minden további nélkül már neki adnék igazat. Más világ volt ez még akkoriban.

"Operationally, the current extensive certificate lifetime has repeatedly led to issues, in that Subscribers frequently forget how or when to replace certificates. Aligning on an annual basis helps ensure and streamline continuity of operations, reducing the number of errors users see and disruptions that sites face."

Ilyen érvek vannak mellette. Beszarok, komolyan.

 

Amúgy meg menjen már az összes ilyen "yes"-es cég a picsába. Amennyiben egy cert brute force "törhető" belátható időn belül, akkor kurvára nem számít, hogy lecsökkentik a cert max. élettartamát 2-ről 1 évre, "csak" dupla számítási kapacitás kell hozzá. Aki a 2 éves törését meg tudja oldani, annak ez nem jelent problémát.

De ezzel nem a Manci néni pékség weblapjának, vagy a Kovács fogászat ajánlatkérő formján levő cert-et fogják támadni, hanem "high-profile" célpontokat. Azok pedig bármiféle böngészős barormkodás nélkül maguk is meg tudják oldani, hogy saját cert-jeik 1 évig (1 hónapig, 1 hétig, stb.) legyenek jók, aztán cserélve legyenek.

Nem hiszem, hogy ha pl. az egyik fogyatekos banknal a 2FA login ellenere is havonta kikenyszeritik a jelszocseret a netbankon, akkor olyan hatalmas elvaras lenne evente egyszer lecserelni a certet az emlitett netbank elott. Foleg, hogy az egesz modell egy kalap szar, egesz gyakran van hir arrol, hogy ez vagy az a szereplo kompromittalodott.

Szóval jobb lenne a kalap szar modellel csinálni valamit [s]szarkenegetés[/s] az ACME és a letsencrypt pofátlan tolása mellett. ;)

Főleg, hogy tulajdonképpen ki is csinálja azt a modellt? Mármint alapvetően ők szarják a spanyolviaszt a CAknak, szóval pl a kliens oldali technikai baszakodás helyett akár lenyomhatnák azt is, hogy mostantól akkor teszünk be, ha nem adsz ki egy évnél hosszabb certet. Nyugodtan lehet kérni ilyet, hiszen megbízunk bennük. Ugye? Mert ha nem, akkor pl kurvára mindegy, hogy 1 évig bízunk meg mégiscsak bennük, vagy tovább ;)

( Z0l v | 2020. 02. 25., k – 15:07 )

Ez egy normalis valaszreakcio a CRL es OCSP protokollok kudarcara. A Google-fele CRLSet sem ad jo megoldast (raadasul az kizarolag Chrome-mal megy). Ugyhogy mivel nincs naptej, rovidebb ideig napozunk.

A kulcs visszavonás nem technikai, hanem logikai probléma jelenleg. Viszont az 1 éves időablak rengeteg lehetőséget ad a visszaélésre, tehát ezen logika alapján a 365 nap is túl sok, ergó a válaszreakció rossz. A blacklist adatbázis sync szerintem azért jobb megoldás, mert azt bármikor elvégezhetik, akár késéssel is, de mindenképpen 365 napon belül meg tud történni valószínűleg, de akár pár órán belül, mert eleve net kapcsolaton böngészik a user. A lejárt kulcsokat meg eleve ki lehet dobni belőle, így nem nő a db mérete végtelen ideig, hanem vissza csökken időnként.

A fontos kérdés hogy mi a jó vagy jobb megoldás egy adott problémára. A revoke sync szerintem jobb megoldás mint a topic téma, mert sokkal kisebb időablakkal kezeli a problémát. Innétől kezdve az a gondom, hogy rosszabb megoldást adnak.

Pedig a revoke sync-kel maradhatna a 2 év, szerintem számít infrastruktúrálisan ennek kezelése, főleg a komolaybb certek esetén, ahol komplikáltabb a process. Mindig túl sok a munka, inkább csökkenteni kellene mint növelni, főleg ha van jobb megoldás.

"egy teljesen automatizalhato Let's Encrypt cert mondjuk kevesbe komoly, mint a Turkiye Bilimsel ve Teknolojik Arastirma Kurumu altal kiadott cert?"

Máshogy komolytalan, inkább így mondom. A LE certificate csak annyit garantál, hogy te azzal a szerverrel beszélgetsz, aki az URL végén van. Semmi mást. Nem garantálja például azt, hogy a http://google.business.site oldal a Google tulajdona lenne, csak azt, hogy a site által bemutatott certificate tényleg a google.business.site oldalé és nincs közbeékelődés. Gyakorlatilag a LE a bizalmi részt áttolja a DNS szolgáltatókra, míg egy tanúsítványkiadó más szempontok szerint is validálhat. Azaz a LE megbízhatósága egyenlő a DNS regisztrátorok megbízhatóságával, például azzal, hogy nem adják-e el a google.business.site domaint egy orosz hackercsapatnak.

A LE tényleg annyit tud, és ezért tud olcsó meg automatikus lenni, mert az egész bizalmi részt a DNS-re bízza. Pont ennyivel tud többet az önaláírt tanúsítványokhoz képest.

Mar hogyne lenne technikai problema? Milyen blacklist sync? Ugye az megvan, hogy a bongeszodben csak root CA-k vannak - nem ezek allitjak ki a tanusitvanyokat, hanem interim CA-k amiket a root alairt, ergo az osszes root CA osszes interim CA-janak (es az azok altal krealt interim CA-knak is, mert ameddig vegig lehet vezetni a trustot, addig a kiallitott tanusitvany is ervenyes lesz) a CRL-jet szinkronizalni kellene - good luck, majd szolj ha sikerult. Ha jol emlekszem a Chrome 0,2 masodpercet hajlando varni az IPv6 valaszra mielott fallbackel IPv4-re, cert checkre pedig meg ennyit sem hajlando aldozni, ezert csinaltak a CRLSetet - a Chrome sajat PKI eseten keptelen erzekelni/jelezni ha visszavontak egy tanusitvanyt.

Es amugy erdemes elolvasni hogy 3 evvel ezelott mennyire jol mukodtek a dolgok: https://tacticalsecret.com/the-state-of-crls/

Az OCSP egy tuneti kezeles, talan a legkevesbe rossz megoldas. Ezzel az a gond, hogy ameddig a staple ervenyes (altalaban 1 hetig), addig mindenkeppen trusted lesz a cert akkor is ha idokozben visszavontak (mert a staple-t nem lehet visszavonni - itt kerulunk bele a 22-es csapdajaba).

Eszre kell venni hogy a problema jelen esetben abbol adodik, hogy nem az egyen donti el, hogy kiben bizik meg, hanem a bongeszok fejlesztoi dontik el, kinek a CA-jat tekintik trustednek, mi felhasznalok pedig automatikusan elfogadunk mindent ameddig a bongeszo nem ad valami errort. Sokkal szimpatikusabb ez a megoldas a bizalom kiepitesere (a web of trust): http://web.monkeysphere.info/ mivel a valosagban az ember is kb pont igy mukodik (ha valami idegen jon 20%-os haszon igeretevel, akkor elzavarod, mig ha valamelyik ismerosod ajanlja, akkor eloszor meghallgatod es csak utana zavarod el :))

A Web of Trust nem skálázódik. Ha te egy friss internethasználó vagy, mi alapján alakítasz ki trustot azokkal a szolgáltatásokkal szemben, amit használni akarsz? Például mondjuk egy amerikai szerverrel szemben? Elutazol hozzá USA-ba és kulcsot cseréltek?

Ha nem, és másokban bízol meg, akkor ugyanott vagy, mint a mostani PKI: másra bízod a trustot.

Az alapveto kulonbseg az, hogy a kezedben van a dontes, nem pedig kapod a bongeszovel; illetve attol hogy valamiben nem bizol meg, meg ugyanugy kapcsolodhatsz hozza, csak nem bizol meg benne (nincs ebben semmi baj). Es pont az lenne a lenyege amugy, hogy szepen egyesevel epited fel a trustot es csak akkor bizol meg az amerikai szerverben, amikor valamelyik ismerosod megbizik benne. Az hogy boldog-boldogtalan a letsencryptes tanusitvanyaval emulalja a paypalt, a figyelmetlenek pedig szepen be is verik a user/pass-t baypal.com-on mert hat "van lakat meg nem volt error" az semmivel sem jobb. Orulok hogy a https lett mostmar a standard, de annak nem hogy emiatt lett egy hamis biztonsagerzete mindenkinek.

( Caro | 2020. 02. 26., sze – 14:29 )

<troll>

Nem gond, ezentúl majd ssh-ra alapozzuk a rendszereinket https helyett, ott meg nincs lejárati idő. :)

</troll>