Let's Encrypt is helemaal niet onveilig, hoe kom je aan die titel?

Het enige wat het doet is het afgeven van SSL certificaten en die zijn opzich gewoon veilig. Het doet niets af aan dit systeem.

Als je de DNS kunt kapen, dat vallen heel veel beveiligingen weg. Ook de mail beveiliging, want dan jun je je eigen public key en spf records in het dns record zetten waardoor zelfs systemen als dmarc de mail als echt zullen bestempelen.

Dat is niet direct een zwakte van Let's Encrypt, maar van een organisatie die zijn DNS record niet goed beveiligd heeft.

Goed dat je me gelijk geeft dat DV certificaten niet veiliger zijn dan DNS! Helaas schieten gewone gebruikers, vooral de nu geplunderde, natuurlijk helemaal niets op met de mededeling dat dit de schuld van DNS (-beheer) is.

Voor degenen die het nog niet snappen: de epic fail van DV certificaten (waaronder Let's Encrypt) is dat zij suggereren dat je een beveiligde verbinding hebt met een site van de bedoelde organisatie, zoals je bank.

Oorspronkelijk was de bedoeling van https certificaten dat zij 3 aspecten zouden koppelen:
1) identificatie van de organisatie
2) domainname van de server
3) public key

Door het schrappen van 1) en het feit dat webbrowsers geen onderscheid maken tussen "gewone" (op naam gezette) certificaten (zoals PKI overheid), zijn alle non-EV certificaten gedegradeerd tot een bevestiging dat het IP-adres, op een gegeven moment verkregen via een DNS request, via internet routeerde naar een server die over de bij de public key behorende private key beschikte.

Oftewel, DV certificaten zijn niet betrouwbaarder dan DNS, waardoor ze een vals gevoel van authenticatie geven.

Zelf 11 jaar geleden certificaten aangevraagd en daar ook onder een wildcard. Geen probleem en geen controle of ik ook was die beweerde dat ik was.

Het is de industrie die certificaten heeft bevorderd tot identificatie van een site terwijl dat toen ook al niet zo was. De gebruiker heeft dat nog steeds in het geheugen terwijl het eigenlijk nooit is geweest en daarom zijn er nu EV certificaten.

Ik zal het maar nog eens herhalen. HTTP verbindingen moeten als onveilig worden weergegeven, HTTPS als normaal en EV zoals het nu gedaan wordt.

Wanneer je de DNS van de bank kaapt kun je ook een certificaat aanvragen bij de meeste andere toko's, dat beperkt zich niet tot Let's encrypt.
Lijtk een beetje op bangmakerij van een overpriced certificaat boer.

Hoe zie jij, bijv. met Google Chrome, dat je op de echte https://www.digid.nl/ zit, bijv. als je belastingaangifte wilt doen?

belastingaangifte doe je niet op de digid site ;)

Dan kijk ik of het DNSSEC icoon bovenin groen is en als het meer wil weten dan klik ik daarop. Dit gaat zowel op voor Digid als voor de Belastingdienst en die ondersteunen beid DNSSEC.

En ja het is een add-on/extension die gemakkelijker te installeren is onder Firefox dan Chrome.

Het is toch ondertussen klip en klaar dat een DV certificaat alleen de verbinding beveiligd maar geen identificatie meer is...al lang niet meer als het überhaupt ooit is geweest.

Dat het verschil tussen de verschillende certificaten nog onvoldoende duidelijk is bij de gemiddelde internet gebruiker onderschrijf ik en daar zouden browser fabrikanten wellicht nog iets meer aan kunnen doen.

Echter staat dat compleet los van de tendentieuze formulering die je gebruikt bij het onderwerp van dit topic. Lets encrypt is een partij die DV certificaten levert en dat heeft niets te maken met het gelinkte nieuwsbericht. Dat DV certificaten op een beperkte mate worden gevalideerd is by-design.

Het doel van zo'n certificaat is enkel client->server versleuteling.

+1...wat een FUD verspreiding zeg...en waarom specifiek Lets Encrypt, er zijn nog tal CA boeren die het niet 100% geregeld hebben en het is 100X veiliger dan geen HTTPS met valide certs.
Met DNS hijacken is het game over en is een cert vals aanvragen 1 van je minste worries..

Aan het certificaat zie je direct dat de root van de staat der Nederlanden is. Deze autoriteit heeft een betrouwbare status. (Idem bij "mijn.belastingdienst.nl" waar je de aangifte doet).
Het probleem bij Chrome is dat ze de controle van het certificaat 'verstopt' hebben, sinds de laatste update, waardoor de gemiddelde internetter dit ook niet meer kan controleren.

Weet je mischien ook waar Edge die verstopt heeft, ik kan ze namelijk niet vinden, en daarom geen Edge.
Alvast bedankt.

Ik zou het niet met dns vergelijken, dat is appel en peer vergelijken.
Met fouten in dns is een cert vrij eenvoudig te omzeilen, bijv. Door simpelweg een nieuwe aan te vragen die je dan krijgt.

Als we certificaten met certificaten vergelijken zijn die van lets encrypt een stuk minder goed, te eenvoudig te krijgen los van gratis of betaald. Lets encrypt certificaten zijn inmiddels ook al heel vaak revoked vergeleken met anderen.

Van comodo krijg je niet zomaar nieuwe ook niet met gekaapte dns, met lets encrypt krijg je die als je die vraagt. Dat is nu juist hun service.

Overigens is het van den zotte om niet https automatisch als onveilig te zien, je kan op een http site prima een login pagina / fijne dback pagina / invulformulier maken die veilig is zodra je op verzenden klikt.

Https met certificaat is namelijk schijnveiligheid want hey mn site heeft https dus veilig is onzin!

Bij moderne TLS verbindingen (gebruik makend van Diffie-Hellmann key agreement AKA forward secrecy) speelt het https certificaat geen enkele rol bij de versleuteling (oftewel de beveiliging-) van de verbinding.

Het doel van een certificaat is authenticatie; DNS is niets meer en niets minder dan de vertaling van een domainname in 1 of meer IP-adressen. Een certificaat dat niet veiliger is dan DNS, is waardeloos. Erger, het geeft een vals gevoel van betrouwbare authenticatie.

Nee dat kan niet (zoals ik al eerder schreef, o.a. in https://www.security.nl/posting/508182/#posting508267). Helaas lijkt dit een niet uit te roeien mythe - notabene op een security site.

Het probleem is dat de code (HTML, Javascript en evt. Flash of Silverlight) die gegevens in de webbrowser versleutelt alvorens ze naar de bedoelde server terug te sturen, op de heenweg (van server naar browser) door een MiTM kan worden gewijzigd.

Meestal zodanig dat de webpagina er hetzelfde uitziet in jouw browser, terwijl jouw vertrouwelijke gegevens nu plain text i.p.v. versleuteld "terug naar de server" worden gestuurd. En dus eenvoudig door de MiTM kunnen worden afgeluisterd.

Dit is nou precies waarom authenticatie essentieel is bij het verzenden van versleutelde informatie; encryptie is zinloos als je niet zeker weet wie (aan de andere kant van de lijn) de sleutel heeft om de versleutelde informatie te decrypten.

Kijk, dat is nou een argument dat hout snijdt. Als je de focus op deze kern legt i.p.v. het "bashen" van Lets Encrypt dan volgen er meer zinvolle discussies. Alhoewel "zinloos" wel erg negatief is. Encryptie maakt het (net als een slot op je voordeur) wel een stuk lastiger voor een casual aanvaller die bijvoorbeeld je router heeft gehackt of in je wifi netwerk zit. Het is nogal een verschil of er helemaal geen versleuteling aanwezig is of dat een aanvaller je apparaat of de dns van de sites die je bezoekt moet hacken.

Nee, niet op de site nee, maar om bij je profiel te komen via de Belastingdienst, moet je eerst inloggen op Digid.
Doe dat zelf al jaren zo.

Ik heb al wel een paar keer gehad dat de certificaat validatie van digid niet lukte door een OCSP probleem.

Authenticatie van wat? RFC5246 heeft het over "the peer's identity" zonder duidelijk te maken wie of wat die peer precies wel en niet kan zijn. Als daar geen eisen aan gesteld worden kan het van alles zijn, inclusief wat Let's Encrypt en andere verstrekkers van DV-certificaten ervan maken.

Voordat EV-certificaten werden geïntroduceerd was de boodschap gewoonlijk slotje=veilig, en werd de indruk gewekt dat alle certificaten waren wat we nu EV-certificaten noemen. Een expliciet onderscheid tussen DV en EV is een verbetering op die praktijk. En de boodschap nu is dat een groen slotje met de naam van de organisatie ernaast nodig is voor kritische zaken (afgaande op Firefox en Chrome, ik heb hoe andere browsers werken niet paraat).

Je kan je druk blijven maken over het feit dat die certificaten in de praktijk niet zijn wat jij vindt dat ze moeten zijn, Erik, maar het ziet er niet uit alsof je die strijd ook maar bij benadering gaat winnen, een flink deel van de wereld denkt er duidelijk anders over. En ook dat kan werken, weet je? De wereld zit vol met zaken die niet optimaal zijn maar toch uiteindelijk goed werken. Dat we daar nog niet zijn met dit onderwerp is duidelijk, maar de oplossingsrichtingen zijn niet gelimiteerd tot wat jij voorstaat.

Dat heb ik op veel meer overheidssites gezien die gebruik maken van PKI overheid certificaten uitgegeven door KPN (validatie via *.managedpki.com).

Maar sinds KPN haar OCSP responses is gaan signeren met SHA256 i.p.v. SHA1 (nog niet zo heel lang geleden, hooguit enkele maanden) lijkt het erop dat ook een ander probleem op die servers is opgelost, waardoor ze geen onverwachte foutmeldingen meer geven.

Overigens zagen alleen mensen die OCSP foutmeldingen als zij OCSP checking op verplicht hebben ingesteld in hun webbrowser (wat in geen enkele gangbare webbrowser meer de default is - voor zover ik weet).

Op lokale schaal heb je welicht gelijk, maar je gaat hierbij voorbij aan de consequenties op globale schaal. Ik probeer mijn stelling te onderbouwen.

Er bestaan 3 soorten https certificaten:

(1) DV (Domain Validated) certificaten waaronder Let's Encrypt.
Hierbij controleert de certificaatuitgever slechts of de domainname (opgenomen in de certificaataanvraag) "klopt" door ofwel:
- Een e-mail te sturen naar een door de aanvrager opgegeven "beheer"-account onder de opgegeven domainname. Als daarop het verwachte antwoord komt, wordt het certificaat meteen afgegeven ([1]);
- Nadat de aanvrager een speciaal stukje software op de webserver heeft geïnstalleerd, zoekt de certificaatuitgever daar verbinding mee en als dat lukt, wordt het certificaat meteen afgegeven.

In beide gevallen ben je afhankelijk van wat de certificaatuitgever als DNS antwoorden krijgt, en van de IP routering tussen die certificaatuitgever en het e-mail account resp. de webserver. Routering is ook niet 100% betrouwbaar (zie bijv. [2]) en geheime diensten lachen om dit soort "authenticatie" (want als zij zich ergens tussen zo'n certificaatuitgever en de te faken site gaan zitten, hebben ze zo een geldig certificaat te pakken - waarna ze de fake site tussen de echte site en de en te bespioneren individuen kunnen positioneren).

Daarnaast, doordat in dit soort certificaten uitsluitend de domainname aan een public key wordt gekoppeld is het noodzakelijk dat de bezoeker de domainname exact kent (prima voor een site als security.nl, maar niet voor icscards.nl) en deze niet visueel gespoofd kan worden met andere karaktersets. Als de bezoeker zich er niet bewust van is dat zij de volledige domainname moet controleren, tot de afsluitende slash (die steeds meer webbrowsers niet eens meer laten zien(!)) kunnen zij zeer eenvoudig om de tuin worden geleid met "lijkt op" domeinnamen [3].

(2) "Gewone" certificaten
D.w.z. waarbij andere velden dan CN (Common Name, met daarin de domainname) in het subject, de identiteit van de eigenaar (min of meer precies) beschrijven. De zorgvuldigheid waarmee wordt vastgesteld dat de aanvrager geautoriseerd is om dit te doen namens de organisatie, en of die aanvullende velden onder subject de bedoelde organisatie nauwkeurig identificeren, varieert helaas enorm. Bijv. bij gewone PKI overheid certificaten is deze check echter behoorlijk streng.

(3) EV (Extended Validation) certificaten
Aanvragen hoervoor ondergaan de meest strenge check (met minimale eisen overeengekomen door de club van certificaatuitgevers, CABforum).

Status
Aangezien webbrowsers geen visueel onderscheid meer maken tussen (1) en (2), en je in steeds meer webbrowsers (niet alleen op portable devices) geen certificaten meer kunt bekijken, kunnen ook ervaren gebruikers geen verschil meer zien tussen (1) en (2).

Effectief blijven er dus maar 2 bruikbare soorten certificaten over:
(1)/(2) - verschil niet te zien
(3) - EV certificaten

Voor huis-tuin-en-keuken toepassingen is een DV certificaat wellicht goed genoeg, maar door het feit dat ze bestaan en zo eenvoudig afgegeven worden, hebben ook kritische toepassingen er last van. De algemeen bekende uitleg:
klopt om allerlei redenen niet meer. Het grootste probleem daarbij is dat het veel te eenvoudig is om een DV certificaat voor een nepsite te verkrijgen. Dat heb niet alleen ik al eerder geroepen, maar door het incident in Brazilië is dit in de praktijk bevestigd. Voorbeeld: als ik op een up-to-date IPad met Safari https://www.digid.nl/ open, kan ik met geen mogelijkheid meer vaststellen dat ik op de echte DigiD site zit doordat ik het certificaat niet kan bekijken. MS Edge vervangt "https://www.digid.nl/" gemakshalve door "digid.nl". Zie ook [4] voor Chrome (waarbij in elk geval de Windows versie nog wel een certificaat kan laten zien als je op F12 drukt - maar dat lijkt me niet bedoeld voor de gemiddelde gebruiker laat staan noobs).

Conclusies
(A) Spoofers kunnen kiezen: een lijkt-op domainname of DNS/routering/beheer e-mail account hacken, en een gewoon DV (e-mail) of Let's Encrypt certificaat aanvragen, wat hun het beste uitkomt. Met als gevolg dat DV certificaten m.i. onvoldoende betrouwbaar zijn voor het uitwisselen van vertrouwelijke gegevens;
(B) Doordat je gewone certificaten niet van DV certificaten kunt onderscheiden, zijn sites met gewone certificaten net zo makkelijk te spoofen als sites met DV certificaten;
(C) Daardoor zijn verbindingen naar sites met alle non-EV certificaten onvoldoende veilig om gebruikersnaam + wachtwoord en/of andere vertrouwelijke gegevens te transporteren. Browsers zouden een rode streep door https moeten zetten op het moment dat een site zonder EV certificaat je om inloggegevens vraagt (ik vind het dan ook onbegrijpelijk dat notabene de DigiD site nog steeds geen EV certificaat heeft);
(D) Zolang browsers dit niet doen moeten gebruikers leren erop te letten dat ze geen vertrouwelijke gegevens afstaan aan sites die geen EV-certificaat hebben. Eigenlijk zouden we allemaal moeten weigeren om belastingaangifte te doen!

Vroeger of later zul je (C) hierboven geïmplementeerd zien worden (de afgedwongen overgang van http naar https werd ook door velen weggehoond). Wen maar vast aan het idee!

[1] https://www.security.nl/posting/422488/XS4ALL-klant+krijgt+certificaat+xs4all_nl+via+e-mailverzoek
[2] Zie "Possible hijack" in https://bgpstream.com/, bijv. https://bgpstream.com/event/78126 (bron: http://seclists.org/nanog/2017/Apr/0)
[3] https://www.security.nl/posting/508472/Let%27s+Encrypt+geeft+15_000+certificaten+uit+voor+PayPal-phishing
[4] https://www.security.nl/posting/510112/Beveiligingsbedrijf+hekelt+%22Veilig%22+melding+in+Chrome

Ja en die hoon ik nog steeds weg want de hele bovenstaande issue wordt veroorzaakt door devaluatie van begrippen
als veiligheid. Mensen wordt eerst geleerd dat http gewoon is en https (slotje) veilig, en dan vervolgens gaat een
stel idioten de hele basis onder dat https wegzagen en ook nog eens uitdragen dat alles https moet zijn (met als
gevolg dat er heel veel certificaten nodig zijn en de validatie daarvan alleen al daardoor nog weer slechter wordt).

Wat er in feite gedaan is, is iets wat eerst wel aardig te vertrouwen was nu te degraderen tot hetzelfde als niet
secure verbinding, met name op het gebied van identificatie van de tegenpartij, maar als gevolg daarvan eigenlijk
ook voor de veiligheid van de verbinding. (als je niet kunt vaststellen met wie je communiceert kun je ook niet
veilig gegevens verzenden zelfs als zijn ze encrypted)

Slechte zaak dus, vooral aangestuurd door kortzichtigheid en niet met een blik op het totaalplaatje.

De devaluatie is niet van het begrip veiligheid maar van de (praktische) veiligheid van HTTP. De idioten die de basis daaronder hebben weggezaagd zijn niet degenen die nu zeggen dat HTTPS overal nodig is maar degenen die daadwerkelijk massaal dataverkeer gingen besnuffelen, NSA voorop. Het advies om alleen nog HTTPS te gebruiken is een reactie daarop. Je schiet de boodschapper af en ziet het eigenlijke probleem over het hoofd.

@Anoniem van 11:31

Wel, je raakt daar wel een "open" zenuw, zeg. We zijn dus met het uitrollen van "extra" veiligheid in feite allemaal flink wat onveiliger geworden of in het gunstige geval niet veel opgeschoten. Men beoogt de status-quo zo lang mogelijk vast te houden ten koste van alles. Langley & Frankfurt spooks monitoren de hele kaboodle.

Je bent wel goed wakker, wat betreft een paar algemene verschijnselen, waardoor de eindgebruiker constant op het verkeerde been gezet wordt, waar het gaat om de veiligheid van de algemene infrastructuur.

Waar heb ik DNSSEC met een netjes verborgen geheime sleutel voor? Waar is DNSmasq uitgerold? Waar tonen naamservers nog allemaal excessieve info proliferatie? Waar wordt veilger verbinding bedoeld i.p.v. site (client-server) veiligheid. e2e "tot de deur" en zoek het dan maar uit, of betaal 12x meer, dan heb je "IDF status" beveiliging.

Ook met je helemaal eens, dat het spel om ieder, die niet van de hoed en de rand weet, op het verkeerde been te zetten ingezet lijkt door de belangen van "Data Graai en Grabbel van Big Commerce, hand in voet met de Overheid" & "Snuf en Snuitje's Cybercrime Circus". Het is bijna voor de gewone man niet meer te ontwijken, de opgelegde ellende dan.

Ga eens naar HTTPS:Everywhere encyclopedie en zie de litanie aan narigheid daar eens aan. Doe eens een certificaat crypto scan. Root-certificaatjes alom. Of kijk hier eens: https://observatory.mozilla.org/

Af en toe rijzen je de haren ten berge....

luntrus

Waarom het anders moet?
https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/

Zonder handen! Eh, zonder DNS!
https://blog.torproject.org/blog/cooking-onions-names-your-onions

Wat betreft de oorlog tegen EFF
Jarenlang hebben veel commerciële partijen bakken met geld verdiend aan een systeem waarvan bekend was welke nadelen het had.
Om nu een idealistische partij in een zucht van aanhoudende wraakoefening eruit te pakken omdat zij binnen dat zelfde systeem gratis certificaten verstrekken en er geen bakken met geld aan willen verdienen is absurd.
Een zeer ongeloofwaardige aanhoudende excuus exercitie waarbij de vraag steeds meer komt bovendrijven uit welk belang er een oorlogje wordt gevoerd tegen één partij.

Nogal schijnheilig om wanneer het verdienmodel wordt ondergraven door een idealistische partij die e.e.a. gratis gaat aanbieden ineens te gaan roeptoeteren dat het allemaal securitykut is en niet meer zo moet.
Dat riekt naar impliciet commercieel protest om de concurrent een loer te kunnen draaien.
Maar bij herhaling propageren dat iedereen aan een e.v. cert moet is niet haalbaar bij hoge prijzen in de markt en dus onzinnig, alsook het selectief zwartmaken van een idealistische partij die er op zich niets aan kan doen dat er nadelen bestaan bij dit dv systeem.

Tenzij er de mogelijkheid bestaat ook gratis EV certificaten te gaan verstrekken.
Geen gek idee wellicht om de idiote prijzengekte bij ev certificaten een halt toe te roepen.
Veiligheid hoort er voor iedereen te zijn, niet alleen voor de partijen met de vetste potomonnee.

Hoe lek is LEK eigenlijk nog meer?
Een willekeurige overheidstoeleverancier in Nederland vluchtig bekeken
Opvallende zaken bij de websites van dat bedrijf

Is dit onveilig?
GEEN Extended Validation Certificate
Betreft een WORDPRESS site
Yoast SEO plugin niet up to date
Mitm-er Cloudflare doet mee
Mozilla observatory geeft een algehele ssl beoordeling score GRADE F
Oude Adobe Illustrator 17.0.0 in bedrijf voor de svg plaatjes

Wie weet wat er echt gevonden wordt als mensen met verstand van zaken echt gaan zoeken op.
Uit goede bron vernomen, gelukkig maar dat er voldoende kennis bij dat bedrijf intern aanwezig is om tenminste dat zichtbare achterstallige werk netjes op te lossen.
Goed voorbeeld doet hopelijk dan ook bij de overheid goed volgen.
Maar buiten die voorbeeldfunctie zouden sommige organisaties en zeker toeleveranciers van belangrijke overheidsdiensten eerst alles in het werk moeten stellen om bijvoorbeeld Watering hole attacks te voorkomen, je zou denken dat geen maatregel dan teveel is.
https://en.wikipedia.org/wiki/Watering_hole_attack
Hopelijk gaat men daar gauw dat ontbrekende Extended Validation Certificate aanvragen en installeren en patchen waar nodig.

Vingers aan de pols samen met de bezoekende afnemers van de 'best wel belangrijke producten' waar twijfel geen plaats mag hebben. Iemand huldigde hier namelijk recent nog de opvatting dat goede security soms wat extra investering vraagt die je niet mag laten liggen. Dat ging, je raadt het al, over de aanschaf van een Extended Validation Certificate op naam van het bedrijf. En daar had hij wel een punt.
Hopelijk gaan ze er daar snel mee aan de slag.
Tenminste voor 2 domeinen benodigd, doen hoor! Anders blijft het alleen bij graag praten, praatjes vullen echter geen security gaatjes.

+1

Hangt er van af. Als je er niet op in hoeft te loggen (om bestellingen te doen ofzo) of er geen valse info op staat die je geld kan kosten is het risico beperkt.

Van security.nl heb ik een bookmark in me browser (naar https://www.security.nl/) en ik krijg geen mails met links naar een naam die lijkt op security.nl en als ik die wel kreeg zou ik er niet op klikken. Als de DNS van security.nl gehackd wordt (zoals TS schrijft voor een bank) kunnen ze een letsencrypt certificaat op een cloudserver ergens zetten en zie je niet dat je op de nepsite zit. Van mensen die hier wel inloggen (anoniem is veilig ;-) hebben ze dan de wachtwoorden. Ook kunnen ze malware proberen te geven (nep flash player update of zo maar mensen die naar security.nl komen trappen daar niet zo snel in) er valt dus denk ik niet veel geld mee te verdienen. Kleine kans dus maar niet nul.

Voor een website met een login of zo waar je wapens kunt bestellen of waar rekeningnummers op staan waar de overheid betalingen naar moet doen na vette orders of banken is het wel een andere verhaal.

Het EV certificaat wordt weergeven als een site dat aanschaft. DNSSEC zie je niet wie kan mij vertellen wat er gebeurd als de DNS Security.nl gekaapt wordt. Is het dan zo dat de DNS resolver automatisch het niet het gekaapte teruggeeft maar die van de originele site of dat het gewoonweg stopt omdat er geen IP nummer terugkomt?

@ anoniem van 12:10

Ja de DNSSEC reflectie aanval: http://www.securitynewspaper.com/2016/08/22/around-four-five-dnssec-servers-can-hijacked-ddos-attacks/

Ga i.g.v. MKB dan eens kijken bij de nationale wasstraat!

Inzet op slechte security websites is lucratief voor cybercriminelen en voor de overheidsspooks (17 geheime Cheltenham directieven voor Telecom providers, sinds 2001, en waaraan de providers geen enkele ruchtbaarheid mogen geven en ik vermoed dat het in Nederland niet anders werkt als in het V.K.).

Het meeste wat er missgaat voor websites en op hosters of op CDN's valt te wijten aan onkunde of komt door lamlendigheid en misplaatst vertrouwen inde "3rd party oplossing aka de cloud zal het wel oplossen" wensdenken, de bulkhoster is te vertouwen". Niet redeneren: "Heb ik het wel goed geconfigureerd. Heb ik wel sri-hashes gegenereerd. Heb ik wel A+ of A status en geen B, F of X.?".

Lopen mijn webservers en naamservers niet te luid te "mauwen", zodat iemand direct kan afleiden waar ik mogelijk kwetsbaar voor ben. Loop ik geen kans op Cloudbleed van de basis omhoog. Zijn mijn naamserver versies zichtbaar? Heb ik oude meuk als code lopen, die vervangen moet worden (jQuery bijvoorbeeld) of zelfs door de developer verlaten code etc.?

Hoe zit het met security headers? Hoe zit het met mijn input-outbut validatie, nonces? Heb ik last van CloudFlare -, GoDaddy, Akamai etc. ellende?

Doe eens een scannetje hier: https://observatory.mozilla.org/analyze.html?host=www.zettchina.com
Hier: http://retire.insecurity.today/#!/scan/0beee4d687fe719690d4ae79d546e264c3bd565576666d8111b61083a11a932e
Hier: https://aw-snap.info/file-viewer/?protocol=not-secure&tgt=www.zettchina.com%2Fes&ref_sel=GSP2&ua_sel=ff&fs=1
Hier: http://face-products.com/modules/bothoi/index.php (random voorbeeld)

Lees ik
Ben ik kwetsbaar voor clickjacking. Is er sprake van cloaking? (Google bot krijgt heel wat anders voorgeschoteld als de web client).

Check eens met RECX Security Analyser wat er qua "best practices' zou kunnen en hoeverre ik daar aan moet voldoen en kan voldoen want niet alle software laat het toe.

En dan is er nog een heleboel meer na te trekken. Maar men moet ergens een begin maken, School uw mensen bij!
Maak ze alert! Laat je CEO dit lezen en trek hem of haar over de streep ondanks haat communicatie en managment gewauwel over risk management en reputation managment and stakeholders etc. etc.

"Praatjes vullen geen beveiligingsgaatjes, mijnheer/mevrouw!".

luntrus

De link je geeft is dat 1 op de 5 DNSSEC servers misbruikt kunnen worden als DDOS wapen. Dit ook gemakkelijk te voorkomen door een bepaald soort aanvragen niet in behandeling te nemen.

Mijn vraag was een andere.

Wat weer parten kan spelen hier is misconfiguratie.

De volgende toegevoegingen aan DNSSEC moeten daarbij in orde zijn:

RRSIG – Bevat een cryptografische handtekening
DNSKEY – Bevat een publieke ondertekeningssleutel
DS – Bevat de hash van het DNSKEY record
NSEC and NSEC3 – Bij expliciet denial van het bestaan van het DNS record
CDNSKEY and CDS – Voor een child zone requesting update naar de DS record(s) in de parent zone.

Steeds wordt daarbij het validatieproces herhaald.

We moeten alleen kunnen rekenen op de lieden van ICANN, die de root zones signeren.
Daar draait het bij de hele trust chain om.

Als het echt gekaapt is, krijg je het gekaapte terug, d.w.z.: meestal het IP-adres van een andere server, die bijv. malware serveert. Maar kapen van de grote DNS servers gebeurt zeer zelden.
Meestal kaapt men een lokale DNS. Thuisrouters zijn populair, omdat ze nog vaak kwetsbaarheden bevatten,
of slechte instellingen hebben. I.c.m. standaard routerwachtwoord of zwak routerwachtwoord is dat vragen om problemen.

Beetje een klok en klepel verhaal. Je kunt iedere certificeringsinstantie om de tuin leiden als je de DNS van een domein kaapt. Het is dan redelijk eenvoudig om websites en e-mail naar je eigen servers te laten verwijzen. En waar controleert een certificeringsinstantie doorgaans mee? Juist, door een email naar mailboxen als postmaster@domein te versturen of door bestanden op webservers te laten plaatsen. Doordat je als aanvaller beide naar je eigen servers kunt laten verwijzen is het dus relatief eenvoudig om zo een certificaat te bemachtigen.
Ligt dit dan aan LetsEncrypt? Nee, absoluut niet. Waar het wel aan ligt is de bank die kennelijk niet goed om gaat met credentials en zo dus de beheercredentials van de DNS server lekken. Dat is domheid waar geen certificeringsinstantie of zelfs een techniek als DNSSEC tegenop kan.

Nee, niet iedere.

INDERDAAD kun je certificeringsinstanties die DV certificaten uitgeven (Let's Encrypt certificaten zijn ook DV certificaten) "om de tuin leiden als je de DNS van een domein kaapt". Exact om die reden voegen DV-certificaten nauwelijks tot niets toe aan de onbetrouwbaarheid van DNS.

Maar dit geldt NIET voor certificeringsinstanties die ANDERE dan DV certificaten uitgeven (waaronder non-EV PKIoverheid certificaten)!

Server (SSL/TLS) certificaten waren oorspronkelijk juist bedoeld om niet afhankelijk te zijn van DNS en van de routering van IP pakketjes. En daarnaast (dus aanvullend) was de insteek dat certificaten zekerheid zouden bieden over de organisatie achter de server waar jouw webbrowser mee communiceert.

Beide aspecten zijn compleet om zeep geholpen door uitgevers van DV certificaten (gedreven door naïeve klanten die voor een kwartje of minder op de eerste rij willen zitten) en door de makers van webbrowsers, die informatie over de organisatie achter een domeinnaam -helaas- steeds minder (in plaats van juist meer) toegankelijk maken voor eindgebruikers (wellicht omdat DV certificaten technisch lastig tot geheel niet van andere non-EV certificaten te onderscheiden zijn, maar vermoedelijk ook omwille van de vereenvoudiging van gebruikerinterfaces en om kleinere portable devices te kunnen ondersteunen).

Om het anders te stellen: ALS DNS en end-to-end routering altijd 100% betrouwbaar zouden zijn en als ook leken uit elke domeinnaam zouden kunnen opmaken van welke organisatie de server met die domeinnaam is [*], had TLS helemaal geen certificaten nodig. Want om een webbrowser en een server veilig (over een nog onversleuteld, dus afluisterbaar) kanaal een symmetrische sleutel te laten overeenkomen waarmee de rest van de sessie word versleuteld (zodat afluisteren niet mogelijk is), wordt tegenwoordig ook geen certificaat meer gebruikt. Best current practice (i.v.m. forward secrecy) is namelijk om daar de Diffie-Hellmann key agreement voor in te zetten - waar, zoals gezegd, geen certificaat bij aan te pas komt.

[*] Zoals wel het geval is bijvoorbeeld bij security.nl, maar niet bijvoorbeeld bij ics.nl (die niets met ICS Cards te maken heeft) of bij digi-d.nl (die niets met digid.nl te maken heeft).

Hoe naïef kun je dan zijn om te stellen dat DV-certificaten nog enige waarde hebben. Terwijl ze in de praktijk vooral een vals gevoel van veiligheid geven, "geholpen" door crappy browsers die ook "secure" tonen bij 15000 op Paypal lijkende nepsites met Let's Encrypt certificaten.

Toegegeven, er gaan ook dingen mis met "betere" certificaten, en daar moeten we bovenop zitten - maar iets beters hebben we nou eenmaal niet. Slechter wel; bij mijn weten zijn er geen 15000 non-DV certificaten uitgegeven voor nep Paypal sites of andere banken.

Verdiep je eens in nonrepudiation of droom lekker verder met je gratis speelgoedcertificaatjes.

De markt bepaalt, de klant volgt en kiest hooguit

Het is onzin de klant te verwijten voor een dubbeltje op de eerste rang te willen zitten.
De klant kan alleen kiezen uit het aanbod en dat goedkoopste dubbeltje is heel relatief.
Want waarom nu ineens EFF de schuld geven van alles omdat het dubbeltje een dubbeltje is geworden nadat het dubbeltje een geeltje was?

Er spelen twee problemen.

1) Een overcommerciële markt die prijzen rekent voor producten die niet gerelateerd zijn aan de kostprijs maar aan wat de gek ervoor geeft en winstmaximalisatie.

Certificaatbeheer en uitgifte met controle lijkt me een nogal administratieve kwestie dat heel goed op basis van uurloon en personeelskosten voor een redelijk tarief valt aan te bieden.

Als je bijvoorbeeld kijkt naar de uitgifte van e.v. certificaten en de werkelijk idioot hoge verschillen tussen verschillende merkjes en aanbieders en achterlijk hoge prijzen van de duurste in de markt (Symantec) dan is de aanname van een volledig uit de hand gelopen commerciële markt heel dichtbij.

Het is absurd om bij een volkomen uit de hand lopende commerciële markt degenen zwart te maken die daartegenin gaan en producten voor een fair prijs gaan aanbieden.

Wees eerlijk en kijk naar wat er zich afspeelde voordat goedkope aanbieders zich met deze markt gingen bemoeien.
De schuld ligt bij de aanjagers binnen een vercommercialiserende markt zelf.
Dat is een pest want maakt security alleen beschikbaar voor een elite, de elite met voldoende cash op zak.

Security hoort geen kwestie te zijn van de elite met voldoende geld.


2) Iets anders dan een fair prijs berekenen voor werkelijk gemaakte (faire) kosten aan administratiekosten is de kwaliteit van je product.

Uit je verhaal valt op te maken dat er technisch iets fout gaat, dat er in dit controle en implementatie proces essentiële stappen worden overgeslagen.
Net zoals bij software dat periodiek gaten vertoont en gepatcht dient te worden zou je datzelfde idee kunnen toepasen op certificaatverstrekking: mankementen aan het producten dienen te worden gerepareerd.

Het lastige is natuurlijk dat de markt van dv certificaten groot is en het daarom een onbegonnen zaak lijkt dit aan te kaarten, waar moet je beginnen?
Nou, misschien niet op dit forum.
Dat is wel zeker.

Maar zoek een grote aanbieder van die certificaten die invloed kan hebben.
En hee, die is er ook!
In plaats van in navolging van de gevlogen stenenbakker een ideële organisatie proberen zwart te maken kan je ook iets heel veel constructievers doen met de specifieke inhoudelijke kennis / inzichten die je hebt / schijnt te hebben

Namelijk, EFF benaderen en ze er in een redelijk en begrijpelijk uitgebreid stuk erop wijzen waar hun product mankementen vertoont en welk gevaar dat voor de algehele markt oplevert.

Want kennelijk moet er wat gerepareerd worden in die wijze van verstrekking.
Mits het verhaal positief inzichtelijk en goed 'verkocht', namelijk in de vorm van kansen die men zou moeten grijpen, heeft dat dus voordelen.

Voordelen voor EFF, want het is het doel van die organisatie SSL voor een breed publiek mogelijk te maken en niet iets aan te bieden dat ze tegelijkertijd mede helpt stuk te maken (als ik je verhaal goed genoeg begrijp).
Het aardige is dat EFF een grote speler is geworden en dus veel positiefs in die markt kan betekenen door haar product spoedig te gaan verbeteren.

Dat kan dan misschien betekenen dat het niet meer gratis kan omdat de administratie en beheer ervan toch kosten met zich meebrengt, maar dat zal dan altijd nog heel veel lager en aantrekkelijker zijn en kunnen dan de rattenprijzen die een rattenmarkt zichzelf toerekent en toe-eigent.
En daar was het EFF waarschijnlijk om te doen, een uit de hand gelopen commerciële markt voor en van de elite openbreken door gratis tegenover absurde prijsstellingen te zetten.

Wat jij dus beter kan doen (als je niet ook de stenenbakker bent die tot over zijn oren in dat andere systeem zit) is EFF benaderen in plaats van hier te klagen en zwart te maken.

EFF uitleggen hoe het technisch goed hoort te werken en waarom EFF daar nog niet zit.
Leg uit dat eventuele kosten misschien het model van geheel gratis in de weg staan maar dat het zou kunnen opleveren een sterker en betrouwbaarder imago.
Want een gemankeerd product aanbieden (als het waar is wat je zegt) is natuurlijk inderdaad slecht voor je imago (tenzij niemand begrijpt en geïnteresseerd is waarom het product niet optimaal functioneert).

Op deze manier stel je EFF is staat zowel haar 'openbreek functie' te behouden alswel de extra kans te grijpen weer iets goed neer te zetten in die DV markt en zich van de rest die dat niet doet te onderscheiden.

Afzeiken van een ideële organisatie met halve argumenten op een securityforum in een of ander mini ruk landje, ja nee, daar ga je niets mee bereiken.
Behalve je eigen superieure inzichten gelijkje (totdat je op je eigen 'nivo' wordt tegengesproken).

Dus: ga iets positiefs doen en gebruik je kennis om EFF ervan te overtuigen dat ze enorme kansen laten liggen bij een imago dat kans loopt op beschadiging, kansen laten liggen bij een product dat nog niet goed genoeg is, kansen laten liggen om werkelijk goede en betaalbare security laten liggen voor de massa.

Laat daarbij je oordeel over de inhoud van de portemonnee van anderen weg, geloof me, er zijn heel veel mensen en organisaties met een relatief lege portemonnee.
Verwijt 'de armen' niet dat ze kiezen voor budget oplossingen, dat is idioot omdat ze nou eenmaal niet de elite prijzen (zie e.v. certificaten) kunnen ophoesten om de overvolle kassen van een obsceen commerciële securityindustrie kunnen en willen spekken.

Succes met je constructieve schrijven aan EFF.

(ja, ik weet dat ik de prijzen van dv en e.v. certificaten wat gechargeerd en scheef met elkaar heb vergeleken maar dan nog mag duidelijk zijn dat in veel gevallen de relatie tussen redelijke kostprijs en vraagprijs volstrekt zoek lijkt. Dat mag, dat is de vrijheid van de vrije markt, maar mag ook in alle vrijheid ter discussie gesteld worden, en dat laatste gebeurt veel te weinig.
Degenen die rattencommercie wel ter discussie stellen affakkelen is begrijpelijk vanuit commercieel eigenbelang maar allerminst redelijk, en daar ging het nou juist om: security voor iedereen en niet alleen voor de elite.

Kennelijk moet daar nog een corrigerende verbeterende kwaliteit verhogende balans in komen, werk daaraan in plaats van eenzijdig partijen af te schieten: dat is nihilisme en of commerciële hypocrisie ten top!)

Wat een woorden.
De werkelijke fout is dat deze banken geen EV-certificaat hadden, of anders hebben klanten daar niet op gelet.
Daarbij had HSTS (certificate pinning!) dit drama grotendeels kunnen voorkomen.

De Conclusie moet zijn dat veel banken in die regio de veiligheid van hun website niet goed op orde hebben.
Daarbij is de toezichthouder in die regio waarschijnlijk veel te laks.

Zie ook: https://www.security.nl/posting/511396/TLS+1_0+toch+nog+steeds+veilig%3F
Daar zien we iets dergelijks. En de PCI Security Council vind het wel best.
Maar dan is er geen redundantie. Het werkt allemaal nog maar net een beetje veilig.
Eén foutje, één onvoorziene hack of kwetsbaarheid en men is al snel onherroepelijk de klos.

Dát is voornamelijk wat we uit beide topics moeten concluderen.

Hier ben ik het niet mee eens, er bestaan maar 2 soorten (voor webservers): DV en EV. Een verschil tussen (1) en (2) is niet relevant en ook nooit geweest. Hoogstens kan de kwaliteit van de uitgever van een DV-certificaat als relevant worden gezien, maar deze kwaliteit kan een buitenstaander sowieso niet controleren en is daarom zeer beperkt bruikbaar.

Waar velen aan voorbij gaan, is het doel van DV-certificaten en "alles HTTPS". HTTPS met DV-certificaten beschermt tegen passieve aanvallers, zoals andere gebruikers van een open WiFi-netwerk en (deels) sleepnetten van veiligheidsdiensten. Daarnaast is een DV-certificaat voor aktieve aanvallers een extra drempel en beschermt bijvoorbeeld tegen ad injection door ISPs en diezelfde andere gebruikers van een open WiFi-netwerk.

Tegen veiligheidsdiensten en andere partijen met veel geld die jou als doelwit hebben, zal een DV-certificaat slechts een klein drempeltje zijn. Een EV-certificaat is een grotere drempel, mits de gebruiker a) überhaupt weet dat er een verschil tussen DV- en EV-certicaten is, b) weet dat een bepaald domein een EV-certificaat heeft, c) bij elk gebruik van dit domein controleert, dat er een EV-certificaat wordt geleverd. Maar eerlijk gezegd zou ik als aanvaller een andere weg inslaan (bijv. spear phishing, 0-days of 1-days), omdat de kans op ontdekking vele malen kleiner is en ik dan controle over het hele systeem heb ipv. 1 enkele verbinding met 1 enkel system op 1 enkel moment.

Dat ben ik met je eens. En dat webbrowsers het ook steeds moeilijker tot onmogelijk maken om het certificaat te zien, is natuurlijk een kwalijke zaak. En ook de melding "veilig" in Chrome is wat mij betreft een stap in de verkeerde richting, omdat het voor een leek niet duidelijk is, dat dit enkel betrekking op de verbinding heeft en zelfs daar nog haken en ogen zijn.

Al met al maken goedkope/gratis DV-certificaten en "alles HTTPS" het Internet wel degelijk veiliger, met name tegen passieve aanvallers. Het is echter geen panacee dat alle problemen op het web oplost, maar dat beweren EFF, Let's Encrypt, etc. ook niet.

Er zijn wel 3 soorten certificaten: Domain Validation (DV), Organization Validation (OV) en Extended Validation (EV)

Als je het certificaat niet kunt bekijken (of niet bekijkt), zie je in webbrowsers geen verschil tussen OV (inclusief onder zeer strikte voorwaarden uitgegeven PKIoverheid) en DV

Als DV niet veiliger is dan DNS, is OV dat dus ook niet meer (omdat je het verschil niet ziet)

Overigens gebruikt rijksoverheid.nl al wel een PKIoverheid EV cert terwijl bijv. zeist.nl een Comodo EV cert heeft.

Correctie, rijksoverheid.nl heeft wel EV maar niet PKIoverheid (wel van QuoVadis die ook PKIoverheid certs uitgeeft)

Voor zichtbare "verschil" (geen dus) OV en DV zie bijv. https://security.stackexchange.com/questions/35076/how-does-an-end-user-differentiate-between-ov-and-dv-certificates

Die link geeft heel veel tekst om dan te concluderen dat er maar één verschil is wat soms wel en soms niet aanwezig is. Om andere het lezen te besparen:


Het wel/niet aanwezig zijn van organisatie info zegt niet dat er op gecontroleerd is. En die policy identifier is er inderdaad niet altijd. Bij de site uit je link wel, en ook het security.nl certificaat, doet er uitspraak over. Beide OV volgens de code van de verstrekker.
Let's Encrypt vermeld via deze code in het certificaat dat het DV is.

Het is in elk geval geen verschil dat de leek zal herkennen.

Dat HTTPS Everywhere en de certificering a la Let's Encrypt met de juiste beveiligingsaanbevelingen veel waardevoller zouden worden voor algemeen gebruik, daar sta ik helemaal achter en is een goede analyse van de situatie door bovenstaande posters.

Wat vinden de posters in deze overigens bijzonder interessante draad van het recente elkander van onveiligheid beschuldigen van Google en Symantec( vice versa). Symantec, die je nou niet bepaald voor een dubbeltje op de eerste rang laat zitten. Is het hier niet de pot, die de ketel verwijt, dat ie zwart ziet? Ook Google die zich graag als full development organisatie profileert.

Trouwens ik zie nog legio certificaten die niet goed zijn geconfigureerd en als 'root', geen "best practices".. Dan denk ik bij mezelf, is zelfs dat niet doorgedrongen. We hebben nog een lange weg te gaan, lieve mensen hier. Een ieder nog bedankt voor de bijdragen aan deze levendige discussie. Nederland beveiligingsland. Het is schatplichtig aan u allen, besef dat wel.

luntrus