Mooi zo dan gaan die nu linea recta op ons gehele netwerk op een blocklist.
Gaat om .dad, .phd, .prof, .esq, .foo, .zip, .mov and .nexus. voor wie geen zin heeft zijn tijd te verspillen aan google marketing mail.

Grootste onzin ooit dat we unieke tlds hebben toegelaten buiten de alpha-2 code (land tlds) en ..org, com
Daarbuiten enkel maar ellende van.

Het grootste probleem dat ik zie is de toename van het aantal TLD's (Top Level Domains). Dat zijn er nu ca. 1500: https://data.iana.org/TLD/tlds-alpha-by-domain.txt.

Dat is een probleem omdat er meer mogelijkheden zijn om mensen in verwarring te brengen; als mensen niet precies meer weten hoe de TLD van een domeinnaam luidde, zijn er voor phishers steeds meer alternatieven om uit te kiezen - en neemt de kans toe dat een domeinnaam nog vrij is (zoals tikkie.zip).

Bovendien: je hebt geen garantie dat een TLD die suggereert van een partij te zijn, zoals .microsoft, dat daadwerkelijk is. Bijvoorbeeld: is .politie van de Vlaamse Politie, de Nederlandse Politie of van een heel andere partij die aan iedereen (ook criminelen) domeinnamen verhuurt? Van welke "Le Clerc" is .leclerc?

Bijvoorbeeld in https://tweakers.net/nieuws/209152/#r_18695074 schreef Tweaker WaylonBoer (in reactie op een post van mij), m.b.t. .ms:
Maar die aanname is onjuist, http://ajax.ms/ (http, https geeft een foutmelding) bestaat ook (ik heb overigens geen idee waarom).

Een ander probleem is de idioterie om van browser-adresbalken tevens een zoekveld te maken. Als je invult: update.zip - wat gebeurt er dan? D.w.z. wordt er gezocht naar webpagina's (en PDF's etc.) waar "update.zip" in voorkomt, of wordt http://update.zip/ geopend?

Dat laatste is overigens geen nieuw probleem (bijv. het domein command.com bestaat ook), maar de kans om hier tegenaan te lopen neemt wel toe, vooral met TLD's die ook als bestandsnaamextensie relatief veel voorkomen.

Om uit te vinden wat je zoal kunt vinden onder een TLD, kun je (bijv. met DuckDuckGo of Google) zoeken naar:
site:TLD

Bijvoorbeeld in het geval van .zip:
site:zip

In dit geval is het wel heel makkelijk om iemand erin te laten trappen
https://www.security.nl/posting/796809/Eerste+phishingaanvallen+vanaf+_zip-domeinnamen+gerapporteerd@download.zip

Hoe ga je je oma vertellen dat ze op die link niet mag klikken?

Als ik het goed begrepen heb is er wel degelijk een controle hierop bij het aanmaken van TLD's. Dwz je kunt niet zomaar
een willekeurige TLD registreren zonder gedegen motivatie. Hoe goed (en hoe lang) dat werkt is een ander verhaal
natuurlijk.

Waarom .zip een bijzonder risico is snap ik niet. En dat het geen goed idee was extra TLD's toe te laten dat is duidelijk.

Welke organisatie(s) beslissen of een nieuwe TLD aangemaakt mag worden of niet. En waarom hebben die dit toegsstaan?
Ik mag toch hopen dat dat niet bij commerrciele organisaties zoals Google en cs. ligt.

.zip kan natuurlijk gauw over het hoofd gezien worden door de gemiddelde internet gebruiker voor een bestand dat gedownload moet worden als drivers of een programma. Ik voorzie nog veel phising aanvallen met deze domein naam. Het zal het vertrouwen in .zip bestandsnaam geen goed doen.

Die link opent bij mij (Firefox en Chrome onder Android, en Safari, Firefox, Chrome en Edge onder iOS) gewoon deze pagina. Vermoedelijk komt dat door de slashes na security.nl en voor de @.

Overigens heb ik getest met Android 13, update May 5, 2023 en iOS 16.5 (20F66). Ik heb (nog) niet onder andere besturingssystemen getest. Browserversies:
Android:
• Firefox: 113.1.0
• Chrome: 113.0.5672.131

iOS:
• Safari: (default)
• Firefox: 113.0 (30633)
• Chrome: 113.0.5672.122
• Edge: 112.0.1722.64

Enkele experimenten volgen. Vooraf: https://familyphotos.zip laat je, op dit moment, het bestand familyphotos.zip downloaden, met daarin what_happened.txt met de volgende inhoud:

Een groter risico zou kunnen zijn (als URL openen op eigen risico):

Test: security.nl@familyphotos.zip

Android:
• Chrome toont zoekresultaten;

• Firefox vraagt wat je wilt:

iOS:
• Safari, Chrome en Edge tonen zoekresultaten;

• Firefox vraagt of je wilt downloaden:

Een gevaarlijker alternatief (testen op eigen risico):

Test: https://security.nl@familyphotos.zip

Android:
• Chrome downloadt, ongevraagd, het bestand;
• Firefox vraagt wat je wilt (zie hierboven).

iOS:
• Safari laat in de URL-balk zien: familyphotos.zip (zonder hangslotje) en toont een kleine dialoogbox:

• Chrome en Edge vragen onderin in 1 regel:

• Firefox maakt het wel heel bont: in de adresbalk verschijnt familyphotos.zip/ (dus met / erachter) voorafgegaan door een hangslotje. Als webpagina wordt de inhoud van het zip-bestand getoond, dus begint met iets als:
(ik heb elk teken, dat ik op deze site niet mag gebruiken in reacties, vervangen door een punt).

Aan de andere kant...
Met betrekking tot oma's: als zij een QR-code-met-URL scant, een t.co link opent, of links die ik beschreef in https://security.nl/posting/779781/Unsafe+%22safe%22+links, heeft zij ook geen idee waar ze uit zal komen en kan er ook, zonder vragen (in elk geval door Chrome) een bestand worden gedownload.

Aanvulling:
Zoals ik hierboven schreef: dat werkt niet.

Echter in https://arstechnica.com/information-technology/2023/05/critics-say-googles-new-zip-and-mov-domains-will-be-a-boon-to-scammers/ beschrijft Dan Goodin dat, indien je de forward slashes tussen security.nl en @ vervangt door Unicode tekens - die lijken op forward slashes, het wel werkt.

De door Dan Goodin getoonde lijkt-op-/ tekens hebben Unicode U+2044 en U+2215 (die tekens zelf kan ik hier niet laten zien, security.nl verbiedt de opname van de meeste Unicode tekens in reacties).

Maar die truc werkte ook al zonder dat een URL op .zip eindigt. En, zoals ik in mijn vorige post schreef: er bestaan veel meer methodes om internetters met URL's (en QR-codes) om de tuin te leiden; zo kan een link die eindigt op .html ook een bestand downloaden.

Okee maar als dat .zip zo gevaarlijk is omdat je zou kunnen denken dat het een .zip bestand is, waarom is .com dan niet gevaarlijk omdat je zou kunnen denken dat het een .com bestand is?

Omdat mensen ofwel weten dat een bestand met naam-extensie .com een uitvoerbaar bestand is (of was), ofwel geen idee hebben waar je het over hebt (noch wat ze daarmee zouden moeten, noch of zo'n bestand kwaad zou kunnen op een besturingssysteem van een specifieke fabrikant), terwijl veel meer mensen weten wat een zip-file is.

Dit naast dat .com mogelijk de meestgebruikte TLD is. Niemand denkt bij microsoft.com dat het om de naam van een uitvoerbaar bestand zou kunnen gaan.

Maar hoe langer ik erover nadenk, hoe kleiner ik dat risico vind. Het is vooral het aantal TLD's waar ik mij zorgen over maak, en dat een TLD iets over de identiteit- en/of de betrouwbaarheid van een organisatie achter een domeinnaam zou kunnen zeggen.

Bijvoorbeeld het .trust TLD bestaat al jaren, maar of je de organisaties achter een domeinnaam met zo'n TLD kunt vertrouwen, hangt van meerder factoren af - o.a. hoe goed checken registrars die subdomeinnamen verhuren, of een aanvrager van een domeinnaam geautoriseerd is om dat te doen namens de kennelijke organisatie?

Met andere woorden: is de webpagina van https://nccgroup.trust van het Britse moederbedrijf van Fox-IT uit Delft? Die domeinnaam vond ik door te Googlen naar site:trust - maar als ik op bovenstaande link klik, zie ik "Address Not Found". Lekker betrouwbaar allemaal...

Het lijkt erop dat de mensen met de (waarschijnlijk) goede bedoelingen achter .trust het hebben opgegeven, want https://nic.trust stuurt mijn browser nu door naar https://uniregistry.link/extensions/trust/. Dat wil niet persé zeggen dat zo'n partij het minder nauw neemt, maar dat weet je niet (in elk geval niet zonder nader onderzoek te doen).

Met andere woorden: een willekeurige domeinnaam zegt niets. Als je gebruik maakt van Microsoft 365 zul je moeten onthouden dat *.microsoftonline.com de juiste domeinnaam is om in te loggen, en alles wat daar meer of minder op lijkt foute boel is.

Voorbeeldplaatje: https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/03/Figure-7.-Credential-harvester-mimicking-a-Microsoft-sign-in-portal.-1.png (afkomstig uit https://www.microsoft.com/en-us/security/blog/2023/03/13/dev-1101-enables-high-volume-aitm-campaigns-with-open-source-phishing-kit/).

In een week tijd op 5000 domeinnamen zijn er dus 5 phishing sites. Dat is nog geen 0,1% van de domeinen.

Het probleem is dat tegenover een TLD met een verantwoordelijkheidsbesef en goede procedures altijd kwaadwillende
klanten staan die naar de rechter stappen als ze zijn afgewezen of worden beperkt. En daar winnen ze dan, met als
gevolg dat beperkende maatregelen moeten worden opgeheven.


Wat dat betreft zijn extra TLD's beter, want nu kan Microsoft een login pagina neerzetten op login.microsoft wat voor
veel mensen logischer zal zijn en handiger te onthouden dan iets met .com (is dat niet Amerika dan?) waar bovendien
de kans op verwarring groter is want dan regeistreert iemand microsoftonIine.com en hoppa daar ga je weer. Zo iets
kan men onder .microsoft veel makkelijker in de hand houden, en een TLD registreren is toch wel wat meer gedoe dan
een .com domein.

ICANN .

Sinds 2012 heeft ICANN besloten dat organisaties en bedrijven voorstellen mochten indienen voor nieuwe top level domains.

https://www.domain.com/blog/what-are-the-new-tlds/

https://en.wikipedia.org/wiki/Top-level_domain
https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

De TLD space is ook "verrijkt" met .amsterdam , bijvoorbeeld.

Heb je daar wat voorbeelden van ?

Betrouwbaarheid is misschien lastig te garanderen (uberhaupt) , maar identiteit of sector is m.i. wel dicht te timmeren als je een duidelijk TLD doel hebt .

Een niet-militaire club die .mil afdwingt ? Een niet-overheid die .gov afdwingt ?
Een bedrijf zonder bankvergunning dat .bank afdwingt ?

Het heeft even geduurd, maar domain squatters op merknamen (en typo's) worden - via gewoon merkenrecht - ook snel ontheven van hun domein . (daar is het alleen niet de TLD die dat afdwingt, maar de rechthebbende ).

Ik was altijd wel jaloers op de subdomein-structuur van .uk. (.gov.uk , .co.uk , ac.uk, .org.uk ) . Meer ruimte in de namespace, een oplossing voor een hoop name collisions ,en je kunt voor die generieke subdomeinen een heel duidelijk beleid voeren .
Ze zijn er helaas vanaf gestapt.

Klopt, maar je begrijpt wat ik bedoel.
De kans op fouten is groter door dit soort extensies.

Laten we dat eens vergelijken we dat eens met .xyz
En ik heb nog nimmer legitiem gebruik gezien bij een .vip

Als je al wat langer meedraait dan zou je weten dat het met .NL zo gegaan is.

Het eerdergenoemde TLD .amsterdam betekent ook niet in alle gevallen een relatie met de stad Amsterdam (laat staan dat alle sites van de gemeente amsterdam.nl zouden zijn).

M.b.t. de betrouwbaarheid: veel van de .amsterdam websites sturen je door naar een andere website - met soms flink afwijkende namen, en veel ervan ondersteunen uitsluitend http (als je bijv. Firefox op "https only" instelt kun je er tegenaan lopen dat als je in de adresbalk rai.amsterdam intikt, je te zien krijgt: "Secure site not available [...]" met als keuzemogelijkheid "Continue to http site").

Een aantal sites die gistermiddag niet via https bereikbaar waren - en dus zeker geen HSTS ondersteunen - (onderstaande links doen het dus hoogstwaarschijnlijk ook vandaag niet):

Nb. security.nl weigert om domeinnamen met een .amsterdam TLD klikbaar te maken.

Helaas zijn er in Nederland nog veel idioten (zelfs op security.nl kom je ze tegen) die niet begrijpen waarom http over internet (vooral bij public WiFi, WiFi in hotels e.d., routers met verouderde firmware en/of onbetrouwbare DNS-servers) een slecht idee is, en dus waarom de Firefox instelling "https only" verstandig is. En het schandalig is dat de meeste andere webbrowsers niet zo'n instelling hebben (en default aanzetten), waarmee we snel van dit onnodige risico af zouden zijn.

Juist, iets stellen en natuurlijk verder geen voorbeelden kunnen noemen - de betrokken grensgeval-domeinen bespreken zou echt wel wat toegevoegd hebben.
Je mag echt wel wat concreter zijn als je heel algemeen poneert dat Iets Niet Gaat Werken Want .

En de TLDs en sub-TLDs waarin het _wel_ kan - namelijk een heel duidelijk gedefinieerde scope en doelgroep - wegknippen .

Ik draai lang genoeg mee om de tijd van Ome Piet te herinneren - en geen wonder dat een natte vinger beleid, zeker als effectieve monopolist - inderdaad NIET houdbaar is als iemand dat aanvecht .
Echt jammer - .overheid.nl (en/of .gov.nl) e.d. had een heel duidelijk - en m.i. prima juridisch houdbaar - beleid kunnen hebben dat het _alleen_ voor overheidsinstanties was.

Het is zelden dat ik jouw bijdrages onzinnig vind, maar wel/geen SSL, is in mijn optiek sowieso een ander kaliber dan .zip abuse.

En wat betreft .zip was er destijds hetzelfde gezwets bij .pl (Polen / Perl URL's).
En enigsinds vergelijkbaar de ongegronde angst bij .mx (Mexico / MX records), .ch (Confederatie Helvetica AKA Zwitserland / CHAOS class in DNS) .in (India / Internet class in DNS).

Waarom zou volgens de hoeveelheid TLD's coherent van invloed zijn op de kwaliteit van een registry?

Enige argument dat ik daar voor kan bedenken is omdat het simpelweg financieel onhaalbaar is. Vanaf de start heb ik die visie aangenomen: aantal delegaties x kostprijs + ICANN fee = onvoldoende omzet om alle aspecten van een registry draaiende te houden. Hetgeen verklaard waarom er thans met regelmaat TLD's worden teruggegeven.

Doch, of er nu 7 of 70 of 700 of 7000 of 70000 TLD's in de rootzone staan is 0,0 van invloed op de betrouwbaarheid van een .arpa - of een .int - of een .bank - of een .fi - of een .etc

Ja, ik. Nog altijd vind ik dat van de content afhangen.
Gay porno loeren in een hotel in Qatar lijkt mij minder levensbedreigend dan in Cityden BoLo District in Bos & Lommer, alwaar Sharia extremisten toch net iets meer op je huid zitten.
Maar ik weet dat er landen zijn waar je zo'n DNS lookup (voorafgaand aan jouw heilige SSL) beter niet op :53 doet.
Met of zonder SSL certificaat ben je dan evenzo dood, na steniging.

En jouw SSL van levensbelang laten opgaan in de massa van mijn onnodige SSL verkeer vind ik geen goed argument waarom ik SSL zou moeten gebruiken om het ganse assortiment van frietkot.be te bezichtigen.