SHA1-digestnamn i OpenSSL: vad en gammal lista betyder

Gamla digestlistor läses som en transkription av kryptografiska beslut, och det är de inte. Namn som SHA1, DSA-SHA1-old eller RSA-SHA1-2 står bredvid varandra i gamla OpenSSL-byggen eftersom biblioteket registrerade flera ingångspunkter kring besläktad hash-maskineri. En RSA- eller DSA-etikett i den listan OpenVPN säger ingenting om vad OpenVPN gjorde med ett paket. Det du läser är bibliotekets inventarium, inte upptagningen av en session.

Tre saker måste skiljas åt innan någon slutsats blir meningsfull: det registrerade namnet, digestberäkningen under det och operationen som förbrukar det.

En registrering är ett gränssnitt, inte en styrkebedömning

I OpenSSL 1.0.2 binder digestregistreringstabellen samman namn, alias och implementeringar i en enda fil. Den gamla DSS1-beskrivningen är det tydligaste fallet: den anger utdatalängden för SHA-1 och anropar SHA-1:s slutrutin medan den bär ett namn som antyder en helt annan algoritm. Extra bokstäver i en registrering innebär därför ingen annan hash, ingen längre utdata och ingen ny säkerhetsnivå.

Samma källa bevarar aliasrelationer för äldre anropare, vilket förklarar varför en lista ser överfull ut. Det är dokumentation av kompatibilitet, inte ett löfte om att en nuvarande OpenSSL-leverantör visar identiska namn.

Signeringsnamn skapar inte signaturer

Ett signeringsramverk kan binda en digest till ett annat algoritmgränssnitt så att befintliga anropare fortsätter att kompilera. En riktig offentlig-nyckel-signatur behöver både en nyckel och signeringssteget som använder den, och ingen av dem tillhandahålls av ett namn i en meny. En RSA-färgad digestpost är ett namn som en anropare får använda, inte bevis för att varje VPN-paket bar en RSA-signatur.

Det är i detta steg äldre texter glider över i folklore. Om du behöver veta hur paket autentiserades, hitta alternativet som valde mekanismen och läs vad det gör i den version du faktiskt kör. Manualsidan som levererades med den utgåvan är den enda beskrivning som passar programmet framför dig. Arkiverad dokumentation beskriver den utgåva de skrevs för, och den kan ligga flera namngivningskonventioner efter.

Hitta alternativet som förbrukade namnet

I paketautentiseringsfallet som OpenVPN 2.6 dokumenterar väljer auth en digest som HMAC använder, en nyckelbaserad meddelandeautentiseringskonstruktion snarare än en certifikatsignatur. Signeringsalgoritmen för TLS-certifikatet är en separat egenskap hos handskakningen.

Med ett AEAD-datachiffer slutar den separata inställningen auth att gälla för datakanalen, medan dess roll för tls-auth förblir en egen fråga. En digestlista kan därför inte säga vilken hash som skyddade de aktuella paketen, vilken TLS-svit som förhandlades eller hur motpartens certifikat signerades. Endast den effektiva konfigurationen plus versionen kan svara på det, och bara för anslutningen framför dig.

Skriv ner vad du faktiskt har

Skriv ner OpenVPN-versionen, det länkade kryptobiblioteket, de exakta alternativen i profilen och resultatet av en riktig anslutning. Den uppsättningen svarar på frågor som en skärmbild av en digestmeny inte kan, och den överlever nästa uppgradering eftersom den namnger versioner i stället för intryck.

Framför allt, välj inte ett gammalt alias för att namnet låter starkare eller mer specifikt. Välj den stödda policyn för hela anslutningen och behandla de gamla namnen som en dokumentation av hur ett bibliotek tidigare presenterade sig.