Forudelt IPsec-nøgle: byteene bag den streng, du skrev

To administratorer sammenligner hemmeligheden på skærmen, er enige om, at den stemmer, og tunnelen fejler stadig i godkendelsen. Den streng, de sammenlignede, er ikke den værdi, som nogen af enderne sender ind i nøgleudledningen. Mellem tegnene, du ser, og de bytes, protokollen hasher, findes en felttype, en tekstkodning, en editor og en udklipsholder, og enhver af de fire kan ændre input uden at ændre, hvordan det ser ud. Sammenlign byteene, og uenigheden dukker normalt op i løbet af sekunder.

Hvad gatewayen gør med strengen

En forudelt nøgle sendes ikke over nettet og sammenlignes. Hver ende sender sin lokale kopi ind i nøgleudledningen til IKE-udvekslingen, og de resulterende godkendelsesnyttelaster verificeres eller gør ikke. Det design betyder, at de to kopier skal være byte-identiske snarere end visuelt ens, og det betyder også, at fejlen rapporteres på godkendelsestrinnet snarere end som en besked om forkert adgangskode.

Så det nyttige spørgsmål er aldrig »ser de ens ud«, men »hvilken nøjagtig byte-sekvens hasher hver implementering«.

Hvor ekstra bytes kommer fra

En efterfølgende ny linje er den klassiske synder, og den skjuler sig i åben lys, fordi de fleste editorer tilføjer en usynligt, når en fil gemmes. Et indledende eller efterfølgende mellemrum indsat fra et chatvindue gør det samme, og det gør et typografisk citationstegn, der er erstattet med et lige af et tekstbehandlingsprogram. Intet af det ændrer den visuelle sammenligning, et menneske udfører.

Sammenlign med et værktøj, der viser bytes i stedet for glyffer. printf '%s' "$PSK" | xxd | tail -2 udskriver slutningen af værdien i hex, hvor en løsrevet 0a eller 20 er tydelig. Gør det i begge ender, og sammenlign de to dumps side om side. Gør det på genereret testmateriale, ikke på en produktionshemmelighed, som du derefter efterlader i shell-historikken.

Kodet er ikke krypteret

Konfigurationseksporter bærer ofte hemmeligheden i en basiskodning, nogle gange med linjeskift for hver tres eller seksoghalvfjerds tegn og nogle gange med udfyldning. Hvis den ene ende forventer de afkodede bytes, og du indsætter den kodede tekst, har du ikke sendt en anden adgangskode, du har sendt en meget længere en lavet af printbare tegn. Base64 giver slet ingen fortrolighed, og det er også derfor, en kodet hemmelighed aldrig må indsættes i et forum for at få en anden vurdering.

Apples IPSec-ordbog er et nyttigt eksempel på, at typen betyder noget: den dokumenterer SharedSecret som data til godkendelsesmetoden med delt hemmelighed i L2TP- og Cisco IPsec-nyttelasterne. Det er en specifik egenskab i en specifik nyttelast, ikke et generelt tekstfelt, du kan genbruge til en anden protokol, der tilfældigvis beder om en hemmelighed.

En påstået grænse tilhører én kombination

Gamle rapporter om et loft på toogtredive tegn på én Apple-klient er rigtige rapporter om én klientversion, protokol og profilform. De er ikke en universel grænse for enhver Apple-platform, enhver udbyder og enhver protokol. Kontroller versionen, nyttelasttypen og gatewaykravet sammen, og test derefter på en godkendt opsætning i stedet for at udlede det fra en tråd. Skriv den testede kombination i ændringsregistret, for ellers vil den næste person citere den samme tråd med større sikkerhed, end den fortjener.

Hvis en grænse virkelig gælder, er svaret et understøttet legitimationsdesign, der passer til den, ikke en forkortet version af en stærk hemmelighed. At afkorte en produktionsnøgle for at opfylde en gættet grænse reducerer dens styrke permanent og skaber et system, hvis dokumentation ikke længere matcher dets sikkerhed.

Ret repræsentationen, ikke styrken

Når godkendelsen fejler, efter at repræsentationen er bekræftet, skal du læse den effektive politik på godkendelsestrinnet: hvilken metode der forhandles, hvilken peer-identitet der forventes, og om gatewayen matcher den forbindelse, du tror. Gradvist svagere gætterier er ikke diagnose, de er en langsom nedgradering med en supportbillet vedhæftet.

Hvis den krævede legitimationsoplysning ikke kan opfylde organisationens standard, skal du ændre designet til et, der kan. En delt hemmelighed med tilstrækkelig entropi, genereret én gang, opbevaret i et administreret felt og aldrig offentliggjort, er et helt godt svar; en kortere version af den er ikke.