OpenVPN TLS-chifferfel: jämför båda sidorna först

Ett fel om ingen gemensam chiffer låter som en enda inställning som måste ändras, och inställningen som de flesta ändrar är den felaktiga. OpenVPN håller separata policyer för kontrollkanalen som utför TLS-handskakningen och för datakanalen som bär paket inuti tunneln, och felet namnger den första medan folk redigerar den andra. Att jämföra vad varje sida tillåter, i rätt ordning, gör gissningarna till två eller tre beslut: version, sedan suitelista, sedan inloggningsuppgifter.

Tar du fel på ordningen kan du lägga en timme på att lägga till ett AES-namn i en lista som aldrig slogs upp.

Två chifferlistor, och bara en bryter handskakningen

Kontrollkanalen förhandlar fram en TLS-session, och dess policy skrivs med tls-cipher för TLS 1.2 och tls-ciphersuites för TLS 1.3. Datakanalen konfigureras separat med data-ciphers, där en avvikelse ger en anslutning som upprättas och sedan inte kan släppa igenom trafik. Båda ger fel som nämner chiffror, och därför blandas de ihop. En handskakning som aldrig slutförs pekar på kontrollkanalen, medan en upprättad tunnel som tappar paket pekar på datakanalen.

Läs hela meddelandet i stället för första raden. En versionsavvikelse, en saknad suite, en certifikatsignaturalgoritm som sidan avvisar och ett misslyckat värdnamnsverifiering slutar alla i ett TLS-fel, och bara en av dem handlar om din suitelista. Att hålla isär de kategorierna är det mesta av diagnosen.

Jämför versioner innan du jämför suiter

En sida som är begränsad till TLS 1.2 och en sida som kräver 1.3 delar ingen version, och ingen chiffersträng överbryggar det. Anteckna tls-version-min och tls-version-max på båda sidor, eller standardvärdena för de byggen som används, eftersom en distributions OpenSSL-policy kan höja golvet utan att någon OpenVPN-inställning säger det. Om ena sidan är en apparat eller en tredjepartsklient är dess fönster vad firmware tillåter. Först när fönstren överlappar betyder en suitejämförelse något.

De anteckningarna bör också namnge de faktiska binärfilerna. En kommandorads-openvpn på din bärbara dator är inte nödvändigtvis klienten som hanterar en importerad profil.

Listor för TLS 1.2 och TLS 1.3 blandas inte

Suitenamn för TLS 1.2 ser ut så här: ECDHE-RSA-AES256-GCM-SHA384 och hör hemma i tls-cipher, som tar en OpenSSL-chiffersträng. TLS 1.3-suiter heter TLS_AES_256_GCM_SHA384 och hör hemma i tls-ciphersuites; att lägga till en i 1.2-strängen konfigurerar inte 1.3-listan, och tolken kan acceptera texten utan att någonsin matcha den. Ett filter som är rätt för en version säger ingenting om den andra. Skriv ned vilken version varje lista är avsedd för.

openvpn --show-tls skriver ut vad det lokala bygget stöder, och det är en inventering, inte ett löfte: den fjärrande sidan tillåter kanske inte dessa suiter, och den aktiva profilen aktiverar dem kanske inte. Använd det för att utesluta ett bygge som inte alls kan erbjuda en suite, och jämför sedan de konfigurerade listorna.

Bevisa förhandlingen på en ny anslutning

En lyckad handskakning är det enda bevis som räknas, och den måste komma från den riktiga klienten med den riktiga profilen. Höj serverns detaljnivå, anslut en gång och läs den förhandlade protokollversionen och suiten ur loggen i stället för att anta att det första erbjudna värdet vann. Bekräfta sedan datakanalen separat med trafik genom tunneln, eftersom en fungerande handskakning och en sviktande datakanal är olika reparationer. Upprepa efter varje konfigurationsändring, eftersom en föråldrad klientprofil är en vanlig falsk negativ.

Finns ingen godkänd gemensam konfiguration är svaret en uppgradering eller en migreringsplan, inte en försvagad policy. Att sänka tls-version-min, stänga av verifieringen eller aktivera alla gamla suiter tar bort avvisningen utan att uppfylla säkerhetskravet som skapade den.

Anteckna den förhandlade versionen, suiten och datachiffern i ändringsärendet. Nästa person som möter ett TLS-fel börjar vid den anteckningen i stället för vid en chiffersträng från ett foruminlägg.