Mozilla wil nieuwe ssl-certificaten WoSign/StartCom blokkeren
Mozilla is van plan om nieuwe ssl-certificaten die door de certificaatautoriteiten WoSign en StartCom worden uitgegeven te blokkeren. Aanleiding is een lange reeks van allerlei incidenten met de twee aanbieders van ssl-certificaten. Eind augustus waarschuwde Mozilla al voor eventuele stappen.
Certificaatautoriteiten spelen een zeer belangrijke rol bij het vertrouwen op internet. De incidenten bij WoSign hadden dit vertrouwen volgens Mozilla kunnen aantasten. Zo bleek het mogelijk om via een systeem van WoSign certificaten voor domeinen aan te vragen waar de aanvrager niet de eigenaar van was. Deze certificaten zouden vervolgens voor man-in-the-middle-aanvallen gebruikt kunnen worden. Certificaatautoriteiten ondergaan daarnaast verplichte audits. De problemen werden echter niet door de gebruikte auditor ontdekt. Toen ze wel aan het licht kwamen besloot WoSign ze voor Mozilla te verzwijgen. In totaal zijn er nu 12 incidenten gedocumenteerd.
Vanwege al de problemen zegt Mozilla geen vertrouwen meer in het functioneren van zowel StartCom als WoSign te hebben. Daarom wil de opensource-ontwikkelaar nieuwe certificaten die beide partijen uitgeven niet meer door Firefox laten vertrouwen. Door alleen nieuwe ssl-certificaten te blokkeren moet de impact op internetgebruikers worden beperkt. De blokkade zou voor een jaar gaan gelden, waarna WoSign en StartCom opnieuw kunnen worden vertrouwd als ze aan een lijst met voorwaarden voldoen. Mozilla heeft de plannen nu voor feedback aan de gemeenschap voorgelegd, zodat ook andere browserleveranciers de informatie kunnen gebruiken om eventuele maatregelen tegen de twee certificaatautoriteiten te nemen.
de gebruiker of een door de gebruiker in te schakelen partij. De user interface voor het blokkeren van certificaat
uitgevers door de gebruiker is heel omslachtig. Je zou verwachten dat er services zouden zijn (wellicht regionaal
specifiek) die certificaat providers in allerlei categorieen indelen en de gebruiker de keuze geven om certificaten al
dan niet na waarschuwing te accepteren. Vergelijkbaar met spamfilters, virusscanners, e.d.
uitgevers door de gebruiker is heel omslachtig.
De gebruiker heeft die keuze altijd al. Dat het omslachtig is; tjsa, voor jan-met-de-pet is dit niet erg interessant en bovendien niet iets wat je dagelijks uitvoert.
Voor de "enkeling" (IT professionals zijn nou eenmaal een relatief kleine groep gebruikers binnen het geheel) is het niet zo spannend om wat meer stappen te doorlopen. En als het wel een probleem wordt, schijf je toch even een scriptje?
de gebruiker of een door de gebruiker in te schakelen partij. De user interface voor het blokkeren van certificaat
uitgevers door de gebruiker is heel omslachtig. Je zou verwachten dat er services zouden zijn (wellicht regionaal
specifiek) die certificaat providers in allerlei categorieen indelen en de gebruiker de keuze geven om certificaten al
dan niet na waarschuwing te accepteren. Vergelijkbaar met spamfilters, virusscanners, e.d.
Zelf vind ik de user interface redelijk. Het probleem zit in het feit dat je geen idee hebt wat al die certificaten zijn. Daarnaast is het lastig om later alsnog CA's toe te voegen.
Ik ben echter tegen enige regionale oplossing. Dan krijg je al snel landelijke oplossingen waarbij de zeggenschap over betrouwbare en onbetrouwbare CA's binnen de jurisdictie van de afzondelijke overheden valt. Als een Nederlandse organisatie een lijst met betrouwbare CA's bijhoudt, is het eenvoudig om DigiNotar-achtige problemen te bagataliseren. Dan krijg je de situatie dat de belangen van de landelijke overheid de voorkeur genieten boven die van de gebruikers.
Bij DigiNotar was men gedwongen snel te handelen omdat de browser fabrikanten een limiet hadden gezet op de geldiheid van die certificaten. Die dwang verdwijnt als ze zelf de lijst met CA's kunnen beinvloeden.
Peter
Een knoeiende CA kan dan wel een certificaat aanmaken voor een domein maar omdat hun CA niet in DNS staat zal niemand er waarde aan hechten.
Mozilla, zet DANE-validatie aan svp.
Ik ben echter tegen enige regionale oplossing. Dan krijg je al snel landelijke oplossingen waarbij de zeggenschap over betrouwbare en onbetrouwbare CA's binnen de jurisdictie van de afzondelijke overheden valt. Als een Nederlandse organisatie een lijst met betrouwbare CA's bijhoudt, is het eenvoudig om DigiNotar-achtige problemen te bagataliseren. Dan krijg je de situatie dat de belangen van de landelijke overheid de voorkeur genieten boven die van de gebruikers.
Tuurlijk de overheid heeft het weer gedaan. Dit is tenslotte security.nl
Maar zo zie ik dat niet. Als ik die lijst open dan begint ie met TÜRKTRUST nou die Erdogan vertrouw ik voor geen meter.
En dus wil ik die gewoon eruit kunnen knikkeren samen met Chunghwa Telecom, E-Tugra en wat dies meer zij.
Maar ik heb geen zin om precies uit te zoeken wat voor duistere toko's dat allemaal zijn dus zou ik het op prijs stellen
dat iemand dat netjes categoriseert zodat ik gewoon een set CA's voor de typische west-europese gebruiker kan aanzetten
en de rest uit of op "warning".
Een Turk, Chinees of zuid-Koreaan ziet dat weer heel anders dus moet dat per regio bepaald worden.
(Zie het linkje "plannen" in het artikel.)
Verder wil Mozilla niet alleen de frauderende certificaatautoriteiten straffen, maar heeft het ook het vertrouwen opgezegd in de auditor (Ernst & Young Hong Kong) die bij de laatste audit alle problemen over het hoofd heeft gezien.
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.
