Erfenis-vertermlyste lees soos 'n transkripsie van kriptografiese besluite, en dit is nie een nie. Name soos SHA1, DSA-SHA1-old of RSA-SHA1-2 staan langs mekaar in ou OpenSSL-bouers omdat die biblioteek verskeie toegangspunte rondom verwante hash-masjinerie geregistreer het. 'n RSA- of DSA-etiket in daardie lys sê niks oor wat OpenVPN aan 'n pakkie gedoen het nie. Wat jy lees, is die biblioteek se inventaris, nie die rekord van 'n sessie nie.

Drie dinge moet geskei word voordat enige gevolgtrekking sin maak: die geregistreerde naam, die verteringsberekening daaronder en die bewerking wat dit gebruik.

Registrasie is 'n koppelvlak, nie 'n sterktegradering nie

In OpenSSL 1.0.2 bind die verteringsregistrasietabel name, aliasse en implementerings saam in een lêer. Die ou DSS1-beskrywer is die duidelikste geval: dit rapporteer SHA-1 se uitsetlengte en roep SHA-1 se finaliseringsroetine aan terwyl dit 'n naam dra wat 'n heeltemal ander algoritme suggereer. Ekstra letters in 'n registrasie impliseer dus geen ander hash, geen langer uitset en geen nuwe sekuriteitsvlak nie.

Dieselfde bron behou aliasverhoudings vir ouer oproepers, wat verduidelik waarom 'n lys oorvol lyk. Dit is dokumentasie van versoenbaarheid, nie 'n belofte dat 'n huidige OpenSSL-verskaffer identiese name blootlê nie.

Ondertekenname skep nie handtekeninge nie

'n Ondertekeningsraamwerk kan 'n vertering aan 'n ander algoritme se koppelvlak bind sodat bestaande oproepers bly kompileer. 'n Ware publiekesleutel-handtekening benodig beide 'n sleutel en die ondertekeningsstap wat dit gebruik, en nie een word deur 'n naam in 'n kieslys verskaf nie. 'n RSA-gegeurde verteringsinset is 'n naam wat 'n oproeper mag gebruik, nie bewyse dat elke VPN-pakkie 'n RSA-handtekening gedra het nie.

Dit is die stap waar ouer geskrifte in volksgeloof verval. As jy moet weet hoe pakkies geverifieer is, vind die opsie wat die meganisme gekies het en lees wat dit doen in die weergawe wat jy werklik hardloop. Die handleidingblad wat saam met daardie uitgawe gestuur is, is die enigste beskrywing wat by die program voor jou pas. Geargiveerde gidse beskryf die uitgawe waarteen hulle geskryf is, wat verskeie naamkonvensies agter kan wees.

Vind die opsie wat die naam verbruik het

Vir die pakkie-verifikasiegeval wat OpenVPN 2.6 dokumenteer, kies auth 'n vertering wat deur HMAC gebruik word, 'n gekodeerde boodskapverifikasiekonstruksie eerder as 'n sertifikaathandtekening. Die ondertekeningsalgoritme van die TLS-sertifikaat is 'n aparte eienskap van die handdruk.

Met 'n AEAD-datakodeerder hou die aparte auth-instelling op om op die datakanaal van toepassing te wees, terwyl sy rol vir tls-auth 'n afsonderlike vraag bly. 'n Verteringlys kan dus nie sê watter hash die huidige pakkies beskerm het nie, watter TLS-suite onderhandel is nie, of hoe die eweknie-sertifikaat onderteken is nie. Slegs die effektiewe konfigurasie plus die weergawe kan dit antwoord, en net vir die verbinding voor jou.

Teken op wat jy werklik het

Skryf die OpenVPN-weergawe neer, die gekoppelde kriptobiblioteek, die presiese opsies in die profiel en die resultaat van 'n werklike verbinding. Daardie stel beantwoord vrae wat 'n skermkiekie van 'n vertermlys nie kan nie, en dit oorleef die volgende opgradering omdat dit weergawes noem eerder as indrukke.

Boonop, moenie 'n erfenis-alias kies omdat sy naam sterker of spesifiker klink nie. Kies die ondersteunde beleid vir die hele verbinding, en behandel die ou name as 'n rekord van hoe 'n biblioteek homself vroeër aangebied het.

Verwante artikels