Windows- en strongSwan-ciphers: tref de juiste laag

Beide uiteinden zeggen AES-128 en de tunnel weigert nog steeds om op te komen. CBC en GCM zijn verschillende transformaties die toevallig dezelfde sleutellengte delen, en een client die de ene aanbiedt, voldoet niet aan een gateway die alleen de andere accepteert. Het woord AES beschrijft een familie, geen overeenkomst.

Er is ook een tweede as, en die zorgt voor de verwarrende fouten.

Twee lagen, twee onafhankelijke lijsten

IKE beschermt de onderhandeling zelf, terwijl de child-associatie het verkeer beschermt waar je echt om geeft. Windows toont de eerste als een versleutelingsmethode en een integriteitsmethode, en de tweede als cipher- en authenticatietransformatieconstanten. Die velden zijn geen aliassen van elkaar, en een waarde die in het ene geldig is, kan in het andere zinloos of fout zijn. Het profiel met die splitsing in gedachten lezen neemt het meeste van de verwarring weg.

De praktische consequentie is dat je een volledig acceptabel sleuteluitwisselingsbeleid kunt hebben en een datakanaalbeleid dat de peer niet accepteert. De ene lijst onderhandelt; de andere beschermt pakketten. Een waarde in de eerste wijzigen heeft geen effect op de tweede, hoe gelijk de twee er ook uitzien in een configuratiedialoog.

Schrijf beide lijsten op voordat je ze met de gateway vergelijkt. Een vergelijking uit het geheugen is hoe het ene veld twee keer wordt bewerkt en het andere nooit. Houd de gatewayconsole open naast het profiel.

Lees de fout naast de voorstellen

De fase die faalde, vertelt je welke lijst je moet onderzoeken. Een weigering tijdens de eerste sleuteluitwisseling is een IKE-voorstelprobleem, en dat gebeurt voordat er een child-associatie bestaat. Een fout terwijl de associatie voor beschermd verkeer wordt onderhandeld, is een ESP-voorstelprobleem, en de sleuteluitwisseling is al geslaagd. Een generiek bericht over beleidsmatch van de client noemt geen van beide fasen, daarom is de eigen kijk van de gateway de nuttige.

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

Vergelijk het ontvangen voorstel, het geconfigureerde voorstel en het geselecteerde voor die ene poging. Drie verschillende lijsten zijn hier van belang, en alleen de laatste beschrijft wat er werkelijk is gebruikt. Citeer het letterlijk in het ticket in plaats van het samen te vatten.

Houd CBC en GCM als afzonderlijke alternatieven

Een gateway die er bewust voor is toegestaan een van beide families te accepteren, heeft twee voorstellen nodig, niet één. In strongSwan scheidt een komma alternatieven, en een koppelteken verbindt de componenten van één suite. Beide families met koppeltekens combineren levert één onmogelijk voorstel op in plaats van twee acceptabele.

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

Het eerste alternatief draagt geauthenticeerde versleuteling en noemt nog steeds een pseudorandomfunctie, omdat sleutelafleiding er een nodig heeft, zelfs wanneer integriteit uit de cipher komt. Het tweede alternatief is klassieke versleuteling met een apart integriteitsalgoritme. Beide blijven afhankelijk van wat de geladen crypto-implementatie ondersteunt.

Een ESP-voorstel is geen hernoemd IKE-voorstel

Het cipher-token ziet er in beide lijsten identiek uit, en bijna niets anders wordt overgedragen. Een ESP-voorstel heeft geen pseudorandomfunctie voor sleuteluitwisseling, en de eisen voor integriteit en forward secrecy worden tegen het Windows-beleid aan de andere kant beargumenteerd in plaats van uit de IKE-regel gekopieerd. De ene lijst mechanisch in de andere vertalen levert iets op dat valideert en nooit onderhandelt.

Kies een richting en blijf daarbij. Ofwel houdt de gateway een beleid met alleen GCM aan en de client implementeert een volledig compatibel beleid, ofwel accepteert de gateway beide families en de client behoudt zijn bestaande suite. Een fallback inschakelen die het beveiligingsbeleid verbiedt, is geen oplossing, hoe snel het de fout ook wegneemt.

Verifieer beide suites, dan een sleutelhernieuwing

Bevestig de geselecteerde sleuteluitwisselingssuite en de geselecteerde verkeerssuite afzonderlijk, omdat ze uit verschillende lijsten komen en onafhankelijk kunnen slagen. Laat dan een sleutelhernieuwing plaatsvinden en bevestig die ook. Een eerste handdruk die werkt en een sleutelhernieuwing die faalt, beschrijven een voorstelverzameling die slechts gedeeltelijk acceptabel is.

Bewaar dat bewijs bij de wijziging. Een terugkerende verbreking heeft zijn eigen registratie van een mislukte uitwisseling nodig voordat iemand een timer of een platformfout de schuld geeft.