Delad DH-grupp, färska hemligheter: varför attacken blir billigare

Gruppens parametrar är offentliga av design, och just den öppenheten gör dem lätta att förbise. I Diffie-Hellman över ett ändligt fält delas modulen och generatorn, medan de privata exponenterna och de resulterande sessionsnycklarna inte gör det. Den dyra fasen i en attack med talsikt beror på gruppen och inte på ett enda utbyte, så en enda svag grupp som används överallt blir en gemensam belastning. Att kalla parametrarna offentliga är korrekt och vid sidan av saken, eftersom den kostnad som återanvänds är kostnaden för att attackera just den gruppen.

Den offentliga halvan är inte den sårbara halvan, och där ligger fällan

Det vanliga halvargumentet säger att parametrarna publiceras i en standard, så en angripare känner redan till dem och att gömma dem inte skulle ändra något. Båda påståendena är sanna och inget av dem följer av det andra. En medföljande standardgrupp är offentlig, och en privat grupp som du genererade förra veckan är också synlig för alla som slutför handskakningen. Hemlighet var aldrig kontrollen; styrka och validering är det.

Det som ändras är hur många platser som delar samma svaghet. En organisation som genererar sin egen 2048-bitsgrupp betalar sin egen attackkostnad, medan ett protokollstandardval som miljontals väljer amorterar en enda kostnad över dem alla. I den meningen är en ovanlig grupp inte automatiskt bättre. En ovanlig grupp som är för liten är bara en mindre gemensam hemlighet med färre ögon på sig.

Validering spelar lika stor roll som storlek. En motpart som skickar en modul med små faktorer, eller en som inte har den form protokollet förväntar sig, kan läcka information om den privata exponenten även när bitlängden ser respektabel ut. Bibliotek som avvisar felaktiga parametrar vid ingången gör ett verkligt arbete, och därför är handskriven parameterparsning en dålig plats att spara kraft på.

Vad förberäkningen faktiskt ger en angripare

Talsikten har en fas som bara beror på primtalet, och dess utdata kan återanvändas mot varje utbyte som använder det primtalet. Det är hela mekanismen bakom den historiska oron: den dyra delen betalas en gång, och marginalkostnaden för varje ytterligare session sjunker. Färska exponenter skyddar fortfarande varje enskilt utbyte mot en passiv observatör, så länge gruppen är tillräckligt stor för att göra sikten ogenomförbar. De två påståendena är förenliga, och de flesta diskussioner i ämnet kommer av att välja det ena och släppa det andra.

Logjam-arbetet från 2015 demonstrerade en nedgradering till 512-bitars exportklass-Diffie-Hellman och uppskattade vad det skulle kosta att attackera större, brett återanvända grupper med betydande resurser. Demonstrationen var konkret, uppskattningarna var uppskattningar, och ingen av dem var bevis för att en viss VPN-session hade dekrypterats.

Citera arbetet för mekanismen och för den demonstrerade nedgraderingen, inte som en mätning av din utrullning. Gammal statistik om hur många servrar som delade en standardgrupp beskriver internet det året, inte ett nätverk du kan granska i dag. Det användbara som följer med är frågan: förhandlar dina enheter fortfarande en grupp som är liten eller svagt validerad?

Standardiserat är inte detsamma som svagt

RFC 7919 definierar namngivna grupper över ändliga fält, så att båda ändarna enas om en grupp via en identifierare och tillämpar en konsekvent policy. Att vara standardiserad är en fördel, eftersom det tar bort oklarheten i förhandlingen och låter en implementation avvisa storlekar som inte stöds. En namngiven grupp är svag bara när storleken ligger under den policy du säger dig följa, inte för att den förekommer i ett dokument. Samma logik gäller för elliptiska kurvgrupper, som har en annan struktur och andra felmoder.

Håll konstruktionerna åtskilda när du resonerar om dem. En slutsats om Diffie-Hellman över ett ändligt fält säger inget om X25519, och en slutsats om en 1024-bits MODP-grupp säger inget om en med 3072 bit. Styrkepolicy gäller per mekanism, per storlek och per protokollversion, och därför är uttalandet stark kryptografi inget granskningsbart påstående.

Autentisering är den andra halvan, och den ersätter inte. En stark grupp utan motpartskontroll lämnar en angripare i mitten, och ett giltigt certifikat kan inte rädda ett 768-bits utbyte. Granska dem som två oberoende linjer och bekräfta sedan att båda faktiskt förhandlas.

Läs den förhandlade gruppen på en verklig anslutning

Läs den förhandlade gruppen från enheten i stället för från konfigurationsmallen. Mallar beskriver avsikt, och det intressanta värdet är det som båda parter enades om under den senaste handskakningen. På en IPsec-ändpunkt skriver statusutdata vanligtvis ut det valda förslaget, inklusive MODP-gruppen.

Fånga den raden före och efter en policyändring, och behåll båda i ändringsloggen. Jämförelsen är beviset.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Om statusen fortfarande visar den gamla gruppen efter ändringen har anslutningen inte förhandlat om, och konfigurationsändringen bevisade ingenting. Starta om motparten eller rensa säkerhetsassociationen och läs sedan statusen igen. En policy som bara tillämpas på nya anslutningar lämnar långlivade tunnlar på de gamla parametrarna så länge de är uppe.

Kontrollera gruppen och motpartens identitet var för sig

Skilj det gruppen skyddar från vem som finns i andra änden. Registrera nyckelutbytesmetoden, gruppstorleken och autentiseringsmetoden som tre fält, eftersom de misslyckas oberoende av varandra. En tunnel som förhandlade en 3072-bitsgrupp men accepterar vilket certifikat som helst är inte samma risk som en som fäster en motpart och använder en 2048-bitsgrupp.

Skriv ned acceptanskriterierna innan granskningen börjar, så att resultatet blir en jämförelse och inte en åsikt. En minsta gruppstorlek per protokollversion, en tillåtelselista för namngivna grupper och obligatorisk motpartskontroll räcker för att göra beslutet mekaniskt. Oklarheten i den listan är det som förvandlar en granskning till en diskussion, och diskussioner åtgärdas inte. Då är utdata en lista över ändpunkter som bryter mot en angiven regel.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Slut cirkeln genom att läsa de förhandlade värdena igen efter åtgärden. En överensstämmande konfigurationsfil är inte bevis för att en tunnel har tagit den i bruk. Statusutdata och ett färskt handskakning är beviset, och att samla dem tar mindre tid än mötet om huruvida de behövs.