"Certificatenhandel blijkt zwendel".

Hoe is dit nieuws? Vertelt'ie iets wat we niet al wisten?

Dat heeft hij dan fout!

De versleuteling van de verbinding vindt plaats met sessie keys die worden uitgewisseld met de partij waarmee
gecommuniceerd wordt. Dit kan alleen als er een certificaat is waarmee de tegenpartij vertrouwd wordt, anders
kan iedere willekeurige man-in-the-middle dit uitwisselingsproces halfweg onderbreken, naar beide kanten sessie
keys uitwisselen en de data onderweg decrypten en her-encrypten. Hij kan dan meekijken met de plaintext data.

Dus de certificaten (en het vertrouwen erop) zijn wel degelijk van groot belang voor de versleuteling. Zonder vertrouwd
systeem van certificaten kun je die versleuteling net zo goed weglaten.

Enkele verschillen tussen gratis en betaald.

Gratis
- wel versleuteling HTTPS
- geen Support
- geen garantie
- maar 3 maanden geldig

Betaald
- wel versleuteling HTTPS
- wel Support uitgever
- wel garantie
- langer geldig (meerdere jare)

Nope, hij is correct. Jij hebt het fout :-) De rest van zijn uitleg ontbreekt hier in het Nerderlands.
Hij vervolgt:

The encryption of data is handled by server configuration and not the certificate. Let's take a look at a few cipher suites to prove the point though. Let's say we have a 2048 bit RSA key and we obtain a certificate, you're going to see a cipher suite that looks something like this in production.


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Let's quickly break this down so we understand each of the components.


TLS - The protocol being used.
ECHDE - The Elliptic Curve Diffie-Hellman Ephemeral key exchange, supports Forward Secrecy.
RSA - The key used for authentication, in this case our 2,048 bit RSA key.
AES - Advanced Encryption Standard, the symmetric encryption algorithm used for encrypting data.
128 - The symmetric key size.
GCM - Galois/Counter Mode, we're using authenticated encryption (AEAD).
SHA256 - The Message Authentication Code used for integrity checking.

Looking at that list, the only component that a certificate has any bearing on is the key used for authentication. In the example above we're using a 2,048 bit RSA key but we don't even list the size of the key in the cipher suite, just the key algorithm. The particular cipher suite above is using AES with a 128 bit key but if we wanted to increase that to AES with a 256 bit key, we'd simply change our configuration to use a different suite.


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256

Now we're using 256 bit encryption and we didn't change anything to do with the certificate, we could still be using exactly the same certificate. In fact, different clients may negotiate either one of these two cipher suites depending on their capabilities. We can even change our authentication key and get an ECDSA certificate, but they're still nothing to do with the encryption, we just update the cipher suites again.


TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA256

Talking about the strength of encryption you can use when purchasing or obtaining a certificate is a bit like talking about whether or not your site can have responsive design when purchasing or obtaining a certificate. It has nothing to do with the CA or the certificate and is entirely down to the site to configure and control.

Hoezo "maar"? Dat klinkt alsof je het slechter vind.

Bij een certificaat is het juist positief als hij zo vaak mogelijk vernieuwd wordt. Des te minder data met een bepaald certificaat versleuteld is, des te minder interessant het wordt de date te bewaren om in toekomst eens te ontsleutelen. (Met kwantumcomputers)

Bedoeld wordt dat de public key in TLS servercertificaat en de bijbehorende private key tegenwoordig, technisch gezien, geen onderdeel uitmaken van het proces waarbij browser en server een symmetrische sessiesleutel overeenkomen - mits van de tegenwoordig gebruikelijke Diffie-Hellman key agreement gebruik gemaakt wordt.

In dat geval verifieert de browser in een transactie die technisch gezien losstaat van de versleuteling van de sessie of de server over de private key behorende bij de public key in het certificaat beschikt, uitsluitend ter authenticatie van de server.

Dus ja, het certificaat is essentieel voor de authenticatie van de server (voor eindgebruikers bij voorkeur eenduidige authenticatie van de eigenaar van de server - want cybercriminelen maken regelmatig gebruik van nepsites met "lijkt op/klinkt als" hostnames) maar speelt -bij een Diffie-Hellman key agreement- geen rol bij de versleuteling van de sessie.

In https://www.security.nl/posting/532047/ESET%3A+Providers+voorzien+downloads+van+overheidsspyware#posting532389 licht ik nader toe hoe e.e.a. in z'n werk gaat.

Erg handig met e-mailen of bestanden ondertekenen dat een certificaat om de 3 maanden vervalt. Dan zul je een heel archief moeten bijhouden om je oude bestanden nog te kunnen openen.

Wel vreemd dat een gratis certificaat maar 3 maanden geldig is, dat maakt het in veel gevallen compleet nutteloos. Oké een website op https houden zal nog wel lukken aangezien de meeste browsers dan wel weer ge-update zijn. Maar ja een gewone informatieve website dwingen naar https slaat ook nergens op dat maakt je server alleen maar kwetsbaar door het lekke openssl te draaien.

Garantie op een certificaat is iets wat een gebakken lucht verhaal is. Het klinkt leuk, gaat nergens over.

De support.... Tja... Hoeveel support heb je nodig. De CA's verwijzen je door naar de software makers of de fabrikanten. De reseller Kan je nog wel eens in de juiste richting duwen maar dat zijn vaak ook knurften.

Onzin.
Als je slechts ondertekent (maar niet encrypt) kun je je bestanden gewoon lezen . En ook met een verlopen certificaat kun je controleren dat de ondertekening klopt. Het is alleen een keuze van de software om een error te geven als een datumveld in het certificaat ouder is dan "nu" . Het is geen cryptografische blokkade .

Er valt wat voor te zeggen om bij lang opgeslagen documenten met digitale handtekening te melden of het tekenende certificaat geldig was tijdens in de periode dat het document getekend werd - dat het _nu_ niet meer geldig is ook nuttig om te weten , maar niet zo cruciaal.

Als documenten ook gecrypt zijn zal de bijbehorende private key bewaard moeten zijn om ze nog te kunnen lezen.
Maar dat heeft niets te maken met de geldigheidsduur van een certificaat - hooguit dat je bij kortlopende certificaten wat meer private keys te bewaren hebt . Maar bewaren moet je, voor zolang als je toegang nodig hebt tot data die versleuteld zijn met de public key. En als je je private key verliest heb je er niks aan dat het certificaat lang geldig - je kunt er niets meer mee.
Het gaat hier dan om private keys van degene aan wie een bericht gericht is , versleuteld met diens public key .
Eventueel, als je een 'kopie to self' ook meestuurt ben je dat zelf ook.



Huh - browsers ge-update ? Dat heeft niets te maken met vervangen van webserver certificaten . (alleen als er nieuwe certificaat authorities ontstaan zijn).
De website eigenaar is degene die elke drie maanden aan de bak moet , maar de browser heeft geen update nodig .

Juist daarom wordt tegenwoordig Diffie-Hellman gebruikt: als het lukt (met quantum computer of op andere wijze) om de private key uit de public key in het certificaat te herleiden, heb je daar helemaal niets aan om de versleutelde sessiedata te ontsleutelen.

Vereenvoudigd kun je Diffie-Hellman ook zien als een asymmetrisch sleutelpaar dat, in het ideale geval, voor elke sessie opnieuw wordt gegenereerd. Versimpeld stuurt de server het volgende naar de webbrowser:
1) een public key ter authenticatie (die public key zit in een certificaat ondertekend door een certificaatuitgever die bevestigt dat de public key bij die server hoort);
2) een andere public key uit een vers gegenereerd keypair.

De webbrowser:
1) checkt het certificaat, versleutelt een random getal met de public key uit het certificaat en stuurt dat naar de webserver. De webserver ontsleutelt dat getal en stuurt dat terug. Daarmee weet de client dat de server over de private key in het certificaat beschikt;
2) versleutelt een ander random getal, te gebruiken als AES sleutel, met de tweede en verse public key die de server stuurde, en stuurt het resultaat naar de server. Die pakt het uit waarna beiden de AES sessie key kennen - waarmee de rest van de sessie wordt versleuteld.

Dit is sterk vereenvoudigd wat er gebeurt bij een DH key agreement. Om achteraf bij de data te komen heb je niks aan de private key behorende bij de public key in het certificaat - want die wordt alleen nog gebruikt voor authenticatie (daarom heet dit proces forward secrecy). Een aanvaller zal de DH "private key" moeten terugrekenen uit de public key, en naar verwachting kunnen quantumcomputers dat binnen afzienbare tijd. Echter, als voor elke sessie een nieuw uniek sleutelpaar wordt gebruikt, kan alleen maar die sessie worden ontsleuteld als het lukt om de DH "public key" te kraken.

De korte geldigheidsduur bij certificaten is verstandig om de schade te beperken (in tijd) voor het geval dat een private key in handen van (kwaadwillende) derden valt - op dit moment nog niet door kraken maar door diefstal van minder goed beveiligde servers - en (voor wat dat waard is) om het leed bij onterecht afgegeven certificaten in tijdsduur te beperken. Voor degenen die het überhaupt checken is een korte looptijd een nadeel omdat het vertrouwen dat een certificaat niet onterecht is afgegeven, elke keer opnieuw moet worden opgebouwd.

@Anoniem gisteren 19:33: het gaat hier expliciet om TLS server certificaten.

Scott Helme staat bij mij helemaal niet hoog op de lijst van betrouwbare bronnen mbt cybersecurity. De man is vooral een hipster.

LetsEncrypt biedt helemaal niet de "vetting procedure" welke voor de 'extended validation' certificates gebruikt wordt. Het biedt vrij zwakke versleuteling aan met een beperkte geldigheid. Ook het werken met letsencrypt tools is verre van vanzelfsprekend.

Wat niet wegneemt dat de bedragen welke voor certificates gevraagd worden exhorbitant zijn tegenover het werk dat er wordt verzet bij het aanmaken ervan, enkel voor EV certificates en dergelijk is een hogere prijs gerechtvaardigd. Hoewel dat ook niet zoveel voorstelt, zoals ian.sh reeds kon aantonen.

De vele inbreuken tegen de certificate vetting procedures zorgden ervoor dat binnenkort niet weinig CA zullen geweigerd worden door zowel Mozilla als Google Chrome.

Maar de conclusie dat certificaat trust steeds meer onder druk komt te staan, mag gerechtvaardigd heten, toch?
Bitwiper, leg het nog eens uit, waarom certificering steeds minder om het lijf heeft.

Jodocus Oyevaer

1.Goedkope certificaten hebben vaker de controle minder goed voor elkaar. Met een certificaat dat nooit aan een bepaald persoon uitgegeven had mogen worden zou een nepsite kunnen worden opgezet die net echt lijkt inclusief certificaat.

2.Ook willen fraudeurs liefst zo weinig mogelijk geld uitgeven.
Daarom zijn dure certificaten veiliger, want die zijn qua prijs minder aantrekkelijk voor fraudeurs dan goedkope certificaten.
(wat niet wil zeggen dat het dan never, nooit fout kan gaan; kijk naar Symantec)

de goedkope/gratis certificaatboeren moeten aan dezelfde eisen voldoen als de niet-gratis om vertrouwd te worden door browser. Je link naar fraudeurs volg ik niet, is ook niet het doel van een certificaat om hier iets te doen. Het gaat erom dat de informatie overdracht met een andere partij op een veilige manier gebeurd, of dat nu een fraudeur is of niet.

Onzin, dat kan ook prima zonder certificaat. Als je wel eens ssh gebruikt hebt (en je een beetje in de werking ervan hebt verdiept bijv. via https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process), weet je dat daar geen certificaat aan te pas komt.

Maar ook met certificaten heb je niet persé een certificaatverstrekker nodig; self-signed certificaten zijn immers ook mogelijk. Bijv. Microsoft's RDP (Remote Desktop Protocol) maakt hier by default gebruik van.

De enige reden dat we self-signed certificaten niet blindelings vertrouwen, is dat er geen vertrouwde derde partij heeft vastgesteld dat:
1) Op zijn minst: de public key in het certificaat hoort bij de domeinnaam in datzelfde certificaat en de aanvrager de rechtmatige eigenaar van die domeinnaam is (of geautoriseerd is om namens die eigenaar dat certificaat aan te vragen);
2) Bij voorkeur: naast de domeinnaam zijn ook uniek identificerende gegevens van de eigenaar van de domeinnaam (vaak een organisatie) opgenomen, en is vastgesteld dat die allemaal bij elkaar horen en de aanvrager geautoriseerd is om, namens de organisatie, dat certificaat aan te vragen.

Bij DV (Domain Validated) certificaten gebeurt zelfs 1 niet volledig betrouwbaar, en daarom noem ik ze speelgoedcertificaten. Helaas is het zo dat zelfs leveranciers van EV certificaten de benodigde checks onvoldoende goed uitvoeren, waardoor ook de betrouwbaarheid van EV certs te wensen overlaat.

En zoals ik al vaker geschreven heb: de essentie van authenticatie is meestal niet dat jij kunt bewijzen dat jij jij bent, maar het verhinderen dat iemand anders kan bewijzen dat hij jij is. Kennelijk vinden de meeste admins de kosten van een certificaat voor hun webserver belangrijker dan dat ze zich zorgen maken over bezoekers die worden misleid op een fake site met een onterecht voor hun domeinnaam, of voor een lijkt-op-domeinnaam, uitgegeven certificaat. En dat vind ik kortzichtig.

Dit is niet fout, maar juist.
Het certificaat heeft inderdaad niets te maken met hoe de data wordt vesleuteld, maar wordt gebruikt ommde session key af te spreken.
Dit kan op meerdere manieren (zoals een pre-shared key). Een certificaat is 1 van de mogelijkheden om de session key veilig af te spreken tussen de peers.

Als je mijn bijdragen hierboven had gelezen, had je geweten dat dit vroeger gebruikelijk was maar tegenwoordig niet meer. Google eens naar "Diffie-Hellman" en spijker je kennis bij...

"Er is absoluut geen verschil tussen een gratis certificaat en één waarvoor je moest betalen", besluit de onderzoeker."

Als leek meen ik deze stelling als waar aan te mogen nemen, ook gelet op de vaak welles en nietes meningen hier op dit forum, die namelijk niet overlopen van zichtbare kennis op dit gebied, maar meer de indruk wekken dat ze worden geplaatst om iemand zijn gelijk te halen.

Wie een email certificaat nodig meent te moeten hebben, moet dan wel voor lief nemen, dat deze alleen maar gebruikt kan worden middels een e-mailprogramma zoals o.a. de twee bekendste en meest gebruikte Thunderbird en Microsoft Outlook. Immers webmail van Microsoft en Google ondersteund geen certificaten, tenzij men een betaalt abonnement neemt.

Feit is ook, tenzij iemand dit inhoudelijk tegenspreekt, dat een aanschaf van een gratis (e-mail) certificaat betekend dat de uitgever over de aanvrager zijn wachtwoord van dit certificaat blijft beschikken. Het certificaat wordt namelijk gegenereerd op de website van de uitgever, en daarna aan de aanvrager verstuurt.

Beste posters in deze draad en met name de door mij zeer gewaardeerde certificeringsdeskundige, Bitwiper,

En wanneer worden de vervalste certificaten waarmee de Amerikaanse overheidsdiensten https verbindingen afvangen voor staatsspyware injectie en redirect doeleinden eens gedetecteerd of aan de kaak gesteld?

Lees (gedateerd maar nog steeds actueel): https://www.wired.com/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/.

Als Gooigle daar met twee maten meet, wat maakt dan die hele Symantec SSL certificaat sanering uit?
Waarom https everywhere als het toch niet helpt tegen gesnuffel van ... of ....?

Straks is het "trust has gone out of the window like privacy has".

Wie helpt? Kaspersky's misschien, die kan in dat kamp toch al geen goed meer doen. Daarom zijn hun detecties zo interessant net als DrWeb's uit St. Peterburg. Andere bedrijven staan al lang "under gag order".

luntrus

Dit is niet fout, maar juist.
Het certificaat heeft inderdaad niets te maken met hoe de data wordt vesleuteld, maar wordt gebruikt ommde session key af te spreken.
Dit kan op meerdere manieren (zoals een pre-shared key). Een certificaat is 1 van de mogelijkheden om de session key veilig af te spreken tussen de peers.