iOS het jou strongSwan-tonnel verwerp: vergelyk die IKE-voorstelle

Niets in die sertifikaat of adres verduidelik waarom 'n iPhone wat verlede jaar aan strongSwan gekoppel het, vanjaar faal nie. Niks aan die adres, die vooraf gedeelde sleutel of die kliëntidentiteit hoef te verander het nie. Wat verskuif het, is die lys transformasies wat die telefoon se ingeboude kliënt bereid is om te onderhandel, en sodra daardie lys ophou oorvleuel met dié van die bediener, eindig die uitruiling voordat enigiemand se identiteit ondersoek word.

Die logreël wat die deurslag gee

Skakel die logboek vir daardie verbinding hoër en soek die twee inskrywings wat die uitslag bepaal: wat die telefoon aangebied het en wat die bediener gekies het. As die logboek eindig sonder 'n gekose voorstel en meld dat niks gepas het nie, is verifikasie nooit probeer nie. 'n Nuwe sertifikaat en 'n nuwe wagwoord verander op daardie punt niks, want albei word eers in 'n later stadium gebruik. Nie een kan 'n uitslag beïnvloed wat bepaal is voordat die identiteit ondersoek is nie.

Hou die twee mislukkingsvorme uitmekaar voordat jy iets wysig. Geen wysiging aan die transformasies red 'n verwerpte geloofsbrief nie, en geen regstelling van die geloofsbrief red 'n verwerpte transformasie nie. Die logboekinskrywing wat 'n gekose voorstel noem, sê vir jou in watter van die twee gevalle jy is. Sonder daardie inskrywing raai jy.

Die gekose reël noem die voorstel aan die hand van sy transformasiestel eerder as 'n vriendelike etiket. Vergelyk die velde vir enkripsie, integriteit en groep in daardie reël met die lys wat die telefoon gestuur het, want 'n verskil in enige een veld is genoeg om te verloor.

Wat op die telefoon verander het

Een iOS-weergawe het die algoritmes ingekort wat sy kliënt bereid is om te gebruik. Swak integriteitshashes, klein Diffie-Hellman-groepe en voorstelle wat ou opsies eerste lys, is nie meer aanvaarbaar nie.

Langer lyste is hier nie veiliger nie. Die keuse volg die telefoon se aanvaarde stel en sy eie voorkeurorde, so 'n bediener wat 'n breë katalogus adverteer, kan steeds die onderhandeling verloor wanneer die moderne inskrywings nie diegene is wat gekies word nie. Verkies 'n kort lys met die moderne inskrywings eerste. 'n Lang lys wat met ou opsies begin, lok juis die mislukking wat jy probeer vermy. Die aanvaarde stel is 'n eksterne beperking wat beweeg elke keer wat die kliënt opdateer, so 'n konfigurasie wat gister gewerk het, is bewyse oor gister.

Een paar wat steeds onderhandel

Vir huidige telefone is 'n enkele moderne kombinasie voldoende. Een paar wat onderhandel, lyk so:

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

Die ike-reël dra die enkripsie, integriteit en Diffie-Hellman-groep wat gebruik word terwyl die sleuteluitruiling plaasvind. Die esp-reël dek net die datakanaal, want die groep is reeds vasgestel voordat dit geld. Herlaai die verbinding of herbegin die daemon en koppel dan die telefoon weer. Hou daardie groepwaarde net as elke kliënt wat jy bedien dit nog aanvaar, en moenie die voorstel vir almal verbreed omdat een ou eweknie meer nodig het nie.

Drie plekke om dit reg te maak, een is gewoonlik gesluit

• Een moderne voorstel vir elke eweknie. Korrek wanneer alle kliënte huidige telefone en rekenaars is. Dit verwyder die ou transformasies in plaas daarvan om daaromheen te onderhandel.
• 'n Tweede verbindingsdefinisie vir Apple-kliënte. Hou een ou eweknie aan die lewe terwyl dit vir die telefoon 'n voorstel gee wat hy aanvaar. Dit kos nog 'n verbindingsblok en maak die uitsondering sigbaar.
• Om die kliënt te verander. Selde vir jou oop: wanneer 'n bestuurstelsel of 'n app die profiel verskaf, is daar geen voorstelredigeerder om aan te raak nie, en die ingeboude kliënt stel nie een beskikbaar nie.

Kies die tweede opsie wanneer 'n toestel buite jou beheer nie opgedateer kan word nie. Kies die eerste wanneer jy die ou eweknie kan aftree en verkies om 'n enkele beleid te dra.

Hoe dit ook al sy, die keuse is in die konfigurasie sigbaar, en dit is die punt. 'n Stille terugval wat na 'n ou transformasie afonderhandel, is slegter as 'n eksplisiete blok, want geen hersiening sal dit ooit opmerk nie.

Bewys dit, teken dit dan op

Koppel weer en kontroleer drie afsonderlike feite op die bediener: 'n voorstel is gekies, die verbinding wys gevestig, en die kliënt het 'n adres ontvang. 'n Gevestigde handdruk sonder 'n afgeleë adres dui op die poel of die verkeerskeiers, en dit hoort in sy eie verandering. Om die twee saam te hanteer, laat 'n opgeloste onderhandeling onopgelos lyk.

Skryf die transformasiestel neer wat aanvaar is, wanneer jy dit verander het en watter kliëntbou jy geverifieer het. Die volgende opdatering kan die vereiste weer skuif, en die waardes wat gewerk het, is die eerste ding wat jy langs die nuwes sal wil hê.