Gedeelde DH-groep, verse geheimen: waarom de aanval goedkoper wordt

Groepsparameters zijn per ontwerp openbaar, en juist die openbaarheid maakt ze makkelijk te negeren. Bij Diffie-Hellman over een eindig veld zijn de modulus en de generator gedeeld, terwijl de privé-exponenten en de resulterende sessiesleutels dat niet zijn. De dure fase van een aanval met een getallenveldzeef hangt van de groep af en niet van één uitwisseling, dus één zwakke groep die overal wordt gebruikt, wordt een gedeelde last. De parameters openbaar noemen is juist en naast de kwestie, want de kosten die worden hergebruikt, zijn de kosten van een aanval op precies die groep.

De openbare helft is niet de kwetsbare helft, en daar zit de valkuil

Het gebruikelijke halve argument zegt dat de parameters in een standaard zijn gepubliceerd, dus een aanvaller kent ze al en ze verbergen zou niets veranderen. Beide beweringen zijn waar en geen van beide volgt uit de andere. Een meegeleverde standaardgroep is openbaar, en een privégroep die u vorige week hebt gegenereerd, is ook zichtbaar voor iedereen die de handdruk voltooit. Geheimhouding was nooit de controle; sterkte en validatie zijn dat.

Wat verandert, is hoeveel plaatsen dezelfde zwakte delen. Eén organisatie die zijn eigen 2048-bitsgroep genereert, betaalt zijn eigen aanvalskosten, terwijl een protocolstandaard gekozen door miljoenen één kostenpost over hen allen amortiseert. In die zin is een ongebruikelijke groep niet automatisch beter. Een ongebruikelijke groep die te klein is, is niets meer dan een kleiner gedeeld geheim met minder ogen erop.

Validatie is net zo belangrijk als grootte. Een peer die een modulus met kleine factoren stuurt, of een die niet de vorm heeft die het protocol verwacht, kan informatie over de privé-exponent lekken, zelfs wanneer de bitlengte respectabel lijkt. Bibliotheken die misvormde parameters bij de ingang weigeren, doen echt werk, en daarom is handgeschreven parameterparsing een slechte plek om inspanning te besparen.

Wat de voorberekening een aanvaller werkelijk oplevert

De getallenveldzeef heeft een fase die alleen van het priemgetal afhangt, en de uitvoer is herbruikbaar tegen elke uitwisseling die dat priemgetal gebruikt. Dat is het hele mechanisme achter de historische zorg: het dure deel wordt één keer betaald, en de marginale kosten van elke volgende sessie dalen. Verse exponenten beschermen nog steeds elke afzonderlijke uitwisseling tegen een passieve waarnemer, zolang de groep groot genoeg is om het ziften onuitvoerbaar te maken. De twee uitspraken zijn verenigbaar, en de meeste discussies over dit onderwerp komen voort uit het kiezen van de ene en het laten vallen van de andere.

Het Logjam-artikel uit 2015 demonstreerde een downgrade naar 512-bits exportkwaliteit-Diffie-Hellman en schatte wat het zou kosten om grotere, breed hergebruikte groepen met aanzienlijke middelen aan te vallen. De demonstratie was concreet, de schattingen waren schattingen, en geen van beide was bewijs dat een bepaalde VPN-sessie was ontsleuteld.

Citeer het artikel voor het mechanisme en voor de aangetoonde downgrade, niet als een meting van uw uitrol. Oude statistieken over hoeveel servers een standaardgroep deelden, beschrijven het internet van dat jaar, niet een netwerk dat u vandaag kunt inspecteren. Wat de moeite waard is om mee te nemen, is de vraag: onderhandelen uw apparaten nog steeds een groep die klein of zwak gevalideerd is?

Gestandaardiseerd is niet hetzelfde als zwak

RFC 7919 definieert benoemde groepen over een eindig veld, zodat beide kanten het eens worden over een groep via een identificatie en een consistent beleid toepassen. Gestandaardiseerd zijn is een voordeel, omdat het de dubbelzinnigheid van de onderhandeling wegneemt en een implementatie niet-ondersteunde groottes laat weigeren. Een benoemde groep is alleen zwak wanneer de grootte onder het beleid zit dat u zegt te volgen, niet omdat hij in een document voorkomt. Dezelfde logica geldt voor elliptische-krommegroepen, die een andere structuur en andere faalmodi hebben.

Houd de constructies gescheiden wanneer u erover redeneert. Een conclusie over Diffie-Hellman over een eindig veld zegt niets over X25519, en een conclusie over een 1024-bits MODP-groep zegt niets over een van 3072 bits. Sterktebeleid is per mechanisme, per grootte en per protocolversie, en daarom is de zin sterke cryptografie geen toetsbare bewering.

Authenticatie is de andere helft, en die vervangt niet. Een sterke groep zonder peer-verificatie laat een aanvaller in het midden, en een geldig certificaat kan een 768-bits uitwisseling niet redden. Beoordeel ze als twee onafhankelijke lijnen en bevestig daarna dat beide echt worden onderhandeld.

Lees de onderhandelde groep op een echte verbinding

Lees de onderhandelde groep van het apparaat en niet uit de configuratiesjabloon. Sjablonen beschrijven de bedoeling, en de interessante waarde is die waar beide kanten het tijdens de laatste handdruk over eens werden. Op een IPsec-eindpunt drukt de statusuitvoer meestal het gekozen voorstel af, inclusief de MODP-groep.

Leg die regel vast vóór en na een beleidswijziging, en bewaar beide in het wijzigingsrecord. De vergelijking is het bewijs.

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

Als de status na de wijziging nog de oude groep toont, heeft de verbinding niet opnieuw onderhandeld en heeft de configuratiewijziging niets bewezen. Herstart de peer of wis de beveiligingsassociatie en lees de status daarna opnieuw. Een beleid dat alleen op nieuwe verbindingen wordt toegepast, laat langlevende tunnels op de oude parameters staan zolang ze actief zijn.

Controleer de groep en de identiteit van de peer apart

Scheid wat de groep beschermt van wie er aan de andere kant zit. Registreer de sleuteluitwisselmethode, de groepsgrootte en de authenticatiemethode als drie velden, omdat ze onafhankelijk falen. Een tunnel die een 3072-bitsgroep heeft onderhandeld maar elk certificaat accepteert, is niet hetzelfde risico als een die een peer vastzet en een 2048-bitsgroep gebruikt.

Schrijf de acceptatiecriteria op voordat de beoordeling begint, zodat het resultaat een vergelijking is en geen mening. Een minimale groepsgrootte per protocolversie, een lijst met toegestane benoemde groepen en verplichte peer-verificatie zijn genoeg om de beslissing mechanisch te maken. De dubbelzinnigheid in die lijst is wat een beoordeling in een discussie verandert, en discussies worden niet hersteld. Dan is de uitvoer een lijst met eindpunten die een gestelde regel niet halen.

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

Sluit de cirkel door de onderhandelde waarden na de herstelling opnieuw te lezen. Een conforme configuratiebestand is geen bewijs dat een tunnel het heeft overgenomen. De statusuitvoer en één nieuwe handdruk zijn het bewijs, en ze verzamelen kost minder tijd dan de vergadering over de vraag of ze nodig zijn.