vpnc-fejl med svag kryptering: gatewaypolitik eller skrivebordsrettelse?

To rettelser ser lige hurtige ud, når en gammel vpnc-forbindelse nægter at komme op: send det gamle svag-krypteringsflag, eller indsæt et wrapper-script, der tilføjer det for dig. De er ikke ækvivalente, fordi den ene ændrer politikken for én profil, og den anden ændrer adfærden for ethvert program, der kalder den sti. Det første spørgsmål er, om gatewayen stadig tilbyder et svagt forslag, og det andet er, hvem der har lov til at acceptere det. Alt andet følger af de to svar.

To rettelser med meget forskellig rækkevidde

En ændring på profilniveau rører én forbindelse, én ejer og én udløbsdato. Udskiftning af den installerede binære fil rører hver frontend på maskinen, inklusive det skrivebordsapplet en kollega bruger til en helt anden gatewayprofil. Wrapperen skjuler også ændringen for enhver, der fejlfinder værten seks måneder senere.

Pakkekontrol er det første offer: en fil på /usr/sbin/vpnc, der ikke længere matcher sin pakke, gør en rutinemæssig sikkerhedsopdatering til en undersøgelse. Opgraderinger overskriver derefter enten wrapperen lydløst eller nægter at blive anvendt, afhængigt af hvordan pakkehåndteringen behandler ændrede filer. Ingen af udfaldene vises i forbindelsesloggen, og derfor forbliver wrapper-tilgangen tillokkende indtil den første hændelse. Én linje i en profil er langt lettere at finde og fjerne end en binær fil, som ingen husker at have udskiftet.

Hvad den forældede kontakt faktisk gør

vpnc-manualen markerer enkelt-DES-muligheden som forældet til fordel for en indstilling til svag kryptering og dokumenterer en separat mulighed, der tillader slet ingen kryptering af datatrafik. Det er forskellige indrømmelser med forskellige konsekvenser. Ingen af dem får en moderne gateway til at forhandle om noget, den ikke længere tilbyder.

Læs fejlstadiet, før du vælger en rettelse. Et afvist forslag og en afvist adgangskode giver lignende frontend-beskeder, men helt forskellige beviser.

Hvor en afgrænset undtagelse hører hjemme

Hvis en organisation bevidst accepterer en gammel peer i en begrænset periode, hører undtagelsen hjemme i den peers profil, med en ejer, en revisionsdato og en migreringsvej til en understøttet protokol. At holde den uden for den globale sti er hele pointen med at kalde den afgrænset.

Få gatewayejeren til at bekræfte, hvilke algoritmer peer'en stadig tilbyder, og hvad der erstatter den. Et klientflag kan ikke reparere et forslag, som serveren ikke længere sender, og en servermigrering, som ingen har planlagt, vil overleve workarounden. Sæt revisionsdatoen i samme ticket som undtagelsen, så indrømmelsen udløber i stedet for at blive permanent.

Kontroller forhandlingen, ikke bare det grønne ikon

Indsaml beviser, der identificerer stadiet frem for stemningen i dialogen. Kommandoerne nedenfor er kun læsning, og de to første viser, hvilken konfiguration og version der faktisk er i spil.

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

Den tredje kommando rapporterer filer, der ikke længere matcher pakken, og det er sådan en glemt wrapper melder sig. Den fjerde viser de indrømmelser, profilen bærer, så en undtagelse ikke stille kan sprede sig til en anden profil gennem en kopieret fil. Kør begge før og efter en ændring, og opbevar outputtet sammen med forbindelsesprofilen i stedet for i et chatvindue.

Hold fejlretningsoutput ude af tickets, indtil nogen har læst det, fordi manualen advarer om, at det højeste fejlretningsniveau dumper autentificeringsdata inklusive adgangskoder. Acceptkriteriet er en autoriseret, understøttet aftale mellem klient og gateway, ikke et menupunkt, der endelig bliver grønt. Hvis peer'en kun tilbyder en brudt algoritme, er det ærlige resultat en undtagelse med en slutdato eller en erstatningsprotokol, og den beslutning tilhører den, der ejer gatewayen. At registrere beslutningen er forskellen mellem en styret undtagelse og en utilsigtet politikændring.