SHA1-digestnammen yn OpenSSL: wat in âlde list betsjut

Alde digestlisten lêze as in transkripsje fan kryptografyske besluten, en dat binne se net. Nammen lykas SHA1, DSA-SHA1-old of RSA-SHA1-2 steane njonken elkoar yn âlde OpenSSL-builts omdat de bibleteek ferskate tagongspunten registrearre hat om besibbe hash-masjinerie hinne. In RSA- of DSA-label yn dy list seit neat oer wat OpenVPN mei in pakket die. Wat jo lêze, is de ynventaris fan de bibleteek, net it ferslach fan in sesje.

Trije dingen moatte losmakke wurde foardat hokker konklúzje dan ek sin hat: de registrearre namme, de digestberekkening dêrûnder en de operaasje dy't him ferbrûkt.

In registraasje is in ynterface, gjin krêftsinprinting

Yn OpenSSL 1.0.2 ferbynt de digestregistraasjetabel nammen, aliassen en ymplemintaasjes yn ien bestân. De âlde DSS1-beskriuwer is it dúdlikste gefal: hy meldt de útfiertelangte fan SHA-1 en ropt de finalisaasjerûtine fan SHA-1 op, wylst er in namme draacht dy't in hiel oar algoritme suggerearret. Ekstra letters yn in registraasje betsjutte dus gjin oare hash, gjin langere útfier en gjin nij befeiligingsnivo.

Deselde boarne bewarret aliasrelaasjes foar âldere oanroppen, wat ferklearret wêrom't in list fol liket. It is dokumintaasje fan kompatibiliteit, gjin tasizzing dat in hjoeddeistige OpenSSL-oanbieder identike nammen toant.

Underskriftnammen meitsje gjin ûnderskriften

In ûnderskriftramt kin in digest oan 'e ynterface fan in oar algoritme bine, sadat besteande oanroppen kompilearje bliuwe. In echt iepenbiere-kaai-ûnderskrift hat sawol in kaai as de ûnderskriftstap dy't him brûkt nedich, en gjin fan beide wurdt levere troch in namme yn in menu. In RSA-fleurend digest-ynfier is in namme dy't in oanroppen brûke mei, gjin bewiis dat elk VPN-pakket in RSA-ûnderskrift droech.

It is by dizze stap dat âldere teksten yn folklore glûpe. As jo witte moatte hoe't pakketten autentisearre waarden, sykje dan de opsje dy't it meganisme keas en lês wat dy docht yn de ferzje dy't jo echt draaie. De hânliedingside dy't mei dy útjefte kaam, is de iennige beskriuwing dy't by it programma foar jo past. Argivearre gidsen beskriuwe de útjefte dêr't se foar skreaun binne, en dy kin ferskate namme-konvinsjes efter rinne.

Fyn de opsje dy't de namme ferbrûkte

Yn it gefal fan pakketautentikaasje dat OpenVPN 2.6 dokumintearret, kiest auth in digest dy't HMAC brûkt, in mei kaai befeilige berjocht-autentikaasjekonstruksje ynstee fan in sertifikaatûnderskrift. It ûnderskriftalgoritme fan it TLS-sertifikaat is in apart eigenskip fan 'e hânskud.

Mei in AEAD-gegevenssyferset hâldt de aparte ynstelling auth op fan tapassing te wêzen op it gegevenskanaal, wylst syn rol foar tls-auth in aparte fraach bliuwt. In digestlist kin jo dêrom net fertelle hokker hash de hjoeddeistige pakketten beskoattelje, hokker TLS-set ûnderhannele waard of hoe't it sertifikaat fan 'e oare partij ûndertekene waard. Allinnich de effektive konfiguraasje plus de ferzje kinne dat beantwurdzje, en allinnich foar de ferbining foar jo.

Skriuw op wat jo echt hawwe

Skriuw de OpenVPN-ferzje op, de keppele kryptobibleteek, de krekte opsjes yn it profyl en it resultaat fan in echte ferbining. Dat set beantwurdet fragen dy't in skermôfdruk fan in digestmenu net kin, en it oerlibbet de folgjende upgrade omdat it ferzjes neamt ynstee fan yndrukken.

Boppedat, kies gjin âld alias om't syn namme sterker of spesifiker klinkt. Kies it stipe belied foar de hiele ferbining, en behannelje de âlde nammen as in ferslach fan hoe't in bibleteek him earder presintearre.