Wêrom it tafoegjen fan opt-verify jo OpenVPN-sifersflater net reparearret

Jo fine in suggestje om opt-verify ta te foegjen, foegje de rigel ta, en de sifersflater bliuwt krekt dêr't er wie. Dat resultaat is foarsisber, om't de opsje nea in sifer ûnderhannele hat. It wie in opsje-konsekwinsjekontrôle, ferâldere yn 2.6 en fuort yn 2.7, en in profyl dat dêrmei noch parst, hat dêrmei neat ôftwongen.

It helpt om te witten wat de rigel earder die foardat jo konkludearje dat it it ûntbrekkende stik is. De skiednis ferklearret ek wêrom't er no net helpe kin.

Wat de opsje earder ôftwong

De 2.6-hânlieding markearret opt-verify as ferâldere en beskriuwt it eardere gedrach: de tsjinner smyt kliïnten fuort waans oanjûne opsjes net oerienkomme mei syn eigen, troch dingen as apparaattype en MTU te fergelykjen. Dy kontrôle hinget ek ôf fan it oan bliuwen fan de opsje-konsekwinsjekontrôle, dus in tsjinner dy't mei disable-occ rint, hat dy nea hân. Tink derom wêr't de fergeliking fan boud is: tekst dy't de konfiguraasje fan in oare part beskriuwt. It seit neat oer hokker sifer it datakanaal brûke sil.

Dat is de earste reden wêrom't de flagge in sifersflater net reparearje kin. Siferkarring wurdt regele troch it data-ciphers-belied en troch wat beide partijen stypje, en in tekstuele konsekwinsjekontrôle wreidet dy list net út en fiert de ûnderhanneling net út. In twadde reden is it berik: de kontrôle giet oer oft de oanjûne opsjes kompatibel lykje, net oer de kwaliteit fan it paad dat derút folget.

Wat 2.7 docht as er de rigel sjocht

Yn 2.7 is de opsje fuort. De parser werkent de namme noch, dêrom laden in âld profyl sûnder syntaksflater, en it meldt dat de opsje fuort is ynstee fan der stil foarby te gean. In namme werkennen en gedrach ôftwinge binne ferskillende dingen, en allinnich it earste bart noch. De fuorthelnotysjes jouwe de reden: sadree't parameters ûnderhannele wurde kinne, kinne twa partijen legitím ferskillende opsje-strings hawwe wylst se it oer de ferbining iens binne.

In profyl dat parst is dus gjin bewiis dat ienige talittingskontrôle rûn hat. As jo iennige sinjaal is dat de kliïnt ferbûn, hawwe jo leard dat de syntaks akseptearre is.

Wêr't de flater eins leit

Bewarje de earste konkrete flater foardat jo wat feroarje, om't lettere berjochten meastentiids gefolgen dêrfan binne. In mislearre ûnderhanneling fan it datakanaal heart by it goedkarde siferbelied en by de mooglikheden dy't beide partijen eins oankundigje. In flater yn TLS-ferzje of -suite heart by it kontrôlekanaal. In sertifikaatôfwizing hat de identiteit en de fertrouwensketen nedich, net in kompatibiliteitsflagge.

Identifisearje ek de motor oan beide kanten. In buroblêdapplikaasje kin in oare bou bringe as it kommandorigelbinêre bestân wêrmei't jo testen, en opsjestipe ferskilt tusken har. Besjoch de dokumintaasje fan dy motor ynstee fan oan te nimmen dat elk programma dat in profyl ymportearret itselde docht.

Ferfang de bedoeling, net allinnich de rigel

As in âldere behearde tsjinner wier fertroude op de konsekwinsjekontrôle, skriuw dan op hokker beheining er foar de upgrade ôftwong. It hâlden fan in negearre opsje yn in nijer profyl kin dat belied net bewarje, en it samar wiskjen fan rigels ek net.

Reagearje net op in âlde suggestje dat alle sifers útskeakele binne troch elk histoarysk algoritme oan te setten.

Nei in goedkarde korreksje, besjoch de ûnderhannele resultaten op in nije ferbining en test it programma dat de brûker wier nedich hat. Hâld de tsjinnerferzje en it effektive belied neist dat resultaat, sadat de folgjende persoan sjen kin wat ôfsprutsen is ynstee fan wat mar akseptearre is.

It doel is in stipe beheining en in wurkjend autentisearre paad, net in âlde flagge dy't noch parst.