Chrome gaat waarschuwingen tonen bij sites met sha-1-certificaten

Google heeft aangekondigd om gebruikers van de Chrome-browser vanaf begin 2016 te gaan waarschuwen voor websites die sha-1-certificaten gebruiken. Het bedrijf wil het hashing-algoritme vanaf uiterlijk januari 2017 volledig gaan blokkeren.

Hiermee laat Google op zijn beveiligingsblog weten dat Chrome de sha-1-certificaten niet meer als veilig zal beschouwen. Daarom gaat de browser vanaf begin 2016 waarschuwingen weergeven wanneer de gebruiker naar een website gaat die gebruikmaakt van het certificaat. Eerst gebeurt dit alleen als het certificaat is uitgebracht op of na 1 januari 2016 en gekoppeld is aan een publieke certificaatautoriteit. Google geeft aan uiterlijk vanaf 1 januari 2017 bij alle websites die een sha-1-certificaat gebruiken een kritieke fout weer te geven, maar overweegt dit te vervroegen naar 1 juli 2016.

Google, Microsoft en Mozilla lieten eerder al weten te gaan werken aan een oplossing voor het veiligheidsprobleem dat het verouderde sha-1-certificaat met zich meebrengt. Alle drie de bedrijven gaven aan na 1 januari 2017 het certificaat te gaan blokkeren. Microsoft kondigde daarna aan om deze datum naar voren te schuiven vanwege steeds grotere veiligheidsrisico's, zoals de freestart collision-aanval in oktober. Google overweegt hetzelfde om gelijke redenen.

De veiligheidsproblemen met sha-1-certifaten waren al langer bekend, maar zijn pas sinds kort relevant omdat het steeds goedkoper is geworden om het certificaat aan te vallen. Door middel van collision of botsingen is het mogelijk om een vals certificaat de plaats in te laten nemen van een legitiem certificaat. Daardoor is de veiligheid van een verbinding niet meer te garanderen. Het sha-1-certificaat wordt gebruikt voor de verificatie van ssl/tls-beveiliging van bijvoorbeeld online betalingen.

In oktober vroegen verschillende bedrijven, waaronder Symantec en Microsoft, nog om uitstel voor het uitfaseren van sha-1-certificaten. Vanaf 1 januari mogen certificaatautoriteiten namelijk geen sha-1-certificaten meer uitgeven. Het uitstel werd aangevraagd omdat niet iedereen beschikt over een browser die sha-2-certificaten ondersteunt. Dit verzoek werd teruggetrokken nadat een team van cryptologen had opgeroepen tot sneller stoppen met sha-1-certificaten toen duidelijk werd hoe relatief goedkoop en snel het kan worden aangevallen.

Reacties (50)

Testen hoe je browser reageert kan via https://badssl.com

Je kan je site testen via de link van @hendrickbert

[Reactie gewijzigd door nullr0ute op 21 december 2015 11:46]

Je kan je eigen website testen via:
https://www.ssllabs.com/ssltest/

Als bonus: altijd handig voor zuinige mensen:
http://startssl.com/ (down for maintence)

[Reactie gewijzigd door hendrickbert op 21 december 2015 12:41]

Wat denk je van deze!
https://letsencrypt.org/

Gratis SSL inderdaad .

Dank je, deze ga ik gebruiken op een aantal domeinen!

Ik gebruik het nu op één domein als test, werkt vooralsnog prima. Houdt er wel rekening mee dat de certificaten maar 3 maanden geldig zijn en je dus een cronjob aan moet maken om ze automatisch weer te vervangen tegen die tijd. Of je kan ze desnoods elke dag vervangen als je dat zou willen.

Nadeel is dat er nog geen FreeBSD support is.

Je hebt geen FreeBSD support nodig als je gewoon een van de andere clients gebruikt.

? niet geprobeerd op BSD, maar de reguliere client is in python. Nou draai ik gentoo en dat ondersteunen ze ook niet, gebruik de certonly en webdirectory opties en werkt prima.

Bedankt voor je aanvulling

Hoe dan?

Ik zie enkel een website met een hoop links naar subdomeinen die enkel flauwe plaatjes tonen. Geen uitleg of documentatie in plain English.

[Reactie gewijzigd door RoestVrijStaal op 21 december 2015 11:47]

Je kan via die site testen hoe je browser reageert op (bijvoorbeeld) een SHA-1 certificaat.

Zo krijg ik bijvoorbeeld op mijn werk geen waarschuwing en beschouwt de browser het als veilig (oude versie FF). Terwijl nieuwe Chrome browsers dus een waarschuwing in je gezicht gaan gooien.

Ah ok, die banner onderaan is dus effectief afkomstig van de browser?

Nee, dit is bijvoorbeeld de reactie van de browser:

http://i.imgur.com/hak4f31.png

Dit was ook het onderwerp in de laatste Security Now podcast. Facebook steunt het idee van CloudFlare voor een tussenoplossing om sha-1 op apparaten die niet geschikt zijn voor sha-2 wel tijdelijk toe te staan. Dit is een alternatief voor de 37 miljoen* (!!) mensen die alleen maar sha-1 ondersteunen. Dit fallback principe heeft Facebook open source aangeboden als onderdeel van hun Proxygen HTTP library voor andere partijenen om dit te integreren.

* Dit gaat om gebruikers van WinXP voor SP3, Android voor Gingerbread (toestellen van 5 jaar oud) en OpenSSL v0.9.8 en eerder. 1,69% van het encrypted internet verkeer is sha-1. 6% van China's internetgebruikers heeft geen ondersteuning voor sha-2.

Overigens zijn er nu nog geen collisions bekend, gelukkig. Een downgrade aanval is wel een risico, maar Facebook heeft vertrouwen in hun oplossing. Nog even waarom Facebook het een probleem vindt:

"We don't think it's right to cut tens of millions of people off from the benefits of the encrypted Internet, particularly because of the continued usage of devices that are known to be incompatible with SHA-256. Many of these older devices are being used in developing countries by people who are new to the Internet, as we learned recently when we rolled out TLS encryption to people using our Free Basics Platform. We should be investing in privacy and security solutions for these people, not making it harder for them to use the Internet safely."

[Reactie gewijzigd door Jelv op 21 december 2015 12:03]

Mjah, en is schijnveiligheid bieden dan veilig te noemen? Dat die apparaten geen veilige verbinding kunnen opzetten betekend niet dat je ze dan maar de kans moet geven op schijnveiligheid.

Volgens mij is een ssl verbinding met sha-1 certificaat altijd nog een stukje veiliger dan een compleet onbeveiligde verbinding. Vind het daarom een beetje raar dat browsers ze zouden moeten blokkeren. Dan kunnen ze beter met het blokkeren van gewone http beginnen, of eindelijk eens ondersteuning voor dat vreselijke ftp uit alle browsers halen.

een sha-1 verbinding is veilig zolang de collisions buiten bereik liggen. Van zodra die binnen bereik komen dan is die verbinding even veilig als een onversleutelde verbinding.

De reden waarom men ze wil blokkeren is net omdat mensen het gevoel hebben dat ze veilig zijn omdat ze op https zitten en het slotje zien terwijl de veiligheid niet langer gegarandeerd kan worden.

Stap jij morgen in een pretpark in een looping als men niet kan garanderen dat het veiligheidsharnas vergrendeld zit? Dan mag het nog in 99% van de gevallen goed gaan. Als het slecht gaat en jij zit net in dat stoeltje ...

Slechte vergelijking. Zou alleen op gaan als ze achtbanen met loopings maar zonder harnas zouden bouwen, wat neerkomt op gewone http gebruiken. Dan is een harnas zonder garantie dat ie werkt altijd nog beter dan helemaal niets.
En dat was mijn punt. Niet dat mensen zich veilig horen te voelen met sha-1. En dat kun je ook anders oplossen dan met onvriendelijke waarschuwingen. Bv gewoon het slotje weglaten, of vervangen door een rood of oranje slotje (itt groen).

Een niet-beveiligde verbinding geeft geen "groen slotje" en dan weet je dat je gewoon zelf moet opletten. Ga ik naar www.mijnfavorietebank.nl en log ik daar in, dan wil ik niet dat er een groen slotje staat als er een groot risico is dat ik eigenlijk op een scam-site zit. Degenen die alleen veilig willen browsen lijden dan onder browser-ondersteuning van zwakke beveiliging.

Onbeveiligd is geen beveiliging, dat snapt iedereen. Zwakke beveiliging is schijnveiligheid, browsers horen juist aan te geven wat je kan vertrouwen en wat niet.

[Reactie gewijzigd door bwerg op 21 december 2015 13:24]

Mjah, en is schijnveiligheid bieden dan veilig te noemen?

Het is niet meteen schijjnveiligheid.
Weliswaar is het mogelijk om SHA-1 certificaten te kraken maar voor veel sites kan het nog steeds een voldoende beveiliging zijn omdat die sites maar een beperkte beveiliging nodig hebben.
Voor banken zijn deze verouderde certificaten natuurlijk volstrekt onvoldoende maar voor een doorsnee internetforumpje of reageerders op een blog/site kan deze vorm van beveiliging nog steeds prima voldoen.
Niet elke site heeft een kluisdeur nodig als beveiliging.

[...]
Weliswaar is het mogelijk om SHA-1 certificaten te kraken

De term 'kraken' zegt in deze context helemaal niets, hij wordt vaker op Tweakers gebruikt, maar is te onspecifiek.

Ik vermoed dat je bedoeld dat er collisions uitgerekend kunnen worden? En in dat geval is het antwoord nog steeds [b]nee, SHA-1 is vooralsnog veilig[/b[.

Dat uitrekenen van die collision gaat er wel aankomen, maar dat is in deze context niet belangrijk aangezien de hash enkel gebruik wordt ter verificatie van het certificaat. Zodra er een methode bekend is om collisions uit te rekenen is het hiervoor niet meer geschikt.

Overigens zit die echt 'kraak' er wel aan te komen, derhalve zouden SHA-1 hashen bijvoorbeeld niet meer voor wachtwoorden (of andere data die opgeslagen wordt) gebruikt moeten worden.

Zie wikipedia voor meer info over bestaande aanvallen.

Het feit dat meer en meer beveiligingsexperts melden dat sha-1 niet meer als veilig bestempeld mag worden en dat een bedrijf als MS zijn stanpunt totaal heeft omgekeerd van een oproep om de uitfasering te vertragen naar een oproep om deze te versnellen is een teken dat we niet ver meer af staan van het berekenen van collisions.

Het moment dat zoiets doenbaar is op relatief korte termijn en tegen een niet al te hoge prijs zijn je sha-1 certificaten geen cent meer waard. Waarom zou je je gebruiker dan alsnog een pagina met sha-1 beveiliging voorschotelen wetende dat deze niet meer veilig is (wat net het doel is van https)?

Woon maar eens in een afrikaans land waar een de facto dictatuur heerst en waar net miljoenen toestellen in omloop zijn die kwestbaar zijn. Voor zo een regime word het ineens wel heel eenvoudig om het verkeer van de landgenoten te gaan monitoren terwijl die mensen net denken dat ze op een veilig communicatiemiddel zitten.

Dus ja, ik blijf bij mijn bewering van schijnveiligheid.

tja, is het bieden van sha-2 dan wel zoveel veiliger, immers kan het best zijn dat in het diepe geheim die al net zo makkelijk te kraken is als sha-1.. het is en blijft (helaas) altijd een 'schijnveiligheid'. Het lijkt er nu al zelfs weer op dat zelfs quantum encryptie niet zo veilig is als men dacht..
Maar niet iedereen kan zo makkelijk een nieuw device kopen, en moet je ze dan maar uitsluiten omdat het heel misschien mogelijk is dat de verbinding niet veilig is..
Wel moeten deze mensen natuurlijk gewaarschuwd worden dat ze relatief onveilig bezig zijn..
Uiteindelijk moeten ze natuurlijk wel een keer overstappen.

sha-1 is altijd 160 bit. sha-2 is een familie van grotes: 224, 256, 384 of 512 bit. Oftewel een fors stuk groter en veiliger. xkcd wachtwoord sterkte strip zei het al, veiligheid zit hem deels in de grote. Security Now 538 begint met het sha-1 verhaal, tip voor als je in 10min een snelcursus wil

[Reactie gewijzigd door Jelv op 21 december 2015 15:21]

Nee, je moet ze niet uitsluiten, maar je moet ze wel op het gevaar wijzen en dan kan je ze beter gebruik laten maken van een site zonder https zodat ze ook effectief zien dat https voor hen geen optie is en dat ze onveilig bezig zijn ipv gewoon terug te vallen op een onveilige versleuteling.

Of wat zou jij er van vinden als morgen tweakers bekend maakt dat sommige doelgroepen hun wachtwoord terug gehashed zal worden in unsalted md5 bijvoorbeeld? MD5 is nog altijd een leuk hashing algorithme en tjah, het is beter dan niets zul je dan maar denken.

Het is ook bedoeld als een tussenoplossing om een kwetsbare groep een voorlopig nog gewoon veilig verbinding te geven. Of dit het vervangingsproces versnelt is maar de vraag natuurlijk.

Maar dat is net het probleem. Die veiligheid kan niet meer gegarandeerd worden. Je zegt tegen de mensen: dit is veilig en kan niet afgeluisterd worden terwijl er mogelijks wel degelijk mensen meelezen.

Misschien ook handig om te vermelden: Als Chrome een waarschuwing geeft over een SSL certificaat, is er in sommige gevallen geen knop om toch door te gaan.

Wat je dan wel kan doen is 'danger' typen, dan ga je gewoon door. Het is natuurlijk dan wel verstandig om dat alleen te doen als je weet waarom het certificaat geweigerd is (self-signed bijvoorbeeld).

[Reactie gewijzigd door GekkePrutser op 21 december 2015 13:01]

Dat slaat toch nergens op?

Op sites waar financiële transacties of vertrouwelijke gegevens ingevoerd/verwerkt worden, prima.

Maar als je gewoon iets wilt opzoeken kun je er dus ook niet bij. Leuk.

Het kan dus wel.. Je moet alleen weten hoe.

Ik snap de beslissing van het Chrome team wel, de meeste computerleken hebben de neiging om gewoon 'doorgaan' te klikken als er een foutmelding verschijnt die ze niet begrijpen. Ook als het wel om bijvoorbeeld bankzaken gaat. Zelfs met een duidelijke uitleg wordt deze zelden gelezen want 'de computer doet raar en ik heb hier geen tijd voor'. Op die manier heeft de hele certificaat check van SSL ook niet zo veel zin meer.

In dit geval wordt er voor de veiligste oplossing gekozen, en heb je dus nog wel de mogelijkheid om dit te omzeilen. De meeste computerkenners weten wel dat je gewoon 'danger' kan typen, maar weten ook de gevaren hiervan dus kunnen de leek er beter bij adviseren.

Een lijst bijhouden met welke sites 'financieel of vertrouwelijk' zijn is praktisch niet te doen.

Overigens hebben de meeste financiele instituten allang hun certificaten geupgrade en zoniet zijn ze zo laks met hun beveiliging dat het nogal terecht is om ze te blokkeren tot ze het fixen.

[Reactie gewijzigd door GekkePrutser op 21 december 2015 12:43]

Een lijst bijhouden met welke sites 'financieel of vertrouwelijk' zijn is praktisch niet te doen.

Zo veel financiële instellingen bestaan er niet... en de instellingen die bestaan zijn gewoon geregistreerd als zijnde?
Je hoeft ook niet alles perse af te dekken, maar als je alleen de grootste banken zou pakken in NL dek je al 90% van de bevolking (van NL) af. Dat is toch een noemenswaardige reductie.

[Reactie gewijzigd door Anoniem: 80487 op 21 december 2015 12:50]

Er zijn meer sites dan alleen die van de banken. Denk aan webwinkels, declaratiesites, etc.

Niks vreemds aan eerlijk gezegd. Als je op een HTTPS (443) site zit, dan zegt dit eigenlijk al genoeg dat de data SECURE moet zijn, anders hadden ze de informatie wel middels HTTP (80) ontsloten.

Ik kan met Chrome gewoon bij self signed certificaten doorklikken? In welke scenario's houd chrome je hard tegen? Ik snap veiligheid maar ik vind het wel heel erg bijdehand om de keuze uit mijn handen te halen.

Ja ik zie dat de knop weer terug is, onder 'advanced'.

Een paar maanden geleden was die echt weg. Misschien hebben ze er teveel klachten over gehad.

Die grappen ken ik van BB10. Erg irritant sommige overheidswebsites kun je dan gewoon niet bezoeken omdat er iets is met het certificaat. Moet ik naar Firefox om alsnog de website te kunnen bekijken .

Met "lokale landing pages" zoals die getoond in de Google blog,' pop-ups, icoontjes in de adresbalk, etc pest je meer de gebruiker dan dat je iets zinnigs doet.

Waarom niet gewoon een whois op het bezochte domeinnaam en dat je EENMALIG de gebruiker vraagt of hij de websitebeheerder wil emailen met de email in de whois?

Een geautomatiseerde whois lookup is niet altijd mogelijk (bekijk maar eens een .be domein bijvoorbeeld, er zal je gevraagd worden om via dns.be te gaan). En hoeveel gebruikers gaan de moeite nemen om de beheerder van een site te mailen?

En je doet wel degelijk iets zinnigs. Je toont aan de gebruiker dat er iets mis is en dat hij deze site op dit moment niet mag vertrouwen.

Ik test regelmatig sites met o.a. SSLLabs gewoon om te zien wat voor instellingen ze gebruiken en hoe veilig de websites zijn. Ik kom regelmatig echt dramatische resultaten tegen terwijl het eigenlijk voor de meeste sites zo simpel is. Volgens mij als mensen hun SSL certificaat installeren en een groen slotje zien denken ze "Top!" en doen verder niks aan de standaard instellingen van Apache/Nginx.

Goede ontwikkeling dus!

Daar heeft dit natuurlijk bar weinig mee te maken. Dit gaat alleen over het encryptieniveau van het certificaat, niet over de andere instellingen die voor de SSLLabs score relevant zijn (zoals TLS, negotiation, forward secrecy etc)

Niet iedereen heeft de expertise om alles goed in te stellen, genoeg 'administrators' die verre van geschikt zijn om een server veilig in te stellen.. En helaas vaak genoeg ook de 'experts' die worden ingehuurd blijken achteraf er ook maar barweinig van terecht te hebben gebracht..
Met dat in het achterhoofd zou ze dus ondertussen mogen verwachten dat de grote serversoftware bouwers betere configuratie/test software mee moeten leveren om grote instellingsfouten te voorkomen..

[Reactie gewijzigd door SuperDre op 21 december 2015 13:39]

Allemaal interessant om te lezen, maar wat kan ik als gebruiker eraan doen als een bepaalde misschien wel voor mij belangrijke website zijn zaken niet op orde heeft wat betreft beveiliging.

Hier zullen developers met elkaar aan tafel moeten gaan zitten.

Chrome, of welke andere browser dan ook, ze kunnen allemaal roepen dit vindt ik onveilig maar daar heb je alleen de eind gebruiker mee.

Het dwingt de developer om zijn zaakjes op orde te krijgen. Als hackers gaten vinden, vinden we het hier allemaal (nou ja, bijna allemaal) goed dat een site eigenaar min of meer wordt gedwongen om zijn security aan te passen. Waarom in dit geval dan niet?

Veel CA's bieden gratis de mogelijkheid een re-issue van het certificaat te doen (gratis) (zoek op re-issue + naam van je CA). Al mijn domeinen draaien (Tomcat, Nginx, Apache, Lighttpd) A of A+ rating met een fatsoenlijke browser support, en configuratie is echt doodsimpel met bijvoorbeeld deze tool:

https://mozilla.github.io...tls/ssl-config-generator/

Bijvoorbeeld een A+ rating met Intermediate setting, met zelfs een werkende IE8 op XP.

De enige browser welke op SSL labs een error geeft is IE6:
IE 6 / XP No FS 1 No SNI 2 | Protocol or cipher suite mismatch

Chrome wordt steeds minder aantrekkelijk en lastiger in gebruik. Sommige legit downloads kun je niet meer downloaden, sites worden eerst voorgegeaan door waarschuwingen. Lekker dan.

Welke browsers zijn niet op chrome gebaseerd? Opera is inmiddels ook chrome geworden

Edge, Pale Moon, QupZilla, K-Meleon...

thanks stuffs om uit te proberen, da's altijd prettig! De multiplatform browsers zijn wel interessant zo te zien

Mozilla Firefox is mijn eerste keuze, is gebaseerd op Gecko. Ook een fijn gevoel dat Mozilla een non-profit organisatie is.

In Firefox krijg je overigens ook een “Untrusted Connection” melding. In een blog geeft Mozilla aan dat untrusted melding gaan geven aan sha-1 uitgegeven na 1 jan 2016 en na 1 jan 2017 voor elke sha-1 (en een melding voor de ontwikkelaars in dev-console ). Mozilla neemt in Firefox er dus een jaar langer voor dan Chrome.

[Reactie gewijzigd door Jelv op 21 december 2015 14:55]

Kan iemand voor mij verklaren waarom ik ten onrechte een waarschuwing krijg als ik naar mijn eigen site (met STARTSSL beveligd) ga met Chrome 47 voor Android maar geen waarschuwing en alles groen met de Windows versie van Chrome (ook 47)?

Zelf al gezocht? Op hun eigen forum hebben ze het er ook over: https://forum.startcom.org/viewtopic.php?f=15&t=16197