tls-auth teenoor tls-crypt: wat elkeen in OpenVPN beskerm

Beide opsies neem 'n gedeelde sleutellêer en albei maak dit moeiliker om handskudverkeer te vervals, daarom word hulle as twee name vir dieselfde funksie behandel. Hulle is nie. Die een onderteken beheerpakketjies, die ander versleutel hulle ook, en nie een het iets te doen met die syfer wat jou vrag beskerm nie.

Daardie onderskeid maak saak wanneer 'n profiel nie kan koppel nie, wanneer 'n sekuriteitsoudit vra wat die sleutel beskerm, en wanneer iemand aanneem die ekstra lêer maak die tonnel op een of ander ongedefinieerde manier versleutel.

Wat die gedeelde sleutel werklik beskerm

Die sleutel wat hierdie opsies gebruik, hoort by die beheerkanaal: die uitruiling wat parameters beding, identiteite bewys en die datasleutels aflei. Dit is 'n vooraf gedeelde geheim wat albei eindpunte moet hê voordat die handskud kan voortgaan. Omdat dit voor identiteitskontroles sit, stop 'n verkeerde sleutel die gesprek vroeër as wat 'n verkeerde wagwoord sou doen. Daardie volgorde verduidelik waarom die foutmodus so stil is.

tls-auth gebruik daardie geheim om 'n HMAC oor beheerpakketjies te bereken. 'n Pakket sonder 'n geldige handtekening word weggegooi voordat dit die duurder TLS-verwerking bereik, en daarom word die opsie dikwels as 'n eerste filter beskryf eerder as 'n vervanging vir TLS.

tls-crypt gaan verder deur die beskermde beheerverkeer te versleutel sowel as te verifieer. Sertifikaatinhoud, bedinge syfername en ander handskudbesonderhede is nie meer op die draad sigbaar nie, en 'n waarnemer sonder die sleutel kan selfs nie sien watter TLS-weergawe probeer word nie. Vir 'n ontplooiing wat bekommerd is oor die openbaarmaking van sy VPN-vingerafdruk, is daardie eienskap die hoofrede om dit te kies. Dit is steeds 'n groepsgeheim, nie 'n geloofsbrief vir een gebruiker nie.

Nie een van die meganismes reik identiteite uit nie. Die gedeelde sleutel is 'n groepsgeheim, en elkeen wat dit het, kan daardie laag van die kontrole bevredig.

Waar die twee opsies verskil

Die waarneembare verskil is wat 'n waarnemer sien. Met tls-auth is die handskud sigbaar maar onverifieerbaar sonder die sleutel. Met tls-crypt is die handskud ondeursigtig vir elkeen wat nie die sleutel het nie.

Die opstelling verskil ook. tls-auth word met 'n rigtingwaarde gebruik, dus een kant gebruik die een helfte van die sleutelmateriaal en die ander kant die ander helfte. tls-crypt gebruik 'n enkele sleutel in beide rigtings, dus die rigtingaanwysing is nie deel van sy reëling nie.

Die twee opsies is in moderne uitgawes onderling uitsluitend. 'n Profiel moet een van hulle dra, nie albei nie, en die bediener en kliënt moet ooreenkom watter een, met ooreenstemmende sleutelmateriaal. Om 'n ou aanwysing langs 'n nuwe een te hou, is algemene migrasiereste. Verwyder die onaktiewe een sodat die volgende leser weet watter laag werklik geld.

'n Nuwer variant, tls-crypt-v2, koppel elke kliënt aan sy eie verpakte sleutel sodat die herroeping van een kliënt nie die heruitreiking van die groepsleutel vereis nie. Dit is die moeite werd om te weet, maar dit is 'n ander opsie en nie 'n sinoniem vir een van die twee hier nie.

Waarom 'n wanpassing lyk of niks gebeur

Wanneer die gedeelde materiaal nie ooreenstem nie, gooi die eweknie die pakketjies weg sonder om die afsender te sê waarom. Daar is geen verifikasiefout om te lees nie, want die pakket het nooit die laag bereik wat een sou produseer nie.

Die kliënt probeer weer, die bediener sê niks, en die simptoom lyk soos 'n netwerkprobleem. Mense herbegin dan die diens, tik die rekeningwagwoord weer in, of verwyder die beskermingsaanwysing om dit te toets, wat die ontplooiing verander eerder as om dit te diagnoseer.

Lees die bedienerlog vir die eerste klag op pakketvlak eerder as die laaste herprobeeringsreël. Bevestig dat albei kante dieselfde opsie met identiese sleutelmateriaal dra, en dat die sleutellêer nie net aan een kant hergenereer is nie.

Om die aanwysing te verwyder is nie 'n veilige herstel nie. Dit skakel 'n beskermingslaag vir elke kliënt af, en 'n werkende tonnel daarna bewys net dat die laag die wanpassing was.

Wat steeds afsonderlik opgestel moet word

Hierdie opsies verifieer nie wie die eweknie is nie. Sertifikaatvalidering, die vertrouensanker en die verwagte bedienernaam bly afsonderlike vereistes, en nie een van hulle word opsioneel omdat 'n gedeelde sleutel daar is nie.

Hulle kies ook nie die data-syfer nie. Dit is 'n afsonderlike bedinging wat deur die datakanaal-instellings aan albei kante beheer word, en 'n tonnel wat deur tls-crypt beskerm word, kan steeds 'n syfer gebruik wat jy nie bedoel het nie.

Laastens moet die gedeelde sleutel self hanteer word. Behandel dit as 'n geheim, versprei dit deur 'n goedgekeurde kanaal, en vervang dit wanneer iemand wat dit gehad het, vertrek. Omdat dit gedeel word, is die blootstelling daarvan die blootstelling van elke eindpunt wat dit gebruik.