Xs4all-gebruiker krijgt certificaat Xs4all.nl in handen

Een abonnee van Xs4all is erin geslaagd om een ssl-certificaat voor Xs4all.nl aan te maken, naar eigen zeggen door '[e-mail]' te registreren. Die alias zou eigenlijk op een zwarte lijst moeten staan, maar dat is niet gebeurd.

Met behulp van het e-mailadres [e-mail], dat hij als alias voor zijn privéadres aanmaakte, wist Xs4all-gebruiker Remy van Elst bij certificaatautoriteit Comodo een ssl-certificaat voor Xs4all.nl te genereren. Door dat e-mailadres dacht de ssl-autoriteit klaarblijkelijk dat het om een medewerker van de provider ging.

Met het certificaat zou een aanvaller een succesvolle man-in-the-middle-aanval kunnen opzetten om zo het verkeer van gebruikers van en naar die website uit te lezen. Daarvoor moet hij wel eerst de verbinding van een gebruiker kunnen onderscheppen, bijvoorbeeld met een vervalste wifi-hotspot. Overigens is het certificaat niet geldig voor webmail.xs4all.nl of klantenportal service.xs4all.nl, maar Van Elst zou daar met behulp van het e-mailadres wel een certificaat voor kunnen aanmaken.

Het certificaat dat de Xs4all-abonnee aanmaakte wordt standaard vertrouwd door alle webbrowsers, aangezien Comodo een vertrouwde certificaatautoriteit is. Wanneer een aanvaller de verbinding van een bezoeker van Xs4all.nl zou kunnen onderscheppen, kan hij daarom het verkeer van klanten uitlezen zonder dat ze daar erg in hebben door aan hen het valse certificaat te serveren.

Uit een test van Tweakers blijkt echter dat het certificaat en de privésleutel inderdaad bij elkaar horen, wat bewijst dat de Xs4all-abonnee een vals certificaat heeft weten te genereren. Xs4all is door Van Elst op de hoogte gesteld, en bevestigt het nieuws, maar voert wel aan dat Xs4all.nl is voorzien van een zogenoemde dane-entry in de dns. Die standaard moet voorkomen dat elk willekeurig certificaat kan worden geserveerd op een domeinnaam, maar op dit moment ondersteunen browsers dane-entries standaard nog niet.

Xs4all laat in een reactie tegenover Van Elst weten dat '[e-mail]' standaard niet als alias te registreren zou moeten zijn, maar dat dit 'in dit geval is misgegaan'. De Xs4all-klant benadrukt dat hij geen kwaad in de zin heeft. "Vandaar dat ik Xs4all direct op de hoogte heb gesteld en het certificaat heb ingetrokken", zegt Van Elst tegenover Tweakers.

Eerder werd een vals ssl-certificaat voor Live.fi uitgebracht, het Finse domein van Windows Live. Ook dat gebeurde waarschijnlijk doordat een onderzoeker een beheerdersadres in handen wist te krijgen. Overigens gaat het in beide gevallen niet om extended validation-certificaten, waarvoor de identiteit van een aanvrager beter wordt gecontroleerd. Die certificaten zijn te herkennen aan een grote groene balk in de browser, met daarop de bedrijfsnaam.

Reacties (133)

[Deem]

"Door dat e-mailadres dacht de ssl-autoriteit klaarblijkelijk dat het om een medewerker van de provider ging."

Tja, daar gaat het mis. Daar kan XS4ALL vrij weinig aan doen, behalve eens met de vuist bij Comodo op de tafel slaan. Het ziet er uit dat er Comodo niet aan de procedures wordt gehouden, of dat er geen procedures zijn.

[Juup]

Comodo heeft zich prima aan haar eigen procedures gehouden.
Die procedure is: als jij mail kan lezen naar [e-mail] dan mag jij een SSL cert (DV) voor domain.tld registreren.
De meeste andere SSL boeren accepteren minder emailadressen dus Comodo wijkt hier wel af van de norm.

[Cipri]

Onzin, Comodo houdt zich hier prima aan de norm. De regels opgesteld door het CA/Browser forum zijn behoorlijk expliciet over HOE een domein validated mag worden, zie https://www.cabforum.org/...eline_Requirements_V1.pdf

1. Supplied by the Domain Name Registrar;
2. Taken from the Domain Name Registrant’s “registrant”, “technical”, or “administrative” contact
information, as it appears in the Domain’s WHOIS record; or;
3. By pre-pending a local part to a Domain Name as follows:
a. Local part - One of the following: ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’; and
b. Domain Name – Formed by pruning zero or more components from the Registered Domain Name
or the requested Fully-Qualified Domain Name.

Oftewel, gewoon een oops van XS4all dat ze het hebben toegestaan, en dit had prima via enig andere CA kunnen zijn gebeurt.

[latka]

Die regels zijn in de loop der jaren steeds verzwakt om vervolgens nog veel duurdere EV certificaten te gaan verkopen die gewoon de validatie regels volgen die rond 2002-2004 gebruikelijk waren.
Dus oops van Xs4all en een dikke vinger naar Verisign/Comodo en dergelijke voor het lobbyen naar dubieuze praktijken. Mag hopen dat Mozilla G4 certificaten voortaan niet meer accepteert om dit soort praktijken snel de kop in te drukken.

[bbob]

Mijn lijkt het als ik bij sidn zoek op xs4all zie ik alleen [e-mail] staan als administrative en technical contact.

Het lijkt mij logisch dat een ssl aanvraag alleen via die mailadressen mag lopen.
Mocht dat niet zo zijn dan klopt naar mijn mening de hele ssl registratie niet en krijg je dus dit soort problemen.

[Jester-NL]

Het probleem is hier vooral dat het om een Domain Validated cerrtificaat gaat.
Alles dat daarvoor nodig is, is een valide mailadres uit een voorgedefineerd lijstje.

De oplossing is eigenlijk heel simpel: Domein validatie is niet voldoende voor een certificaat. Wat mij betreft schaffen ze het af (en daarmee ook alle gratis certificaten). Het resultaat is dat er uiteindelijk weer wat meer vertrouwen in certificaten komt. Bovendien kun je op dat moment een CA die een certificaat onterecht aan een derde verstrekt aanpakken.
Comodo is 'gewoon' een internationaal bedrijf dat zich 'gewoon' aan de regels houdt. (Het wordt weer een beetje anders als het certificaat door een (Nederlandse) reseller verstrekt zou zijn; daar had bij "XS4ALL" toch een belletje moeten rinkelen).

[tERRiON]

Het probleem is hier vooral dat het om een Domain Validated cerrtificaat gaat.
Alles dat daarvoor nodig is, is een valide mailadres uit een voorgedefineerd lijstje.

De oplossing is eigenlijk heel simpel: Domein validatie is niet voldoende voor een certificaat.

De oplossing is nog simpeler: Voorkom dat derden een mailadres uit het voorgedefinieerde lijstje kunnen bemachtigen. Deze worden namelijk voor wel meer diensten gebruikt.

En waarom zou domeinvalidatie afgeschaft moeten worden? Misschien zie ik het verkeerd, maar voor een hoop toepassingen zijn certificaten met alleen DV prima te gebruiken hoor.

[Jester-NL]

Nope... de kern van het probleem is die Domein validatie.
Er wordt hier wat gezwarte piet of de fout bij de controle van Comodo zit, of bij het feit dat iemand de alias administartor@... heeft kunnen aanmaken, maar dat gaat voorbij aan het feit dat er een certificaat en dus beveiliging en vertrouwen wordt uitgegeven op basis van nauwelijks controle. Namelijk een enkele e-mail, met een linkje daarin.

'tuurlijk... een DV is meer dan genoeg voor een hoop toepassingen. Dat neemt echter niet weg dat het systeem van slechts een controle op basis van een e-mail (ondertussen bewezen) minder veilig is.

[Verwijderd]

Waarom zou het niet veilig zijn? Het systeem lijkt me prima werken zolang bedrijven voldoende zorg besteden aan het veilig stellen van bepaalde e-mail adressen. Voor de meeste domeinen doen dit soort problemen zich sowieso niet voor omdat slechts een beperkt aantal domeinen gebruikt worden door externen die adressen en aliassen kunnen aanmaken.

[latka]

Het is niet veilig omdat het vertrouwensniveau wat uitgaat van een e-mail validatie door de CA vertaald wordt in een algemeen vertrouwen in de site. Dit is niet hetzelfde. Een SSL certificaat had ooit de status 'is veilig' die status is waardeloos geworden door deze grappen (en breek me de bek niet open over EV-SSL certificaten).

[2TheMaks]

Het is niet veilig omdat vrijwel geen enkele gebruiker zelf de vertrouwde root-certificaten van z'n browser, telefoon of tablet beheert, maar gewoon klakkeloos aanneemt dat de trust-store met root-certificaten die door de leverancier van de browser, telefoon of tablet aangeleverd word louter de root-certificaten van CA's bevat die een 100% betrouwbare procedure hanteren.

De gebruiker vertrouwd dus blind op de leverancier van browser, telefoon of tablet wat betreft de chain-of-trust, dus is er in feite ten aller tijden sprake van intermediate trust, zelfs in het geval van een EV certificaat.

[Reactie gewijzigd door 2TheMaks op 24 juli 2024 00:45]

[Jester-NL]

zolang bedrijven voldoende zorg besteden aan het veilig stellen van bepaalde e-mail adressen

Het idee van hetslotje, is dat ik een bedrijf kan vertrouwen, en mijn data veilig met ze kan delen. In een paar dagen tijd komen er twee soortgelijke berichten dat bedrijven die we over het algemeen toch wel vertrouwen een zeperd hebben gemaakt met betrekking tot e-mailadres uitgave. En als gevolg daarvan is er tot twee keer toe een certificaat uitgegeven omdat de enige controle was op basis van dat emailadres.
En vervolgens spreek je vertrouwen uit in "het voldoende zorg besteden aan" door bedrijven...

Alleen een e-mailadres is gewoon niet voldoende controle...

[Verwijderd]

[...]
Het idee van hetslotje, is dat ik een bedrijf kan vertrouwen, en mijn data veilig met ze kan delen.

HTTPS zegt maar heel weinig over hoe veilig de site omgaat met je gegevens. Een HTTPS website kan net zo lek zijn als een HTTP website.

Wat HTTPS voor je doet is:
- Versleuteling van het verkeer tussen jou PC <-> server.
- Garanderen dat je ook werkelijk op de site bent uitgekomen die je in je browser hebt ingetyped.
Niet meer en niet minder.

[Powermage]

De gemiddelde certificaat reseller doet vrij weinig toevoegen aan het hele proces, alleen als het mis gaat zullen ze handmatig ingrijpen, maar voor DV certificaten gaat dit gewoon helemaal vanzelf.

[Jester-NL]

En vandaar dat ik DV een wassen neus vindt

[Powermage]

Dat is zo, maarja, het geeft in iedergeval een groen slotje, veel verder kijkt 99% van de gebruikers toch niet... (ik ken ook klanten die certificaat foutmeldingen gewoon negeren en doorklikken "anders werkte de website niet" )

[Bartmanz]

Een DV certificaat geeft geen groen slotje. Alleen EV certificaat geeft het groene slotje, maar daar zit (zoals de term Extended Validation) ook wel iets meer aan controles achter dan alleen een controle op domeinnaam.

[Murfy]

Hangt af van de browser, maar in Chrome bijvoorbeeld krijg je wel gewoon een groen slotje met domeinvalidatie hoor. Ik zit er net op te kijken.

[Bartmanz]

Daarin is Chrome wel de uitzondering wat betreft de meest gebruikte browsers. Firefox, Opera en Internet Explorer tonen geen van allen bij een DV Certificaat een groen slotje.
Ook de mobiele browser van Chrome doet dit niet. Voor deze browsers telt dat alleen bij een EV-Certificaat een groen slotje en/of groene balk getoond wordt.

[Powermage]

Geen idee waar je de info vandaan haalt, maar net getest met wat DV certificaten die we her en der gebruiken, allemaal netjes groene slotjes in Chrome

Positive SSL Certificaten zijn DV certs en groene slotjes met groene https, maar ook Geotrust DV SSL CA certificaten geven groene slotjes met een groen https.

Een groene naam van het bedrijf, dat is idd een EV cert.

edit: excuses, niet goed gelezen, idd, Chrome geeft groene slotjes, andere browsers niet meer.

[Reactie gewijzigd door Powermage op 24 juli 2024 00:45]

[mrdemc]

[edit]

[Reactie gewijzigd door mrdemc op 24 juli 2024 00:45]

[Armada651]

Het lijkt me geen goed idee DV algeheel af te schaffen, er moet een manier zijn voor servers om verbindingen te encrypten met een minimaal aan authenticatie. Hoe meer encryptie hoe beter, zeker omdat er nog geen automatische (oppertunistic) encryptie plaatsvind voor HTTP verbindingen.

Wat mij wel een goed idee lijkt is om voor DV certificaten geen slotje meer te laten zien. De verbinding kan dan nog steeds plaatsvinden over een encrypted HTTPS verbinding maar geeft het gebruiker niet het idee dat het een veilige verbinding is.

Dit geeft ook de kans voor OV certificaten om zich beter te onderscheiden, hiervoor wordt het telefoonnummer gebeld dat geregistreerd staat bij de KvK. Dat lijkt me al een stuk betrouwbaarder om tenminste een slotje voor te tonen. Echter zijn ze op dit moment amper te onderscheiden van DV certificaten.

[Reactie gewijzigd door Armada651 op 24 juli 2024 00:45]

[djiwie]

Wat mij wel een goed idee lijkt is om voor DV certificaten geen slotje meer te laten zien. De verbinding kan dan nog steeds plaatsvinden over een encrypted HTTPS verbinding maar geeft het gebruiker niet het idee dat het een veilige verbinding is.

Hoezo? De verbinding is versleuteld, dat geeft het slotje aan. Groene balk (EV) geeft aan dat de identiteit grondig is gecheckt.

[Armada651]

Het slotje geeft niet alleen encryptie aan, het geeft ook aan dat met de juiste server is verbonden. Maar wat we dus nu vaak zien is dat een DV certificaat niet genoeg is om de authenticiteit van de server te verzekeren.

[latka]

Beetje subtiel, vind je niet. Snappen je niet door de IT wol geverfde kennis/familie etc. dit verschil?

[djiwie]

Nee, maar die zien het slotje an sich vaak ook niet. Groene adresbalk wel.

[i-chat]

ben ik het totaal niet mee eens, DV certificaten zijn heel nuttig omdat ssl er zo nodig gebruik van moest maken, hadden ze daar andere methodes voor bedacht dan was ik het nog met je eens geweest, maar aangezien password-reclycling aan de orde van de dag is zouden feitelijk alle websites voorzien moeten zijn van een DV'cert... gebruikers moeten zelf gewoon beter opletten en zich realiseren dat iets als de site van een ISP gewoon van EV voorzien hoort te zijn en dat dit dus fake zal zijn...

misschien zou je nog iets van een dns-trick kunnen toevoegen zoals google ook met google apps om gaat... maar an sick is er niets mis met een goedkoop cert voor non-vitale systemen.

[CH4OS]

Want voorkomen dat [e-mail] door klanten te registreren en te gebruiken is, is geen optie? Comodo kan namelijk de identiteit van de issuer niet controleren. Hoe Comodo dit had moeten voorkomen, geen idee.

[Verwijderd]

Ik had gehoopt dat mensen die over security gaan zelf iets beters zouden gebruiken dan plain-text email. Bij voorbeeld PGP. Als zelfs die mensen dat niet doen, dan wordt het nooit wat met encrypted/authenticated email.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 00:45]

[CH4OS]

PGP gaat meer over de encryptie van de content van de e-mail en helpt dus niet bij het hier geschetste probleem.

[Verwijderd]

PGP heeft de feature dat je je emails kunt "signeren".
De ontvanger weet dan zeker dat de email van de zender afkomstig is. (En dat er niets aan de tekst van de email veranderd is).

https://en.wikipedia.org/...rivacy#Digital_signatures

[CH4OS]

Ja, maar dat heeft dan toch geen effect als ik [e-mail] als alias kan krijgen. Maak ik vervolgens voor het adres een PGP key aan en geef die door, is het gewoon valide.

[DFyNt2U]

simple, eis dat request voor certificaat moet komen van het admin email adres komen welke in het domain whois info staat. in dit geval hostmaster@

[CH4OS]

Ja, maar als je dus het admin e-mailadres moet opgeven, heeft dat verder weinig zin.
De "standaard" beheer e-mailadressen zijn ook niet altijd aangemaakt of wat dan ook. Het hoeft dus niet zo te zijn dat [e-mail] een e-mailadres is.

[DFyNt2U]

Volgens de eisen van de dns registrar wel. Praktijk even terzijde.

[moozzuzz]

gelukkig draait het internet niet alleen op theorie

[swhnld]

Dat is de procedure juist, een e-mail sturen naar een voor bepaald adres.

Xs4all heeft al toegegeven dat ze dit hadden moeten blokkeren, maar eigenlijk hadden ze nog beter het mail adres zelf moeten registreren want dan is het echt geblokkeerd voor registratie, een zwarte lijst kan makkelijk fout gaan.

[DonLexos]

Die zijn er wel degelijk, maar als je [e-mail] of [e-mail] toelaat als alias voor 1 van je klanten, dan kan comodo daar verder ook niet zoveel aan doen.

[Verwijderd]

"Niks aan doen?"

Dit account had never aangemaakt mogen worden, als klant zijnde- denk ik dan.
Als je het woordje "poep" in je mailnaam verwerkt, krijg je de gehele abuse-afdeling over je heen, dat deze naam 'ongewenst' is, maar als je 'admin' in je naam verwerkt, valt niemand daar over?

Bij de 'provider of the nerds' nog wel? Daar werkten toch allemaal IT-Geeks die het zo goed weten en je zelfs uitnodigden om XS4All te hacken, in de algemene voorwaarden? De isp die het technisch allemaal zo goed voor elkaar had? Blijkbaar is dat vergane glorie en werken er snurkers.
Excuus voor de lichte bash-tone in deze post, maar ik kan het niet anders verwoorden. Altijd nerdie Linux collega's gehad die XS4All tot de tand verdedigden t.o.v. andere 'plebse' providers, voor het normale grut, mensen zonder verstand en zonder Linux en nu zo'n security-breach?! Ongelooflijk! Diginotar ging hierdoor failliet, was het niet- gerommel met certificaten. XS4All is idd XS4All, in de ruimste zin van het woord.

[Winkey]

Waarom staat [e-mail] er eigenlijk tussen bij Comodo?
We hebben toch al de 'standaard' namen:
- [e-mail]
- [e-mail]
- [e-mail]

[Giesber]

Dat noemen ze social engineering. Als jij een mail krijgt van [e-mail] met de vraag om een receptie bij te wonen zou je misschien ook geneigd zijn om te gaan kijken.

Zeker als je achterdochtig bent en toch maar even de mailheader geverifieerd hebt. Die lijkt dan echt van amsterdam.nl te zijn, dus moet het wel om de burgemeester gaan. Want in dit geval is er namelijk niets gehackt of gefoefeld met headers.

Ik zeg daarmee niet dat het truucje altijd zal werken, maar met een adres als [e-mail] zullen veel mensen er toch in trappen op een slechte dag. Ik ben zelf nogal achterdochtig in zulke zaken, maar ik durf niet te beweren dat dat bij mij nooit zal werken (als ik eens onoplettend ben).

[Winkey]

Tja dat is natuurlijk waar social engineering kan inderdaad ook een gevaar zijn bij het gebruik van dit soort namen/mailadressen. Probleem is wel dat je dan wel veel namen gaat krijgen die op de blacklist moeten.

[Jester-NL]

Valt wel mee... het rijtje adressen dat door een CA wordt gebruikt is redelijk beperkt. En valt daarbij al samen met adressen waarvan je sowieso eigenlijk niet wilt dat deze door anderen dan beheerders worden gebruikt.

[jozuf]

Als je zo slim bent om de mailheaders te checken weet je ook dat je die gewoon als spammer zelf op kan geven in je programmatuur... Heb je dus nix aan.
Tenminste als we er vanuit gaan dat er geen maatregelen als DKIM en/of SPF zijn genomen, en dan nog is dat wel te truuken (kost wat meer moeite).

[Reactie gewijzigd door jozuf op 24 juli 2024 00:45]

[Bor]

Als [e-mail] echt in de lijst met geaccepteerde valide e-mail adressen staat opgenomen in het proces voor het aanvragen van een certificaat heeft dit niets met social engineering te maken.

[Bor]

Dat is niet zo vreemd; [e-mail] zie je veel vaker gebruikt worden hoor. Webmaster is dan weer veel minder in gebruik van postmaster voor dit soort zaken.

Het grotere probleem is het gebrek aan controle wat men doet voor men een certificaat uitgeeft. Zo is het eigenlijk raar dat het voldoende is om een e-mail te sturen bij het aanvragen van een certificaat en dat er geen andere manier van legitimatie nodig is (wat het sturen van een e-mail eigenlijk helemaal niet is). Daar zit een hele grote crux in het systeem rond certificaten.

Verschillende bedrijven hanteren verschillende regels rond het uitgeven van een certificaat ondanks dat deze certificaten door bijvoorbeeld webbrowsers wel als gelijkwaardig worden gezien als het op vertrouwen aankomt.

De regels rond o.a. het uitgeven van een certificaat is overigens opgenomen in de Certificate Policy en het Certification Practice Statement welke elke organisatie die certificaten uitgeeft (intern en extern) zou moeten hebben.

Op basisvan deze documenten zou je afwegingen kunnen maken met betrekking tot hoeveel waarde je aan een certificaat mag hangen. In de praktijk is dat voor gebruikers van bv SSL / TLS al gedaan door de certifcaten als gelijkwaardig te accepteren door het OS of de applicaties zoals een webbrowser terwijl er veel meer onderscheid mogelijk is in het systeem.

[Reactie gewijzigd door Bor op 24 juli 2024 00:45]

[calvinturbo]

Waarom niet authenticeren door een DNS record aan te maken zoals Google Analytics/Webmaster doet?
Is dat onveiliger?

[Bor]

Dat hoeft op zich niet onveiliger te zijn maar het probleem is dat je met een dergelijke procedures geen persoon authenticeert. In feite kan elke beheerder met rechten om DNS records aan te maken een certificaat aanvraag doen. Dan hoeft echter niet een bevoegd iemand te zijn. Daarbij is het DNS systeem, wanneer er geen gebruikt wordt gemaakt van DNSSEC ook geen heel erg veilig systeem. Het issue hierbij is weer dat DNSSEC ook weer afhankelijk is van digitale handtekeningen (en hiermee certificaten).

[.oisyn]

Ik vind je reactie wat kort door de bocht. Sowieso kan de beheerder van de DNS ook andere MX-records instellen - een email voorkomt dus niet dat de DNS beheerder geen verificatie kan doen. Bovendien zit er bij de mailserver ook weer een zwakke schakel - de beheerder daarvan.

Hoe dan ook zul je altijd hebben dat er binnen je organisatie bepaalde personen zijn met macht, en moet je erop vertrouwen dat die macht niet wordt misbruikt.

[Blokker_1999]

Het grotere probleem is het gebrek aan controle wat men doet voor men een certificaat uitgeeft. Zo is het eigenlijk raar dat het voldoende is om een e-mail te sturen bij het aanvragen van een certificaat en dat er geen andere manier van legitimatie nodig is (wat het sturen van een e-mail eigenlijk helemaal niet is). Daar zit een hele grote crux in het systeem rond certificaten.

Dat is het verschil in verificatie niveaus bij certificaten. In dit geval gaat het om een domain validated certificate waarbij het voldoende is om aan te tonen dat jij administratieve toegang hebt tot het domein. In dit geval met aan mail van 1 van de administratieve ontvangers.

Een duurder certificaat dat je een groene balk geeft heeft wel wat meer eisen bij de certificatie. Ze worden dan wel gelijkwaardig geaccepteerd, je ziet daar als gebruiker wel dat de eigenaar van het domein ook geverifieerd is.

[Ypho]

Dat zijn de "standaarden" die door meer CA's worden gebruikt. Overigens zal het hier gaan om een simpel certificaat (niet minder erg!), maar bij een EV of OV zou dit niet kunnen gebeuren omdat er dan meer validatie plaatsvindt, al dan niet met notariële stukken.

/edit: Is het ook niet verplicht om deze emailadressen zelf geregistreerd te hebben?

[Reactie gewijzigd door Ypho op 24 juli 2024 00:45]

[Powermage]

Notariele stukken? toevallig pas geleden bezig geweest met een EV certificaat, maar de checks vielen mij nog ernstig mee. NAW en telefoon gegevens van bedrijf invullen, dit word gecheckt aan enkele publieke bronnen (dus of je telefoonnummer en overige gegevens echt bij het bedrijf horen) en een KVK check vervolgens word de contactpersoon gebeld, die krijgt een validation code en die moet je dmv de email weer bevestigen.

[Blokker_1999]

Notaris keek vreemd op toen ik daarvoor bij hem kwam. Was de eerste keer dat hij zoiets meemaakte

[aapjeisbaas]

admin en administrator + whois mail adres worden ook gebruikt
Waarom?
het is zo I guess...

[Reactie gewijzigd door aapjeisbaas op 24 juli 2024 00:45]

[Anoniem: 510495]

xs4all heeft wel meer dubieuze email adresen bij klanten open staan 3 jaar terug werkte ik bij een bedrijf waar ik mijn rooster gemailt kreeg van de domijn naam
[e-mail] dit zou toch niet mogelijk moeten zijn
ik heb de email nog
ik heb even wat gekopieerd

Scan Date: 03.04.2012 14:26:49 (+0200)
Queries to: [e-mail]

[Reactie gewijzigd door Anoniem: 510495 op 24 juli 2024 00:45]

[Terrestrial]

Laat me raden, Remy van Elst is een Security Now kijker waar die Steve Gibson afgelopen woensdag exact heeft verteld hoe dit werkt en dat de meeste providers vergeten bepaalde aliassen uit te sluiten voor hun klanten.

Ook de CA's verstrekken te gemakkelijk zo'n SSL certificaat.

[CH4OS]

Hoe moet Comodo dat soort zaken controleren dan?

[Terrestrial]

Misschien contact opnemen met de persoon uit de whois informatie om te dubbel checken. En zoals marcelvb hieronder vermeld, er zijn veel meer methodes te bedenken.

[Reactie gewijzigd door Terrestrial op 24 juli 2024 00:45]

[.oisyn]

Misschien contact opnemen met de persoon uit de whois informatie om te dubbel checken

Als onderdeel van de standaard vastgelegde procedure valt onder andere een mailtje sturen naar een standaard emailadres op een domein. Dat de provider er niet voor zorgt dat die standaard adressen op een zwarte lijst staan kan de CA verder weinig aan doen.

[Blokker_1999]

geen e-mail validatie maar het domein op een andere manier valideren waarbij de kans kleiner is dat er misbruik word gemaakt (bijv. via DNS of via een webserver).

[lepel]

Misschien is het handig even in het artikel te vermelden dat XS4ALL het emailadres op de blacklist had moeten zetten, en niet Comodo. Het is dus een slordigheid van XS4ALL, niet Comodo, dit had net zo goed bij een andere certificaat autoriteit kunnen gebeuren.

[mdavids]

En welke adressen moeten dan nog meer op zo'n blacklist staan volgens jou?

[lepel]

Alles dat voor officieel aangezien kan worden. Als jij gebruikers email adressen laat aanmaken met jou domein dan moet je ervoor zorgen dat gebruikers niet bijv. "[e-mail]" kunnen registreren of andere officieel ogende adressen.

[Suggs]

Ik heb de introductie van Wanadoo van dichtbij meegemaakt en ook zo'n blacklist voorbij zien komen. Enerzijds staan daar de adressen op op die je als provider gebruikt (abuse, postmaster, helpdesk e.d.). Daar staan ook de diverse verbasteringen op die die je in eerste instantie doen denken dat je mail krijgt van je provider (bijv. [e-mail]). Ja dat is een stevige lijst waarin je makkelijk iets over het hoofd kunt zien, maar administrator/admin zou je toch niet kunnen/mogen missen.
Anderzijds staan op die lijst adressen waar je als provider niet mee geacciosieerd wil worden. Denk aan racisme, beledigend, godslasterend e.d. Ik weet nog dat Hitler niet mocht.

Xs4all heeft al aangegeven dat dit niet had mogen gebeuren, dus ik er vanuit dat die blacklist nu serieus wordt bekeken.

[aapjeisbaas]

Nu wachten op de appeltaart ;-)

[lhuizing]

Dit verdient zeker appeltaart. Doet XS4ALL dat nog? Zou ze sieren.

[aapjeisbaas]

Ik weet niet of ze het nog doen, Remy heeft het in ieder geval gevraagd.
Ik ben benieuwd of de taart verstuurd wordt.

[Anoniem: 601896]

Zo wordt XS4ALL wel heel letterlijk genomen!

Ontopic:
Helaas is het bedrijf niet meer hetzelfde bedrijf dat het was voor de overname van kpn.

[pegagus]

Zit hier nu de fout bij Xs4all, of bij Comodo die niet verder kijkt dan dat het emailadres lang is? Het lijkt me dat tussen Xs4all en Comodo vastgelegd is via welke procedures en bijgehorende emailadressen certificaten aangevraagd kunnen worden.

[.oisyn]

Het lijkt me dat tussen Xs4all en Comodo vastgelegd is via welke procedures en bijgehorende emailadressen certificaten aangevraagd kunnen worden.

Nonsens, Comodo is maar een van de zovele certificaat-authoriteiten, en heeft geen enkele relatie met xs4all (de officiele xs4all certificaten komen namelijk van GlobalSign). Daarnaast is voor een standaard certificaat alleen maar domeinverificatie vereist, wat op een aantal manieren getest kan worden:
- Een mailtje naar een standaard mailadres (wat hier dus is gebeurd), of een mailadres dat uit de WHOIS gegevens van het domein te halen is (wat in dit geval [e-mail] is)
- Het hosten van een bepaald bestandje onder een specifieke URL
- Het toevoegen van een specifieke TXT record op de nameserver

Je kunt twee dingen stellen:
- Het is dom dat je "admin" en "administrator" als alias of accountnaam kunt gebruiken bij xs4all
- Het is redelijk non-standaard van Comodo om administrator@ te accepteren als validatie-mailadres. De standaard adressen zijn hostmaster@, postmaster@ en webmaster@.
.edit: zoals ik verderop al aangeef zijn admin@ en administrator@ weldegelijk standaard adressen. Comodo kun je dus geen fout aanrekenen.

[Reactie gewijzigd door .oisyn op 24 juli 2024 00:45]

[DonLexos]

Nee hoor, zowel admin@ als administrator@ kun je gebruiken voor domain control. Ook niet zo gek, het gaat om controle over het domein.

Lijkt me hier toch echt fout van xs4all dat ze dit adres niet zelf hebben gelinkt of iig gebiokkeerd. Zelfde geldt voor marketing@ info@ webmaster@ etc ..

[.oisyn]

Nee hoor, zowel admin@ als administrator@ kun je gebruiken voor domain control. Ook niet zo gek, het gaat om controle over het domein.

Nou is dat een beetje een circelredenatie . Waar het uiteindelijk om gaat is dat CA's standaard voorafgesproken mailadressen gebruiken, want als elke CA zijn eigen adressen verzint dan kun je daar als mailprovider natuurlijk nooit tegenop boksen. Maar je hebt inderdaad gelijk dat admin en administrator daar ook onderdeel van zijn, wat je kunt lezen in deze verkeerd geplaatste post die ik eigenlijk hier wilde plaatsen

[DonLexos]

Uiteindelijk kan het zijn wat je wil, zolang je maar vooraf in de WHOIS zorgt dat dat bij het domein staat (admin-contact). En dát kunstje is wat lastiger. Voor de rest is je andere post spot-on.

Foutje van xs4all, begrijp dat de gebruiker het heeft geprobeerd, uitgevoerd en ze erna op de hoogte heeft gebracht. Loopt dus allemaal met een sisser af.

[Blokker_1999]

spijtig genoeg pakken ze niet altijd het administratieve contact adres uit de whois data bij comodo. Recent zelf nog meegemaakt. Sturen ze verificatie via e-mail voor een domein waar geen e-mail op geconfigureerd staat. Men gebruikte daarvoor wel het voorvoegsel dat ze hadden gevonden of gekregen maar het domein erachter werd vervangen door het domein waarvoor het cert moest dienen.

En ja, dat was admin@

[Reactie gewijzigd door Blokker_1999 op 24 juli 2024 00:45]

[.oisyn]

Alleen bij de whois van xs4all.nl staat gewoon [e-mail]. Maar admin@ is ook standaard, zo nu blijkt.

[Reactie gewijzigd door .oisyn op 24 juli 2024 00:45]

[NetCompany]

Het is een faal aan de kant van XS4ALL (en niet aan de kant van Comodo), het lijstje met validatie emailadressen is redelijk standaard, afspraken tussen de verschillende certification authorities (Symantec / Verisign, Comodo, GeoTrust, Thawte, GlobalSign etc. Volgens mij is dit via het CA-Browser Forum geregeld.

hostmaster@
admin@
administrator@
webmaster@
postmaster@

Eventueel (indien afwijkend van bovenstaande) nog het emailadres dat in de WHOIS staat.

XS4ALL had deze op een 'blacklist' moeten hebben, overigens hebben eigenlijk alleen maar partijen die email bieden onder hun eigen / een gedeelde domeinnaam dit probleem, hostingproviders hebben dit probleem meestal niet want daar mag je enkel emailadressen aanmaken op je eigen domeinnaam (waar je dus inderdaad de 'eigenaar' / 'beheerder' van bent).

[.oisyn]

[.edit: oeps dit was bedoeld als reactie op DonLexos in 'nieuws: Xs4all-gebruiker krijgt certificaat Xs4all.nl in handen']

Ah ja, admin en administrator staan er inderdaad tussen

quote: https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

11.1.1 Authorization by Domain Name Registrant
For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has
control over the FQDN by:

1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
4. Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or
7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.

[Reactie gewijzigd door .oisyn op 24 juli 2024 00:45]

[mdavids]

Ok, helder. Ik hoop dat iedere ISP zich hier goed rekenschap van geeft!

[DonLexos]

Ja of je brengt je klanten onder onder een ander domein. Want [e-mail] kan nu een medewerker zijn of meneer de Vries van hier om de hoek nummer 12.

Voor communicatie met de buitenwereld wel overzichtelijker.

[Milt]

Los van wat CA's doen, moet je als e-mailprovider al helemaal niet willen dat klanten dergelijke e-mailadressen kan aanmaken en dus moet er sowieso al een blacklist zijn. Ik kan er nog wel meer (ook minder technisch) verzinnen waarvan je niet wilt dat klanten die kunnen aanmaken.

[Verwijderd]

Het verbaast me niet zoveel maar ik vind dit erg slordig van Comodo. 2 dagen geleden werd er een nieuwsbericht naar buiten gebracht waarbij iemand hetzelfde voor elkaar heeft gekregen voor een live domein van microsoft.
http://www.tivi.fi/Kaikki...-certificate-3217662.html

[Reactie gewijzigd door Verwijderd op 24 juli 2024 00:45]

[Room42]

Zoals elders al beschreven kan Comodo hier niet zoveel aan doen. Zij accepteren gewoon een standaardset e-mailadressen waar een activatiemail naartoe verzonden mag worden. Als domeinhouder (c.q. mailadmin) ben je gewoon verplicht deze adressen veilig te stellen. Zeker jouw klanten/gebruikers mogen deze adressen niet in handen krijgen.

[Mopperman]

een simpel ssl certificaat controleerd alleen de domain-naam door een pre-fix adres te gebruiken, o.a. postmaster, webmaster, administrator en hostmaster (@domain.tld) staan in deze lijst.

Als je dan kan veriferen dat je dit bent, word een certificaat uitgeleverd.

Als je een "groen" ofwel een "Extended Validation" certificaat wil zijn de checks wel groter en grondiger. Dit is meer een slordigheid van XS4ALL.

[Rafe]

Er is geen afspraak tussen Comodo en Xs4all, Comodo heeft hun procedures voor domeinnaamcontrole op hun site staan en het is aan de makers van browsers en besturingssystemen om te besluiten al dan niet het Comodo root certificate als standaard vertrouwd op te nemen in hun software. Voordat ze dat vertrouwen in de organisatie hebben zal die wel de nodige certificeringen moeten behalen, het CA/Browser forum noemt er een aantal voordat je lid van ze kan worden.

[Reactie gewijzigd door Rafe op 24 juli 2024 00:45]

[Blokker_1999]

Wanneer je een domain verified certificaat wenst dan is de controle zeer beperkt. De meeste bedrijven die een certificaat afleveren doen dit door ofwel te vragen om een bepaald bestand beschikbaar te stellen op het domein zodat ze zien dat jij eigenaar bent van de webserver achter het domein ofwel door een e-mail te sturen naar een administratief adres van het domein waarbij de bekende voorvoegsels zoals administrator en hostmaster zijn te gebruiken.

Meer verificatie dan dat gebeurd er over het algemeen niet bij deze goedkope certificaten. Indien je een extended validation wenst (waarbij de adresbalk groen kleurt en de bedrijfsnaam tevoorschijn komt) dan word er wel dieper gekeken. Dan zal men zowel telefonisch als administratief nagaan of je bent wie je beweerd te zijn. Dat soort certificaten zijn daarom ook duurder en voor niet kleine groeperingen zonder officiële erkenning bijv. onmogelijk te bekomen.

[E-Mile]

"Helaas is het bedrijf niet meer hetzelfde etc etc." Sinds de overname in 1999(!) heeft XS4ALL talloze zaken op gebied van security en privacy aangevochten. Nog steeds speelt dit in alle dienstverlening een hoofdrol. Het voorval verdient geen schoonheidsprijs maar deze uitspraak begint 15 jaar na dato wel een beetje een uitgekauwd te raken...

[Verwijderd]

XS4all is alleen nog een merknaam met marketing functie. Het is gewoon een KPN bedrijf.

[batjes]

Nee hoor, net als Telfort draait XS4ALL los van KPN. KPN bemoeit zich redelijk weinig met die 2 dochters tenzij ze slechte cijfers hebben. En XS4ALL komt nog steeds vaak op voor ons consumenten (niet eens alleen hun eigen klanten) en daarin backed KPN XS4ALL ook altijd netjes.

[Quilt]

Schaamtelijk. Zeker omdat dit twee dagen geleden al op Ars stond. Echt niemand bij Xs4all op het idee gekomen om eens door de lijst met de aliassen te gaan?

[.oisyn]

Dat is ook nogal zinloos, door de lijst met aliasen heen gaan. Dat is namelijk een momentopname. Een alias kun je op elk moment gewoon aanmaken. Ze zouden vooral even over de lijst met verboden aliasen moeten gaan.

[marcelvb]

Erg vreemd dat een email adres genoeg validatie is. Ik heb een gratis certificaat van cacert.org en hun policy is:

Domain Control. Domains addresses for server certificates are verified by passing two of the following checks:

• An Email-ping test is done on an email address chosen from whois or interpolated from the domain name.
• The system generates a cookie which is then placed in DNS by the Member.
• The system generates a cookie which is then placed in HTTP headers or a text file on the website by the Member.
• Statement by at least 2 Assurers about ownership/control of the domain name.
• The system generates a cookie which is then placed in whois registry information by the Member.

Alleen checken of het gedeelte voor de @ van een emailadres een bepaald woordje is lijkt me een vrij slechte controle.

[Reactie gewijzigd door marcelvb op 24 juli 2024 00:45]

[Brummetje]

Voor een standaard certificaat (domein validatie) is bij bijna alle cert-autoriteiten een email adres voldoende.

[killabee.nl]

Commodo neemt ook regelmatig telefonisch contact op met de klant zelf om te verifiëren of er daadwerkelijk door hen een certificaat is aangevraagd. Echter doen ze dit niet iedere keer maar willekeurig. Dit zouden ze dus vaker kunnen doen voor extra veiligheid.

[Bor]

Als je een dergelijke controle niet elke keer uitvoert maar slechts als steekproef heeft zo'n proces weinig tot geen nut. Je bepaalt daarmee niet of het systeem misbruikt kan worden maar alleen of het systeem in dat ene geval niet is misbruikt. Een soort polaroid van dat moment dus welke niets zegt over het verleden of de toekomst.

[Benji87]

"Xs4all is door Van Elst op de hoogte gesteld, en bevestigt het nieuws, maar voert wel aan dat Xs4all.nl is voorzien van http strict transport security. Een browser zou daardoor alarm moeten slaan als een vals ssl-certificaat wordt geserveerd, hoewel niet alle browsers hsts ondersteunen."

Kan iemand mij uitleggen hoe HSTS moet beschermen tegen dit certificaat? Want het is toch gewoon een legitiem certificaat doordat het door Comodo is uitgegeven?
Volgens mij is HSTS alleen om te zorgen dat je niet naar http://xs4all.nl gaat, maar gelijk naar https://xs4all.nl. Maar als die dan vervolgens gehijacked wordt met een certificaat van Comodo, dan kan HSTS daar toch helemaal niks aan beschermen?

[XVI]

Je hebt gelijk, alleen HSTS is niet genoeg, je hebt ook HTTP Public Key Pinning (HPKP) nodig én je moet de site al van te voren hebben bezocht.
Een oplossing voor het gemis van HPKP is het distribueren van lijsten met daarin de site-certificaatcombinaties.