startssl vs. mozilla

"Mozilla decided to distrust all StartCom root certificates as of 21st of October, this situation will have an impact in the upcoming release of Firefox in January. StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested. Meanwhile StartCom is updating all their systems and will generate new root CAs as requested by Mozilla."

Ejha.

( csardij v | 2016. 10. 24., h – 20:29 )

Forrás? Gugli nem talál semmit még erre a szövegre.

Nem pont ezzel a szövegezéssel, de lefedi (illetve plusz infókat is ad): https://blog.gerv.net/2016/10/wosign-and-startcom/
___________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Az a legkevesebb, a treyblogon levő posztban linkelt doksiban sokkal brutálisabb dolgok is vannak (visszadátumozott certek mind a WO-tól mind a felvásárlás utáni StartSSL-től, hogy adhassanak SHA-1 certet speckó felhasználásra a szokásos procedúra megkerülésével, github.io-ra kiadott certek (speciel bármire kérhettél, ha egy domain-t autholtál :) ) stb....)

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

De hogy a francba tudtak a github.io -t autholni? Marmint, azert az nem kevesse trukkos dolog.

Nekem siman nem engedtek olyan domainre certet kerni, amire nem volt authom. Egyszer typo volt a req eloallitasa soran, es nem vettem eszre, egyre csak bosszankodtam, hogy mekkora fos ez, hogy nem adja ki a certet. Aztan persze meglett a problema oka.
--
Blog | @hron84
Üzemeltető macik

Pont ez a lényeg, hogy azt nem kellett autholniuk, hanem egy másikat.

És rosszul emlékeztem, nem a reportban, hanem a wikiben volt:
https://wiki.mozilla.org/CA:WoSign_Issues
Issue N: Additional Domain Errors (June 2015)

Bug N1 was an issue where someone proving control of .example.tld also was given a cert covering example.tld.

Bug N2 was an issue where arbitrary domains can be added to an existing request after validation.

The reporter proved that there was a problem in two ways. They accidentally discovered that there was a problem when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then used their control of schrauger.github.com/schrauger.github.io to get a cert for github.com, github.io, and www.github.io. They also obtained another github cert using a different subdomain of github.io. These are both, in fact, instances of bug N2.

Szerk.: ill. a másik része... pár éve találkoztam egy előadással, hogy mennyire ótvar az X509 és mi minden szutykot lehet belepatkolni a csr-be, amire garantáltan nem figyelnek a CA-k és hogy hány nagyon komoly CA-tól lehet egy kicsit kreatívabb csrral gyakorlatilag akármire certet szerezni...

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

Kapcsolódó kérdés-kérés: van CSR boncoló / alapozó (megosztható publikusan) leírásod/prezentációd neked v. bárkinek aki olvassa ezt?
Megmagyarázom.

Legfrisebb élmény, h. 1 aplliance-en generáltattam CSR-t. A kimenetet elküldtem aláírásra egy privát CA üzemeltetőjének. Az a válasz jött vissza, h. ők már nem engedélyezik az SHA1 használatát, csak az SHA256-ot. Az én CSR-em meg SHA1-et tartalmaz, legyek szíves újat generálni, de mostmár SHA256-al. Elkezdtem vakarni a fejem, h. ez az egész aktuális SHA1-->SHA256 átállás mizéria az IT világban miről is szól pontosan? Egy CSR-be mi is kerül bele pontosan? Ezek közül a CA miket is ellenőriz le, miket változtathat meg kénye szerint mielőtt aláírná? Pl. a CA saját jogkörben határozza meg legjobb tudomásom szerint, h. a cert-ben az aláírást milyen algoritmussal hash-eli (alias "signature hash algorithm"). Azaz ha a CA-ban a kiindulási feltételezés szerint az SHA256 van beállítva, akkor az én CSR-em lehet bármilyen, csakis 1 féle válaszfájlt (valójában a válaszfájl A nagybetűs tanúsítvány maga) adhat rá a CA: SHA256 "signature-hashed"-et. Az viszont igaz, h. a CSR-t openssl-el analizálva SHA1 szerepel signature hash algoritmus helyen. De ez almát-körtével összahasonlítás esete: az az SHA1-es hash csak a CSR hitelesítésére szolgál a CA felé, h. út közben nem manipulálta senki a CSR-t. Az IT ipar SHA256-ra történő migrációs mozgalmának célja a VÉGLEGES aláírt tanúsítvány Signature hash algoritmusát akarja SHA256-ra tenni, nem a köztes CSR fájlt!

Na én ezt próbálnám helyrerakni a fejekben, ha lenne róla vmi jó, lehetőleg MSFT PKI-n alapuló színes-szagos powerpoint (vmi nevesebb PKI guru előadásából), ami kiemeli h. az egyik SHA1 meg a másik SHA256 az két teljesen különböző dologra való!

Gugli sok kókler indiai blogot kidob PKI témában, de azokról süt h. még ők se értik az ok-okozat közötti összefüggést. Általában csak kijött vmi ordas hülyeség végén nekik a jó eredmény véletlenül, gyorsan aláhúzták 2x, magyarázat semmi oszt csókolom! Na ezért keresek pedagógiailag is korrekt prezentációt.

Átkozottul nehéz az egyszeri IT-s embernek megérteni ezt a gyakorlati PKI-t, mert nincs róla jó könyv, amit a halandók is megértenek! Az elmúlt 5-6 évben ami könyvet találtam a témáról, az 2 kategóriába esett:
1) a Brian Komar féle Microsoft PKI on Windows Server 2008 és a 2) kismillió Public Key Infrastructure design Plan stb. típusú könyvek.

Az 1) egy pár oldalas összecsapott, minden pedegógiát nélkülöző gyorstalpaló után már a CA adatbázisfájl szerkezetét elemzi, az egyszeri IT ember meg csak pislog h. ez mi a f@sz-ról beszél itt?
A 2) típusúak meg 100 oldalakon keresztül lamentálgatnak azon, h. mit is jelent az h Public meg Key de főleg mit az Infrastructure. Végigszenveded a 600 oldalt, és 1 szo nem volt benne SHA1-ról.
Az optimális 3) alternatívát meg még senki nem ült neki megírni.
--

Sajnos nincs prezim, amiből nekem anno a legtöbb dolog képbe került a PKI-ból, az a Bounce Castle (egy pure-Java crypto lib) "gyorstalpalója" volt (pl. fontosabb kiterjesztések) ill. hogy játszottam egy kicsit az API-val.

Egyébként ha tippelnem kéne: azért kell aláírnod a CSR-t, hogy bizonyítsd, hogy rendelkezel a publikus kulcshoz tartozó privát kulcssal (fenti doksi 3.8.2.1-es szakaszban írják). Ha jól tippelem a PKCS#10-nél kötelező (a PKCS10CertificationRequestBuilder build metódusának át kell adnod egy ContentSigner-t), a CRMF-nél (mert úgy tűnik, ilyen is van :) ) viszont nem.

Hogy miért fontos, hogy ne SHA1 legyen, amit te is írtál: a SHA1-nél már (megfelelően nagy számítási kapacitással) megoldható a hamisítás. Ha tippelnem kéne a CAB szabályzata a SHA-1 tanúsítvány aláírással egyidőben megtiltotta, hogy SHA-1-el aláírt CSR-t kezeljenek, de a 60 oldalas jogi szöveget most nincs kedvem átolvasni ezért :)

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

"Ha tippelnem kéne a CAB szabályzata a SHA-1 tanúsítvány aláírással egyidőben megtiltotta, hogy SHA-1-el aláírt CSR-t kezeljenek, de a 60 oldalas jogi szöveget most nincs kedvem átolvasni ezért :)"

Mivel halvány lila fogalmam nincs mi az a "CAB" (tippre egy MSFT tömörítvény formátuma, vagy a Change Advisory Board rövidítése, de acronymfinder még kidob biztos 2 tucat jelentést), csak annyit tudok kérdezni h. TECHNIKAI akadálya lehet-e pl. egy Windows Server 2012 (R2) CA-n aláíratni egy SHA1-es CSR-t ha a végleges cert már SHA256-al jön ki a CA-ból, v. ilyen SHA1-es CSR-ekre nem vonatkozik az algoritmus közeljövőbeni betiltása?

--
WP8.x kritika: http://goo.gl/udShvC

Szerintem technikai akadálya nincs. A CAB a CA/Browser forum (https://cabforum.org/), akinek a szabályzata miatt kellett a WUSignnak visszadátumozott certeket adnia (ők határoztak, hogy jan. 1-től nem adható ki SHA-1 cert, csak előzetes engedély/elbírálás szerint)

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

( tigrincs | 2016. 10. 25., k – 16:49 )

Es ez miben nyilvanul meg? Vagy mar van uj root cert? Gyorsan megneztem mozilla alol az oszes startssl-es domainem es mind szep zold...

Illetve implementálnak +1 eszközt a mozillába, miszerint csak az október 21 után kiállított certeket nem fogják elfogadni.
Hogy ezt a hamisítások ellenére hogyan kivitelezik, egyszerű, monitorozzák. Ha csalnak, a root certet fogják eltávolítani

"StartCom and WoSign will no longer be trusted in Mozilla’s root store for certs issued after 21st October"

Jelen állapotok szerint nem lesz új root certjük, valószínűleg ezzel végleg elvágták magukat

// Happy debugging, suckers
#define true (rand() > 10)

ezzel végleg elvágták magukat

De legalábbis egy évre (az eredeti report egy éves tiltást javasolt), és egy-két feltételnek meg kell felelniük (pl. külsős, Mozilla által jelölt cég általi audit)

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

( csardij v | 2016. 11. 03., cs – 09:06 )

Mostanában járna le a validációm, így rákérdeztem, hogy mi a helyzet.

Annyira gáz, hogy ezt írták vissza:

I apologize for the concern it aroused but currently I won’t suggest you to renew the service. Apologize and thanks.

És ki is raktak egy hírt: https://startssl.com/NewsDetails?date=20161103

használj lets encrypt-et. Tudom, csak 3 hónapra adják, viszont automatizálható a megújítás (berakod cronba hogy havonta/hetente megbökje - mert van direkt cron feature-je ami csak akkor frissíti ha valóban kell - aztán elfelejted örökre)

// Happy debugging, suckers
#define true (rand() > 10)

Találtál már másik szolgáltatót? Ha igen, ki a szerencsés kiválasztott? Van egy Class2-es csomagunk (a StartSSL-nél), ami januárban jár le, és azzal együtt számos *.domain.hu alakú cert is, de a support (tegnap) azt írta, hogy kb 2-3 hónap még, mire az új ROOT CA-k elkészülnek. Jó lenne valami hasonló szolgáltató, ahol azonosítás után tudunk saját domainre akármilyen certet készíteni.

Hátőőő...
https://www.cacert.org/index.php?id=1

A kapcsolat nem biztonságos.
...
www.cacert.org uses an invalid security certificate.

Persze van megoldás a FAQ-ban:
http://wiki.cacert.org/FAQ/BrowserClients#Mozilla_Firefox

"New versions of Firefox (as version 39.0 on Linux Ubuntu 14.10) don't permit importing of the CAcert Root cert (root.crt, root.der) as its signing algorithm MD5 is treated as obsolete and not secure. Simply use the add-on stated above."

Nem érzem, hogy ezzel előrébb lennénk. :)

Nem tudom számít-e még a Let's Encrypt tanúsítványok mellett, de van SHA256 aláírt CAcert Root certificate (bár a CAcert.org oldal root cert oldalán még az MD5 aláírt jelenik meg...).
- https://wiki.cacert.org/Audit/Results/session2016.1
- http://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/o…
- https://blog.hqcodeshop.fi/archives/335-CAcert-Root-Certificate,-SHA-2-…
Ha esetleg valaki használ manapság CAcert.org-os tanúsítványokat, írhatna pár sort a tapasztalatairól.
--
Légy derűs, tégy mindent örömmel!