Delt DH-gruppe, friske hemmeligheder: hvorfor angrebet bliver billigere

Gruppeparametre er offentlige af design, og netop den offentlighed gør dem lette at overse. I Diffie-Hellman over et endeligt felt er modulus og generator delt, mens de private eksponenter og de resulterende sessionsnøgler ikke er. Angrebets dyre fase med et talsigte afhænger af gruppen og ikke af én udveksling, så én svag gruppe brugt overalt bliver et fælles ansvar. At kalde parametrene offentlige er præcist og uden betydning, fordi den omkostning, der genbruges, er omkostningen ved at angribe netop den gruppe.

Den offentlige halvdel er ikke den sårbare halvdel, og det er fælden

Det sædvanlige halve argument siger, at parametrene er offentliggjort i en standard, så en angriber kender dem allerede, og at skjule dem ikke ville ændre noget. Begge led er sande, og ingen af dem følger af det andet. En medsendt standardgruppe er offentlig, og en privat gruppe, du genererede i sidste uge, er også synlig for enhver, der fuldfører håndtrykket. Hemmeligholdelse var aldrig kontrollen; styrke og validering er.

Det, der ændrer sig, er hvor mange steder der deler den samme svaghed. Én organisation, der genererer sin egen 2048-bitgruppe, betaler sin egen angrebsomkostning, mens et protokolstandardvalg valgt af millioner amortiserer én omkostning over dem alle. Det er i den forstand, at en ualmindelig gruppe ikke automatisk er bedre. En usædvanlig gruppe, der er for lille, er blot en mindre fælles hemmelighed med færre øjne på sig.

Validering betyder lige så meget som størrelse. En peer, der sender et modulus med små faktorer, eller et der ikke har den form, protokollen forventer, kan lække information om den private eksponent, selv når bitlængden ser respektabel ud. Biblioteker, der afviser fejlbehæftede parametre ved indgangen, gør et rigtigt arbejde, og derfor er håndskrevet parameterparsing et dårligt sted at spare kræfter.

Hvad forudberegningen egentlig giver en angriber

Talsigtet har en fase, der kun afhænger af primtallet, og dets output kan genbruges mod hver udveksling, der bruger det primtal. Det er hele mekanismen bag den historiske bekymring: den dyre del betales én gang, og marginalomkostningen for hver yderligere session falder. Friske eksponenter beskytter stadig hver enkelt udveksling mod en passiv observatør, så længe gruppen er stor nok til at gøre sigtningen uigennemførlig. De to udsagn er forenelige, og de fleste diskussioner om emnet kommer af at vælge det ene og droppe det andet.

Logjam-artiklen fra 2015 demonstrerede en nedgradering til 512-bit eksportgrad-Diffie-Hellman og estimerede, hvad det ville koste at angribe større, bredt genbrugte grupper med betydelige ressourcer. Demonstrationen var konkret, estimaterne var estimater, og ingen af dem var bevis for, at en bestemt VPN-session var blevet dekrypteret.

Citér artiklen for mekanismen og for den demonstrerede nedgradering, ikke som en måling af din udrulning. Gamle statistikker om, hvor mange servere der delte en standardgruppe, beskriver datidens internet, ikke et netværk, du kan undersøge i dag. Det nyttige, der følger med, er spørgsmålet: forhandler dine enheder stadig en gruppe, der er lille eller svagt valideret?

Standardiseret er ikke det samme som svag

RFC 7919 definerer navngivne grupper i endelige felter, så begge ender bliver enige om en gruppe ved hjælp af en identifikator og anvender en ensartet politik. At være standardiseret er en fordel, fordi det fjerner uklarhed i forhandlingen og lader en implementering afvise ikke-understøttede størrelser. En navngivet gruppe er kun svag, når dens størrelse ligger under den politik, du påstår at følge, ikke fordi den optræder i et dokument. Den samme logik gælder for elliptiske kurvegrupper, som har en anden struktur og andre fejltilstande.

Hold konstruktionerne adskilt, når du ræsonnerer om dem. En konklusion om Diffie-Hellman over et endeligt felt siger intet om X25519, og en konklusion om en 1024-bit MODP-gruppe siger intet om en 3072-bit en. Styrkepolitik er pr. mekanisme, pr. størrelse og pr. protokolversion, og derfor er sætningen stærk krypto ikke et efterprøvbart udsagn.

Autentificering er den anden halvdel, og den erstatter ikke. En stærk gruppe uden peer-verifikation efterlader en angriber i midten, og et gyldigt certifikat kan ikke redde en 768-bit udveksling. Gennemgå dem som to uafhængige linjer, og bekræft derefter, at begge faktisk forhandles.

Læs den forhandlede gruppe på en rigtig forbindelse

Læs den forhandlede gruppe fra enheden i stedet for fra konfigurationsskabelonen. Skabeloner beskriver hensigt, og den interessante værdi er den, begge parter blev enige om under det sidste håndtryk. På et IPsec-endepunkt udskriver statusoutputtet normalt det valgte forslag, inklusive MODP-gruppen.

Fang den linje før og efter en politikændring, og gem begge i ændringsloggen. Sammenligningen er beviset.

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

Hvis status stadig viser den gamle gruppe efter ændringen, har forbindelsen ikke genforhandlet, og konfigurationsændringen beviste intet. Genstart peer'en, eller ryd sikkerhedsassociationen, og læs derefter status igen. En politik, der kun håndhæves på nye forbindelser, vil efterlade langlivede tunneler på de gamle parametre, så længe de er oppe.

Kontrollér gruppen og peer-identiteten hver for sig

Adskil, hvad gruppen beskytter, fra hvem der er i den anden ende. Registrér nøgleudvekslingsmetoden, gruppestørrelsen og autentificeringsmetoden som tre felter, fordi de fejler uafhængigt. En tunnel, der forhandlede en 3072-bitgruppe, men accepterer ethvert certifikat, er ikke den samme risiko som en, der pinner en peer og bruger en 2048-bitgruppe.

Skriv acceptkriterierne ned, før gennemgangen begynder, så resultatet er en sammenligning og ikke en mening. En minimumsgruppestørrelse pr. protokolversion, en tilladelsesliste for navngivne grupper og obligatorisk peer-verifikation er nok til at gøre beslutningen mekanisk. Uklarhed på den liste er det, der gør en gennemgang til en diskussion, og diskussioner bliver ikke udbedret. Så er outputtet en liste over endepunkter, der fejler en angivet regel.

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

Luk kredsen ved at læse de forhandlede værdier igen efter udbedringen. En overensstemmende konfigurationsfil er ikke bevis for, at en tunnel har taget den til sig. Statusoutputtet og ét friskt håndtryk er beviset, og det tager mindre tid at indsamle dem end mødet om, hvorvidt de er nødvendige.