Diginotar heeft google.com uitgegeven

[CyBeR]

Anoniem: 55140 schreef op zaterdag 03 september 2011 @ 02:19:
[...]

DNSSEC zal de situatie niet beter maken. Dat brengt weer compleet andere risico's met zich mee.

DNSSEC geeft je een redelijke manier om te stellen: "deze DNS-informatie komt bij de originele bron vandaan". Daarna kun je die gebruiken om te stellen: "deze CA('s) gebruiken wij om certificaten te ondertekenen".

Thralas schreef op zaterdag 03 september 2011 @ 02:28:
[...]


Comodo is too big to fail. DigiNotar niet.

Niet persee. Als de private key van de root van Comodo uitlekt kunnen ze groter zijn dan de maan, die CA gaat eruit. Idem Verisign en Thawte (beide nog groter.)

[ Voor 27% gewijzigd door CyBeR op 03-09-2011 03:04 ]

[Anoniem: 55140]

CyBeR schreef op zaterdag 03 september 2011 @ 03:02:
[...]


DNSSEC geeft je een redelijke manier om te stellen: "deze DNS-informatie komt bij de originele bron vandaan". Daarna kun je die gebruiken om te stellen: "deze CA('s) gebruiken wij om certificaten te ondertekenen"

SSL And The Future Of Authenticity
Lees die blog post maar eens, heeft een hele sectie over DNSSEC en waarom het geen goed idee is.

[CyBeR]

Anoniem: 55140 schreef op zaterdag 03 september 2011 @ 03:13:
[...]


SSL And The Future Of Authenticity
Lees die blog post maar eens, heeft een hele sectie over DNSSEC en waarom het geen goed idee is.

Dat is iets anders dan ik bedoel.

Ik vind het systeem van CA's die identiteiten verifieren enzo op zich prima, het enige probleem is dat DigiNotar een certificaat voor google.com kan genereren wat mijn brower vervolgens prima vindt, terwijl Google eigenlijk zaken doet met Thawte. Met andere woorden: een certificaat voor google.com gegenereerd door DigiNotar is per definitie ongeldig.

Het huidige CA-model heeft daar geen enkele voorziening voor. En die voorziening is ook niet echt te maken omdat de enige bron van technische adresinformatie DNS is, en DNS ook eigenlijk zo onveilig is als de pest.

DNSSEC poogt dat laatste op te lossen; met DNSSEC kan een gebruiker van een domein controleren of de DNS-responses kloppen met wat de houder van een domein ingesteld heeft. Op zo'n moment kun je dus een extra controle in je SSL proces aanbrengen: klopt het certificaat met de gegeven url (doen we nu al), klopt de certificate chain (doen we nu al), en mag de CA van die chain wel certificaten ondertekenen voor dit domein?.

Het stuk waar je naar linkt gaat over het vervangen van het CA-systeem door DNSSEC. Dat lijkt me inderdaad geen goed idee en is niet wat ik voorstel. Het moet ook alleen een extra controle zijn waar de certificaten gecontroleerd worden aan de hand van DNS, zoals bij SSL het geval is; in het geval van bijvoorbeeld S/MIME certs werkt het bijvoorbeeld niet op die manier.

[ Voor 7% gewijzigd door CyBeR op 03-09-2011 03:24 ]

[Thralas]

CyBeR schreef op zaterdag 03 september 2011 @ 03:02:
Niet persee. Als de private key van de root van Comodo uitlekt kunnen ze groter zijn dan de maan, die CA gaat eruit. Idem Verisign en Thawte (beide nog groter.)

Ik bedoelde dan ook dat Comodo wel wegkwam met een enkel incident waarbij 'valse' certificaten werden gesigned. Op het moment dat een private key van een trusted CA zou lekken is de authenticity-value van SSL wel geruduceerd tot 0 ja..

[__fred__]

CyBeR schreef op zaterdag 03 september 2011 @ 03:22:
[...]

DNSSEC poogt dat laatste op te lossen; met DNSSEC kan een gebruiker van een domein controleren of de DNS-responses kloppen met wat de houder van een domein ingesteld heeft. Op zo'n moment kun je dus een extra controle in je SSL proces aanbrengen: klopt het certificaat met de gegeven url (doen we nu al), klopt de certificate chain (doen we nu al), en mag de CA van die chain wel certificaten ondertekenen voor dit domein?.

Ik denk dat Dnssec dit soort hacks nog veel erger maakt. De hackers hadden net zo goed wat extra certificaten voor hun dns infrasstructuur kunnen genereren, en de midm attack op deze manier nog meer legitimiteit kunnen geven.

Het zijn dezelfde ca's die dezelfde certificaten voor dnssec uitgeven.

[CyBeR]

__fred__ schreef op zaterdag 03 september 2011 @ 09:11:
[...]

Het zijn dezelfde ca's die dezelfde certificaten voor dnssec uitgeven.

Nee, dat is niet zo. DNSSEC gebruikt een chain of trust vanaf de root van DNS, en daar hebben de CA's niets mee te maken.

Afgezien van dat .com en .net door Verisign geexploiteerd worden.

[ Voor 10% gewijzigd door CyBeR op 03-09-2011 09:32 ]

[Equator]

Thralas schreef op zaterdag 03 september 2011 @ 02:28:
[...]


Comodo is too big to fail. DigiNotar niet.

En hoe zit dat dan met Verisign. Die is nog een stukje groter in mijn beleving.
Maar daar werd tot 2x toe met succes een certificaat aangevraagd (Code signing) op naam de "Microsoft Corporation" door een bedrijf die helemaal niets met Microsoft te maken had.

Daar is een werknemer van het bedrijf behoorlijk in de fout gegaan. De beste man is ontslagen, en de certificaten direct ingetrokken. Microsoft heeft in een security patch ook de certificaten opgenomen als expliciet not-trusted. (je vind ze dan ook terug in de non-trusted certificate store op welke windows PC)

Initieel dacht ik "Dit had prima met Diginotar ook gekund. Maar nee, we trashen de gehele Diginotar Root CA. Persoonlijk vind ik dat overdone. Een ferme waarschuwing, en klaar".

Maar aangezien ze gewoon gefaald hebben in hun due diligence, en niet direct geacteerd hebben is dit toch best een redenlijke actie. Als blijkt dat je niet met de verantwoordelijkheid om kan gaan, dan moet je er maar mee stoppen.

Gelukkig zijn er nog genoeg PKIoverheid CSP's. Dat de overheid dit in eigen beheer wil nemen lijkt mij geen goed plan. Dat kost alleen maar meer geld. Uitbesteden dus. CyBeR had al een lijstje van CSP's die dat over kunnen nemen.

[ralpje]

Bij Verisign ging het om twee certs en een medewerker die zat te slapen.
Bij DigiNotar gaat het om een security-flaw die is ontdekt maar stilgehouden, waardoor het sinds medio juli mogelijk was om zelf certs te laten signen. Dat zijn iets meer certs dan 2 geweest, ben ik bang.
Het is dan een stuk praktischer om de hele root CA te 'untrusten', dan om alle individuele certs op te zoeken in de logs stuk voor stuk te untrusten.

Daarnaast is het meer een sanctie voor DigiNotar als bedrijf. Een firma die zo met zulke issues omgaat verdient het vertrouwen niet om certs te mogen uitdelen.

[Anoniem: 26306]

CyBeR schreef op zaterdag 03 september 2011 @ 03:22:

Dat is iets anders dan ik bedoel.

Ik vind het systeem van CA's die identiteiten verifieren enzo op zich prima, het enige probleem is dat DigiNotar een certificaat voor google.com kan genereren wat mijn brower vervolgens prima vindt, terwijl Google eigenlijk zaken doet met Thawte. Met andere woorden: een certificaat voor google.com gegenereerd door DigiNotar is per definitie ongeldig.

Het huidige CA-model heeft daar geen enkele voorziening voor. En die voorziening is ook niet echt te maken omdat de enige bron van technische adresinformatie DNS is, en DNS ook eigenlijk zo onveilig is als de pest.

DNSSEC poogt dat laatste op te lossen; met DNSSEC kan een gebruiker van een domein controleren of de DNS-responses kloppen met wat de houder van een domein ingesteld heeft. Op zo'n moment kun je dus een extra controle in je SSL proces aanbrengen: klopt het certificaat met de gegeven url (doen we nu al), klopt de certificate chain (doen we nu al), en mag de CA van die chain wel certificaten ondertekenen voor dit domein?.

Het stuk waar je naar linkt gaat over het vervangen van het CA-systeem door DNSSEC. Dat lijkt me inderdaad geen goed idee en is niet wat ik voorstel. Het moet ook alleen een extra controle zijn waar de certificaten gecontroleerd worden aan de hand van DNS, zoals bij SSL het geval is; in het geval van bijvoorbeeld S/MIME certs werkt het bijvoorbeeld niet op die manier.

Akkoord, echter vangt dit nog niet af dat toevalligerwijs de juiste CA kan worden gehackt en dat ook dat dus geen garanties geeft. Een combinatie van EV en DNSSEC zou dan nog steeds kunnen falen.

Ik denk persoonlijk dat er een nieuw systeem moet komen. Als we EV als 1e generatie SSL certificaten zien, moeten we ons eigenlijk bezighouden met 2e generatie EV SSL certificaten. We moeten liefst af van een single point of failure. Ik stel dan een systeem voor waarbij:

- Een SSL certificaat door meerdere CA's moet zijn ondertekend.
- OCSP verificatie van alle signatures verplicht is.
- DNSSEC wordt meegenomen in de infrastructuur.
- Een CA niet voor elke TLD certificaten mag uitgeven.

Dat laatste zal lastig worden qua risico's op een monopolie, echter is dat bij certificaten voor overheidsinstellingen juist niet zo'n gek idee. Ik zie niet in waarom ik een SSL certificaat voor een .nl-domeinnaam zou willen aanschaffen bij bijvoorbeeld Türktrust.

Behalve die groene browserbalk, wil ik dan ook een security level zien, namelijk het aantal CA's dat het certificaat heeft ondertekend. Ik zou dan ook bijvoorbeeld willen kunnen instellen dat voor EV-2G certificaten ik wil dat minimaal 2 CA's hem hebben ondertekend. Als er dan één CA niet trusted is, valt het certificaat simpelweg een beveiligingsniveau terug. In dit geval zou voor *.google.com in Iran dan "beveiligingsniveau 1" hebben gestaan terwijl bijvoorbeeld 2 of 3 vereist is.

Er zijn ongetwijfeld verbeterpunten aan een infrastructuur als deze, maar ik denk dat nu is aangetoond dat een SPOF te gevaarlijk is.

[CyBeR]

Anoniem: 26306 schreef op zaterdag 03 september 2011 @ 09:55:
[...]

Akkoord, echter vangt dit nog niet af dat toevalligerwijs de juiste CA kan worden gehackt en dat ook dat dus geen garanties geeft. Een combinatie van EV en DNSSEC zou dan nog steeds kunnen falen.

Je zou eventueel ook een specifieke fingerprint erin kwijt kunnen: "dit is het certificaat dat je gepresenteerd zou moeten worden".

Punt is: op dit moment bestaat heel een dergelijk mechanisme gewoon niet. Dit probleem zouden we niet gehad hebben als dat er wel was.

[Anoniem: 26306]

CyBeR schreef op zaterdag 03 september 2011 @ 10:06:

Je zou eventueel ook een specifieke fingerprint erin kwijt kunnen: "dit is het certificaat dat je gepresenteerd zou moeten worden".

Je bedoelt dan neem ik aan dat je dat in een DNS record zou kunnen vastleggen? Aangezien je DNSSEC wilt betrekken, want zonder DNSSEC is een DNS record natuurlijk nog steeds niets waard.

Punt is: op dit moment bestaat heel een dergelijk mechanisme gewoon niet. Dit probleem zouden we niet gehad hebben als dat er wel was.

Zaak om daaraan te gaan werken dus

Het wordt technisch een stuk ingewikkelder, maar ik denk dat dat op zich geen probleem moet zijn. Dan moeten beheerders maar iets beter worden opgeleid, denk ik zo.

Theoretische procedure:

1: Persoon genereert private key (minimaal een x aantal bits) en CSR.
2: Die CSR moet naar minstens 2, maar liever 3 of meer verschillende CA's.
3: CA's genereren elk een certificaat aan de hand van de CSR en sturen dit terug.
4: Persoon installeert de certificaten en voegt voor elk certificaat een DNS record toe (signature bijvoorbeeld).

Daarna moet een browser (of andere client) bij de server in de handshake élk SSL certificaat controleren (eventueel OCSP check en DNS check) en vergelijken of de belangrijke velden uit de certificaten overeenkomen. En zo heb je meer zekerheid en kan de client verder onderhandelen over het te gebruiken cipher etc. Maar de handshake is dan een stuk verbeterd.

Voor een succesvolle MitM aanval is dan nodig:

- Een gecompromitteerd DNS systeem.
- Minstens 2 of 3 certificaten van vertrouwde CA's.

Dit maakt het nog niet onmogelijk, maar wel véél lastiger dan het nu was. Eén gehackte server was nu waarschijnlijk voldoende.

[Gomez12]

Equator schreef op zaterdag 03 september 2011 @ 09:21:
[...]
En hoe zit dat dan met Verisign. Die is nog een stukje groter in mijn beleving.
Maar daar werd tot 2x toe met succes een certificaat aangevraagd (Code signing) op naam de "Microsoft Corporation" door een bedrijf die helemaal niets met Microsoft te maken had.
...
Initieel dacht ik "Dit had prima met Diginotar ook gekund. Maar nee, we trashen de gehele Diginotar Root CA. Persoonlijk vind ik dat overdone. Een ferme waarschuwing, en klaar".

Het verschil tussen verisign en diginotar is, bij verisign wisten ze het aantal foutieve certificaten en ze deden er iets tegen.

Bij diginotar was het meer :
- We weten dat we gehackt zijn, maar dit houden we stil
- We weten dat er certificaten uitgegeven zijn, maar zelfs na een audit missen we nog een google.com
- Na het opmerken van de media qua iran wordt er nog steeds niets gezegd over bijv de tor-certificaten (had diginotar dat wel inzichtelijk?)
Als diginotar niet getrashed was dan vraag ik me af hoeveel certificaten er nog zouden opduiken, diginotar geeft tot nu toe geen 100% openheid en het is voor mij maar net de vraag of ze het wel 100% inzichtelijk hebben.

Revoken werkt alleen maar als er 100% duidelijkheid is wat er gerevoked moet worden, dat is simpelweg bij diginotar niet het geval dus er is een kans dat je tot in de eeuwigheid losse certificaten kan revoken als ze door externe partijen opgemerkt worden.

[CyBeR]

"geen 100% openheid"? Dat is understating zeg. Ik heb nul openheid van ze gezien.

[Vinnienerd]

CyBeR schreef op zaterdag 03 september 2011 @ 10:06:
[...]


Je zou eventueel ook een specifieke fingerprint erin kwijt kunnen: "dit is het certificaat dat je gepresenteerd zou moeten worden".

Punt is: op dit moment bestaat heel een dergelijk mechanisme gewoon niet. Dit probleem zouden we niet gehad hebben als dat er wel was.

Chrome heeft de google.com certificaten ingebakken als ik me niet vergis. Het zou in ieder geval helpen als je een waarschuwing krijgt wanneer het certificaat van een website opeens een andere issuer heeft. Dan kun je als website wel netjes een recenter certificaat of een certificaat met sterkere versleuteling aanbrengen, maar gaan er toch alarmbellen rinkelen als de issuer opeens Comodo is geworden terwijl je eerst VeriSign had oid.

[Gomez12]

Vinnienerd schreef op zaterdag 03 september 2011 @ 15:55:
[...]
Het zou in ieder geval helpen als je een waarschuwing krijgt wanneer het certificaat van een website opeens een andere issuer heeft. Dan kun je als website wel netjes een recenter certificaat of een certificaat met sterkere versleuteling aanbrengen, maar gaan er toch alarmbellen rinkelen als de issuer opeens Comodo is geworden terwijl je eerst VeriSign had oid.

Dat is geen beveiliging, dat is enkel machtsmisbruik in de hand werken.

Daarmee dwing je een partij om altijd bij dezelfde CA te blijven.

Dan kan een verisign dus bijv bij grotere partijen extra kosten gaan rekenen, want een amazon / google / microsoft / nederlandse staat kan het zich niet veroorloven dat er ook maar enige onduidelijkheid ontstaat qua betrouwbaarheid

[Tourniquet]

Iraanse (en Turkse) hackers hebben in 2009 al wat berichtjes achtergelaten op een DigiNotar portal, heeft F-Secure ontdekt.

[ Voor 9% gewijzigd door Tourniquet op 03-09-2011 16:08 ]

[Gomez12]

Wat ik me net even zit af te vragen : Zijn er ook vanuit Diginotar / NL overheid al publiekelijke instructies vrijgegeven hoe je de certificaten blokkeert in oudere browsers?

Want bijv bedrijven zijn notoire achterlopers qua browserupdates. Het is heel leuk dat de nieuwste FF/IE het blockt, maar daar schiet je weinig mee op als je als bedrijf 3 versies achterloopt.

En dan zit je dus even te kijken op de diginotar site zelf en dan zie je dus dat die mensen nog niet eens na vermelden dat de pki certificaten van diginotar ook niet meer 100% vertrouwd worden. Lekkere club is dat...

[Vinnienerd]

Gomez12 schreef op zaterdag 03 september 2011 @ 16:32:
Wat ik me net even zit af te vragen : Zijn er ook vanuit Diginotar / NL overheid al publiekelijke instructies vrijgegeven hoe je de certificaten blokkeert in oudere browsers?

Want bijv bedrijven zijn notoire achterlopers qua browserupdates. Het is heel leuk dat de nieuwste FF/IE het blockt, maar daar schiet je weinig mee op als je als bedrijf 3 versies achterloopt.

En dan zit je dus even te kijken op de diginotar site zelf en dan zie je dus dat die mensen nog niet eens na vermelden dat de pki certificaten van diginotar ook niet meer 100% vertrouwd worden. Lekkere club is dat...

Je kan toch via een GPOtje de desbetreffende (root) CA's toch blokkeren?

[Gomez12]

Vinnienerd schreef op zaterdag 03 september 2011 @ 17:50:
[...]
Je kan toch via een GPOtje de desbetreffende (root) CA's toch blokkeren?

FF die behoorlijk via GPO's werkt?

[CyBeR]

Gomez12 schreef op zaterdag 03 september 2011 @ 16:32:
Wat ik me net even zit af te vragen : Zijn er ook vanuit Diginotar / NL overheid al publiekelijke instructies vrijgegeven hoe je de certificaten blokkeert in oudere browsers?

Want bijv bedrijven zijn notoire achterlopers qua browserupdates. Het is heel leuk dat de nieuwste FF/IE het blockt, maar daar schiet je weinig mee op als je als bedrijf 3 versies achterloopt.

Dat lijkt me heel sterk het probleem van de niet-updatende bedrijven. Moeten ze maar updaten.

Er zijn gangbare manieren om met het probleem vertrouwensbreuk in CA's om te gaan, namelijk het revoken van de certificaten. Als beheerders ervoor zorgen dat die manieren niet werken én vervolgens ook hun software niet up-to-date houden is dat hun eigen verantwoordelijkheid.

[RaZ]

CyBeR schreef op zaterdag 03 september 2011 @ 20:38:
[...]


Dat lijkt me heel sterk het probleem van de niet-updatende bedrijven. Moeten ze maar updaten.

Er zijn gangbare manieren om met het probleem vertrouwensbreuk in CA's om te gaan, namelijk het revoken van de certificaten. Als beheerders ervoor zorgen dat die manieren niet werken én vervolgens ook hun software niet up-to-date houden is dat hun eigen verantwoordelijkheid.

Aan de ene kant kan ik hier helemaal in mee gaan. Aan de andere zeg ik ook wel, nee.

Er zijn zat mensen die prive dingen doen op de computers die ze op hun werk ter beschikking hebben. Even een mailtje via Gmail cq. Hotmail. Noem maar op. Ligt die verantwoordelijk dan direct bij de werkgever? Ik vind van niet.

Bedrijven waar webapps (intranet) enkel draaien in IE6 zullen gewoon niet zo snel updaten. De vraag is dan of ze voor hun werk uberhaupt met https werken, en dan vind ik niet dat de werkgever schuld heeft omdat iemand uit gemakzucht spullen van de werkgever voor prive doeleinden gebruikt.

Ik denk dat je de situatie ietswat te zwart/wit ziet eerlijk gezegd.

[Vinnienerd]

Gomez12 schreef op zaterdag 03 september 2011 @ 17:52:
[...]

FF die behoorlijk via GPO's werkt?

Bedrijven die met FF werken?

[Edgarz]

Tourniquet schreef op zaterdag 03 september 2011 @ 16:05:
Iraanse (en Turkse) hackers hebben in 2009 al wat berichtjes achtergelaten op een DigiNotar portal, heeft F-Secure ontdekt.

[afbeelding]

Dit is heftige shit... Als ik lees dat deze berichten in 2009 al achtergelaten zijn en dat andere internationale organisaties al vanaf 2006 gehackt zijn (McAfee bericht juli 2011) dan vrees ik met grote vrees dat beveiligingsmaatregelen eigenlijk jaren achterlopen op de hackers. En dat is een verontrustende gedachte...

[Dennism]

RaZ schreef op zaterdag 03 september 2011 @ 20:51:
[...]

Aan de ene kant kan ik hier helemaal in mee gaan. Aan de andere zeg ik ook wel, nee.

Er zijn zat mensen die prive dingen doen op de computers die ze op hun werk ter beschikking hebben. Even een mailtje via Gmail cq. Hotmail. Noem maar op. Ligt die verantwoordelijk dan direct bij de werkgever? Ik vind van niet.

Bedrijven waar webapps (intranet) enkel draaien in IE6 zullen gewoon niet zo snel updaten. De vraag is dan of ze voor hun werk uberhaupt met https werken, en dan vind ik niet dat de werkgever schuld heeft omdat iemand uit gemakzucht spullen van de werkgever voor prive doeleinden gebruikt.

Ik denk dat je de situatie ietswat te zwart/wit ziet eerlijk gezegd.

Sorry, maar IE 6.0 webapps zijn toch ook echt niet meer van deze tijd. ie 6.0 stamt uit 2001? Ik snap echt wel dat je als een groot bedrijf even de kat uit de boom kijkt qua nieuwe releases van applicaties maar als je heden ten dage nog niet de investering gedaan hebt om je applicaties te updaten dan zit er toch iets mis in je bedrijf. De ondersteuning voor IE6 is al tijden minimaal in web land en dit zal echt niet meer toe gaan nemen. security issues zullen echter wel groter en groter worden, en dan gaat het hier nog niet eens om prive zaken, ik weet bijvoorbeeld dat de belastingsdienst ook certs van diginotar gebruik(te).

[Freee!!]

Edgarz schreef op zaterdag 03 september 2011 @ 20:52:
[...]
dan vrees ik met grote vrees dat beveiligingsmaatregelen eigenlijk jaren achterlopen op de hackers.

En dat is nieuws voor jou

En dat is een verontrustende gedachte...

Eindelijk wakker

[CyBeR]

RaZ schreef op zaterdag 03 september 2011 @ 20:51:
[...]

Aan de ene kant kan ik hier helemaal in mee gaan. Aan de andere zeg ik ook wel, nee.

Er zijn zat mensen die prive dingen doen op de computers die ze op hun werk ter beschikking hebben. Even een mailtje via Gmail cq. Hotmail. Noem maar op. Ligt die verantwoordelijk dan direct bij de werkgever? Ik vind van niet.

Ik betwijfel ten zeerste of die mensen dergelijke prive-zaken op hun werk doen. Ik open op kantoor al niet eens de ING en dan ben ik notabene zélf de beheerder.

De verantwoordelijkheid voor veilige privécommunicatie ligt altijd bij jou zelf.

[ Voor 6% gewijzigd door CyBeR op 03-09-2011 22:08 ]

[RaZ]

Als het kan, dan kan het, en is de kans reeel dat het gebeurd.

Ik heb bij m'n oude werk menig rabo-reader of abn-ding gezien bij collega's. En dat komt niet omdat hun de partner niet vertrouwen met bankzaken

Zo zit m'n chef rustig te internet bankieren op de zaak, en online te shoppen met ideal. De ene keer doet ie het lokaal met de browser op de dekstop, de andere keer zit ie in een terminal server sessie omdat de administratie via exact loopt (hoofdkantoor staat 100km verder op). Opzich niks mis mee, maar lopen zeuren dat youtube niet goed werkt terwijl je in een TS sessie zit (op windows 2000 ook nog eens) begin ik dan weer te lachen.

Men is zich simpelweg niet bewust van zulke gevaren.

[CyBeR]

Dat maakt het niet minder hun eigen verantwoordelijkheid, imo. Het is nou ook weer niet zo dat dit heel moeilijk is ofzo...

[user109731]

Volgens mij nog niet genoemd, maar Mozilla is bezig met een actie om webmasters te waarschuwen dat hun certificaat binnenkort geweigerd gaat worden. Alle hulp hierbij is welkom trouwens

[Gomez12]

CyBeR schreef op zaterdag 03 september 2011 @ 22:02:
[...]
Ik betwijfel ten zeerste of die mensen dergelijke prive-zaken op hun werk doen. Ik open op kantoor al niet eens de ING en dan ben ik notabene zélf de beheerder.

Ach, ik heb ze door de jaren heen gezien, van porno-video sites bekijken tot aan uitgebreid belastingaangiftes invullen en ondertussen de belastingtelefoon aan de lijn hebben op de werktelefoon tot aan iemand die 5 uur op een 8-urige werkdag IE met hotmail als actief venster had staan.

En dan niet echt in de pauzes.

De verantwoordelijkheid voor veilige privécommunicatie ligt altijd bij jou zelf.

Het ligt ietwat gecompliceerder, werkgever moet het accepteren dat je x tijd je eigen dingen kan doen met door werk verleende spullen. Werkgever is verplicht om een goede werkomgeving te verschaffen.

En tja, als je dan een minister hebt die iets (probeert) uit te leggen op het landelijke journaal dan denk ik best dat dat op te vatten is als slecht beheer als je dat als werkgever totaal naast je neerlegt omdat het volgens jou niet voor de werkzaamheden van toepassing is.

[YouKnow]

Edgarz schreef op zaterdag 03 september 2011 @ 20:52:
[...]


Dit is heftige shit... Als ik lees dat deze berichten in 2009 al achtergelaten zijn en dat andere internationale organisaties al vanaf 2006 gehackt zijn (McAfee bericht juli 2011) dan vrees ik met grote vrees dat beveiligingsmaatregelen eigenlijk jaren achterlopen op de hackers. En dat is een verontrustende gedachte...

Dat is Operation Shady RAT geweest, en dat staat hier naar mijn weten gewoon los van.. Maar inderdaad, welkom in de grote wereld - ik verwacht dat er op korte termijn nog een aantal andere/grotere dingen bekend gaan worden..

[Tourniquet]

quote: http://nos.nl/artikel/269...stsites-doelwit-hack.html

CIA, Mossad, providers, protestsites doelwit hack


Grote sites doelwit Iraanse hackers

Toegevoegd: zondag 4 sep 2011, 16:50
Door verslaggever Jeroen Wollaars met medewerking van Nieuwsuur-redacteur Roozbeh Kaboly

Onder de websites die na de hack bij het Nederlandse bedrijf Diginotar waarschijnlijk zijn afgeluisterd door Iraanse hackers, bevinden zich alle grote aanbieders van e-maildiensten en sociale netwerken. Ook geheime diensten en Iraanse oppositiesites staan op de lijst van vijftig domeinen die in het bezit is van de NOS. De lijst lijkt ook een boodschap van de hackers te bevatten.

Vorige week werd bekend dat in elk geval de e-maildienst GMail van Google was getroffen door de hack en mogelijk wekenlang is afgeluisterd. Naar nu blijkt zijn ook valse certificaten uitgegeven voor Yahoo, Hotmail, Microsoft Messenger, Twitter, Facebook en Skype.

Dissidenten
Vooral Yahoo wordt veel door Iraanse dissidenten gebruikt om via internet te kunnen communiceren. Op de lijst komt verder de site balatarin.com voor. Dat is een veelgebruikte site van de oppositie die is opgezet door Iraniërs die in Amerika wonen om interessante websites met elkaar te delen. Hetzelfde geldt voor de site azadegi.com (dat Vrijheid betekent).

Geheime diensten
Opvallend is verder dat ook voor websites van een aantal internationale geheime diensten valse certificaten zijn gemaakt. Het gaat onder meer om de Israëlische Mossad, de Amerikaanse CIA en MI6 in het Verenigd Koninkrijk. Ook de Iraanse versie van de website van het ministerie van Buitenlandse Zaken van Israel staat op de lijst.

Iraanse internetbezoekers zouden via die vervalste certificaten kunnen worden omgeleid naar nepversies van die sites en gevoelige informatie zou zo bij de Iraanse overheid terecht kunnen komen. Al is de kans niet heel groot dat geheime diensten openbare websites voor gevoelige operaties gebruiken.

Aangepaste software
Daarnaast maakten de hackers certificaten aan voor de software-update-functie van Microsoft, wat er op wijst dat ze mogelijk ook aangepaste programmatuur verspreid hebben om afluisteren nog makkelijker te maken.

Boodschap van de hackers
Opvallend is verder dat het lijkt alsof de hackers een afzender hebben achtergelaten. Er staan drie domeinen op de lijst in het Perzisch, de Iraanse taal: JanamFadayeRahbar.com, RamzShekaneBozorg.com en SahebeDonyayeDigital.com

Janam Fadaye Rahbar verwijst naar een gevleugelde uitspraak van de Revolutionaire Garde van Iran die de Islamitische Staat moet beschermen. Het is gebruikelijk dat die term wordt achtergelaten wanneer zij websites hacken. Het betekent 'ik offer mezelf op voor de Grote Leider'. De term dook ook op bij een vergelijkbare hack bij het certificatenbedrijf Comodo eerder dit jaar.

Ramz Shekane Bozorg betekent 'De Grote Codekraker' en Sahebe Donyaye Digital betekent 'De Eigenaar van de Digitale Wereld'. De berichten wekken de indruk dat de Revolutionaire Garde van Iran achter de kraak zit, maar zeker is dat niet. De laatste twee termen worden niet gebruikt door de Iraanse overheid en doen wat minder professioneel aan.

Complete lijst
CN=*.10million.org
CN=*.JanamFadayeRahbar.com
CN=*.RamzShekaneBozorg.com
CN=*.SahebeDonyayeDigital.com
CN=*.android.com
CN=*.aol.com
CN=*.azadegi.com
CN=*.balatarin.com
CN=*.comodo.com
CN=*.digicert.com
CN=*.globalsign.com
CN=*.google.com
CN=*.microsoft.com
CN=*.mossad.gov.il
CN=*.mozilla.org
CN=*.skype.com
CN=*.startssl.com
CN=*.thawte.com
CN=*.torproject.org
CN=*.walla.co.il
CN=*.windowsupdate.com
CN=*.wordpress.com
CN=Comodo Root CA
CN=CyberTrust Root CA
CN=DigiCert Root CA
CN=Equifax Root CA
CN=GlobalSign Root CA
CN=Thawte Root CA
CN=VeriSign Root CA
CN=addons.mozilla.org
CN=azadegi.com
CN=friends.walla.co.il
CN=login.live.com
CN=login.yahoo.com
CN=my.screenname.aol.com
CN=secure.logmein.com
CN=twitter.com
CN=wordpress.com
CN=www.10million.org
CN=www.Equifax.com
CN=www.balatarin.com
CN=www.cia.gov
CN=www.cybertrust.com
CN=www.facebook.com
CN=www.globalsign.com
CN=www.google.com
CN=www.hamdami.com
CN=www.mossad.gov.il
CN=www.sis.gov.uk
CN=www.update.microsoft.com

[Fish]

Lol vraag eens een certifikaat aan

https://aanvraagformulier...Forms/controls/index.aspx
*bam* failed

zowiezo belachelijk dat ze deze nog durven te verkopen

[Marzman]

Op hun site staat ook nog steeds dat er niks aan de hand is.

Actueel
> PKIoverheid certificaten van DigiNotar nog steeds vertrouwd
Lees hier het nieuwsbericht van Logius.
> Informatie voor gebruikers van DigiNotar certificaten
Op Internet zijn berichten verschenen over DigiNotar-certificaten die niet meer vertrouwd worden door verschillende browsers (Microsoft Internet Explo...
> Betrouwbaarheid PKIoverheid certificaten niet in het geding
Lees hier het nieuwsbericht van Logius.

[Fish]

PKIoverheid-certificaten van DigiNotar nog steeds vertrouwd

linkt naar ->
http://www.logius.nl/actu...tar-nog-steeds-vertrouwd/

Maar dan wel vergeten te referen naar de update

http://www.logius.nl/actu...ficaten-van-diginotar-op/


sneaky gasten
kansloos ze moeten gewoon de normale frontpage platgooien en sorry schrijven ofzo, eigenlijk al te laat
wel jammer voor de mensen die er werken en er niks aan kunnen doen

[ Voor 18% gewijzigd door Fish op 04-09-2011 18:27 ]

[Ulysses]

http://webwereld.nl/Poll/vote/ gezien?... toch frappant merendeel wil SSL redesignen, ik dus ook, als ik ook mag meestemmen over de oplossing wordt het meerdere CA's per Cert voor Extra Extended validatie op overheidssites e.d. maar voor webwinkels optioneel, aangezien het aanzienlijke lag oplevert en echte topgeheimen offsite staan en

[Anoniem: 353137]

Heeft DigiD nieuwe certificaten van Getronics??

[Fish]

kan die staat op de lijst

ja

Op dit certificaat is de CPS van Getronics PinkRoccade van toepassing, welke kan worden geraadpleegd op: https://www.pki.getronicspinkroccade.nl/pkioverheid/cps

[ Voor 77% gewijzigd door Fish op 04-09-2011 21:18 ]

[T-8one]

Anoniem: 353137 schreef op zondag 04 september 2011 @ 21:11:
Heeft DigiD nieuwe certificaten van Getronics??

Jup, daar lijkt het indd op.


iets anders, als ik het goed begrijp had Iran theoretisch de mogelijkheid om custom windowsupdates aan te bieden: http://webwereld.nl/nieuw...mijnt-windows-update.html

[ Voor 34% gewijzigd door T-8one op 04-09-2011 21:19 ]

[CyBeR]

Anoniem: 353137 schreef op zondag 04 september 2011 @ 21:11:
Heeft DigiD nieuwe certificaten van Getronics??

Yup:

$ openssl s_client -connect as.digid.nl:443 | openssl x509 -issuer
depth=3 /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA
[..]
issuer= /C=NL/O=Getronics PinkRoccade Nederland B.V./CN=Getronics PinkRoccade PKIoverheid CA - Overheid en Bedrijven

Gek genoeg een tijdelijke voor vier maanden, die expiret op 1 januari 2012:

notBefore=Sep  4 00:00:00 2011 GMT
notAfter=Dec 31 23:59:59 2011 GMT

[ Voor 15% gewijzigd door CyBeR op 04-09-2011 21:23 ]

[Anoniem: 353137]

CyBeR schreef op zondag 04 september 2011 @ 21:20:
[...]


Yup:

$ openssl s_client -connect as.digid.nl:443 | openssl x509 -issuer
depth=3 /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA
[..]
issuer= /C=NL/O=Getronics PinkRoccade Nederland B.V./CN=Getronics PinkRoccade PKIoverheid CA - Overheid en Bedrijven

Gek genoeg een tijdelijke voor vier maanden, die expiret op 1 januari 2012:

notBefore=Sep  4 00:00:00 2011 GMT
notAfter=Dec 31 23:59:59 2011 GMT

is die betrouwbaar dan?

[Gomez12]

CyBeR schreef op zondag 04 september 2011 @ 21:20:
[...]


Yup:

$ openssl s_client -connect as.digid.nl:443 | openssl x509 -issuer
depth=3 /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA
[..]
issuer= /C=NL/O=Getronics PinkRoccade Nederland B.V./CN=Getronics PinkRoccade PKIoverheid CA - Overheid en Bedrijven

Gek genoeg een tijdelijke voor drie maanden, die expiret op 1 januari 2012:

notBefore=Sep  4 00:00:00 2011 GMT
notAfter=Dec 31 23:59:59 2011 GMT

Waarom gek genoeg? Ik vind het niet meer dan normaal dat de NL-overheid eerst voor een tussenoplossing gaat om daarna het hele traject te herzien en mogelijk ook een Getronics nog af te keuren.

Momenteel zijn er fouten bij Diginotar geconstateerd, dan lijkt het mij vrij logisch dat je Getronics dan ook ff naloopt of die niet dezelfde fouten hebben. En in de tussentijd moet je toch iets.
Slaagt Getronics de test dan kan je altijd nog een nieuw cert uitgeven, komt Getronics niet door de test heb je max een certificaat tot eind 2011 wat theoretisch problematisch kan zijn.

Anoniem: 353137 schreef op zondag 04 september 2011 @ 21:27:
[...]


is die betrouwbaar dan?

Cynisch gezegd : In zoverre dat die nog niet naar buiten zijn gekomen met een hack, en dat er ook niemand anders naar buiten gekomen is met een hack van hun.
Praktisch gezegd : Dat verifieer je als overheid niet even in een weekje tijd. Dit is imho meer een stop-gap oplossing om in een langduriger traject de regels aan te scherpen.

[ Voor 17% gewijzigd door Gomez12 op 04-09-2011 21:30 ]

[Fish]

Anoniem: 353137 schreef op zondag 04 september 2011 @ 21:27:
[...]


is die betrouwbaar dan?

Waarom zou je deze niet vertrouwen en verisign wel ?

[leuk_he]

Anoniem: 353137 schreef op zondag 04 september 2011 @ 21:27:
[...]
is die betrouwbaar dan?

Het gaat enkel om het certificaat he? Niet de site van de overheid is gehacked, maar de certificaat uitgever.

[T-8one]

Ik lees trouwens overal dat de Iraanse overheid erachter zou zitten en de gestolen certificaten wil gebruiken/gebruikt. Waar is dit op gebaseerd?

[Gomez12]

leuk_he schreef op zondag 04 september 2011 @ 21:33:
[...]
Het gaat enkel om het certificaat he? Niet de site van de overheid is gehacked, maar de certificaat uitgever.

Wat dus opzich veel kwalijker is. Site-hack valt van binnenuit te achterhalen, certificaat uitgever hack betekent enkel maar dat je minder iran-bezoekers op je site ziet.

[leuk_he]

T-8one schreef op zondag 04 september 2011 @ 21:35:
Ik lees trouwens overal dat de Iraanse overheid erachter zou zitten en de gestolen certificaten wil gebruiken/gebruikt. Waar is dit op gebaseerd?

De valse google certificaten zijn in iran aangetroffen in het wild. De isp kan gehacked zijn door iraanse hackers of door de iraanse overheid. Dat verteld uiteraard niemand. De lijst bekende valse certificaten zijn ook opvallend. lees hierbovern nog maar eens. Tourniquet in "Diginotar heeft google.com uitgegeven" geen financieele sites, juist sites die cyberwarefare achtig zijn.

[frapex]

CyBeR schreef op zondag 04 september 2011 @ 21:20:
[...]


Yup:

$ openssl s_client -connect as.digid.nl:443 | openssl x509 -issuer
depth=3 /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA
[..]
issuer= /C=NL/O=Getronics PinkRoccade Nederland B.V./CN=Getronics PinkRoccade PKIoverheid CA - Overheid en Bedrijven

Gek genoeg een tijdelijke voor vier maanden, die expiret op 1 januari 2012:

notBefore=Sep  4 00:00:00 2011 GMT
notAfter=Dec 31 23:59:59 2011 GMT

Vanaf 1 januari 2012 zijn G2 certificaten vereist. De G2 certificaten worden al langer uitgegeven, tegelijk met G1 certificaten. Dit in verband met een tijdelijke overgangsfase. as.digid.nl gebruikt nog de G1 certificaten.

[CyBeR]

frapex schreef op zondag 04 september 2011 @ 21:43:
[...]

Vanaf 1 januari 2012 zijn G2 certificaten vereist. De G2 certificaten worden al langer uitgegeven, tegelijk met G1 certificaten. Dit in verband met een tijdelijke overgangsfase. as.digid.nl gebruikt nog de G1 certificaten.

Ah right, logisch. Gebrek aan G2 was me nog niet opgevallen.

[__fred__]

Aanpak DigiNotar-problematiek
5 september 2011

Bij het beheersen van de gevolgen van de problematiek met betrekking tot DigiNotar analyseert de overheid samen met het bedrijfsleven per sector potentiële gevolgen. Zodra de gevolgen per sector bekend zijn worden deze gepubliceerd door de overheid en het bedrijfsleven. Voor de fiscale sector heeft dit voor het ministerie van Financiën, VNO-NCW, MKB-Nederland en betrokken bedrijven geleid tot onderstaande conclusie.
Elektronische aangifte ondernemers
Naar aanleiding van de situatie rond de DigiNotar-beveiligingscertificaten is er intensief overleg gevoerd tussen de Belastingdienst, het ministerie van Financiën, VNO-NCW, MKB-Nederland, ICT~Office en diverse softwareleveranciers en belastingconsulenten. In het overleg is vastgesteld dat de systemen waarmee ondernemers direct of via hun intermediair aangifte doen ook in deze situatie kunnen blijven functioneren. Het systeem kent voldoende aanvullende waarborgen voor een veilige aangifte. Alle betrokken partijen zijn overeengekomen dat de situatie de komende tijd nauwgezet wordt gemonitord. Indien zich nieuwe ontwikkelingen voordoen, wordt in overleg met de betrokken partijen bepaald welke vervolgactie noodzakelijk is. Als zich onverhoopt toch vertragingen voordoen, dan zal de Belastingdienst hier coulant mee omgaan.

Andere sectoren
Over de andere sectoren vindt op dit moment intensieve analyse plaats door overheid en betrokken bedrijfsleven. Zodra deze resultaten bekend zijn worden deze per sector gepubliceerd.

Ah, heerlijk toch. We gaan gewoon lekker door met de huidige certificaten, niets aan de hand.

[Rukapul]

__fred__ schreef op maandag 05 september 2011 @ 12:45:
[...]


Ah, heerlijk toch. We gaan gewoon lekker door met de huidige certificaten, niets aan de hand.

Je kunt het heel makkelijk zo wegzetten, maar het is best denkbaar dat voor deze toepassing en in het grotere geheel van maatregelen het tijdelijk voortzetten van gebruik te verantwoorden is.

Belangrijk hier is o.a. dat de overheid deze uitspraken doet, dat de overheid de facto het beheer van het bedrijf heeft overgenomen, en dat de overheid de te beschermen dienst biedt. Door deze uitspraken te doen neemt de overheid ook verantwoordelijkheid over. Men zal onder andere er vrij zeker van zijn dat er geen certificaten zijn uitgegeven die gebruikt worden in de context van deze toepassing.

Trust is een complex begrip en moet nooit platgeslagen worden tot een enkele technische faciliteit.

[ Voor 3% gewijzigd door Rukapul op 05-09-2011 13:13 ]

[DDX]

Nos journaal weer lekkere onzin, digid is weer veilig...
Nee het is pas veilig als browsers zoals firefox en internetexplorer alle diginotar certificaten blokkeren.
(of als mensen zelf kijken of het een diginotar certificaat is als ze een site bezoeken, maar dat doet de gemiddelde consument echt niet)

[Rukapul]

DDX schreef op maandag 05 september 2011 @ 20:04:
Nos journaal weer lekkere onzin, digid is weer veilig...
Nee het is pas veilig als browsers zoals firefox en internetexplorer alle diginotar certificaten blokkeren.
(of als mensen zelf kijken of het een diginotar certificaat is als ze een site bezoeken, maar dat doet de gemiddelde consument echt niet)

Het ligt genuanceerder.

digid is alleen onveilig als
• er ongeauthoriseerd certificaat is uitgegeven (onwaarschijnlijk door Diginotar; zeer onwaarschijnlijk door een van de andere talloze CAs)
• men doorklikt bij een certificaat waarbij de verificatie faalt (waartoe de situatie met de gerevokeerde Diginotar certificaten uitnodigde)

Aangezien het eerste zeer onwaarschijnlijk is en het tweede geaddresseerd met het nieuwe certificaat is de uitspraak dat digid weer veilig is best redelijk..

[Tourniquet]

Ronald Prins van Fox-IT vanavond om 22u bij Nieuwsuur. Ben benieuwd!

Tevens: http://nos.nl/artikel/270...-zo-lek-als-een-zeef.html

Het bedrijf Diginotar, dat verantwoordelijk was voor de beveiliging van Nederlandse overheidssites, is zelf volstrekt onveilig. Dat blijkt uit een onderzoeksrapport dat de NOS heeft ingezien.

Zo stonden er op de computers van het bedrijf geen anti-virusprogramma's en draaide een belangrijke server zonder de juiste updates aan een besturingssysteem.

Verschillende systemen van het bedrijf zouden los van elkaar moeten werken, maar het was voor de hackers mogelijk van de ene computer naar de andere te komen. Verder gebruikten de medewerkers wachtwoorden die eenvoudig te achterhalen waren.

edit: Uitgebreide achtergrondinfo op Webwereld: http://webwereld.nl/nieuw...et-eens-virusscanner.html
Ben benieuwd of het rapport van Fox-IT nog openbaar wordt gemaakt.

[ Voor 11% gewijzigd door Tourniquet op 05-09-2011 20:59 ]

[CyBeR]

DDX schreef op maandag 05 september 2011 @ 20:04:
Nee het is pas veilig als browsers zoals firefox en internetexplorer alle diginotar certificaten blokkeren.

Dat geldt voor álle ssl-beveiligde sites. DigiD is daar niet speciaal in omdat zij toevallig normaal gesproken al DigiNotar gebruiken.

Ik zie ondertussen dat rdw.nl inmiddels over is gestapt op Verisign.

[ Voor 9% gewijzigd door CyBeR op 05-09-2011 21:17 ]

[Rukapul]

Tourniquet schreef op maandag 05 september 2011 @ 20:53:
Ronald Prins van Fox-IT vanavond om 22u bij Nieuwsuur. Ben benieuwd!

Tevens: http://nos.nl/artikel/270...-zo-lek-als-een-zeef.html


[...]



edit: Uitgebreide achtergrondinfo op Webwereld: http://webwereld.nl/nieuw...et-eens-virusscanner.html
Ben benieuwd of het rapport van Fox-IT nog openbaar wordt gemaakt.

Dat wordt smullen.

Het valt me nog mee dat de private key nog niet gelekt is

[_JGC_]

Als ik dat artikel op webwereld zo lees snap ik niet hoe PWC dat niet heeft gezien tijdens hun audit. Misschien PWC ook maar eens voorzien van een Audit om te zoeken naar corruptie?

Als Vasco zijnde zou ik overigens ook een onderzoek instellen naar wat voor kat ik in de zak zou hebben gekocht. Ik neem aan dat je je eerst wel even inleest in een bedrijf voordat je de hele toko overneemt? Zouden die ook gewoon van misleidende informatie voorzien zijn?

[DDX]

Iemand enig idee waarom mozilla en microsoft dit keer zo lang wachten met een update ?
Toch niet omdat de nederlandse overheid dit weer heel lief gevraagd heeft mag ik hopen ?

[Gomez12]

Rukapul schreef op maandag 05 september 2011 @ 21:22:
[...]

Dat wordt smullen.

Het valt me nog mee dat de private key nog niet gelekt is

Even wachten nog, ik gok dat er nog wat meer lijken uit diverse kasten gaan komen.

Na 19 juli was er toch ook al een audit gedaan (alhoewel die enkel het google certificaat en nog 300 andere miste maar dat is toch niet zo erg).
Welk bedrijf heeft die audit dan gedaan? Want die heeft wmb ook wat uit te leggen.

[Volture]

aangepast

[ Voor 92% gewijzigd door Volture op 05-09-2011 22:07 ]

[Tourniquet]

Gomez12 schreef op maandag 05 september 2011 @ 21:44:
[...]

Even wachten nog, ik gok dat er nog wat meer lijken uit diverse kasten gaan komen.

Na 19 juli was er toch ook al een audit gedaan (alhoewel die enkel het google certificaat en nog 300 andere miste maar dat is toch niet zo erg).
Welk bedrijf heeft die audit dan gedaan? Want die heeft wmb ook wat uit te leggen.

Die eerste audit was door PWC gedaan.

[Gomez12]

Tourniquet schreef op maandag 05 september 2011 @ 21:52:
[...]
Die eerste audit was door PWC gedaan gefactureerd.

There, I fixed it for ya.

Ik kan namelijk niet echt zeggen dat ze veel gedaan hebben als ze 200+ aangemaakte certificaten niet zagen, die simpele basisdingetjes van Fox-IT niet zagen...
Ik neem echter gelijk aan dat ze gefactureerd hebben...

[DDX]

DDX schreef op maandag 05 september 2011 @ 21:38:
Iemand enig idee waarom mozilla en microsoft dit keer zo lang wachten met een update ?
Toch niet omdat de nederlandse overheid dit weer heel lief gevraagd heeft mag ik hopen ?

Volgens journaal is er dus idd afspraak gemaakt met microsoft....

[CyBeR]

Die laatste madam stelde wel een belangrijke vraag: waarom deed praktisch (zover ik kan beoordelen) de complete overheid zaken met DigiNotar en niet met een van de andere drie commerciele CSP's?

[matthijsln]

CyBeR schreef op maandag 05 september 2011 @ 22:12:
Die laatste madam stelde wel een belangrijke vraag: waarom deed praktisch (zover ik kan beoordelen) de complete overheid zaken met DigiNotar en niet met een van de andere drie commerciele CSP's?

Er zijn genoeg diensten die wel de andere CSP's gebruikten, daar hoor je alleen niks over. Daarnaast is Getronics 200 euro duurder een heeft KPN-stigma, heeft QuoVadis praktisch 0 informatie online staan (geen prijzen iig) en moet je bij ESG helemaal naar Weert met twee personen. Bij DigiNotar stond wel goede informatie en prijzen online en hoefde alleen de certificaatbeheerder zijn handtekening te laten legaliseren bij een notaris in de buurt voor een klein bedrag. Dat DigiNotar veel klanten heeft vind ik dus niet zo vreemd.

Als certificaataanvrager kan je verder geen praktische inschatting maken over de vertrouwelijkheid van het bedrijf als deze is gecertificeerd als CSP. Qua overheid is alleen de instantie die toezicht had moeten houden op PKIoverheid CSP's aan te spreken. De aanpak van de crisis zelf vind ik juist verbazingwekkend goed.

Goede business wel trouwens, in de persconferentie sprak Donner over ruim 50.000 certificaten. Als dat allemaal PKIoverheid certificaten zijn a 600 euro kan je toch voor 30 miljoen aan virusscanners e.d. aanschaffen.

[ Voor 3% gewijzigd door matthijsln op 05-09-2011 22:50 ]

[begintmeta]

Zou dit geen excuus kunen zijn om Iran aan te vallen eigenlijk? Aanval op NAVO-bondgenoot...

[matthijsln]

begintmeta schreef op maandag 05 september 2011 @ 22:53:
Zou dit geen excuus kunen zijn om Iran aan te vallen eigenlijk? Aanval op NAVO-bondgenoot...

Afshin Ellian kwam er ook mee in Nieuwsuur, maar die overdrijft qua IT nog wel eens in zijn columns vind ik. Daarnaast is er natuurlijk geen keihard bewijs dat de Iraanse overheid hier achter zit. Ook lijkt me niet dat een hack bij een private CSP voor een Root CA van de overheid onder een casus belli valt, alhoewel ik het NATO-verdrag niet heb gelezen...

[Puch-Maxi]

DDX schreef op maandag 05 september 2011 @ 22:04:
[...]
Volgens journaal is er dus idd afspraak gemaakt met microsoft....

Het lijkt er wel op ja, nieuws: Overheid dwingt bij Microsoft vertraagde Windows Update af

[Tourniquet]

Puch-Maxi schreef op maandag 05 september 2011 @ 23:17:
[...]
Het lijkt er wel op ja, nieuws: Overheid dwingt bij Microsoft vertraagde Windows Update af

Ah, het interim rapport van Fox-IT staat er ook bij.

[HarmoniousVibe]

Wat mij nog niet goed duidelijk is: stel dat het niet de Iraanse overheid was, hoe met het scenario er dan hebben uitgezien? Ik bedoel het enkel kunnen decrypten van data is niet genoeg; je moet die bytes ook nog fysiek in handen krijgen. Dit betekent dat er naast de hack ook nog voor gezorgd moet worden dat de client connecten met een andere host. Dit betekent dat de clients ook compromised hadden moeten zijn. Hier is echter geen enkele aanwijzing voor.

Of er moet zijn geknoeid met de infrastructuur (dus dat er iemand "op de lijn" zit af te luisteren), en de enige die dat kan is de eigenaar van de infrastructuur, i.e. de Iraanse overheid. Voor zover ik kan zien is dit dus veruit de meest logische verklaring.

[Marzman]

In die landen is de provider de overheid, dus dan is het niet zo'n probleem "op de lijn" af te luisteren.

[matthijsln]

HarmoniousVibe schreef op dinsdag 06 september 2011 @ 00:43:
Of er moet zijn geknoeid met de infrastructuur (dus dat er iemand "op de lijn" zit af te luisteren), en de enige die dat kan is de eigenaar van de infrastructuur, i.e. de Iraanse overheid. Voor zover ik kan zien is dit dus veruit de meest logische verklaring.

Uiteraard, maar zo'n redenatie alleen is geen bewijs

[begintmeta]

Er zijn wel uit schimmigere redenaties oorlogen voortgekomen...

Ik denk overigens niet dat't zo'n vaart zal lopen

De hele toestand is nogal problematisch voor een paar mensen daar in Iran vermoed ik. Hoe zou je dergelijke zaken kunnen voorkomen als eindgebruikers (behalve door 'je eigen CA te draaien')?

[ Voor 61% gewijzigd door begintmeta op 06-09-2011 01:09 ]

[Anoniem: 32925]

matthijsln schreef op dinsdag 06 september 2011 @ 01:00:
[...]


Uiteraard, maar zo'n redenatie alleen is geen bewijs

Maar wel redelijk wat antibewijs. Juist door de quote die je aanhaalt. Er moet ergens een organisatie zijn geweest die het verkeer van de Iraanse bevolking heeft kunnen omleiden. Zonder hacken kom je al snel uit op de overheid aldaar, danwel lieden die een aardige vinger in de lokale pap hebben.
Uiteraard is dit geen bewijs, maar het doet wel sterk vermoeden.

[leuk_he]

HarmoniousVibe schreef op dinsdag 06 september 2011 @ 00:43:
Of er moet zijn geknoeid met de infrastructuur (dus dat er iemand "op de lijn" zit af te luisteren), en de enige die dat kan is de eigenaar van de infrastructuur, i.e. de Iraanse overheid. Voor zover ik kan zien is dit dus veruit de meest logische verklaring.

Je hoeft alleen maar de dns te rerouten hoor. Zo high tech is dat niet. Sterker nog, er is een gat bekend (dat kamninsy dns gat) dat zonder dnssec niet 100% te dichten is. En ik kan zo nog een paar gaten noemen die je verkeer kunnen omleiden. Dan zou je dus het onderzoek moeten horen wat er bij de inraanse ISP is gebeurd. Nou, daar zul je niks van horen.

Het kan uiteraard de overheid zijn, maar het kunnen uiteraard ook wat slimme iraanse studenten zijn die de zelfde ideeen hebben als de Iraanse overheid.

[HarmoniousVibe]

leuk_he schreef op dinsdag 06 september 2011 @ 10:44:
[...]


Je hoeft alleen maar de dns te rerouten hoor. Zo high tech is dat niet. Sterker nog, er is een gat bekend (dat kamninsy dns gat) dat zonder dnssec niet 100% te dichten is. En ik kan zo nog een paar gaten noemen die je verkeer kunnen omleiden. Dan zou je dus het onderzoek moeten horen wat er bij de inraanse ISP is gebeurd. Nou, daar zul je niks van horen.

Het kan uiteraard de overheid zijn, maar het kunnen uiteraard ook wat slimme iraanse studenten zijn die de zelfde ideeen hebben als de Iraanse overheid.

Tuurlijk, ik heb nooit gezegd dat het ingewikkeld is, maar het is wel zo dat er praktische complicaties bijkomen. Naast het compromisen van DNS moet je ook nog de infrastructuur hebben om al die informatie binnen te hengelen en weer door te sturen naar de echte gmail, op te slaan en te analyseren. Dat moeten ze iig toch wel een dikke pijp, een goed storage-systeem en een stevige computer hebben om alles te kunnen 'handlen'. Bovendien zou Google in een dergelijke opstelling moeten merken dat er wel heel veel requests voor heel veel verschillende accounts naar hun servers komen, vanaf een zeer beperkt aantal IP-adressen.

Het is mogelijk, maar in mijn ogen niet de meest waarschijnlijke uitleg. Ik heb overigens ook nooit gezegd dat mijn redenering met aan zekerheid grenzende waarschijnlijkheid aantoont dat de overheid erachter zit, maar door doordat de alternatieve verklaringen minder waarschijnlijk zijn geworden is het in mijn ogen wel zo dat de verklaring dat de overheid erachter zit waarschijnlijker is geworden.

[ Voor 18% gewijzigd door HarmoniousVibe op 06-09-2011 13:16 ]

[DDX]

Ziet er naar uit dat firefox 6.0.2 ook uitgesteld wordt op verzoek nl overheid ?
Kan er alleen niets over vinden, behalve dat op ftp de 6.0.2 versie al staat, maar de update check nog netjes meld dat 6.0.1 up2date is.

[Anoniem: 32925]

DDX schreef op dinsdag 06 september 2011 @ 19:05:
Ziet er naar uit dat firefox 6.0.2 ook uitgesteld wordt op verzoek nl overheid ?
Kan er alleen niets over vinden, behalve dat op ftp de 6.0.2 versie al staat, maar de update check nog netjes meld dat 6.0.1 up2date is.

Nope, de mijne ging zichzelf net updaten

[DDX]

Hehe idd komt net uit

[DDX]

En microsoft :

http://www.microsoft.com/...ity/advisory/2607712.mspx

Why was this advisory revised September 6, 2011?
Microsoft revised this advisory to announce the release of an update that addresses this issue. The update adds five DigiNotar root certificates to the Microsoft Untrusted Certificate Store. Typically no action is required of customers to install this update, because the majority of customers have automatic updating enabled and this update will be downloaded and installed automatically. For customers who do not have automatic updating enabled, see Microsoft Knowledge Base Article 2607712 for information on how to manually apply the update.

en dan :

Microsoft Security Advisory: Fraudulent digital certificates could allow spoofing

At the explicit request of the Dutch government, the release of this update on Windows Update will be delayed for the Netherlands.

This update will become available to the Netherlands on Windows Update and on all Automatic Update channels at a later date. Customers who want to manually install this update should click the appropriate platform download in the "Download information" section. On the next page, users will be able to select the language to install and can continue with the download and the installation.

De wsus server bij ons op de zaak had deze update trouwens gewoon gedownload en gewoon automatisch gestuurd naar de clients. (dus niets uitgesteld omdat deze server in nederland staat)

En net ook 2 standalone systemen windowsupdate gekeken, bij beide systemen gewoon als critical update die automatisch geselecteerd staat.

[ Voor 45% gewijzigd door DDX op 06-09-2011 22:14 ]

[matthijsln]

Wel frappant vind ik dat het hele SSL unsafe renegotiation verhaal (waardoor ook MITM attacks mogelijk zijn) aan een bepaalde overheidsinstelling waar ik berichten mee uitwissel voorbij is gegaan zonder zo'n hype als dit. Om berichten te kunnen ontvangen met een PKIoverheid beveiligde verbinding moet ik dus in Apache expliciet insecure renegotiation aanzetten. Ik zal zo nog eens controleren of dit nog steeds nodig is of dat ze ondertussen al RFC 5746 ondersteunen.

[CyBeR]

Ik zie even niet waarom dat nodig zou zijn?

[wlchris]

GlobalSign lijkt ook de l*l.

http://pastebin.com/GkKUhu35

[NLsandman]

Ik heb nu net een update gehad van firefox 6.01 naar 6.02, ik had begrepen dat de diginotar certificaten verwijdert zouden worden, waarom staat diginotar nog steeds in mijn certificaten beheerder van firefox?

[Anoniem: 422313]

begintmeta schreef op maandag 05 september 2011 @ 22:53:
Zou dit geen excuus kunen zijn om Iran aan te vallen eigenlijk? Aanval op NAVO-bondgenoot...

En wij hebben recht van spreken? Doelend op Stuxnet die ongeveer 1/5 deel van de computers die gebruikt werden voor het kernprogramma van Iran lam legde.

En het is nog niet eens zeker dat de overheid erachter zit, een kerel beweert tegen Nieuwsuur dat hij erachter zit, maar de informatie doorgespeeld heeft naar de Iraanse overheid en dat die er wel gebruik gemaakt van hebben. Maar goed dat zou ik ook doen als overheid zijnde.

[Batiatus]

Even een snelle vraag. Hoe is die ene burger in Iran er achter gekomen dat het Certificaat vals was? Kwam dat omdat het nogal raar was dat er een Nederlandse CA het certificaat voor o.a. Gmail uitgaf?

[CyBeR]

Batiatus schreef op maandag 12 september 2011 @ 14:24:
Even een snelle vraag. Hoe is die ene burger in Iran er achter gekomen dat het Certificaat vals was? Kwam dat omdat het nogal raar was dat er een Nederlandse CA het certificaat voor o.a. Gmail uitgaf?

Chrome trapte er niet in.

[Gomez12]

Batiatus schreef op maandag 12 september 2011 @ 14:24:
Even een snelle vraag. Hoe is die ene burger in Iran er achter gekomen dat het Certificaat vals was? Kwam dat omdat het nogal raar was dat er een Nederlandse CA het certificaat voor o.a. Gmail uitgaf?

Sowieso is Iran al een apart land (inet-technisch gezien) vanwege the great firewall en de controle die ze fysiek over hun burgers willen hebben.

Ik kan me dan ook best voorstellen dat een IT'er bij bijv een ambassade ietwat achterdochtiger is en bijv handmatig certificaten vergelijkt, bij verandering even navragen bij een collega in NL en het balletje gaat rollen.

Als je erop let dan is het natuurlijk apart als er in 1 land een certificaatverandering is die over de rest van de wereld niet geldt...

[Freee!!]

Gomez12 schreef op maandag 12 september 2011 @ 14:43:
[...]

Sowieso is Iran al een apart land (inet-technisch gezien) vanwege the great firewall en de controle die ze fysiek over hun burgers willen hebben.

Ik kan me dan ook best voorstellen dat een IT'er bij bijv een ambassade ietwat achterdochtiger is en bijv handmatig certificaten vergelijkt, bij verandering even navragen bij een collega in NL en het balletje gaat rollen.

Als je erop let dan is het natuurlijk apart als er in 1 land een certificaatverandering is die over de rest van de wereld niet geldt...

Nog veel eenvoudiger, die gebruiker gebruikte Chrome en Chrome controleert de certificaten voor Google ook bij Google zelf. Toen was het vrij snel duidelijk.

[begintmeta]

offtopic:
Wel grappig trouwens dat het onderdeel van de AIVD dat over de veiligheid van verbindingen gaat (het Nationaal Bureau voor Verbindingsbeveiliging) haar ssl-website alsnog problematische DigiNotar-certificaten laat gebruiken.

[susscorfa]

Ik was zojuist bezig met het doen van belasting aangifte, het lijkt er op dat je het aangifte programma download over een onbeveiligde verbinding ( http://belastingdienst.nl/download/2749.html http://download.belasting...linux/ib2010_linux.tar.gz ). Ook zie ik nergens hashes vermeld staan die ik zou kunnen gebruiken om de echtheid van het programma te controleren. Ik vroeg me af of dit je niet in de zelfde manier zwak maakt voor een man in de middle attack zoals de false certificaten. Als ik het goed heb kun je nu niet controleren gemanupuleerd aangifte programma heb ontvangen. Dit zou denk ik oa je belasting aangifte naar naar ook een andere server kunnen sturen.

[Thralas]

susscorfa schreef op donderdag 15 september 2011 @ 17:52:
Ik was zojuist bezig met het doen van belasting aangifte, het lijkt er op dat je het aangifte programma download over een onbeveiligde verbinding ( http://belastingdienst.nl/download/2749.html http://download.belasting...linux/ib2010_linux.tar.gz ).

Beveiliging van de verbinding is niet vereist (de confidentiality-component, in ieder geval), je kunt de authenticiteit van de installer ook controleren dmv. een signature (zie volgende opmerking). Daarnaast zou de hele site van SSL gebruik moeten maken - en de gebruiker zou moeten controleren of 1. SSL gebruikt wordt 2. het certificaat legitiem is.

Ook zie ik nergens hashes vermeld staan die ik zou kunnen gebruiken om de echtheid van het programma te controleren.

Hashes bieden geen authenticiteit, alleen integriteit. Je bedoelt een (PGP-)signature. In het geval van de Windowsexecutable neem ik aan dat de (installer)executable wel is ondertekend - controle van het certificaat zou enige uitkomst bieden (behalve als iemand een code signing certificate op naam van de Belastingdienst in handen krijgt..).

Dit zou denk ik oa je belasting aangifte naar naar ook een andere server kunnen sturen.

Correct.

[Freee!!]

Lijkt alles bij elkaar een uitstekende reden om de belastingdienst eens te bellen en navraag te doen

[susscorfa]

Hmm the windows executable kan ik niet controleren (linux only user).

Ik zit net ff verder naar de linux downloads te kijken. De ene is een tar en heeft volgens mij echt nix om de authenticiteit vast te stellen. De ander download lijkt van iets dat autopackage heet af te hangen, wat iig volgens de website niet meer maintained word sind 5 nov 2010 ( http://www.autopackage.org/ ). Zo ver ik zo snel zie is daar ook nix om de authenticiteit vast te stellen. De autopackage download heeft wel een md5 hash er in staan maar zoals door Thralas uit gelegd helpt dat niet veel zeker niet als het in het package vermeld staat.

[YouKnow]

En het onvermijdelijke is nu gebeurd: Diginotar is failliet verklaard.

http://nos.nl/artikel/274...r-failliet-verklaard.html

[@r!k]

YouKnow schreef op dinsdag 20 september 2011 @ 12:42:
En het onvermijdelijke is nu gebeurd: Diginotar is failliet verklaard.

http://nos.nl/artikel/274...r-failliet-verklaard.html

Dat is nog behoorlijk snel gegaan zeg. Helemaal geen berichten over surseance ofzo maar meteen faillissement.

Wel het evrstandigst denk ik, als dit bedrijf onder een andere naam zou zijn doorgegaan dan nog zouden de grote bedrijven ze waarschijnlijk niet meer vertrouwen.

[Rukapul]

De echte vraag is natuurlijk hoeveel bedrijfsmiddelen het moederbedrijf (Vasco) nog uit de toko heeft getrokken de afgelopen maanden.

Voor dit soort vertrouwensdiensten is het eigenlijk vreemd dat organisatievormen met beperkte aansprakelijkheid (BV/NV) zijn toegestaan in plaats van hoofdelijke aansprakelijkheid of eventueel het aanhouden van een wettelijke verplichte (grote) buffer/borg.

[KatirZan]

Dat is gewoon een manier geweest om een falende neven sector te laten vallen. Diginotar is failliet verklaard, maar de onderneming zelf zal gewoon een doorstart maken in Nederland, onder een andere naam, in een andere BV.

Besloten vennootschappen en naamloze vennootschappen zijn onderandere om wettelijke rechtspersonen niet hoofdelijk aansprakelijk te maken. Echter staat er wel in de wet aangegeven dat bij opzettelijk schuld de DGA, o.a Vasco, aansprakelijk gesteld kan worden en eventuele schulden op neven verhaald kunnen worden. Dat zal hier denk ik echter niet van pas zijn, daar een enkele certificaat slechts 250 euro per jaar moet kosten en er genoeg aanbieders zijn die een dergelijke bezigheid onderhouden.

[leuk_he]

Rukapul schreef op dinsdag 20 september 2011 @ 12:55:
De echte vraag is natuurlijk hoeveel bedrijfsmiddelen het moederbedrijf (Vasco) nog uit de toko heeft getrokken de afgelopen maanden.

Voor dit soort vertrouwensdiensten is het eigenlijk vreemd dat organisatievormen met beperkte aansprakelijkheid (BV/NV) zijn toegestaan in plaats van hoofdelijke aansprakelijkheid of eventueel het aanhouden van een wettelijke verplichte (grote) buffer/borg.

Webwereld heeft een heel verhaal over de financiële handel en wandel staan:

http://webwereld.nl/achte...ergang-van-diginotar.html

Buffer/borg? Het enige wat een certificaten buro doet is certificaten uitdelen. Verder heeft het helemaal geen verantwoordelijkheden. Een certificaat verteld ook helemaal niet zoveel, het is 1 ding in een hele keten van veiligheden. Een certificaat heeft volgens de leveringsvoorwaarden van een certificaat ook geen verantwoordelijkheid voor andere dingen dan de beveiligde http. Ik heb net eens bij comodo gekeken, die hebben een soort verzekering. Maar als je goed gaat kijken sluit die hackers uit. lekker dan.

[Rukapul]

^ en daarmee is dus geillustreerd wat een farce het systeem is

De belangen van stakeholders zijn volstrekt asymmetrisch.