OpenVPN tls-crypt-v2: wat de clientsleutel en de ingepakte blob doen

Een tls-crypt-v2-profiel in een ticket plakken lijkt onschuldig tot je telt wat het bestand bevat. De regelkanaalsleutel van de client staat naast een versleutelde kopie van diezelfde sleutel, en een derde object, de inpakselutel, verlaat nooit de server die accepteert. Die drie beantwoorden verschillende vragen over bewaring, delen en uitfasering. Ze scheiden beslecht de meeste beleidsdiscussies voordat ze beginnen.

Wat het profiel werkelijk bevat

De clienthelft van tls-crypt-v2 is een sleutel plus een ingepakte kopie ervan. De client gebruikt de gewone sleutel voor bescherming van het regelkanaal en geeft de ingepakte kopie tijdens de installatie aan de server, zodat de server dezelfde sleutel terugkrijgt zonder per client een kopie in platte tekst op te slaan. De inpakselutel maakt dat herstel mogelijk en hoort alleen aan de accepterende kant. Alles hieronder volgt uit waar die drie objecten leven.

Lees de tabel naar bewaring, niet naar naam, en de gevolgen vallen vanzelf uiteen. Het verliezen van de inpakselutel is de dure gebeurtenis, omdat niets in een profiel die kan reconstrueren en het eerlijke herstel is de groep opnieuw uitgeven. Een uitgelekt profiel is goedkoper maar veel gewoner, omdat mensen profielen in tickets plakken in de overtuiging dat de ingepakte kopie het bestand veilig maakt om te delen. De twee fouten vragen verschillende reacties, en daarom worden de objecten apart gehouden.

Waarom de ingepakte kopie niet het hele verhaal is

Een profiel draagt het bruikbare clientmateriaal samen met zijn ingepakte tegenhanger, dus de kopie voor de server beschermen zegt niets over het bestand beschermen. De blob is veilig om te verzenden en onveilig om te publiceren. De metadata erin zijn zichtbaar voor iedereen die de blob ontvangt, inclusief iedereen die later het ticket leest waarin hij is geplakt.

Behandel een profiel als een inloggegeven, niet als een configuratievoorbeeld. Een uitgelekt bestand geeft de houder een werkende clientidentiteit tot de server die identiteit niet meer accepteert, en de inpakking doet niets aan dat venster. Geef één profiel per client uit zodat intrekken een beslissing over één bestand blijft, en maak een back-up van de inpakselutel los van de serverconfiguratie die hij mogelijk maakt. Geen van beide gewoonten repareert een gecompromitteerd profiel, maar beide bepalen hoe snel het volgende wordt ingedamd.

Waar de verificatiehaak in de handshake zit

De verificatiehaak draait voordat de TLS-stack wordt blootgesteld, en zijn taak is de metadata te inspecteren die in de ingepakte blob wordt meegedragen. Hij ontvangt die metadata plus een kleine, gedocumenteerde omgeving, en heeft minder om mee te werken dan een authenticatiehaak. Aannemen dat hij gebruikersnamen, sessiestatus of pluginvariabelen ziet, is de gebruikelijke manier waarop deze haak slecht wordt geschreven. Lees de eigen handleidingsectie van de haak in plaats van verwachtingen van een andere haak te lenen.

Zijn exitstatus is de beslissing: een resultaat dat niet nul is weigert de client en een nulresultaat laat de handshake doorgaan. Het beleid moet dus zeggen wat er gebeurt als metadata ontbreken, niet te parsen zijn of onverwacht zijn. Schrijf eerst het weigeringspad, en bepaal daarna welke waarden aanvaardbaar zijn.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Die twee regels zijn het beleidsoppervlak op de server: de ene noemt de inpakselutel, de andere noemt het programma dat elke client beoordeelt. Alles interessants zit in het script, dat versiebeheer en dezelfde beoordeling verdient als elke andere toegangsregel.

Account, certificaat en regelsleutel gaan apart uit dienst

Vroege acceptatie van het regelkanaal is geen authenticatie, omdat het gebeurt vóór de TLS-identiteitscontrole en vóór enige accountautorisatie. Een account uitschakelen, een certificaat intrekken en een clientregelsleutel weigeren zijn drie acties met drie mechanismen. Een uitrol die er maar één doet, heeft een gat in plaats van een beleid. Stem de drie bewust op elkaar af en leg vast welke stap welke bevoegdheid uitoefent.

Timing is het tweede onderscheid. Een gewijzigde acceptatielijst geldt voor nieuwe handshakes, terwijl al opgezette sessies blijven draaien tot iets ze beëindigt. Het aantal regels op de nieuwe lijst als bewijs tellen dat oude sessies zijn afgelopen, is hoe een verwijderde client urenlang verbonden blijft.

Niet-afgestemde bevoegdheden laten twee gaten achter die in de praktijk makkelijk te vinden zijn. Een account kan uitgeschakeld zijn terwijl zijn regelsleutel nog een handshake opent, en een certificaat kan ingetrokken zijn terwijl het metadatabeleid dezelfde client nog toelaat. Beide zijn dezelfde fout op verschillende plaatsen, omdat een operator één lijst als de hele bevoegdheid behandelde. Leg de drie lijsten bij het verwijderen naast elkaar en de fout wordt zichtbaar.

Een profiel uitgeven en intrekken

Uitgeven is de makkelijke helft: maak de clientsleutel aan de accepterende kant, geef het profiel aan precies één eigenaar, houd het inpakmateriaal beperkt en draai hetzelfde verificatieprogramma op elke accepterende server. Goedkope toelating is een eigenschap van de hele groep, niet van de nieuwste host. Een tweede server met een ouder of losser script wordt stilzwijgend het zwakste pad in de uitrol.

Intrekken vereist de drie stappen in een bewuste volgorde. Weiger de client in de verificatiehaak zodat nieuwe handshakes mislukken, trek zijn certificaat in als er een PKI wordt gebruikt, en schakel het account uit zodat latere autorisatie niets meer te autoriseren heeft. Beëindig daarna de sessies die de oude acceptatie toestond, want die merken geen van de drie. Oefen de volgorde op een client die je je kunt permitteren te breken.

Metadata in een profiel zijn een invoer voor dat beleid, niet het bewijs dat toegangsbeheer al bestaat. Het ontwerpdokument van OpenVPN 2.6 beschrijft de objecten en de grens die ze trekken, terwijl de handhaving bij de operator blijft.