Privacy is niet echt een probleem wanneer het een minuut wachten is voordat een browser de onmogelijke zoektocht opgeeft en eindelijk content begint te tonen - ware het niet dat de surfer als z.g.a. minuut daarvoor verder gegaan was met zijn/haar leven.

Corrigeer dat dus maar naar "welke websites iemand had willen bezoeken".

Theoretisch was correct configureren te moeilijk, en in de praktijk helemaal,
hetgeen overeenkomt met de aanvankelijke inschatting van deze feature.
Gaat geen groot gemis zijn.

En langzaam aan schuiven we meer richting DANE.

Jammer dat OCSP Stapling door webservers nooit echt van de grond gekomen is. Als de webserver een ondertekende OCSP response in cache heeft, is er geen sprake van een privacy probleem. Caddy bijvoobreeld ondersteunt dit wel.

Browsers hadden een tussenoplossing kunnen bieden. Zolang het certificaat niet gecontroleerd kan worden, kun je niet inloggen met wachtwoorden of formulieren invullen.

Browsen kan dan nog wel en in de URL balk wordt dan aangeven dat je in een beperkte mode zit.

Echte digibeten weten dit natuurlijk allemaal wel en regelen hun eigen certificaten.
De rest moet even naar de bibliotheek om hulp te vragen.

Wat betekent z.g.a.? Ik kan het niet vinden in woordenboeken, en ik neem aan dat Zorggroep Almere, Zorggroep Apeldoorn en Zorggroep Achterhoek ook niet zijn wat je bedoelt.

Mag zelf even naar bibliotheek als je denkt dat digibeet betekend digitale kennis van zaken haha.
Je draait het net verkeerd. Digibeet is iemand die niks snapt van digitale zaken.
Kan gebeuren uiteraard ik draai ook stuff zo vaak om als ik te weinig caffeine heb.

Maar eigen certificaat uitrol is ook niet bepaald iets dat uberhaubt mensen met kennis doen enkel professionals die het moeten vanuit regels, standaard en een handje aan zelfstandigen. En dan beperkt het zich ook nog vaak tot TLS certs met geen weet van gebruikte cipher suites.

Certificate management is hoe dan ook een regelrechte ramp omdat ze altijd standaard spul vertrouwen en je overzicht dus echt een zooi is from the start. Snap waarom ze het doen uiteraard maar mijn hemel wat een troep.

En zo gaat de afbraak verder. Let's Encrypt geeft voornamelijk certificaten uit voor criminele websites en heeft ook geen zin om die in te trekken. Sterker, aan bij herhaling uitsluitend voor criminele doeleinden gebruikte webservers, blijft zij enorme aantallen certificaten afgeven (vaak vragen de eigenaren vele certificaten per maand aan bij dezelfde én bij andere verstrekkers van gratis DV-certificaten).

Uitsluitend Let's Encrypt:
• https://www.virustotal.com/gui/ip-address/91.215.85.79/relations
• https://www.virustotal.com/gui/ip-address/91.215.85.16/relations

Vooral nep US Postal Services:
https://crt.sh/?Identity=usps

Zoekplaatje: nep en echte DHL door elkaar (beperkt tot nog geldige certs):
https://crt.sh/?Identity=dhl&exclude=expired

Onbeperkt eten - voor nop (nep "pakket niet bezorgd" junk):
https://crt.sh/?q=post-helpen.com

De meeste zijn nepsites (en het zijn er VEEL, meestal krijg je een timeout):
• https://crt.sh/?Identity=.bond&exclude=expired
• https://crt.sh/?Identity=.space&exclude=expired
• https://crt.sh/?Identity=.top&exclude=expired

In China zijn goksites verboden en worden domeinnamen geblokkeerd. Fix: registreer voortdurend nieuwe domeinnamen en vraag daar certificaten voor aan (zie de lijst onder "X509v3 Subject Alternative Name"): https://crt.sh/?id=13053559801

Klik in https://www.virustotal.com/gui/ip-address/188.114.96.0/relations (Cloudflare) een paar keer op ••• onder "Passive DNS Replication (200)" totdat je links rood ziet, dan heeft de domeinnaam rechts in bijna alle gevallen een DV certificaat (te zien, nadat je op zo'n domeinnaam hebt geklikt, door het "Details" tabblad te openen).

Het is één grote criminele bende - waar Big Tech vet aan meeverdient.

Aanvulling 11:56, reactie op de tekst bovenaan:
Dat eerste is een schandalige leugen die maar herhaald blijft worden, en de resr van de zin is, strikt genomen en relevant voor een security site, ook fout:

1) TLS certificaten hebben, bij het (sterk aanbevolen) gebruik van Forward Secrecy, volstrekt NIETS te maken met de versleutelde verbinding.

De naam Let's Encrypt is pure misleiding.

Bewijs: bij TLS v1.3 wordt eerst de versleutelde verbinding tot stand gebracht. Pas daarna verstuurt de server diens certificaat naar de client - plus bewijs van bezit van de private key - die één-op-één past bij de public key in het certificaat.

2) Het doel van certificaten is niet het identificeren van een entiteit, maar het aantonen dat het gaat om de gegeven identiteit. Dat noemen mensen, die iets snappen van security, authenticatie; niet identificatie.

De identiteit, in dit geval een doneinnaam, wordt volledig bepaald door de gebruiker van de browser - door een domeinnaam in te voeren of door op een link te klikken.

Voorts:
Niet als je in jouw browser instelt dat de verbinding met de website geblokkeerd moet worden als er geen antwoord komt op een OCSP-request.

We zijn gestopt met CRL's omdat die niet schalen; die lijsten kunnen veel te lang worden.

Bullshit. Autoriteiten hebben allang veel betrouwbaarder methodes om te zien wie waneer welke website bezoekt (dit licht ik desgewenst toe).

RIGHT. Het is een pure bezuinigingsmaatregel ingedekt met wollige leugens.

Dit is wat mij betreft ook het grootste probleem met OCSP. Of je CA's überhaupt kan vertrouwen is al een lastige kwestie, en dan ga je ze ook nog voeden met wie wanneer welke website bezoekt.
Volgens mij was voor dit probleem toch OCSP stapling bedacht?

Ik ben blij dat ik mijn certificaten automatisch gratis kan verlengen en nee ik ben geen crimineel. U werkt voor een dure certificaten uitgever?

De term "digibeet" wordt meestal gebruikt voor mensen zonder verstand van digitale zaken. Eigenlijk zou "adigibeet" een betere aanduiding zijn (vergelijk "atechnisch"). Wat wordt hier nu bedoeld?

Een certificaat beschermt wel tegen MITM (Man In The Middle), maar niet tegen CATE (Criminal At The End).

Geen ocsp? Niet acceptabel. Is er inmiddels een alternatief voor Let's Encrypt?


O ja? Een certificaat beschermd niet zonder meer tegen MitM. Een MitM kan een eigen certificaat laten maken. Dat is juist het probleem van MitM.

Inderdaad. Ook ik heb al mijn (privé) websites met Let's Encrypt certificaten gehost. Sites zijn misschien crimineel slecht van layout, maar weinig crimineel in de zin die u waarschijnlijk bedoelt. Dat virustotal een opsomming van sites geeft met uitsluitend Let's Encrypt certificaten wil natuurlijk niet zeggen dat Let's Encrypt daarom alleen crimineel gebruikt wordt...

Het is ook helemaal niet de taak van een certificaatautoriteit om dat te controleren. Een certificaat bewijst dat de gebruikte encryptiesleutels horen bij de domeinhouder, niets meer en niets minder. Net als dat een paspoort ook niet bewijst dat je te vertrouwen bent. En dat een bakker ook niet gaat checken of hij brood aan criminelen verkoopt.

Hoe zouden certificaatautoriteiten ook moeten vaststellen dat ik geen "crimineel" ben? Wil je dat ze verplicht een KYC-proces en klantenonderzoek moeten doen, zoals bij de banken? Dat ze alles op je website moeten factchecken? Lijkt me zeer onwenselijk en onwerkbaar. Let's Encrypt moet checken of jij de domeinhouder bent, verder niets.

Daarmee claim je dat de helft van alle websites voornamelijk crimineel is:
https://w3techs.com/technologies/details/sc-letsencrypt
Daarmee maak je nogal een dijk van een insinuatie over iedereen die het gebruikt (waaronder ik). Eigenlijk vind ik dat je excuses verschuldigd bent.

Zelfs een EV-certificaat garandeert je niet dat de eigenaar van een website niet crimineel is, het geeft alleen geverifieerde informatie over welke juridische entiteit de eigenaar is. TLS en de certificaten dienen voor het verhogen van de betrouwbaarheid van de verbinding, en zeggen niets over de betrouwbaarheid van hetgeen waarmee je verbinding maakt.

Het is in het verleden veel te vaak voorgesteld alsof het veel meer garandeert, doordat mensen die probeerden de boodschap zo simpel te maken dat iedereen hem kon snappen zo dom waren om hem simpeler te maken dan de realiteit. Die boodschap kon niet en kan niet waargemaakt worden en was dus oerstom om uit te dragen. Is dat niet waar je je ergernis op zou moeten richten in plaats van op een partij die opereert vanuit de realiteit dat het alleen de betrouwbaarheid van de verbinding raakt?

Let's Encrypt is een non-profit-organisatie.

Nginx en Apache ondersteunen ook stapling, dus om nu te beweren dat het nooit echt van de grond is gekomen
is lichtjes overdreven.
https://www.digitalocean.com/community/tutorials/how-to-configure-ocsp-stapling-on-apache-and-nginx

N.B.; bij Apache zou ik voor mod_md gaan!
https://github.com/icing/mod_md/
https://httpd.apache.org/docs/2.4/mod/mod_md.html

Ja het is wel te hopen dat Let's encrypt of een andere partij een oplossing bedenkt waardoor OCSP stapling wel blijft werken.

Internetters zijn niet blij dat zij een kritische echte websites (zoals van banken) niet meer van nepsites kunnen onderscheiden en nee ik werk niet voor een dure certificaten uitgever.

Hoezo ben jij geen kortzichtige egoïst omdat je het, puur met winstoogmerk, gecreëerde systeem steunt, waarbij internetters betrouwbare (dus dure) certificaten niet meer van (gratis) speelgoedcertifcaten kunnen onderscheiden?

Van mij mag jij jouw speelgoedcertificaatjes houden hoor, zolang jij niet van mij verwacht dat ik jouw effectief anonieme website vertrouw qua inhoud en evt. om vertrouwelijke gegevens met "jou" te delen. Wie "jou" ook moge zijn; immers, dat jij zegt dat jij geen crimineel bent, zegt nul-komma-niets. Want álle criminelen (meestal anonieme, pseudonieme of met vervalste identiteit) claimen dat.

Aso.

Dus omdat bijna alle criminele sites een DV-certificaat hebben, zijn alle sites met een DV-certificaat crimineel?

Zo is dat woord bedacht ja, maar dat is wel HEEL VREEMD.
Iemand die niet kan lezen noem je een ANalfabeet. AN is daarin de ontkenning van alfabeet, iemand die het alfabet kent.

En dan zou iemand die geen digi kent ineens een digibeet zijn? Alsof beet dan ineens een ontkenning is, terwijl dat in alfabeet niet zo is?
Het zou inderdaad adigibeet moeten zijn. Maar ja, dat ga je nu niet meer veranderen, we moeten het maar gewoon zien als een nieuw bedacht woord wat zich niet aan bestaande afleidingen houdt.

Als het goed is, dan kan een MiTM niet eenvoudig andermans certificaat vervalsen. Als DNS of eindbestemming gecompromitteerd zijn, dan helpt vrijwel niets meer.

Niets garandeert 100% betrouwbaarheid. Paspoorten zijn ook niet perfect.

Weten wie verantwoordelijk is voor een kritische website, is essentiële informatie voor internetters. Nee, het garandeert niet dat een website of die verantwoordelijke betrouwbaar is. Maar je weet wel wie je voor de rechter kunt slepen als je belazerd bent.

Het systeem, waarbij internetters opzettelijk nauwelijjs nog, of geheel niet meer, onderscheid kunnen maken tussen enerzijds volstrekt anonieme websites, en anderzijds websites waarvan de daarvoor verantwoordelijke bekend is, is een godsgeschenk voor cybercriminelen, big tech en hun aandeelhouders.

Nb. het primaire probleem is niet het bestaan van DV speelgoedcertificaten, maar het opzettelijk uit de markt drukken van betrouwbaarder certificaten - exact om anonieme websites net zo betrouwbaar te laten lijken als kritische websites.

Leg mij dan maar eens precies uit waarom dat géén duimzuigerij zou zijn.

Dat aan een déél van de internetters nooit is verteld waarom het essentieel is dat je weet met welke partij jij informatie uitwisselt, en dat een kleiner deel daarvan dat nooit zal begrijpen, is een krankzinnig excuus om er dan maar helemaal mee te stoppen.

Raad eens wie hen betaalt - of denk je dat het allemaal vrijwilligers zijn met, zonder vereiste tegenprestatie, bergen gedoneerde servers?

Open your eyes

Jij denkt kennelijk dat een betaald certificaat WEL garandeert dat je met een betrouwbare instantie, niet met een crimineel, communiceert. Maar dat is helemaal niet zo!
In het begin toen het systeem was ontworpen wel, ja. Ik herrinner me nog wel dat als je een certificaat wilde aanvragen (zelfs als je een DOMEIN wilde aanvragen!) je een uittreksel KVK moest hebben en handtekening van tekenbevoegde en (bij een certificaat) door vergelijkbare hoepels moest springen als nu bij aanvragen van een bankrekening.
Maar dat was al jaren niet meer zo.
Die uitgebreide controle hebben ze nog een tijdje op een "nieuw product" (extended validation certificaten) toegepast maar dat was kennelijk ook niet meer werkbaar en niet waterdicht genoeg, dus dat is ook weer een stille dood gestorven.

De naam "Let's encrypt" zegt het ook al: er wordt wel ge-encrypt maar niet gevalideerd.
Dat het dan niet meer zo waardevol is dat is duidelijk, maar kennelijk gelooft de wereld (en jij volgens mij als eerste) niet in waterdichte controle.
Misschien moet er een nieuw internet worden opgetuigd waarin het veel duidelijker is met wie je nou eigenlijk communiceert, zowel aan leveranciers- als aan klant zijde?
Ik denk dat daar ook wel een hoop mensen tegen zullen zijn... Chinese toestanden, ik wil anoniem rottigheid uit kunnen halen, enz.

@Erik van Straten Ook al heb je op een bepaald punt inhoudelijk gelijk, gooien met naamkaartjes is niet nodig. Iedereen mag een mening hebben.

Naast alle andere drogredenen die je opvoert:

1) In de eerste plaats moeten zij, met een gedocumenteerde minimale betrouwbaarheid, de identiteit van de aanvrager vaststellen. Betrouwbaarheid nul is prima, maar de mate van betrouwbaarheid waarmee een identiteit is vastgesteld moet volstrekt helder zijn voor internetters - als je überhaupt wilt beginnen met het serieus aanpakken van alle vormen van cybercriminaliteit. Weten wie is een fundamentele bouwsteen van IB.

2) In de tweede plaats kunnen blocklists van notoire criminelen worden gebruikt.

Het énige doel van certificaten is weten wie, oftewel authenticatie, oftewel het aantonen van een identiteit (het zijn van een uniek identificeerbare entiteit).

Hoe minder zeker je "weet om wie het gaat, hoe groter jouw risico's. Onder meer omdat je, bij grotere zekerheid over een identiteit, de juiste entiteit kunt sanctioneren indien nodig. En vanwege de dreiging die daar vanuit kan gaan, en de mogelijkheid om betrouwbare informatie m.b.t. de reputatie van de identiteit te vergaren.

Als aan internetters uitsluitend aangetoond wordt dat hun browser verbinding heeft met een nietszeggende (of erger: een wél iets zeggende, doch bewust misleidende) domeinnaam (zoals de nep bunq doneinnamen die ik noemde in https://security.nl/posting/850659), dan is dat niets meer dan een semi-random pseudoniem voor een identiteit. En precies dat maakt impersonatie door cyberrcriminelen zo supereenvoudig.

Internetters hebben er totaal niets aan als iemand met behulp van prijzige certificaten (of bijv. met SPF, DKIM en DMARC) diens uiterste best doet om diens identititeit aan klanten of andere bezoekers (of e-mail lezers) te bewijzen, als het voor fraudeurs eenvoudig is om die klanten etc. ervan te overtuigen dat zij of hij diens identiteit heeft.

Authenticatie is minder betrouwbaar naatmate impersonatie eenvoudiger is.

Serverbeheerders/website-eigenaren: denk eens niet aan jezelf, maar aan jouw klanten. Servercertificaten zijn er voor hen.

Maar wat ga je dan vaststellen/vastleggen? Naam? BSN? KVK nummer? Whois info?
En hoe gaat dat passen in de tegenwoordige belachelijke privacy wetgeving?
Mogen criminelen niet meer de privacy hebben om zonder dat ze te achterhalen zijn rottigheid uit te halen?
En beperkt zich dat dan tot de mensen waar we zaken mee doen (leveranciers) of komen we dan zelf ook in beeld?
Bijv mag een webshop eisen dat klanten waterdicht geidentificeerd zijn?
En dat kon toch helemaal niet volgens jou?


Ja maar dan moet je wel eerst een 1:1 mapping hebben tussen "criminelen" en "domeinen" (of sites of whatever).
Hoe weet je als je hebt vastgesteld dat je met een site van bedrijf X communiceert, dat daar dan crimineel A, B en C werken?
Of moet dat ook allemaal waterdicht vastliggen in een electronisch bij ieder browserbezoek te raadplegen register?
(popup bij het slotje "u bent op de site van bedrijf X maar daar is de directeur niet zuiver op de graat, of wacht even niet de directeur maar zijn vriendin is het probleem!")

Aanvankelijk was het doel van https servercertificaten tweeledig:

1) Aantonen dat de browser verbinding heeft met de bedoelde website van een specifieke eigenaar, die door de internetter wordt vertrouwd. Vaak is dat vertrouwen gebaseerd op reputatie van de eigenaar (zoals bij ing.nl of digid.nl). Toegegeven, ook zonder dat je precies weet wie de eigenaar is, kan een domeinnaam een reputatie opbouwen (denk aan security.nl of bol.com), maar effectief is dat dan de "naam van de organisatie" die mensen onthouden (waarbij het vertrouwen daarin groter wordt naarmate een domeinnaam langer bestaat en zelden of nooit negatief in het nieuws komt).

2) Het versleuteld naar de client sturen van een, door de server gegenereerde, symmetrische sessie-encryptiesleutel.

Sinds forward secrecy wordt gebruikt (middels het Diffie Hellman algoritme) zijn we (jaren geleden) gestopt met punt 2. De reden daarvoor is dat, als een kopie van de private key (passend bij de public key in het certificaat) van de server op straat zou belanden, of door geheime diensten zou worden opgeëist, opgeslagen versleuteld netwerkverkeer van eerdere sessies alsnog zou kunnen worden ontsleuteld.

Door certificaten géen onderdeel te maken van de verseuteling van de sessie, worden twee vliegen in één klap geslagen (die tweede duurde wat langer, tot TLS v1.3):

a) Zoals gezegd, je realiseert forward secrecy (met een gelekte private key kun je geen opgeslagen versleutelde sessies decrypten);

b) Na het opzetten van de TCP-verbinding en het uitwisselen van enkele onversleutelde gegevens, kan de verbinding


v kunt beginnen met het versleutelen van de verbinding (de data in netwerkpakketjes) versleute

Al te bout. Let's Encrypt wordt gewoon heel veel toegepast, ook voor zeer legitieme doelen. Vrijwel elke website in een shared hosting omgeving maakt nu gebruik van LE. Bovendien is het niet aan een RA/CA om te bepalen of een certificaat wordt ingezet voor criminele zaken.

Wat een on onderbouwde onzin vertel jij hier Erik,


het woord: 'voornamelijk' hier doet jouw " heavy lifting"... echter word Lets Encrypt op allerlei plekken gebruikt, en 'criminelen' is slechts 1 deel hiervan. ook is het niet aan een CA om criminelen te voorkomen. (en certificaten intrekken is op dit moment hell, CRL (Certificate Revocation List) is te omslachtig en werkt niet, OCSP (if stappled) lost dit probleem op.


Dit heeft niets met OCSP of met Lets Encrypt te maken. deze partijen deden dit in het verleden met 'betaalde' certificaten... de kosten zijn namelijk voor hen geen barrière.

En? DV zijn de meeste certificaten in gebruik op dit moment... dit toont niets aan.
Certificaten d.m.v. trusted Cerificate Authorities zijn inderdaad nogal een wassen neus... de oplossing is DANE met DNSSEC.
echter werkt dat voorlopig ook niet.
1) Gesproken als iemand die niets weet over hoe TLS werkt, het Ceritificaat word gebruikt 2 ledig: als bron van de Public Key, zodat de connectie gevalideerd van iemand met die Private key afkomt. En om to zien welke partij deze key heeft, alsmede welk gebruik er is voor deze key. dit is het doel van x509 certificaten. welke dit doel al sinds de jaren 70 heeft.

Tl;Dr: het Certificaat is onderdeel van het opzetten van de beveiligde verbinding. dat er een secure exchange tunnel word opgezet zonder certificaat doet hier geen afbraak aan... TLS 1.3 volg een vergelijkbaar protocol als SSH, welke ook eerst een "pilot" connection opzet om de validatie en dan een andere zodra er geauthenticeerd en geauthorizeerd is.

1B) De naam "Lets Encrypt" is gewoon een naam.

2) het doel van Certificaten is om Meta data te koppelen aan het bezit van een Private key. zodat bewezen kan worden dat de oorsprong de genen is die dat certificaat "bezit".
ergo, het doel is IDENTIFICATIE, niet AUTORISATIE. (het autorisatie stuk werkt buiten de tunnel om via de CA lijst van de browser of OS in de meeste gevallen)

Dit voegt enkel nog een (single) point of failure toe aan de set. welk dus gebruiksonvriendelijk is. een ander systeem, iets dat bijvoorbeeld werkt met het DNS systeem, zou beter zijn.
Correct, ook omdat de lijst alle verlopen en ingetrokken certificaten moet blijven bevatten. (design flaw).
dit is een Non sequitur. dat er andere (betere) manieren zijn om te tracken welke websites bezocht worden heeft niets te maken met deze (mogelijke) manier van tracken.
Mogenlijk, echter zou ikzelf stappled OCSP wel mogenlijk maken maar niet OCSP voor browsers. (bijvoorbeeld).

stappled OCSP heeft niet de privacy probleem en geeft wel een kleine window waarin het certificaaat geldig is.

Ik zie hier vooral veel miskennis over hoe TLS werkt. en weinig begrip voor waarom privacy keuzes soms anders zijn voor andere mensen.

Speciaal voor Eric even een linkje naar de meest uitgebreide uitleg over hoe TLS 1.3 nou ECHT werkt...

https://tls13.xargs.org/

Dus eerst een initiële encryptie van de handshake en daarna een symkey voor de applicatie data.
Lees even de kopjes "Server Application Keys Calc" en "Client Application Keys Calc".

Oftewel, dankzij de uitwisseling van beider public keys, het gebruik van de eigen private keys EN het gebruik van de hashes van verzonden en ontvangen pakketjes berekenen beide zijden dezelfde session key voor het versleutelen van de applicatie data. De initiële versleuteling is dus enkel om de handshake procedure zoveel mogelijk te versleutelen.

Aanvankelijk was het doel van https servercertificaten tweeledig:

1) Authenticatie
Doel 1: aantonen dat de browser verbinding heeft met de bedoelde website van een specifieke eigenaar, die door de internetter wordt vertrouwd - door drie essentiële attributen op te nemen in zo'n certificaat:
1.a) Identificerende gegevens van de eigenaar van de server(s) met de gegeven domeinnaam of -namen;
1.b) Domeinnaam (of domeinnamen);
1.c) Public key (de bijpassende private key bevindt zich op de server).

Vaak is dat vertrouwen gebaseerd op reputatie van de eigenaar (zoals bij ing.nl of digid.nl). Toegegeven, ook zonder dat je precies weet wie de eigenaar is, kan een domeinnaam een reputatie opbouwen (denk aan security.nl of bol.com), maar effectief is dat dan de "naam van de organisatie" die mensen onthouden (waarbij het vertrouwen daarin groter wordt naarmate een domeinnaam langer bestaat en zelden of nooit negatief in het nieuws komt).

2) Encryptie (van de sessiesleutel)
Doel 2: het versleuteld naar de client sturen van een, door de server gegenereerde, symmetrische sessie-encryptiesleutel. Dat gebeurde door de, random door de client verzonnen symmetrische (AES bijvoorbeeld) sessiesleutel te versleutelen met de public key uit het servercertificaat.

Dankzij asymetrische encryptie kan alleen de bezitter van de private key de versleutelde sessiesleutel decrypten. De client kan die versleutelde sessiesleutel dus veilig naar de server sturen (over de dan nog onversleutelde verbinding). De server verkrijgt de gewenste "plain text" sessiesleutel door de versleutelde sessiesleutel met diens private key te ontsleutelen. Daarna kan het datadeel van tussen de server en client (en vice versa) uitgewisselde TCP/IP pakketjes door de verzender worden versleuteld en door de ontvanger worden ontsleuteld.

Sinds forward secrecy wordt gebruikt (middels het Diffie Hellman key-agreement algoritme (*)), zijn we (jaren geleden) gestopt met punt 2.

(*) Vereenvoudigd uitgelegd wordt, bij forward secrecy, voor élke sessie een, éénmalig te gebruiken, asymmetrisch sleutelpaar gegenereerd, bijv. door de server - die de public key daarvan naar de client stuurt. De client verzint een random symmetrische sessiesleutel en versleutelt deze met de public key uit het éénmalig gebruikte sleutelpaar - dus in plaats van met de public key uit het certificaat, dat voorheen langdurig (maanden of jaren) tevens voor dit doel (2) werd gebruikt. Daarna gaat het verder zoals uitgelegd onder punt 2 vanaf "Dankzij asymetrische encryptie ...".

Het doel van forward secrecy is het voorkómen dat éérder afgeluisterde en opgeslagen versleutelde sessiedata, op een later tijdstip kan worden ontsleuteld, namelijk op het moment dat de langdurig geldige private key (horend bij een public key in een certificaat) in handen van de bezitters van (indirect met die private key) opgeslagen versleutelde sessiedata valt. Daarbij moet vooral aan geheime diensten worden gedacht.

Door certificaten géén onderdeel meer te laten zijn van de versleuteling van de sessie, worden twee vliegen in één klap geslagen (die tweede duurde wat langer, nl. tot de introductie van TLS v1.3):

a) Forward secrecy
Zoals gezegd, je realiseert forward secrecy (d.w.z., met een gelekte of opgeëiste private key kunnen geheime diensten en/of kwaadwillenden geen eerder opgeslagen versleutelde sessiedata decrypten);

b) Certificaat geheel niet meer zichtbaar "op de lijn"
Er kan gewacht worden met het door de server naar de client sturen van het servercertificaat (en intermediate certificaten) totdat de verbinding is versleuteld - hetgeen de privacy ten goede *kan* komen. Overigens nauwelijks, want IP-adressen in netwerkpakketjes worden niet versleuteld door https (uitgezonderd bij "SSL-VPN's - maar zo'n VPN eindigt altijd ergens vóór de webserver). En bij IP-adressen waar vele domeinnamen achter zitten, heb je het kip-ei probleem dat de browser aan die server zal moeten vertellen met welke domeinnaam deze verbinding wil maken. Anyway, het vormt een praktisch bewijs dat certificaten geen onderdeel meer uitmaken van het proces om verbindingen te versleutelen.

Wat je ook doet, doel 1 zal nooit met 100% betrouwbaarheid worden bereikt.

De manier waarop certificaten worden uitgegeven, moet ertoe leiden dat elke (van álle) door internetters vertrouwde certificaatuitgever pas een certificaat uitgeeft nadat die certificaatuitgever (op de, voor genoemde internetters, minimale en voldoende betrouwbare wijze) heeft vastgesteld dat:

a) De domeinnaam/namen van de aanvrager zijn
De domeinnaam/namen in de certificaataanvraag allen leiden naar één of meer servers "die van de aanvrager zijn" (meestal zijn ze gehuurd, de aanvrager moet aantonen een specifieke schrijftoegang te hebben tot die server(s). Er bestaan ook andere protocollen voor deze "Domein Validatie").

b) Optionele, naar verantwoordelijken herleidbare identificerende gegevens correct zijn
Optioneel, doch essentieel voor kritische (risicovolle qua uitgewisselde info) websites: met (meer of minder vergaande) eisen gesteld aan de betrouwbaarheid ervan: de certificaataanvrager toont aan wie zijn of hij zegt te zijn - én, indien van toepassing, de aanvrager toont aan (met minimaal gelijkwaardige betrouwbaarheid) dat deze door de, in het certificaat genoemde, organisatie geautoriseerd is om dat certificaat aan te vragen.

M.b.t. punt b: deze aanvullende identificerende gegevens zijn simpelweg noodzakelijk voor kritische websites, omdat géén enkel normaal mens van alle ooit eerder bezochte sites de exacte (en volledige, inclusief TLD) domeinnaam kan onthouden, en bij (mogelijk) niet eerder bezochte websites met onbekende (of niet herinnerde) domeinnamen, daaruit met voldoende zekerheid kan herleiden wie de verantwoordelijke daarvoor is.

Als aan de gestelde minimale betrouwbaarheidseisen wordt voldaan (en de uitgever diverse metadata heeft toegevoegd aan de aanvraag), zet de certificaatuitgever een digitale handtekening onder de certificaataanvraag waamee het, in principe, een geldig certificaat is geworden (bij CT, Certificate Transparency, zijn counter-signatures, gezet door andere certuitgevers, noodzakelijk om een certificaat geldig te laten zijn).

De reden om certificaatverstrekkers (derde partijen die moeten worden vertrouwd door internetters) de identiteit van aanvragers te laten checken, is dat:

Niet elke individuele internetter dat zelf maar voor elkaar moet zien te krijgen.

Iets dat totaal niet schaalt en in de praktijk simpelweg onmogelijk gemaakt is (zelfs whois vertelt je alleen nog maar "Redacted for privacy reasons").

De primaire voorwaarde voor elke individuele internetter voor dit systeem is dat zij elke (allemaal dus) certificaatuitgever van de in de browsers en/of besturingssystemen op hun apparaten opgenomen rootcertificaten moet vertrouwen, en dat dit vertrouwen terecht is.

De essentie van, of, zo je wilt - het ontlenen van haar bestaansrecht aan, het publieke (op PKI gebaseerde) certificatensysteem is precies het voorkómen dat kwaadwillenden, als MitM's, identiteitsfraude kunnen plegen.

Daarbij moet worden opgemerkt dat DV-certiticaten niet alleen grotendeels waardeloos zijn voor internetters omdat zij totaal geen info bevatten over de identiteit van de verantwoordelijke voor een domeinnaam, maar óók omdat DV-certificaten in steeds meer gedocumenteerde gevallen aan MitM's, onrechtmatige domeinnaamkapers, zijn verstrekt.

Notabene exact de reden waarom, aldus de DV-fanclub, allerlei uitgevers van OV, EV en QWA-certificaten zouden hebben gefaald (dat deden ze, maar de pot verwijt de ketel) en zúllen falen.

Probleem: de slager keurt diens eigen vlees - bestemd voor consumenten.

Als onze expert https://security.nl/profile?alias=musiman nou eens precies zou aangeven wat er exact onjuist is aan mijn begrip (dat zomaar fout kan zijn) van hoe het e.e.a. werkt (en op welke wijze precies dat mijn betoog zou beïnvloeden), dan leer ik (en wellicht anderen) daar wat van.

En dan kan ik dit soort zaken een volgende keer met minder fouten (indien die hierboven aanwezig zouden zijn) uitleggen.

Aanvulling 17:21: ik heb https://tls13.xargs.org/ bekeken - en zie niets dat inhoudelijk afwijkt van wat ik hierboven schreef. Ik sta altijd open voor correcties en/of aanvullingen, maar als het ook jouw doel is om mij pootje te lichten met neppe betweterige bullshit, en je hieronder geen toelichting geeft, mag je van mij wegzakken in /dev/null.

Wat jij in feite zegt is dat je een controlestaat wilt op Internet.
Tuurlijk, dat geeft zeker voordelen! Hardstikke handig dat als je webshop een oplichter blijkt te zijn je meteen even zijn doopceel kunt aanklikken om in je aangifte bij de politie aan te leveren!
Heb je misschien zo iets meegemaakt de laatste tijd, dat je zo gedraaid bent van "kan allemaal nooit" naar "dit moeten we regelen"?
Of ben je op vakantie en is je account gehacked ofzo? Want ik zie nu een totaal andere redenering dan we normaal van jou zien.

Wel vind ik dat als je dit zo uitgebreid wilt optuigen, dit wel tweezijdig moet zijn.
Dwz de server waar je verbinding mee maakt is uitgebreid geidentificeerd, met allerlei verwijzingen naar verantwoordelijken en kwalificatie als goedwillend of crimineel, prima.
Maar dan ook wel een verplicht client certificaat voor alle bezoekers (of op zijn minst de bezoekers die dat nieuwe protocol gebruiken en dus die info te zien krijgen) zodat de websitebeheerder als die dat wil altijd kan natrekken wie er achter een bepaalde transactie zat, ook weer voor het gemak bij aangifte bij ongewenste zaken.

@Erik van Straten Je begrijpt het niet helemaal denk ik. Als je ergens in het midden zit, kun je je voordoen als de domeinhouder. Het gaat om de wijze van authenticeren bij de aanvraag van het certificaat. Als dat werkt door met een domein te communiceren, kan een MitM zich voordoen als dat domein (bijvoorbeeld als de locatie van de MitM dicht bij het doel aanwezig is).

Reputatie van een domeineigenaar heeft weinig te maken met het aanvragen van een certificaat als MitM. Ik begrijp niet waarom je dat erbij haalt.

Forward secrecy verandert er ook niets aan als er met de MitM gecommuniceerd wordt, met een nieuw certificaat.

Identiteit kan eenvoudig worden vervalst. Zeker iemand die in staat is een MitM aanval te plegen heeft waarschijnlijk ook meer mogelijkheden om dat af te vangen. Wat er moet gebeuren is dat er via diverse kanelen bevestiging plaatsvind. Dus niet alleen via internet, maar ook per post, identificatie van de persoon. Het gaat dan niet zozeer om die identificatie zelf, maar wel om de diversiteit en onafhankelijkheid van de kanelen en de controlemogelijkheden van de CA.

Het gebruik van het woord digibeet is kenmerkend en synbolisch voor hoe dingen op het gebied van computers ingewikkeld gemaakt worden. Dit gedoe met certificaten is daar weer een voorbeeld van.

Haha ik ben gestopt met lezen na dat laatste woord lol

Op internet is het duidelijk niemands taak om cybercriminaliteit op fundamentele wijze aan te pakken. Werk jij voor Google of Cloudflare of zo?

Blijkbaar is Erik niet helemaal op de hoogte.

Zoals iedereen die iets verder op certificaten in gaat weet is de privatekey de identiteit. Het certificaat is door een derde uitgegeven en bestigd dat de organisatie die dat uitgeeft bepaalde controles heeft gedaan zoals kan de aanvrager ook dns records en/of website aanpassen op verzoek.
Zo ja dan moet dat de eigenaar zijn van de domeinnam, server en private key.
De public key wordt dan met de private key van de verifyer vastgelegt.

Van verifyers die aan bepaalde voorwaarden voldoen is een register aangelegd ed die lijst wordt door de meeste tools die encryptie gebruiken toegepast. Expliciet dan wel impliciet.

Omdat de controle nooit verder gaat zullen criminelen overal terecht kunnen. Alleen laten ze een betaalspoor achter bij betaalde certificaten.
Ik denk dat CA's die van overheden zijn minder betrouwbaar zijn omdat achterdeurtjes met inlichtingen diensten kunnen bestaan... Al zullen die vast een paar tientjes over hebben voor andere certificaten.

Een certificaat is niet veel anders dan een id kaart/paspoort met een private key ipv een pasfoto, en de burgermeester van je gemeente als verifyer.

Voor websites waarvoor dat relevant of ommisbaar is, ondubbelzinnige identificerende informatie over de verantwoordelijke partij. Zoals bekend bij de KvK, maar niet elke organisatie is daar ingeschreven (Politie bijvoorbeeld). Alle informatie waar zelfs "eenvoudige" uit kunnen afleiden:
• Om welke uniek identificeerbare partij het gaat, en
• Hoe betrouwbaar die identificerende gegevens zijn vastgesteld.

Prima.

Als boven elke winkeldeur in het centrum "anoniem" of (een QR-code voor) https://garantie.tot-aan-de.deur zou staan, en de etalage zou lijken op die van de HEMA, de Ecco of een bankfiliaal, zou jij daar dan naar binnen gaan?

Als nepshops of nepbanken op internet anoniem willen blijven: prima. Echte webshops en echte banken weten dat hun anonimiteit primair niet in het belang is van hun klanten of andere bezoekers, en uiteindelijk allesbehalve in hun eigen belang is. Wat ik noodzakelijk vind is dat internetters het verschil tussen nep en echt zelf beter kunnen maken.

Dat internetters verschil kunnen zien tussen nep en echt, is echter beslist niet in het belang van Big Tech, want ook zij verdienen bakken geld aan cybercrime.

Mede om het leven van iedereen die een "web presence" en bijv. een CDN-proxy wil (inclusief steeds meer cybercriminelen), zo eenvoudig mogelijk te maken, zijn DV-certificaten geïntroduceerd. Die zijn niet in het belang van internetters, maar juist wel superhandig voor beheerders: gratis, geen gedoe met authenticatie, binnen seconden live en automatische updates. Geen omkijken meer naar! Daarbij, gemakshalve, vergetend (of bewust kromlullend, zoals vele egoïsten hierboven) voor wie die certificaten bedoeld zijn.

Straks moet jij, met jouw niet verplichte EDIW (holbewonen is het alternatief), op steeds meer websites met geuren en kleuren bewijzen wie jij bent - terwijl websites dat niet zouden hoeven? Dat is smeken om AitM websites - met zou-kunnen-zijn-van domeinnamen - die frauderen met de "superbetrouwbare" identiteit hun slachtoffers.

Probleempje van Big Tech: als browsers alle websites met DV-certificaten (al dan niet terecht in elk specifiek geval) als minder betrouwbaar zouden weergeven, zouden alle verstandige internetters de voorkeur geven aan websites met betrouwbaarder certificaten - simpelweg omdat zij minder risico's lopen door informatie met dergelijke websites uit te wisselen.

Dus heeft Big Tech (wapperend met heel veel Dollarbiljetten) alle browsermakers gevraagd om geen onderscheid meer te maken tussen de betrouwbaarheidniveaus waarmee de identiteit van een domeinnaameigenaren wordt vastgesteld (betrouwbaarheidsniveaus zijn een fundamentele bouwsteen van infosec, bijv. ook DigiD baseert daarop).

Bovendien heeft helemaal niemand - ook de (door Big Tech gesponsorde?) EFF niet - de moeite genomen om certificaten fatsoenlijk leesbaar te maken voor mensen.

Sterker, we worden belazerd (EFF en Mozilla zijn voor het karretje gespannen met het hoogste woord) m.b.t. dat QWAC's primair bedoeld zouden zijn voor overheidsspionage - terwijl de three-letter-agencies, met FISA section 702 in de hand, zielsgelukkig zijn met de Fastly's en Cloudflare's van deze wereld (met E2EE-terminating servers op bijna elke straathoek).

Of zie -bij toeval ontdekt- https://notes.valdikss.org.ru/jabber.ru-mitm/.

Kom eens uit je ivoren toren en probeer het met een helikopterview te bekijken. Op sporadische speldenprikjes na wordt cybercriminelen geen strobreed in de weg gelegd.

En ik ben behoorlijk klaar met alle roepers dat iets niet de taak van welke partij dan ook zou zijn: puur je kop in het zand steken. M.i. moet er iets veranderen. Kom met realistische oplossingen of (je raadt het al).

Ik werk wel voor een Trusted Service Provider. Niet eentje voor tv’s of web authenticatie certificaten. Maar eentje voor uitsluitend persoonsgebonden certificaten.

Ik wil het hebben over
- privacy gevoeligheid OCSP
- informatieveiligheid
- doorgetrokken naar certificaten
- Lets encrypt
- bigtech en hun rol in certificaten

Privacy gevoeligheid OCSP.
Lets Encrypt heeft gelijk als zij zeggen dat OCSP privacy issues heeft.
Met OCSP (de pointer staat in het certificaat) zal (in principe) elke keer als een website wordt bezocht een validatievraag naar de OCSP server worden gestuurd. Deze validatievragen kunnen worden afgevangen voor allerhande doelen. Over overheden maak ik me hier geen zorgen. Over bigtech zelf des te meer. Met name omdat Lets Encrypt een heel erg grote speler is Lets Encrypt in staat om t.a.v. heel erg veel websites de bezoekers ervan kunnen profilen. Als ik als gebruiker naar een Audi zoek, daarna naar een Opel, daarna naar een BMW, dan zal LetsEncrypt mij all snel kunnen profilen als een potentiële koper van een Duitse auto. Dat heeft reclamewaarde. En dit is slechts een onschuldig voorbeeld.
Ikzelf heb Lets Encrypt keer op keer beschuldigd dat zij een profielinformatie bedrijf zijn of zullen worden.
Hoewel OCSP echt meerwaarde heeft, logenstraft de mededeling van Lets Encrypt mijn beschuldiging.

Informatieveiligheid.

Informatieveiligheid gaat er niet alleen om dat iets kan worden geheim gehouden. Het gaat er ook om dat informatie (systemen) beschikbaar zijn. En het gaat er ook om dat ik van de informatie op aan kan (dat is ook de mate dat ik zeker kan weten of het waar is). Weten met wie ik zaken doe is onlosmakelijk deel van informatieveiligheid over een zeer groot publiek netwerk. Internet is zo’n groot publiek netwerk.

Domein validatie zegt slechts dat het domein is gevalideerd. En cybercriminaliteit (met name de bewust bekwame slechterik die nepwebsites maken)maakt juist gebruik van uitsluitend domeinvalidatie. Wordt je (als onwetende consument) gefopt via een nepwebsite, dan kan je met domeinvalidatie nooit de eigenaar vinden.

Dit wil niet zeggen dat domeinvalidatie slecht is (veel websites maken hier gebruik van). Het wil wel zeggen dat domeinvalidatie certificaten een ankerpunt is voor (georganiseerde) cybercriminaliteit.

Tot voor enkele jaren geleden werden Extended Validation (EV) Certificaten voorzien van een groen balkje. EV certificaten garandeerden dat de eigenaar bekend is. En dus opspoorbaar als er een cybercrimineel achter zit waarvoor reden bestaat dat die opgespoord moet worden. De BigTech heeft dat groene balkje weggehaald uit de browsers omdat er geen verschil zou zijn tussen EV en DV certificaten. Ten aanzien van techniek heeft BigTech gelijk. Maar niet als het gaat over verkleinen van cybercriminaliteit.

INFORMATIEVEILGHEID MOET HERKENBAAR ZIJN VOOR ONWETENDE IT GEBRUIKERS
Wat techneuten vinden of beter weten gaat de gewone burger niet helpen.

Doorgetrokken naar certificaten

Domein Validated levert eigenlijk alleen maar een versleutelde verbinding op
Organisatie Validated levert versleuteling én een beetje kennis op van de organisatie achter de website
Extended Validation levert versleuteling én veel meer kennis op van de organisatie achter de website
Qualified Web Authentication Certificated (QWAC) levert én versleuteling én veel meer kennis van de organisatie én wettelijke bescherming binnen de Europese eIDAS verordening op.

Voor mij zou het zo moeten zijn
- DV en OV hoeven niet herkenbaar te zijn
- EV moet alsnog met een groene balk herkenbaar worden gemaakt
- QWAC moet worden voorzien van een blauwe balk of eIDAS kenmerk om herkenbaar te zijn.

LetsEncrypt

Een organisatie waar ca 37 mensen werken en die ruim 370 miljoen websites van certificaten voorziet.
Dat is marktmacht. Ik heb Lets Encrypt altijd als kwade genius gezien. Maar de OCSP uitspraak is daarmee in tegenspraak.
Lets Encrypt kan hebt aantal alleen maar halen als de certificaatuitgifte volledig is geautomatiseerd. Dat is ook hun doel (staat op hun website). Dat betekent dat men wel DV certificaten kan uitgeven, maar geen OV, EV of QWAC. Omdat de controle op eigenaarschap naar rechtspersoon niet (of nog niet) kan worden geautomatiseerd.

Lets Encrypt is inderdaad een not-for-profit organisatie. Lets Encrypt staat daarmee (helaas) niet los van Bigtech. Bigtech is de grootste sponsor van LetsEncrypt (speel zelf maar follow-the-money).

BigTech

Bigtech gaat over geld verdienen. Big Money. Dat is niet verwijtbaar. Integendeel. Geld verdienen is niet vies.
Bigtech verdient zoveel geld met automatiseren en schaalbaarheid. Lets Encrypt is daar slechts een van de spelers in. Controles inbouwen (bijv om eigenaarschap vast te leggen in certificaten) is dat niet.
Precies dit (denk ik) is de reden voor Bigtech geweest om de groene balk van EV weg te halen.
Onder het motto: technisch is EV gelijk aan OV. Technisch is dat juist, maar t.a.v. opsporing en terugdringen cybercrime is dat niet.

Nevenschade is dat cybercrime kan blijven bestaan.
Denk in termen
- de kraan staat open
- je gaat dweilen
- dan is het toch handig als je de kraan dicht draait

Er is nog veel meer te vertellen hoor

Want?

Vraagt een slager ook om jouw legitimatiebewijs als je een pond gehakt koopt? Nee, want consumenten hebben rechten. En waarom zou die slager dat doen - als jij meteen betaalt?

Als je daarentegen jouw portemonnee (oeps, ouderwets, smartphone) vergeten bent bij die slager, of als je iets huurt, of een leverancier om andere redenen significante risico's loopt, of als de wetgever bijv. leeftijdsverificatie verplicht als er twijfel bestaat (zoals aan de deur van casino's of bij de verkoop van alcoholhoudende drank), dan vindt "de Nederlander" verplichte authenticatie acceptabel of zelfs volkomen terecht.

Idem online. Je kunt gewoon informatie vinden op de website van de gemeente waar je woont - en zelfs van elke andere gemeente; het is nergens voor nodig om daarvoor te authenticeren. Anders wordt dat als je online bijvoorbeeld een parkeervergunning of een toeslag aanvraagt. Volstrekt normaal vind ik.

Wat er op internet vaak fout gaat, is dat als je iets online bestelt, je meestal veel meer persoonsgegevens dan nodig verplicht moet invullen - die vervolgens absurd lang worden bewaard in databases die effectief aan "het internet hangen". Om vervolgens jaren (gefeliciteerd met jouw verjaardag!) sufgespamd te worden door de webshop - dat mag van de wetgever, want er was sprake van een zakelijke relatie. En door "echte" spammers en phishers (wat niet mag van de wetgever, maar die kan of wil er zelden iets effectiefs tegen doen), want dat soort databases worden gehacked of jouw gegevens worden sowieso verhandeld.

Op internet verschuiven steeds meer risico's naar internetters die zich daar nauwelijks of niet tegen kunnen beschermen, noch zich tegen (soms zeer grote) schades kunnen of willen verzekeren. Of wil je dat ontkennen?

Ik begrijp werkelijk niet waar je op aan probeert te sturen.

Zo vermoeiend dit.

In de tweede helft van https://security.nl/posting/322952 zie je een private key (base64 gecodeerd). Gedecodeerd is het een nietszeggende en door normale mensen niet te onthouden reeks bytes, een soort extreem lang BSN.

Maar de nietszeggendheid en ononthoudbaarheid ervan zijn hier niet het grootste probleem: dat is dat een private key met niemand gedeeld mag worden. Alleen al daarom zou "iedereen die iets verder op certificaten in gaat weet is de privatekey" NIET "de identiteit".

Ik snap dat je iets anders bedoelt, maar dit soort redeneringen waarbij elke lezer er vanalles bij moet verzinnen, met het risico op het verkeerde been te worden gezet, schiet niemand iets op.

Mijn vereenvoudigde uitleg voor leken (met een aanvulling voor gevorderden):

1) Certificaat: vergelijkbaar met kopietje paspoort
Een certificaat kun je vergelijken met een kopie van een paspoort.

Een paspoort:
• Is uitgegeven door een (door verifieerders) vertrouwde derde partij (de overheid);
• Koppelt identificerende gegevens aan een pasfoto;
• Is een lastig te vervalsen document.

Een certificaat:
• Is uitgegeven door een (door verifieerders) vertrouwde derde partij (een certificaatuitgever);
• Koppelt identificerende gegevens aan een public key;
• Is een extreem lastig te vervalsen document.

Omdat degene die een kopie van jouw paspoort ontvangt (of profiteert van een datalek met zulke kopieën), zich naar derden voor kan doen als jou, zegt uitsluitend het kunnen overleggen van een kopie van jouw paspoort helemaal niets (zie ook https://security.nl/posting/827137).

2) Private key: gebruikt om bezit van originele paspoort te bewijzen
Middels een wiskundige truc (asymmetrische cryptografie) bewijst de server over het echte paspoort te beschikken, zonder dit zelf uit handen te geven (dat alleen maar tot onnodige risico's zou leiden). Nb. uit de private key (op de server) kun je welliswaar de public key herleiden, maar sleutelparen worden meestal ververvang bij elke certificaat-update. En dat is knap onhandig voor identificerende gegevens; het enige doel is het uit elkaar kunnen trekken van de (bij elkaar blijven horende) asymmetrische sleutels om de identiteit, tevens "ingekapseld" in het certificaat, aan te kunnen tonen.

3) Channel binding (voor gevorderden)
Met 1 en 2 zijn echter nog steeds Attacker-in-the-Middle aanvallen mogelijk - zoals ook telefonisch kan, zie het "plaatje" onder "De Chase case" in https://security.nl/posting/842742.

Nb. om dezelfde reden hebben onderling afgesproken wachtwoorden om whatsapp-fraude ("nieuwe telefoon, heb dringend geld nodig") te voorkómen, potentieel geen enkele zin.

Bij het gebruik van forward secrecy (zie elders op deze pagina voor uitleg) zijn er, als een soort bijproduct van de TLS-handshake, grote random getallen (in principe uniek) beschikbaar die de client en de server kennen - maar die verder geheim zijn en blijven. Als de server het bewijs van het bezit van de private key cryptografisch combineert met zo'n groot getal (of alle getallen), kan de client vaststellen dat het bewijs afkomstig moet zijn van het andere einde van de E2EE-verbinding. Daarmee worden twee (of meer) TLS verbindingen tussen de client en de server uitgesloten - oftewel, een AitM zal daarnee door de mand vallen - tenzij die AitM over een certificaat beschikt dat de browser geldig acht voor de betreffende server.

"Legitieme" AitM's, zoals https openbrekende proxy-servers van Cloudflare en Fastly, moeten dus over een servercertificaat (en bijpassende private key) beschikken als ware zo'n proxy de echte server.

Als je https://kellogs.com zou openen, maakt jouw browser verbinding met een Fastly server die jou op dit moment een certificaat stuurt dat geldig is voor 98 verschillende, voor de helft totaal ongerelateerde, domeinnamen (zie "X509v3 Subject Alternative Name" in https://crt.sh/?id=13725803170) - iets dat bij een fatsoenlijk certificaat onmogelijk zou zijn: niet TLS maar Fastly magie -met onbekende betrouwbaarheid- zorgt voor een verbinding met uiteindelijk een server met de door jou opgegeven domeinnaam.

Als je die link zou openen, wordt jouw browser echter doorgestuurd naar https://wn.com/Kellogg?from=kellogs.com - waaruit nog maar weer eens blijkt hoe misleidend domeinnamen kunnen zijn. Gelukkig zie ik rechts in die pagina:
Helaas http, maar wat aardig! Klik - hee nou zit ik ineens op "Kellanova Job Search": https://www.kellanova.com/us/en/home.html - met een foto van een meneer die een bus Pringles bij zijn oor houdt alsof het een telefoon is.

Oh, u wilde cornflakes? Dan zou https://kelloggs.com wel de juiste URL kunnen zijn, maar in Firefox voor Android kan ik alleen zien (na tap op hangslotje):
Dus niets over het type certificaat, laat staan mogelijk aanvullende identificerende gegevens over het "Subject". Hoe kom ik er achter wat echt is? Als het echt lijkt of zo?

Nog eentje proberen maar, nu met .nl TLD. Onderaan https://www.kelloggs.nl/nl_NL/home.html staat:
Hmm Frans? Waar heb ik "Kellanova" ook al weer eerder gezien...

Ah, in de -gebrekkige- certificate viewer van Chrome voor Android zie ik dat het niet om een DV-cert gaat:
Precies het verwijt van Google tegen EV-certs ("het" drama van EV-certs bestaat eruit dat Google onderzoekers ooit aantoonden dat zij, door het gebrek aan een fatsoenlijke federale KvK in de VS, in een andere staat een EV-cert voor "Stripe, Inc." konden aanvragen - en verkregen): onvolledige identificerende informatie. Want die zit wél in het certificaat voor kelloggs.nl.

Als ik namelijk dat serienummer (zonder ':') opzoek in crt.sh, vind ik (https://crt.sh/?id=11403170519) uitsluitend een precertificate, echter met meer "Subject" info dan de Chrome certificate viewer mij laat zien:

Het blijft een zoekplaatje - dat voor de meeste internetters volstrekt onnavolgbaar is.

Dank je wel Erik

Net alsl ik laat jij zien dat informatieveiligheid alleen mogelijk is als
- die hoge betrouwbaarheid reflecteert
- herkenbaar is door de normale (onwetende) internetgebruiker.
- en dus ‘als vanzelfsprekend’ doorwerkt naar gebruik.

Net zoals transportveiligheid voor wegeninfrastructuur en voertuigen in de wet is ingeregeld.
Dat maakt het mogelijk dat de bestuurders niet eerst hoog technologische kennis nodig hebben voordat zij veilig de weg op kunnen.

Wat jij in je posts hierboven optuigt is een complete database van natrekbare eigenaren van websites en andere services, compleet met een daaraan gelinkte "lijst van notoire criminelen".
Je stuurt er kennelijk op aan dat websites niet meer bedreven kunnen worden tenzij ze volledig gedocumenteerd en traceerbaar zijn, en wilt er een vlaggetje bij "dit is een crimineel!".
Tuurlijk, dat heeft zeker nuttige effecten. Maar is het sop de kool wel waard?

Ik zeg er al bij: als de websitebeheerder dat wil. Als je meteen afrekent hoeft dat niet. Maar als je ergens op rekening koopt of op afbetaling of een abonnement afsluit dan is het toch hardstikke fijn als je weet met wie je te maken hebt zodat je daar later een rechtszaak tegen kunt aanspannen, net zoals jij wilt doen met de website/leverancier waar JIJ niet blij mee bent?
Of zie ik dat verkeerd en wil je wel criminaliteit bij leveranciers aanpakken, maar klanten vrij laten crimineel te zijn?

Je ziet het VOLSTREKT verkeerd.

Overheden (vb: EDIW, CSS, etc) en winstgedreven partijen (vb: https://www.security.nl/posting/851497/Banken+willen+toegang+tot+social+media+en+ip-adressen+voor+monitoring) zijn als DOLLE DWAZEN bezig om, (bij wijze van spreken) onder het permanente toezicht van HUN drones met camera's, al JOUW kleren uit te trekken en jou overal in jouw blote billen te volgen - want JIJ zou (ooit) wel eens een bedreiging kunnen vormen voor HEN.

Dat ZIJ dáármee, of anderszins, een bedreiging zouden kunnen vormen voor JOU, kan helemaal niemand ook maar iets schelen (totdat jij zelf in de shit belandt, maar dan zeggen alle dappere Dodo's om jou heen, net zoals eerder jijzelf deed, dat -ongetwijfeld- JIJ iets stoms gedaan hebt).

Tegelijkertijd dekken ZIJ zich in tegen de weinige overgblijvende risico's, laten hun KvK- en Whois gegevens maskeren en gebruiken DV-certs. "Trust us, you can trust us".

Hoe BLIND kun je zijn?

Lezers: check https://security.nl/posting/851474 voor de visie van een Anonieme reageerder!

@Anoniem 09:40 hierboven: als jij dezelfde bent als de Anonieme reageerder van gisteren 21:13 - ik ben het in grote lijnen met jou eens, dank voor die bijdrage!

De kern van de zaak is m.i. dat browsers (en mail readers etc., maar ook besturingssystemen m.b.t. apps en documenten), m.b.v. info uit certificaten (waarin m.i. meer ruimte moet komen voor aanvullende ident. gegevens), onmiskenbaar moeten tonen:

1) Leesbare en bruikbare identificerende gegevens;

2) Hoe groot de kans op impersonatie was toen die gegevens werden vastgesteld.

Daarnaast is het m.i. essentieel dat eisen, enerzijds t.a.v. user interfaces voor het tonen van "bewijs" van identiteit, en anderzijds gesteld aan certificaatuitgevers, én controles op de naleving daarvan (audits), niet langer aan de branche zelf (hoorde ik iemand "Google dictates" fluisteren?) worden overgelaten, maar worden uitgevoerd door aantoonbaar onafhankelijke partijen waar consumentenorganisaties in vertegenwoordigd zijn. In de eerste plaats zijn het immers de ontvangers die belang hebben bij de bruikbaarheid en betrouwbaarheid van certificaten (nb. criminelen zullen maximale druk blijven uitoefenen om beide aspecten te verzwakken).

Last but not least moeten, om zo veilig mogelijk te kunnen "internetten", alle internetters zich bewust zijn (c.q. worden gemaakt) van het belang van authenticiteit; genoemde software kan daar beslist ook een rol in spelen (bijv. met tutorials).

Dan zijn die woordenboeken vast niet z.g.a.n.

De Haagse ex-ambtenaar Mildred van D. (50) gaf paspoorten uit.
Logischerwijs is de Gemeente Den Haag dus één grote criminele bende.

Mag je zoiets roepen wanneer er (nog) geen veroordelingen zijn?
Hoe moet ik deze informatie die jij zomaar roept valideren?
Laatst deed je datzelfde bij Bunq, waarna ze hun rechtszaak over coulance glansrijk wonnen...
Iets daarvoor klaagde jij juist zelf, elders alhier, dat iedereen zomaar alles kan roepen.

Huh? Big Tech vet aan meeverdient? Dat ontgaat mij.
Overigens is er weinig omzet bij gratis certificaten.

Ik poneerde niet deze ferme aantijging.
Doch, ik bespeur eveneens regelmatig signalen van jouw omgekeerde authoriteitsprobleem.

Is dat inclusief alles grenzend aan cybercriminaliteit?
De zaakjes die nooit voor een rechter zullen komen maar wel opgelost moeten worden?
Zoiets als bijvoorbeeld een waarschuwing aan Flavio Pasquino.

Een Verisign of GlobalSign is in essentie zoveel anders?

Dat eeuwige cliche was toch altijd authenticatie versus autorisatie?
Volgens Google resultaten is authenticatie het bevestigen van identificatie.
Maargoed, wellicht zit Google in dit complot.

Mensen die werkelijk intelligent zijn bedienen zich niet van dergelijke denigrerende discrimatoren.

Dat methode A bestond en werkt, betekend inherent dat methode B niet ook kan gaan bestaan en werken?

Is dat een jouw mening of werkelijk een feit?
Ik dat dat van de taak van encryptie encryptie was.

Je hebt duidelijk nog nooit een OCSP service gerund. En die "leugens" zijn momenteel wellicht hypotetische argumenten - maar "misschien" toch best waarheidsgetrouw hun reden om zinloze overhead te schrappen.
En dat dat zinloos is en geen gemis, zou juist jij toch moeten begrijpen: daar je zelf het hardst roept dat Let's Encrypt niet authenticeert.

Het signaalwoord "alternatief" is exemplarisch.
Ik gok dat jouw vraag is: wie biedt certificaten die niks mogen kosten en OCSP?

Ridouan Taghi? Google? De Bilderberg Groep? Op welk spoor moet ik zoeken? Waarom moet ik raden? Valt er iets te winnen? Wat is het juiste antwoord? Waarom zo vaag? Kun je iets duidelijker zijn in je complot danwel feiten die mij hier totaal ontgaan?

Ik dacht dat HEMA enkel nog online bestond. En Ecco koop je gewoon op zalando.nl
En een bankfiliaal in een winkelcentrum is anno nu nogal onrealistisch. Daarin is Bunq allerminst trendsetter.

Ik ben Joep niet, maar hebben bovengenoemde partijen patent op cybercriminaliteit ongemoeid laten?
Ik meen toch echt dat het juist Google was die het CAA record een RFC maakte en zodoende bij IANA liet registreren.
...nadat de Franse overheids-CA valse gmail.com SSL certifcaten had ingezet bij spionage.

Als we nu terugblikken op jouw omgekeerde authoriteitsprobleem, moet diezelfde criminele Franse overheid dan een rol spelen in identificatie / autorisatie / authenticatie voordat je informatie mag publiceren of consumeren?
(verhuld in een wet als de Europese NIS2-richtlijn die nogal relevant is bij registraties van bonafide danwel malefide domeinnaamregistraties welke essentieel zijn alvorens je een SSL certificaat met of zonder OCSP danwel CRL kunt vergaren).

En als ik een Diginotar "Godwin" mag doen; het verhaal gaat dat de overheid daar een belang had om een soortgelijke rol (zoals Frankrijk) te verhullen. Waar of onwaar, sindsdien is de waarde en het nut van SSL nogal nihil geworden, ondanks dat Let's Encrypt de kwantiteit nogal onvoorstelbaar opgeschaald heeft.

Nee. Die bedrijven hebben hun "governance" overigens wel behoorlijk op orde.
Natuurlijk zou het mooi zijn als een RA/CA boeven kan dwarsbomen, maar hoe te onderscheiden welke aanvrager van een certificaat kwade bedoelingen heeft? Nog los van kwesties als waar de grens dan zou moeten worden getrokken zijn voor zulk een taak gegevens nodig die meestal vanwege goede redenen (o.a. privacy) niet voor een ieder beschikbaar zijn. Bevoegde opsporingsinstanties daarentegen zouden misschien wel meer moeite moeten doen om criminele in het digitale domein aan te pakken.

CACERT(.org) geeft non-profit certificaten uit waarbij werkelijk in persoon is vastgesteld dat de houder is wie hij pretendeert te zijn, d.w.z. je moet met je paspoort langs bij een "assurer" (in NL meestal iemand bij SURF of het CWI) die dan nota neemt van de identiteit. De regels waaraan alle processen van cacert moeten voldoen zijn zeer strikt (maar het gedoe erover is vergelijkbaar met de discussies die Debian ook wel kent). Een ander alternatief voor certificaten uitgegeven door CAs zou DANE kunnen zijn; daarin wordt voortgebouwd op de authenticiteit die middels DNSSEC wordt bewerkstelligd.

Wat ik nooit heb begrepen is waarom de ontwikkelaars van webbrowsers, zelfs ook Mozilla, de root certs van cacert niet hebben opgenomen en ook geen ondersteuning voor DANE validatie bieden.

Gut gut gut daar hebben we onze anonieme beroepstrol weer.
Je leest mijn posts niet (https://security.nl/posting/851372) maar brult wel.

Ik had op dat moment andere bezigheden. Het was een waardeloze advocaat die zijn pleidooi uitsluitend baseerde op een kansloos argument, uit https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBAMS:2024:3461
gevolgd door financiële eisen.

Je leest mijn posts niet (https://security.nl/posting/851372) maar brult wel.

en
Lastig discussiëren met een "securityspecialist" die het verschil tussen signing en encryption niet snapt.

Je leest mijn posts niet (https://security.nl/posting/851316) maar brult wel.

Insgelijks.

Je verdraait mijn woorden weer eens: ik claim nergens dat Let's Encrypt niet authenticeert.

Dwaas.

Doe jezelf een lol: open https://www.virustotal.com/gui/ip-address/188.114.96.0/relations en druk een paar keer op ••• onderaan het bovenste blok.

Links rood: hoogstwaarschijnlijk cybercriminelen die zich verstoppen achter een van vele Cloudflare IP-adressen - de meeste met certificaten van "Google Trust services".

Links groen: waarschijnlijk nog niet op de radar van AV-boeren (de domeinnaam is meestal veel- (in de zin van niets) zeggend.

En lees ook, 1 jaar oud maar nog hartstikke actueel: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/its-raining-phish-and-scams-how-cloudflare-pages-dev-and-workers-dev-domains-get-abused/.

Via Google's Firebase en andere cloudservers worden gigantische hoeveelheden malware verspreid.

Hoe veilig internet is, is een keuze. Op basis van het resultaat van elke keuze moet je besluiten welke zaken je dan nog wel via internet kunt afwikkelen, en voor welke zaken de risico's te groot worden - daarbij rekening houdend met menselijk gedrag, in plaats van te blèren dat het hun eigen schuld is als (nagenoeg invloedloze) internetters slachtoffer worden van het gekozen systeem.

Mijn papieren Van Dale is inderdaad niet de nieuwste editie. De afkorting z.g.a.n. (zo goed als nieuw) staat er wel in, maar z.g.a. niet, en de actuele online-versie en andere online woordenboeken die ik al had geraadpleegd bevatten het ook niet. Ik weet nog steeds niet wat je met "ware het niet dat de surfer als z.g.a. minuut daarvoor verder gegaan was met zijn/haar leven" bedoelt. Mij lukt het tot nu toe woorden in te vullen die met z, g en a beginnen die een kloppende zin opleveren. Kan het zijn dat er ook nog iets anders rammelt aan de zin?

Ik ga er niet wakker van liggen, maar het was aardig geweest als je gewoon even had aangegeven wat je nou eigenlijk bedoelde te zeggen.

Slecht excuus van Lets Encrypt. OCSP Stapling wordt al heel lang ondersteund.
OCSP-must-staple maakt dit nog veiliger, maar helaas is de ondersteuning daarvan slecht.

Dit heb ik zelf een tijd gedaan. Super gebruiksonvriendelijk aangezien je constant allerlei sites niet kan bezoeken, omdat de OCSP servers slecht onderhouden worden en niet snel gefixed worden als ze down gaan.