OpenVPN-besturingspakketten traceren: tls-auth vóór TLS

Een tls-auth-fout wordt meestal gemeld als een handshake-probleem, en dat is het nooit geweest. De HMAC wordt op het besturingspakket gecontroleerd voordat enige TLS-verwerking plaatsvindt, dus een verkeerde sleutel of richting levert een fout op die op een certificaatprobleem lijkt en twee lagen eerder wordt beslist. De envelop als een eigen object behandelen maakt de diagnose kort: lees de velden, bevestig dat de controle vroeg afgaat en vergelijk daarna de drie dingen waarover beide kanten het eens moeten zijn.

Lees de envelop in de volgorde waarin hij wordt opgebouwd

Een besturingspakket draagt een sessie-identificatie, de optionele tls-auth-HMAC, herhalings- en bevestigingsinformatie en een betrouwbare berichtidentificatie, en daarna volgt de payload van het berichttype. Als het bericht een handshake-bericht is, is de payload toevallig TLS-cijfertekst. Dat is de hele relatie: TLS-materiaal reist in een bericht dat de envelop al beschermt. De OpenVPN-referentie voor het netwerkprotocol somt de velden van het besturingskanaal in die volgorde op.

De betrouwbaarheidslaag wordt gemakkelijk voor cryptografie aangezien. Bevestigingen, herverzending en de berichtidentificatie bestaan zodat besturingsberichten één keer en in de juiste volgorde aankomen over een onbetrouwbaar transport. Ze zijn geen authenticatie, en een correcte berichtidentificatie bewijst niets over wie het pakket heeft verzonden.

Houd deze groepering conceptueel. Het is geen byte-volgordediagram en het is niet genoeg om een tag te berekenen, omdat de velden die in de HMAC gaan van implementatie, versie en modus afhangen.

Laat zien dat de controle vóór de handshake afgaat

Een ontvanger met de gedeelde sleutel kan de HMAC verifiëren en een vervalst pakket onmiddellijk weggooien, zonder handshakestatus toe te wijzen of publieke-sleutelwerk te doen. De bescherming dekt ook de eerste handshake-pakketten, en juist daarom verschijnt een verkeerde sleutel als een mislukte verbinding en niet als een late authenticatiefout.

Verhoog de uitvoerigheid van de daemon en kijk naar het besturingskanaal in plaats van het tun-apparaat:

openvpn --config /etc/openvpn/server.conf --verb 6

Wat u zoekt is een HMAC-verificatiefout van het besturingskanaal, gemeld op pakketniveau, vóór enige TLS-waarschuwing. Een TLS-waarschuwing in het log betekent dat de envelop is geaccepteerd en de fout naar binnen is verschoven, wat een ander onderzoek met een andere oplossing is.

Richtingsafhandeling zit hier ook. Wanneer een statisch sleutelbestand met tls-auth wordt gebruikt, nemen de twee kanten tegengestelde sleutelrichtingen in, en het protocol gebruikt die splitsing zodat een onderschept pakket niet naar de afzender kan worden teruggekaatst. De richting omdraaien houdt de sleutel gelijk en laat toch elk pakket mislukken. Wijzig één kant per keer en herstart daarna beide daemons zodat het paar samen wordt geladen.

Stem sleutel, richting en digest aan beide kanten af

Drie waarden moeten overeenkomen en slechts één daarvan is het bestand. De inhoud van de statische sleutel moet aan beide kanten identiek zijn, de richting moet tegengesteld zijn en de digest die voor de HMAC wordt gebruikt moet kloppen. Controleer de configuratie voordat u het sleutelmateriaal aanraakt, want één omgekeerde richting verklaart meer fouten dan een beschadigd bestand:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Genereer het gedeelde geheim met het gereedschap en niet met een editor, en houd de rechten strikt:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Oudere releases accepteerden een iets andere optievolgorde voor sleutelgeneratie, en profielen die voor die releases zijn geschreven, circuleren nog steeds. Het gegenereerde bestand is in beide gevallen hetzelfde soort object, dus de controle is of beide kanten identieke bytes hebben, niet welke spelling ze heeft gemaakt.

Verwissel tls-auth niet met tls-crypt. Beide beschermen het besturingskanaal, maar tls-crypt versleutelt het ook en verbergt de handshake voor waarnemers, en het vervangt de richtingsplitsing door zijn eigen sleutelafhandeling. Een profiel met het ene werkt niet samen met een tegenpartij die voor het andere is geconfigureerd, en geen enkele digest-afstemming dicht die kloof.

Reproduceer een tag alleen uit het echte formaat

Byte-exacte reproductie is een andere taak dan een VPN draaien, en het werkt alleen met de echte invoer: de implementatie en versie die het pakket hebben gebouwd, de gekozen digest, de richting en de werkelijke bytes, inclusief sessie-identificatie en bevestigingsarray. Een tekstuele weergave van de veldenlijst zijn die bytes niet.

De taglengte volgt uit de digest, dus een aanname van vaste lengte breekt op het moment dat iemand die wijzigt. Hash het pakket zoals de implementatie doet, niet zoals een tabel in een blogpost het presenteert, en vergelijk met een opname van dezelfde tegenpartij in plaats van met een verwachting die u met de hand hebt afgeleid.

Houd die oefening weg bij productieprofielen. Niets aan het reproduceren van een tag vertelt u of een implementatie de bescherming moet inschakelen.

Draai een afwijking terug zonder de bescherming te verwijderen

De verleidelijke test is tls-auth verwijderen, de verbinding zien slagen en concluderen dat de sleutel verkeerd was. Dat antwoord kost u de bescherming en leert niets over welke van de drie waarden afweek. Haal in plaats daarvan de goedgekeurde overeenkomende configuratie van de serverkant en vergelijk daarmee.

Bereid de wijziging voor zodat die omkeerbaar is. Bewaar de vorige serverconfiguratie en het sleutelbestand, pas het gecorrigeerde paar toe, verifieer dat een client de handshake voltooit en verwijder pas dan de back-up. Als clients na de wijziging falen, herstel dan de vorige bestanden in plaats van tijdens een storing een derde variant te improviseren. Het herstel moet één commando zijn dat u al kent voordat u begint.

Onthoud ten slotte wat een geslaagde controle betekent. Het bewijst dat de tegenpartij de gedeelde sleutel heeft, niet dat het certificaat of account is geautoriseerd, en het zegt niets over de onderhandelde versleuteling van het datakanaal. Autorisatie en gegevensbescherming worden later vastgesteld, dus een schone envelopcontrole is een uitgangspunt en geen vonnis.