Vad openssl dhparam -check bekräftar, och vad den missar
En godkänd parameterkontroll är inte en säkerhetsgranskning. Se vad den bevisar om din DH-fil, hur du läser gruppstorleken och hur du undviker att generera om.
Att klara dhparam -check känns som en dom över Diffie-Hellman-inställningen för din VPN. Det är det inte. Kommandot jämför en parameterfil med den aritmetik den påstår sig uppfylla, och det säger ingenting om gruppstorleken passar din policy eller om tunneln ens laddar filen. Att läsa det som en säkerhetsgranskning är antagandet som är värt att rätta först.
En parameterfil innehåller ett primtal och en generator. Giltighet är en egenskap hos talen, medan styrka är en bedömning av din hotmodell och dina motparter, och de två är inte utbytbara.
Vad giltighetskontrollen faktiskt bekräftar
Kör kontrollen på filen du har och läs svaret. openssl dhparam -in dh.pem -check -noout utför parameterkontrollerna och undertrycker den kodade utdatan. Ett meddelande om att parametrarna verkar okej betyder att värdena är strukturellt konsekventa; det betyder inte att en kort grupp är acceptabel i din miljö.
Generering utan -dsaparam ger säkra primtal, där (p-1)/2 också är primtal, och därför tar det så lång tid. DSA-stilens väg bygger parametrar snabbare och omvandlar dem till DH-form, och OpenSSL-handboken knyter extra krav på färska nycklar till användningen av dem. Ingen av konstruktionerna är en sessionshemlighet: filen är offentligt konfigurationsmaterial, inte certifikatets privata nyckel och inte kontrollkanalens delade hemlighet.
Läs storlek och generator innan du bedömer filen
Ett giltighetsresultat betyder mer när du vet vad som validerades. Skriv ut parametrarna med openssl dhparam -in dh.pem -text -noout och notera sedan primtalslängden och generatorvärdet.
Jämför den längden med en skriftlig policy i stället för med en vana. Om ditt krav är en godkänd namngiven grupp från en modern TLS-stack kan en handgenererad fil vara helt fel artefakt. Skriv båda talen i ändringsloggen så att nästa granskare inte behöver härleda dem igen.
Gör inte en inspektion till en ny generering
Felläget här är ett kommando som ser ut som en kontroll och beter sig som en generator. Att lägga till en bitlängd, som i openssl dhparam -check 2048, ber om nya parametrar och indatafilen ignoreras. Ett generatoralternativ kan göra samma sak. Om du bara ville inspektera, ge -in och -check och ingenting som beskriver en storlek.
Att skriva utdata över den ursprungliga sökvägen förtjänar samma misstänksamhet, eftersom handboken varnar för att filutdata inte är atomär. En krasch mitt i skrivningen lämnar en avkortad parameterfil och en tjänst som inte startar.
Anpassa gruppen till protokollet, inte till en trend
Storlekspolicy är ett beslut som verktyget inte kan läsa åt dig. En ändlig-fält-grupp på 2048 bitar är en vanlig nedre gräns och större grupper kostar handskakningstid, så välj talet som din egen baslinje anger och skriv ner det. Flitigt använda grupper är inte svaga för att de är offentliga; okändhet tillför ingenting här.
Där stacken stöder godkända namngivna grupper, följ den dokumenterade ordningen i stället för att generera ovanliga parametrar för att de ska se unika ut. En namngiven grupp är något en motpart kan känna igen och en granskare kan slå upp, vilket är värt mer än en skräddarsydd fil som ingen kan klassificera.
Bekräfta att VPN:en överhuvudtaget laddar filen
En korrekt parameterfil som ingen process läser ändrar ingenting. I OpenVPN är serverdirektivet dh med en sökväg, och driftsättningar som förlitar sig på ECDH eller TLS 1.3-nyckelutbyte kan i stället sätta dh none. Kontrollera den körande konfigurationen i stället för en mall och bekräfta sedan att klienter och motparter förhandlar samma konstruktion.
Stäng cirkeln med de bevis du faktiskt behöver: gruppen som tunneln förhandlade, parameterns längd i filen och den policylinje som längden uppfyller. En godkänd kontroll hör hemma på listan som en enda post. Att behandla den som hela svaret är hur en kort grupp överlever en granskning som skulle ha fångat den.