Vooraf gedeelde IPsec-sleutel: de bytes achter de tekenreeks die u typte

Twee beheerders vergelijken het geheim op het scherm, zijn het erover eens dat het overeenkomt, en de tunnel faalt nog steeds op authenticatie. De tekenreeks die ze vergeleken is niet de waarde die een van beide uiteinden in de sleutelafleiding stopt. Tussen de tekens die u ziet en de bytes die het protocol hasht, zitten een veldtype, een tekstcodering, een editor en een klembord, en elk van de vier kan de invoer veranderen zonder het uiterlijk te veranderen. Vergelijk de bytes en de mismatch komt meestal binnen enkele seconden aan het licht.

Wat de gateway met de tekenreeks doet

Een vooraf gedeelde sleutel wordt niet over de lijn verzonden en vergeleken. Elk uiteinde stopt zijn lokale kopie in de sleutelafleiding voor de IKE-uitwisseling, en de resulterende authenticatiepayloads worden wel of niet geverifieerd. Dat ontwerp betekent dat de twee kopieën byte-identiek moeten zijn in plaats van visueel gelijk, en het betekent ook dat de fout in de authenticatiefase wordt gemeld in plaats van als een bericht over een verkeerd wachtwoord.

De nuttige vraag is dus nooit „zien deze er hetzelfde uit“, maar „welke exacte reeks bytes hasht elke implementatie“.

Waar extra bytes vandaan komen

Een afsluitende nieuwe regel is de klassieke boosdoener, en hij verstopt zich in het zicht omdat de meeste editors er bij het opslaan van een bestand onzichtbaar een toevoegen. Een voorloop- of volgspatie die uit een chatvenster is geplakt doet hetzelfde, en een typografisch aanhalingsteken dat door een tekstverwerker door een recht is vervangen ook. Niets daarvan verandert de visuele vergelijking die een mens uitvoert.

Vergelijk met een hulpmiddel dat bytes toont in plaats van glyfen. printf '%s' "$PSK" | xxd | tail -2 drukt het einde van de waarde in hex af, waar een verdwaalde 0a of 20 duidelijk is. Doe dat aan beide uiteinden en vergelijk de twee dumps naast elkaar. Doe dat op gegenereerd testmateriaal, niet op een productiegeheim dat u daarna in de shellgeschiedenis laat staan.

Gecodeerd is niet versleuteld

Configuratie-exports dragen het geheim vaak in een basiscodering, soms met regeleinden elke zestig of zesenzeventig tekens en soms met opvulling. Als het ene uiteinde de gedecodeerde bytes verwacht en u plakt de gecodeerde tekst, dan hebt u niet een ander wachtwoord gestuurd, maar een veel langer wachtwoord van afdrukbare tekens. Base64 biedt helemaal geen vertrouwelijkheid, en daarom mag een gecodeerd geheim nooit op een forum worden geplakt voor een tweede mening.

Apples IPSec-woordenboek is een nuttig voorbeeld dat het type ertoe doet: het documenteert SharedSecret als gegevens voor de authenticatiemethode met gedeeld geheim in de L2TP- en Cisco IPsec-payloads. Dat is een specifieke eigenschap in een specifieke payload, geen algemeen tekstveld dat u kunt hergebruiken voor een ander protocol dat toevallig om een geheim vraagt.

Een beweerde limiet hoort bij één combinatie

Oude rapporten over een plafond van tweeëndertig tekens op één Apple-client zijn echte rapporten over één clientversie, protocol en profielvorm. Ze zijn geen universele limiet voor elk Apple-platform, elke provider en elk protocol. Controleer de versie, het payloadtype en de gateway-eis samen, en test dan op een goedgekeurde opstelling in plaats van uit een thread af te leiden. Schrijf de geteste combinatie in het wijzigingsregister, anders citeert de volgende persoon dezelfde thread met meer vertrouwen dan die verdient.

Als een limiet echt geldt, is het antwoord een ondersteund inloggegevensontwerp dat erin past, niet een verkorte versie van een sterk geheim. Een productiesleutel inkorten om aan een vermoede limiet te voldoen verlaagt de sterkte permanent en levert een systeem op waarvan de documentatie niet meer bij de beveiliging past.

Repareer de weergave, niet de sterkte

Als authenticatie mislukt nadat de weergave is bevestigd, lees dan het effectieve beleid in de authenticatiefase: welke methode wordt onderhandeld, welke peer-identiteit wordt verwacht, en of de gateway overeenkomt met de verbinding die u denkt. Geleidelijk zwakkere gissingen zijn geen diagnose, het is een langzame afwaardering met een supportticket eraan vast.

Als de vereiste inloggegevens niet aan de standaard van de organisatie kunnen voldoen, wijzig het ontwerp dan in een dat wel kan. Een gedeeld geheim met voldoende entropie, één keer gegenereerd, opgeslagen in een beheerd veld en nooit gepubliceerd, is een volkomen goed antwoord; een kortere versie ervan niet.