8192-bitars nycklar stoppar handskakningen; DH på 1024 bitar avvisas

På en server hänger klienter ett tag och återansluter sedan, och en annan avvisar anslutningar direkt med ett meddelande om nyckelstorlek. De ser ut som olika fel och det är samma fel som pekar i motsatta riktningar. Handskakningskryptografi har en kostnad som växer med parameterstorleken, och den har också ett golv som moderna bibliotek inte går under. Att dimensionera materialet är checklistan, och första punkten är att avgöra vilket av de två felen du faktiskt har.

Läs felet innan du genererar något igen

Tidpunkten säger det mesta. En handskakning som tar flera sekunder och sedan dör betyder oftast att beräkningen överlevde motpartens tålamod, vilket pekar på parametrar som är för stora för hårdvaran eller för tidsgränsen. En omedelbar avvisning som namnger en nyckel- eller gruppstorlek pekar åt andra hållet, mot material som biblioteket inte alls tar emot.

Dessa två behöver motsatta rättelser, och det är här de flesta försök går fel. Att generera 8192-bitars parametrar på nytt på en klient som redan avvisat en liten grupp förvärrar det långsamma fallet utan att göra något för det snabba. Skriv ner vilket symptom du såg innan du rör en fil.

Kontrollera sedan vad motparten ombeds göra. En server konfigurerad för en stor grupp i ett ändligt fält tvingar varje klient att spendera samma CPU-tid vid varje omförhandling, inte bara vid anslutning. Om problemet dyker upp med ett fast intervall i stället för vid start är det intervallet en stark ledtråd till vilken inställning som är dyr. Omförhandlingen upprepar hela beräkningen, så en avstängning som återkommer varje timme är oftast samma kostnad som betalas igen.

Det långsamma fallet: material som hårdvaran inte har råd med

Arbetet med Diffie-Hellman och RSA växer snabbt med nyckelstorleken, och allt sker innan någon trafik flyter genom tunneln. På en liten router eller en klient med låg effekt kan en tillräckligt stor grupp skjuta utbytet förbi andra sidans tidsgräns, så anslutningen försöker igen eller verkar helt enkelt hänga utan något fel.

Rättelsen är att gå ner till en storlek som varje motpart stöder och varje enhet kan beräkna bekvämt. En RSA-nyckel på 2048 bitar och en grupp på 2048 bitar är fortfarande en brett kompatibel baslinje; större hjälper bara när alla parter är överens och CPU:n kan betala för det vid varje omförhandling. Allt över den baslinjen är en medveten avvägning, inte en uppgradering.

Storlek är inte poäng, och det största talet i en jämförelsetabell är inte automatiskt rätt val. Välj det minsta värde som din policy tillåter och alla motparter accepterar, och mät sedan handskakningen i stället för att anta att den blev bättre. En mindre grupp som fortfarande går ut på tid berättar att storleken aldrig var hela historien.

Det snabba fallet: en grupp som biblioteket avvisar

Moderna OpenSSL-byggen avvisar de minsta grupperna i ändliga fält direkt, och en höjd säkerhetsnivå skjuter golvet ännu högre. Router-firmware som bär med sig en decennier gammal parameterfil är den vanliga källan, och symptomet är en anslutning som misslyckas direkt med ett meddelande som namnger gruppen eller nyckelstorleken. Inget i det felet är periodiskt, och det är just det som gör det lätt att känna igen.

Ersätt filen i stället för att redigera konfigurationen för att hoppa över kontrollen. Generera en aktuell grupp, validera den och installera den sedan där daemonen faktiskt läser den. Behåll den gamla filen tills en klient har anslutit med den nya:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

Kontrollkommandot validerar filen och skriver inget användbart när den går igenom; listningen bekräftar att du ersatte filen som tjänsten läser in, inte en inaktuell kopia bredvid. Peka konfigurationen mot den sökvägen, starta om daemonen och bekräfta att en klient som tidigare misslyckades nu slutför handskakningen.

Om servern också sätter en säkerhetsnivå eller en certifikatprofil, läs dem innan du drar slutsatsen att gruppen var fel. En profil som kräver en strängare klass kan avvisa material som standardvärdet skulle ha accepterat, och att ta bort den inställningen är en snävare ändring än att stänga av kontrollen globalt.

Välj en storlek för motparten och hårdvaran

Ta reda på vad den bortre änden tål innan du genererar något exotiskt. En enhet som är för gammal för en grupp på 2048 bitar är en enhet att byta ut, eftersom att peka servern mot en svagare grupp bara förvandlar ett kompatibilitetsklagomål till ett avbrott. Varaktiga rättelser rör sig mot nyare programvara, inte äldre parametrar. Varje tillfälligt undantag på det här området har en tendens att bli den permanenta konfigurationen.

Där serverns CPU är gränsen, ändra algoritmen i stället för att gå under policyn. Ett nyckelutbyte med elliptisk kurva som X25519 är dramatiskt billigare än en stor grupp i ett ändligt fält och stöds brett, vilket gör det till ett bättre svar på ett prestandaklagomål än en mindre RSA-modul.

Vad du än väljer, testa med en riktig anslutning och se hur lång tid handskakningen tar, inte bara om den till slut ansluter. En anslutning som lyckas på tolv sekunder har samma grundorsak som en som misslyckas på femton.

Skriv ner valet så att en återuppbyggnad inte kan upphäva det

Håll parameterfilen under konfigurationshantering och skriv storleken, orsaken och datumet bredvid. En återuppbyggd server som tyst genererar sina egna standardvärden är hur samma fel återkommer sex månader senare utan att någon kan förklara det ursprungliga beslutet.

Skriv samma information bredvid slutpunkten och profilen, så att en granskning inte behöver rekonstruera den från en filstorlek. När nästa anslutning hänger är den anteckningen skillnaden mellan en femminuterskontroll och en ny utredning. Det hindrar också nästa ingenjör från att lösa det långsamma fallet med en rättelse som var avsedd för det snabba.