IE en Edge tonen vanaf februari waarschuwing bij sites met sha-1-hashing

Microsofts browsers Internet Explorer en Edge zullen vanaf 14 februari volgend jaar een waarschuwing gaan tonen als sites zijn beveiligd met een sha-1-certificaat. Gebruikers kunnen na een waarschuwing nog wel op de site komen.

Op Valentijnsdag volgend jaar krijgen beide browser een update, waardoor gebruikers bij het openen van een site die gebruik maakt van een sha-1-certificaat een melding dat de site mogelijk onveilig is. Er staat duidelijk bij dat Microsoft afraadt om de site te bezoeken, maar de site blijft vooralsnog toegankelijk. Daarmee volgt het Amerikaanse bedrijf de lijn van andere browserbouwers, die inmiddels bij sites met sha-1-hashing ook waarschuwingen zijn gaan geven. Certifcaatautoriteiten mogen inmiddels alleen nog sha-2-certificaten uitgeven.

Op een later moment wil de Redmondse softwaremaker gaan inbouwen dat Windows zijn gebruikers ook buiten de browser gaat waarschuwen als software bij hashing gebruik maakt van sha-1. Wanneer dat precies is, zegt Microsoft nu nog niet. Het maakt wel duidelijk dat het aanvallen op sha-1-hashing in de gaten houdt om te bepalen hoe snel dat moet gebeuren.

De veiligheidsproblemen met sha-1-certifaten waren al langer bekend, maar zijn nu 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.

Reacties (58)

[biglia]

En wat gaan ze dan doen bij websites die geen SSL aanbieden. Beter geen certificaat dan een sha-1-certificaat dan?

[lolgast]

Vind ik wel ja. Bij een niet SSL pagina weet je dat de gegevens niet beveiligd verstuurd worden. Bij een onveilige SSL verbinding kun je dus spreken van schijnveiligheid.

[Verwijderd]

Waarom dan niet http:// zonder slotje tonen wanneer sha1 gebruikt wordt? Gelijk duidelijk voor iedereen. En dan zijn oude onbeheerde sites nog steeds toegankelijk.

Desnoods met alsnog een melding erbij (omdat het een https site was): "Pas Op: Deze site vraagt/toont wellicht gevoelige informatie en zou daarom eigenlijk https:// moeten hebben."

Deze strategie zou je ook kunnen toepassen bij verouderde ssl, of andere verouderde ciphers, of onvertrouwde CA's.

Edit:
Om mijn eigen vraag maar meteen te beantwoorden. In bijna alle gevallen gaat het om vertrouwde informatie, waar je nou juist niet automatisch de beveiliging wilt omzeilen (met een lullige waarschuwing). Dan liever stoppen waar je mee bezig was.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:09]

[SuperDre]

Slotje zegt helaas helemaal niets..

[deadinspace]

Het slotje betekent dat je communicatie met die website versleuteld en geverifieerd is, en daadwerkelijk terechtkomt bij de website die je in de URL ziet. Dat zegt dus best wel veel eigenlijk.

[SuperDre]

nee hoor, want zoals ik al op een andere plek aan gaf, mensen worden nu geinstrueerd, 'oh zie je een slotje, dan zit je goed'. Ja voor een tweaker zoals jij en ik zal het meevallen, alhoewel als men bv https://mijn.lng.nl ziet staan met een slotje, dan kan men toch wel denken dat men op de ing site zal zitten. dus het zegt dan helemaal niets, want elke site kan gewoon werken met echte certificaten..

[deadinspace]

... alhoewel als men bv https://mijn.lng.nl ziet staan met een slotje, dan kan men toch wel denken dat men op de ing site zal zitten. dus het zegt dan helemaal niets ...

Het zegt wel wat, namelijk dat je een beveiligde verbinding hebt met mijn.lng.nl. Dat dat niet het domein is wat je hoopte te bezoeken is wat andres. Natuurlijk moet je ook de domeinnaam controleren.

Nee, dat je een slotje ziet betekent niet dat alles meteen goed is, maar dat het niets zegt is niet waar. Het vertelt je zelfs erg veel: namelijk dat je een beveiligde verbinding hebt met het domein dat getoond wordt.

[SuperDre]

ja, maar beveiligde verbinding of niet, het gaat eigenlijk om de correcte site, want anders heft de beveiligde verbinding nog steeds geen reet zin.
Maar je voelt je dus veilig terwijl je helemaal niet veilig bent, dan kun je dus IMHO net zo goed geen beveiligde verbinding hebben..

[batjes]

Slotje zelf zegt dat helemaal niet, het groene blok/text naast dat slotje doet dat. Tweakers heeft dat bv niet, maar je internetbankieren website bv wel.

Het slotje beweert enkel dat er een SSL verbinding is met iets wat achter dat domein zit. Of het het echte domein is, 213.239.154.30 in het geval van Tweakers. Of een lokale webserver op 10.10.10.50 in het geval van een MitM, zie je niet aan het slotje.

Wat jij beweert geeft een groen blokje, groen slotje, groene text, of iets groens iig afhankelijk van je browser.

[deadinspace]

Het slotje beweert enkel dat er een SSL verbinding is met iets wat achter dat domein zit. Of het het echte domein is, 213.239.154.30 in het geval van Tweakers. Of een lokale webserver op 10.10.10.50 in het geval van een MitM, zie je niet aan het slotje.

Dat is niet waar; het slotje geeft aan dat de verbinding versleuteld is met een geldig certificaat voor dat domein.

Alleen Tweakers heeft een certificaat voor tweakers.net, dus als je adresbalk "tweakers.net" toont met een slotje, dan weet je dat je een beveiligde verbinding hebt met de webserver van Tweakers.

Iemand die een MitM-aanval wil uitvoeren heeft geen geldig certificaat voor tweakers.net en kan dat effect dus niet bereiken.

(fuckups van CAs buiten beschouwing gelaten, maar dat risico bestaat natuurlijk ook voor EV-certificaten - al is het risico daar hopelijk wel kleiner)

[RGAT]

Zonder slotje = zonder httpS, dus daar dan meerdere varianten van maken is alles behalve duidelijk.
Probeer maar eens uit te leggen aan een leek 'Ja groen = goed, niks = minder goed en een rood slotje met een kruisje kan zijn dat er SHA1 wordt gebruikt, dussssss......'
Melding zoals hij nu wordt getoont dat de pagina niet meer veilig is is toch zo duidelijk als het maar kan? Niet te missen, duidelijke informatie en herkenbaar.

[Eagle Creek]

Hier sluit ik mij bij aan. Persoonlijk vind in "alles https" overtrokken maar ik snap de motivatie achter de beweging wel. Maar áls je dan tls implementeert moet deze implementatie wel duigen. "Wat je doet, doe 't goed".

Een informatieve waarschuwing bij een site die geen encryptie gebruikt maar eveneens een meer dringerendere waarschuwing bij sites die een zwakke vorm gebruiken. Dit inderdaad om schijnveiligheid tegen te gaan.

Hoe dringend de waarschuwing moet zijn is afhankelijk van het daadwerkelijke risico..

[bartje]

persoonlijk vind ik dat sites met wachtwoordvelden altijd over https zouden moeten.
bij sites waar gebruikers geen wachtwoorden hoeven in te vullen ligt dit meer aan de content en doel van de site.

[jcoenen]

Iedere website met verwerking van persoonsgegevens is volgens de wet verplicht om een SSL/TLS certificaat te hebben.

https://autoriteitpersoon...ging-persoonsgegevens.pdf

Deze website legt het iets makkelijker uit:
https://ictrecht.nl/ictre...n-niet-bij-gewone-e-mail/

Een wachtwoord zal niet bij persoonsgegevens horen maar ik ben toch van mening dat het hierbij ook verplicht zou moeten zijn.

[kvdveer]

Een wachtwoord doet niet zoveel zonder gebruikersnaam, en een gebruikersnaam is wel een persoonsgegeven.

Overigens wordt het IP-adres waar je vandaan komt ook gezien als persoonsgegevens. Dus als je echt op alle slakken zout wilt leggen, verplicht de WPB al HTTPS-everywhere.

[jcoenen]

Het is alleen zeldzaam dat het veld voor de gebruikersnaam en het wachtwoord op 2 verschillende pagina's staan. Het is dus voor beide wel https of beide niet.

Een IP-Adres is inderdaad een persoonsgegeven maar het gaat alleen om het verwerken. Veel websites verwerken dit wel maar dit is lastiger te controleren dan het verwerken van een contact/login formulier. Je zet deze formulieren immers niet op je website om vervolgens niks met de data te gaan doen. Het IP-Adres krijg je altijd bij een bezoek van de website en zonder in de broncode te kijken is lastig te bepalen of deze verwerkt word.

[Belgar]

Dat is ook steeds minder te verdedigen. Als men een HTTP verbinding kan onderscheppen en aanpassen kan men javascript injecteren en draaien. In combinatie met andere exploits is dat een risico.

Ook sommige lokale aanvallen zoals laatst gedemonstreerd door Samy Kamkar berusten op het feit dat er nog steeds HTTP verbindingen zijn. Als alles op HTTPS zou zijn werken dit soort aanvallen niet meer.

[Tom]

Chrome gaat volgend jaar al een waarschuwing plaatsen bij sites zonder SSL:
https://security.googlebl...ards-more-secure-web.html
Eerst zal de waarschuwing neutraal zijn, maar ze willen dit in daaropvolgende versies nadrukkelijker weer gaan geven in de UI.
Zie ook https://www.chromium.org/...arking-http-as-non-secure

[biglia]

Enkel op pagina's met een paswoord of kredietkaart veld.

Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.

[mschol]

imho een kwalijke ontwikkeling: ssl is niet een magische oplossing voor alle problemen, sterker nog ik denk dat het bij de meeste meer problemen veroorzaakt door onkunde als het geforceerd (/onder druk van) wordt geïntroduceerd

[Verwijderd]

Beetje jammer, niet alle websites hebben SSL nodig. Ik vind de beweegreden zoals Microsoft aangeeft met IE en Edge duidelijker. Als je een beveiligde website hebt, wil je het goed beveiligd hebben. Dus waarschuwing.

Maar er zijn ook zat websites waar een SSL certificaat gewoonweg niet nodig is.

[kristofv]

Case in point, de website van één van de grootste Belgische kranten heeft een zone voor betalenderabonnees maar het logon proces verloopt nog via plain http .. niets beveiliging.

Toch bijna te gek voor woorden voor een website waarvoor je moet betalen.

[biglia]

Je bedoelt hln.be? De website lijkt inderdaad niet https te ondersteunen. Maar bij het inloggen wordt wel degelijk een POST request naar een https url uitgevoerd. https://caps.hln.be/service/web/authentication

hln.be is trouwens onderdeel van De Persgroep, dezelfde eigenaars als tweakers.net

[Reactie gewijzigd door biglia op 22 juli 2024 17:09]

[kristofv]

Nee, hln is in orde, het is een andere grote krant

[Mijzelf]

Maar bij het inloggen wordt wel degelijk een POST request naar een https url uitgevoerd.

Een 'onderwater' POST? Hoe vangt de browser dit op als de certificaat niet klopt, kwa gebruikers interface?

[Dreamvoid]

Eigenlijk zouden browsers bij alle non-SSL sites (incl sha1) standaard javascript uit moeten zetten.

[tinus73]

Wat betekend dit eigenlijk voor de Let's Encrypt en StartSSL oplossingen zoals ook voor de Synology gebruikt wordt? Is dit dan in een klap onbruikbaar?

[Loller1]

Ik veronderstel - en hoop - dat die geen SHA-1 gebruiken voor hun certificaten.

[tinus73]

Ok, ik ben een beetje noob op dit vlak; Er staan verschillende entries in het certificaat, waaronder: "algoritme voor vingerafdruk" staat op sha1...
De overige zijn sha256

[Peetz0r]

Gelukkig zijn het twee verschillende zaken. Opzich is de benaming wel verwarrend.

Zie ook What is the difference between a “Thumbprint Algorithm” “Signature Algorithm” and “Signature Hash Algorithm” for a certificates?

[Reactie gewijzigd door Peetz0r op 22 juli 2024 17:09]

[hackerhater]

Dat is een sha256 certificaat met sha1-fallback. Die certificaten zijn prima.

[Belgar]

LEt's encrypt is al SHA-2

[theduke1989]

Bij ons kom je niet eens op de site met een super verouderd SSL verbinding!

Gelukkig wordt er aandacht aan besteedt zodat mensen er echt naar gaan kijken....

[latka]

Je kunt ook een TLSv1.2 verbinding met een SHA-1 certificaat opbouwen. Heeft niets te maken met het niveau van de SSL verbinding.

[Eagle Creek]

Je lijkt onbedoeld appels met peren te vergelijken.

Ook het moderne TLS-protocol i.c.m. met een (server side) strak geconfigureerde ciphersuite kan tesamen met een sha-1-certificaat worden gebruikt. Je dwingt op die manier wel af dat clients op een veilige manier met jouw server praten maar vanuit de cliënt gezien is de identificatie van de server nog een risico.

Immers - als de cliënt op een andere server uitkomt met een "gekraakt" certificaat, is jouw serverconfiguratie niet van invloed.

[Reactie gewijzigd door Eagle Creek op 22 juli 2024 17:09]

[dennizzz]

Naast dat certifice authorities geen SHA1-certificaten meer mogen uitgegeven, is het ook zo dat alle SHA1's een einddatum voor 31 dec 2016 hebben of al actief gerevoked moeten zijn door CA's.

[SuperDre]

Dus technisch gezien zouden er helemaal geen sites meer kunnen zijn met een SHA-1 certificaat. Dus zou niemand die melding hoeven te zien.

[MDKlapwijk]

Daarom snap ik deze stap van Microsoft niet.

De CA's hebben dit al enige tijd geleden afgesproken en geven al zeker 3 jaar lang geen sha1 certificaten meer uit, welke een eind datum van na 31 december 2016 hebben.

[TheRealProcyon]

Bij ons op school verloopt inloggen naar de webmail etc. via Sha-1, de einddatum van het certificaat staat overigens ver van 31 December 2016, namelijk ergens ver in 2019.

Zie foto's in URLs:

http://i.imgur.com/3TAd7TQ.jpg
http://i.imgur.com/PvJnm8b.jpg
http://i.imgur.com/U7BEgLg.jpg
http://i.imgur.com/VCrSbha.jpg

[Reactie gewijzigd door TheRealProcyon op 22 juli 2024 17:09]

[dennizzz]

Je school heeft inmiddels al wel een nieuw certificaat aangevraagd en gekregen op 16-10 (https://crt.sh/?q=ambelt.nl).

Ik denk dat ze door hun CA zijn benaderd dat ze hun certificaat gaan intrekken op uiterlijk 31 december. Het was ook 5 jaar geldig, tegenwoordig mag het maar 3 jaar en 3 maanden max geloof ik.

[TheRealProcyon]

Aaah ok, daar had ik voor de rest geen onderzoek naar gedaan.

[dennizzz]

Vanaf 31-12 kan men het dus actief gaan blokkeren. Het is een goede actie om zo veel mogelijk te blokkeren. Je kunt niet altijd uitgaan van de goedheid/correctheid van alle CA's (het is vaker fout gegaan), en als een private key van een SHA-1 intermediate CA uit zou lekken kunnen ze die ook niet misbruiken voor uitgifte.

[Soribaj]

Ik hoop dat het een beetje een duidelijke error wordt. En niet zo een standaard als wat hierboven staat. Mag je weer 10 dingen gaan uitzoeken voordat je weet wat de oorzaak is.

[Batiatus]

Iemand een idee wat er dan gebeurt bij een niet-versleutelde verbinding? Ik kan me voorstellen dat je niet je niet al je adressen op de site volledig HTTPS uit wil voeren i.v.m. performance, maar inlogpagina's en dergelijken verwacht ik dan toch wel HTTPS. Echter, ik kan me nog herinneren dat infosecurity website (de ironie), geen HTTPS inlogpagina had en dat daar geen enkele waarschuwing voor was. Dan heb ik liever daar een waarschuwing over dan een minder veilig certificaat. In een ideale wereld je wil je ze natuurlijk beide, of alles in HTTPS.

[_h93]

Voor http gaat dit niet op, omdat er dan geen sprake is van een uitwisseling van certificaten. Kan me trouwens niet voorstellen dat er vandaag de dag nog websites zijn die je trachten in te loggen via een http -pagina? (Hoop ik )

[Batiatus]

Nee klopt, maar dat is eigenlijk wel apart dat de eindgebruiker er geen melding van krijgt wanneer er helemaal niets aan encryptie wordt gedaan. Nu krijg je dus een melding bij een site die out of date is, maar geen melding bij een site die helemaal niets doet aan encryptie. De eindgebruiker ziet alleen een rode vlek op z'n scherm en denkt, goh hier is iets mis. Bij HTTP heeft men het idee dat er niets aan de hand is, terwijl de data nog veel makkelijker te onderscheppen is.
En ja, ik geloof best dat er nog wat huis, tuin en keuken websites zijn die geen HTTPS inlogscherm hebben.

[icratox]

Dit gaat in de toekomst wel gebeuren, oa Google is bezig met Chrome om in de nabije toekomst pagina's met inlog mechanismes als onveilig te bestempelen wanneer er geen vertrouwd certificaat aanwezig is.

[The Zep Man]

Microsofts browsers Internet Explorer en Edge zullen vanaf 14 februari volgend jaar een waarschuwing gaan tonen als sites zijn beveiligd met een sha-1-certificaat. Gebruikers kunnen na een waarschuwing nog wel op de site komen.

Heeft twintig jaar onderzoek ondertussen niet aangetoond dat dit soort waarschuwingen geen enkel effect hebben? Wat de gebruiker ziet is "kies deze optie om door te gaan met wat je wilde doen" en "kies deze optie om iets te doen wat totaal niet je doel is". Een gebruiker toont pas interesse als zijn site niet meer bereikbaar is, en zelfs dan nog zal alles op alles gezet worden om dat weer mogelijk te maken (installeren andere browser, aanpassen beveiligingsinstellingen, etc.).

Volgens mij mogen SHA-1 certificaten sowieso niet meer uitgegeven worden. Het probleem verdwijnt dus vanzelf. Daarnaast is SHA-1 weliswaar niet zo veilig, maar een certificaat met SHA-1 is nog steeds veiliger dan geen certificaat met een normale HTTP verbinding (waar geen waarschuwing voor wordt getoond).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 17:09]

[Keiichi]

Ik denk zelf wel dat meldingen website eigenaren er naar bewegen om dit in orde te hebben, niet zozeer dan de eindgebruiker.
Verwacht zelf eigenlijk dat bij het periodiek vernieuwen van certificaten dat opzich de hash methode wel geupdate wordt van een nieuw certificaat omdat uitgevers dit moeten omdat ze anders een ongeldigde CA hebben.

[ultimate-tester]

Nee maar voor de website beheerder en mensen met technische kennis is het wel handig. De website beheerder kan zo tenminste aandringen bij zijn klant dat er geld moet worden vrijgemaakt voor een nieuw certificaat.

[The Zep Man]

Nee maar voor de website beheerder en mensen met technische kennis is het wel handig. De website beheerder kan zo tenminste aandringen bij zijn klant dat er geld moet worden vrijgemaakt voor een nieuw certificaat.

Certificaten verlopen vanzelf. Als het volgende certificaat SHA-256 of beter moet bevatten, dan lost dat probleem zich vanzelf op.

[Voutloos]

Dat klopt, voor iedereen die zijn configuratie ook maar een beetje proper bijhoudt (zowel CA als site admins) zal deze melding nooit van toepassing zijn.

Als een CA zich echter niet aan de regels houdt (meermaals recent in het nieuws) of er om een andere reden iemand deze afgeraden instellingen gebruikt, is deze detectie toch een leuke extra.

[biglia]

Het is ook vooral een boodschap aan de website eigenaars. Upgrade je certificaat en de melding is weg voor al je bezoekers. Soms hebben websitebouwers een duwtje nodig.

[ASS-Ware]

Quote:
Er staat duidelijk bij dat Microsoft afraadt om de site te bezoeken, maar de site blijft vooralsnog ontoegankelijk.

Moet dat niet toegankelijk zijn?

[SilentLucidity]

Je kan de feedback button hiervoor gebruiken om dit direct aan de auteur door te geven

[Reactie gewijzigd door SilentLucidity op 22 juli 2024 17:09]

[feep]

Zo te zien is de update nog niet van toepassing voor self signed certificaten.

In February 2017, there will be no impact for roots that are not included in Microsoft Trusted Root Program, such as enterprise or self-signed roots that you’ve chosen to trust.

Wij hebben daar nog heel wat certificaten van in omloop die binnenkort vervangen moeten gaan worden.

[Trommelrem]

Grappig, in Chrome krijg ik zelfs certificaatmeldingen dat het certificaat van google.nl onveilig is. Nader onderzoek wijst uit dat ik met Google verbind middels SHA1. Toch maar even een offline virusscan draaien.