Sorry hoor, maar ik snap niet waarom die gast vasthoudt aan SHA1 .... Vragen om problemen!

SHA1 is aan het verouderen; voor nieuwe toepassingen wordt SHA2 aangeraden. Dat is nog geen reden om ieder gebruik van SHA1 te verketteren, alle SHA1 vingerafdrukken te weigeren, enz. Je moet het gebruik van geval tot geval bekijken.

@ de gewaardeerde anoniem van 9:18

Bedankt voor je posting.

Men kan hier elk bestand controleren op een zogeheten colission aanval: https://shattered.io/
Test is mede tot stand gekomen met medewerking van het Nederlands CWI en o.a. Google medewerkers.
(Centrum voor Wiskunde & Informatica).

Binnen moderne browsers als Google Chrome en ook in Firefox,
ben je al drie jaar beschermd tegen onveilige TLS/SSL certificaten.

luntrus

Jammer alleen dat als je Firefox downloadt, de signature over de binary nog uitsluitend SHA1 gebruikt.

Dat is iets minder dramatisch dan het lijkt, want je zult de makers van de door jou gebruikte webbrowser sowieso moeten vertrouwen. De kans dat zij opzettelijk twee verschillende binaries met dezelfde SHA1 hash zouden willen maken, lijkt mij klein (maar niet nul, Mozilla zou daar zelfs toe gedwongen kunnen worden. Om alle schijn weg te nemen zou Mozilla hiermee moeten stoppen).

Bij digitale handtekeningen onder tekst (overeenkomsten, prijsfafspraken e.d.) is de kans, dat de ondertekenaar belang heeft bij twee verschillende "waarheden", waarschijnlijk groter. Bij PGP en dergelijke hoor je daarom geen SHA1 meer te gebruiken. En, als ontvanger, te vertrouwen.

Binary certificaat is eigenlijk niet meer zo interessant als je zeker weten downloadt van de originele site met HTTPS.
Het komt maar hoogst zelden voor dat het gedownloade bestand in zo'n geval niet authentiek is.
Voor de zekerheid toch even checken is niet verkeerd (want je weet nooit, bijv. de site kan gehackt zijn waarbij een bestand is vervangen door een ander (kwaadaardige) bestand onder dezelfde naam).
Maar ik denk dat de meeste mensen niet zullen meemaken in hun leven dat men via deze weg foute software ontvangt waarvan de binary signature niet klopt of vervalst is. En bij een professionele site is die kans nog kleiner, omdat je mag verwachten dat daar de nodige aandacht is besteed aan security, zodat zo'n hack meestal behoorlijk lastig of onmogelijk is.

Bij downloaden via http destijds was (en is) controle van de signature vele malen belangrijker,
en ook als je software via een andere weg ontvangt.
(hoewel ik me niet kan herinneren dat ik dit zelfs ook in die tijd ooit heb meegemaakt)

De kans is heel erg veel groter dan je een ongevallen bitje in je geheugen (of van geheugen naar disk) vindt.


Ik heb inderdaad wel eens een fout meegemaakt - geen hack, maar wel een bit-error. Waarschijnlijk in mijn systeem , aimgh kwam een tweede download goed aan.

Ook nuttig om de checksum van de 'master repo' te halen, en de feitelijke download van nabije snelle mirror.
Bij Linux distributies heb je meestal vrij direct de keus van welke mirror je de download haalt.

Het overgrote deel van werkelijk PGP/GPG gebruik zal nu zitten in linux package validatie - de bekende distributies, zowel dpkg als rpm gebaseerd, gebruiken pgp signatures in de package manager.
Je hoeft dus alleen de eerste key/signature (dan wel de boot/install image die je gebruikt) te checken.


Beschouw het óók vooral als een check op silent corruptie.

Goede aanvulling. Thanks.

Veel software komt echter zonder signature maar met een hash-uitkomst en aantal bytes genoemd op de downloadsite.
Dus je zou het bijna vergeten dat deze check ook met een digital file signature kan. ;)

Uh, ja - maar een hash-programma is tegenwoordig erg wijd verbreid standaard beschikbaar op veel OSen, en een digital signature checker is veel zeldzamer - en lastiger te gebruiken.
Met een image.iso.sha256.txt kan ik meteen wat. Met een image.iso.asc.gpg kost het moeite.

Voor Linux distro's - als die eenmaal draaien doen de gpg signatures 'onder water' in de package manager het uitstekend.
maar voor de start - beginnen met een installatie image - moet je dat image min of meer handmatig checken.

En - voor vrijwel iedereen - hoe bootstrap je je web-of-trust ?
Bijvoorbeeld :

Ik download (of controleer) de Redhat gpg key van de redhat site - feitelijk is de trust dan op basis van de TLS certificaten van de Redhat website - en de kwaliteit van hun ops team.
In dat geval komt het op hetzelfde neer wanneer ik de hash van een image van de redhat site haal - ook dan is de trust dat de hash 'echt' is op basis van TLS dat identiteit van de site en niet-wijzigbaarheid van het transport moet garanderen.

(fwiw : https://access.redhat.com/security/team/key

(toeval of niet : maar het duurt een eeuwigheid om iets terug te krijgen van de MIT pgp keyserver.
Dan een untrusted certificaat van https://pool.sks-keyservers.net/ . En een stel 504 proxy errors .
Dan alleen een signature van ene marc cox op de RH key die op de keyserver staat .
Ik denk echt dat het oorspronkelijke pgp concept 'web of trust' dood is.

Bij elkaar komt de trust-bootstrap neer op 'vertrouw de key die je via HTTPS van de primaire bron site gehaald hebt' , in elk geval voor dingen als linux distributies - en wat dat betreft zie ik dan eigenlijk geen verschil met 'controleer de hash dat je via HTTPS van de primaire bron site gehaald hebt' .

Vooraf: niet bedoeld als verwijt! Het is complexe materie, ik licht toe voor de mensen die (net als ik) precies willen weten hoe het zit. Ook ik heb dit ooit moeten leren, en als ik iets fout heb (komt vaak voor) hoor ik dat natuurlijk graag.

Vooral bij grotere downloads is er op Internet geen sprake meer van "de originele site". Sowieso staan de servers van Mozilla niet meer in de kelder van hun hoogdgebouw, dus weten Mozilla-medewerkers niet wie er allemaal toegang hebben tot die servers. Vervolgens vindt distributie van binaries plaats via vele CDN (Content Delivery Network) servers die op strategische locaties zijn opgesteld, inclusief het datacenter "om de hoek" en/of van jouw ISP.

M.a.w. zelfs als https://download.mozilla.org/?product=firefox-latest-ssl&os=win64&lang=en-US jouw browser niet laat redirecten naar een http link, heb je geen idee vanaf welke fisieke server jouw browser (die je op dat moment nog gebruikt) Firefox downloadt. Zonder digitale handtekening (gezet door een door jou vertrouwd stel Mozilla-medewerkers die digitaal kunnen ondertekenen) zou er, in het brave Duitsland, een "Staatstrojaner" aan kunnen worden toegevoegd (in Nederland kan zoiets ook, maar ik denk hierbij vooral aan landen met minder burgerrechten).

Persoonlijk controleer ik dan ook altijd het gebruikte certificaat en vergelijk dit met eerdere downloads (niet omdat ik vind dat iedereen dit zou moeten doen, maar omdat als er een keer iets niet klopt, ik denk te kunnen onderbouwen wat er niet klopt en Mozilla kan waarschuwen).

ECHTER: Ik vermoed dat de meeste mensen niet begrijpen wat het risico is bij MD5 en SHA1.


Gegeven een willekeurig bestand en een MD5 of SHA1 hash van dat bestand, is het nog steeds zo goed als onmogelijk om dat bestand zo te wijzigen dat de hash daarvan hetzelfde is. Dit is dus niet het probleem.

Het probleem is dat de maker van een bestand (al dan niet daartoe gedwongen) een bestand zodanig kan manipuleren (dus voordat er gehashed wordt) dat er twee afwijkende versies van het bestand ontstaan die dezelfde hash opleveren.

Dat risico is echt van een andere orde, maar niet verwaarloosbaar. Vooral bij certificaten zelf is het risico groot als dit mogelijk is: immers als iemand een schijnbaar simpel servercertificaatje aanvraagt, met SHA1 hashwaarde X, dat door een certificaatuitgever ongewijzigd wordt ondertekend met die SHA1 hashwaarde X, en de kwaadwillende tevens een CA-certificaat heeft gegenereerd eveneens met SHA1 hashwaarde X, kan de kwaadwillende de digitale handtekening van dat siimpele certificaatje kopiëren naar het CA-certificaat om vervolgens naar believen zelf certificaten uit te geven.

Juist om dit scenario te voorkomen (ook bij momenteel nog als veilig beschouwde hashes) voegen certificaatuitgevers een random getal van minstens 64 bits toe aan elk CSR (certificate signing request, feitelijk een certificaat nog zonder handtekening van de uitgever, vergelijkbaar met het deel tussen de eerste twee bakhaken van de "Signed file" in het grijze vlak hierboven). Daardoor kan de aanvrager niet voorspellen wat de in de handtekening gebruikte hash zal zijn, en heeft het genereren van twee verschillende CSRs die dezelfde hash opleveren, dus geen zin.

Een ander scenario is bijv. een koopcontract in de vorm van een digitaal ondertekend PDF bestand. Ongewenst is natuurlijk dat er twee verschillende versies van kunnen bestaan met een identieke digitale handtekening over dezelfde hash van de twee verschillende versies (in tegenstelling tot platte tekst biedt het PDF formaat zat ruimte voor een blob ter compensatie van afwijkende teksten in de twee versies met dezelfde hash).

Conclusie
SHA1 en MD5 zijn niet dusdanig gebroken dat bijv. een MitM een willekeurig bestand zodanig kan wijzigen dat de hash hetzelfde blijft. Vanwege een andere reden, namelijk kwade opzet (eventueel gedwongen) in het proces t/m ondertekenen, hoor je MD5 en SHA1 niet meer te gebruiken voor digitale handtekeningen.

Sorry, maar waarom zou dat niet kunnen? Bijv. een overheid kan optreden als MITM en een vervalste versie van een veel gevraagde download ontwikkelen, die bij aanvraag van de download ongemerkt automatisch de vervalste versie laat downloaden in plaats van het aangevraagde bestand, en waarvan de SHA1 of MD5 hash overeenkomt met de hash van het originele bestand.

PS: het is alweer een graad moeilijker om MD5 én SHA1 én de bestandsgrootte alledrie hetzelfde te laten zijn.
(hoewel niet absoluut voor iedereen onmogelijk).
Maar vandaar dat sommige sites meerdere hashes plus de bestandsgrootte vermelden om met nog grotere zekereheid te kunnen achterhalen of het gedownloade bestand in orde is.

Wanneer een MITM attack mogelijk is, dan kan de download + signatures vervangen worden. Daarom moet je altijd controleren of de download is getekend met een PGP-signature van de developer.

Het is niet voldoende om de signatures van de html-pagina als betrouwbaar te beschouwen.

Hmmm, not sure if i agree. Als de html pagina wordt geserved via HTTPs dan zou het toch ok moeten zijn? Ook
als is er een MITM dan gaat mijn browser mij toch een warning geven? Of ben ik dan bizar naief, doen "we" al
MiTM via valid CAs?

Ik kan niet bewijzen dat dit onmogelijk is, maar voor zover ik weet zijn realistische aanvallen (d.w.z. praktisch uitvoerbaar) van dat type (preimage, uit te spreken als pré-image, een gegeven bestand dus) nog niet gepubliceerd.

https://en.wikipedia.org/wiki/Hash_function_security_summary biedt een aardig overzicht. MD5 is, vanuit cryptografisch oogpunt, gekraakt omdat je gemiddeld "slechts" de helft van 2^123.4 (in plaats van 2^128) berekeningen moet doen om een gegeven (preimage) bestand zo aan te passen dat de hash erover hetzelfde is als van het originele bestand.

Zoals ik schreef (lees het nog eens na): het is voor een MitM in de praktijk onmogelijk om een willekeurig bestand, waar de SHA1 (of zelfs MD5) hash van bekend is, zo te wijzigen dat dit bestand dezelfde hash oplevert. Zelfs als een wijziging van de lengte acceptabel is (niet wordt opgemerkt).

Dit geldt niet voor een voor dit doel geprefabriceerd bestand, zoals je bijv. kunt lezen in https://sha-mbles.github.io/. Als bijvoorbeeld de Russische of Chinese overheid van Mozilla zou eisen dat zij elke binary zo prepareren dat er tevens een backdoored versie van bestaat, zouden de geheime diensten in die landen de "goede" binary door de "foute" kunnen vervangen (op lokale CDN-servers bijvoorbeeld) en zou bijna niemand weten van het bestaan van deze verschillende binaries. Met als (aanvullend) risico dat criminelen hierachter komen en ook gebruikers buiten genoemde landen de backdoored versie downloaden en installeren.

Om alle schijn te vermijden is het daarom verstandig om, bij het signeren van executables en contracten gebruik te maken een cryptografische hash waarvan nog geen chosen-prefix collision attacks bekend zijn (of waarvan bedenkingen in die richting bestaan).

Vergelijkbaar: het is nog steeds onmogelijk om, als je de MD5 hash van een jou volledig onbekend wachtwoord kent, uit te rekenen wat dat wachtwoord moet zijn (of desnoods een collision ervan). En, hoewel MD5 op dit punt niet gekraakt is, wordt toch dringend afgeraden om MD5 te gebruiken om wachtwoord-afgeleiden te bepalen!

Het probleem hier is NIET dat MD5 gekraakt zou zijn, maar dat MD5 een snel algoritme is, en vooral dat mensen voorspelbare en/of te korte wachtwoorden gebruiken. Mede doordat MD5 erg snel is, kan een aanvaller in relatief korte tijd gigantische aantallen wachtwoorden (verkregen via eerdere lekken en/of achtereenvolgens uitproberen van karaktercombinaties) hashen totdat een overeenkomstige hash wordt gevonden. Om deze redenen moet je geen enkele cryptografische hash gebruiken voor het bepalen van wachtwoord-afgeleiden, maar een algoritme dat bewust aanzienlijk trager is dan de gebruikelijke cryptografische hashes (die immers voor een ander doel zijn ontworpen).

Mede omdat veel mensen niet begrijpen onder welke omstandigheden risico's spelen, kun je beter helemaal stoppen met het gebruiken van een cryptografische hash als deze op minstens één aspect "gebroken" (significant verzwakt) is. Helaas leidt dit wel vaak tot misverstanden, vooral als (stronteigenwijze) partijen deze afgeraden hashes toch blijven gebruiken - ook al is dat op een minder kwetsbare manier dan sommigen veronderstellen.

De eerste Anoniem bedoelt vermoedelijk dat als een aanvaller toegang heeft tot de downloadserver (of CDN- server) waarop tevens een hash van het bestand getoond wordt, die aanvaller beide kan vervangen. De aanvaller kan jou ook voorschotelen wat hij wil indien jij denkt dat je naar de echte downloadserver zit te kijken, terwijl het om een fake "lijkt op" site gaat. Of als hij toegang heeft tot een niet end-to-end versleutelde verbinding tussen de downloadserver en jouw browser, of indien een kwaadaardige plugin in jouw browser jou voor de gek houdt.

Verder ben je, zo te zien, niet "bizar naief"!

Zie mijn posting 24 okt 23:40 - hoe kom ik eigenlijk met goede zekerheid aan de echte PGP key van de developer ?

Bedenk trouwens dat - zoals je stelt - je blijkbaar zit in een situatie waarin een MITM attack mogelijk is....

Zonder de developer zelf via een ander kanaal te benaderen (met het risico dat ook de contactgegevens van dat kanaal zijn vervalst), kom je met enige creativiteit vaak een heel eind.

Als een key naar verluidt al een tijd bestaat, kun je een ouder package o.i.d. downloaden en de signature daarvan verifiëren, en zo vaststellen of dezelfde key ook toen al is gebruikt. Als dat zo is, weet je in elk geval dat de key niet recentelijk door een vervalsing is vervangen.

Risicovol bij PGP/GPG/GnuPG is het gebruik van 4 byte lange identifiers zoals fd431d51: met ca. 4 miljard mogelijke combinaties zijn deze allesbehalve gegarandeerd uniek, en het is ook niet onmogelijk om een andere key te genereren waarvan de "vingerafdruk" ook eindigt op fd431d51.

Googlen naar de volledige thumbprint/fingerprint zoals:
"567E 347A D004 4ADE 55BA 8A5F 199E 2F91 FD43 1D51"
(let op, Google daarnaar inclusief beide aanhalingstekens) geeft vaak informatie over hoe lang en hoe vaak zo'n key gebruikt is; weinig en/of alleen recente resultaten (bij een geclaimd jaren oude key) is verdacht. In dit specifieke geval krijg ik voldoende resultaten om ervan overtuigd te zijn dat deze key niet recentelijk is vervalst. Als deze al jaren geleden zou zijn vervalst, is de kans groot dat iemand dat ondertussen is opgevallen - maar 100% zekerheid heb je nooit.

Sowieso niet omdat er natuurlijk niet slechts één developer is die kan signen, hetgeen het risico vergroot dat de private key in verkeerde handen valt. En zelfs dat is niet nodig als het een kwaadwillende lukt om aangepaste code door de "build straat" te jassen - dat meestal een geautomatiseerd proces is (anders zou het veel te arbeidsintensief zijn). Dat de private key dan in een HSM zit (waar je in principe de private key niet uit kunt extracten), helpt dan ook niet.

Kortom, een gezonde dosis wantrouwen (niet slechts één bron geloven, minstens double checken) en bijv. de hash van een download berekenen en Googlen en/of daarop zoeken bij virustotal.com, geven vaak extra vertrouwen - of juist niet. Bij twijfel in elk geval wachten met installeren, tenzij je voldoende expertise en tijd hebt om zelf onderzoek te doen (bijv. installeren op een geïsoleerd testsysteem, reverse-engineeren, bin-diffen met een vorige versie etc).

Het gaat aardig richting 'reflections on trusting trust' .

Want blijkbaar heb ik wel op de één of andere manier wel een betrouwbare implementatie van een signature checker (gpg/pgp) binnen - ondanks de aanname dat er een MITM aanwezig is.

Hetzelfde advies kun je dus voor een hash-check geven : 'google ernaar' - en doe de aanname dat niet alles vervalst kan zijn, en dat de MITM alleen acteert op de bron site en niet alles wat je binnenkrijgt kan manipuleren.

Voor iets als een grote Linux distributie kun je keys - en hashes - ook wel 'overal' vinden - maar als het gaat om dingen met een veel kleiner bereik is de optie "google of je 'overal' hetzelfde ziet " niet zo kansrijk.

Da's mooi, ik leer graag - wat is die oplossing?

Die hash is uitsluitend geldig voor de versie die jij wilt downloaden en zegt bovendien helemaal niets over de ontwikkelaars. Het voordeel van een PGP key of signing certificate is dat deze over een langere periode worden gebruikt: zelfs als je de ontwikkelaars niet kent kun je vaak vaststellen dat eerdere code van hun hand niet kwaadaardig werd bevonden. Dat biedt welliswaar geen garanties voor de toekomst, maar is wel een aanwijzing.

Maar het is het vaak minder belastend voor kleine ontwikkelaar(s) als gebruikers persoonlijk contact met hen zoeken (sterker, er zullen er zijn die dat waarderen). Bovendien is een klein bereik zelden interessant voor ongerichte aanvallers. Als jij een typisch doelwit bent voor gerichte aanvallers, is het verstandig om dat soort code te mijden of, na download, een tijdje te wachten met installeren en waarschuwingen van derden m.b.t. die versie in de gaten te houden.

Maar goed, ik ben benieuwd naar de oplossing die jij gebruikt!

Thanks this makes sense. Ik snap dan ook waarom PGP beter zou werken (als we er uit vanuit gaan
dat de PGP private key niet op de server staat, which would be weird indeed). Maar dan blijft idd de
vraag hoe je dat "eenvoudig controleert. Maar thanks voor de feedback erik!

Die oplossing is er niet vanzelf.
Ik wijs alleen op nog een verborgen aanname voor de stelling "gewoon een crypto signature checken als een MITM actief bezig is je een backdoored versie te leveren" .

Dat je op de één of andere manier wel de goede key weet te krijgen om de crypto signature mee te checken, en dat je ook op de een of andere manier ook een betrouwbaar programma weet te krijgen om dat mee te doen.

Een trust bootstrap _is_ moeilijk - en ergens moet je aannames gaan doen welke componenten, onderdelen of informatie vertrouwd zijn en buiten bereik van de aanvaller om te manipuleren.

Dat geeft niet - maar het is wel beter om je aannames bewust te maken - en je af te vragen of je aannames reëel zijn.


Een key kan langere tijd meegaan met een product inderdaad.
Maar ook zonder key kun je de reputatie van het product/ontwikkelteam in acht nemen bij je keuze om het te gaan gebruiken ?


Ik zit meestal niet met het probleem dat ik 'nieuwe' code van een kleine partij moet valideren - of dat ik moet aannemen dat ik met een actieve aanval op mij te maken heb.

Voor de bekendere Linux distributies is het vrij simpel, want die pgp keys heb ik altijd wel van 'eerder'.

Als ik echt blanco zou moeten bootstrappen kom ik ook met niks beters dan een rondje google , en met name de aanname dat het OS dat ik gebruik voor de download wel schoon zal zijn, en de TLS root store van dat OS/browser echt.
(je kunt wel _redelijk_ je best doen om dat te bereiken, maar ergens houdt het op ).