Microsoft wil eerder stoppen met verouderd sha-1-algoritme

Microsoft wil het hashing-algoritme sha-1 vanaf juni 2016 gaan blokkeren. Het verouderde algoritme is in de loop van de tijd kwetsbaar geworden voor steeds eenvoudigere aanvallen. Met de blokkade treedt Microsoft in de voetsporen van Mozilla en Google.

Dit meldt Microsoft op zijn blog. In eerste instantie zou het gebruik van sha-1 vanaf 1 januari 2017
geblokkeerd worden. De reden voor het vervroegen van de deadline is dat de veiligheid van het hashing-algoritme steeds meer in het geding komt. Microsoft refereert daarbij aan de freestart collision-aanval, die in oktober werd uitgevoerd.

Beveiligingsexpert Bruce Schneier had in 2005 al bedenkingen bij het algoritme uit 1995, maar destijds was het doen van een aanval nog niet economisch interessant. Het wordt echter steeds goedkoper om een aanval uit te voeren. Sha-1 wordt onder andere gebruikt voor het ondertekenen van ssl/tls-certificaten. Het vervalsen van een enkel certificaat door collision kan vergaande gevolgen hebben. Hierbij wordt een certificaat aangemaakt met dezelfde hashwaarde als een legitiem certificaat.

In zijn planning geeft Microsoft aan dat certificate authorities vanaf 1 januari 2016 alleen nog maar certificaten mogen uitgeven die zijn ondertekend met het vernieuwde sha-2. Na het verstrijken van de deadline in juni 2016 zal Windows alleen nog certificaten vertrouwen die met sha-2 zijn ondertekend.

Reacties (69)

[Yggdrasil]

Gelijk maar even in Outlook ingesteld dat voor ondertekenen of versleutelen via S/MIME ook het SHA2 algoritme gebruikt wordt, i.p.v. de standaard SHA1. Is niet moeilijk, maar wel ver weg gestopt.

Volg de stappen op https://www2.ku.edu/~tech...igicert/setup/step3.shtml, behalve stap 6. Kies daar als Hash-algoritme voor SHA256 (= SHA2) en als Versleutelingsalgoritme voor AES (256-bit).

Die algoritmes leveren een goede beveiliging én compatibiliteit. Als je zwaardere instellingen kiest (zoals SHA512) kan het zijn dat ontvangers op bijv. Windows XP je mail niet kunnen lezen.

[H!GHGuY]

Je kan maar beter AES niet op 256bit gebruiken.
Zie ook https://www.schneier.com/...9/07/another_new_aes.html

Meer bits is niet altijd beter.

[deadinspace]

Je kan maar beter AES niet op 256bit gebruiken.
Zie ook https://www.schneier.com/...9/07/another_new_aes.html

Nou nou, selectief lezen is ook een kunst

De aanval die Schneier daar aanhaalt is tegen afgezwakte versies van AES-256. De aanval is erg effectief tegen AES-256 met 9 rounds, minder effectief bij 10 rounds, nog minder bij 11 rounds, en daarvoorbij helpt de aanval niet noemenswaardig meer. Volledig AES-256 gebruikt 14 rounds en is dus niet te breken met deze aanval.

Waarom was de aanval van Schneier dan überhaupt nieuws? Omdat we de wiskunde achter de meeste encrypties niet goed genoeg begrijpen. We kunnen niet bewijzen dat bijvoorbeeld AES of RSA veilig zijn. Het beste dat we op dit moment kunnen doen is iedereen laten proberen, en als duizenden slimme onderzoekers het niet weten te kraken, dan nemen we aan dat het veilig genoeg is.

Maar daarvoor is het fijn een veiligheidsmarge te hebben, voor het geval dat er toch nog een betere aanval gevonden wordt. En 11 van de 14 rounds is natuurlijk akelig dichtbij aan het komen, dus enige zorg over AES-256 is terecht. Maar het is niet alsof AES-128 er veel beter aan toe is (wat jij impliceert), daarvoor zijn 8-round aanvallen bekend, en volledig AES-128 gebruikt 10 rounds. Ook eng dus.

Wat Schneier zegt is dat er gegeven de aanvallen die nu bekend zijn, relatief weinig reden is om AES-256 te gebruiken over AES-128:

And for new applications I suggest that people don't use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you're already using AES-256, there's no reason to change.

Verder stelt hij (terecht, imho) voor om AES te reviseren, om meer rounds te gebruiken voor alle key-lengtes.

[Verwijderd]

NSA, voor zover het een bron is, adviseert tenminste AES-256
https://www.nsa.gov/ia/programs/suiteb_cryptography/

[smiba]

Persoonlijk maak ik me zorgen als ik encryptie gebruik die de NSA mij aanraad. Maar misschien ben ik de enige daar in

[vSchooten]

het is een dubbele taak die ze hebben.

[Yggdrasil]

Goed punt. Dat bedoelde ik eigenlijk ook met mijn waarschuwing maar had het alleen op het hash-algoritme betrokken. AES-128 is voor encryptie een goede keuze.

[uiltje]

Oud nieuws. Dat is de related key attack van weleer. Erg belangrijk als je een hash algorithme op AES-256 wilt baseren. Als je gewoon versleuteld met (pseudo) random sleutels is er niets aan de hand. Dat heeft Schneier zelf ook met zoveel woorden gezegd.

[dasiro]

aanvallers kiezen de zwakste schakel, dus waarschijnlijk gaan ze eerder die XP bak hacken/cracken als ze de mail willen lezen. dan is jouw communicatie alsnog achterhaald, dus als je de moeite wil doen om mails te encrypten doe het dan ineens deftig.

[Yggdrasil]

Mwah, ik melde het meer omdat sommigen denken dat een hoger getal beter is terwijl dat bijv. in het geval van AES nog niet bewezen is. Heb zo gauw geen zicht op welke compatibiliteitsproblemen het kiezen voor SHA512 bijv. met zich mee brengt, maar ik vind het belangrijker om alles te kunnen signen dan encrypten en omdat dat al genoeg vragen van ontvangers met zich meebrengt vind ik compatibiliteit wél belangrijk. De CA's die ik gecheckt heb raden overigens allemaal SHA256 aan, maar zonder veel uitleg.

[Martinspire]

Moeten ze eigenlijk tegenwoordig al niet naar een vervolg op SHA-2 gaan? Want voor veel hackergroepen en overheidsinstanties met veel rekenkracht, is dat toch ook geen gigantisch probleem meer?

[the-dark-force]

Het grootste gevaar is naar mijn idee dat versleutelde bestanden nu opgeslagen kunnen worden om later te ontsleutelen zogauw er mogelijkheid toe is of wanneer het economisch verantwoord is om te bruteforcen.

Om de opslagruimte hoeven kwaadwillenden het niet te laten en met de komst van quantumcomputers zou het wel eens heel gauw gedaan kunnen zijn met de nu gebruikte versleutelingstechnieken.

Interresant leesvoer over encryptie en quantum computers:

http://www.nature.com/new...uantum-revolution-1.18332

[Verwijderd]

1024 bit sleutels zijn al niet meer veilig die kun je met voldoende rekenkracht al breken, quantum computers gaan dit nog eens versnellen. Alleen het gegeven waarom we die encryptie niet kunnen breken, de moeilijkheid grote priemgetalen te factoriseren, dat veranderd niet en zal het maken van een grotere sleutel voldoende zijn. Mijn sleutels zijn 4096 bit het te factoriseren getal is zn 2500 cijfers lang dat zijn best veel mogelijkheden! Als het niet genoeg is met een quantum computer maak ik 40960 of 409600 sleutels. Een van de bedenkers van RSA heeft een methode ontwikkelt om aan het geluid van je proccessor te horen wat je private key is.
https://en.m.wikipedia.org/wiki/Acoustic_cryptanalysis

[uiltje]

Heb je wel eens geprobeerd om zo'n grote sleutel te maken? RSA heeft een heel traag sleutelpaar generatie algorithme, wat ook nog eens erg onvoorspelbaar is wat betreft de benodigde tijd / CPU cycles. Als er echt quantum crypto komt moet je toch echt overschakelen naar een ander algoritme. Voor nu, als je echt veilige sleutels wilt gebruiken, kan je het beste aan Elliptic Curves denken. Die zijn heel snel te genereren en ook veel sneller voor berekeningen met de private sleutel.

[MoonWatcher]

Wij doen dit voor al onze hosting klanten.
Zowel voor DHPARAM/SSH/SSL als OPENVPN keys.
Het kan inderdaad 0.5 to 6 uur duren voor een enkele sleutel. ( behoorlijk random )

De hosting uitrol is bij ons verder wel volledig geautomatiseerd.
Aangezien wij als ontwikkelbureau met hosting vooral opleveren voor eigen klanten is dit voor ons niet een heel groot probleem aangezien we over het algemeen al even van tevoren weten wanneer de site van een klant klaar is.

Het is niet iets waar klanten ons echt op beoordelen maar alle kleine beetjes helpen.

[Verwijderd]

Met gpg wel een aantal gemaakt die ik ook gebruik, ja dat duurt wel een paar uurtjes. Heb ook een python script gemaakt zonder limit maar die gebruikt het raben miller algoritme dus niet zo veilig. 8192 key pair duurde meer dan 24 uur.

[Superstoned]

4096 bit? https://xkcd.com/538/

[Lord Daemon]

Er zijn wel twee punten die ervoor zorgen dat het gevaar wat minder groot is dan jij het misschien voorstelt. Ten eerste is het natuurlijk zo dat de gevoeligheid van informatie in de loop van de tijd vaak afneemt. Veel zaken die je nu heel graag zou willen ontsleutelen, zijn over dertig jaar beduidend minder interessant geworden. Dat geldt niet voor alles, maar wel voor heel veel.

Ten tweede schiet het met die quantumcomputers allemaal nog niet zo op. Nature schrijft in het artikel dat jij citeert dat het nog een "decade or more" kan duren. Maar precies datzelfde werd vijftien jaar geleden ook gezegd. Het zou mij niet verbazen als we over vijftien jaar nog steeds hetzelfde zeggen: dit soort technologische vooruitgang is nu eenmaal niet te voorspellen.

Dat neemt niet weg dat je punt een goed punt is; ik wil het hiermee alleen een klein beetje nuanceren.

[the-dark-force]

Een hele goede toevoeging want het inderdaad niet zo heel eng maar een vals gevoel van veiligheid is wat mij betreft gevaarlijker als geen gevoel van veiligheid omdat het de drempel v.h. online delen verlaagt en wie kan met zekerheid zeggen wat wel of niet gevoelig is?
Je geaardheid of geloof kan een gevaar vormen, misschien niet in NL maar over 30 jaar? Wie weet waar iemand dan is of welk regime dan het desbetreffende land bestuurd?

Quantum computers zijn de eerste paar jaar niet commercieel beschikbaar maar onder andere d-wave en ook google hebben al flinke stappen gezet op dat gebied en volgens het eerder genoemde artikel hoeft geen complete quantum computer te zijn zolang het maar die taken kan afhandelen die voor het ontsleutelen van belang zijn.

[Verwijderd]

Er is laatst een redelijke stap gemaakt in quantum computing. De University of New South Wales heeft een gewone silicon transistor aangepast tot een quantum logic gate.
Bron: http://www.gizmag.com/silicon-quantum-computer/39711/

[The Zep Man]

Moeten ze eigenlijk tegenwoordig al niet naar een vervolg op SHA-2 gaan? Want voor veel hackergroepen en overheidsinstanties met veel rekenkracht, is dat toch ook geen gigantisch probleem meer?

Er zijn (nog) geen collision attacks bekend voor SHA-2. Er is dus (nog) geen reden om over te gaan op SHA-3 (Keccak). Als zo'n overschakeling nodig is, dan kan je verwachten dat het weer tien jaar zal duren voordat er een beetje vaart achter komt.

[Soldaatje]

Je zegt het goed: ik nog niet bekend.
Vergeet niet dat toen Alan Turing de Enigma gekraakt had, ze niemand vertrouwden, hun eigen leger niet Churchill niet, niemand. Ze moesten heel veel moeite doen om het geheim te houden en er toch voorzichtig profijt van kunnen hebben militair gezien.
Als je dat doortrekt naar vandaag: zou je als geheime dienst met de kennis van een kwetsbaarheid dit meteen aan de grote klok hangen? Ik denk het niet.

[roy-t]

Er zijn nog geen problemen met SHA-2 bekend en ook nog geen met SHA-3. De kans dat er een probleem gevonden wordt in een van beide algoritmen is denk ik even groot . (Hoewel SHA-2 op dit moment meer aangevallen zal worden omdat het meer gebruikt wordt).

Beide standaarden zijn theoretisch gezien veilig*.

Beide algoritmen hebben op hun veiligste (door standaard gedefinieerde) stand even veel bits die je goed moet gokken om het 'wachtwoord' te achterhalen. Zie ook de tabel onderaan dit artikel: https://en.wikipedia.org/wiki/SHA-2

(*=Zolang er niet ineens een hele rare doorbraak is in de wiskunde of een grote fout is gemaakt in het algoritme)

[uiltje]

SHA-2 heeft een structuur die grotendeels overeenkomt met MD5 en SHA-1. Dat was een van de redenen om met de SHA-3 competitie te beginnen. Een van de verrassingen van de competitie was inderdaad dat er geen extra problemen werden gevonden met SHA-2. Intern is SHA-2 veel complexer dan SHA-1 - zowel wat betreft de structuur als wat betreft de grote van de interne "state". Wel is SHA-2 door de Merkle-Damgard structuur kwetsbaar voor length extension attacks. SHA-3 heeft daar geen last van.

Keccak, de winnaar van de wedstrijd is gebaseerd op een spons constructie. Dat Keccak intern heel anders is dan SHA-2 is een groot pluspunt mochten er toch nog onoplosbare problemen worden gevonden met SHA-2.

[roy-t]

(+2 maar dat mag ik niet geven ).

Het is goed om SHA-3 al achter de hand te hebben, zeker waar! Maar misschien heeft SHA-3 weer last van andere aanvallen, die we nu nog niet kennen, dus zomaar een opvolger gebruiken ondanks dat het huidige systeem nog niet gekraakt is leek me niet zo logisch .

[Soultaker]

Die is er ook al: SHA-3. Maar de voordelen t.o.v. SHA-2 zijn niet zo groot, en met SHA-2 is voorlopig nog niets mis.

[CAPSLOCK2000]

Moeten ze eigenlijk tegenwoordig al niet naar een vervolg op SHA-2 gaan? Want voor veel hackergroepen en overheidsinstanties met veel rekenkracht, is dat toch ook geen gigantisch probleem meer?

Voor zover ik weet is er nog geen realistische aanval op sha2 mogelijk.
Overgaan op SHA-3 is dus nog niet nodig, maar als je toch bezig bent en je hebt de mogelijkheid dan kun je het ook in één keer goed doen. Het probleem is vooral dat er nog maar weinig software is die sha3 ondersteunt. Dat zal eerst moeten komen.
Ik hoop dus dat programmeurs die aan het werk moeten om sha1 te vervangen de kans aangrijpen om zowel sha2 als sha3 toe te voegen, dat zou niet heel veel werk extra moeten zijn. Nog beter is het om het algoritme configureerbaar en vervangbaar te maken zodat je in de toekomst eenvoudig op een ander algoritme kan overstappen zonder je programma aan te hoeven pasten.

[.oisyn]

StartCom, de CA van de veelgebruikte gratis SSL certs van startssl.com, gebruikt ook altijd nog SHA1 ondertekende certs in de chain (de cert zelf is wel SHA256). Je krijgt dan ook geen groen icoontje meer in de balk.

.edit: oh wacht, dat blijkt een caching probleem: https://forum.startcom.or...15&t=15929&st=0&sk=t&sd=a

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:02]

[deadinspace]

StartCom, de CA van de veelgebruikte gratis SSL certs van startssl.com, gebruikt ook altijd nog SHA1 ondertekende certs in de chain (de cert zelf is wel SHA256). Je krijgt dan ook geen groen icoontje meer in de balk.

StartCOM geeft sha-2 certs uit, met sha-2 intermediates (het root cert is nog wel sha-1, maar dat maakt niet uit).

Het probleem is dat hun sha-2 intermediates een heruitgave is van hun bestaande sha-1 intermediates. Hun sha-1-signed en sha-2-signed intermediates hebben dus dezelfde identifier, en daardoor krijg je dat bepaalde browsers deze twee niet uit elkaar houden en in bepaalde gevallen dus de sha-1 versie gebruiken (wat jij caching issues noemde) en dus veiligheidswaarschuwingen tonen.

Naar mijn mening ligt dit aan de aanpak die StartCOM gekozen heeft, en ze houden ondanks alle problemen die dit geeft bijzonder koppig vast aan hun aanpak. Op mijn werk gebruiken we redelijk wat StartCOM certificaten, en dit heeft ons heel veel problemen opgeleverd. De enige manier om dit op te lossen was voor ons door andere, oudere, deprecated sha-2 intermediates van StartCOM te gebruiken omdat die wel een andere identifier hebben. Als die intermediates verlopen dan begint het hele gezeik weer opnieuw, maar tegen die tijd zitten we bij een andere CA.

Ik ben echt goed pissig over hoe StartCOM dit aangepakt heeft, en over hoe ze met hun (betalende) klanten omgaan, en kan alleen maar aanraden ze te mijden als de pest.

[HMS]

StartCom levert toch ook gewoon SHA-2 ondertekende certs voor hun CA en intermediaries? Tenminste, op http://www.startssl.com/certs/ staan ze gewoon. Welke bedoel je precies?

[odiw]

In mijn ogen een goede zet! Alleen hoe zit dat dan in het VK?
Dan zou er in die SHA-2 een backdoor moeten zitten, of zie ik dit verkeerd?

[Dasprive]

In VK wil men end-to-end encryptie aanpakken, en dan specifiek de implementatie er van. Dit betekent dus niet dat men de ondersteunende algoritmes zoals SHA of AES wilt (of uberhaupt kan) voorzien van een backdoor.

Wat ze mogelijk wel gaan doen is makers van software die end-to-end encryptie toepast verplichten in hun software een backdoor in te bouwen.

[The Zep Man]

Wat ze mogelijk wel gaan doen is makers van software die end-to-end encryptie toepast verplichten in hun software een backdoor in te bouwen.

Of degene die het implementeert. Ze kunnen dus gewoon met een bevel komen bij iemand in het VK dat eerdere verstuurde informatie aan de overheid beschikbaar moet worden gemaakt. Doe je dat niet, ga je de bak in. Vergelijk het met het decryptiebevel.

[CyBeR]

SHA-2 is een hash, dat is überhaubt niet terug te rekenen naar de originele inhoud dus wat het VK wil met crypto is irrelevant.

[Armin]

Dan zou er in die SHA-2 een backdoor moeten zitten, of zie ik dit verkeerd?

Ja, want dit is geen encryptie, maar signing. Signing is om te bewijzen dat de verstrekker van de code of server met wie je praat ook daadwerkelijk is, wie hij/zij zegt dat hij/zij is.

Overigens was het gerucht over de UK wet niet zozeer een backdoor, maar enkel dat de sleutels bekend moeten zijn bij de verstreker. Bij TLS verkeer is dat per definitie zo. En bovendien bleek het gerucht onjuist.

[odiw]

Aah oke bedankt voor de verheldering!

[RatedR]

Speaking of which, wanneer gaat tweakers nou eens naar standaard SSL voor de hele website?

[DiedB]

Daar is al eens een artikel over geschreven waarin goed onderbouwd wordt waarom Tweakers geen SSL gebruikt: plan: Dilemma: moet Tweakers https inzetten?

[RatedR]

Bedankt, daar was ik niet van op de hoogte... Vind de eerste (best gewaardeerde) reactie van PlaceboRulez onder dat artikel erg sterk... Eigenlijk wordt SSL afgescheept als "te traag", dit zou volgens mij nooit vóór privacy/security moeten gaaan.

[Yggdrasil]

Precies, én zoals in die reactie al wordt onderstreept zijn er veel manieren om de performance van SSL/TLS te verbeteren die niet standaard aan staan. We zijn nu inmiddels een jaar later en HTTP/2 is officieel beschikbaar en wordt door de meeste servers en browsers goed ondersteund. Hierin zijn ook diverse technieken overgenomen uit SPDY die TLS-sites verder versnellen. Volgens mij zou dit onderwerp door Tweakers opnieuw bekeken moeten worden.

[Sissors]

Overdreven situatie: Het duurt met SSL 30 seconde om tweakers te laden. Dan vind jij nog steeds dat het ingevoerd moet worden om een verwaarloosbare hoeveelheid extra privacy te krijgen?

Het probleem is simpelweg dat het openbare informatie is. Waarom encrypten wat iedereen weet? Ja er zijn wat argumenten, maar volgens mij komt het er toch al snel op neer: Omdat het kan. En dat vind ik nou ook niet heel sterk.

[Reactie gewijzigd door Sissors op 23 juli 2024 03:02]

[ari3]

Privacy is nooit verwaarloosbaar.

[Dasprive]

Ondertussen is er een nieuw belangrijk element bijgekomen waarom men dat toch mag overwegen: Google laat het tegenwoordig meetellen in de ranking waardoor sites met https hoger in de resultaten komen.

[the-dark-force]

Daar is een post over geweest waar dat allemaal wordt toegelicht:
plan: Dilemma: moet Tweakers https inzetten?

TLDR:
Responsetijd is belangrijker als privacy.

Edit: was dus iets te laat door het zoeken van een bron
Maar hier is er dan eindelijk 1 na vele vreemde zoektermen die me vast wel ergens op een lijst plaatsen
http://linuxjournal.com/c...lagged-extra-surveillance

Kleine quote uit de tekst:
"While that is troubling in itself, even more troubling to readers on this site is that linuxjournal.com has been flagged as a selector!"

[Reactie gewijzigd door the-dark-force op 23 juli 2024 03:02]

[rhuijben]

Ik denk dat Microsoft alleen in heel specifieke gevallen gaat stoppen met SHA-1. Dat schrijven ze ook: het gaat om gebruik in certificates.

Anders kunnen we ook wel meteen stoppen met GIT, dat helemaal gebouwd is op deze hashkey.

[Armin]

Precies, SHA-1 certificaten voor code signing vervallen per 1-1-2016. Die moeten vanaf die datum SHA-2 zijn.

Echter een SHA-2 certifciaat is zelf echter ook weer ondertekend om bepaalde kenmerken te beveiligen. Deze kenmerken mogen beveiligd worden met een SHA-1 certifciaat tot 1-1-2017. Daarna moeten de kenmerken ook ondertekend zijn met een SHA-2 certificaat.

Er wordt nu overwogen deze laatste datum naar voren te halen voor certificaten wanneer gebruikt bij TLS tot 1-6-2016.

Alle specifieke details staan hier.

[halofreak1990]

SHA-1 wordt in GIT ook alleen maar gebruikt voor de integriteitsvalidatie en niet voor security.

[Bonez0r]

Eerste zin van het gelinkte sha-2 artikel:

SHA-2 (Secure Hash Algorithm 2) is a set of cryptographic hash functions designed by the NSA.

Doet meteen alarmbellen rinkelen. Maar ik neem aan dat ze het algoritme ontworpen hebben en dat dat openbaar is?

[CAPSLOCK2000]

Doet meteen alarmbellen rinkelen. Maar ik neem aan dat ze het algoritme ontworpen hebben en dat dat openbaar is?

De NSA heeft eigenlijk een verdedigende functie. De laatste jaren horen we vooral over hun aanval op de internetveiligheid maar zo zijn ze niet begonnen. Vroeger was de NSA een belangrijke adviseur voor beveiligers. Op een gegeven moment is de aanvallende rol zo belangrijk geworden dat ze zijn gestopt met gaten in de eigen verdediging te sluiten om te voorkomen dat de vijand z'n eigen gaten sluit. Sindsdien vertrouwt niemand ze meer en wordt ieder advies met argusogen bekeken.

SHA-2 komt nog uit de tijd dat er algemeen vertrouwen was in de NSA.

[the-dark-force]

De code is inderdaad openbaar:https://tls.mbed.org/sha-256-source-code

Mocht het overduidelijk zwaktes bevatten dan werd het niet gebruikt.
Denk aan rsa, niet de methode maar een random number generator was de backdoor.
https://www.schneier.com/...7/11/the_strange_sto.html

[Peran]

Bruce Schneier is erg boeiende gast naar mijn idee. Een aanrader om van tijd tot tijd op te zoeken!

[Yggdrasil]

Precies. Schrijf je vooral in voor zijn zeer interessante nieuwsbrief "Crypto-gram": https://www.schneier.com/...cribe-or-unsubscribe.html

[Peran]

Dit heb ik net op mijn leeslijst gezet:
"Analyzing Reshipping Mule Scams"
https://www.schneier.com/...5/11/analyzing_reshi.html
Het zijn in dit geval hoofdzakelijk een paar quotes.
De reacties zijn echter vaak zeer boeiend. Een van de weinige plekken - naast Tweakers - waar voor mij de reacties vaak belangrijker zijn dan het stuk zelf.

[GoT]

Als je nog een sha1 certificaat gebruikt is het nu al mogelijk om het te vervangen door sha2.
Meestal is het zelfs kosteloos, behalve de tijd die je erin moet steken.

[Reactie gewijzigd door GoT op 23 juli 2024 03:02]

[ErEf]

verstandig om alle root en intermediate certs op een server ook te controleren. maar ik neem aan dat CA's als Comodo Verisign Symantec dat al op orde hebben.