Al eens contact met de eigenaar van deze tools opgenomen?

Iemand die een certificaat aanvraagt, heeft er nog geen, dus moet dat via http gebeuren. (-:

Misschien is het een storing bij Lets't Encrypt? Normaal kon het altijd wel via poort 443. Maar ik het net even getest. Als poort 80 dicht zit, lukt de update inderdaad niet meer.

Voor zover ik weet is het alleen en uitsluitend noodzakelijk voor het doen van de domein eigendom check, d.w.z dat txt-bestand met die code die gebruikt wordt om te verifieeren dat jij de eigenaar bent.
Dat dat op http moet draaien is niet zo vreemd, je moet immers in staat zijn om je eerste certificaat aan te vragen (als je dus nog geen https kan draaien omdat je op dat moment nog geen geldig (third-party signed) certificaat hebt). In dit geval, bij renewals, zou het natuurlijk technisch wel kunnen op https. Waarom dat niet kan weet ik niet, maar de foutmelding suggereert dat http "needed" is, d.w.z niet optioneel, dus daar moet je het vrees ik mee doen.

Ik adviseer een virtualhost op poort 80 specifiek voor dit doel, met een zo restrictief mogelijke configuratie en op een locatie buiten de normale documentroot van je eigenlijke site. Dat http niet versleuteld is, is voor dit specifieke doel geen probleem, het is een code voor een eenmalige check, er is geen vertrouwelijke data die beschermd moet worden tegen onderschepping of manipulatie.

Dat geldt voor zoveel specieke doelen!
Maar http heeft een soort stempel van inferioriteit gekregen en daardoor gaan mensen al gauw miepen als dingen
alleen via http kunnen. En software ook, wat die mensen dan weer aanmoedigt om het zo te zien.

check de certbot faq (kwam ik via een simpele google opdracht, gebruik het zelf niet)

Q: Can I issue a certificate if my webserver doesn't listen on port 80?

A: Yes, using the TLS-SNI-01 challenge. At the moment, Certbot only implements this challenge for Apache. If you’re using the webroot mode, your web server must listen on port 80.

volgens mij haal je hier wat zaken door elkaar.

Nee, wat ik bedoel te zeggen is dat 'echte' certificaten niet op RFC1918 hoeven te draaien, dit is immers 'intern', maar ook daar wordt RC4 geblokkeerd. En dat is onzettend <ruk> als je firewalls eerst moet updaten voordat je erbij kunt. Checkpoint 1900 series bijvoorbeeld met <= R77 of Ubiquiti gateways en controllers.

TLS-SNI werkt niet meer, dat is uitgezet na een hack:

" Let's Encrypt has disabled TLS-SNI-01 validation after the discovery of an attack able to hijack certificates ."

Het probleem is dat ik GEEN shit op poort 80 wil hebben draaien vanwege scanners die dan verder gaan kijken.

Misschien eens gewoon in de manual kijken. Dns verification gebruiken

TLS server certificaten, met de bijbehorende geauthenticeerde verbindingen, hebben in principe *NIETS* te maken met IP-adressen, dus ook niet met adressen uit de "private range" reeksen gedefinieerd in RFC1918.

Zelfs als jouw webserver bereikbaar is via IPX, AppleTalk of een RS-232 lijntje, kun je er een certificaat opzetten - de enige voorwaarden daarvoor zijn:
1) Voor alle (TCP/IP pratende) webbrowsers die ermee moeten kunnen verbinden, moet minstens één van de domeinnamen in het certificaat resolven naar een willekeurig IP-adres (en de gebruiker moet zo'n domeinnaam gebruiken in de URL);
2) Routering moet ervoor zorgen dat pakketjes, die door de webbrowser naar dat IP-adres worden gestuurd, uitkomen op jouw server en vice versa.

Voor certificaten uitgegeven door CSP's voor publiek Internet geldt de aanvullende eis dat elke "domeinnaam" in het certificaat (waar dat cert. voor geldt) uniek moet zijn (met wildcard certificaten als enige uitzondering op deze regel, een uitzondering die overigens niet bestaat bij EV certificaten). Ik schreef "domeinnaam" tussen aanhalingstekens, want dit mag ook een IP-adres zijn - mits uniek aan het publieke internet (daardoor heeft bijvoorbeeld https://1.1.1.1/ een geldig certificaat).

Een RFC1918 IP-adres is niet uniek en hoort bovendien niet te routeren op het publieke internet. Alleen al vanwege dat eerste aspect kun je daar geen "commercieel" certificaat meer voor krijgen - en je kunt er zeker geen DV (Domain Validated) certificaat voor krijgen omdat de authenticiteitscheck van DV vereist dat er een route bestaat tussen de DV CSP en het IP-adres van jouw server (en terug natuurlijk).

Heel sneu voor je dat je nog met dergelijke museumstukken moet werken, maar de relatie met certificaten ontgaat me. Tuig een VM op met WFW 3.11 + TCP/IP stack + Netscape 1.0: probleem opgelost.

Dat is geen hack, maar by design bij alle DV speelgoedcertificaten: als jij configuratie-toegang hebt tot een webserver op een willekeurig IP-adres, kun je een DV certificaat krijgen voor elke gewenste domeinnaam die -op dat moment- (bijv. via een door jou uitgevoerde DNS poisoning attack, onrechtmatige toegang tot DNS records of evt. via een BGP hijack) resolvt en routeert naar dat IP-adres.

Voorbeeld: stel je bent crimineel en wilt malware installeren op PC's van mensen die via een publieke WiFi hotspot internetten. Je weet dat ze regelmatig software downloaden van https://www.example.com/ met IP-adres 93.184.216.34. Stel op datzelfde IP-adres zitten meerdere andere websites, dan hoef je maar 1 van die websites te hacken (of de eigenaar van een van die websites met een smoes om te kopen) om een DV certificaat voor www.example.com te verkrijgen, dat je vervolgens bij een MitM aanval kunt inzetten.

Ah now we're getting somewhere. Wellicht is bekend vanaf welke IP-adressen Let's Encrypt jouw server belt en kun je een firewall rule maken die poort 80 alleen voor die IP-adressen openzet?

Ik heb geen idee wat je nu hier probeert te zeggen of melden. Wat heeft dit met RC4 te maken?

Aahaa. Je gebruikt dus eignlijk de verkeerde techniek voor je oplossing. Hiervoor hebben ze DNS authenticatie voor.

Enige alternatief is.... Je firewalls of port 80 aanzetten indien je certificaat vernieuwd moet worden, en daarna weer uitzetten.

Volgens mij is het niet voldoende om maar controle op één website op dat IP te krijgen. Ik gebruik multidomein certifiaten van Let's Encrypt. Als er één domein tussen zit, waar hij geen verbinding mee kan krijgen, dan breekt de procedure al af.
Om toch nog op illegale manier zo'n Let's Encrypt certificaat te bemachtigen moet je al zo diep in de server binnengedrongen zijn, dat je bij een EV certificaat waarschijnlijk ook de private key van de server kunt stelen.

Ik weet niet waar je deze info vandaan hebt, maar als ik zoek, zie ik alleen berichten van januari 2018. Dus een jaar geleden. Een paar maand geleden kon ik echter nog via poort 443 connecten. Als ik in mijn log kijk, is er even veel data uitgewisseld met hun server via poort 80 als over poort 443.

Heeft niets met de manual van doen. Recentelijk werkte het nog gewoon.

Maar dat is geen echt probleem want je hoeft dit alleen open te zetten in die paar seconden dat je een certificaat aan
het verlengen bent.

Bovendien moet je afleren om die Steve Gibson security dwalingen "als ik niet zichtbaar ben dan gaan ze me ook
niet hacken" te volgen. Je zult ook "ping" wel dichtgezet hebben, of wellicht zelfs ALLE ICMP.
Daar word je echt niet veiliger door maar je veroorzaakt er wel problemen mee.

Tussen die berichten die ik vond toen ik zocht zag ik dat ze het voor hosting providers van wie duidelijk was dat die het probleem niet hebben de mogelijkheid weer werd geactiveerd, op het moment van dat bericht waren dat er twee. Ook namen ze contact op met hosters bij wie het mis ging. Wellicht zit je bij een provider waarvan inmiddels duidelijk is dat het goed gaat.

@Briolet,

Misschien moeten we bij verificatie wel naar een ander model, net als bij innovatieve decentrale ad- en tracking-vrije browsers. Geen interferentie meer door Big Tech & Big Guv gedreven, altijd weer subtiel te manipuleren authenticatie methoden en niet-verifieerbare Whois voor eindgebruikers bijvoorbeeld.

Daar waar privacy alleen nog schijnt te bestaan voor de cybercrimineel, de scammer en de spammer achter hun Privacyschildje uit Panamabijvoorbeeld en verder de grote "cloakende" bot-graai-club. Daar waar grote Big Tech jongens als Google etc. via "double Irish en de dutch sandwich' constructies de belasting in de USA van 35% voor miljarden kunnen ontwijken, ja juist ook via ons eigenlijk helemaal niet zo brave Nederland. Tot 2020 kunnen ze rustig hiermee door. Zeker niet leuk voor "America First"-aanhgangers. We moeten derhalve naar een geheel andere New Deal.

Geen adware en surveillance gedreven zoekresultaten, maar een decentrale directe relatie tussen content-aanbieder en eindgebruiker op basis van indifferente solid blockchain core-token gebaseerde resultaten en geen profilering van alle data op basis van soms ondoorzichtige sharing- en commercie-belangen. ERC-20 token gebaseerd dus. Dat is veel eerlijker en veel privacy vriendelijker. De content aanbieder krijgt direct de opbrengsten en Google en facebook gaan maar weer eens op zoek naar een beter verdienmodel, als dat er dan nog is. Weg met graaiers en oplichters en hun sp**ks en collaboranten.

Rian, het orakel uit Veghel, had gelijk met haar "de veiligheidsoplossingen zit waarschijnlijk in de blockchain technologie".. Zij kon het waarschijnl;ijk echter niet zo goed uitleggen. Ik begrijp nu ook beter waarom er een excuus moest worden gezocht bij Mozilla om de zogenaamde alt-right figuur, Brendan Eich, de man die ons een eeuw geleden javascript bracht en nu Brave, aan de schandpaal moest worden genageld om hem daarna weg te bonjouren als browser-ontwikkelaar.

Ja, lieve mensen, Brave 1.0 en beaker peer2peer browsers zijn betere varianten dan de eeuwige op steeds veranderende algoritmen en scripts gebaseerde chrome variabele mono-cultuur. Ook pertinent onveilig zo'n eenvormige soep.

Zo kunnen ook cert en DNS verificatieprotocollen dienovereenkomstig worden aangepast, ik heb liever "eerlijke" AI sturing dan Big Tech commercial verkokering. Geef het Internet eindelijk weer eens echt terug in handen van de eind-gebruikers.
Het zou eens tijd worden.

Een fijn 2019 van,

luntrus

Ik wel. Bijvoorbeeld: https://www.zdnet.com/article/lets-encrypt-disables-tls-sni-01-validation/

Toch is het volgens mij validatie via poort 80 mogelijk als je niet bij een "foute" provider zit.
Het waren de "foute" providers die in een lijst werden verzameld,
d.w.z. providers waarvan meerdere gebruikers hetzelfde IP-adres hebben.

Maar ik lees er op dit moment dit over:


bron: https://certbot.eff.org/docs/challenges.html
(en ik neem aan de je uiteraard de nieuwste versie van Certbot moet gebruiken!)

Hoop voor je dat het hiermee lukt, en anders zul je misschien toch een ander type challenge moeten gebruiken.

Dat was de eerste die ik vond. Maar zoals ik al schreef is dat bericht een jaar oud en klopt niet meer. Bij mij werkte het een paar maand geleden nog en bij TS werkte het ook nog tot recent.

Bij mij werkt het overigens weer via poort 443. De cerbot werkt via poort 443 alleen met een Apache webserver. Ik had een paar week geleden de webserver eens op Nginx gezet. Bij Nginx is geen contact mogelijk met de cerbot via poort 443. Op de Let's Encrypt site staat hier info over en dat ze bezig zijn met een plugin die het gebruik van Nginx mogelijk moet maken.

De webserver weer terug op Apache en ik kan poort 443 gebruiken voor de renewals.

Nee dat is niet bekend. En dat willen ze ook niet bekend maken, helaas.
Want dat betekent dat je geen let's encrypt certificaten kunt aanvragen voor webservers die niet vanaf het hele internet
bereikbaar zijn... jammer maar helaas.
(alleen openzetten voor een stuk of wat let's encrypt validatieservers zou ik voor bepaalde intranetservers nog wel
willen doen, maar niet voor het hele internet)

Pro-tip: Je krijgt een gratis certificaat. Andere aanbieders waar je betaald doen het anders.
Misschien een bounty-feature aanvragen als je graag iets anders ziet? Dan krijgt iemand betaald om jouw ongemak te verhelpen.

Ofwel je moet de DNS authenticatie gebruiken? Of gewoon een betaald certificaat. Oplossing is niet zo lastig.....

Natuurlijk is het bekend. Bij mij gebruiken ze het vaste IP 66.133.109.36. (outbound1.letsencrypt.org). Ze hebben alleen vanaf het begin gezegd dat ze niet willen garanderen dat dit IP altijd gelijk blijft.

Sinds vorig jaar kun je ook via je DNS valideren met ACME v2 en is er helemaal geen ingaande verbinding naar je server nodig.

February 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support
API Announcements
josh
ISRG Executive Director
Oct '18

Let's Encrypt allows subscribers to validate domain control using any one of a few different validation methods. For much of the time Let's Encrypt has been operating, the options were "DNS-01", "HTTP-01", and "TLS-SNI-01". We recently introduced the "TLS-ALPN-01" method. Today we are announcing that we will end all support for the TLS-SNI-01 validation method on February 13, 2019.

In January of 2018 we disabled the TLS-SNI-01 domain validation method for most subscribers due to a vulnerability enabled by some shared hosting infrastructure 64. We provided temporary exceptions for renewals and for a small handful of hosting providers in order to smooth the transition to DNS-01 and HTTP-01 validation methods. Most subscribers are now using DNS-01 or HTTP-01.

If you're still using TLS-SNI-01, please switch to one of the other validation methods as soon as possible. We will also attempt to contact subscribers who are still using TLS-SNI-01, if they provided contact information.

We apologize for any inconvenience but we believe this is the right thing to do for the integrity of the Web PKI.


https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

Nee maar volgens mij WILLEN ze ook de vrijheid hebben om het van een willekeurig IP te doen.
Anders zouden ze een DNS naam "outbound.letsencrypt.org" kunnen maken met alle IP adressen die gebruikt worden (dus niet een aparte naam per adres) en zou je daarmee kunnen filteren op je firewall.
Echter uit de uitleg begrijp ik dat de vrijheid om zomaar een willekeurig adres te gebruiken (bijvoorbeeld via een proxy) een onderdeel is van de beveiliging tegen bijvoorbeeld attacks via man-in-the-middle.

Maar daarvoor moet je weer je eigen DNS draaien of in ieder geval de juiste programmatische controle erover hebben.
Dat is ook niet altijd even praktisch. Veel mensen besteden hun DNS hosting uit ergens bij een hoster die ze alleen een webinterface biedt. Of ze gebruiken split-DNS waarbij de namen van de interne hosts niet allemaal in de externe DNS staan.

Dus geen dedicated hosting op hetzelfde IP zitten, trek je conclusies.

2018-12-24 hns24.ubfmlive.net
2018-11-29 online.ast.com.vn
2018-10-26 rbetransport.com
2018-07-20 bluestick.eu
2018-06-23 skyetechs.com
2017-04-10 outbound1.letsencrypt.org

luntrus

Ik heb wat domeinen met een Spaanse ñ er in. Die zit ook standaard op elk Spaans toetsenbord. (De eerste PC's mochten Spanje nooit in omdat het voor geimporteerde tikmachines ook verplicht was dat die toets erop zat. Daarom loopt Spanje nog steeds achter ook trouwens).

Letsencrypt verstrekt geen certificaten voor die domeinen. Ik snap het wel voor een stukje want je lunt met die domeinen ook prachtig phishen en fake bank domeinen maken waarbij de surfer het verschil nietmeer ziet in de browser. Dus doen ze ze allemaal maar niet bij letsencrypt. Want dan zien mensen een slotje en dan denken ze dat het veilig is.

Letsencrypt verstrekt certificaten om de communicatie te versleutelen. Daar moeten ze zich mee bezig houden. Via de https verbinding met de echte bank kun je uiteindelijk ook totaal kaalgeplukt worden. Met als enig verschil dat dat dan wel legaal is.

Als je eenmaal bent geplukt en er blijkt niks tegen te doen, dan maakt het weinig verschil meer.

Daarnaast ben ik niet met plukken bezig. Ik zou het wel leuk vinden als ik voor een domein met een ñ ook gewoon veilige verbindingen met gebruikers op kan zetten. En dan heb ik het nog maar over Spanje.

Die mentaliteit van iedereen moet maar Engels leren mag wel eens doorgeprikt. Want 80% van de wereld spreekt geen Engels. En ik wil gewoon leuke sites maken voor iedereen. Die 80% is ook markt. Noem het maar een niche dan.

Okeeeeejjj dus een provider waar meerdere gebruikers hetzelfde IP-adres hebben heet nu "een foute provider"??

En hoe zit het dan met het standpunt dat een provider die iedere klant een ander IP-adres geeft een foute provider
is, omdat deze grote hoeveelheden IP-space moet aanvragen/hebben en dus het uitputten van de IP-space in de
hand werkt?

Hoe kom je er bij? Als test heb ik een subdomein "eño" gemaakt en daar een certificaat voor aangevraagd. Geen probleem. Let er wel op dat je bij dat soort tekens uit de niet-ascii set de punnycode gebruikt. Dus dat subdomein op naam "xn--eo-zja".

Ik zeg niet dat (certificaat) hosters met meerdere domeinen op 1 en hetzelfde IP adres onveilig zijn.
Het hangt er maar van af hoe competent de hosting werkt en hoe zwak of sterk de zwakste schakel is.

Als het gratis is, kan het natuurlijk wel ietsjes minder veilig zijn. Dat blijft als een paal boven water staan.

Denk maar eens aan het beruchte afraid dot org, waar soms ineens jouw sub-domein jouw sub-domein niet meer is.

Koop je bij hen het duurste in, zit je echter wel op IDF/Hamas veiligheidsniveau,
maar dat heeft ook ieder mens ook niet ineens nodig.

Er zou dus duidelijke overzichten moeten zijn van Autonome Systemen
en de gang van zaken betreffende het hosten van misbruik op hun domeinen.
Dan kunt je bijvoorbeeld met 1 blik zien waarom je niet bij een Brabants Russian Bussiness Network hostertje moet zijn
en ook waarom bijvoorbeeld Webzilla steeds weer in de cybercrime prijzen valt.
Greed is always an important factor.

Wat we in de eerste plaats nodig hebben is transparentie.
Nu lijkt het wel of de enige bescherming er is voor lieden, die helemaal geen bescherming behoeven. "
When no one has privacy and protection, only outlaws have privacy and are being protected!".

Maar dat geldt tevens voor infrastructuur, die men momenteel het veiligst acht, zie:
https://magoo.github.io/Blockchain-Graveyard/

Lees daar eens en griezel gerust mee van de basale onveiligheid op vele blockchain nodes.
De wereld wil immmers bedrogen worden, dus dan wordt ie dat ook.
En dat loop in de papieren hoor, dat is een hoop "ping ping".

luntrus

Ah mooi. Blijft er toch een poort 443 (=encrypted) authenticatie-challenge.

Let's Encrypt is een vreemde naam aangezien zij certificaten uitgeven om websites mee te authenticeren. Servercertificaten hebben namelijk (mits, volgens best practice, de Diffie-Hellman key agreement wordt gebruikt) niets te maken met het versleutelen van de verbinding.

Dat versleutelen van een verbinding mogelijk is als je niet weet met wiens server je communiceert, zie je bijv. bij een (gasten-) WiFi netwerk: iedereen die het wachtwoord daarvan kent kan een vals accesspoint met hetzelfde SSID en wachtwoord opzetten, waarbij jouw PC/portable device geen verschil kan zien tussen nep en echt.

Webservercertificaten zijn geïntroduceerd om bezoekers met enige zekerheid te laten weten dat hun browser met een server van de bedoelde partij communiceert (en niet met een nepsite van een crimineel). Aanvankelijk werden de private key op de server en de bijbehorende public key in het certificaat, naast voor authenticatie, tevens gebruikt voor een veilige key exchange (van de symmetrische sleutel gebruikt voor het encrypten en decrypten van de verbinding), maar wegens het gemis aan "forward security" daarbij wordt dit afgeraden.

Erg zeker dat je met de bedoelde server communiceert is dat bij DV speelgoedcertificaten overigens niet, wat blijkt uit de vele phishing sites met o.a. Let's Encrypt certificaten.

Dat er twee methodes zijn voor een challenge via poort 443, verklaart een beetje de tegenstrijdige berichten. TS geeft niet expliciet aan welke methode hij gebruikt. En ik weet het bij mij niet omdat ik de gebruikte methode niet zie op mijn Synology nas. Maar ik gok dat dit bij mij dan al de nieuwe challenge is.

Het klopt dat validatie via DNS niet voor iedereen mogelijk is. Als aanvulling op je voorbeelden heb je ook DDNS systemen waar het subdomein naar jou wijst, maar je er verder geen controle over hebt. Doordat browsers steeds moeilijker doen over self-signed certificaten, werkt het ook goed om een Let's Encrypt certificaat aan te vragen voor de ddns naam die naar jouw servertje wijst.


Dan zou ik graag een voorbeeld willen zien van Let's Encrypt certificaat die de "bedoelde server" authentiseert. Volgens mij is het echt zo dat een Let's Encrypt certificaat alleen de url in je browserbalk certificeert. En als daar wel het bedoelde domein staat, en niet van de phishingsite, heb je geen probleem met het certificaat, maar een veel ernstiger probleem.

Nee dat is nou net het grote probleem. Het oorspronkelijke doel van certificaten is allang naar de verdommenis
geholpen, maar op hetzelfde moment wordt iedereen "gedwongen" om https te gaan gebruiken of anders als inferieur
te worden geclassificeerd.

Ik vind http prima voor veel doeleinden maar de gebruikers krijgen meldingen dat de site niet vertrouwd kan worden.
Dus denk je "dan maar zo'n gratis certificaat" maar die kun je dus alleen onder zeer stricte condities aanvragen
waaraan ik niet wil en kan voldoen. (bereikbaar van heel internet, mogelijkheid om naar believen TXT records in
DNS te zetten, dat soort dingen)

Nu is de bovengenoemde "simpele oplossing": ga maar een certificaat KOPEN.
Maar dan gaat het dus geld kosten en renewal gedoe geven (ieder jaar weer spannend of het allemaal goed gaat)
terwijl ik helemaal niet op https zit te wachten.
Waarom geven ze dan niet gewoon toe dat er ook een plek voor http is en dat gezeik over niet vertrouwd of niet
veilig gewoon weg kan? Immers https is ook niet vertrouwd en ook niet veilig.

De naam slaat op de doelstelling. Die is om zoveel mogelijk webverkeer versleuteld te krijgen. Om dat laagdrempelig te maken moeten TLS-certificaten laagdrempelig zijn. Dat is het middel dat ze inzetten om het doel te bevorderen. Dat ze zich naar het doel hebben genoemd en niet naar het middel vind ik niet vreemd.

Je slaat de spijker op zijn kop: zie wikipedia (ik weet het, dat is ook maar verzonnen, maar toch):
https://en.wikipedia.org/wiki/IDN_homograph_attack

Er zijn 4 problemen met Let's Encrypt (en andere gratis DV) certificaten waardoor ze extra aantrekkelijk zijn voor criminelen:

1) De aanvrager hoeft zich niet te legitimeren, wat de pakkans verlaagt;

2) Er is geen money trail dat de pakkans kan verhogen;

3) LE houdt zich niet aan de regels van het CAB forum die van CSP's eist dat ze checken of het om een phishing domein gaat. Zie bijv. https://www.security.nl/posting/510879/Certificaten+Let%27s+Encrypt+en+Comodo+gebruikt+voor+phishing, https://www.security.nl/posting/508472/Let%27s+Encrypt+geeft+15_000+certificaten+uit+voor+PayPal-phishing of https://www.netcraft.com/anti-phishing/deceptive-domain-score/;

4) Er is minstens 1 geval gepubliceerd van waar jij om vraagt, zie https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/. De reactie van Let's Encrypt oprichter Josh Aas daarop in dat artikel:

Met andere woorden, DV certificaten zijn net zo (on) veilig als DNS en/of routering op internet, waarbij meneer Aas het niet nodig vindt om een lijst van domeinnamen bij te houden, die als ze gedeeltelijk of (zoals in geval nr. 4) volledig overeenkomen met een bestaand domein, na te gaan of het verstandig is om zo'n certificaat uit te geven.

(Ongetwijfeld gaat er nu weer iemand blêren dat we allemaal DNSSEC zouden moeten gebruiken, maar (a) dat lost het probleem als gevolg van het onrechtmatig wijzigen van DNS records niet op, (b) helpt niet tegen BGP hijack attacks (zoals deze: https://www.theregister.co.uk/2018/11/13/google_russia_routing/) en dat we allemaal DNSSEC zouden gebruiken is wishful thinking - los van evt. risico's bij het gebruik van DNSSEC).

Letsencrypt is gepromoot als middel tegen afluisteren door veiligheidsdiensten, maar doet dat maar half. Als een veiligheidsdienst in een land (zoals bijv. Turkije, Hongarije, Rusland, China etc.) tussen een lokale webserver en de Letsencrypt check-server "kan gaan zitten", kan die veiligheidsdienst eenvoudig een vals Letsencrypt certificaat voor die website (lees: domeinnaam) verkrijgen en daarmee alle verbindingen van bezoekers met die website -onversleuteld- onderscheppen. Speelgoedcertificaten dus en nog volksverlakkerij ook: ze maken het Internet in een klein maar levensbelangrijk deel onveiliger, en door phishing sites vallen heel veel slachtoffers.

Vandaag, 19:11 door Anoniem
Door Anoniem:

Op welke kop???
https://letsencrypt.org/upcoming-features/:

De kwetsbaarheid is opgelost in Chrome browser en nog een aantal browsers. (Safari, Vivaldi etc)
Firefox wordt ik niet goed wijs uit. Het lijkt erop dat ze het overlaten aan hun "safebrowsing" als er iets niet klopt.
Pech als je tot de categorie behoort die safebrowsing niet vertrouwt.
Je kan nog wel punycode aanzetten zodat het tenminste opvalt. (je krijgt een url die begint met xn.)
(network.IDN_show_punycode = true) Je moet daarna nog wel zelf nagaan of het werkelijk een valse site is of niet.

Er is hierover eerder ook een artikel geweest op security.nl:
https://www.security.nl/posting/511152/Browsers+kwetsbaar+voor+phishingaanval+via+unicode-domein

Volledig verbieden van deze ons "vreemde tekens" in domeinnamen is weer een nadeel voor landen die gewend zijn ze te gebruiken. (en dat zijn er nogal wat)

Is dat erg boeiend, dat mensen zonder verstand van zaken dan gaan ''miepen'' ?

Ja. In ieder geval wel buiten het wereldje van de nerd op zijn zolderkamertje.

Wij hebben in ons alfabet geen vreemde tekens. Daarom konden we al in het begin prima tikken op amerikaanse keyboards. Tegelijk hebben we dan weer een hele rij onuitspreekbare dubbelklinkers. En we plakken woorden aan elkaar als nergens anders.

Wat wel gewoon een feit is, is dat een gebruiker, al spreekt die twintig talen vloeiend, zich nog altijd het lekkerst thuisvoelt in de eigen moedertaal. Er meer vertrouwen in heeft. Dat heel de wereld maar Engels moet leren omdat Joe and Maureen anders met verkansie nergens meer een broodje kunnen kopen, daar moeten we vanaf. Letsencrypt magzich dat wel eens aantrekken. Want als bijvoorbeeld een Yandex of een Baidu met ssl certificaten komt die wel alles ondersteunen, dan zet ik al mijn certificaten vandaag nog om. Of dat kosher is, is vers twee. Gebruikersvriendelijk zijn is voor mij veel belangrijker. Cultuur- en taalvriendelijker moet ik eigenlijk zeggen. Daar heb ik als Europeaan ook meer feeling voor. Ik weet bijvoorbeeld dat Denmark niet de hoofdstad van Amsterdam is. And they all speak Frensch. Waar veel Amerikanen nog serieus moeite mee hebben of zeker menen te weten dat dat wel zo is. Het ook schadelijk voor onze open Europese markt dat letsencrypt zich zo gedraagt.

Wat dat betreft zou de Europese Unie wel eens zo een ssl certificaten dingetje mogen bouwen wat wel respect heeft voor ons. Genoeg slimme mensen op ons continent te vinden die dat kunnen maken.

Speciaal voor Anoniem 17:15 nog een keer:

En ook de wereldwijde toonaangevende organisatie ICANN is hier al een tijd mee bezig.
https://www.icann.org/resources/pages/idn-2012-02-25-en

Dat we in Europa veel Engels spreken heeft voor een groot deel met historie te maken.
De eerste kolonisten van N-Amerika kwamen uit Europa en vooral Groot Brittanië.
Zo werd de algemene voertaal daar bepaald de wet van de meeste mensen die de taal spreken en dat was dus Engels.
Iedereen die vervolgens emigreerde naar N-Amerika of Canada kon maar beter engels leren in daar met de mensen te communiceren. Vervolgens groeide USA uit tot de grootste economie en het land waar alles mogelijk is. (binnenkomen met een dollar en er in no-time miljonair worden). Dus gingen de meeste mensen Engels leren als tweede taal om er zaken mee te kunnen doen. Dat is ook de reden dat zelfs Chinezen ondertussen engels zijn gaan leren en in Nederland zie je dan ook steeds meer jonge mensen die proberen de Chinese taal (als tweede taal) machtig te worden omdat China is uitgegroeid tot de derde economie en perspectieven biedt. Als laatste zijn Nederlanders nogal lui om een Nederlands woord te verzinnen voor een Engels term. Vlaanderen was daar een stuk beter in maar dat zwakt ook al af. Verengelste woorden vind men in Nederland bovendien hip (en dan vooral jongeren).

Kortom:
Als je een graantje mee wil pikken van een welvarend land kan je maar beter de taal van je grotere rijkere handelspartner kennen. Zo werkt dat. Of er immigreren als het kan, maar ook dan kom je niet ver zonder de taal van het land te leren.
Dus als je jong bent en je wilt wat: leer je talen.

Wat er uit dit soort lijstjes komt hangt af van een paar criteria:
- heb je het over moedertaal of over tweede taal waarin men zich ook verstaanbaar kan maken
- kijk je alleen op westers hautaine wijze naar "invloed" of gaat het gewoon om iedere communicatie
- beperk je je tot bepaalde vakgebieden

Ik kan me best voorstellen dat veel computernerds denken dat de hele wereld om Engels draait, en dat zal ook
in andere vakgebieden zo zijn, bijvoorbeeld de financiele wereld, maar dat wil natuurlijk niet zeggen dat je alleen
Engels hoeft te ondersteunen ("ik ga dit echt niet vertalen hoor, dan leren ze maar Engels!") zeker niet als het gaat
om iets algemeens als Internet en niet om het beheren van een computer ofzo.

Wereldwijd is Engels niet eens de meest gesproken (moeder) taal, en is het aantal sprekers van talen die niet
genoeg hebben aan de standaard 7-bit ASCII character set in grote meerderheid tov van degenen die dat wel hebben.
Dus het negeren van het character set probleem is niet verstandig. Toch kom je dat onder computernerds vaak tegen.

7-bit ASCII??? Dat is op het web verleden tijd. Dit is sinds een jaartje of 10 over naar UTF-8.
https://nl.wikipedia.org/wiki/UTF-8. Er is dus helemaal geen character set probleem en de meeste nerds weten dat allang. En voor wat betreft talen: Stel dat dit Manderijns (chinees) is. Of Spaans. Zouden we dan gelukkiger zijn? ;P

We dwalen wel weer geweldig af van de topic-start, luitjes.
Graag wel een beetje on-topic blijven, a.u.b.

Begin anders over het gevaar van Letsencrypt in verband met PHISHing sites of noem maar even een zijstraat.
Wat heeft dit met BEef te maken. Niets.

DNS support geen UTF-8. Zelfs niet eens de volledige 7-bit ASCII set.

...terug naar OP:

Met andere woorden (en hoofdletters); probeer het eens met DNS verificatie.
...die zonder DNSSEC even veilig is als :80
Dus als we toch bezig zijn; maak het een standaard en laat DANE gewoon (ooit) Letsencrypt vervangen.

Dat is slechts een halve waarheid.

Weliswaar accepteert DNS technisch gezien alleen een subset van ASCII karakters,
toch kunnen m.b.v. punycode alle UTF-8 karakters ermee worden weergegeven.
Een browser kan deze punycode automatisch vertalen naar de bedoelde UTF-8 url in je url balk.
(evt. afhankelijk van de browserinstellingen)

Lastig? valt mee hoor, hier heb je tools voor.
Bijv. op het web https://www.charset.org/punycode
Punycode begint overigens altijd met xn-.

xn--6qqu8il7az50cge3o

Nee het is de hele waarheid. Dat er applicaties omheen werken door zelf de UTF-8 tekens te verhaspelen naar
tekens die DNS wel aankan dat staat er los van. Bij het ontwerp van DNS is er geen rekening gehouden dan wel
niet gedacht aan requirements van niet-Engelse gebruikers. Anders was deze shit nu niet nodig.

In aanvulling op mijn vorige bijdrage punt 4: er zijn meer aanvallen bekend waarbij, slechts via ongeaurhoriseerde toegang tot accounts bij DNS registrars, kwaadwillenden onterecht DV certificaten (waaronder van Let's Encrypt) hebben weten te verkrijgen. Zie:
- https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html (van 2018-11-27);
- mijn bron daarvan (van gisteren) https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html;
- en mijn bron (van vandaag) daar weer van: https://www.theregister.co.uk/2019/01/10/fireeye_iran_dns_hijacking/.

Uit laatstgenoemd artikel:
DV certificaten maken beter onderlegde cybercriminelen en (in onze ogen) minder frisse veiligheidsdiensten het leven veel te makkelijk, waardoor je websites met DV certificaten niet goed kunt vertrouwen. Omdat webbrowsers geen verschil tussen DV (Domain Validated) en OV (Organizational Validation) certificaten laten zien, zijn EV (Extended Validation) certificaten het enige type dat bezoekers, van websites met een relatief groot imitatie-risico, nog redelijkerwijs kunnen vertrouwen.

Ja het is een neergaande spiraal waar bewegingen als "http is onveilig we moeten allemaal naar https" en het gratis
aanbieden van certificaten hard aan hebben bijgedragen.

Jaren geleden moest je nog in persoon naar een soort notaris om certificaten aan te kunnen vragen.
Met legitimatie van jezelf en verklaring dat je bevoegd bent te handelen namens het bedrijf.
(zoals gedocumenteerd bij de Kamer van Koophandel)

Eigenlijk wat nu EV heet. Dat was toen standaard. En dat was ook hoe het bedoeld was.

Het alternatief zou ook niet ideaal zijn. Weergave van characters in computers gebeurt altijd in bytes.
Punycode is daarom meestal efficiënter en verwerkt dus sneller.
Vergeet niet dat een teken gecodeerd in UTF-8 uit meerdere (6) bytes bestaan. (U+ met daarachter 4 of 5 decimale cijfers die het bedoelde character aanduiden)
Daarbij had men al vastgelegd dat een url-label uit ten hoogste 63 (ASCII) characters (=bytes) mag bestaan.
Dit wordt met UTF-8 te gemakkelijk overschreden.

Waar een wil is is uiteraard een weg, maar voorlopig zitten we hier aan vast en relatief weinig mensen maken er een probleem van. (en zo problematisch is het in feite ook niet)

Je wilt er kennelijk maar over blijven doorzagen, maar het feit blijft gewoon dat er bij het ontwerp van DNS niet
is nagedacht over de requirements van internationale gebruikers. En daar zitten we nu mee. Die hele idiote
manier waarop een DNS request in het packet gestopt wordt met al die ingebouwde beperkingen is daar maar
een deel van.
Dat krijg je als mensen die denken zoals jij schrijft (bytes zijn sneller te verwerken) de standaard maken.

Daar is uiteraard wel een verklaring voor: het is gemaakt door een stel Amerikanen (die zien Amerika als de wereld)
en de doelgroep was ook niet "het publiek op straat" maar wetenschappers en militairen. Plus dat in die tijd de
systemen veel beperkter waren in capaciteit dan nu.
Maar het is ook helemaal geen waarde-oordeel, het is alleen de constatering van een feit.


Weinig mensen IN JOUW KRINGETJE maken er een probleem van.
Maar wereldwijd is de groep mensen die er een probleem van maakt de overgrote meerderheid.
Alleen dat zijn anderen dan die hier posten. In Nederland hebben we het geluk dat we perfect kunnen werken
binnen de limieten van DNS.
(nouja perfect, eigenlijk hebben we de letter ? nodig maar het wordt vaan gewoon geaccepteerd als je ij neerzet of zelfs y)

DNS domeinnamen zijn uniek identifcerende gegevens. Vanuit securityoogpunt is het daarom onwenselijk dat een getoonde domeinnaam niet of nauwelijks van een afwijkende domeinnaam kan worden onderscheiden.

Kennelijk hebben mensen al moeite om 0ffice36o te onderscheiden van Office360 (beide gevolgd door .com, zie https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html die ik hierboven eerder noemde).

Door allerlei multibyte fonts, met vaak sterk gelijkende of identiek getoonde karakters (vooral op kleinere displays), toe te laten in DNS, zul je veel meer fake websites zien verschijnen - vooral "dankzij" DV certificaten.

Ik verwacht dan ook dat het door Let's Encrypt ondersteunen van IDN (International Domain Names) tot veel meer phishing sites zal leiden, waar die "overgrote meerderheid" die jij noemt wel eens de meeste schade door zou kunnen ondervinden.

Dat detail heb je verkeerd. De notatie met U+ wordt gebruikt om van de hexadecimale (niet de decimale zoals jij stelt) representatie aan te geven dat hij op een Unicode-codepoint slaat. UTF-8 is ontworpen om backwards compatibel met ASCII te zijn. Geldige ASCII-tekens zijn ook geldige UTF-8-tekens op binair niveau, en een geldig ASCII-bestand is dus ook een geldig UTF-8-bestand. Voor de volledige Unicode-tekenset gebruikt UTF-8 1-4 bytes per teken.

Een beetje off-topic, maar de volgende pagina legt erg duidelijk uit hoe unicode op bit niveau in files staat.

https://betterexplained.com/articles/unicode/

Lees dat en je kunt de hele discussie hierboven over UTF-8 kortsluiten.

Als je de abuse cloud amazon blokkeert doet letsencrypt het ook al niet.

O kijk, er wordt een beetje opgelet. ;) . Heel goed.
Maar de conclusie blijft dezelfde:
UTF-8 karakters in talen die de ASCII-subset niet gewend zijn verbruiken per karakter meer dan 1 byte per karakter.
Dus UTF-8 verbruikt in zulke gevallen meestal meer bytes dan punycode.