iOS wees je strongSwan-tunnel af: vergelijk de IKE-voorstellen

Niets in het certificaat of het adres verklaart waarom een iPhone die vorig jaar verbinding maakte met strongSwan dit jaar faalt. Aan het adres, de vooraf gedeelde sleutel of de identiteit van de client hoeft niets te zijn veranderd. Wat is verschoven, is de lijst met transformaties waarover de ingebouwde client van de telefoon wil onderhandelen, en zodra die lijst niet meer overlapt met die van de server, eindigt de uitwisseling voordat iemands identiteit wordt onderzocht.

De logregel die het beslist

Zet de logging voor die verbinding hoger en zoek de twee regels die de uitkomst bepalen: wat de telefoon aanbood en wat de server koos. Als het log eindigt zonder gekozen voorstel en meldt dat niets overeenkwam, is authenticatie nooit geprobeerd. Een nieuw certificaat en een nieuw wachtwoord veranderen op dat punt niets, omdat beide in een latere fase worden verbruikt. Geen van beide kan een uitkomst beïnvloeden die werd bepaald voordat de identiteit werd onderzocht.

Houd de twee faalvormen uit elkaar voordat je iets aanpast. Geen enkele aanpassing van de transformaties redt geweigerde inloggegevens, en geen enkele correctie van de inloggegevens redt een geweigerde transformatie. De logregel die een gekozen voorstel noemt, vertelt je in welke van de twee je zit. Zonder die regel gok je.

De gekozen regel noemt het voorstel bij zijn transformatieset in plaats van bij een vriendelijk label. Vergelijk de velden voor versleuteling, integriteit en groep in die regel met de lijst die de telefoon stuurde, want een afwijking in ook maar één veld is genoeg om te verliezen.

Wat er op de telefoon veranderde

Eén iOS-release heeft de algoritmes ingekort die de client wil gebruiken. Zwakke integriteitshashes, kleine Diffie-Hellman-groepen en voorstellen die oude opties eerst noemen, zijn niet meer acceptabel.

Langere lijsten zijn hier niet veiliger. De selectie volgt de geaccepteerde set van de telefoon en de eigen voorkeursvolgorde, dus een server die een brede catalogus adverteert kan de onderhandeling alsnog verliezen wanneer de moderne regels niet de gekozen zijn. Geef de voorkeur aan een korte lijst met de moderne regels vooraan. Een lange lijst die met oude opties begint, lokt precies de fout uit die je probeert te vermijden. De geaccepteerde set is een externe beperking die verschuift bij elke update van de client, dus een configuratie die gisteren werkte is bewijs over gisteren.

Eén paar dat nog onderhandelt

Voor huidige telefoons volstaat één moderne combinatie. Eén paar dat onderhandelt ziet er zo uit:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

De ike-regel draagt de versleuteling, de integriteit en de Diffie-Hellman-groep die worden gebruikt terwijl de sleuteluitwisseling loopt. De esp-regel dekt alleen het datakanaal, omdat de groep al is bepaald voordat die geldt. Herlaad de verbinding of herstart de daemon en verbind daarna de telefoon opnieuw. Houd die groepswaarde alleen als elke client die je bedient hem nog accepteert, en verbreed het voorstel niet voor iedereen omdat één oude peer meer nodig heeft.

Drie plekken om het te repareren, één is meestal gesloten

• Eén modern voorstel voor elke peer. Juist wanneer alle clients huidige telefoons en desktops zijn. Het verwijdert de oude transformaties in plaats van eromheen te onderhandelen.
• Een tweede verbindingsdefinitie voor Apple-clients. Houdt één oude peer in leven terwijl de telefoon een voorstel krijgt dat hij accepteert. Het kost een extra verbindingsblok en maakt de uitzondering zichtbaar.
• De client vervangen. Zelden voor je open: wanneer een beheersysteem of een app het profiel levert, is er geen voorstellen-editor om aan te raken, en de ingebouwde client biedt er geen.

Kies de tweede optie wanneer een apparaat buiten je controle niet kan worden bijgewerkt. Kies de eerste wanneer je de oude peer kunt uitfaseren en liever één beleid voert.

Hoe dan ook, de keuze is zichtbaar in de configuratie, en dat is het punt. Een stille terugval die naar een oude transformatie onderhandelt is erger dan een expliciet blok, omdat geen enkele review het ooit aan het licht brengt.

Bewijs het en leg het dan vast

Verbreek en maak opnieuw verbinding en controleer drie afzonderlijke feiten op de server: er is een voorstel gekozen, de verbinding toont zich als tot stand gebracht, en de client heeft een adres ontvangen. Een tot stand gebrachte handshake zonder extern adres wijst op de pool of de verkeersselectoren, en dat hoort in een eigen wijziging. Beide samen behandelen laat een opgeloste onderhandeling onopgelost lijken.

Noteer de transformatieset die is geaccepteerd, wanneer je die hebt gewijzigd en welke clientbuild je hebt geverifieerd. De volgende update kan de eis weer verschuiven, en de waarden die werkten zijn het eerste dat je naast de nieuwe wilt hebben.