Jaettu DH-ryhmä, tuoreet salaisuudet: miksi hyökkäys halpenee
Tuoreet istuntosalaisuudet eivät korjaa heikkoa äärellisen kunnan ryhmää. Yhden ryhmän uudelleenkäyttö jakaa hyökkäyksen kalleimman vaiheen jokaiselle sitä neuvottelevalle vaihdolle.
Ryhmän parametrit ovat suunnittelultaan julkisia, ja juuri se julkisuus tekee niistä helposti sivuutettavia. Äärellisen kunnan Diffie-Hellmanissa moduuli ja generaattori ovat yhteisiä, mutta yksityiset eksponentit ja niistä syntyvät istuntoavaimet eivät ole. Lukukenttäseulan hyökkäyksen kallis vaihe riippuu ryhmästä eikä yhdestä vaihdosta, joten yksi kaikkialla käytetty heikko ryhmä muuttuu yhteiseksi vastuuksi. Parametrien kutsuminen julkisiksi on täsmällistä ja asian vierestä, koska uudelleen käytetty kustannus on juuri tuon ryhmän hyökkäämisen kustannus.
Julkinen puolisko ei ole haavoittuva puolisko, ja siinä on ansa
Tavallinen puoliargumentti sanoo, että parametrit on julkaistu standardissa, joten hyökkääjä tuntee ne jo eikä niiden piilottaminen muuttaisi mitään. Molemmat väitteet pitävät paikkansa, eikä kumpikaan seuraa toisesta. Mukana toimitettava oletusryhmä on julkinen, ja viime viikolla luomasi yksityinen ryhmä on myös näkyvissä kenelle tahansa, joka saa kättelyn valmiiksi. Salaisuus ei koskaan ollut se hallintakeino; vahvuus ja validointi ovat.
Mikä muuttuu, on se, kuinka moni paikka jakaa saman heikkouden. Yksi organisaatio, joka luo oman 2048-bittisen ryhmänsä, maksaa oman hyökkäyskustannuksensa, kun taas miljoonien valitsema protokollan oletusarvo jakaa yhden kustannuksen kaikkien kesken. Siinä mielessä epätavallinen ryhmä ei ole automaattisesti parempi. Liian pieni epätavallinen ryhmä on vain pienempi yhteinen salaisuus, jonka päällä on vähemmän silmiä.
Validointi on yhtä tärkeää kuin koko. Vastapuoli, joka lähettää moduulin pienillä tekijöillä tai moduulin, joka ei ole protokollan odottamassa muodossa, voi vuotaa tietoa yksityisestä eksponentista, vaikka bittipituus näyttäisi kunnioitettavalta. Kirjastot, jotka hylkäävät virheelliset parametrit jo sisääntulossa, tekevät todellista työtä, ja siksi käsin kirjoitettu parametrien jäsennys on huono paikka säästää vaivaa.
Mitä esilaskenta todella antaa hyökkääjälle
Lukukenttäseulalla on vaihe, joka riippuu vain alkuluvusta, ja sen tulos on uudelleenkäytettävissä jokaista vaihtoa vastaan, joka käyttää tuota alkulukua. Siinä on koko historiallisen huolen mekanismi: kallis osa maksetaan kerran ja jokaisen seuraavan istunnon rajakustannus laskee. Tuoreet eksponentit suojaavat edelleen jokaista yksittäistä vaihtoa passiiviselta tarkkailijalta, kunhan ryhmä on tarpeeksi suuri, jotta seulonta on mahdotonta. Molemmat väitteet ovat yhteensopivia, ja suurin osa aiheen väittelyistä syntyy siitä, että valitaan toinen ja pudotetaan toinen.
Vuoden 2015 Logjam-työ osoitti alentamisen 512-bittiseen vientitason Diffie-Hellmaniin ja arvioi, mitä suurempien, laajalti uudelleenkäytettyjen ryhmien hyökkääminen merkittävillä resursseilla maksaisi. Esittely oli konkreettinen, arviot olivat arvioita, eikä kumpikaan ollut todiste siitä, että jokin tietty VPN-istunto olisi purettu.
Viittaa työhön mekanismin ja osoitetun alentamisen vuoksi, ei oman käyttöönoton mittauksena. Vanhat tilastot siitä, kuinka moni palvelin jakoi oletusryhmän, kuvaavat sen vuoden internettiä, eivät verkkoa, jonka voit tarkastaa tänään. Hyödyllinen siirrettävä asia on kysymys: neuvottelevatko laitteesi yhä ryhmästä, joka on pieni tai heikosti validoitu?
Standardoitu ei ole sama kuin heikko
RFC 7919 määrittelee nimetyt äärellisen kunnan ryhmät, jotta molemmat päät sopivat ryhmästä tunnisteen perusteella ja soveltavat johdonmukaista käytäntöä. Standardoitu oleminen on etu, koska se poistaa neuvottelun epäselvyyden ja antaa toteutuksen hylätä tukemattomat koot. Nimetty ryhmä on heikko vain silloin, kun sen koko on sen käytännön alapuolella, jota väität noudattavasi, ei siksi, että se esiintyy asiakirjassa. Sama logiikka pätee elliptisten käyrien ryhmiin, joilla on erilainen rakenne ja erilaiset vikatilat.
Pidä rakennelmat erillään, kun pohdit niitä. Johtopäätös äärellisen kunnan Diffie-Hellmanista ei kerro mitään X25519:stä, eikä johtopäätös 1024-bittisestä MODP-ryhmästä kerro mitään 3072-bittisestä. Vahvuuskäytäntö on mekanismi-, koko- ja protokollaversiokohtainen, ja siksi lause vahva salaus ei ole tarkistettavissa oleva väite.
Todennus on toinen puolisko, eikä se korvaa. Vahva ryhmä ilman vastapuolen varmennusta jättää hyökkääjän väliin, eikä kelvollinen varmenne pelasta 768-bittistä vaihtoa. Tarkastele niitä kahtena riippumattomana linjana ja vahvista sitten, että molemmat todella neuvotellaan.
Lue neuvoteltu ryhmä todellisesta yhteydestä
Lue neuvoteltu ryhmä laitteesta, älä kokoonpanomallista. Mallit kuvaavat aikomusta, ja kiinnostava arvo on se, josta molemmat päät sopivat viimeisessä kättelyssä. IPsec-päätepisteessä tilatuloste tulostaa yleensä valitun ehdotuksen, mukaan lukien MODP-ryhmän.
Tallenna tuo rivi ennen käytännön muutosta ja sen jälkeen, ja pidä molemmat muutosmerkinnässä. Vertailu on todiste.
ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -nooutJos tila näyttää muutoksen jälkeen yhä vanhan ryhmän, yhteys ei neuvotellut uudelleen eikä kokoonpanon muutos todistanut mitään. Käynnistä vastapuoli uudelleen tai tyhjennä tietoturvayhdistys ja lue tila sitten uudelleen. Käytäntö, jota valvotaan vain uusilla yhteyksillä, jättää pitkäikäiset tunnelit vanhoille parametreille niin kauan kuin ne pysyvät pystyssä.
Tarkista ryhmä ja vastapuolen identiteetti erikseen
Erottele se, mitä ryhmä suojaa, siitä, kuka on toisessa päässä. Kirjaa avaintenvaihtomenetelmä, ryhmän koko ja todennusmenetelmä kolmeksi kentäksi, koska ne epäonnistuvat riippumattomasti. Tunneli, joka neuvotteli 3072-bittisen ryhmän mutta hyväksyy minkä tahansa varmenteen, ei ole sama riski kuin se, joka kiinnittää vastapuolen ja käyttää 2048-bittistä ryhmää.
Kirjoita hyväksymiskriteerit ennen tarkastuksen alkua, jotta tulos on vertailu eikä mielipide. Vähimmäisryhmäkoko protokollaversiota kohden, nimettyjen ryhmien sallittujen luettelo ja pakollinen vastapuolen varmennus riittävät tekemään päätöksestä mekaanisen. Epäselvyys tuossa luettelossa muuttaa tarkastuksen väittelyksi, eikä väittelyjä korjata. Silloin tuloste on luettelo päätepisteistä, jotka rikkovat ilmoitettua sääntöä.
ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'Sulje kehä lukemalla neuvotellut arvot uudelleen korjauksen jälkeen. Vaatimustenmukainen kokoonpanotiedosto ei ole todiste siitä, että tunneli otti sen käyttöön. Tilatuloste ja yksi tuore kättely ovat todiste, ja niiden kerääminen vie vähemmän aikaa kuin kokous siitä, tarvitaanko niitä.