Nederlandse overheid stopt met uitgifte publiek vertrouwde TLS-certificaten
De Nederlandse overheid stopt met de uitgifte van publiek vertrouwde TLS-certificaten die websites gebruiken voor identificatie en het opzetten van een beveiligde verbinding. Dat heeft demissionair staatssecretaris Knops van Binnenlandse Zaken besloten. Aanleiding zijn verschillende incidenten met certificaten die onder het PKIoverheid-stelsel zijn uitgegeven en dat de overheid maar met moeite kan voldoen aan de steeds hogere eisen die browserleveranciers aan de uitgifte van certificaten stellen.
Deelnemers aan het PKIoverheid-stelsel geven digitale certificaten uit aan overheidsorganisaties en bijvoorbeeld nutsbedrijven, zoals vervoerders en energieleveranciers, maar ook aan ondernemers of zorgaanbieders. Die gebruiken de certificaten voor hun websites. De Nederlandse overheid is op dit moment het enige EU-land dat publiek vertrouwde TLS-certificaten uitgeeft, in andere landen wordt dit gedaan door bedrijven.
Vanwege incidenten die zich in 2019 en 2020 met uitgegeven TLS-certificaten voordeden werden vorig jaar zomer alle publiek vertrouwde TLS-certificaten voor websites onder een nieuw intermediate CA-certificaat uitgegeven, met de naam Staat der Nederlanden Domein Server CA 2020. Dit certificaat verloopt op 6 december 2022. Dit houdt in dat onder dit certificaat tot begin december 2021 nog PKIoverheid TLS-certificaten met een geldigheid van een jaar uitgegeven kunnen worden.
Browserleveranciers
Naast de verschillende incidenten zijn ook de regels die browserleveranciers stellen reden om met het uitgeven van TLS-certificaten te stoppen. Browserleveranciers zoal Google en Mozilla bepalen waar uitgegeven certificaten aan moeten voldoen. Volgens Logius, ict-dienstverlener van de overheid, heeft diezelfde overheid weinig tot geen grip op de browserpartijen en kan maar met moeite voldoen aan de steeds hogere eisen die zij aan certificaatuitgifte stellen.
Tevens is de uitgifte van TLS-certificaten binnen het PKIoverheid-stelsel ooit begonnen als beveiligingsmaatregel voor websites. "Webbrowsers en de beveiliging van websites stonden destijds nog in de kinderschoenen en de overheid liep voorop in het beveiligen van websites", merkt Logius op. Inmiddels hebben browsers grote stappen gemaakt en kunnen bedrijven goedkoper en net zo goed certificaten uitgeven. "Daarom is het uitgeven van publiek vertrouwde TLS-certificaten onder de vlag van PKIoverheid niet meer noodzakelijk", aldus de ict-dienstverlener. De overige dienstverlening die onder PKIoverheid valt, wordt gewoon doorgezet.
Reacties (29)
Dus digid.nl krijgt over iets meer als een jaar een Let's Encrypt certificaat? Dat zal inderdaad aan alle veiligheidseisen van Mozilla voldoen.
Wel goed dat de overheid toegeeft dat ze iets niet kunnen. Dat zouden ze meer moeten doen.
Wel goed dat de overheid toegeeft dat ze iets niet kunnen. Dat zouden ze meer moeten doen.
Gaan de browser fabrikanten dan ook dat Staat der Nederlanden root certificaat op den duur verwijderen?
Want zo'n ding is natuurlijk een gigantisch risico voor de Nederlandse internet gebruikers...
(voor wat betreft de mogelijkheid voor de Staat om op allerlei manieren man-in-the-middle te spelen)
Want zo'n ding is natuurlijk een gigantisch risico voor de Nederlandse internet gebruikers...
(voor wat betreft de mogelijkheid voor de Staat om op allerlei manieren man-in-the-middle te spelen)
02-08-2021, 19:45 door
Erik van Straten
Slechte zaak dit.
Door Anoniem: Dus digid.nl krijgt over iets meer als een jaar een Let's Encrypt certificaat?
Dat verwacht ik niet, maar degenen die het niet helemaal vertrouwen en het https servercertificaat checken, kunnen er niet meer vanuit gaan dat het om een PKI-Overheid certificaat moet gaan.Exact 10 jaar geleden hadden we het DigiNotar debacle. Het had logius gesierd als ze toen al hadden toegegeven dat ze niet in staat waren pkioverheid goed te regelen. Toezicht was totaal niet toereikend. Hoe ze zo lang hebben kunnen doormodderen is een raadsel
Ik zou verwachten dat als ze dit " te koop " aanbieden dat er best wat partijen zijn die dit zo willen overnemen, met bak geld naar de staatskas.
02-08-2021, 20:38 door
Eric-Jan H te D
Dat wordt lachen denk ik. De Belastingdienst, het UWV, Rijksoverheid.nl, Tweedekamer.nl, het Openbaar ministerie, de Politie, Rijkswaterstaat (met waarschijnlijk al hun op afstand bedienbare waterwerken), het NVWA (met "al" hun inspecteurs in het veld) en waarschijnlijk nog honderden meer maken hier gebruik van.
Dit is nou typisch zoiets wat je in Europees verband moet regelen. NL is te klein voor een fatsoenlijke PKI met alle aandacht die hierbij komt kijken. Op EU niveau echter heb je voldoende afnemers om de juiste hoeveelheid geld en tijd eraan te kunnen besteden.
@ Erik van Straten en Eric-Jan H te D
Wat is er mis met normale CA zoals DigiCert? Dus straks gaan jullie geen DigiD of online Belastingaangifte doen?
Moet ik nu ook niet IB met Rabobank omdat ze DigiCert gebruiken?
Ik dacht dat de prive sleutel prive was?
Wat is er mis met normale CA zoals DigiCert? Dus straks gaan jullie geen DigiD of online Belastingaangifte doen?
Moet ik nu ook niet IB met Rabobank omdat ze DigiCert gebruiken?
Ik dacht dat de prive sleutel prive was?
Ik ben van mening dat alle encryptie die gebaseerd is op public key encryptie per definitie onveilig is, inclusief certificaten, ik begrijp niet waarom ze niet gewoon afstappen van public key encryptie.
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
03-08-2021, 00:07 door
Erik van Straten
Door Anoniem: @ Erik van Straten en Eric-Jan H te D
Wat is er mis met normale CA zoals DigiCert?
Niet heel veel, maar nu weet ik nog dat als een kennelijke overheidswebsite geen PKI-overheid cerificaat heeft, het om een fake site moet gaan. Straks weet ik dat niet meer. Bovendien is of was het knap lastig om een PKI-overheidcertificaat te verkrijgen (ook voor fraudeurs), helaas nemen sommige andere certificaatboeren het niet zo nauw.Wat is er mis met normale CA zoals DigiCert?
Door Anoniem: Dus straks gaan jullie geen DigiD of online Belastingaangifte doen?
Jawel, maar dan zal ik wat beter op andere zaken moeten letten.Door Anoniem: Moet ik nu ook niet IB met Rabobank omdat ze DigiCert gebruiken?
De vraag die je jezelf zou kunnen stellen luidt: "Moet ik nu ook niet IB met Rabobank omdat ze ineens Let's Encrypt gebruiken?"Door Anoniem: Ik dacht dat de prive sleutel prive was?
Ik geloof niet dat je het helemaal snapt.Stel jij opent https://self-signed.badssl.com/ en op de een of andere manier weet je 100% zeker dat de private key van de echte "self-signed.badssl.com" server nooit is gelekt. Welke zekerheid heb je dan dat jouw browser verbinding heeft met de echte "self-signed.badssl.com" server?
@Erik van Straten
Is een Extended Validation Certificate niet de oplossing?
Door Anoniem: Dus straks gaan jullie geen DigiD of online Belastingaangifte doen?
Jawel, maar dan zal ik wat beter op andere zaken moeten letten.Is een Extended Validation Certificate niet de oplossing?
Door Anoniem: Dus straks gaan jullie geen DigiD of online Belastingaangifte doen?
Jawel, maar dan zal ik wat beter op andere zaken moeten letten.iedere keer de SHA-1 van elke site (Certificate) checken is ook geen doen
03-08-2021, 05:32 door
Eric-Jan H te D
Door Anoniem: @ Erik van Straten en Eric-Jan H te D
Wat is er mis met normale CA zoals DigiCert?
Daar is niks mis mee, Maar je weet hoe het gaat als er iets mis gaat en er aan de andere kant meer dan één partij in het spel is. Die gaan naar elkaar lopen te wijzen. Nu kon je nog zeggen: Overheid zoek het even zelf uit. En er zijn altijd instanties die hun infrastructuur (licenties, certificaten, updates etc) niet op orde hebben en er straks gewoon uit liggen. Wat is er mis met normale CA zoals DigiCert?
Bovendien vind ik het jammer voor mijn oud collega Stan die aan de wieg heeft gestaan van het hele PKI gebeuren bij de overheid. Het was toch een beetje een kindje van hem.
Door Anoniem: Ik ben van mening dat alle encryptie die gebaseerd is op public key encryptie per definitie onveilig is, inclusief certificaten, ik begrijp niet waarom ze niet gewoon afstappen van public key encryptie.
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
Het zou een elegante opzet zijn als hij zou werken, maar dat gaat met sterke versleuteling helaas niet lukken.De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
Sterke versleuteling maakt namelijk voor wie de sleutel (of het wachtwoord) niet kent de inhoud volstrekt willekeurig en betekenisloos, er is dan niets over waar je nog wat zinnigs mee kan doen. Als de klant het bericht heeft versleuteld met diens wachtwoord is het bericht onherkenbaar voor het bedrijf. Als het bedrijf dat weer versleutelt met diens wachtwoord is het resultaat onherkenbaar geworden voor de klant, en ook voor een poging om het met de sleutel van die klant te ontsleutelen. De bitpatronen waar de ontsleuteling iets mee kan zijn door de versleuteling van het bedrijf volstrekt ontoegankelijke gemaakt. "Klant browser decrypt met sleutel klant" gaat daarom niet werken, en daar loopt je opzet spaak.
De opzet zou wél werken met een simpele versleuteling op basis van een exclusive-or-bewerking tussen het bericht en iets dat van het wachtwoord wordt afgeleid. Die versleuteling is echter zo zwak dat hij volstrekt onbruikbaar is.
Door Anoniem: Ik ben van mening dat alle encryptie die gebaseerd is op public key encryptie per definitie onveilig is, inclusief certificaten, ik begrijp niet waarom ze niet gewoon afstappen van public key encryptie.
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
Je weet dat wat je hier beschrijft ongeveer is hoe Diffie-Hellman werkt? Probleem is: hoe weet de verzendende partij zeker dat de ontvanger is wie hij zegt dat hij is? Dat is waar het hele PKI systeem voor is.De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
Door Anoniem: Ik ben van mening dat alle encryptie die gebaseerd is op public key encryptie per definitie onveilig is, inclusief certificaten, ik begrijp niet waarom ze niet gewoon afstappen van public key encryptie.
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
Zoek nog even op hoe encrypt werktDe volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
M=Bericht S1=Encryptysleutel Klant S2=Encryptysleutel Bedrijf
Klant verstuurd bericht: M x S1 = MS1
Bedrijf versleuteld ook MS1 x S2 = MS1S2
Bedrijf stuurt MS1S2 terug
Klant beschikt nu over S2 want MS1S2/MS1 = S2
Klant stuurt MS2 terug
Bedrijf heeft M want MS2/S2 = M
Bedrijf bechikt nu ook over S1 aangezien MS1S2/MS2 = S1
Door Anoniem:
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
De volgende encryptie methode is oneindig malen veiliger:
Klant heeft wachtwoord opgeslagen in browser, klant verstuurd bericht naar server bedrijf, dit wordt versleuteld met wachtwoord van klant voordat het wordt verzonden naar bedrijf server, bedrijf server encrypt het geencrypte pakket met eigen wachtwoord en verstuurd het dubbele encryptie bericht naar browser klant. Klant browser decrypt met sleutel klant en verstuurd het weer terug naar server bedrijf. Bedrijf decrypt het pakket. Op die manier ben je van de gevaren van public key encryptie af… zonder dat je vooraf wachtwoorden uitwisselt.
Maar hoe stel je dan initieel dat wachtwoord in? Je zult toch ooit een keer het wachtwoord wat jij bedacht hebt (of met
een tooltje gegenereerd) aan het bedrijf moeten mededelen en op dat moment kun je nog geen encryptie gebruiken.
Dat is het moment waarop je het risico loopt dat iemand anders ook je wachtwoord te weten komt en vanaf dat moment
alles kan meeluisteren. Je zou dan dus minimaal het wachtwoord via een ander medium (kanaal) moeten sturen, en
dat moet dan al veilig zijn. EN je moet er zeker van zijn dat je op dat moment inderdaad praat met het bedrijf waarmee
je denkt dat je praat en niet met een of andere slimmerik die je wachtwoord aanpakt en opslaat en doorstuurt naar het
echte bedrijf.
Deze problematiek is nou juist wat het systeem probeert op te lossen, door te werken met officiele certificaatuitgevers
die "garanderen" dat je te maken hebt met degene die je denkt. Dat dit bijna niet hard te maken en vol te houden is
dat is zeker een feit, maar het dan maar helemaal droppen maakt het nog slechter.
Door Anoniem: Exact 10 jaar geleden hadden we het DigiNotar debacle. Het had logius gesierd als ze toen al hadden toegegeven dat ze niet in staat waren pkioverheid goed te regelen. Toezicht was totaal niet toereikend. Hoe ze zo lang hebben kunnen doormodderen is een raadsel
Waarom trek je nou het bedrijf Diginotar gelijk met Logius, die twee hebben toch niks met elkaar te maken en hebbenieder hun eigen systeem waarvan je helemaal niet weet welke van de twee beter of slechter is?
En waarom denk je dat als overheidsbedrijven "dat niet kunnen regelen", commerciele partijen dat wel kunnen?
Die hebben op zijn minst de schijn tegen dat ze er alleen voor het geld in zitten en niet om de burger te beschermen.
"Browserleveranciers zoal Google en Mozilla bepalen waar uitgegeven certificaten aan moeten voldoen. Volgens Logius, ict-dienstverlener van de overheid, heeft diezelfde overheid weinig tot geen grip op de browserpartijen".... dat is maar goed ook, want de NL overheid heeft nogal eens de neiging om de norm bij te stellen naar wat ze kan/wil waarmaken. Goed dat in deze aparte partijen elkaar scherp houden.
Door Anoniem: Dit is nou typisch zoiets wat je in Europees verband moet regelen. NL is te klein voor een fatsoenlijke PKI met alle aandacht die hierbij komt kijken. Op EU niveau echter heb je voldoende afnemers om de juiste hoeveelheid geld en tijd eraan te kunnen besteden.
Haha. Ja alles naar de EU want NL is te klein. Eigen expertise is niet belangrijk. Alle technische meuk over de schutting bij een handjevol Duits- en Franstaligen en dan hier in Nederland alleen nog maar managers op de loonlijst.Ik mag toch hopen dat jij ook sarcasme bent?
03-08-2021, 11:40 door
Erik van Straten
Door Anoniem:De opzet zou wél werken met een simpele versleuteling op basis van een exclusive-or-bewerking tussen het bericht en iets dat van het wachtwoord wordt afgeleid. Die versleuteling is echter zo zwak dat hij volstrekt onbruikbaar is.
Voor degenen die dit niet weten: versleutelen met XOR is niet persé zwak, integendeel; "one time pad" is erop gebaseerd.Als voor de gesuggereerde authenticatiemethode van XOR gebruik gemaakt wordt, heeft dat niets met een OTP te maken, en is één van de problemen hier een (passieve, sniffende) MitM [#] die zowel het bericht naar de server als het (met de sleutel van de server middels XOR "versleutelde") retourbericht kan uitlezen. Dan kan de MitM daaruit direct de sleutel van de server afleiden, en zich voortaan voordoen als de server. En datzelfde geldt voor de sleutel van de user, zodra deze het bericht van de server heeft ge-XOR-ed met de user-key.
[#] Man in the Middle, ook te lezen als Woman itM, of -gender-neutraal- Attacker itM.
Toelichting voor de minder ervaren lezer, een handige eigenschap van XOR is dat het volgende geldt:
a XOR b XOR c XOR b XOR c geeft weer a (ongeacht de volgorde van XOR-operaties op b en c en hun inhoud)
Je zou dus als volgt kunnen authenticeren:
User: secret XOR userkey geeft blob1, stuur naar server
Server: blob1 XOR serverkey geeft blob2, stuur naar user
User: blob2 XOR userkey geeft blob3, stuur naar server
Server: blob3 XOR serverkey geeft secret
Server: blob1 XOR serverkey geeft blob2, stuur naar user
User: blob2 XOR userkey geeft blob3, stuur naar server
Server: blob3 XOR serverkey geeft secret
Helaas weet een MitM daar wel raad mee:
User: secret XOR userkey geeft blob1, stuur naar server
MitM: sniff blob1
Server: blob1 XOR serverkey geeft blob2, stuur naar user
MitM: sniff blob2; blob1 XOR blob2 geeft serverkey
User: blob2 XOR userkey geeft blob3, stuur naar server
MitM: sniff blob3; blob2 XOR blob3 geeft userkey
GAME OVER
MitM: sniff blob1
Server: blob1 XOR serverkey geeft blob2, stuur naar user
MitM: sniff blob2; blob1 XOR blob2 geeft serverkey
User: blob2 XOR userkey geeft blob3, stuur naar server
MitM: sniff blob3; blob2 XOR blob3 geeft userkey
GAME OVER
De PKI voor https servercertificaten is in de eerste plaats bedoeld voor de authenticatie van webservers waarop je (nog) geen account hebt. Voor de authenticatie van (web- en andere) servers waarop je al wel een account hebt, bestaan veel veiliger user-authenticatiemethodes dan het naar de server sturen van een user-ID plus shared secret [*], maar helaas worden die op het web nog nauwelijks gebruikt.
[*] Meestal een wachtwoord dat niet wijzigt bij elke sessie (risico: replay attacks) en dat bovendien door veel mensen voor accounts op verschillende servers wordt gebruikt.
Door Anoniem:
Ik mag toch hopen dat jij ook sarcasme bent?
Door Anoniem: Dit is nou typisch zoiets wat je in Europees verband moet regelen. NL is te klein voor een fatsoenlijke PKI met alle aandacht die hierbij komt kijken. Op EU niveau echter heb je voldoende afnemers om de juiste hoeveelheid geld en tijd eraan te kunnen besteden.
Haha. Ja alles naar de EU want NL is te klein. Eigen expertise is niet belangrijk. Alle technische meuk over de schutting bij een handjevol Duits- en Franstaligen en dan hier in Nederland alleen nog maar managers op de loonlijst.Ik mag toch hopen dat jij ook sarcasme bent?
Blijkbaar snap jij niet hoe de EU werkt. Zo'n instituut wordt gewoon toegekend aan 1 van lidstaten, kan dus ook gewoon NL zijn. Het verschil is dat het dan door de hele uni gefinancierd wordt en dat je dus er veel meer man op kan zetten om het goed te bouwen en onderhouden.
Maar goed, aan jou manier van reageren vermoed ik dat je hier toch blind voor bent.
Door Erik van Straten:
[#] Man in the Middle, ook te lezen als Woman itM, of -gender-neutraal- Attacker itM.
Goed, deze vind ik geniaal, die houdt ik er in.[#] Man in the Middle, ook te lezen als Woman itM, of -gender-neutraal- Attacker itM.
Door Anoniem: Gaan de browser fabrikanten dan ook dat Staat der Nederlanden root certificaat op den duur verwijderen?
Want zo'n ding is natuurlijk een gigantisch risico voor de Nederlandse internet gebruikers...
(voor wat betreft de mogelijkheid voor de Staat om op allerlei manieren man-in-the-middle te spelen)
Want zo'n ding is natuurlijk een gigantisch risico voor de Nederlandse internet gebruikers...
(voor wat betreft de mogelijkheid voor de Staat om op allerlei manieren man-in-the-middle te spelen)
Wat een gelul dan snap jij niet het verschil tussen certificaat en een sleutel (versleutelen en ontsleutelen) en dat het sleutelmateriaal van de server van bedrijf A op de server blijft en de overheid alleen een "stempel" geeft op het aangeboden cerificaat van bedrijf A. Ga ergens anders je onzin verkondigen.
Door Anoniem: Gaan de browser fabrikanten dan ook dat Staat der Nederlanden root certificaat op den duur verwijderen?)
Hoeft helemaal niet, dat certificaat verloopt vanzelf, staat in het artikel.Door Anoniem: Exact 10 jaar geleden hadden we het DigiNotar debacle. Het had logius gesierd als ze toen al hadden toegegeven dat ze niet in staat waren pkioverheid goed te regelen. Toezicht was totaal niet toereikend. Hoe ze zo lang hebben kunnen doormodderen is een raadsel
Yup, ze hebben een grote broek aan willen trekken en vaak komen ze ermee weg. Maar hier is het niet de overheid die de dienst uitmaakt, maar de browserleveranciers. Overheidsorganisaties zijn te groot, te log, te traag en hebben te weinig expertise om de snelheid van technologische ontwikkelingen bij te houden. Binnen de overheid komt men er vaak mee weg, maar hier worden simpelweg uitgegeven certificaten door browserleveranciers ongeldig verklaard en is het leed niet te overzien.
Reageren
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.
