DH-lêer of tls-auth-sleutel? Twee OpenVPN-lêers uitmekaar gehou

Twee lêers, twee direktiewe, en die gewoonte om albei te vernoem na die ding wat hulle instel. So beland dh.pem op tls-auth-reël en misluk die kliënt met ’n boodskap oor ’n onverwagte sleutelformaat. Die besluit voor jou is nie watter lêer sterker is nie. Dit is watter rol die ontplooiing werklik nodig het, en drie voorwaardes beslis dit: watter sleuteluitruiling jou TLS-stapel sal onderhandel, of jy hoegenaamd beheerkanaalverifikasie wil hê, en of die materiaal geheim moet bly.

Antwoord dié in volgorde en die lêervraag antwoord homself. Slaan hulle oor en die direktiefname begin uitruilbaar lyk, wat juis die toestand is waaruit die fout kom.

Lees die etiket voor die lêernaam

Die eerste reël van die lêer is meer insiggewend as sy naam, want ’n naam is ’n menslike konvensie en die etiket word deur die gereedskap geproduseer. Diffie-Hellman-parameters dra ’n PEM-etiket van BEGIN DH PARAMETERS. ’n OpenVPN-statiese sleutel is heeltemal ’n ander struktuur, met sy eie kop en heksa-lading.

Hernoeming skakel niks om nie. ’n Parameterlêer met die naam ta.key is steeds parameters, en ’n statiese sleutel met die naam dh.pem is steeds ’n statiese sleutel; die ontleder lees die inhoud en verwerp die wanverhouding. Kontroleer voordat jy die profiel wysig:

head -n 1 dh.pem
head -n 1 ta.key

Drie voorwaardes wat bepaal watter lêer jy nodig het

Voorwaarde een is die uitruiling. ’n Eindigeveld-Diffie-Hellman-handdruk het ’n groep nodig, en die dh-direktief is waar die bediener die parameters daarvoor benoem. ’n Elliptiese-kurwe-handdruk het daardie lêer glad nie nodig nie, want die kurwe is die parameterstel. As jou bediener net ECDHE-suites onderhandel, is ’n DH-lêer dooie gewig eerder as ekstra sterkte.

Voorwaarde twee is beheerkanaalverifikasie, wat ’n aparte funksie met sy eie materiaal is. ’n tls-auth-lêer is ’n gedeelde statiese sleutel wat albei eweknieë hou, gebruik om beheerkanaalpakkette te onderteken sodat ’n onverifieerde eweknie nie eens die handdruk kan voltooi nie. Dit bestaan of jy eindigeveld-DH gebruik of nie, en dit het niks met die groepparameters te doen nie.

Voorwaarde drie is geheimhouding en verspreiding. DH-parameters mag gepubliseer word sonder om die sessie te verswak, want die geheime waardes word per handdruk gegenereer en verlaat nooit die eweknieë nie. ’n Statiese sleutel mag nie gepubliseer word nie: dit is dieselfde grepe aan albei kante, dit roteer nie vanself nie, en enigiemand wat dit het, kan geldige beheerkanaalhandtekeninge produseer. Daardie twee antwoorde wys na heeltemal verskillende hanteringsreëls, en daarom kan een lêer in ’n bewaarplek sit en die ander nie.

Genereer die regte materiaal vir elke rol

Gebruik die gereedskap wat die formaat produseer wat die direktief verwag, eerder as om tussen hulle om te skakel. Vir die gedeelde sleutel op OpenVPN 2.6 noem die getikte vorm van die generator die doel uitdruklik.

openvpn --genkey tls-auth ta.key

Daardie opdrag skep nuwe geheime materiaal; dit herstel of inspekteer nie ’n bestaande sleutel nie, en as jy dit weer laat loop, kry jy ’n ander sleutel wat die ander eweknieë nie het nie. Kopieer die resulterende lêer na die eweknieë wat dit nodig het deur ’n kanaal wat jy vir enige gedeelde geheim sou gebruik, en hou die rigtingkonvensie konsekwent: met tls-auth gebruik een kant key-direction 0 en die ander key-direction 1.

DH-parameters, wanneer jy hulle nodig het, kom uit parametergenerering eerder as uit ’n sleutelgenerator, en hul herkoms maak saak selfs al is die uitset openbaar. ’n Groep wat uit ’n onbekende bron gehaal is, word nie betroubaar gemaak deur openbaar te wees nie; dit moet steeds ’n groep wees waaroor jou eweknieë saamstem en een wat nie deur sy grootte of konstruksie verswak word nie.

Wat dh none doen en nie doen nie

dh none is ’n regte direktief met ’n eng betekenis: geen eindigeveld-parameterlêer sal gelaai word nie, want die handdruk gebruik elliptiese-kurwe-Diffie-Hellman. Dit is nie ’n kortvorm vir “slaan die DH-stap oor” in die sin dat dit iets verswak nie, en dit sê beslis nie vir OpenVPN om een of ander ander lêer as plaasvervanger te aanvaar nie.

Twee foute volg uit die verkeerde lees daarvan. Die eerste is om aan te neem dat dh none die behoefte aan tls-auth verwyder, terwyl die twee verskillende dinge beheer. Die tweede is om ’n verouderde dh-reël langs ’n kurwe-only-konfigurasie te hou en dan te wonder watter lêer die bediener eintlik gebruik; as die direktief daar is, word die lêer gelees, en ’n stukkende pad daar laat die opstart misluk om ’n rede wat nie met die uitruiling wat onderhandel sal word, verband hou nie.

As die verkeerde lêer al ontplooi is

Herstel die bedoelde geheim van die profieleienaar en laat sertifikaatverifikasie alleen terwyl jy dit doen. Die mislukking is ’n formaatwanverhouding, nie ’n vertrouensmislukking nie, en om verifikasie af te skakel om verby die fout te kom, vervang ’n opstartprobleem met ’n stille een.

Skei dan die twee voorvalle wat mense geneig is om saam te voeg. Om ’n DH-parameterlêer te publiseer is naastenby onskadelik, want die parameters was by ontwerp openbaar. Om die tls-auth-sleutel bloot te lê is ’n ander gebeurtenis: die sleutel verifieer beheerkanaalpakkette vir elke eweknie wat dit hou, so vervanging moet oor die ontplooiing gekoördineer word eerder as op een gasheer toegepas.

Vyf minute se kontrole beslis in watter geval jy is: lees die eerste reël van elke lêer, bevestig die direktief wat daarna verwys, en bevestig dat die lêer se verspreiding pas by wat die materiaal vereis. Dit is ’n kleiner werk as om ’n werkende PKI te hergenereer, en dit is die een waarheen die drie voorwaardes die hele tyd gewys het.