Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 44 reacties

Een Egyptisch bedrijf, MCS Holdings, gaf ssl-certificaten voor meerdere Google-domeinen uit. Dat stelt Google. De certificaten waren bedoeld om het versleutelde internetverkeer van medewerkers te kunnen uitlezen, maar zijn ook te misbruiken.

googleHet Egyptische MCS gebruikte het certificaat in zijn commerciële software waarmee bedrijven het internetverkeer van hun medewerkers kunnen aftappen. Daartoe gebruikte het bedrijf echter een certificaat dat ook buiten de omgeving van MCS te misbruiken is, waardoor kwaadwillenden de certificaten zouden kunnen misbruiken om een vals ssl-certificaat te serveren en zo verkeer uit te lezen. Het certificaat is namelijk ondertekend door Cnnic, een certificaatautoriteit die onder de Chinese overheid valt. Die autoriteit wordt vertrouwd door alle grote besturingssystemen en browsers. MCS leverde de privésleutel van het certificaat mee met zijn softwarepakket, waardoor een aanvaller die relatief eenvoudig zou kunnen buitmaken.

Volgens Google gaf MCS onder meer valse certificaten voor Google-domeinen uit. Inmiddels heeft Google die certificaten geblokkeerd, maar volgens het bedrijf is niet uit te sluiten dat ook voor andere domeinen valse certificaten zijn uitgegeven. Overigens waren Chrome-gebruikers voor Google-domeinen niet kwetsbaar: Google heeft voorkomen dat zomaar elk certificaat voor Google-domeinen kan worden gebruikt.

Het gebeurt vaker dat valse ssl-certificaten worden uitgegeven. Vorige week nog meldde Tweakers dat een Xs4all-abonnee met een simpele e-mailtruc een certificaat voor Xs4all.nl in handen wist te krijgen. Met hetzelfde trucje kreeg een gebruiker eerder een certificaat voor Live.fi, het Finse Windows Live-domein, in handen.

Moderatie-faq Wijzig weergave

Reacties (44)

Op google vullen mensen hun zoekopdracht, hun intentie.
Dus hetgene dat zij willen aan informatie/koopkansen/ideeën of dromen.

Dus het is ook al mag het niet, heel voor de hand liggend om als werkgever te richten op wat mensen invullen op Google. Het is vals dat deze werkgever dat doet met valse ssl certificaten, want die zijn voor de gemiddelde werknemer moeilijk van origineel te onderscheiden.

Of de werkgever het nou wel of niet opslaat, echte privacy heb je sowieso niet, omdat Google ook als je een zuiver ssl certificaat hebt jouw informatie wel zelf opslaat. Zo zegt een ssl certificaat dus niets over welke informatie er over je verzameld wordt. Maar geeft alleen aan, dat je op de juiste site zit.

[Reactie gewijzigd door nul07 op 24 maart 2015 13:22]

Het gaat hier natuurlijk niet alleen om privacy-schending, maar om het mogelijk maken van een man-in-the-middle-attack waardoor een aanvaller van buitenaf jouw verbinding met google kan onderscheppen en zo alles wat over die verbinding gaat binnenhengelen, waaronder account-gegevens end credit-cardgegevens waarmee identiteitsfraude mogelijk wordt.

Hoe zulke werkgever-meekijk-software zou moeten werken is dat de valse google-certificaten ondertekend worden door een CA die niet globaal vertrouwd wordt (self-signed door de werkgever bijvoorbeeld) en dat dit CA-certificaat expliciet vertrouwd wordt door de computers van de werknemers, waardoor de enige persoon die de mitm-aanval kan uitvoeren de werkgever is, en dan alleen op de pcs van het bedrijf.

Nu is het blijkbaar zou dat een globaal vertrouwde CA valse certificaten heeft afgegeven. Dit ondermijnt volledige de vertrouwensbasis van het hele certificatensysteem en ik hoop dat dit tot gevolg heeft dat deze CA zo snel mogelijk niet meer vertrouwd wordt door de browsers.
Je kan stellen dat het grootste gevaar zit in dat derden een MITM kunnen uitvoeren, maar het grootste probleem zit hem natuurlijk in de opzet van dit certificaat.
De certificaten waren bedoeld om het versleutelde internetverkeer van medewerkers te kunnen uitlezen.
Het spul was bedoeld, en werd gebruikt door werkgevers om als MITM hun eigen werknemers te bespioneren.

Om zo dezelfde informatie over medewerkers te verzamelen die google van de mensen verzameld. Zoals je aangeeft is de partij die die gegevens kan verzamelen, alleen maar de werkgever als hij de enige is die toegang heeft tot z'n eigen infrastructuur.

Schijnbaar is wat we wel of niet op google invoeren interessant genoeg voor werkgevers om een certificaat voor te vervalsen.
Hoe zulke werkgever-meekijk-software zou moeten werken is dat de valse google-certificaten ondertekend worden door een CA die niet globaal vertrouwd wordt (self-signed door de werkgever bijvoorbeeld) en dat dit CA-certificaat expliciet vertrouwd wordt door de computers van de werknemers, waardoor de enige persoon die de mitm-aanval kan uitvoeren de werkgever is, en dan alleen op de pcs van het bedrijf

Geheel eens!

Maar het probleem is natuurlijk 'bring your own device' waar dat self-signed corporate certificaat niet op staat 8-) En dan is de verleiding heel groot om maar een andere methode te gebruiken.

Overigens natuurlijk schandalig dat een CA zo'n certifciaat uitgeeft aan een provider. Aan de andere kant is dat niet zo'n precedent, want Google zélf heeft ook dat soort certifciaten van CA's gekregen. Dus het is ook wel een beetje 'not all pigs are equal' O-)
Maar zo makkelijk is het nu ook weer niet om nu een man-in-the-middle attack uit te voeren. Bedoel je zult dan toch echt nog valse websites moeten optuigen, en zorgen dat het verkeer naar Google.com daarop uitkomt etc.
nee hoor, een proxy of een kleine aanpassing in de route tabellen is genoeg om het verkeer te kunnen onderscheppen. Vervolgens kan je het verkeer decrypten middels deze certificaten.
Dan zet je dat toch uit? :)
Geen garantie dat ze het dan niet alsnog opslaan..
Ook dat kan:
https://history.google.com/history/optout?hl=en
Maar het venijn zit hem dan in de kleine lettertjes die je noemt.
Geen garantie dat ze het dan niet alsnog opslaan..
Er is een verschil tussen opslaan en tussen "misbruiken" zoals advertenties tonen of data-mining.

Microsoft doet dit expliciet niet zolang je Europees burger bent; dit is bekrachtigd/bevestigd door de EU en geldt hierdoor als enige "betrouwbare" partner voor online diensten zoals Office 365 & Azure voor alle bedrijven (inclusief de Nederlandsche Bank).
in het leven heb je sowieso geen echte privacy, mooi voorbeeld was gisteren op het nieuws: ‘Kijkers van Boer zoekt vrouw hielden plas op’
http://beverwijk.nieuws.n...kt-vrouw-hielden-plas-op/
nou google gaat tuurlijk verder maar je krijgt beter resultaten daardoor en tuurlijk om reclame te serveren want al die servers lopen niet op lucht.
Dat noemt men statistiek en heeft niets te maken met de privacy van een individu.
Waarom zou je als werkgever enige SSL verkeer binnen je eigen infrastructuur willen?

Ook vraag ik me af voor hoeveel functies open Internet of Google gebruik echt noodzakelijk is.

Ik vind het zelf zeer storend dat personeel Facebook en whatsapp gebruiken tijdens kantoor uren terwijl het niet mag... maar nog asocialer terwijl ze in gesprek met je zijn.

Gaat nog wel een generatie duren voordat dit soort omgangsvormen onderdeel worden van eenieder opvoeding.
Het is vast niet het enige bedrijf dat haar eigen personeel bespioneerd.
Wat erger is, is dat hoe meer ik deze verhalen lees hoe onbetrouwbaarder certificaten zijn.

Volgens mij kun je ze helemaal niet vertrouwen en wordt het tijd voor een ander systeem.
c.q keihard optreden tegen dit soort bedrijven waarbij je alle certificaten die ze uitgegeven hebben ongeldig verklaard.

een andere mogelijkheid is juist een lijst met geldige certificaten dus geen blacklist maar omgekeerd.
Daarbij moet er worden uitgegaan bij registratie van het mailadres dat bij het domein hoort.
Je moet dan zelf je certificaat op een whitelist laten zetten en dat via bijv een code die naar het mailadres wordt gestuurd bij het domein.
Op deze manier zal het uitgeven van certificaten als stukken betrouwbaarder kunnen worden.
Wat erger is, is dat hoe meer ik deze verhalen lees hoe onbetrouwbaarder certificaten zijn.

Er zijn enkele tientalloze miljoenen certifciaten in omloop voor enkel SSL/TLS en het feit dat het groot nieuws is elke keer als er een hack is, geeft aan dat het reuze meevalt. Facebook heeft ooit een onderzoek gedaan naar het aantal MitM aanvallen op hun site en kwam tot de coclusie dat dat vrijwel nietbetsaand was en de meeste anti-malware systemen waren.

Merk namelijk op dat het hier gaat om een intranet en geen internet.

alle certificaten die ze uitgegeven hebben ongeldig verklaard.

Het ging hier om een Egytische provider die een certifciaat misbruikte van een Chinese CA. Goed die Chinezen hadden nooit zo'n generiek certifciaat moeten geven, maar als je dit intrekt kan half China op Android niet meer internetten. Android kan namelijk haar certifciaatstore bijvoorbeeld niet aanpassen.

Wat veel meer moet gebeuren is een methode om snel certifciaten in te kunnen trekken. Microsoft is de enige die dit fatsoenlijk vooe elkaar heeft met en online revocation checks en een systeem waarin ze dynamisch binnen een paar uur alle PC en telefoons kunnen updaten én vervangen door een nieuwe.

Firefox moet in zo' geval een geheel nieuwe browser update uitgeven, en Chrome is afhankelijk van Microsoft of Apple want kan dat zelf in het geheel niet. Dat is veel urgenter dan een radicale aanpassin. Immers overal waar mensen werken zullen dit soort incidenten plaatsvinden. Het probleem is eerder dat er te weinig incidenten zijn waardoor men systemen uitbegracht heeft (Android) waar men de certiciaat store niet kan updaten. MacOS en Windows hebben dat probleem niet.

Daarnaast zou een uitrol van EV-certificaten (die moeilijker vervalst kunnen worden) en OCSP Must Staple (veplichte online check op geldigheid) dit ook oplossen. En zowel Microsoft EMET, Chrome en Firefix hebben certifciaat pinning die dit ook tegengaan. Dus er zijn niet echt radicale veranderingen nodig.

Da wil niet zeggen dat er geen wijzigingen nodig zijn, maar we kunnen daar beter rustog over nadenken ipv met de botte bijl aan de gang. Gelukkig is die discussie in de industrie dan ook aan de gang waar men aan decentrale 'moderator' servers denkt die permanent controleren op de achtergrond.
Leuk dat je schrijft een tiental miljoen certificaten en natuurlijk kun je redeneren dat het aantal valse certificaten maar een fractie is. Toch blijft het kwalijk zeker als het dus mogelijk is om van google een certificaat te krijgen. Dit kan een grote impact hebben evenals bijv bij xs4all of andere mailprovider.

Android kan haar certificaatstore niet aanpassen. Tja ook weer een voorbeeld dus gewoon maar verder gaan omdat android het niet kan wijzigen. Dit lijkt me dan een grof gebrek in de android certificaatstore.

Neem niet weg dat er het ene na het andere incident is. Let wel wat we nu te weten komen. Dit kan ook gewoon het topje van de ijsberg zijn, waarbij er veel meer valse certificaten in omloop zijn dan we nu weten. Veiligheidsdiensten kunnen zo bij leuk mailverkeer onderscheppen, als dat wenselijk is geen probleem. Ik acht het niet wenselijk.
Android kan haar certificaatstore niet aanpassen. Tja ook weer een voorbeeld dus gewoon maar verder gaan omdat android het niet kan wijzigen. Dit lijkt me dan een grof gebrek in de android certificaatstore.

Ikw as inderdaad niet duidelijk, maar dat was dan ook mijn punt. In principe is het niet te voorkomen dat er af en toe valse certificaten zijn. Er blijven immers mensen bij betrokken.

Maar zolang het gaat om uitzonderingen is het probleem meer dat sommige OS'en - zoals Android - geen mogelijkheid hebben om certificaten in te trekken. Andere platforms, zoals Firefox kunnen het wel maar moeten een software update doen. Dat is juist het zwakke punt.

De enige die zijn zaakjes uitstekend voor elkaar heeft op dit gebied is Mircosoft. Die kunnen het via een zogenaamde CAPI update buiten de gewone Windows Update om aanpassen. Plus dat hun TLS bibliotheek de enige is die volledige runtime revocatie checks doet. Als andere platformen dit ook zouden doen, zou een vals certifciaat hier en daar niet zo'n meer gevaar zijn.
Conclusie android heeft een veiligheidsprobleem.
keihard optreden tegen dit soort bedrijven waarbij je alle certificaten die ze uitgegeven hebben ongeldig verklaart.
Weet je wat er dan allemaal omvalt? Nog niet zo heel lang geleden vroeg onze overheid aan Microsoft om niet gelijk het rootcertificaat van Diginotar te verwijderen: nieuws: Overheid dwingt vertraagde Windows Update af bij Microsoft
Jou conclusie pappen en nathouden dus en weer wachten op een volgend probleem.

Zoals ik schreef het mag duidelijk zijn dat uitgifte van ssl certificaten erg lek begint te worden. Dan kun je wachten tot je met de kraan open moet gaan dweilen of gewoon keihard ingrijpen.
Malifide uitgevers van certificaten meteen straffen. 1e overtreding bijv 3 maanden lang geen certificaten meer mogen uitgeven.
Nog een keer 6 maanden lang.
Nog een keer alles intrekken.

Als je bankverkeer of weet ik wat via ssl loopt moet je daarop kunnen vertrouwen en dan kun je nu dus steeds minder.
Jou conclusie pappen en nathouden dus en weer wachten op een volgend probleem.
Nee hoor, er is alleen een verschil tussen iets direct uitschakelen of gecontroleerd uitschakelen. Is toen in Chernobyl ook fout gegaan, dat overkomt de besten.
Klinkt leuk gecontroleerd uitschakelen alleen de vergelijking met een kerncentrale is toch heel iets anders.

Feit blijft dat dit soort incidenten structureel begint te worden en je dus niet meer over gecontroleerd kan spreken.
Er moet dus echt iets gebeuren in die rotte lekke systeem.
Wat is nou belangrijker; dat er dingen niet omvallen en dat "we" zolang mogelijk voor 1 of 2 bedrijven allerlei vervalste informatie in stand houden? Of dat "de hele wereld" zo veilig mogelijk communiceert en dat dus die 1 of 2 bedrijven maar pech moeten hebben?

Even afgezien van dat het in jouw voorbeeld over overheid gaat; als ik mijn PC thuis niet op orde heb en ik dien een klacht in bij mijn bank over phishing, moet ik gaan bewijzen dat ik wel veilig ben bezig geweest. Dan kan ik toch ook niet zeggen "ja, maar ik moest 2 vervalste certificaten blijven gebruiken voor dit of dat"?
Wat mijn bank doet als een vals ssl certificaat hun website authenticiteit vast steld, is dat ze de inlog-knop van internet bankieren niet weergeven.

Als Google dat ook bij dubieuze certificaten zal doen voor haar [zoek] knop, zouden ze hun gebruikers beter kunnen bschermen tegen misbruik door derden.

Zo'n maatregel beschermt de google-gebruiker niet tegen verzameling van persoonsgegevens door google, ten gunste van profiling die gebruikt wordt om te monitiseren samen met derden.
Het laat weer mooi het zwakke punt van het CA-systeem zien. Iedere CA kan voor ieder domein in de wereld certificaten uitgeven. Daar moeten we vanaf.
Die kleine nuance is inderdaad achterwege gelaten.
Het is een gecertificeerd bedrijf dat valse certificaten uitgeeft.
De controle op dergelijke bedrijven is verre van sluitend. Daar mag ook toelichting op worden gegeven. Als het een systeem is dat op vertrouwen werkt en achteraf pas intrekt, dan is dat achter het net vissen.
Die controle krijg je ook niet sluitend. Zo'n beetje ieder land heeft wel z'n eigen gecertificeerde CA. Ik ga er van uit dat er ook een paar geheime diensten zijn die een eigen, volledig gecertificeerd, CA hebben of anders wel invloed hebben op een CA. Daarmee heeft zo'n CA ook strategische en politieke waarde. Volledige controle daar op is vrijwel onmogelijk.

Misschien dat we iets bitcoinachtigs kunnen bedenken zoals namecoin dat voor DNS doet. Dan kun je decentraal controleren welke certificaten worden uitgegeven, door wie en voor wie.
Er bestaat al zo iets dat Certificate Transparency heet maar dat is vrijwillig. Een onwillige of kwaadaardige CA kan informatie achterhouden.
Certificate transparency helpt tegen het feit dat de meeste CA's eerder incompetent zijn dan kwaadaardig ... dus het helpt wel iets.

Tegen de intermediary CA's die door "toevallige" incompetentie certificaten uitgeven helpt het natuurlijk niet ... die worden dan gewoon toevallig ook zo incompetent dat ze het transparancy systeem verkeerd implementeren.
Nou ja, daar heb je dus DANE voor.
Maar hebben browsers ondertussen al ondersteuning voor DANE?
Laatst wat ik las zit de code al in Chrome maar werd deze nog niet gebruikt & heeft firefox enkel ondersteuning via een plugin
Gelukkig begint DNSSEC op stoom te komen want dat is een voorvereiste voor DANE. Het nadeel is wel dat je toegang moet hebben tot DNS en dat is bij veel kleine beheerders niet vanzelfsprekend.
Plus dat DNSSEC het gevaar op DDOS misbruik via DNS groter maakt als je niet oppast. Immers de pakketjes zijn groterdan gewone DNS.

En het feit dat DNSSEC enkel nog 1024 bit RSA certificaten gebruikt wat qua sterkte natuurlijk ook niet helemaal 2015-conform is, is ook niet echt geweldig.

Gelukkig hebben we inmiddels eliptical curve DSA certificaten, maar dat wordt helaas nog niet door iedereen ondersteund bij DNSSEC.

Ofwel, ik verwacht persoonlijk niet teveel van DNSSEC.
Plus dat DNSSEC het gevaar op DDOS misbruik via DNS groter maakt als je niet oppast. Immers de pakketjes zijn groterdan gewone DNS.
Geen DNSSEC gebruiken neemt het risico op misbruik helaas niet weg. DNSSEC kan het erger maken maar er is sowieso een oplossing voor dat probleem nodig. Moderne DNS-servers hebben tegenwoordig ratelimiting ingebouwd. Dat is helaas nog geen totale oplossing maar het helpt wel.
En het feit dat DNSSEC enkel nog 1024 bit RSA certificaten gebruikt wat qua sterkte natuurlijk ook niet helemaal 2015-conform is, is ook niet echt geweldig.

Gelukkig hebben we inmiddels eliptical curve DSA certificaten, maar dat wordt helaas nog niet door iedereen ondersteund bij DNSSEC.
Dat is gedeeltelijk waar maar niet het hele verhaal. Het is wel populair om 1024bit sleutels voor signatures te gebruiken maar die zijn maar kort geldig, bv 3 uur. Aangezien DNSSEC niet voor geheimhouding is maar slechts tegen manipulatie beschermd is dat een redelijk compris voor de meeste situaties. Als je iets anders wil kan dat gewoon, je kan langere keys gebruiken en/of ze sneller vervangen.
Ofwel, ik verwacht persoonlijk niet teveel van DNSSEC.
Er zal iets moeten gebeuren. DNS is tegenwoordig behoorlijk kritische infrastructuur geworden. DNSSEC is niet fijn want het voegt een hoop complexiteit toe maar tot iemand met iets beters komt is het onze beste optie.

Ik ben wel bang dat het nog lang gaat duren. HTTPS is al 20 jaar oud en er zijn nog steeds hordes sites die denken dat ze zonder kunnen of die het slecht hebben geimplementeerd. Gelukkig staan een aantal grote internetbedrijven er achter. Google heeft het aan staan op de 8.8.8.8 resolver, Comcast doet het voor haar tientallen miljoenen klanten, alle nieuwe TLDs ondersteunen het en ruim 40% van de .NL domeinen is ondertekend. Nu de Nederlandse ISPs nog.
Ik kan geen plugin vinden voor Firefox. Welke bedoel je?
Dank je! Die komt niet tevoorschijn als je op "dnssec" zoekt bij de Firefox addons.
Ik heb die plugin nu een week geinstalleerd, en ik heb nog geeneen site gezien waarvoor ie valideert. Ik zie alleen maar sites met een rood stoptekentje. Het lijkt me dat deze plugin niet meer zo goed werkt.
Niet echt, kan evengoed zeggen dat die domeinen geen DNSSEC ingesteld hebben. Kan je anders een domein checken dat zeker een DNSSEC heeft?
Wordt de uitgevende intermediate CA ook meteen toegevoegd aan certificate revocation lists? Immers is door dit gedrag bewezen dat ze niet te vertrouwen zijn.
Wordt de uitgevende intermediate CA ook meteen toegevoegd aan certificate revocation lists?
Het certificaat dat MCS gebruikte *is* een intermediate CA, waardoor ze ook voor alle sites "echte" certificaten konden genereren in hun proxysoftware. CNNIC zegt dat intermediate CA cert te hebben gegeven onder strenge voorwaarden.
strenge voorwaarden? Ze hebben dat helemaal NIET af te leveren aan een derde partij !!!

Dit zou ik als provider een goeie reden vinden om hen inderdaad op de revocation list te gooien, de klanten zullen snel genoeg een andere CA vinden en CNNIC kan de deuren sluiten (behalve dan misschien voor bedrijven die enkel in China werkzaam zijn)
strenge voorwaarden? Ze hebben dat helemaal NIET af te leveren aan een derde partij !!!
Dan zouden er helemaal geen intermediate CA's bestaan... Het hele model van trust chains met CA's werkt op vertrouwen en afspraken. Nu dat blijkbaar MCS de voorwaarden grondig heeft geschonden, hebben ze het vertrouwen flink geschaad. Ook CNNIC's vertrouwens is beschadigd, doordat het proces van controle onder hun verantwoordelijkheid viel door het uigeven van die intermediate aan MCS.

Verder ben ik voorstander van het strikt gebruik van nameConstraints bij het uitgeven van intermediate CA's aan partijen die niet daadwerkelijk een CA zijn. Dan beperk je feitelijk de domeinen (wildcards mostly) waarop certificaten geldig zijn uitgegeven ermee. Dus een intermediate certificaat met nameConstraint op *.mcs.com valideert alleen voor certificaten met *.mcs.com in de subjectAltName. :)
Google heeft (na het DigiNotar-incident) ook een eigen intermediate CA afgenomen bij GeoTrust: https://pki.google.com/. Zoals daar te lezen is mag zoiets van het overkoepelende CA/Browser-forum mits er aan bepaalde regels voldaan wordt.
Net zoals Turktrust en ANSSI zeker? Intermediate CAs zijn gewoon een mechanisme geworden voor plausible deniability ... iedereen in de industrie weet het, niemand doet er wat aan.

[Reactie gewijzigd door Pinkys Brain op 24 maart 2015 17:10]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True