tls-auth versus tls-crypt: wat elk in OpenVPN beschermt

Beide opties gebruiken een gedeeld sleutelbestand en beide maken handshakeverkeer moeilijker te vervalsen, daarom worden ze behandeld als twee namen voor dezelfde functie. Dat zijn ze niet. De ene ondertekent controlepakketten, de andere versleutelt ze ook, en geen van beide heeft iets te maken met het cijfer dat uw payload beschermt.

Dat onderscheid doet ertoe wanneer een profiel geen verbinding maakt, wanneer een beveiligingsaudit vraagt wat de sleutel beschermt, en wanneer iemand aanneemt dat het extra bestand de tunnel op een of andere ongedefinieerde manier versleuteld maakt.

Wat de gedeelde sleutel werkelijk beschermt

De sleutel die deze opties gebruiken, hoort bij het controlekanaal: de uitwisseling die parameters onderhandelt, identiteiten bewijst en de datasleutels afleidt. Het is een vooraf gedeeld geheim dat beide uiteinden moeten hebben voordat de handshake verder kan. Omdat het vóór de identiteitscontroles staat, stopt een verkeerde sleutel het gesprek eerder dan een verkeerd wachtwoord zou doen. Die volgorde verklaart waarom de faalmodus zo stil is.

tls-auth gebruikt dat geheim om een HMAC over controlepakketten te berekenen. Een pakket zonder geldige handtekening wordt weggegooid voordat het de duurdere TLS-verwerking bereikt, daarom wordt de optie vaak beschreven als een eerste filter en niet als een vervanging van TLS.

tls-crypt gaat verder door het beschermde controleverkeer te versleutelen naast het te authenticeren. Certificaatinhoud, onderhandelde cijfernamen en andere handshakegegevens zijn niet langer zichtbaar op het netwerk, en een waarnemer zonder de sleutel kan zelfs niet zien welke TLS-versie wordt geprobeerd. Voor een uitrol die vreest zijn VPN-vingerafdruk te verraden, is die eigenschap de belangrijkste reden om het te kiezen. Het blijft een groepsgeheim, geen inloggegevens per gebruiker.

Geen van beide mechanismen geeft identiteiten uit. De gedeelde sleutel is een groepsgeheim, en iedereen die hem heeft, kan die laag van de controle vervullen.

Waar de twee opties verschillen

Het waarneembare verschil is wat een waarnemer ziet. Met tls-auth is de handshake zichtbaar maar zonder de sleutel niet verifieerbaar. Met tls-crypt is de handshake ondoorzichtig voor iedereen die de sleutel niet heeft.

De configuratie verschilt ook. tls-auth wordt met een richtingswaarde gebruikt, dus de ene kant gebruikt de ene helft van het sleutelmateriaal en de andere kant de andere helft. tls-crypt gebruikt één sleutel in beide richtingen, dus de richtingsaanwijzing hoort niet bij de opzet.

In moderne releases sluiten de twee opties elkaar uit. Een profiel hoort er één te bevatten, niet beide, en de server en client moeten het eens worden welke, met overeenkomend sleutelmateriaal. Een oude aanwijzing naast een nieuwe houden is een veelvoorkomend migratierestant. Verwijder de inactieve zodat de volgende lezer weet welke laag werkelijk geldt.

Een nieuwere variant, tls-crypt-v2, koppelt elke client aan zijn eigen ingepakte sleutel, zodat het intrekken van één client niet vereist dat de groepssleutel opnieuw wordt uitgegeven. Het is de moeite waard om te kennen, maar het is een andere optie en geen synoniem voor een van de twee hier.

Waarom een mismatch lijkt alsof er niets gebeurt

Wanneer het gedeelde materiaal niet overeenkomt, gooit de tegenpartij de pakketten weg zonder de afzender te vertellen waarom. Er is geen authenticatiefout om te lezen, omdat het pakket nooit de laag bereikte die er een zou produceren.

De client probeert opnieuw, de server zegt niets, en het symptoom lijkt op een netwerkprobleem. Dan herstarten mensen de dienst, typen het accountwachtwoord opnieuw in of verwijderen de beschermingsaanwijzing om die te «testen», wat de uitrol verandert in plaats van die te diagnosticeren.

Lees in het serverlog de eerste klacht op pakketniveau in plaats van de laatste herhalingsregel. Bevestig dat beide kanten dezelfde optie met identiek sleutelmateriaal hebben en dat het sleutelbestand niet alleen aan één kant opnieuw is gegenereerd.

De aanwijzing verwijderen is geen veilige reparatie. Het schakelt een beschermingslaag uit voor elke client, en een tunnel die daarna werkt bewijst alleen dat die laag de mismatch was.

Wat nog apart moet worden geconfigureerd

Deze opties verifiëren niet wie de tegenpartij is. Certificaatvalidatie, het vertrouwensanker en de verwachte servernaam blijven afzonderlijke vereisten, en geen ervan wordt optioneel omdat er een gedeelde sleutel is.

Ze kiezen ook niet het datumcijfer. Dat is een aparte onderhandeling die door de instellingen van het datakanaal aan beide kanten wordt gestuurd, en een tunnel die met tls-crypt is beschermd kan nog steeds een cijfer gebruiken dat u niet bedoelde.

Ten slotte moet de gedeelde sleutel zelf worden behandeld. Behandel hem als een geheim, verdeel hem via een goedgekeurd kanaal en vervang hem wanneer iemand die hem had vertrekt. Omdat hij gedeeld is, is zijn blootstelling de blootstelling van elk uiteinde dat hem gebruikt.