Symantec trekt onterecht uitgegeven certificaten in na melding

Symantec heeft certificaten ingetrokken, die het eerder voor verschillende domeinen had uitgegeven. De actie volgt op een melding van Andrew Ayer, oprichter van SSLMate, die de certificaten ontdekte.

Ayer schreef afgelopen week dat Symantec vorig jaar verschillende certificaten voor het domein example.com heeft uitgegeven. Hij meldde dit aan Icann, dat de eigenaar is van het domein. De organisatie zei dat er geen toestemming was verleend voor het uitgeven van de certificaten. Deze certificaten waren echter al ingetrokken. Daarnaast vond hij andere certificaten die waren uitgegeven voor domeinen met het woord 'test' erin. Symantec reageert op de melding en zegt dat de certificaten door een van zijn 'vertrouwde partners' zijn uitgegeven.

Als gevolg van de actie zegt Symantec de uitgaverechten van de betreffende partner te hebben ingetrokken, zolang er een onderzoek loopt. Daarnaast heeft het bedrijf de overige nog geldige certificaten ingetrokken. Daarbij gaat het om verschillende door Ayer gevonden domeinen, bijvoorbeeld 'test1' tot en met 'test9'. Ayer schreef dat deze domeinen aan verschillende partijen toebehoren en dat het onwaarschijnlijk is dat zij allemaal toestemming voor de uitgave hadden verleend. De certificaten zouden niet 'in het wild' gebruikt worden.

Google had in 2015 eerder een root-certificaat van Symantec geblokkeerd, omdat het was uitgegeven in strijd met de geldende regels. Andere certificaatautoriteiten hebben eveneens in het verleden zonder toestemming certificaten voor domeinen uitgegeven. Zo gaf WoSign een certificaat uit voor GitHub, naast andere fouten.

Reacties (43)

[derx666]

Alles moet tegenwoordig secure, maar hoe secure is alles als we de certificaat uitgevers eigenlijk niet kunnen vertrouwen. Het blijkt dat deze tot op vandaag nog steeds grove fouten maken in het toekennen en uitgeven van certificaten, terwijl de veiligheid van in principe het hele internet ervan afhangt.
Het wordt tijd om te zorgen dat de voorkant eens goed geregeld en gecontroleerd wordt, nu alles (eindelijk) over aan het stappen is naar "veilige" communicatieprotocollen.

[TheGhostInc]

Alles moet tegenwoordig secure, maar hoe secure is alles als we de certificaat uitgevers eigenlijk niet kunnen vertrouwen.

Vertrouwen hebben in iemand betekent niet dat iemand geen fouten mag maken!
Het gaat erom dat fouten worden (h)erkend en opgelost. En het liefst dat we er nog iets van leren.

Maar we zijn tegenwoordig heel makkelijk in het opzeggen van het vertrouwen in partijen. Of dat nu de overheid, tech reus of buurman is.
Wat ik vooral lees in dit bericht is dat Symantec bij de example.com certificaten al sneller was met intrekken dan de Icann was met bevestigen dat er geen toestemming was. Dat betekent dat ze hun taak serieus nemen en de impact van dergelijke problemen begrijpen (example.com is verder weinig relevant voor de gemiddelde internetter). Het idee dat ze foutloos zouden moeten werken, dat is eigenlijk gewoon naïef, niemand werkt foutloos.

[derx666]

Dat is het eigenlijk dus juist wel. Het hele certificaat systeem is gebaseerd op vertrouwen. Als daarbij een partij die die certificaten uitgeeft fouten maakt, hoe kun je die partij dan vertrouwen? Wat doen ze om dit in de toekomst te voorkomen?
Heel veel van dit soort bedrijven zijn nauwelijks transparant in hun procedures, wat het vertrouwen niet beter maakt.

Ik kon me vaag iets herinneren dat Google bezig was met iets wat de echtheid van de uitgegeven certificaten beter zou moeten garanderen. Net terug gevonden op tweakers: nieuws: Google stelt volgend jaar Certificate Transparency voor Chrome verplicht

Denk dat dit wel een stap in de goede richting is.
Al is het natuurlijk altijd de vraag wat Google weer met deze gegevens kan en gaat doen

[TheGhostInc]

Als daarbij een partij die die certificaten uitgeeft fouten maakt, hoe kun je die partij dan vertrouwen? Wat doen ze om dit in de toekomst te voorkomen?

Een partij die je kunt vertrouwen is EERLIJK, niet foutloos!
Uiteraard is er wel een grens qua fouten, maar zolang ze open en eerlijk zijn over hun fouten kun je goed bepalen of je ze nog vertrouwd. Een 'foutloze' partij die al hun fouten niet vermeld is echt niet te vertrouwen!

En als je het artikel leest zie je wat Symantec al gedaan heeft en waarschijnlijk zullen er ook nog wel wat aanbevelingen volgen uit het onderzoek.
Dat ze niet meteen alles omgooien en hals over kop allerlei maatregelen treffen is eigenlijk beter, want anders maken ze in de hectiek misschien nog grotere fouten die wel impact hebben.

[supersnathan94]

Ik heb liever een partij die open en eerlijk is over zijn fouten dan een partij die geen fouten maakt. Dan kun je namelijk nooit weten of er een fout is. Ze kunnen namelojk ook alles in de doofpot stoppen.

[rr7r]

Van een partij die geen fouten maakt weet je wel of er een fout is gemaakt, namelijk nooit. In dat geval heb je dus beide. Zou mijn voorkeur hebben.

[supersnathan94]

Je kan er niet vanuit gaan dat er geen fouten worden gemaakt. Dat is immers inherent aan werken met mensen en procedures.

Een partij die geen fouten maakt kan dus wel degelijk fouten maken maar dit gewoon niet toegeven en het niet naar buiten brengen. Daar is de overheid bijvoorbeeld erg goed in.

De verantwoordelijkheid leggen bij groepen die die verantwoordelijkheid helemaal niet kunnen dragen en als het dan fout gaat zeggen dat het niet hun verantwoordleijkheid is, maar alleen als er vragen worden gesteld.

[BeosBeing]

Een partij die je kunt vertrouwen is EERLIJK, niet foutloos!

Klopt. Het lijkt mij, kort door de bocht genomen dat Symantec in deze geen blaam treft.

Echter wat ik vindt: Gezien het feit dat er ergens een fout gemaakt kan worden én dat dit grote gevolgen kan hebben lijkt het me dat het vertrouwen op één partij, ofwel één chain-of-trust onvoldoende is.

Volgens mij zou ieder certificaat door meerdere partijen geverifieerd moeten worden. Een certificaat dat door slechts één partij is goedgekeurd is dus in mijn ogen onvoldoende vertrouwd. Als er zoiets gebeurd als hier, of zoals bij Diginotar, en deze twee zijn niet de enige incidenten, dan is dus ook een door twee partijen vertrouwd certificaat niet voldoende.

Een certificaat zou dus door minimaal drie en bij voorkeur nog meer partijen als vertrouwd moeten worden aangemerkt voordat het als veilig mag worden beschouwd. Hierdoor kan er dus nooit een certificaat onterecht vertrouwd worden aangemerkt.

En blijkt er echt iets fout gegaan te zijn dan kun je dus altijd nog een certificaat expliciet op untrusted zetten.

[latka]

De dag dat ik mijn bank moet bellen omdat er ipv. 10 euro 11 euro is overgeschreven stap ik op bij die bank. CAs hebben maar 1 taak en als ze die niet foutloos doen dan zijn ze per direkt onbetrouwbaar en dus waardeloos. Het is niet de bakker die iets teveel zout gebruikt. Het is de dokter die je been afzet. Een keer om het goed te doen. Dus vertrouwen opzeggen in de CA is volledig terecht.
Overigens ben ik voor (gecontroleerd) fouten maken en leren. Maar wel onder het motto "fail fast and fail hard". Voor CAs (en banken en dokters) superhard.

[Dreamvoid]

En zo stuiter je dus van de ene naar de andere nieuwe oplossing, hopend op die ene tegenpartij die perfect en foutloos is.

[Venix1990]

Dan hop jij vast vaak van bank naar bank..niets gaat foutloos in deze wereld. Iedereen maakt fouten, dat kun je (haast) niet voorkomen.

[latka]

Ik heb nog niet meegemaakt dat geld weg was of verkeerd bezorgd. Wel dat de site het niet doet, dat de servicedesk je niet terugbelt, dat mijn pasje kapot gaat. Maar de core van de bank (transacties doen) gaat goed. Heb jij andere ervaringen?

[Armin]

Het blijkt dat deze tot op vandaag nog steeds grove fouten maken in het toekennen en uitgeven van certificaten, terwijl de veiligheid van in principe het hele internet ervan afhangt.

Je kunt het ook andersom zien. We hebben milioenen certificaten, en elke dag worden er duizenden uitgegeven of vernieuwd. En toch gaat het zelden fout. En als het fout gaat komt het (dus) in het nieuws.

Merk op dat deze fout vooralsnog lijkt op een partner die voor interne test-redenen een aantal certificaten uitgaf, en vervolgens door up-stream CA uitgever meteen ontdekt en op de vingers getikt is. En upstream CA meldt het ook meteen netjes.

Dit alles geeft mij juist meer vertrouwen in het systeem van CA's. Immers zelfs dit soort kleine foutjes worden opgemerkt en komen in het nieuws.

Perfect is soms de vijand van het goede

Het wordt tijd om te zorgen dat de voorkant eens goed geregeld en gecontroleerd wordt, nu alles (eindelijk) over aan het stappen is naar "veilige" communicatieprotocollen

Probleem in deze is dat die alternatieven ook niet zonder gevaren en problemen zijn. En ook daar zul je geen perfectie mee halen.

[latka]

Het is een audited partner (WebTrust audited) en het intrekken gebeurde nadat Ayer het gemeld heeft. Geen eigen audit of finding dus. Dus 2 CAs met audits + trusts etc. zien het niet. Of er miljoenen wel goed gaat vind ik niet zo belangrijk. Iedere dag gaan er miljoenen mensen over de weg in Nederland. Dat er 800 doden per jaar vallen is ook te verwaarlozen.
Perfect is zeker de vijand van goed. Maar het process zoals het nu gedaan wordt is te afhankelijk van de nukken van de CA. De eigenaar van het domein hoeft er niet eens een akkoord voor te geven (dat geld overigens ook voor EV certifcaten). Het idee dat een derde partij de trust bepaald is vreselijk achterhaald. Een beetje als banken versus bitcoin. Het rechtpraten van een systeem wat niet veilig te krijgen is vind ik zonde van mijn tijd.

[Blokker_1999]

En daarom moeten we voor security naar een systeem zonder CAs. En dat kan perfect met bijvoorbeeld DANE/TLSA.

Laat ons voor het encrypten van een verbinding gewoon met self signed certificaten werken icm andere controle mechanismen en laat ons de CAs nog gebruiken voor het vaststellen van de identiteit (EV certificaten).

[.oisyn]

Laat ons voor het encrypten van een verbinding gewoon met self signed certificaten werken icm andere controle mechanismen en laat ons de CAs nog gebruiken voor het vaststellen van de identiteit (EV certificaten).

Wat lost dat op dan? Je hebt nog steeds dezelfde vertrouwen in CA's nodig, want zonder intenditeitsverificatie zijn certificaten nutteloos.

[Blokker_1999]

Dat je niet zomaar een DV certificaatje gaat uitgeven. Voor een EV doorloop je hele procedures om je identiteit bevestigd te zien en krijg je traceerbaarheid. Als ik evenwel vandaag aan een SSL reseller een DV certificaat vraag voor tweakers.net en die geeft dat aan mij dan gaat die wel in de fout maar ook alleen maar omdat de procedures voor DV zo kort en zwak zijn.

[.oisyn]

Moot point, je blijft erop vertrouwen op een authority zijn werk goed doet. Uit dit nieuwsartikel blijkt al dat dat niet het geval is.

[supersnathan94]

De Ca had voor een aantal van de domeinen gewoon direct nee moeten zeggen. Een domein van de icann certificeren aan iemand anders is gewoon dom.

Maar dat is dus ook de reden waarom de procedures transparanter moeten worden. Dan vang je dat soort dingen af.

[Dorank]

Wat lost dat op dan? Je hebt nog steeds dezelfde vertrouwen in CA's nodig, want zonder intenditeitsverificatie zijn certificaten nutteloos.

Daar heb je geen CA voor nodig (behalve voor de EV certs zoals Blokker_1999 al aangeeft). Het alternatief is een Web of Trust:
-Piet heeft het certificaat van Jan gecontroleerd en gesigned.
-Ik heb het certificaat van Piet gecontroleerd (en gesigned)
-Als ik Piet vertrouw kan ik ervan uitgaan dat de gegevens van Jan kloppen.

Als ik een CA niet vertrouw heb ik geen andere manier om een certificaat te controleren op dit moment. Als ik Piet niet vertrouw kan ik wellicht via Henk erachter komen of het certificaat van Jan klopt. PGP heeft hier al jaren geimplementeerd.

Maar als je al bv met iemand communiceerd via email, waarom zou je dan niet al de DANE DNS records vertrouwen? Die zelfde DNS keten vertrouw je schijnbaar wel voor het afleveren van mail via SMTP.

[WhatsappHack]

Ik heb er toch m'n twijfels bij of dat dan wel feilloos gaat werken.
Ja er zitten absoluut schoonheidsfoutjes in het huidige systeem, maar over het algemeen werkt het in 99.99%van de gevallen helemaal prima. 100% is onmogelijk te halen lijkt me, zeker in een chain waar mensen altijd nodig zijn.
Dat krijg je bij een WoT ook... En hoe controleer je dat dan?

Het CA systeem is redelijk kak, maar het werkt tegelijkertijd redelijk goed.
Wat misschien nog wel kan helpen om het te verbeteren is als je kan aangeven dat voor jou (sub-)domeinnaam enkel CA <naam> vertrouwd mag worden, en geen enkele andere.

[Verwijderd]

dus je wilt dat websites 2 certificaten moeten hebben, 1 voor de encryptie en 1 voor de identiteit? Waarbij het onderdeel waar het nu fout gaat als nog door een zelfde soort partij uitgegeven zal moeten worden?

[Blokker_1999]

Niet noodzakelijk. Ik wil dat CAs enkel nog gebruikt worden voor het vastleggen van de identiteit met behulp van een EV certificaat. Als het puur om encryptie gaat kan je evengoed je vertrouwen schenken aan de beheerder van de webserver. Als die een DV certificaat te pakken kan krijgen moet hij/zij even goed in staat zijn om zelf de controle van de echtheid op te zetten.

Er is ook geen enkele reden waarom je een DV certificaat ook niet via DANE kunt verifieren op gebied van encryptie en via de CA op gebied van identiteit.

De reden waarom het fout gaat is omdat op DV certificaten vaak geen goede controle zit. Dat zijn vaak volledig geautomatiseerde processen omdat die certificaten zo goedkoop zijn dat je daar geen personeel op kunt zetten om alles handmatig na te kijken.

[latka]

En waarom zouden EV certificaten wel veilig zijn? Het is alleen het proces wat anders is en keer op keer is gebleken dat CAs hun eigen processen al niet goed kunnen organiseren. Waarom dan wel het (dure!) EV proces ineens goed doen. Men zal ook daar proberen om de kosten te drukken.

[Armin]

Eén van de voordelen van EV is dat de specificatie voorschijft dat er elke keer controle gedaan moet worden, inclusief revocatie. Zelfs notoire non-checkers zoals Google Chrome moeten dan verplicht knarsentandend toch controleren.

Dus niet alleen is het krijgen van een EV moeilijker, maar als het dan toch fout gaat is detectie en vooral ook revocatie een stuk beter geregeld.

Is EV daarmee perfect? Nee, maar het is wel weer een stapje beter.

Uiteindelijk is veiligheid geen zwart-wit, maar altijd een grijstint.

[latka]

Het is valse veiligheid: SSL schreef voor dat je een validatie moest doen (al vanaf dag 1, inclusief KvK controle en controle van de loonlijst van de BV). Dit was in 2001 ruim voor EV. Omdat het moeilijk is doen we dat niet meer en prompt gezeik met valse certificaten. Dus gaan we EV doen (was dus eigenlijk weer de oude validatie constructie was maar dan een stuk duurder).
Een certificaat kost helemaal niets om te maken. De kosten zitten in het proces. Processen kosten geld. Aandeelhouders willen meer winst. Enige kostenpost is proces. Zie hier de ellende waarom CAs in de huidige vorm op de lange termijn NOOIT van nature integer kunnen zijn. Dat chrome het checkt: good for them. Alleen ze toetsen tegen een revocatie lijst van DEZELFDE CA. Dus tjsa, slager is mijn groene vlees nog goed? Tuurlijk.

[Armin]

Processen kosten geld. Aandeelhouders willen meer winst. Enige kostenpost is proces. Zie hier de ellende waarom CAs in de huidige vorm op de lange termijn NOOIT van nature integer kunnen zijn.

Beetje kort door de bocht. Aandeelhouders zijn ook dol op subscription models, ofwel doorgaande controle waar ze facturen voor kunnen blijven sturen.

Dat chrome het checkt: good for them. Alleen ze toetsen tegen een revocatie lijst van DEZELFDE CA. Dus tjsa, slager is mijn groene vlees nog goed? Tuurlijk

Chrome checkt net als IE/Edge en Firefox ook een lijst gemaakt door het bedrijf zelf. Ofwel een CA-revocatie lijst gemaakt door Google/Microsoft/Firefox. Maar een revocatie-lijst van de CA (wat Google nu net niet doet) is ook nuttig, omdat 99,9999+% van de revocaties door de CA gebeuren.

Jij suggereerd dat er massale fraude plaatsvindt bij CA's, maar realiteit is dat fouten zeldzaam zijn en altijd ontdekt worden. Zo ook hier.

Het enige wat ik in deze context stelde is dat bij EV vind extra controle vooraf plaats en ook extra verplichte controle achteraf. Dus als Google vergeet haar eigen lijst te updaten of daarin traag is, wordt het bij EV wel ontdekt, en bij non-EV niet.

Ofwel EV is wel degelijk veiliger dan non-EV. En aangezien fraude bij non-EV al zo goed als niet-bestaand is, durf ik EV veilig te noemen.

[latka]

EV is net zo veilig als regulier is mijn punt: het is een bitje in het certifcaat dat aangeeft dat we deze certificaten beter gecontroleerd hebben. Dat kun je er dus uit bezuiningen.
En aandeelhouders willen alleen ROI. Als er geen groei is dan is dividend ook een vorm van ROI. Alleen is dividend altijd minder gunstig dan flink hard groeien. Er is geen enkele noodzaak om als CA aan de beurs te zitten. Ik zou er voor willen pleiten dat CA een overheidstaak is. Geen BSN maar een certificaat per burger en entiteit. Verdienmodel is niet relevant en mijn BSN als BTW nummer gebruiken vind ik een stuk minder erg als het mijn publieke sleutel is. Ik zeg een win-win situatie ;-)

[Armin]

EV is net zo veilig als regulier is mijn punt: het is een bitje in het certifcaat dat aangeeft dat we deze certificaten beter gecontroleerd hebben. Dat kun je er dus uit bezuiningen.

Maar dat is dus niet zo. Die regels kun je er niet uit bezuinigen.

Plus dat ik jouw visie op het bedrijfsleven niet deel. Ik zie bijvoorbeeld juist een bedrijfsmodel om dat bitje helemaal niet weg te bezuinigen, maar extra facturen te kunnen sturen

Plus dat EV certificaten ook regels tijdens runtime hebben. Tenzij je als browserbouwer de RFC regels niet naleeft. Maar aangezien zélfs Google die een notoir criticus van die RFC is, het netjes naleeft maak ik me daar geen zorgen om.

EV feitelijk:
- vereist meer controle in relatieve zin dan non-EV. En ik ken geen enkele CA die niet meer controleert bij EV dan bij non-EV.
- vereist meer controle tijdens runtime. En elke main-stream browser voert die controles uit.

Dus feitelijk is EV veiliger dan non-EV. Wellicht dat jij die extra borgen niet noemenswaardig vindt, maar dat verandert niets aan de feiten.

Ik zou er voor willen pleiten dat CA een overheidstaak is.

Helaas zijn de enkele van de grootste veiligheidslekken bij cerrtificaten in de geschiedenis nu net die CA's die door overheden gerund werden.

Juist overheden zou ik niet vertrouwen in deze context, want die hebben er soms belang bij (veiligheidsdiensten) om certificaten te vervalsen omwille van spionage van hun burgers of andere overheden.

[moeilijkenaam]

Ik weet hier weinig van, maar wat houdt dit precies in? Wat gebeurt er als zo'n organisatie zo'n certificaat uitgeeft?

[Dreamvoid]

Om een certificaat te krijgen moet je door allerlei verificatiestappen heen waaruit moet blijken dat je bent wie je zegt dat je bent. In dit geval is (blijkbaar?) een certificaat uitgegeven voor het domein example.com, zonder dat de eigenaar (ICANN) dit wist.

Mogelijk heeft iemand zich voorgedaan als ICANN, en is door de verificatieprocedure geglipt.

Een andere mogelijkheid is dat iemand van ICANN (dus wel met de 'juiste' credentials) dit heeft aangevraagd, maar dat dit intern niet afgetikt is.

Waar de fout ook zit, niemand weet nu zeker of het (geheime) private certificaat niet ergens rondzwerft, en dus wordt het certificaat ingetrokken.

[WhiteDog]

Dat is niet noodzakelijk waar, er worden ook certificaten uitgegeven (Domain Validation) waar zelfs geen email aan te pas komt. Zie bv. AutoSSL in cPanel (certificaten uitgegeven door cPanel en Comodo). Dit systeem werkt volautomatisch. Enkel aan de kant van de CA gebeuren er controles in dit geval. De eigenaar van het domein weet soms zelfs niet dat hij een SSL certificaat heeft voor zijn domein

[WhatsappHack]

Er hoef ook geen mail aan te pas te komen, het kan ook op basis van HTTP (tekstbestandje) of een speciale DNS entry.

cPanel regelt dat in dit geval automagisch, in plaats van dat je 't zelf moet doen - maar de controle vindt uiteraard nog steeds plaats. Als je een certificaat aanvraagt voor een domein dat niet naar de server point, dan faalt de verificatie en word dus ook je cert niet gesigned door COMODO. (Of LE, dat ondersteunen ze nu ook.)

[Reactie gewijzigd door WhatsappHack op 26 juli 2024 05:12]

[vitrix]

Zo werkt Let's encrypt bijvoorbeeld.
Die plaats een txt bestand in een map en probeer vervolgens dat tekst bestaat op te halen. Wanneer het bestand bestaat weet let's encrypt dat het domein ook naar die server word verwezen en verwijderd vervolgens ook het txt bestand.

[latka]

Dat is de theorie. In de praktijk kan Symantec voor een willekeurig domein een SSL certificaat afgeven. Alle genoemde controles zijn aan de kant van Symantec en optioneel. Om de status van betrouwbare partner te hebben en houden (en dus vertrouwd te worden door de browsers) zouden alle genoemde controles plaats moeten vinden.
Dat was de theorie.

In de praktijk: iedereen met technische know-how binnen symantec kan een willekeurig certificaat maken voor iedere domeinnaam,
Mederwerkers bij Symantec zijn ook mensen en soms lui en doen stappen niet.
Symantec levert ook sub-CA diensten en dan leg je de verantwoordelijkheid bij een andere partij (en heel veel papier en regels zodat ze het echt helemaal goed gaan doen. Yeah, right).

Dus in theorie is SSL supergoed. In de praktijk is het keer op keer een wassen neus. Van klein tot groot is het vertrouwen in CAs misplaatst.

Wat al beter zou zijn is als je in DNS publiceert wat je publieke sleutel is Dan kan je in ieder geval controleren dat het certificaat wat je vind van de CA ook echt voor jouw domein aangevraagd is en niet alleen dat iemand de hostname in een fake aanvraag heeft gestopt.

[m3gA]

Een website kan zich mogelijk voordoen als een andere website incl het groene slotje.

[Blokker_1999]

Dan heeft iemand een certificaat in handen waar zij geen recht op hebben en kunnen zij de andere partij nabootsen, ook met https verbindingen.

In de gevallen van dit artikel is de kans op misbruik zeer klein omdat het domeinen betreft die enkel voor demonstraties en testdoeleinden worden gebruikt, maar als je bijv. een ssl certificaat voor tweakers.net weet vast te krijgen heb je alweer een puzzelstukje in handen om een man-in-the-middle aanval uit te voeren.

[latka]

Symantec geeft honderden certificaten per dag uit. Het probleem is dat je die niet allemaal kunt toetsen. De gevonden voorbeelden lijken mij gevonden te zijn met een snelle grep actie door de log van uitgegeven sleutels. Als je dan al dit soort rommel vind houd ik mijn hart vast voor de rest van de certificaten die ze uitgeven.

[crzyhiphopazn]

Dat een "foute" site toch via een certificaat middels HTTPS als te vertrouwen bestempeld wordt.

Kort door de bocht versie.

[dennizzz]

GoDaddy heeft onlangs een veel grotere fout gemaakt. Ze deden aan validatie dmv een bestandje met een code, maar ze controleerden de statuscode niet en de naam van het bestand was ook de inhoud. Sommige sites (zoals Google) geven de url terug in de tekst van de 404-pagina (bv http://google.com/geheimecode). Hierdoor vond GoDaddy dus dat de validatie compleet is. Immers, de validatiecode staat in de webpagina.

https://groups.google.com...curity.policy/Htujoyq-pO8

[gjmi]

Daar is het linkje feedback linkje voor onder de titel.

[CaptainHologram]

er staat een feedback knop bovenaan het artikel. deze is bedoeld voor tikfouten en dat soort dingen.