OpenVPN TLS-chifferfeil: samanlikn begge partar først

Ein feil om ingen felles chiffer høyrest ut som éi innstilling som må endrast, og innstillinga dei fleste endrar, er den gale. OpenVPN held åtskilde retningslinjer for kontrollkanalen som utfører TLS-handtrykket, og for datakanalen som ber pakkar inne i tunnelen, og feilen nemner den første medan folk redigerer den andre. Å samanlikne kva kvar part tillèt, i rett rekkjefølgje, gjer gjettinga om til to eller tre avgjerder: versjon, deretter suiteliste, deretter påloggingsinformasjon.

Tek du feil av rekkjefølgja, kan du bruke ein time på å leggje til eit AES-namn i ei liste som aldri vart slått opp.

To chifferlister, og berre éi øydelegg handtrykket

Kontrollkanalen forhandlar fram ein TLS-økt, og retningslinja vert skriven med tls-cipher for TLS 1.2 og tls-ciphersuites for TLS 1.3. Datakanalen vert konfigurert separat med data-ciphers, der eit avvik gjev ei tilkopling som vert oppretta og deretter ikkje slepp gjennom trafikk. Begge gjev feil som nemner chiffers, og difor vert dei forveksla. Eit handtrykk som aldri vert fullført, peikar på kontrollkanalen, medan ein etablert tunnel som slepp pakkar, peikar på datakanalen.

Les heile meldinga i staden for den første lina. Avvik i versjon, ein manglande suite, ein algoritme for sertifikatsignatur som parten avviser, og ein mislukka vertsnamnkontroll endar alle i ein TLS-feil, og berre éin av dei handlar om suitelista di. Å halde desse kategoriane frå kvarandre er det meste av diagnosen.

Samanlikn versjonar før du samanliknar suitar

Ein part avgrensa til TLS 1.2 og ein part som krev 1.3, deler ingen versjon, og ingen chifferstreng byggjer bru over det. Noter tls-version-min og tls-version-max på begge sider, eller standardverdiane til bygga som vert brukte, fordi ei distribusjons OpenSSL-retningslinje kan heve golvet utan at nokon OpenVPN-opsjon seier det. Er den eine sida eit apparat eller ein tredjepartsklient, er vindauget dens det fastvaren tillèt. Først når vindauga overlappar, tyder ei suitesamanlikning noko.

Desse notata bør òg namngje dei faktiske binærfilene. Ein kommandolinje-openvpn på den berbare maskina di er ikkje nødvendigvis klienten som handterer ein importert profil.

Lister for TLS 1.2 og TLS 1.3 blandast ikkje

Suitenamn for TLS 1.2 ser slik ut: ECDHE-RSA-AES256-GCM-SHA384 og høyrer til i tls-cipher, som tek ein OpenSSL-chifferstreng. TLS 1.3-suitar heiter TLS_AES_256_GCM_SHA384 og høyrer til i tls-ciphersuites; å leggje éin til i 1.2-strengen konfigurerer ikkje 1.3-lista, og tolken kan godta teksten utan å nokon gong matche han. Eit filter som er rett for éin versjon, seier ingenting om den andre. Skriv ned kva versjon kvar liste er meint for.

openvpn --show-tls skriv ut kva det lokale bygget støttar, og det er ei oversikt, ikkje eit løfte: den eksterne parten tillèt kanskje ikkje desse suitane, og den aktive profilen aktiverer dei kanskje ikkje. Bruk det til å utelukke eit bygg som ikkje kan tilby ein suite i det heile, og samanlikn deretter dei konfigurerte listene.

Prov forhandlinga på ei ny tilkopling

Eit vellukka handtrykk er det einaste provet som tel, og det må kome frå den ekte klienten med den ekte profilen. Auk detaljnivået på tenaren, kople til éin gong, og les den forhandla protokollversjonen og suiten frå loggen i staden for å gå ut frå at den første tilbodne verdien vann. Stadfest deretter datakanalen separat med trafikk gjennom tunnelen, fordi eit fungerande handtrykk og ein sviktande datakanal er ulike reparasjonar. Gjenta etter kvar konfigurasjonsendring, fordi ein utdatert klientprofil er ein vanleg falsk negativ.

Finst det ingen godkjend felles konfigurasjon, er svaret ein oppgradering eller ein migrasjonsplan, ikkje ei svekt retningslinje. Å senke tls-version-min, slå av verifisering eller aktivere alle gamle suitar fjernar avvisinga utan å oppfylle tryggleikskravet som skapte henne.

Noter den forhandla versjonen, suiten og datachifferen i endringssaka. Den neste som møter ein TLS-feil, startar frå det notatet i staden for frå ein chifferstreng funnen i eit foruminnlegg.