SHA1-digestnavn i OpenSSL: hva en gammel liste betyr

Gamle digestlister leses som en transkripsjon av kryptografiske beslutninger, og det er de ikke. Navn som SHA1, DSA-SHA1-old eller RSA-SHA1-2 står ved siden av hverandre i gamle OpenSSL-bygg fordi biblioteket registrerte flere inngangspunkter rundt beslektet hash-maskineri. En RSA- eller DSA-etikett på den listen OpenVPN sier ingenting om hva OpenVPN gjorde med en pakke. Det du leser, er bibliotekets inventar, ikke opptaket av en økt.

Tre ting må skilles før noen konklusjon gir mening: det registrerte navnet, digestberegningen under det og operasjonen som forbruker det.

En registrering er et grensesnitt, ikke en styrkerangering

I OpenSSL 1.0.2 binder digestregistreringstabellen navn, aliaser og implementasjoner sammen i én fil. Den gamle DSS1-beskrivelsen er det tydeligste tilfellet: den oppgir utgangslengden til SHA-1 og kaller avslutningsrutinen til SHA-1 mens den bærer et navn som antyder en helt annen algoritme. Ekstra bokstaver i en registrering betyr derfor ingen annen hash, ingen lengre utgang og ingen ny sikkerhetsgrad.

Den samme kilden bevarer aliasforhold for eldre kall, noe som forklarer hvorfor en liste ser overfylt ut. Det er dokumentasjon av kompatibilitet, ikke et løfte om at en nåværende OpenSSL-leverandør viser identiske navn.

Signeringsnavn skaper ikke signaturer

Et signeringsrammeverk kan binde en digest til et annet algoritmegrensesnitt slik at eksisterende kall fortsatt kompilerer. En ekte offentlig-nøkkel-signatur trenger både en nøkkel og signeringstrinnet som bruker den, og ingen av dem leveres av et navn i en meny. En RSA-farget digestoppføring er et navn en kaller kan bruke, ikke bevis for at hver VPN-pakke bar en RSA-signatur.

Det er på dette trinnet eldre tekster glir over i folklore. Hvis du trenger å vite hvordan pakker ble autentisert, finn alternativet som valgte mekanismen, og les hva det gjør i versjonen du faktisk kjører. Manuellsiden som fulgte med den utgivelsen, er den eneste beskrivelsen som passer til programmet foran deg. Arkiverte veiledninger beskriver utgivelsen de ble skrevet for, og den kan ligge flere navnekonvensjoner bak.

Finn alternativet som forbrukte navnet

I pakkeautentiseringstilfellet som OpenVPN 2.6 dokumenterer, velger auth en digest som HMAC bruker, en nøkkelbasert meldingsautentiseringskonstruksjon snarere enn en sertifikatsignatur. Signeringsalgoritmen til TLS-sertifikatet er en separat egenskap ved håndtrykket.

Med en AEAD-datachiffer slutter den separate auth-innstillingen å gjelde for datakanalen, mens rollen dens for tls-auth forblir et eget spørsmål. En digestliste kan derfor ikke fortelle deg hvilken hash som beskyttet de aktuelle pakkene, hvilken TLS-suite som ble forhandlet, eller hvordan partnerns sertifikat ble signert. Bare den effektive konfigurasjonen pluss versjonen kan svare på det, og bare for tilkoblingen foran deg.

Skriv ned hva du faktisk har

Skriv ned OpenVPN-versjonen, det koblede kryptobiblioteket, de nøyaktige alternativene i profilen og resultatet av en ekte tilkobling. Det settet svarer på spørsmål som et skjermbilde av en digestmeny ikke kan, og det overlever neste oppgradering fordi det navngir versjoner i stedet for inntrykk.

Framfor alt, ikke velg et gammelt alias fordi navnet høres sterkere eller mer spesifikt ut. Velg den støttede policyen for hele tilkoblingen, og behandle de gamle navnene som et opptak av hvordan et bibliotek tidligere presenterte seg.