sorry, maar is nu niet echt eenvoudig en site is slecht opgezet.
Als technisch persoon zou ik meteen hebben, mzzl, veel te stappen, slechte volgorde, veel te veel mogelijkheden. Dit gaat geen leek gebruiken. Nog afgezien de meeste waarschijnlijk Windows gebruiken om de ISO te downloaden.

Mee eens, veel te moeilijk voor iemand die b.v. Windows draait en eens Linux wil proberen. Schrijvers van dit alles begrijpen niet waarom sommige mensen zoiets niet kunnen begrijpen en waarom dit mensen afschrikt iets met Linux te gaan doen.

Gewoon iso downloaden, bijbehorende SHA256 sum staat er vaak bij op de site. In windows de iso verifieren met https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility/, iso naar usb stick schrijven en live uitproberen.

Ik draai zelf Manjaro Linux en daar is de handleiding op de download pagina snel te vinden zoals het hoort. Ook voor Windows gebruikers. https://osdn.net/dl/manjaro/Manjaro-User-Guide.pdf

De aangeduide directory met Ubuntu releases is voor professionals. Het is ook geschikt voor hen die gewoon "cut the crap" willen toepassen, dus voor zij slechts willen weten waar de ISOs en bijbehorende checksums en signatures staan.

Onder een Bash shell met Vim middels reversed engineering de assembler code herschrijven van de boot firmware, dat is pas ingewikkeld. Vooral als je er net mee begint... hetzelfde geldt voor gebruik van GnuPG voor een beginner.

Deze handleiding heeft een difficulty van 3/5. Dus is voor iets meer ervaren gebruikers maar zeker niet voor de professionals.

Maar het gaat om de hele handleiding, die hier beschreven is. Deze is veel te slecht uit gelegd. Als ik een professionals 5/5 opzoek zijn sommige veel beter beschreven.

Daarom is deze veel te complex voor iets wat veel gemakkelijker kan. Als ik een leek zou zijn, zou ik meteen weg rennen. Als je zo iets gemakkelijks zo slecht kan uitleggen, dan snap je niet hoe de gemiddelde gebruiker denkt.

Ach. Of je kijkt gewoon even zelf. Open de directory met het gedownloade bestand in de file manager en klik op de rechter muisknop. Dan Properties en dan de Checksums tab. Daarin heb je drie knopjes om verschillende soorten checksums te berekenen (MD5, SHA1 en SHA256). Klik op de knop voor de te controleren checksum en vergelijk het resultaat met wat er op de download pagina staat. Voila. (Onder Linux met KDE).

Ik heb er geen probleem mee. Als ik dit zou willen controleren, heb ik gewoon 7zip draaien die netjes de checksums kan genereren. Kost mij een paar seconden en werkt een stuk gemakkelijker en sneller dan de handleiding naar welke hier verwezen wordt.

Het gaat mij er om, dat blijkbaar iemand die deze handleiding heeft geschreven, zelf geen enkel idee heeft, wat een normale gebruiker aan kennis heeft. De hele opzet van deze handleiding is gewoon slecht. En geeft juist bij beginnende gebruikers aan, linux is veel te complex, zie hier hoelastig het wel niet is.

Ik denk dat voor het gros van computergebruikers geldt dat ze installatie van een besturingssysteem beter aan iemand met enige kennis van zaken kunnen overlaten. Dat geldt (zeker, met name) ook voor Windows, echter Microsoft heeft OEM's gechanteerd om Windows standaard geïnstalleerd mee te leveren. Zou datzelfde met Linux aangeboden worden bij nieuwe computers dan zou het al snel afgelopen zijn met de 'populariteit' van Windows.

Ik denk dat dit wel mee valt. Ondersteuning is vaak minder van hardware. En zodra men applicaties wilt gaan gebruiken loopt men totaal vast. Want niets doet het er op van wat men normaal nodig heeft.

Meer keuze zou wel netjes zijn, maar in het verleden verkocht dit bijna nooit. Waarom zou het nu wel in eens anders zijn?

Gewoon hier downloaden, dan loop je de minste risico's.
http://cdimage.ubuntu.com

Precies! En daarna even de Windows Powershell opstarten als administrator en de volgende toverspreuk intikken:

Code:

Vergelijk de output met de hash van de image. Is die gelijk, dan heb je de goede te pakken.

En voor de verificatie onder Linux: open een terminal en tik de volgende commando, ervan uitgaande dat de image in de map downloads zit in je homemap:

Code:

Heel even wachten (je ziet even niets gebeuren), en voilà: je ziet snel daarna de cijferreeks verschijnen. Easy does it! :-)

Zeer slecht voorbeeld...

Moet ik nu ubuntu-base ubuntukylin mythbuntu nemen? Of en van de vele andere.... Maar als je een halt uurje hebt rond geklikt kom je ergens. Al is dat niet heel veel duidelijker. http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/
Hoe moet een gebruiker nu weten wat hij nodig heeft? Je advies is exact het zelfde als de link in als waar de discussie mee gestart wordt. Deze is eigenlijk zelfs nog minder overzichtelijker.

Nee juist NIET precies. Je hebt geen idee wat je moet downloaden.

Dit is inderdaad een stuk gemakkelijker, al hebben de meeste geen flauw benul wat powershell is of willen dit weten. Er bestaan genoeg GUI tools die het een stuk gemakkelijker maken voor gebruikers.

Deze werkt 10 keer beter dan de de genoemde GnuPG check. Jouw instructie is ook veel duidelijker dan de genoemde handleiding.

Kijk! Daar heb je het al! Waarom zou je administrator privileges nodig moeten hebben voor het simpele opvragen van een checksum? Als je die privileges niet hebt kan je niet eens een checksum controleren? Microsoft bedankt. En waarom moet dat met de 'Windows PowerShell'? Ik kan dat onder mijn Linux + KDE gewoon in de file manager opvragen.

Aangezien dit onder "security professionals" staat... Ik mag toch hopen dat echte security professionals geen genoegen nemen met het vergelijken van:
- de zelf berekende hash van bijv. http://releases.ubuntu.com/bionic/ubuntu-18.04.1-live-server-amd64.iso
- de bij dat bestand horende hash uit bijv. http://releases.ubuntu.com/bionic/SHA256SUMS
Want als dat zo is, is Microsoft's aanpak met authenticode vele malen veiliger en wordt het niks met veilige Linux systemen. Vries me dan meer weer in...

Het lijkt mij goed als een van de reageerders hierboven (die ook het bijbehorende .gpg bestand downloaden en die ook de authenticiteit van de public key checken) of een andere echte security professional, uitlegt waarom je met deze check hooguit aantoont dat de ISO niet onopzettelijk is beschadigd tussen het moment waarop iemand eerder de hash berekende over het bestand dat jij gedownload hebt, en jij dat nu opnieuw doet en die twee hashes vergelijkt.
Hint: een CRC of zelfs een nog simpeler checksum was goed genoeg geweest voor dat doel.

Bonuspunten voor degene die uitlegt waarom het ronduit schandalig is dat https://releases.ubuntu.com/ niet werkt (waarbij het onwenselijk, maar nog net acceptabel, zou zijn als downloads van grote bestanden, met name ISO's, uitsluitend via http mogelijk zouden zijn).

@Bitwiper: Je hebt op zich gelijk natuurlijk (een beetje schaamrood op de wangen hier i.p.v. het meer gebruikelijke schuim op de bek).

De http download links zijn echter op zich niet zo erg (want je controleert immers het downloaded bestand immers met SHA256) maar je moet de herkomst van de 'good-values' informatie wel hebben gecontroleerd natuurlijk. Dat staat ook in de instructies: https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#3 en https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#4.

"A Good signature means that the checked file was definitely signed by the owner of the keyfile stated (if they didn't match, the signature would be reported as BAD). The warning message is simply there to let you know that you have not countersigned the key and it isn't in your list of trusted sources."

Je hebt ook helemaal geen administrator privileges nodig. Kan gewoon user gebruikers rechten.

1: assumption is the mother of all f ups.... Denk je nu echt dat de middelde gebruiker dit gaat doen? Of zelfs de normale gebruiker? Je mist duidelijk de ervaring van de middelde gebruiker.
2: We hier op een security forum. https moet gewoon de standaard zijn. En niet daarom heen iets fabriceren. Dit zijn hele slechte adviezen, en vallen mij zwaar tegen van FOSS.
3: Als Microsoft dit over http zou aanbieden, was de wereld te klein. Nu bagatelliseer je dit even.

Die beide bestanden (ISO en file met hashes) heb jij dan, waarschijnlijk - maar niet noodzakelijkerwijs, geheel gedownload vanaf één en dezelfde server.

1) Dat is niet noodzakelijkerwijs het geval: een MITM met toegang tot jouw verbinding met de echte releases.ubuntu.com kan een (evt. heel klein) deel van het ISO bestand -on the fly- hebben gewijzigd, en daarmee een backdoor hebben gecreëerd. En ook van het SHA256Ssums bestand hoeft de MITM alleen maar de hash van de ISO aan te passen om die weer te laten kloppen, maar gemakshalve zal de aanvaller vermoedelijk dat hele bestand vervangen door haar versie. Toegegeven, het scenario van "on-the-fly" aanvallen ligt niet zo voor de hand - tenzij je iets te vrezen hebt van één of meer "state level actors".

Indien die twee bestanden daadwerkelijk zijn gedownload vanaf één en dezelfde server, heb je te maken met in elk geval de volgende risico's:

2) Middels BGP-hijacks kunnen aanvallers jou naar een geheel andere server (doch met hetzelfde IP-adres als van releases.ubuntu.com) sturen, waarna die aanvallers jou kunnen laten downloaden wat zij willen;

3) Een aanvaller kan downloaders, via DNS manipulatie, naar een andere server, met een ander IP-adres, sturen. DNS manipulatie kan o.a. door jouw modem te hacken, de cache van jouw DNS server te poisonen, met social engineering of hacking in te breken op het DNS-configuratie account van Ubuntu.com, of door BGP hijacks uit te voeren tussen de authoritative DNS server(s) voor releases.ubuntu.com en de door jouw PC gebruikte DNS server;

4) Een aanvaller kan hebben ingebroken op de server releases.ubuntu.com en bestanden hebben vervangen (maar dat kan lastig zijn, bijv. als grote uploads tot alarm bij de beheerders leiden), maar kan ook bestanden minimaal hebben gewijzigd (inclusief de hash files);

5) Een aanvaller kan tussen de "build server" en releases.ubuntu.com, doch na het signeren van bestanden, bestanden hebben gemanipuleerd;

6) Een aanvaller kan ergens voor het signeren van bestanden, bestanden hebben gemanipuleerd (dit is de gemeenste, op dit punt ben je volledig afhankelijk van hoe veilig Ubuntu en hun toeleveranciers werken).

Exact.

Die eerste bevat het slechtste advies dat je m.b.t. PGP/gpg/gnupg kunt geven. Daaruit (een deel; wat daarop volgt -of vooral wat daarin ontbreekt- is ook zeer belangrijk):
, but (for multiple reasons) these could as well be keys belonging to an attacker.

I.v.m. TLDR laat ik het hierbij (het gaat trouwens deels om een herhaling van wat ik aan het begin van deze bijdrage schreef).

Daar heb je wel een punt. De verificatie van een downloaded ISO-bestand wordt inderdaad wat (te) ingewikkeld voor de gemiddelde gebruiker. En daarom geeft Microsoft er natuurlijk gewoon helemaal geen instructies voor: als je een Windows 10 image downloadt via https://www.microsoft.com/nl-nl/software-download/windows10 krijg je gewoon een ISO-bestand (ik zie nergens instructies om dat te verifiëren). (We hebben het niet over het updatemechanisme maar over downloaded ISO-bestanden.)


Ik had niet de bedoeling om die http i.p.v. https te bagatelliseren... Ik dacht alleen dat het door de verificatie niet uit zo (mogen) maken. Maar - bij nader inzien - is dat verificatie-stappenplan inderdaad nogal ingewikkeld. Gebruik van https bij de bron - zoals Microsoft doet - is vanzelfsprekend beter. Hoewel die ISO-bestanden natuurlijk gaan rondslingeren en je er niet steeds zicht op hebt. Zonder verificatie moet je die dan niet gebruiken (bij twijfel nieuwe downloaden).


Dat gaat natuurlijk (hopelijk) niet zomaar want die public keys worden gegenereerd met de secret key van "Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>".

Indien je de Windows tool gebruikt, zit dit al ingebakken. En volgens mij wordt de download via https aangeboden.

Veel, zo niet alle, Windows updates gaan via http (de meeste als signed .cab, .exe en .msi files). State (level) actors kunnen, mits in bezit van de juiste private key (horende bij een pubkey in een cert dat door Windows wordt geaccepteerd als geldig voor signing van updates), zo eenvoudig backdoors aanbrengen op PC's naar keuze. Indien hiervoor authenticated https verbindingen gebruikt zouden worden, zouden aanvallers een two-factor uitdaging hebben. Gezien de laksheid waarmee gecompromiteerde codesigning certs worden ingetrokken (als dat al gebeurt), m.i. geen overbodige luxe.

In WireShark zie ik echter ook unsigned XML bestanden vanaf MS update servers gedownload worden via http, maar ik weet niet of aanvallen mogelijk zijn door die bestanden te manipuleren. In elk geval versturen W10 PC's ook niet-versleutelde (en unsigned) telemetriegegevens naar Microsoft (voor ietsje meer details zie halverwege https://www.security.nl/posting/573853#posting573908).

Ten slotte (in deze bijdrage, Microsoft heeft m.i. qua PKI een veel te groot aanvalsoppervlak) worden een stel CRL files, kort na optstarten van Windows, onverbloemd via http gedownload - waardoor het voor aanvallers een onnodig koud kunstje is om die downloads (straffeloos, want je ziet geen foutmelding) te blokkeren. Die wereld zou m.i. allang te klein moeten zijn...

Maar hoewel Authenticode absoluut niet feilloos is zou de Linux community op dit punt wat van Microsoft kunnen leren.

Stel je het op prijs als ik het toelicht?

P.S. niet aan jou persoonlijk gericht, want ik weet niet uit m'n hoofd of jij wel eens kritiek hebt geuit op mijn bijdragen, maar ik ben er een beetje klaar mee om als wijsneus te worden bestempeld. Ook ik ben als noob begonnen, en ook ik weet nog lang niet alles (gaat nooit lukken trouwens) - maar beproef graag of ik het e.e.a. goed begrepen heb en ben dan ook zielsgelukkig met goed onderbouwde tegenargumenten. En ik ben ook niet te beroerd om mijn ongelijk toe te geven - chapeau nog voor jouw "een beetje schaamrood op de wangen hier", zoiets siert mensen!

Microsoft heeft hier als voordeel (kost wat, heb je ook wat) dat ze de distributie heel erg in eigen beheer houden.
Dus zolang je het via HTTPS van een microsoft.com site haalt krijg je de hele keten garantie van SSL.

Heel veel Linux distributies moedigen het gebruik van mirrors aan(die door jan -en alleman gerund kunnen worden) , om de noodzaak van een eigen CDN te beperken, en zodat gebruikers overal een snelle download kunnen hebben.
Of torrent downloads.

Die mirror server kan op zich best HTTPS gebruiken alleen dat garandeert heel weinig of de bestanden van redhat/centos/ubuntu/debian werkelijk kopieën van de bron zijn - dat is je vertrouwen in de operator van de mirror.

En zolang de images/packages op een vertrouwde manier GPG gebruiken om iso's en packages te controleren is daar helemaal niks mis mee

[..]


De _echte_ public key is inderdaad gemaakt met de echte secret key van Ubuntu. Maar je kunt prima een andere key maken die zich ook zo noemt, en ook dat keyid heeft .

SSL lost dit kip-en-ei verhaal op met root certificaties die andere certificates ondertekenen. En die 'vast' in je browser zitten.
GPG lost het op met een 'web of trust' , van vertrouwde GPG keys die andere keys ondertekenen. Het heeft dus niet de gedwongen hierarchie van SSL, maar het probleem dat je keten van vertrouwen ergens moet beginnen is hetzelfde.
En dat je een ononderbroken keten van trusted signatures nodig hebt om een key te kunnen vertrouwen.

(Of je moet de volledige key fingerprint controleren - als je die op de één of andere manier wel op een vertrouwde manier kunt krijgen/controleren )

En als je begint met een helemaal lege keyring, kun je (in theorie) dus een valse signing key toegestuurd krijgen en daarmee valse images accepteren.

Natuurlijk! Ik neem aan dat je doelt op de (hopelijk theoretische) mogelijkheid dat je zelf een secret key aanmaakt voor "Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>" en dan een 'evil' public key naar de Ubuntu keyserver uploadt. Ik hoop dat dit niet mogelijk is maar ik (durf) het niet zelf te proberen :-)


Volgens mij niet of op z'n minst weinig. Als 'wijsneus' zal ik je zeker niet hebben bestempeld.


Ik was zo fel van leer aan het trekken met het gemak van checksums controleren onder Linux + KDE dat ik het grotere plaatje met verificatie van signatures uit het oog was verloren...

OK dan :-)

A) hkp is een protocol waarbij de server niet wordt geauthenticeerd en de verbinding niet wordt versleuteld (laat staan dat de integriteit van de overgedragen gegevens automatisch wordt gecontroleerd). Hoewel keyservers met geauthenticeerde TLS verbindingen ook valse public keys kunnen bevatten, vergroot een download via een "plain text" verbinding het aanvalsoppervlak en daarmee jouw risico's. Doordat hkp vergelijkbaar is met http (en hkps met https) ontbreekt een stukje zekerheid dat er gewoon had kunnen zijn, doordat je, via de eerder door mij genoemde aanvalstechnieken, ook een valse public key vanaf een valse server (of on-the-fly gewijzigd door ee MITM) kunt downloaden.

In bijv. https://security.stackexchange.com/questions/4161/shouldnt-gpg-key-fetching-use-a-secure-connection wordt beargumenteerd (de arrogantie spat er vanaf) dat de noodzaak voor authenticatie van keyservers, en het vervolgens beschermen van de integriteit van de overdracht, flauwe kul zou zijn - omdat je keyservers sowieso niet moet vertrouwen. Echter, daar gaat de Ubuntu tutorial volledig aan voorbij (zie C) maar sowieo ben ik het niet eens met die stelling, omdat:
- Als een public key op een "echte keyserver" staat (en dus door keyservers onderling wordt gesynchroniseerd) is de kans groter dat nepsleutels op een gegeven moment worden ontdekt;
- Op basis van wat ik onder B uitleg, zouden er, van dezelfde geclaimde eigenaar, niet twee verschillende public keys met dezelfde key-ID (in de crypto wereld een collision genoemd) op mogen voorkomen;
- Het bij "TLS eronder" om een zeer gangbare maatregel gaat.

M.b.t dat derde punt: wellicht voegt TLS netto niet heel veel veiligheid toe, maar alle beetjes helpen. Bovendien zie ik nauwelijks een gevaar voor een vals gevoel van veiligheid (omdat https helemaal geen bijzonderheid meer is, en iedereen zou moeten weten dat een https verbinding niet betekent dat wat op de site staat, altijd betrouwbaar is of klopt).

B) De in de Ubuntu tutorial vermelde key ID's zijn 4 bytes lang: 0xFBB75451 en 0xEFE21092. In een 4 bytes lang getal kun je maximaal 4.294.967.296 verschillende decimale getallen kwijt. Dat is minder dan de wereldbevolking groot is, en bovendien bestaat hiervoor geen systeem dat zoveel mogelijk uniciteit nastreeft. Er is dus, vroeger of later, gegarandeerd sprake van collisions (verschillende public keys die tot dezelde key ID leiden). Sterker, er bestaan tools om deze collisions te genereren (zie evil32 verderop).

Bij een collision zijn er 2 situaties mogelijk (ik heb geen idee wat er precies gebeurt in zo'n situatie):
- Keyservers accepteren ook de tweede key ID (identiek aan de key ID van een eerder geüploade public key), waarna je maar moet afwachten welke public key je terug krijgt op basis van een key ID;
- Om misverstanden te voorkomen, accepteren keyservers de public key met de niet unieke key-ID niet (genereer maar nieuwe sleutelparen totdat je een unieke key ID vindt of zo).

Beide situaties zijn onwenselijk. Maar in de tweede situatie, als het een aanvaller lukt om een code signing keypair te genereren met een identieke key ID, en zij jou middels eerder door mij genoemde aanvallen naar haar eigen keyserver stuurt, heb jij een foute key met correcte key ID in handen. In de eerste situatie zou het best Russisch roulette kunnen zijn welke key je krijgt, of wellicht altijd de als laatst geüploade. Beide scenario's zijn dus onwenselijk.

Volgens https://lwn.net/Articles/689792/ was het Enrico Zini, notabene een Debian contributor, die de eerste PGP key ID collission "in the wild" zou hebben ontdekt. Zie https://gwolf.org/node/4070 voor het hele verhaal en/of check https://lwn.net/Articles/697417/. Uit https://evil32.com/:
TLDR: vertrouw nooit alleen op afkortingen van unieke identifiers (fingerprints, secure hashes) van public keys, want met bijv. 4 bytes lengte heb je in de praktijk gigantisch veel meer kans op collisions dan met bijv. SHA1 - een cryptografische hash van 20 bytes lang, die we, vooral vanwege mogelijke collisions, al niet meer gebruiken!

C) Maar los van het bovenstaande: het grootste risico is dat op keyservers fake public keys (daarmee bedoel ik echte public keys van een andere dan de geclaimde eigenaar) te vinden zijn, met hoogstwaarschijnlijk een andere 4 byte lange key ID (maar die leidt de gnupg software af uit wat in sha256sums.sig staat, die nou net van dezelfde aanvaller afkomstig kan zijn als waarvan jij daarna de public key gaat downloaden - omdat die - duh- nog ontbreekt in jouw sleutelbos).

En dit is geen fictie: in 2015 (ruim voor evil32) schreef de security redacteur van de Duitse c't (uitgeverij Heise), Jürgen Schmidt, dat aanvallers of grappenmakers een public key op zijn naam (@ heise.de) op keyservers hadden gepubliceerd (Duitstalig en helaas grotendeels achter een pay-wall: https://www.heise.de/ct/ausgabe/2015-6-Gefaelschte-PGP-Keys-im-Umlauf-2549724.html; algemene kritiek op PGP, van dezelde auteur doch zonder pay wall: https://www.heise.de/ct/ausgabe/2015-6-Editorial-Lasst-PGP-sterben-2551008.html). Probleem: hij ontvangt versleutelde mails die hij niet kan ontsleutelen en anderen kunnen namens hem mails en bestanden ondertekenen (waarbij non-repudiation AKA "it wasn't me proof" alleen mogelijk is bij ontvangers die de risico's kennen en begrijpen). Last but not least kan hij deze sleutels niet intrekken (want hij heeft de bijbehorende private key niet).

Met andere woorden, het is essentieel dat je, op secundaire wijze, zorgvuldig controleert dat een public key daadwerkelijk van de geclaimde eigenaar is voordat je deze toevoegt aan jouw keyring (om deze daarna te gebruiken om bijv. de authenticiteit van bestanden, zoals Ubuntu ISO's, te controleren). Doe je dat niet, dan hou je jezelf voor de gek als je meent dat deze weg veiliger is dan het downloaden van een secure hash plus het onderhavige bestand vanaf dezelfde server (zelfs als het daarbij om een https verbinding zou gaan). Immers, het is zaak om in elk geval de risico's 1 t/m 5 uit mijn bijdrage van 13:53 van 18-08-2018 af te dekken (https, mits een servercertificaat wordt gebruikt waarvan je voldoende zeker weet dat deze niet aan een andere organisatie dan Ubuntu is verstrekt, mitigeer je de risico's 1 t/m 3 uit mijn eerdergenoemde bijdrage).

Kortom, los van dat maar weinigen tutorials als https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#3 weten te vinden en helemaal lezen:
- Het gebruik van hkp i.p.v. hkps wordt beschrevent;
- Er worden 4 byte lange key identifiers gebruikt waarvan jaren geleden is aangetoond dat die onveilig zijn;
- Last but not least vermeldt de tutorial niets over het wellicht allerbelangrijkste aspect van PGP et al, vooral m.b.t. digitale handtekeningen: dat je zelf moet vaststellen (of anderen, die jij vertrouwt en waarvan jij de public keys hebt en hebt vastgesteld dat die van hen zijn, hebben vastgesteld) dat een public signing key, zoals van Ubuntu, daadwerkelijk toebehoort aan de geclaimde identiteit.

Prima verhaal - alleen een nitpickje hier - SHA-1 is deprecated omdat het genereren van collisions _makkelijker_ is dan op basis van de lengte te verwachten was.
Je tekst lijkt te suggereren dat 20 bytes (160 bits) al het probleem is.
Het falen in collision resistance is echt een zwakte van het algorithme en de meest belangrijke reden om SHA-1 uit te faseren.

Normaal kost het vinden van een _collision_ (in de crypto definitie) van een n-bits hash 2^(0,5n) pogingen. 2^80 dus voor een 160 bit hash .
Voor SHA-1 is dat gedaald naar ca 2^63 - 100,000 keer makkelijker dan gewenst voor een hash van deze lengte.

Een collision attack is het vinden van _twee_ messages met dezelfde hash uitkomst .
Het vinden van een (andere) message die past bij een gegeven hash uitkomst is - voor een goede hash - *ontzettend veel moeilijker* . Dat wordt geen 'collision attack' genoemd - maar een (first) pre-image attack. Voor een goede hash van n bits hoort die moeilijkheid 2^n te zijn .

Noch voor MD5 , noch voor SHA-1 zijn (bruikbare) pre-image aanvallen bekend.

Eens, maar het risico zit hem erin dat een kwaadwillende 2 verschillende bestanden (binaries, PDF's, certificaten, Ubuntu ISO's etc.) kan maken met dezelfde hash, een "nette" en een "kwaadaardige". Er bestaan tools om deze collision attacks uit te voeren, die een input bestand 2x zodanig aanpast dat er 2 bestanden ontstaan met dezelfde hash. Een dergelijke truc betekent (in tegenstelling tot wat veel mensen denken) wel degelijk een risico in de praktijk.

Zo zou een foute (of gedwongen) Ubuntu medewerker een schone en backdoored ISO kunnen maken met bijv. identieke SHA1 checksums, de schone op de Ubuntu downloadserver zetten, en de backdoored versie aan state (level) attackers verkopen - die de laatste selectief kunnen inzetten via bijv. een MITM aanval. Een slachtoffer dat SHA1 gebruikt om te controleren dat zijn versie dezelfde is als die op de download server zal niet zien dat zij een binair verschillend bestand in handen heeft.

Op vergelijkbare wijze was het destijds mogelijk om 2 verschillende certificate signing requests te genereren met dezelfde hash. Je moet dan wel wat moeite doen om de variabelen die de Certificate Service Provider in het certificaat zet te voorspellen, maar ook dat is mogelijk gebleken (desgewenst kan ik een link voor je opzoeken).

Exact om deze reden moet je NOOIT meer MD5 of SHA1 gebruiken om te checken of een bestand "nog hetzelfde is". Het gaat bij deze aanval dus niet om wijzigingen "onderweg" zodanig dat de hash hetzelfde is (een pre-image attack), maar om een echte collision attack vooraf.

Terzijde: je zou MD5 prima kunnen gebruiken als afgeleide van een wachtwoord, ware het niet dat het probleem met MD5 (en de meeste andere cryptografische hash functies for that matter) is dat deze, zeker op moderne computers, veel en veel te snel is (wat je nog een beetje kunt mtigeren met salts). En daarnaast, dat mensen veel te korte en voorspelbare wachtwoorden gebruiken (maar ook dat is een probleem hooguit ietsje gemitigeerd door slome functies te gebruiken). MD5 is niet gekraakt in de zin dat je, uit een hash, altijd de input kunt herleiden. De voorwaarde daarbij is wel dat de input evenveel of meer entropie kent dan de hash zelf, maar ook dat probleem geldt voor alle cryptografische hashes (het maakt niet uit of je MD5 of SHA-512 gebruikt om 10-cijferige telefoonnmummers te hashen, met een snel gerealiseerde rainbow table kun je uit elke hash het oorspronkelijke telefoonnummer herleiden).

Ik bedoelde aan te geven dat collisions een risico vormen. En zoals ik hierboven heb toegelicht, zijn collision attacks wel degelijk de reden dat je geen 20 byte lange SHA1 meer moet gebruiken. En dus al helemaal geen 4 byte lange key ID's, en dat is wat ik probeerde aan te geven ;-)

Iemand die thuis Windows draait en wel eens Linux wil proberen, kan prima volstaan door de download van het ISO installatie bestand via een beveiligde HTTPS verbinding plaats te laten vinden. Geeft enige mate van zekerheid.

Zolang men zich dan maar beperkt tot een van de grotere, bekende Linux distributies en de ISO installer daarvan rechtstreeks vanaf de website van de organisatie van de ontwikkelaar download.

De online gepubliceerde ISO checksum kan men daarna vergelijken met de eigen uitkomst daarvan. Klopt die som niet, dan is het bestand vermoedelijk stuk. Geen directe reden voor achterdocht, maar zekerheid heb je niet.

Voor professionals die een wagenpark aan desktops en servers onderhouden bestaat er de mogelijkheid om de mate van zekerheid van de authenticiteit van het ISO bestand te waarborgen: dat doet men door de GPG signatuur te verifieren:

https://gnupg.org/documentation/

Niet iedereen kan het wagen om over slechts een nacht ijs te gaan. Dus stel het gemak voor de gemiddelde Windows gebruiker niet boven de eisen die men beroepshalve moet stellen als het er echt om spant.

Dat is om dezelfde reden dat <ftp://ftp.ubuntu.com> ook nog steeds gewoon oversleuteld geschiedt. De gegeven URL <http://releases.ubuntu.com> is namelijk de HTTP-webinterface van de anonymous FTP-directory van Ubuntu.com

De installatie ISO-bestanden van Debian en Ubuntu worden namelijk ook wereldwijd verspreid door middel van anonymous FTP en middels BitTorrent. Vandaar de noodzaak van SHA256 checksums en detached GPG signatures ;-)

Dat is wel zo aardig voor mensen in Afrika en Zuid-Amerika of andere delen in de wereld die nog niet over de meest snelle hardware noch over breedband internet beschikken. Toepassing van FTP en BT houdt de overhead kosten laag.

Daarnaast is er voor de verwende westerling met snelle internet uiteraard tot z'n beschikking ook een versleutelde download rechstreeks vanaf Ubuntu.com via HTTPS mogelijk:

Official CD/DVD images of the "stable" release
https://www.debian.org/CD/http-ftp/#stable

Download Ubuntu Desktop
https://www.ubuntu.com/download/desktop

n.b. De default download HTTPS-pagina van Ubuntu.com voor de Desktop ISO-installer versie verwijst niet naar de locatie van de SHA256 checksum en het bijbehorende detached GPG signature.

Die benodigde gegevens treft men, na enig zoeken, aan onder de genoemde sectie van alternative-downloads:

https://www.ubuntu.com/download/alternative-downloads

Ubuntu.com draait een SKS OpenPGP Key server die via het web beschikbaar onder HTTPS

https://keyserver.ubuntu.com/

Een beveiligde HKPS aanvraag vanaf de Terminal commandline zou met GnuPG daarom gewoon moeten werken:


Let op die extra kleine letter S in het gekozen protocol om de keyserver aan te roepen: zo ingrijpend kan een klein detail zijn als het op veiligheid aankomt.

Dat gpg commando blijkt ook gewoon te werken, waarmee een MITM aanval op dit vlak aanzienlijk te bemoeilijken valt. De aangehaalde Tutorial van Ubuntu.com kan op dit ene punt dus aanzienlijk worden verbeterd.

Ook Microsoft stuurt gegevens via http en zijn net zo min "heilig". Zie hier: https://www.security.nl/posting/574019/W10+sends+USB+telemetry+via+http

Ik was deze draad uit het oog verloren, sorry!
Als dat werkt is dat een fix voor punt A), maar daarmee zijn de problemen beschreven in B) en C) uit mijn bijdrage (https://security.nl/posting/573957) nog niet opgelost.