Mozilla adviseert Symantec om Google-voorstel te accepteren
Mozilla heeft Symantec geadviseerd om een voorstel van Google om weer vertrouwen in de ssl-certificaten van het beveiligingsbedrijf te krijgen op te volgen. Vanwege verschillende fouten bij ssl-certificaten die door Symantec zijn gecontroleerd en uitgegeven kondigde Google in maart een plan aan om geleidelijk het vertrouwen in de certificaten van het bedrijf op te zeggen.
Zo had Symantec ten onrechte een ssl-certificaat voor Google aan een andere partij uitgegeven. Om het vertrouwen te herstellen stelde Google verschillende maatregelen voor. Zo zouden nieuwe door Symantec uitgegeven ssl-certificaten een geldigheidsperiode van 9 maanden of minder krijgen. Daarnaast zou het vertrouwen in al uitgegeven Symantec-certificaten geleidelijk worden opgezegd. Symantec reageerde door te stellen dat de berichtgeving van Google misleidend en overdreven was.
Na overleg kwam Google met een tweede voorstel, waarbij Symantec een nieuwe public key infrastructure (PKI) zou moeten gaan gebruiken, die in eerste instantie van één of meer andere certificaatautoriteiten zou zijn. Ook zou het vertrouwen in de ev-ssl-certificaten van Symantec niet worden opgezegd en zouden nieuwe Symantec-certificaten 13 maanden in plaats van 9 maanden geldig blijven. Symantec kwam vorige week met een eigen voorstel, maar dat valt niet in goede aarde.
"We vinden dat het antwoord van Symantec niet voldoende weergeeft dat ze de ernst van de problemen begrijpen en dat hun voorstel voornamelijk ervoor zorgt dat ze meer van hetzelfde blijven doen, wat in het verleden niet voor consistente hoge standaarden heeft gezorgd", zegt Mozilla's Gervase Markham. Hij benadrukt dat Mozilla zelf beslissingen maakt, maar zich in dit geval in de oplossing van Google kan vinden. Het tweede voorstel van Google biedt volgens Mozilla de juiste balans voor Symantec tussen het breken met het verleden om weer in de toekomst te kunnen worden vertrouwd en het minimaliseren van de impact op het ecosysteem. Mozilla adviseert Symantec dan ook om het voorstel te heroverwegen.
"Als dat voorstel niet wordt geïmplementeerd, moeten we alternatieve maatregelen nemen om het risico te verminderen van in het verleden en de toekomst verkeerd uitgegeven certificaten door Symantec", aldus Markham. Mozilla zal in dit geval alleen nog nieuwe Symantec-certificaten voor een periode van 13 maanden accepteren en de geldige levensduur van bestaande certificaten naar 13 maanden terugbrengen. Ook moet Symantec onderdelen die niet aan de Baseline Requirements voor certificaten voldoen afstoten en de eigen PKI volledig in kaart brengen.
Toch gek dat een commercieel bedrijf gaat bepalen wat een ander commercieel bedrijf al of niet mag op publieke infra.
Je geeft weer precies aan waar de schoen wringt. Commercie is almachtig en we krijgen alles opgedrongen door de dikste portemonnee. Geen toezichthouders, die nog wat in de melk te brokken hebben of ze zitten liever op hun luie achterwerk.
De politiek heeft in deze ook zeer slecht gewerkt. Boetes betaalt men fluitend uit de achterzak.
En de eindgebruiker heeft helemaal geen stem meer in het kapittel. Kijk naar de recente "losse flodder ballon" van demissonair minister Edith Schippers, om onze DNA gegevens over te hevelen naar politie- en justitie-databanken. Afgrijselijk.
Net zo met de afgedwongen verwatering van de 4 mei herdenking door hetzelfde paarsgroene affront. Jodenvervolging kan al bijna op scholen niet meer aan de orde komen. In wat voor zieke tijd leven we toch, waar andersdenkenden democratisch worden geringeloord.
Google moet je in deze context zien als browsermaker (net als mozilla). Jouw browser is de eind node in de chain of trust van ssl-certificaten. In vind dat ze nog erg coulant zijn naar Symantec!
Google moet je in deze context zien als browsermaker (net als mozilla). Jouw browser is de eind node in de chain of trust van ssl-certificaten.
En dat is een HELE SLECHTE zaak!!!
Die rol zou helemaal niet bij de browser maker mogen liggen maar moet worden belegd bij een onafhankelijke partij,
en nog liever meerdere onafhankelijke partijen waarvan je er als gebruiker een kunt kiezen die je het meeste vertrouwt.
Google moet je in deze context zien als browsermaker (net als mozilla). Jouw browser is de eind node in de chain of trust van ssl-certificaten.
En dat is een HELE SLECHTE zaak!!!
Die rol zou helemaal niet bij de browser maker mogen liggen maar moet worden belegd bij een onafhankelijke partij,
en nog liever meerdere onafhankelijke partijen waarvan je er als gebruiker een kunt kiezen die je het meeste vertrouwt.
Ja, maar dat kan toch niet anders. Je gebruikt immers de browser om de websites in te bekijken. Dus je moet altijd vertrouwen op de bouwer van de website. Echter kun je wel weer kiezen uit meerdere browsers, de één van commerciële partijen en de andere zijn open source. Dus je kunt gewoon zelf kiezen wie je vertrouwt.
Toch gek dat een commercieel bedrijf gaat bepalen wat een ander commercieel bedrijf al of niet mag op publieke infra.
Wat ik me al afvroeg toen halverwege de jaren '90 SSL werd bedacht en CA's in opkomst kwamen was trouwens waarom dat niet door overheden wordt gedaan. Als ik naar het loket van de gemeente ga om een paspoort te regelen, waarom ga ik dan niet ook daarheen om mijn persoonlijke digitale sleutels te laten certificeren? Voor rechtspersonen kan daar ook een geschikte instantie voor worden bedacht. Overheid werd toen, voor mensen die dat onmiddelijk gaan roepen, nog niet met falende IT geassocieerd. Het is eind jaren '90 dat het RCC en GCEI (computercentra van het rijk en van Amsterdam) werden geprivatiseerd. Ik heb met een aantal ex-GCEI'ers jarenlang samengewerkt en dat waren oerdegelijke professionals die overduidelijk in een oerdegelijke professionele omgeving hun vak hadden geleerd. Het is vermoedelijk juist het afstoten van die kennis geweest die de huidige warboel heeft veroorzaakt. Als in plaats daarvan de overheid zich verder was gaan professionaliseren en daarbij tegen betaalbare leges ook digitale sleutels was gaan certificeren was ik daar blij mee geweest.
Google moet je in deze context zien als browsermaker (net als mozilla). Jouw browser is de eind node in de chain of trust van ssl-certificaten.
En dat is een HELE SLECHTE zaak!!!
Die rol zou helemaal niet bij de browser maker mogen liggen maar moet worden belegd bij een onafhankelijke partij,
en nog liever meerdere onafhankelijke partijen waarvan je er als gebruiker een kunt kiezen die je het meeste vertrouwt.
En deze "onafhankelijke" partij bestaat al: het CA/Browser Forum. Echt onafhankelijk is deze partij natuurlijk niet, maar een echt onafhankelijke partij bestaat sowieso niet, omdat er altijd wel hidden agendas zijn.
Hoe groot is het aandeel `security through obscurity`? Het goed Oud-Hollandse gezegde zegt "Veel beloven en weinig geven, doet de gek in vreugde leven". We weten niet eens meer "wat" nog precies veilig is, waar overheidsachterdeuren samen met die van de commercie al jaren en jaren bestaan. Hoe veel oude exploits steeds weer opnieuw kunnen worden opgetuigd tot een eindeloze rij nieuwe varianten omdat de basis fouten uit het begin nooit echt verholpen zijn en we allemaal onveilig worden gehouden onder hetzelfde stoplapdeken. Hoe meer ik er van gezien heb, hoe meer ik ervan overtuigd raak: Ïnternet insecurity by design! En als het dat doel niet al lang diende, was het er al lang niet meer.
We kennen allemaal het voorbeeld van Diginotar, maar ondertussen hebben al vele andere CA's in meer en mindere mate grote fouten gemaakt.
Het in bovenstaand artikel gegeven voorbeeld dat Symantec een certificaat voor een Google domain heeft uitgegeven aan een derde partij is maar een voorbeeld, maar wel een met mogelijk zeer vergaande ongewensten effecten (bijv. dat journalisten of leden van een oppositie vervolgd worden op grond van onderschepte communicatie, mogelijk met de dood van dezen tot gevolg). Er zijn honderden CA's en vele maken er een potje van, vooral de aanverwante rol van RA (registrating authority, de taak die verificatie behelst van de identiteit en authenticiteit van een certificaat dat de CA tekent) is een zeer kwetsbare gebleken.
Om die reden zien de makers van webbrowsers en operating systems toe op de qualiteit van de CA van wie zij het root certificaat (het anker van een keten van vertrouwen) met hun producten meeleveren. Het is vooral dankzij partijen als Mozilla en Google en de belangrijkste OSS distributies (Debian enz.) dat de CA een beetje bij de les worden gehouden. Grote partijen als Microsoft en Oracle (Java !) zijn tot nog toe op zijn best vooral volgers in deze.
Nog een wonderlijke iets:
De non-profit organisatie CACERT.ORG geeft ook certificaten uit. Als een van de weinigen CA zijn zij volledig transparant in hun processen en bovendien zijn alle certificaathouders verplicht zich eerst **in persoon** aan de hand van minimaal een paspoort te registreren. Prima, maar het wonderlijke is dat de root certificaten van CACERT niet in de grote webbrowsers zijn opgenomen. CACERT is voor in de wetenschappelijke wereld populair.
Verder is een heel interessante ontwikkeling DNSSEC i.c.m. DANE. In deze opzet vervalt het belang van CA's en hun root certificaten en wordt de rol van anker in de vertrouwensketen DNSSEC. Zoek er maar een op. Overigens is ook hier wonderlijk dat de grote webbrowsers dit (nog) niet ondersteunen. Grote kans dat DANE vooral eerst doorbreekt in e-mail toepassingen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
