Szankciókat léptet életbe a Mozilla a WoSign/StartCom tanúsítványkibocsátókkal szemben

Titkosítás, biztonság, privát szféra

Nemrég volt szó a Mozilla bizalomvesztéséről a WoSign/StartCom tanúsítványkibocsátókkal szemben. Akkor a Mozilla az általa felfedezett technikai és menedzsmentbeli "hibák" miatt szankciókat helyezett kilátásba. A Mozilla friss blogbejegyzése szerint a szankciókat életbe is léptetik:

    1. Distrust certificates with a notBefore date after October 21, 2016 which chain up to the following affected roots. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the affected roots.
    • This change will go into the Firefox 51 release train.
    • The code will use the following Subject Distinguished Names to identify the root certificates, so that the control will also apply to cross-certificates of these roots.
      • CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
      • CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
      • CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN

        CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN

      • CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
      • CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

    2. Add the previously identified backdated SHA-1 certificates chaining up to these affected roots to OneCRL.

    3. No longer accept audits carried out by Ernst & Young Hong Kong.

    4. Remove these affected root certificates from Mozilla’s root store at some point in the future. If the CA’s new root certificates are accepted for inclusion, then Mozilla may coordinate the removal date with the CA’s plans to migrate their customers to the new root certificates. Otherwise, Mozilla may choose to remove them at any point after March 2017.

    5. Mozilla reserves the right to take further or alternative action.

Részletek itt.

( gee v | 2016. 10. 26., sze – 16:47 )

No longer accept audits carried out by Ernst & Young Hong Kong

Nem gyenge.

Olvass bele csak az elso 10-15 emailbe a regebbi HUP cikkbol is linkelt email valtasba. Egeszen elkepeszto amiket a WoSign-os csoka valaszolgat a Mozillaeknak, teljesen ugy tunik, vagy ko kemeny profizmussal azt a latszatot keltetik magukrol, hogy egy par szemelyes Ver Istvan Bt. az egesz banda.

Ha jol emlekszem ilyesmik voltak a problemak:
- visszadatumozott certek (gyenge hash-ekkel)
- google.com hamis cert ("csak internal, csak teszt, soha tobbet becs szo")
- StartCom webes rendszere adott ki WoSign-os certeket es viszont egy PUT vagy GET valtozo atirasaval, tehat osszekotottek a felvasarlas utan a rendszereket, kifele meg azt kommunikaltak, hogy semmi fele osszekotes nincs.
- lehetett kerni hamis certeket egy hibat kihasznalva, amikor a hibat jelentettek nekik a bejelentett certjet rendesen revokaltak, de a tobbi hasonlot nem (bejelento direkt csinalt maganak tobb hamis certet, hogy megnezze mit lep a WoSign)
- eloirt auditokban meg a bejelentett/javitott hibaknak sincs nyoma

Ezek utan tort angolsaggal mellebeszel, mismasol, amikor kiderul, hogy nem tud valamit elkenni, akkor ertetlenkedik, masra valaszol. A legszebb amikor a kerdesre, hogy "jo-jo, hogy galadsagokat csinaltatok es mostantol minden mashogy lesz, de miert nem derult ki ez az auditokbol" azt valaszolja, hogy hat nem tudott senki annyira angolul, hogy megertsek a Mozilla CA-kra vonatkozo eloirasait es az auditalo szemely sem igazan ert ehez az egeszhez!

A Mozillas csavonak megneztem volna a fejet, de olyan diplomatikusak maradtak, hogy azonnal le az osszes kalappal.

( agostonl | 2016. 10. 27., cs – 11:34 )

Fincsi...

Komolyan mondom, olyan érzésem van ezekkel a tanúsítvány-kibocsájtókkal kapcsolatban, mint nálunk a közjegyzőkkel.
Azért fizetek, hogy kapjak egy pecsétet, amivel kitörölhetem a hátsó régiót.
Ha nincs igazam, sorry.

"Az atombombát és a C vitamint is a Magyarok találták fel...
Mindkettőből elég, napi 500 mg. - by Bödőcs Tibor"

( tigrincs | 2016. 10. 27., cs – 12:38 )

Van valami free ssl alternativa a let`s encrypten kivul?

Nem muszáj automatizálni. A certbot-tól lábrázást kaptam mert fel akart tenni GCC-t meg vagy 30 plusz csomagot, viszont találtam egy acme.sh nevű shell script-et, amit simán userként futtattam és kézzel telepítettem. Én se érzem jól magam attól, hogy egy idegen script matasson a certek között, szóval egyelőre dolgozok egy saját script-en ami a user-ként futtatott cuccos eredményét automatán feldolgozza, mert azért 2-3 hetente cert-ekkel játszani, hát az annyira nem hiányzik nekem...

Én céges viszonylatban se nagyon értem a havi cserélgetést, de itt egyébként 90 nap a cert érvényessége és az automaták általában 60 napnál cserélnek (de ez konfigurálható).

Viszont a legolcsóbb cert-ek is 1500-2000 Ft/év áron vannak (általában comodo dv cert-ek). Eddig volt a vps-emen 1 cert és néhány self signed, illetve mindenféle LAN-os otthoni cuccon is self signed. Ha most egyszeri munkával meg tudom oldani hogy ezekre valid cert kerüljön, ráadásul még évente/kétévente se kell újítgatni hanem intézi "magától", akkor ezzel egyrészt spórolok egy kisebb összeget, akkor szerintem megéri foglalkozni vele. Pláne hogy érdekel is.

you can install Certbot on your own computer and use it in manual mode. In manual mode, you upload a specific file to your website to prove your control. Certbot will then retrieve a certificate that you can upload to your host

Ha a certbot-tal az a gond, hogy biztonsági rizikó, akkor esetleg egy sandboxban/másik gépen futtatva, és kézzel vagy scripttel másolva a tanúsítványt?

Igen, tudom, de nem akartam sehova se _installálni_ a certbot-ot. Nekem egy viszonylag egyszerű eszközre volt (van) szükségem ami intézi ezt a certificate-es kommunikációt. Egy olyanra ami készen van, amit letöltök és megy. Ha 16.04 ubuntun lennék akkor valszeg jó lenne a certbot is (van csomagban), de 14.04-re nincs, Szóval itt azzal kezdené, hogy felrak egy csomó dev csomagot és - gondolom - fordítgatja a letöltött forrást. Én pedig ezt nem szeretném.

Úgy emlékszem, azt írták, a certbot az ajánlott, de nem kell feltétlenül ezt telepítened.

Nem emlékszem, hogy mást is említettek volna, de bizonyára vannak más alternatívák, vagy akár te magad is készíthetsz egyet. Gondolom nyílt, hogy hogyan működik az igénylés, bizonyítás, cert megkapása.

Nekem, Debian alatt egyébként certbot-python vagy mi a csomag, szóval feltételezem egy python scriptről lehet szó. Nem ellenőriztem mondjuk.

Igen, ezért választottam mást. A LE oldalon vannak listázva a kliensek, és az acme.sh ezek egyike aminek a bash elég. Meg talán a dash és még más "butább" shell-ek is, de ez annyira nem érdekelt szóval nem emlékszem rá.

Ez nekem pont elég arra amire kell, megcsinálja dedikált user-ként a cert-es bohóckodást, erre majd faragok egy saját script-et ami root-ként diff-eli az élesekkel, ellenőrzi is, és ha minden ok akkor lecseréli az éles cert-et, reload/restart amire kell, majd küld nekem egy email-t arról hogy mit végzett.

Ja, azt akartam kérdezni, mert nincs még igazán tapasztalatom vele (eddig StartSSL-t használtam), hogy ha nem weboldalhoz kell, hanem pl. levelezés alá tenném (SMTP alatt TLS, submission porton TLS, IMAPS), arra lehet-e valahogy külön tanúsítványt kérni a let's encrypt-től?

Pl. van egy mail szerverem, ami kiszolgálja az akármi.hu domain levelezését. Ehhez van hozzáférésem.
Nincs rajta httpd, és az akármi.hu domain név más IP címre mutat, egy olyan gépre, amin webszerver van, és én nem férek hozzá.

StartSSL esetén az emailcímet kellett tudnom olvasni, ez volt a megerősítés.

Let's encrypt esetén mi a mód?

Alapból valóban a webserveres móka megy (az acme.sh egy .well-known mappába tesz egy fájlt, valami szép hosszú fájlnévvel, ha jól rémlik), a másik alternatíva a DNS-es validáció, ahol egy TXT rekordot kell elhelyezned. (https://github.com/Neilpang/acme.sh/tree/master/dnsapi - sajátot is lehet hozzáadni)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( hzsolt94 v | 2016. 10. 28., p – 23:01 )

Egy dolgot sajnálok fejlesztőként: egyedül a StartSSL adott lehetőséget arra - elérhető árban -, hogy kézzel összerakott, több wildcardot is tartalmazó, univerzális certeket lehessen generálni. Ez sok felhasználós, meg oktatási jellegű szerverparkokon nagyon kézre állt, igazából nem is tudom hogyan fogjuk megoldani hogy https alatt ezres nagyságrendű aldomaineket ki tudjunk szolgálni több eltérő fődomain alatt. Valószínűleg az egyetlen megoldás az a külön-külön wildcard cert lesz minden szolgáltatáshoz (fődomainhez), és vagy az SNI-t elvárjuk vagy az IP-kel bűvészkedünk.

Felhasználóként ugyanakkor tökéletesen megértem és támogatom hogy a nem átlátható CA-knak mennie kell, jó lenne ha ez nem egyedi eset hanem általános elvárás lenne, nem csak a mozillánál.

( gee v | 2016. 10. 29., szo – 00:55 )

Az érdekelne engem, hogy ha a Mozillának a Google adta le a drótot, és kiderült a visszadátumozás, az, hogy google.com domain-re készítettek certet "csak tesztelésre", stb. meg más csúnyaságok, akkor most ez csak a Mozillának volt elég arra, hogy szankciókat léptessen életbe?

Chrome-ban ezek szerint továbbra is működni fog a StartSSL által "tesztelésre" kiállított google.com domainre szóló tanúsítvány?

És a többi böngésző?

Chrome AFAIK simán a rendszer által megbízhatónak jelölt CA-kat támogatja, a Safari/Explorer|Edge pedig valszeg szintén rövid időn belül kiveszi, hiszen ők is tagjai a CA Browser Forumnak, aminek a követelményeit megsértették.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom…

"Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted. Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom."