Ook in dit stukje de veel gemaakte fout..

certificaten versleutelen niet (dat doet het server protocol)..

certificaten verifieren alleen of het ip bij de hostnaam hoort.

Chrome geeft certificaten niet verkeerd weer, het is de bedoeling dat ze zo weergegeven worden. Voor de prijs die je voor EV certificaten betaald, mag je wel verwachten dat CA's nu hun zaakjes op orde hebben mbt Certificate Transparency.

Volgens mij worden ze niet verkeerd weergegeven, maar precies zo als Google van plan was. Google stelt gewoon iets strengere eisen om ze als 'groen' in de adresbalk te tonen.

Edit: Netcraft geeft in hun artikel zelfs aan dat het "flawed EV certificates" zijn, dus kun je ook stellen dat juist de andere browsers het niet goed doen. In elk geval geeft het woord "verkeerd" in bovenstaande titel een te sterk waardeoordeel over dit gedrag.

Certificate Transparency is een mooi project om valse certificaten tijdig te kunnen ontdekken.

Het zou prettig zijn als Chrome een extra hangslotje toont (met uitleg) wanneer CT-informatie correct is.
Maar om certificaten als minder sterk te tonen is misbruik van de macht als browser-bouwer.

Bovendien lost CT het onderliggende probleem niet op: Hoe kan een eindgebruiker bepalen *welke* CA er door de site-eigenaren gekozen is. DNSSEC met DANE doen dat wel. Waarom biedt chrome geen ondersteuning daarvan?

Het artikel zegt: . Ik begrijp hieruit, dat dit iets is dat specifiek van Google afkomt? In dat geval gaat het dan om een afwijking t.o.v. de algemeen afgesproken werkwijze. Wanneer MS dat zou doen, werd die club hier openlijk geroosterd. Hopelijk kan iemand die de standaard kent/weet te vinden even aangeven hoe het zit en kunnen we dan verder gaan?

Dit is natuurlijk de werreld op zijn kop. Je koopt een ev sslcertificaat en het wordt niet als ev sslcertificaat weergegeven. Dan zou ik me als site toch bekocht voelen. Zeker omdat firefox het wel als een geldig ev sslcertificaat laat zien.

Bijna goed, de browser checkt of het certificaat bij de hostname hoort.

Het protocol versleuteld (het eerste stuk van de communicatie) aan de hand van het certificaat, totdat een symmetrische sleutel is overeengekomen waarmee de rest versleuteld wordt.

En certificaten verifiëren niets, en al helemaal geen IP adres.
Je browser controleert aan de hand van de CN van het certificaat of je op de juiste website zit, meer niet! IP doet er niet toe!

Het is dus een door Google zelf verzonnen eis.

Meeste recente versie van de standaard: https://cabforum.org/wp-content/uploads/EV-V1_5_4.pdf

Certificaten versleutelen niks en verifiëren niks.
Certificaten zijn zelf versleuteld, en bevatten slechts gegevens die de authenticiteit van een website(s) moet bevestigen.
Ze worden bij aangaan van de verbinding door de browser ontsleuteld, en (beperkt) gecontroleerd door de browser.
Dankzij zgn. "a-symmetrische versleuteling" kan het certificaat tijdens overdracht niet worden buitgemaakt door de lijn
af te luisteren. Op die manier kan dus niemand het certificaat stelen (als de a-symmetrische versleuteling tenminste sterk genoeg is) om zich vervolgens ook als die website voor te gaan doen. En dat is wel zo veilig.

Versleuteling van de data is een hele andere versleuteling, en hangt totaal niet af van het certificaat.
Onafhankelijk van het certificaat komen browser en webserver hierbij een SSL type protocol overeen
(TLS1.0, TLS1.1, etc.) en een encryptiecipher die webserver en browsercliënt allebei kennen.

Browsers verifiëren certificaten van bezochte websites steeds zoveel mogelijk op echtheid, afwijkingen en geldigheid.
Hierna zouden gebruikers eigenlijk nog moeten verifiëren aan de hand van gegevens in URL balk en certificaatdetails
of het inderdaad 100% de juiste website is, en afwegen wat het risico van eventuele geconstateerde afwijkingen is.
Bij EV certs. wordt in het algemeen verondersteld dat groene balk al genoeg zekerheid biedt.

Goeroehoedjes

Google heeft het bedacht, maar het heeft al een aanhanger hoor:
https://www.security.nl/posting/411597/Firefox+gaat+Google%27s+aanvulling+op+SSL+ondersteunen

Goeroehoedjes

Nee, het IP-adres is totaal irrelevant. De essentie is dat de public key in het certificaat hoort bij de domainname van de server, zoals getoond in de URL-balk van de webbrowser (in de plaatjes in het artikel van de redactie is dit "online.lloydsbank.co.uk").

Als het goed is beschikt uitsluitend de server over de private key (die hoort bij de public key in het certificaat). De browser controleert dit door een random getal te versleutelen met de public key uit het certificaat; uitsluitend de bezitter van de private key kan dit getal ontsleutelen. Zodra de server het ontsleutelde getal heeft teruggestuurd naar de webbrowser, weet die laatste zeker dat het om de bedoelde server moet gaan (waarvan de domainname in de URL balk van de browser wordt getoond). Dit natuurlijk onder voorwaarde dat de private key niet gekopieerd is of op andere wijze uit de public key kan worden herleid.

De rol van de certificaatuitgever is om, in meer of mindere mate, te controleren dat de aanvrager voor de betreffende server (zoals "online.lloydsbank.co.uk") een certificaat mag aanvragen. Als zij dat niet zouden doen kan iedereen een asymmetrisch sleutelpaar genereren en een certificaat voor bijv. "online.lloydsbank.co.uk" aanvragen.

Deze uitleg is onjuist. Certificaten zijn niet versleuteld en worden ook niet verzonden via een versleutelde verbinding. Er is helemaal niets geheim aan of in een digitaal certificaat.

Kijk maar eens met Wireshark naar het opzetten van een SSL/TLS verbinding: Wireshark kan certificaten dan volledig decoderen. Het enige dat wel versleuteld is in een certificaat, is de digitale handtekening. Dit is een secure hash (bijv. SHA-1 of SHA256) over het feitelijke certificaat; die secure hash is met de private key van de ondertekenaar versleuteld.

Dat klopt wel.

Ja, ik was er al bang voor dat ik dit in mijn streven naar eenvoud wat al te simplistisch had voorgesteld. ;-)
Een voorbeeld met uitleg van hoe het er in detail aan toe gaat, kan men hier vinden: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

Het klopt helemaal dat alleen de digitale handtekening (én de "exchange keys") versleuteld (encrypted) over de lijn gaan.
Maar deze digitale handtekening maakt deel uit van het certificaat. Dus daarmee is ook het certificaat in een bepaalde zin
in zichzelf "versleuteld". Of misschien moet ik zeggen: alle waarden zittten "op slot" met die digitale handtekening.
Of kun je als MITM iets van de zichtbare, "niet encrypted" certificaatwaarden aanpassen zonder dat de cliënt browser foutmeldingen geeft? (ik heb dit eerlijk gezegd nog nooit uitgeprobeerd omdat het me volkomen logisch leek)

Goeroehoedjes

Ja, daar heb ik destijds veel van geleerd!

Het is muggenziften, maar je kunt stellen dat de digitale handtekening geen deel uitmaakt van het certificaat zelf, wel van het "bestand" dat over de lijn gaat.

De essentie van een digitale handtekening is dat je niets onopgemerkt in een "document" (certificaat in dit geval) kunt wijzigen. Dit kan fout gaan als een zwakke cryptografische hash is gebruikt (zoals MD5, zie "5.5. Results" in https://www.win.tue.nl/hashclash/rogue-ca/). Omdat er twijfels bestaan over SHA1 staat deze "op de lijst" om te worden afgeschaft.

Kun je stellen dat een waardepapier zonder echtheidskenmerken nog steeds een waardepapier is? ;-)

Ok, dus je zou toch wel kunnen zeggen dat een certificaat (defined als: alle certificaatwaarden + digitale handtekening)
in zichzelf is versleuteld. Niet in de zin van "alles is encrypted" of: "alles gaat encrypted over de lijn",
maar in de zin dat de digitale handtekening (waarvan men vanuit hiervoor genoemde "waardepapierlogica" al muggenziftend ook wel weer zou kunnen stellen dat deze toch eigenlijk wél deel uitmaakt van het certificaat...)
het onmogelijk maakt om zomaar iets in het certificaat te veranderen, zodat alles in het certificaat in feite "op slot" zit.

Dan heb ik dus wat ik aanvankelijk stelde ("Certificaten zijn zelf versleuteld") in een bepaalde zin toch wel goed gezegd
(en het in ieder geval juist bedoeld), maar voor een expert klonk dit wat ongelukkig vanwege mijn wat eigenaardig gebruikte terminologie in dit verband? ;-)

Goeroehoedjes