Wellicht handig te vermelden om welke TSP het gaat.
Dat voorkomt ontrust en onnodig werk.

Goede actie van Logius. Zo zie je maar dat ICT en overheid wel samen kunnen gaan. Logius is hiervan een bewijs. PKI Overheid zit goed in elkaar en ze ondernemen acties indien noodzakelijk.

Verschil tussen negatieve en positieve integer.Scheelt een factortje onveilig. Dank aan de graaiende lutser.

Eens met reactie hierboven. Logius pikt zijn verantwoording goed aan hier en is inhoudelijk sterk op de hoogte.
PKI-O is een gedegen product en met goede bewaking blijft dat ook zo.

2 en een halve maand TE LAAT...

ICT en overheid goed?

http://blog.ejbca.org/2019/03/ejbca-701-psd2-and-sn-entropy.html

De fout zit bij een conmerciële leverancier die niet snel genoeg in actie kwam.

Hoe bedoel je? Het probleem bestaat zo te zien al bijna 2,5 jaar. Dus hoe bedoel je 2,5 maand te laat? Ik heb dit namelijk nergens kunnen lezen.

Daarnaast men neem actie, en durft ook actie te ondernemen.

Anoniem en duidelijk?

Neen de fout zit bij de graaier, die zijn Technische IT dit niet goed laat verifieren
of liever tegen een te goedkoop urentarief dit laat gebeuren.

Zij, die bepalen, hebben er geen verstand van,
en degenen die er verstand van hebben, krijgen niet het respect,
dat ze verdienen en mogen er zelfs niet meer toe doen.

Mooie praaatjes vullen geen certificeringsgaatjes en nog steeds.
Bitwiper kom er maar in man, ik mis je analyse in deze.

De echte betrouwbare IT-staff met expertise,
komt daar echt z'n bed niet meer voor uit, zeker niet jobs tegen het huidige Londense uurtarief,
fink minder als in Berlijn bijvoorbeeld.
Bij sinkholen krijg je voor een paar uurtjes online remote analyse al gauw het dubbele.

Er komt niet voor niets een harde Brexit aan, let maar op..
De moderne grootgraai Scrooge is de schuld van dit alles,

De rekening zit nog altijd later onder in de zak en dan nog "Oj & weh" roepen

#sockpuppet

Volgens mij is het open source software en iedereen die een beetje kan rekenen kan er toch vanuit gaan dat als je als EIS 64 bit serienummer hebt en je hebt alleen EVEN getallen die meetellen dat je dan een 65 bit serienummer moet hebben, of ben ik nu zo slim en logius zo dom.

Volgens mij ook niet, of in elk geval maar zo ontzettend minimaal dat het geen noemenswaardig risico is.
Als je maar oplet of je naar de bedoelde website gaat. (net als anders)

(zie ook de reacties bij https://www.security.nl/posting/601348/Apple%2C+GoDaddy+en+Google+maakten+fout+bij+uitgifte+certificaten)

En het risico is kennelijk dat de certificaten op den duur mogelijk door bepaalde browsers niet meer geaccepteerd worden, met een beschikbaarheidsprobleem als gevolg?

Is het nou een fout in EJBCA of hebben TSPs de verkeerde instelling gedaan of krijg je van EJBCA een 63-bits nummer als je 64 bit had ingesteld?
Vertel gewoon eens wat meer...

Fout van EJBCA, ze hebben een "signed int" voor dit veld gebruikt, waarbij het eerste bit aangeeft of het postief (bit = 0) of negatief (bit = 1) is. Maar serienummers zijn altijd positief, dus het eerste bit was altijd 0.
Als het goed is, hebben ze er nu een "unsigned int" van gemaakt en meteen maar de default lengte opgevoerd van 8 byte (64 bit) en 20 bytes.

Het verschil gaat niet over de mate van onveiligheid. Het verschil zit tussen werk van iemand, die weet wat ie aan het doen is of maar een beetje zit te gokken.

Je moet je onderbouwende theorie toch beheersen? Het is net als iemand laten werken met een lambda generator, die niet eerst de toets met een toegelaten rekenmachine heeft gedaan en dus bewezen heeft te weten wat ie doet en waar ie mee bezig is.

De kortste en goedkoopste weg is niet altijd de veiligste. Let's encrypt heeft wel voor een stuk downgrading gezorgd, wat dit betreft. Dat disrespect wreekt zich nu. Weer een stukje" Google-isatie", noem ik dat. Denk zelf na en volg niet AI blindelings.

luntrus

Op het moment dat EJBCA de (signed) 63bit configuratie had, was 64 bit entropy nog geen eis, dus het was prima in orde.

Later zijn de eisen aangepast, en is ook de EJBCA config aangepast, deze ondersteund een entropy die vele malen hoger is - zolang het maar geconfigureerd is.

Er zijn dus geen bugs, of fouten bij EJBCA, de eisen zijn veranderd en niet door de beheerder in de config aangepast !

Huh ?

De RFC auteurs waren zo dom om de spec hier wat dubieus te laten, de (open source) developers van EJBCA waren zo dom om de default zo in te stellen dat er certs uitkwamen die in dit opzicht niet aan de baseline requirements voldoen , en zowel GoDaddy, Google, Apple en één van de leveranciers van PKI Overheid waren zo dom om die default zo te laten staan.

En de verzamelde experts spotten het probleem pas toen er gezocht werd naar een technisch argumentje om een moreel twijfelachtige CA (Darkmatter) als trusted root weg te halen.

Ik vraag me af waar die '2.5 maand' claim vandaan komt.
De discussie op de mozilla dev lijst over Darkmatter lijkt op 22 feb te duiden als eerste indicatie, de blog van Adam Caudill is van 9 maart , en een update vanuit EJBCA met betere default is van 4 maart . (zie hun blog).
[dat het een issue is, valt uit de ejbca website bepaald niet op te maken... ]

Uit het Logius bericht blijkt dat de niet compliant certificaten tot 5 maart ge-issued zijn.
Ik leid af "binnen 1 dag na de vendor update opgelost" .

Jeez. De reflex posters "Overheid Kan Niks" mogen zich echt eens gaan schamen.

Uit de ejbca blog van een nieuwe versie :

==========
Configurable SN Entropy, Default Value Raised to 20 Octets
CA/B Forum requires the use of 64 bit entropy when generating serial numbers (see CABF Ballot 164). Due to only positive values being valid serial numbers, 8 octets will only result in 63 bit entropy as the most-significant-bit will always be 0, hence we recommend larger sizes than 8 octets. Previously this was set using the property ca.serialnumberoctetsize in cesecore.properties, which has now been dropped and the value is instead set directly in the CA.
Possible values may range between 4 and 20 octets, and the default for all new CAs is 20 while upgraded CA's will retain whatever value was set in ca.serialnumberoctetsize, or 8 if none was set.

==========

Je stelde blijkbaar (in een configuratie bestand zo leid ik af, en in de nieuwe versie in een drop down) een aantal octets in, dat default op 8 stond . En je kreeg daar in de code een signed integer voor, dus netto 63 bits.
Met als eindresultaat dat je dan niet letterlijk voldoet aan een baseline requirement van 64 bits entropie .

Ik heb nog geen werkelijke risico analyse gezien , en ik heb heel sterk het idee dat enig risico zeer beperkt is.
Maar het is wel een technische eis en dan volgt de procedurele consequentie "niet compliant, intrekken".

Wat een gelul om een serienummer dat niet voldoet aan een of andere absurde eis.

Volgens Logius is er geen sprake van een beveiligingsrisico en ik zie dat ook niet: een serienummer moet uniek zijn en that's it. Als je randomness zou vereisen (ik zie niet in waarom maar wellicht mis ik iets) wil je, naar de huidige maatstaven, tenminste 128 bits zien. Ga dan niet mierenneuken over 63 versus 64 bits.

De enige reden voor deze paniek zou kunnen zijn dat browsers (nu of binnenkort) vallen over serienummers kleiner dan 64 bits, maar ik heb geen idee of zoiets aan de orde is, en zo ja, waarom die eis ineens oppopt.

Tot iemand mij uitlegt waarom dit een issue is vind ik het schandalige verspilling van belastinggeld en erger, het leidt af van veel belangrijker zaken.

KPN.

Quo Vadis no problem

Het technische issue zie ik ook niet , en ik ben nog geen analyse ervan tegengekomen.
De serial moet binnen de CA uniek zijn, en als het gaat om hash collisions lijkt het me dat je dan heel erg grote hoeveelheden certs moet bestellen bij een CA om een collision binnen de certificaten van die CA te krijgen. Ik denk niet dat dat goedkoop of onopvallend kan.

Maar het blijft wel een certificaat dat niet voldoet aan de technische eisen die in de baseline spec staan - en nu google, apple en GoDaddy ze allemaal hebben ingetrokken is het niet verdedigbaar dat PKI overheid hier een peanuts bedragje [op overheids breed ICT budget] gaat zitten besparen en rond blijft lopen met 'risico certificaten' .

Ik vind het logisch en terecht dat een minister geen politiek kapitaal gaat verbranden aan de kamer discussie 'Google en Apple en GoDaddy zijn nodeloos voorzichtig wij weten beter er geen risico is voor PKI Overheid en besparen zo een klein beetje' .

Sterker - het probleem werd gevonden toen gezocht werd naar een technische stok om Darkmatter uit de root store te slaan.
Wil jij in die context adviseren dat PKI Overheid moet doorwerken met niet compliant certificaten ?

Kan niet, want dan heb je weer dat dat ene bitje '1' zou moeten zijn, dan houd je de andere helft van die 64-bits over en dus hetzelfde probleem..

yep, het voorkomt vooral kritiek dat er niets aan gedaan wordt.

Waarom is dit geen beveiligingsrisico?
Als een certificaat plotseling wordt ingetrokken, dan heb je geen beveiligde verbinding meer.

Het gaat om de KPN CA's. Zie ook https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/r9C_Mh9Du_g


Die 'absurde eis' is er (als ik de begeleidende tekst mag geloven) in gekomen om hash-collisions lastiger te maken in het geval dat de hash functie daar minder goed tegen bestand lijkt (nadat dit voor MD5 het geval bleek te zijn). Ze zijn onderdeel van een minimum set met eisen die door alle CA's gevolgd dient te worden. Certificaten welke niet aan die minimum set met eisen voldoen, dienen volgens dezelfde eisen binnen 5 dagen ingetrokken te worden. Je kan het leuk vinden of niet, maar er is nu eenmaal gezamenlijk afgesproken dat dit de regels zijn waaraan een CA moet voldoen. Dat is voor een deel natuurlijk ook waarom ze het vertrouwen genieten om als root te fungeren.

Interessant is natuurlijk dat het hier gaat om het PKI-Overheid stelsel. 'Belangrijke' publieke zaken als digid.nl hangen hier van af, maar volgens mij ook redelijk wat b2b/m2m communicatie binnen het hele diginetwerk van de overheid. Dat gaat natuurlijk aardig in de soep lopen als die zomaar worden ingetrokken. Ik vind het opmerkelijk dat Logius voor doet komen alsof de 30 revocatie zomaar oke zou zijn. Volgens mij zouden de certificaten binnen 5 dagen (dus aanstaande zaterdag als ze er maandag achter kwamen) al ingetrokken moeten zijn. Als je dan een appel wil doen op operationele risico's, zoals meerdere andere CA's doen/deden, laat dan zien dat je ieder geval je best hebt gedaan. Gelijk laten weten dat alles binnen een maand opgelost moet zijn en voorbij gaan aan de 5 dagen eis lijkt mij niet de juiste houding.

Apple heeft binnen 5 dagen al meer dan 350K certificaten ingetrokken, waarna er nog zo'n 23% overbleef. Google heeft in die 5 dagen 86.5% van meer dan 100K certificaten ingetrokken. Dat laat zien dat het automatiseren van de uitgifte zo zijn voordelen heeft bij een mass revocation. Wellicht een les voor te toekomst voor andere CA's?

Als positieve noot is het natuurlijk goed om te zien dat dit probleem gemeld wordt. Er zijn volgens mij nog wat vraagtekens of dit probleem wel goed te detecteren is in uitgegeven certificaten. Dat zou het interessant maken als CA om je mond te houden om zo geen mass revocation te hoeven uitvoeren, zonder betrapt te kunnen worden.

@ Bitwiper & Acrimony,

Als we hier eens nalezen: https://adamcaudill.com/2019/03/09/tls-64bit-ish-serial-numbers-mass-revocation/
hebben jullie in feite beiden gelijk, maarnaar mijn bescheiden mening is er hier meer sprake van een gelegenheidsexcuus om o.a. van DarkMatter CA af te komen.

Steeds meer blijkt dus dat browser-makers in CA-land de toon gaan zetten met een lange termijnpolitiek,
die door hun agenda is ingegeven. De achtergronden, daar is nog raden naar. Niet zuiver veiligheidsoverwegingen,
maar ook weer het monopoliespel en zoveel mogelijk zeggenschap over de toonzetting (regelgeving naar je hand zetten).

Het begon destijds met de Symantec battle. Symantec, die de pijp aan DigiCert doorgaf met een bijrol voor Comodo.
Dit alles gespreid over een genoeg lange periode, dat het financieel gezien minder pijn zou gaan doen voor afnemers.
Symantec's certificaatstokoballon nu volledig leeg gelopen.

Ik kwam als 3rd party cold reconnaissance website security analyst nogal eens hier: https://cryptoreport.websecurity.symantec.com/checker/

M.i. heeft het allemaal te maken met meer of minder certificeringstransparantie:
Checken:https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=SO28983

Test zelf eens op CT (Certificate Transparency) .https://www.entrust.com/ct-search/
En domein check ook (sub-domain(en)) hier: https://www.entrust.com/ct-search/

Voor TLS etc. test hier: https://geekflare.com/ssl-test-certificate/

Mijn vraag is? Was dit een stok zoeken om een bepaalde hond te kunnen slaan (DarkMatter etc.).
Is qua veiligheidsimplicaties er van alles met de haren bijgesleept? (mening van onze vriend Bitwiper, denk ik).

Natuurlijk moet men de afspraken volgen, maar hier kwam het toch wel weer bijzonder goed uit.

Wat is de lange termijn agenda van Google (chromium) & Mozilla browser-makers in deze?
Speculeren in dit geval. Want geen insider heeft het mij nog verteld.

Er is wel naar te speculeren net zoals over het voortdurende gesjacher rond de Brexit.
Straks wordt het besluit via een verkregen uitstel over de datum van verplicht invoeren van de euro getild (2020)
en dan is er voor Londen geen weg meer terug, want ze hebben mogelijk geen Brits Pond meer.
Of ze hebben op dat punt al wat anders afgesproken dan met alle andere EU-leden.

Maar ik heb over die laatste mogelijkheid en politiek nog niets vernomen,
men moet dus steeds zelf nadenken, want een ander doet het meestal niet voor je.

Worden er door browser-makers op instigatie van wie dan ook de nodige protocol-spelletjes gespeeld?

Overigens wordt certificeringsmisbruik steeds meer een security issue,
aangeduid als SMU::EE malcode, vaak misbruikt door spamvertisers alsmede trackback malcreanten.

Voorbeeld om te checken: https://certificate.revocationcheck.com/
Zie: htxps://www.hybrid-analysis.com/sample/76282e7506de8f2d97eaa0957873ac55741768783b6062e07de952eeeddfbb73?environmentId=100.

Graag jullie beider gewaardeerd commentaar?

#sockpuppet

Ik niet dat het tempo van terugtrekking te maken heeft met automatisering bij de CA's , maar met de impact en deployment bij de gebruikers van de certificaten , en hoe goed die updates geautomatiseerd hebben.

De CA's van Apple en Google werden voor een heel groot deel intern gebruikt. Ik denk dat het grote volume van certificaten dat snel teruggetrokken kon worden certificaten betreft waarbij _de gebruiker_ de vernieuwing en deployment geautomatiseerd had. (vele interne gebruiken zullen certificate updated geautomatiseerd hebben ).
Ik denk dat batches die Google en Apple nog niet teruggetrokken hebben degenen zijn waar vervanging niet op die termijn gedaan kon worden.


Dit deel heb ik heel vluchtig gelezen, maar het kwam meen ik uit statistiek op uitgegeven certifcaten.
(En werd gedaan bij het zoeken naar fouten gemaakt door Darkmatter).
Nu bekend is dat dit een fout kan zijn, denk ik niet dat je als CA met publiek uitgegeven certificaten je mond kunt houden zonder risico betrapt te worden op dezelfde manier.

Update op mezelf : De link van Acrimony (thx) geeft de tijdslijn gezien vanuit Logius .
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/r9C_Mh9Du_g

Dat de betreffende TSP na 5 maart geen 63 bit certificaten heeft uitgegeven was als gevolg van een eerder genomen besluit om naar 96-bit serials te gaan , en niet het gevolg van het heel snel installeren van een nieuwe EJBCA versie.

Na wat leeswerk (met name de antwoorden van Jack Lloyd en Thomas Pornin in https://crypto.stackexchange.com/questions/257/unpredictability-of-x-509-serial-numbers), denk ik de reden te begrijpen om een random serial number te gebruiken. Het doel lijkt om een potentieel andere kwetsbaarheid lastiger exploitable te maken.

Bij die andere kwetsbaarheid gaat het om hash collisions in de digitale handtekening onder het certificaat, zoals aangetoond in 2008 door Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik en Benne de Weger in hun "hash-clash" onderzoek aan de TUe (TU Eindhoven, zie https://www.win.tue.nl/hashclash/rogue-ca/). Voor degenen die niet weten hoe dat werkt, de volgende uitleg.

Een digitale handtekening maak je door een cryptografische hash over een document te berekenen, waarna die hash wordt versleuteld met de private key van de ondertekenaar (de certificaatverstrekker in dit geval). Nb. wat we in de praktijk gemakshalve een certificaat noemen, is feitelijk het echte certificaat + digitale handtekening (bijv. Wireshark zie je dit netjes opsplitsen).

Bij het ondertekenen van een certificaat gebeurt, in essentie, het volgende. De certificaataanvrager levert een CSR (Certificate Signing Request) in bij een CSP (Certificate Service Provider). Die CSP checkt of de public key daarin echt hoort bij het "subject" (zoals de domeinnaam in het geval van een website of een e-mail adres in het geval van een S/MIME certificaat). Als dat klopt zet de CSP een digitale handtekening waarmee het CSR een certificaat wordt. In de basis zou je dus exact dezelfde digitale handtekening moeten krijgen als je hetzelfde CSR nogmaals indient bij dezelfde CSP.

Het ligt echter wat ingewikkelder, want de CSP wijzigt verschillende velden in het CSR, zoals datum en tijd waarin de geldigheid ingaat en eindigt, maar ook het certificaat-serienummer (deze wijzigingen vinden natuurlijk plaats vóórdat de CSP ondertekent).

De "hash-clash" aanval van de TUe was mogelijk doordat dat zij de waardes van alle velden die de CSP wijzigde vlak voor het ondertekenen konden voorspellen, en daarmee de waarde van de hash. Dankzij het feit dat zij precies konden voorspellen wat de inhoud zou worden van het certificaat, en dus de resulterende waarde van de hash (toen nog MD5), konden zij hun feitelijke aanval uitvoeren, namelijk een MD5 hash collision realiseren.

Het risico daarvan bestaat eruit dat je voor twee verschillende subjects certificaten kunt maken die dezelfde MD5 hash opleveren. Rekening houdend met de voorspelbare wijzigingen door de CSP kon de TUe (met veel rekenwerk) voor twee verschillende domeinnamen het volgende maken:
1) Een CSR voor een onbenullige domeinnaam waarvan ze de waarden van de door de CSP te wijzigen informatie hadden voospeld waarmee de voorspelde certificaatinhoud een specifieke MD5 hash zou opleveren;
2) Een volledig ingevuld maar nog niet ondertekend certificaat -nog zonder handtekening- voor een andere domeinnaam (van een bank bijvoorbeeld) met identieke MD5 hash.

Na het terugkrijgen van het eerste -door de CSP ondertekende- certificaat, hoefden ze alleen maar de handtekening daaruit te kopiëren en plakken achter het nepcertificaat, waarmee ook dat een geldige handtekening kreeg.

Het idee is dat je dit soort aanvallen lastiger uitvoerbaar maakt als je niet kunt voorspellen wat de CSP wijzigt in het CSR voordat deze wordt ondertekend. Dat hoeft overigens geen serienummer te zijn, de CSP zou een apart veld (onder een OID) kunnen toevoegen met een aantal random bytes naar keuze. Maar goed, er is gekozen voor ranomization van het serienummer om dit (en daarmee de hash gebruikt voor de handtekening) onvoorspelbaar te maken.

De discussie is nu kennelijk dat 64 bits genoeg is en 63 bits te weinig. Ervan uitgaande dat de in omloop zijnde 63bit lange random nummers niet voorspelbaar zijn (daar heb ik niks over gelezen), blijf ik bij mijn standpunt: tot iemand mij uitlegt waarom dit een issue is vind ik het schandalige verspilling van belastinggeld en erger, het leidt af van veel belangrijker zaken.

Nb. zelfs als de gebruikte serienummers (ongeacht aantal bits) voorspelbaar zouden zijn, heb je een SHA2 hash-collision nodig om een nepcertificaat te kunnen maken. Het risico van dit soort trucs (randomization van serienummers) is dat we, zodra een of meer SHA2 hash-collisions worden gevonden, we gaan stellen dat dit niet erg is omdat die random serienummers aanvallen tegengaan (net zo stompzinnig als bij 2FA stellen dat verlies van 1 factor geen probleem is).

Lees mijn post van gisteren 20:03
Technische risico's zijn niet de enige input in beslissingen.

64 vs 63 bits pseudo-random-number die moet worden verwerkt in het serienummer om de kans op gelijke hashes "te voorkomen" :-) Een lezer zou nu zelf de risico kunnen inschatten.

Ofwel er is sprake van een beveiligingsrisico, of niet. Aangezien er volgens Logius geen beveiligingsrisico is, en niet duidelijk is wat het risico dan wel is, en mensen al beveiligingsmoe genoeg zijn, vind ik het vervangen van certificaten tijd- en geldverspilling (dat ongetwijfeld overal van het IB budget af gaat).

Het lijkt er sterk op dat omdat er "iets is" met certificaten, en bijna niemand snapt hoe ze werken, de blinde paniek toeslaat.

Laat de overheid eerst maar eens zorgen dat overheidsdiensten HSTS op orde hebben (of überhaupt https afdwingen zoals http://www.almere.nl/), zie https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites.

Als je daarmee bedoelt dat de kans op identieke serienummers bestaat als je daar 63 of 64 bit hashes voor gebruikt: je moet sowieso bijhouden welke certificaten je uitgeeft. Natuurlijk hoort daarbij dat je, als je serienummers random genereert, je doorgaat met genereren tot je een uniek nummer gevonden hebt voor het eerstvolgende uit te geven certificaat.

Als de reden van deze paniek is dat er certificaten met identieke serienummers zijn uitgegeven, heeft dat helemaal niets met de (bit-) lengte van dat serienummer te maken (en je dus als je er één wegens compromittering moet intrekken, je onbedoeld ook een ander certificaat ongeldig maakt). Als dat aan de orde is, zeg dat dan en ga niet bitneuken over 1 bit.

Ter aanvulling: in https://www.theregister.co.uk/2019/03/13/tls_cert_revoke_ejbca_config/ lees ik:
Dramatically?!? Een factor 2. Nog suffer, hoe weet je of een random nummer in een 64 bit register 63 of 64 bits lang is, door te checken of het hoogste bit 0 of 1 is? M.a.w. alleen 64-bit serienummers waarvan het hoogste bit 1 is zijn voortaan OK? Laat me niet lachen...

Dat mag je vinden, en ik zie ook geen praktisch technisch risico. Er zijn wel meer overschatte risico's in de wereld, van security of elders.
Zo'n certificaat vervanging is zeker hinderlijk voor de betrokken beheerders - maar als je zegt dat mensen beveiligingsmoe zijn is dat meer van de eindeloze zeik-eisen van password policy makers en rete trage virus scanners dan van certificaat updates die , als de beheerders hun vak verstaan, onmerkbaar kunnen gebeuren.

Maar leg nou eens uit of *jij* werkelijk aan de minister zou adviseren :

"Ze willen met dit probleem als argument een CA uit de root store gooien, Google en Apple en GoDaddy trekken alles in, maar laat PKI-O maar niks doen en gewoon certificaten actief laten die niet aan de door ons zelf opgestelde eisen voldoen want ikke zeg dat er niet echt een technisch risico is." .


Je moet begrijpen dat je dit soort beslissingen als CA niet op een eilandje neemt maar in een politiek landschap van CA forums, working groups en de browser makers die beslissen of een CA betrouwbaar is. Schijt hebben aan vastgestelde requirements omdat je even geen zin om een batch certificaten te updaten is een heel snelle manier om dat vertrouwen om zeep te helpen.

Het is goed om te realiseren dat het niet de browser vendors zijn die dit bepalen, maar de partijen die de CA root store bijhouden. Chrome/Google doet dat niet, maar wijst altijd naar het OS hier voor. Mozilla doet dit wel voor Firefox en dit is tevens de store die op veel/alle linux distributies gebruikt wordt. Net zoals Microsoft en Apple hun store hebben. Er is dus geen plan vanuit de browser vendors. De meeste discussie hier gaat om de Mozilla NSS CA store en is dus ook niet relevant voor bijvoorbeeld Microsoft gebruikers die GEEN Firefox gebruiken.

Mozilla heeft een duidelijk beleid en dat is dat CA's zo transparant mogelijk moeten zijn. Daarom is er nu een hoop (publieke) discussie over.

Overigens lijkt het probleem ook niet zo zeer te gaan over de vraag of 63 bits nu echt een risico is of niet. De echte vraag is wat doen CA's als reactie om de constatering dat er een tekortkoming is. Vragen om uitstel en uitzonderingen of inspanning om dit binnen de gestelde termijn (proberen) op te lossen.

Ik heb vanavond wat meer tijd om te reageren op de rest van je post,
Acrimony

Beste Acrimony,

Ik wacht op je reactie. Tevens graag jouw visie en wellicht, die ook van Bitwiper aangaande mijn posting met m.n., hoe men hier oplossingen voor kan aandragen.

Gaat er op de infrastructuur nog iets in de goede richting gebeuren of blijft het verder "dweilen met de kraan open"
(wat betreft het misbruik van nep- en pret-certificaten, scammers en andere mogelijke CA abusers?

Is het hierbij net als met het setten van header-policy-security - te weinig, te laat.
Te weinig mensen, die echt relevante kennis bezitten om enig echt verschil te gaan maken.

Onze IT-infrastructuur lijkt vaak nog op het Wilde Westen uit 1876,
waar de sheriff wat langer op vakantie is gegaan.

Mijn "ding" is javascript security en ik doe aan disclosure van niet goed ge-escapte code.
Anderen blijven er graag op zitten en laten zich voor rapporteren uitbetalen.

Daarom zie ik hier ook niet veel beweging in de goede richting met af te voeren jQuery bibliotheken: https://retire.insecurity.today/ , maar ook bij SRI issues, pre-loading en nog een heel scala aan zaken.

Vaak client-afhankelijk script, zoals wat ik nu weer zie op een site rendered in chromium
Google Map.Init API error.
Ik zit daarom ook vaak als lurer op Stack-Overflow.

Jullie bijdragen alhier oprecht zeer waarderend, gegroet van

#sockpuppet

Hier bij www.security.nl staan tenminste alle vinkjes op groen: https://certificate.revocationcheck.com/www.security.nl

luntrus

Dat was ook mijn gedachte. Aan een 64 bit getal is niet te zien of dit een signed of unsigned integer is. (Kan iemand me b.v. vertellen of security.nl een 96 of een 95 bit serienummer gebruikt? Het eerste bit is nu een nul. )

Jouw samenvatting van je stukje literatuurstudie hierboven was verhelderend. Dat is in elk geval een goede verklaring. Nu maakt één bit meer of minder natuurlijk niet veel uit voor de veiligheid, maar als je een grens trekt, moet je je daar aan houden.

Bullshit! Hiero Quo Vadis :
https://bugzilla.mozilla.org/show_bug.cgi?id=1533899

Nee, dat denk ik niet. Dit issue is per toeval ontdekt tijdens de root aanvraag van DarkMatter en is gewoon technisch niet in lijn met de richtlijnen. Het is niet zoeken naar een reden om DarkMatter uit een CA store te houden. Wat overigens ook helemaal geen recht is.

Goed om ook nog te realiseren is dat DarkMatter al zijn eigen (intermediate) CA heeft. In principe kunnen ze op dit moment, onder het toeziend oog van hun issuing CA, onze root CA, al ongelimiteerd certificaten uitgeven. Daarom zijn er ook 2 losse vragen: 1) moet DarkMatter een eigen root CA krijgen of niet en 2) zo nee, moeten ze hun huidige intermediate CA nog wel behouden.


Ik moet bekennen dat ik niet bekend ben hiermee. Wat is een SMU::EE malcode precies? Zelf zie ik het overigens niet als een security probleem als een malafide website of phishing website een (Domain Validated) certificaat weet te krijgen. Sterker nog, als ze eigendom van het domein kunnen aantonen zou dat hun goed recht zijn.

@ Acrimony,

Je kent je zaakjes theoretisch op je duimpje. Ik vermoed opleiding Tech-Inf en ik denk dat je je vnml. bezig houdt met back-end solutions. Maar dat is pure speculatie van mijn kant.

SMU::EE is voor DEVAStreamServer 1.4 met self-signed cert.
Lees: https://www.beyondsecurity.com/scan_pentest_network_vulnerabilities_ssl_certificate_self_signed

Maar er zijn ook nog onvermoede kantjes aan certificering en altijd is er ook nog het gebruik van malcode.

Over handel in frauduleuze certificaten, voornamelijk voor het signeren van malcode:
https://securityintelligence.com/certificates-as-a-service-code-signing-certs-become-popular-cybercrime-commodity/

Er wordt gestolen en gekocht en het wordt ondergronds (op darkweb) verhandeld.

Je kunt ook te maken krijgen met een onzinnige string bug, als deze

Ik verbaas me niet gauw meer. A dirty coding mind is a joy forever, zoals sommigen menen te zeggen.;)

luntrus

Ik lees jou vermoeden als verhaal hier terug
https://www.golem.de/news/mozilla-tls-zertifikate-von-der-spionagefirma-aus-den-emiraten-1902-139614.html
https://www.golem.de/news/zertifizierungsstellen-millionen-tls-zertifikate-mit-fehlendem-zufallsbit-1903-139979.html

Men had een fout gevonden bij die partij, hadden alleen niet door dat die fout ook bij de rest zat.
Dan heb je het over code die iedereen zag en iedereen jarenlang gebruikte
"Das Problem ist demnach ursprünglich auf die Software EJBCA zurückzuführen, die in der Standardeinstellung dieses Verhalten zeigt. EJBCA ist Open Source und wird von mehreren Zertifizierungsstellen verwendet, es ist daher auch gut möglich, dass demnächst bei weiteren Zertifizierungsstellen dasselbe Problem entdeckt wird."


Alle kosten om nu maar van alles te gaan vervangen lijken me wat ver gezocht maar zijn een gevolg van harde uitspraken dat het zo zou moeten.

Off topic: die heb ik handmatig verwijderd.
Na 1 week kwam ik enkel "rijksoverheid.nl" tegen, en vorige week "kiesraad.nl".
Verder -na weken dus- totaal niets en niemand.

Gaat blijkbaar om KPN. En volgens KPN (ik heb ze aan de lijn gehad) raakt het maar een klein aantal klanten. Niet alle certificaten in die periode schijnen het te hebben namelijk. Slecht een kleine greep uit de gehele lijst van certificaten die zien die periode hebben uitgegeven. De klanten die er last van hebben zijn door KPN reeds benaderd.