Kijk, voortvarende actie.

Toevallig genoeg was Mozilla juist op het moment van de aankondiging al bezig met de laatste fase van het uitschakelen van SHA-1, zodat dit eigenlijk geen reactie is op de succesvolle collission maar er precies mee samenvalt. Dit valt op te maken uit hun issue tracker.[1]

Hoewel Firefox 52 pas op 7 maart uitkomt,[2] wordt de fix volgens [1] op dit moment uitgerold via een zogeheten System Add-On, een mechanisme dat Mozilla heeft gebouwd om wijzigingen in Firefox aan te brengen zonder een nieuwe versie te hoeven te publiceren.[3]

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1339662
[2]: https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates
[3]: https://gecko.readthedocs.io/en/latest/toolkit/mozapps/extensions/addon-manager/SystemAddons.html

Ik snap dat SHA1 certificaten geblokkeerd moeten worden. Maar kan iemand mij uitleggen waarom je nooit iemand hoort over de certificate tree waarbij de hoogste in de tree eigenlijk in bijna alle gevallen nog op SHA1 werkt.

Ik snap dat het veel werk is om overal de rootcertificates bij te werken. Maar ze zouden toch al kunnen beginnen met een aanzet hierin, en daar zie ik ook weinig van.

Of zie ik dit helemaal verkeerd?

Verkeer wordt toch nooit versleuteld met de root certificaten, dus die prio is niet zo hoog. Daarnaast is er nog genoeg oud spul wat niet goed werkt met SHA2, dus voorlopig zal dit nog wel even blijven.

Resellers van Symantec en GlobalSign kunnen vaak wel gewoon kiezen voor een full-SHA2 chain. Echter komt het te vaak voor dat dit dan weer op een andere root komt ivm backwards compatibility.

Ben net overgestapt naar het ESR update kanaal (van 51 naar hopelijk ESR51.xx)

En aan het testen met Palemoon (omdat het wegzetten van de XUL door Mozilla me niet bevalt).

Dus vraag ik me af of SHA-1 in die programmaversies eveneens verboden wordt of uit te zetten is.

De eventuele truc door in about:config de sleutel security.pki.sha1_enforcement_level op waarde 2 te zetten gaat denk ik niet werken bij Pale Moon, want die sleutel bestaat daar niet.

Weet iemand trouwens een goede site waar je kunt testen of je browser correct ingesteld staat voor SHA-1 weigeren? Heb wel sites gezien waar je een server kunt laten testen, maar niet voor browsers.

Ja.

Rootcertificaten zijn self-signed certificaten - en daarmee inherent onbetrouwbaar, omdat iedereen zo'n certificaat kan maken en zelf ondertekenen (de hash speelt alleen een rol in die ondertekening). Veel meer dan een public key, een (hopelijk unieke) uitgeversnaam en een geldigheidstermijn is het niet. Essentieel bij rootcertificaten is dat de overdracht daarvan tussen de uitgever, eventueel via de verspreider (Microsoft, Oracle, Mozilla, Linux distro's etc.) en eindgebruikers op andere wijze grondig wordt beveiligd.

Overigens verbaast het mij dat we niet een model hanteren waarbij de verspreider van rootcertificaten die certificaten ondertekent; immers zij moeten er garant voor staan dat rootcertificaten daadwerkelijk van een CA afstammen.

Onverantwoordelijk vind ik het dat sommige partijen rootcertificaten ter download aanbieden via ongeauthenticeerde en onversleutelde verbindingen, zoals onze overheid hier [1] (de verbinding met de webpagina vindt plaats via https, maar downloads van certificaten via http). Toegegeven, er staat een verwijzing bij naar de staatscourant waarin hashes van deze rootcertificaten zijn gepubliceerd. Helaas zijn dat, zelfs van het redelijk recente PKI Overheid EV Root CA certificaat [2], SHA1 hashes...

[1] https://cert.pkioverheid.nl/
[2] https://zoek.officielebekendmakingen.nl/stcrt-2011-527.html

Inderdaad, mijns inziens mogen ze hier ook al mee beginnen alhoewel het risico vele malen kleiner is: een root certificate is self-signed (de hash-waarde wordt digitaal ondertekend) en staat geïnstalleerd op de client's PC. Het certificaat is dus al vertrouwd en een hash-collision kan hoogstens ervoor zorgen dat het certificaat onopgemerkt vervangen kan worden in de trust-store. Al heb je dan al een ander groot probleem, als een aanvaller je trust-store kan manipuleren!


https://badssl.com/, al zijn de test-cases voor SHA1 hier voor oude certificaten die al verlopen zijn...

Wat een beetje jammer is bij al die voortvarende veranderingen aan de certificaat afhandeling is dat er ook situaties
zijn waarin de certificaten niet "even" kunnen worden ge-update. Als je een of ander device hebt wat https gebruikt
voor een web beheer pagina dan is er met moderne browsers bijna niet meer mee te werken omdat het certificaat
of de door het device gebruikte SSL versie dan wel encryptie methode niet aan de huidige eisen voldoet.
De firmware updaten kan niet altijd (wordt niet meer vernieuwd, moet ook via die webinterface, whatever) en het wordt
steeds lastiger om nog wat te doen als je niet een stokoude browser bewaart voor dit soort situaties.

Doe eens een scannetje hier:

https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp

Of hier: https://www.htbridge.com/websec/

Er zijn er nog veel meer en nog bekendere ook. o.a.: https://www.digicert.com/help/

Aangaande het probleem, dat alreeds vrijwel overal uitgefaseerd had moeten zijn:
https://shaaaaaaaaaaaaa.com/check/

Geniet van het weekend en je nieuwe week,

luntrus

Het root certificaat wordt sowieso vertrouwd door je webbrowser. De signature is onbelangrijk aangezien deze niet geverifieerd wordt.

Voor alle certificaten eronder, wordt er via de signature geverifiëerd of ze wel echt door het bovenliggende ondertekend werden
Hierdoor de de veiligheid (meer bepaald de "collision resistance") van de signature dus zeer belangrijk, maar voor een root certificaat dus niet.

Verkeer wordt nooit versleuteld door of met de certificaten...

Ze dienen enkel voor peer authentication.
Voor HTTPS wil dat zeggen dat er wordt geverifieerd of de hostname die je hebt ingetypt ook wel overeenkomt met het certificaat op de server. Indien dat zo is, weet je dat de server een geldig certificaat heeft voor die hostname.

Encryptie staat er lost van, maar een correct certificaat is belangrijk, anders heb je geen idee met wie het een geëncrypteerde verbinding bent aan het opzetten en dan heeft het natuurlijk weinig zin...

(HTTPS kan ook "peer authentication" doen zonder dat er encryptie gebeurd.)