Windows og strongSwan-chifre: treff riktig lag

Begge ender sier AES-128, og tunnelen nekter fortsatt å bygges. CBC og GCM er forskjellige transformasjoner som tilfeldigvis deler samme nøkkellengde, og en klient som tilbyr den ene, tilfredsstiller ikke en gateway som bare godtar den andre. Ordet AES beskriver en familie, ikke en avtale.

Det finnes også en andre akse, og det er den som gir forvirrende feil.

To lag, to uavhengige lister

IKE beskytter selve forhandlingen, mens den underordnede assosiasjonen beskytter trafikken du faktisk bryr deg om. Windows eksponerer den første som en krypteringsmetode og en integritetsmetode, og den andre som chiffer- og autentiseringstransformasjonskonstanter. Disse feltene er ikke aliaser for hverandre, og en verdi som er gyldig i den ene, kan være meningsløs eller feil i den andre. Å lese profilen med denne delingen i tankene fjerner det meste av forvirringen.

Den praktiske konsekvensen er at du kan ha en helt akseptabel nøkkelutvekslingspolicy og en datakanalpolicy som motparten ikke vil godta. Den ene listen forhandler; den andre beskytter pakker. Å endre en verdi i den første har ingen effekt på den andre, uansett hvor like de to ser ut i en konfigurasjonsdialog.

Skriv ned begge listene før du sammenligner dem med gatewayen. En sammenligning fra hukommelsen er hvordan ett felt blir redigert to ganger og det andre aldri. Hold gateway-konsollen åpen ved siden av profilen.

Les feilen ved siden av forslagene

Trinnet som feilet, forteller deg hvilken liste du skal undersøke. En avvisning under den innledende nøkkelutvekslingen er et IKE-forslagsproblem, og det skjer før noen underordnet assosiasjon eksisterer. En feil mens assosiasjonen for beskyttet trafikk forhandles, er et ESP-forslagsproblem, og nøkkelutvekslingen har allerede lyktes. En generisk policytreffmelding fra klienten navngir ingen av trinnene, derfor er gatewayens eget syn det nyttige.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Sammenlign forslaget som ble mottatt, forslaget som er konfigurert og det som ble valgt for det ene forsøket. Tre forskjellige lister betyr noe her, og bare den siste beskriver hva som faktisk ble brukt. Siter den ordrett i saken i stedet for å oppsummere den.

Hold CBC og GCM som separate alternativer

En gateway som bevisst er tillatt å godta hvilken som helst av familiene, trenger to forslag, ikke ett. I strongSwan skiller et komma alternativer, og en bindestrek forbinder komponentene i ett enkelt sett. Å kombinere begge familiene med bindestreker gir ett umulig forslag i stedet for to akseptable.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

Det første alternativet bærer autentisert kryptering og navngir fortsatt en pseudorandomfunksjon, fordi nøkkelavledning trenger en selv når integriteten kommer fra chifferen. Det andre alternativet er klassisk kryptering med en separat integritetsalgoritme. Begge er fortsatt avhengige av hva den innlastede kryptoimplementasjonen støtter.

Et ESP-forslag er ikke et omdøpt IKE-forslag

Chiffer-tokenet ser identisk ut i begge listene, og nesten ingenting annet overføres. Et ESP-forslag har ingen pseudorandomfunksjon for nøkkelutveksling, og kravene til integritet og forward secrecy argumenteres mot Windows-policyen på den andre siden i stedet for å kopieres fra IKE-linjen. Å oversette den ene listen mekanisk til den andre gir noe som validerer og aldri forhandler.

Velg en retning og bli i den. Enten beholder gatewayen en policy med bare GCM og klienten ruller ut en fullstendig kompatibel policy, eller så godtar gatewayen begge familiene og klienten beholder sitt eksisterende sett. Å aktivere en reserve som sikkerhetspolicyen forbyr, er ikke en rettelse, uansett hvor raskt det fjerner feilen.

Verifiser begge settene, deretter en nøkkelnygenerering

Bekreft det valgte nøkkelutvekslingssettet og det valgte trafikksettet hver for seg, fordi de kommer fra forskjellige lister og kan lykkes uavhengig. La deretter en nøkkelnygenerering skje og bekreft den også. Et første håndtrykk som virker og en nøkkelnygenerering som feiler, beskriver et forslagssett som bare er delvis akseptabelt.

Oppbevar beviset sammen med endringen. En tilbakevendende frakobling trenger sin egen registrering av mislykket utveksling før noen klandrer en timer eller en plattformfeil.