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

'Drieduizend Nederlandse sites gebruiken nog steeds Symantec-certificaten'

Drieduizend Nederlandse websites gebruiken nog steeds Symantec-certificaten, ondanks de aankondiging dat Google met versie 70 van Chrome deze certificaten blokkeert, waardoor bezoekers een waarschuwing krijgen. Dat claimt de Open State Foundation na onderzoek.

De organisatie deelde zijn resultaten met de NOS. Onder de eigenaren van de websites bevinden zich grote bedrijven, zoals Ekoplaza en supermarkt Emté. In de publieke sector gaat het om 189 sites, waaronder die van de gemeentes Zutphen en Heemskerk. Andere voorbeelden zijn Buma Stemra en de klantenservicepagina van NS International. Volgens de NOS zijn ook twee pagina's van persbureau ANP getroffen, die veel door journalisten worden gebruikt. Een woordvoerder zei niet van de ontwikkeling op de hoogte te zijn, maar stelde dat de certificaten maandagavond nog vervangen zouden worden.

Het is al langer bekend dat onder meer Google het vertrouwen in Symantec-certificaten zou opzeggen, zo waarschuwde het bedrijf ongeveer een half jaar geleden opnieuw dat er actie is vereist door site-eigenaren. De laatste stap in dat proces, het definitief blokkeren van door Symantec uitgegeven certificaten, vindt plaats bij de release van Chrome 70. Die versie moet in de loop van dinsdag uitkomen. De beslissing van Google heeft ermee te maken dat Symantec ten onrechte certificaten voor sites had uitgegeven. Het bedrijf dat het certificatenonderdeel van Symantec vorig jaar overnam, DigiCert genaamd, vervangt de getroffen certificaten zonder kosten.

Firefox-ontwikkelaar Mozilla kondigde onlangs aan de beslissing het vertrouwen in Symantec-certificaten definitief in te trekken uit te stellen, omdat te veel sites nog steeds hiervan gebruik zouden maken. Google bleef stil over eventueel uitstel. Met de release van Chrome 70 zullen bezoekers van de getroffen sites daarom een waarschuwing te zien krijgen. Microsoft en Apple trekken ook hun vertrouwen in Symantec-certificaten terug.

Door Sander van Voorst

Nieuwsredacteur

16-10-2018 • 07:46

53 Linkedin Google+

Reacties (53)

Wijzig sortering
Voor heel veel beheerders zijn certificaten taaie kost en vanuit de business is er altijd druk om geen onderhoud te plegen, zeker niet als het verstorend kan werken. Voor de gewone websites valt het nog mee, maar vooral als je secure webservices aanbiedt is het altijd een hoop gedoe, ook omdat derde partijen aanpassingen moeten doen. Voor je het weet zit je diep in de keystores en truststores en probeer je dat aan de part-timebeheerder van een toeleverancier van een klant uit te leggen.

Aan de andere kant, bij ons hebben we er meteen een gecombineerd projectje van gemaakt. Inventaris van alle certificaten gemaakt, meteen meegenomen om bij de vervanging allerhande deprecated ciphers en TLS1.0/1.1 uit te schakelen. Immers, zo vaak krijg je het budget en de uren niet om dat soort onderhoud te plegen.

Overigens, moet wel eerlijk toegeven dat ik, ondanks dat het onderdeel van mijn dagelijkse werk is, ik pas begin van dit jaar leerde van het Symantec-verhaal. Dat maakte de tijdslijnen best strak. Want ondanks het budget en de uren heeft preventief onderhoud op een goed werkende service praktisch nooit prioriteit boven andere business-vragen.

[Reactie gewijzigd door Keypunchie op 16 oktober 2018 09:35]

Semi-Off topic:
Want ondanks het budget en de uren heeft preventief onderhoud op een goed werkende service praktisch nooit prioriteit boven andere business-vragen
Wordt het niet eens tijd een kosten/baten analyse te maken van preventief onderhoud? De overuren alleen al maakt het waarschijnlijk een goed en kostendekkend idee om dit te doen en die besparing is wel een business-vraag.
Ja, *ik* ben het met je eens. De budgethouders roepen dan altijd "ik neem het risico". Totdat het mis gaat uiteraard, dan heeft beheer het gedaan :+ :D

Security patching is altijd wel te verkopen geweest, helemaal nu de business als de dood is geworden voor datalekken (hoera voor de AVG!). Dat risico gaan ze niet nemen. Life Cycle Management van soft-en hardware is meestal ook wel redelijk beschreven en gebudgetteerd. Maar al het overige is altijd een constante onderhandeling, waarbij lange-termijn voordeel niet per se wint van korte termijn kosten.

[Reactie gewijzigd door Keypunchie op 16 oktober 2018 10:32]

Logboek bijhouden James Comey-style en ze vervolgens klappen geven daarmee dat jij precies weet hoe vaak en wanneer je het hebt voorgesteld en met wat voor slechte argumenten zij het telkens hebben weggeveegd. Komt misschien niet optimaal aan bij de budgethouder maar bij de etage boven hun zou dat wel impact moeten hebben.
En altijd even per mail bevestigen dat je preventief onderhoud voorgesteld hebt maar daar geen toestemming/ruimte/geld/resources/... voor gekregen hebt. Werkt vaak ook: de eerste keer dat je zo'n mail stuurt roept het irritatie op, de volgende keer wordt er wel 2x nagedacht voor toestemming geweigerd wordt. Zeker als er een calamiteit is opgetreden die met het preventieve onderhoud voorkomen was :)
Daarom moet je dat soort beslissingen vast leggen. ‘Prima dat je als business dat risico wil nemen, dat is jullie keus. Dus hier heb je een memo waarin staat dat je het risico accepteer, graag bij het kruisje je handtekening zetten’.

Als ze niet weten waar het over gaat, of het niet begrijpen, ondertekenen ze vaak ook niet zonder extra advies in te winnen. En als ze het wel weten en ondertekenen nemen ze prima hun verantwoordelijkheid en leggen ze hun eigen (spreekwoordelijke) ballen op het blok.

Dit is echt Risk Mgt. 101 en zelfs voor kleine bedrijven niet heel veel meer moeite.
Daarom is dit in mijn ogen ook een goed iets dat ze deze verouderde zaken niet meer accepteren in nieuwe versies.

Als dit altijd maar ondersteund moet worden zullen sommige bedrijven er nooit wat aan veranderen. Nu krijgen klanten etc. zo’n melding in hun gezicht gedrukt waardoor je gaat nadenken of je wel met een bedrijf in zee wilt gaan die zijn zaken (in mijn ogen) niet op orde heeft.

Helaas laat ook dit dan weer duidelijk zien dat veel bedrijven alleen maar meer dan het minimale geld in de ICT kant van hun bedrijf willen stoppen als ze klanten mis dreigen te lopen.
Voor heel veel beheerders zijn certificaten taaie kost en vanuit de business is er altijd druk om geen onderhoud te plegen, zeker niet als het verstorend kan werken.
Wat is onze sector toch een drama. Certificaten/PKI zijn een pilaar van het hedendaagse IT-landschap. Als je daar niet mee kan zingen en schrijven dan weet ik niet hoe je het vak kan uitoefenen. Helaas heb je helemaal gelijk dat de meeste beheerders het maar taai vinden en het een flink risico op storingen met zich meebrengt.

Kunnen we geen jaarlijkse Purge organiseren? 1 dag per jaar dat je vrij mag hacken en kraken. Als je systemen zo belangrijk zijn dat ze die dag niet uit mogen dan moet je maar zorgen dat ze veilig zijn. Als ze niet veilig zijn en toch gehackt worden dan is dat een gevalletje opgeruimd staat netjes.
Zojuist geüpdatet naar Chrome 70 stable en certificaten worden zo te zien nog steeds geaccepteerd. Melding in DevTools is gewijzigd in:
"The SSL certificate used to load resources from https://... will be distrusted very soon. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information."
Het is wel grappig had onder dit artikel het 1.5 jaar oude nieuwsbericht staat waarin het vertrouwen in Symantec certificaten verloren is:
Het is eigenlijk wel schandalig dat er nog steeds websites zijn die dit niet aangepast hebben in al die tijd.
Het meest schandalige is dat er dus mensen zijn die NADAT het vertrouwen opgezegd is, opnieuw Symantec-certificaten hebben gekocht... en dat hun leverancier daarbij niet heeft geroepen "Uh... zou je dat nou wel doen?"
(Even in jip en janneke, zonder een volledige technische beschrijving te geven)

Misschien omdat er alleen groot gecommuniceerd is dat Symantec certificaten niet te vertrouwen zijn maar pas in de teksten staat dat het ook de certificaten van GeoTrust, Thawke, RapidSSL vervangen dienen te worden ? Doordat SSL een Chain structuur ( Chain of Trust) gebruikt vervalt alles onder dat specifieke stukje chain en zal dus moeten vervangen worden.

Vooral GeoTrust heeft weer een helehoop onder zich hangen waardoor het soms totaal onduidelijk is wat er nu gedaan dient te worden, vanuit dat punt is het maar net hoe je het ingericht hebt binnen je bedrijf, wie de beheerder en aanvrager is van je certificaten meestal is dit geen technisch proces maar een puur administratief proces.

Medewerker: Ja we hebben de Symantec certificaten vervangen we gebruiken nu GeoTrust certificaten !

Soms is het ook (jammer genoeg) totaal niet inzichtelijk waar welke certificaten gebruikt worden ik ben bang dat dat het grootste probleem is en dan hebben we het helemaal nog niet dat destijd sper direct alle EV certificaten zijn omgezet naar domein certificaten.

Kortom chaos alom als er niet een afdeling is die SSl certificaten aanvragen doet en deze bewaak :)

[Reactie gewijzigd door ShadowBumble op 16 oktober 2018 08:19]

En daarvoor gaan mensen naar een leverancier die kennis van zaken heeft.
Zo eentje die weet van de hoed en de rand en zijn klant kan aanraden om bij de hele Symantec-keten vandaan te blijven en daarvoor [globalsign/digicert/comodo/.../let's encrypt(!!)] te gebruiken.
Ik ben redelijk goed met de SSL-markt bekend... vandaar dat ik verbazing uitspreek.
Uiteindelijk is de leverancier voor een klagende klant het eerste loket... wat heb JIJ me verkocht.
En daarvoor gaan mensen naar een leverancier die kennis van zaken heeft.
Zo eentje die weet van de hoed en de rand en zijn klant kan aanraden om bij de hele Symantec-keten vandaan te blijven en daarvoor [globalsign/digicert/comodo/.../let's encrypt(!!)] te gebruiken.
Ik ben redelijk goed met de SSL-markt bekend... vandaar dat ik verbazing uitspreek.
Uiteindelijk is de leverancier voor een klagende klant het eerste loket... wat heb JIJ me verkocht.
You would be surprised hoeveel bedrijven dit gewoon zelf in handen hebben en willen houden, dit resulteerd dus in een niet vragen maar gewoon leveren beleid en is je hele SSL inkoop gereduceerd tot een strak "inkoop" proces wat met een beetje pech ook nog eens per bedrijfs afdeling is ingeregeld.

Ik snap je standpunt maar je gaat ervanuit dat mensen luisteren naar een leverancier die enkel even een certificaatje hoeft te leveren. Jij blijft er vanuit gaan dat mensen die kennis van zaken hebben en ook de technische gevolgen kan inschatten bij zowel inkoop als verkoop, dit is echt allang niet meer zo (helaas) want immers (als we al praten over echt een traditioneel inkoopproces) is het goedkoper dat een paar studenten door de "generate wizard" lopen en de NAW gegevens invullen als wat anders. Omgekeerd kan een student prima even dit aanvraagformulier volgen en insturen " no questions asked".

Zeker met de hele Agile beweging waarin teams alles zelf even kunnen regelen voor het lanceren van een nieuwe customer facing website is dit zo gebeurd, want "een certificaatje kan je toch overal aanvragen dat hoeft geen 5 dagen te duren, hier via website x heb ik het met 6 minuten." Zo de website is gelanceerd op naar de volgende sprint en er wordt niet meer naar omgekeken tot het certificaat vervalt of bijna vervalt, en dan heb je nog geluk dat de mensen onboard blijven voor het bedrijf want als je hier met externe ontwikkelaars te maken heeft ben je helemaal het inzicht kwijt waar welk certificaat geplaatst is en wanneer deze vervalt :)

[Reactie gewijzigd door ShadowBumble op 16 oktober 2018 09:10]

Als bedrijven kiezen voor een goedkope oplossing met ondermaats beheer, lopen ze vanzelf het risico op problemen als deze.
Het is wel vrij uitzonderlijk dat zo'n grote autoriteit omvalt, maar juist daarom zou je daar als beetje site echt wel van op de hoogte moeten zijn.
Zijn ze daar niet bewust van, dan is dit iig een leermomentje. Nu kunnen ze kiezen voor investeren in/zoeken naar beter beheer, of wachten op het volgende leermomentje.
In bredere zin scheppen dit soort problemen ook vraag en aanbod om dit voortaan goed te laten regelen door een "specialist". De industrie is nog erg jong, mss dat er op den duur ook competentie certificaten komen voor beheerders, dat ingeburgerd raakt dat als je geen problemen wilt, je iig een beheerder met "blije site garantie" moet hebben.
Tuurlijk, maar ik betwijfel of alle hier genoemde bedrijven de ' studenten-optie' hebben gekozen.
Daarvoor ken ik deze branche iets te goed.
Je bent wel erg naief, want iemand die geen kennis van zaken heeft kan volgens jou dus goed beslissen of een leverancier WEL kennis van zaken heeft. Dat JIJ toevallig bekend met deze markt is een ander verhaal, voor die paar keer dat ik het nodig heb ga ik niet mijn tijd verdoen om me daar zwaar in te verdiepen. Ben zelf al lang van mening dat een hoop leveranciers totaal geen kennis hebben van de technologie die ze leveren, en dus uiteindelijk gewoon verspilde moeite en geld was..
Yup. Had zelf 2 jaar geleden een RapidSSL certificaat gekocht. Ik wist wel inderdaad van het Symantec verhaal af maar was niet op de hoogte dat RapidSSL gebruik maakte van een Symantec certificaat.

Ik kwam er zelf achter doordat tijdens de ontwikkeling van mijn website, Google Chrome me al in de console waarschuwde dat het Certificaat niet te vertrouwen was. Vond ik beetje vreemd; heb toch geld neergelegd om juist van dat soort meldingen af te zijn. Toen contact gezocht met de verschaffer van het certificaat, die me toen het hele verhaal vertelde. Kon toen m'n certificaat omruilen voor een geldige versie.
Netjes opgelost. Maar had het niet nog netter geweest als ze je dat certificaat ook niet verkocht hadden, wetende dat het (ook) ongeldig was?
Aan de andere kant zijn er websites genoeg die even het certificaat voor je controleren. Dat heb ik ook gedaan met de website van mijn vereniging. Je vult het in en ik neem aan dat je een aanbieding krijgt ter vervanging als je certje niet klopt. Maar het is verder een redelijk pijnloos proces - als je een copy / paste van de URL en een enkele klik een "proces" wil noemen.
Eens, het is ook niet iets wat tergend ingewikkeld is of hoort te zijn iig.
Probleem is dat de certificaten zelf nog geldig zijn laatste ongeveer t/m juli 2019. Dus dan valt het bij sommige bedrijven buiten het normale process.
Ekoplaza, het LOI, BumaStemra, Zutphen en Heemskerk lijken (inmiddels?) andere certificaten te gebruiken dan Symantec, en vallen dus buiten de boot. Alleen de supportsite van NS International zie ik nog Symantec gebruiken.

[Reactie gewijzigd door AW_Bos op 16 oktober 2018 08:00]

Geotrust, maar als je het certificaat bekijkt zie je dat Symantic het beheert.
http://gt.symcb.com/gt.crl
Op welke site doel je?
Die jij aanhaalt hebben certificaten bij ondernemingen waarbij Symantec de eigenaar is. Alleen de LOI gebruikt COMODO. Thawte en GeoTrust zijn van Symantec

[Reactie gewijzigd door Emin3m op 16 oktober 2018 08:07]

Ah, oke. Op die manier.
Ik zag het niet direct namelijk 😉
Ekoplaza heeft rapidssl issued in 2017
Loi.nl heeft Comodo RSA ook uit 2017
Ekoplaza: Symantec is/was eigenaar van GeoTrus dus ze hebben het nog niet op orde.
Loi.nl gebruikt inderdaad Comodo nu waarschijnlijk hadden ze nog een certificaat uit 2017 op de plank liggen die nog geldig was.
Mooi, dit speelt al maanden en dit had je als systeembeheerder gewoon moeten weten en optijd moeten fixen.

SSL certificate installeren/vervangen is geen rocket science dus een excus is er eigenlijk niet.

[Reactie gewijzigd door HKLM_ op 16 oktober 2018 07:59]

Wel als het niet je dagelijkse business is, een systeembeheerder had het misschien moeten weten, maar veel bedrijven/mensen hebben geen systeembeheerder..
Misschien een vreemde vraag, maar hoe stel je vast of een certificaat niet meer wordt vertrouwd? Ik werk nu 2 weken bij het bedrijf waar ik nu zit en ik heb werkelijk geen idee of wij hierdoor getroffen zijn.
Het certificaat openen en kijken waar het vandaan komt.
Als ik dat doe dan zie ik precies de zelfde trust chain als bij de LOI. Daar staat echter niet Symantec tussen staan. Waar moet ik dus precies op letten?
Als je het certificaat open moet je kijken bij verleend door als daar iets staat als Geotrust, Globalsign, Symantec, Thawte dan zit je niet goed. Of onder details / verlener daar kan je het ook vinden.

[Reactie gewijzigd door HKLM_ op 16 oktober 2018 09:52]

Bij LOI staan die er ook niet tussen. Bij LOI staat er alleen Comodo.
Dan is het prima :)

sowieso gaat het alleen om certificaten tot 1 december 2017

"Alleen de GeoTrust, Thawte en Symantec certificaten die zijn uitgegeven voor 1 december 2017 worden inderdaad vanaf vandaag niet meer vertrouwd in Google Chrome. Per 1 december 2017 is de certificaatuitgifte van deze merken overgenomen door DigiCert, deze certificaten blijven hierdoor gewoon vertrouwd in de browsers."
LOI heeft zijn certificaten al aangepast. Dat gaf waarschijnlijk de verwarring.
Maarja, jij noemt nu dus een lijstje op die je dan wel moet weten, want zeker weten dat jij nog een hele waslijst aan bedrijfsnamen vergeet.. Als ik zelf aan de hand van een bedrijfsnaam moet gaan achterhalen of een certificaat te vertrouwen is, wat is dan het nut van het certificaat?
De betreffende site in Chrome openen met developer console open. In de console zie je deze melding als de site is getroffen:

The SSL certificate used to load resources from https://www.zutphen.nl will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.
Bedankt! Onze website blijkt niet getroffen.
Hebben we het hier dan over dezelfde Symantec als die van de Norton antivirus software?
Dat kan je echt even opzoeken, kom op.
Wat ik me afvraag: krijgen websites zonder certificaat ook een melding? Een onveilig certificaat is altijd nog veiliger dan geen certificaat toch, behalve dan dat het voor de gebruiker duidelijker is dat er geen slotje dus geen beveiliging is. Maar een groot deel let echt niet op of er een slotje is.
Bij een onbeveiligde website wordt niet een dergelijke melding weergeven. Wel wordt in de adresbalk in Chrome een label "onbeveiligd" voor het webadres getoond (kun je hier testen) en in Firefox wordt onder ieder wachtwoord/invoerveld een uitgebreide waarschuwing getoond dat de website niet veilig is. Ook staat er een rode streep door het slotje in de adresbalk om aan te geven dat de verbinding niet veilig is.

Vanaf deze update wordt een Symantec-certificaat dus net zo "veilig" als een zelfondertekend certificaat; je moet zelf het vertrouwen van het certificaat aangeven in je browser, standaard krijg je een error.

Een onveilig certificaat is net zo onveilig als geen certificaat, dat is de hele reden dat het certificaat gebruikt wordt. In dit geval betekent het eigenlijk: de verbinding die je gebruikt probeert je te overtuigen dat hij veilig is, maar dat is hij niet. Dat is dus iets anders dan normale een onveilige verbinding.

Voor zover ik weet is Google van plan om alle HTTP-verbindingen inderdaad op een gegeven moment van plan om HTTP-verbindingen als onveilig te bestempelen maar als ze dat nu zouden doen zou het veel te veel problemen opleveren.
Wat ik me afvraag: krijgen websites zonder certificaat ook een melding?
Een melding van wat precies? Zonder certificaat heb je uberhaupt geen https-verbinding. Je zult op z'n minst een self-signed certificaat hebben, en die geeft wel altijd een melding, aangezien die in principe nooit trusted zijn (tenzij je hem handmatig getrust hebt).
Een onveilig certificaat is altijd nog veiliger dan geen certificaat toch, behalve dan dat het voor de gebruiker duidelijker is dat er geen slotje dus geen beveiliging is. Maar een groot deel let echt niet op of er een slotje is.
Moah, ik weet het niet. Technisch is het wel wat veiliger omdat je minder makkelijk kunt eavesdroppen dan wanneer je helemaal geen encryptie toepast. Maar security is gebouwd op vertrouwen, en zonder 'veilig' certificaat is er geen vertrouwen. Je kunt dus niet 100% zeker zijn dat je safe bent.

Ik zou dus willen zeggen dat een onveilig certificaat eerder een vals gevoel van veiligheid geeft. Je denkt "beter dan niets", maar wat is dat waard, als je niet kunt vertrouwen op wat er onderweg gebeurt?
Een certificaat is tegenwoordig eigenlijk net zo onveilig als wel een certificaat. Meeste malware sites hebben tegenwoordig gewoon een trusted certificaat.
Als ik de lijst zo bekijk (https://data.openstate.eu/dataset/symantec-ct-scan) hadden voldoende van die sites voorzien kunnen worden van een Let's encrypt (wel encryptie voor data maar geen certified uitgever of officiele stempeltjes nodig) en een aantal lijken domeinen met enkel een redirect (abnamro-basishypotheek.nl) die dus waarschijnlijk al uitgefaseerd zijn en daarom geen nieuw certificaat krijgen.

Al met al zullen deze partijen het vanzelf wel merken als ze 0 hits hebben of klachten krijgen bij invoer gegevens of zo.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True