SHA1-digestnamen in OpenSSL: wat een oude lijst betekent

Oude digestlijsten lezen als een transcript van cryptografische beslissingen, en dat zijn ze niet. Namen als SHA1, DSA-SHA1-old of RSA-SHA1-2 staan naast elkaar in oude OpenSSL-builds omdat de bibliotheek meerdere toegangspunten rond verwante hash-machinerie registreerde. Een RSA- of DSA-label in die lijst OpenVPN zegt niets over wat OpenVPN met een pakket deed. Wat u leest, is de inventaris van de bibliotheek, niet het verslag van een sessie.

Drie dingen moeten worden gescheiden voordat enige conclusie zin heeft: de geregistreerde naam, de digest-berekening eronder en de bewerking die hem verbruikt.

Een registratie is een interface, geen sterktebeoordeling

In OpenSSL 1.0.2 verbindt de digestregistratietabel namen, aliassen en implementaties in één bestand. De oude DSS1-beschrijving is het duidelijkste geval: die meldt de uitvoerlengte van SHA-1 en roept de finalisatieroutine van SHA-1 aan terwijl hij een naam draagt die een heel ander algoritme suggereert. Extra letters in een registratie impliceren dus geen andere hash, geen langere uitvoer en geen nieuw beveiligingsniveau.

Dezelfde bron bewaart aliasrelaties voor oudere aanroepers, wat verklaart waarom een lijst vol lijkt. Dat is documentatie van compatibiliteit, geen belofte dat een huidige OpenSSL-provider identieke namen toont.

Ondertekeningsnamen maken geen handtekeningen

Een ondertekeningsraamwerk kan een digest aan de interface van een ander algoritme binden zodat bestaande aanroepers blijven compileren. Een echte openbare-sleutelhandtekening vereist zowel een sleutel als de ondertekeningsstap die hem gebruikt, en geen van beide wordt geleverd door een naam in een menu. Een RSA-getinte digestvermelding is een naam die een aanroeper mag gebruiken, geen bewijs dat elk VPN-pakket een RSA-handtekening droeg.

Op deze stap glijden oudere teksten af naar folklore. Als u moet weten hoe pakketten werden geauthenticeerd, zoek dan de optie die het mechanisme koos en lees wat die doet in de versie die u werkelijk draait. De handleidingspagina die met die release werd meegeleverd, is de enige beschrijving die bij het programma voor u past. Gearchiveerde gidsen beschrijven de release waarvoor ze zijn geschreven, en die kan verschillende naamgevingsconventies achterlopen.

Vind de optie die de naam verbruikte

In het geval van pakketauthenticatie dat OpenVPN 2.6 documenteert, selecteert auth een digest die door HMAC wordt gebruikt, een berichtauthenticatie met sleutel in plaats van een certificaathandtekening. Het ondertekeningsalgoritme van het TLS-certificaat is een aparte eigenschap van de handshake.

Bij een AEAD-gegevensversleuteling geldt de aparte instelling auth niet meer voor het gegevenskanaal, terwijl de rol ervan voor tls-auth een aparte vraag blijft. Een digestlijst kan u daarom niet vertellen welke hash de huidige pakketten beschermde, welke TLS-suite werd onderhandeld of hoe het certificaat van de tegenpartij werd ondertekend. Alleen de effectieve configuratie plus de versie kan dat beantwoorden, en alleen voor de verbinding voor u.

Noteer wat u werkelijk hebt

Noteer de OpenVPN-versie, de gekoppelde cryptobibliotheek, de exacte opties in het profiel en het resultaat van een echte verbinding. Die set beantwoordt vragen die een schermafbeelding van een digestmenu niet kan, en overleeft de volgende upgrade omdat hij versies noemt in plaats van indrukken.

Vooral: kies geen oud alias omdat de naam sterker of specifieker klinkt. Kies het ondersteunde beleid voor de hele verbinding, en behandel de oude namen als een verslag van hoe een bibliotheek zich vroeger presenteerde.