SHA1-digestnavne i OpenSSL: hvad en ældre liste betyder

Ældre digestlister læses som et transskript af kryptografiske beslutninger, og det er de ikke. Navne som SHA1, DSA-SHA1-old eller RSA-SHA1-2 står ved siden af hinanden i gamle OpenSSL-builds, fordi biblioteket registrerede flere indgangspunkter omkring beslægtet hash-maskineri. Et RSA- eller DSA-mærke på den liste siger intet om, hvad OpenVPN gjorde ved en pakke. Det, du læser, er bibliotekets inventar, ikke optagelsen af en session.

Tre ting skal skilles ad, før nogen konklusion giver mening: det registrerede navn, digestberegningen under det og den operation, der forbruger det.

En registrering er en grænseflade, ikke en styrkekarakter

I OpenSSL 1.0.2 binder digestregistreringstabellen navne, aliaser og implementeringer sammen i én fil. Den gamle DSS1-beskrivelse er det tydeligste tilfælde: den angiver SHA-1's outputlængde og kalder SHA-1's afsluttende rutine, mens den bærer et navn, der antyder en helt anden algoritme. Ekstra bogstaver i en registrering betyder derfor ingen anden hash, ingen længere output og ingen ny sikkerhedsgrad.

Den samme kilde bevarer aliasrelationer for ældre kald, hvilket forklarer, hvorfor en liste ser overfyldt ud. Det er dokumentation af kompatibilitet, ikke et løfte om, at en nuværende OpenSSL-udbyder viser identiske navne.

Signeringsnavne skaber ikke signaturer

Et signeringsframework kan binde en digest til en anden algoritmes grænseflade, så eksisterende kald fortsat kompilerer. En ægte offentlig-nøgle-signatur kræver både en nøgle og det signeringstrin, der bruger den, og ingen af dem leveres af et navn i en menu. En RSA-præget digestpost er et navn, en kalder må bruge, ikke bevis for at hver VPN-pakke bar en RSA-signatur.

Det er på dette trin, ældre tekster glider over i folklore. Hvis du skal vide, hvordan pakker blev autentificeret, skal du finde den indstilling, der valgte mekanismen, og læse, hvad den gør i den version, du faktisk kører. Den manualside, der fulgte med den udgivelse, er den eneste beskrivelse, der passer til programmet foran dig. Arkiverede vejledninger beskriver den udgivelse, de blev skrevet til, og den kan være flere navnekonventioner bagud.

Find den indstilling, der forbrugte navnet

I det pakkeautentificeringstilfælde, som OpenVPN 2.6 dokumenterer, vælger auth en digest, der bruges af HMAC, en nøglebaseret beskedautentificeringskonstruktion snarere end en certifikatsignatur. Signeringsalgoritmen for TLS-certifikatet er en separat egenskab ved håndtrykket.

Med et AEAD-dataciffer holder den separate auth-indstilling op med at gælde for datakanalen, mens dens rolle for tls-auth forbliver et selvstændigt spørgsmål. En digestliste kan derfor ikke fortælle, hvilken hash der beskyttede de aktuelle pakker, hvilken TLS-suite der blev forhandlet, eller hvordan peer-certifikatet blev signeret. Kun den effektive konfiguration plus versionen kan svare på det, og kun for den forbindelse, der er foran dig.

Skriv ned, hvad du faktisk har

Skriv OpenVPN-versionen, det linkede kryptobibliotek, de præcise indstillinger i profilen og resultatet af en rigtig forbindelse ned. Det sæt besvarer spørgsmål, som et skærmbillede af en digestmenu ikke kan, og det overlever den næste opgradering, fordi det nævner versioner i stedet for indtryk.

Frem for alt: vælg ikke et gammelt alias, fordi navnet lyder stærkere eller mere specifikt. Vælg den understøttede politik for hele forbindelsen, og behandl de gamle navne som en registrering af, hvordan et bibliotek tidligere præsenterede sig.