Waarom serversleutels en gebruikersreferenties aparte eigenaren nodig hebben

De sleutel die bewijst dat je gateway zichzelf is en de referentie die zegt dat iemand mag deelnemen zijn beide geheimen, en daar houdt de gelijkenis op. De ene identificeert een dienst tegenover elke client; de andere identificeert één gebruiker tegenover die dienst. Ze door elkaar halen bespaart een stap bij het opzetten en kost een middag tijdens een incident, omdat het herstel voor elk niet dezelfde handeling is. De splitsing is saai om op te zetten en gedenkwaardig om over te slaan.

Twee geheimen, twee verschillende eigenaren

De gateway bewaart een persoonlijke sleutel of certificaat waarvan de enige taak is de eigen identiteit tijdens de handdruk te bewijzen. Clients hebben het bijpassende openbare materiaal nodig om die te verifiëren, en ze hebben nooit de persoonlijke helft nodig. Die asymmetrie maakt serverauthenticatie mogelijk zonder elke gebruiker het vermogen te geven de server na te doen.

Gebruikersmateriaal gaat de andere kant op. Een persoonlijke clientsleutel, een clientcertificaat of een wachtwoord toont aan dat precies deze persoon of dit apparaat toegang heeft gekregen. Er wordt verwacht dat het wordt verspreid, tussen apparaten wordt gekopieerd en uiteindelijk wordt ingetrokken.

WireGuard maakt de splitsing duidelijk omdat elke deelnemer een sleutelpaar heeft: de persoonlijke sleutel van de server blijft op de server, en een configuratiebestand dat je een gebruiker geeft bevat diens eigen persoonlijke sleutel plus de openbare sleutel van de server. Een profiel dat de persoonlijke sleutel van de server bevat is geen kortere weg, het is een compromis dat op een bestandsdeling wacht.

Drie vragen die de splitsing bepalen

Vraag wie het geheim moet kunnen lezen, wat een blootstelling een aanvaller zou laten doen, en of de oplossing één intrekking of een hernieuwde opbouw van de dienst is.

Als een gebruiker het kan lezen en het bewijst de identiteit van de gateway, dan is het antwoord op de tweede vraag dat de aanvaller je server tegenover elke client kan nabootsen — de slechtste uitkomst, omdat clients zijn ontworpen om die identiteit te vertrouwen. Als het alleen één gebruiker bewijst, geeft de blootstelling die gebruiker toegang tot één peer, en intrekken is een routinehandeling. Als het een sleutel van een certificaatautoriteit is, is blootstelling erger dan beide, omdat de aanvaller identiteiten kan maken die elk eindpunt vertrouwt.

Die drie antwoorden leveren de opslagregel op: de CA-sleutel woont offline of in een kluis, de gatewaysleutel woont op de gateway, en gebruikerssleutels wonen bij gebruikers. Elke indeling die alle drie voor het gemak in één map zet, heeft een beslissing in een ongeluk veranderd.

Wat een client echt nodig heeft

Een client heeft het openbare certificaat of de openbare peersleutel nodig, het CA-materiaal of de vingerafdruk die hij moet vertrouwen, zijn eigen persoonlijke sleutel en de details van het eindpunt. Die lijst bevat niets dat bij de persoonlijke identiteit van de gateway hoort.

Documentatie is waar dit lekt. Een handleiding die zegt kopieer de servermap en verwijder wat je niet nodig hebt, heeft al het verkeerde model geleerd, omdat het bestand dat na de verwijderstap overblijft zelden door iemand wordt gecontroleerd.

Trek één gebruiker in zonder de gateway aan te raken

Omdat gebruikersidentiteiten apart worden uitgegeven, kunnen ze apart worden teruggetrokken. Een op certificaten gebaseerde uitrol trekt het clientcertificaat in en publiceert een bijgewerkte intrekkingslijst; een WireGuard-uitrol verwijdert de peer-regel uit de serverconfiguratie. Geen van die handelingen verandert de eigen sleutel van de gateway.

Bewaar het uitgifteregister, anders weet je niet welke identiteit je moet terugtrekken. Een spreadsheet is genoeg, mits die de persoon, het apparaat, het serienummer of de openbare sleutel en de datum noemt, en mits iemand hem beheert nadat de persoon die hem heeft gebouwd vertrekt.

De onderstaande opdrachten inspecteren een clientcertificaat en trekken het daarna in via een autoriteit in OpenSSL-stijl, wat de stroom is die easy-rsa inpak:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publiceer de nieuwe lijst waar clients die controleren, anders is de intrekking een notitie in een bestand die niets verandert. Als je gateway clientcertificaten accepteert zonder een intrekkingslijst te raadplegen, zeg dat dan expliciet in plaats van te suggereren dat intrekking werkt.

Houd back-ups net zo gescheiden als de geheimen

Een herbouwarchief bevat terecht de gatewaysleutel en het CA-materiaal, omdat een herstel zonder die twee de dienst niet kan reproduceren. Een clientinstallatiepakket mag dat niet, en de twee mogen niet samen worden opgeslagen. Label elk archief naar wie het mag bewaren, niet naar de datum waarop het is gemaakt. Dat label is wat een vermoeide beheerder om twee uur 's nachts leest.

Dat onderscheid bepaalt ook wie elk mag ophalen. De gateway beheren, gebruikersidentiteiten uitgeven en back-ups lezen zijn drie verschillende bevoegdheden, en iemand die er één nodig heeft, heeft niet automatisch de andere nodig. Schrijf die rechten op en toets ze daarna aan wat je opslag feitelijk toestaat, want mapovererving verleent stilzwijgend meer dan het beleid bedoelt.