OpenVPN TLS-chifferfeil: sammenlign begge parter først

En feil om ingen felles chiffer høres ut som én innstilling som må endres, og innstillingen de fleste endrer, er den gale. OpenVPN holder adskilte retningslinjer for kontrollkanalen som utfører TLS-håndtrykket, og for datakanalen som bærer pakker inne i tunnelen, og feilen nevner den første mens folk redigerer den andre. Å sammenligne hva hver part tillater, i riktig rekkefølge, gjør gjettingen om til to eller tre beslutninger: versjon, deretter suiteliste, deretter påloggingsinformasjon.

Tar du feil av rekkefølgen, kan du bruke en time på å legge til et AES-navn i en liste som aldri ble slått opp.

To chifferlister, og bare én ødelegger håndtrykket

Kontrollkanalen forhandler frem en TLS-økt, og retningslinjen skrives med tls-cipher for TLS 1.2 og tls-ciphersuites for TLS 1.3. Datakanalen konfigureres separat med data-ciphers, der en uoverensstemmelse gir en tilkobling som opprettes og deretter ikke slipper gjennom trafikk. Begge gir feil som nevner chiffere, og derfor forveksles de. Et håndtrykk som aldri fullføres, peker på kontrollkanalen, mens en etablert tunnel som slipper pakker, peker på datakanalen.

Les hele meldingen i stedet for den første linjen. Uoverensstemmelse i versjon, en manglende suite, en algoritme for sertifikatsignatur som parten avviser, og en mislykket vertsnavnkontroll ender alle i en TLS-feil, og bare én av dem handler om suitelisten din. Å holde disse kategoriene fra hverandre er det meste av diagnosen.

Sammenlign versjoner før du sammenligner suiter

En part begrenset til TLS 1.2 og en part som krever 1.3, deler ingen versjon, og ingen chifferstreng bygger bro over det. Noter tls-version-min og tls-version-max på begge sider, eller standardverdiene til byggene som brukes, fordi en distribusjons OpenSSL-retningslinje kan heve gulvet uten at noen OpenVPN-opsjon sier det. Hvis den ene siden er et apparat eller en tredjepartsklient, er vinduet dens det fastvaren tillater. Først når vinduene overlapper, betyr en suitesammenligning noe.

Disse notatene bør også navngi de faktiske binærfiler. En kommandolinje-openvpn på den bærbare maskinen din er ikke nødvendigvis klienten som håndterer en importert profil.

Lister for TLS 1.2 og TLS 1.3 blandes ikke

Suitenavn for TLS 1.2 ser slik ut: ECDHE-RSA-AES256-GCM-SHA384 og hører til i tls-cipher, som tar en OpenSSL-chifferstreng. TLS 1.3-suiter heter TLS_AES_256_GCM_SHA384 og hører til i tls-ciphersuites; å legge én til i 1.2-strengen konfigurerer ikke 1.3-listen, og tolkeren kan godta teksten uten å noen gang matche den. Et filter som er riktig for én versjon, sier ingenting om den andre. Skriv ned hvilken versjon hver liste er ment for.

openvpn --show-tls skriver ut hva det lokale bygget støtter, og det er en oversikt, ikke et løfte: den eksterne parten tillater kanskje ikke disse suitene, og den aktive profilen aktiverer dem kanskje ikke. Bruk det til å utelukke et bygg som ikke kan tilby en suite i det hele tatt, og sammenlign deretter de konfigurerte listene.

Bevis forhandlingen på en ny tilkobling

Et vellykket håndtrykk er det eneste beviset som teller, og det må komme fra den ekte klienten med den ekte profilen. Øk detaljnivået på serveren, koble til én gang, og les den forhandlede protokollversjonen og suiten fra loggen i stedet for å anta at den første tilbudte verdien vant. Bekreft deretter datakanalen separat med trafikk gjennom tunnelen, fordi et fungerende håndtrykk og en sviktende datakanal er forskjellige reparasjoner. Gjenta etter enhver konfigurasjonsendring, fordi en utdatert klientprofil er en vanlig falsk negativ.

Finnes det ingen godkjent felles konfigurasjon, er svaret en oppgradering eller en migreringsplan, ikke en svekket retningslinje. Å senke tls-version-min, slå av verifisering eller aktivere alle gamle suiter fjerner avvisningen uten å oppfylle sikkerhetskravet som skapte den.

Noter den forhandlede versjonen, suiten og datachifferen i endringssaken. Den neste som møter en TLS-feil, starter fra det notatet i stedet for fra en chifferstreng funnet i et foruminnlegg.