IPsec - IPsec

Internet protokoll csomag
Alkalmazási réteg
Szállítási réteg
Internet réteg
Linkréteg

A számítástechnikai , Internet Protocol Security ( IPsec ) egy biztonságos hálózati protokollkészlet , amely hitelesíti és titkosítja a csomagokat az adatok, hogy a biztonságos, titkosított kommunikáció két számítógép közötti több mint egy Internet Protocol hálózat. Ezt alkalmazzák a virtuális magánhálózatok (VPN).

Az IPsec protokollokat tartalmaz az ügynökök közötti kölcsönös hitelesítés létrehozására a munkamenet elején, és a munkamenet során használható titkosítási kulcsok egyeztetésére . Az IPsec védheti az adatáramlást egy pár gazdagép ( hoszt-hoszt ), egy pár biztonsági átjáró ( hálózat-hálózat ) között, vagy egy biztonsági átjáró és egy gazdagép ( hálózat-hoszt ) között. Az IPsec kriptográfiai biztonsági szolgáltatásokat használ az Internet Protocol (IP) hálózatokon keresztüli kommunikáció védelmére . Támogatja a hálózati szintű társhitelesítést, az adatok eredetének hitelesítését, az adatok integritását, az adatok bizalmasságát (titkosítását) és az ismétlésvédelmet.

A kezdeti IPv4 csomagot kevés biztonsági előírással fejlesztették ki. Az IPv4 fejlesztés részeként az IPsec egy 3. rétegű OSI modell vagy internetes réteg teljes körű biztonsági rendszer. Ezzel szemben, míg néhány más széles körben használt internetes biztonsági rendszer a 3. réteg felett működik, mint például a Transport Layer Security (TLS), amely a Transport Layer és a Secure Shell (SSH) felett működik, amely az Application rétegben működik, az IPsec automatikusan védheti az alkalmazásokat az IP réteg.

Történelem

A fejlett kutatási projektek ügynöksége az 1970 -es évek elejétől kezdve számos kísérleti ARPANET titkosítóeszközt szponzorált , először a natív ARPANET csomag titkosítására, majd a TCP/IP csomag titkosítására; ezek egy része hitelesített és pályázott. 1986 és 1991 között az NSA a Secure Data Network Systems (SDNS) program keretében támogatta az Internet biztonsági protokolljainak kidolgozását. Ez összehozta a különböző gyártókat, köztük a Motorolát, akik 1988 -ban hálózati titkosító eszközt állítottak elő. A munkát körülbelül 1988 -tól nyilvánosan közzétette a NIST, és ezek közül a Security Layer 3 (SP3) protokoll végül az ISO szabványú hálózati rétegbiztonsági protokollmá alakult. (NLSP).

1992 és 1995 között különböző csoportok kutattak az IP-réteg titkosításával kapcsolatban.

  • 1. 1992 -ben az amerikai haditengerészeti kutatólaboratórium (NRL) megkezdte az Simple Internet Protocol Plus (SIPP) projektet az IP -titkosítás kutatása és megvalósítása érdekében.
  • 2. 1993 -ban a Columbia Egyetemen és az AT&T Bell Labs -ban John Ioannidis és mások a SunOS -on futó szoftveres kísérleti Software IP Encryption Protocol (swIPe) protokollt kutatták .
  • 3. 1993 -ban, a Whitehouse internetszolgáltatási projekt támogatásával, Wei Xu, a Trusted Information Systems (TIS) tovább kutatta a szoftver IP biztonsági protokolljait, és kifejlesztette a hardveres támogatást a háromszoros DES Data Encryption Standard számára , amelyet a BSD 4.1 rendszermagban és támogatja az x86 és a SUNOS architektúrákat. 1994 decemberére a TIS kiadta a DARPA által támogatott nyílt forráskódú Gauntlet Firewall termékét, integrált 3DES hardveres titkosítással, T1 sebesség felett . Ez volt az első alkalom, hogy az IPSec VPN-kapcsolatokat használták az államok keleti és nyugati partjai között, az első kereskedelmi IPSec VPN-termékként.
  • 4. Az NRL DARPA által finanszírozott kutatási erőfeszítései keretében az NRL kifejlesztette az IETF szabványkövetési specifikációit (RFC 1825 -től RFC 1827 -ig) az IPsec -hez, amelyet a BSD 4.4 -es kernel kódolt, és támogatja az x86 és a SPARC CPU architektúrát. Az NRL IPsec megvalósítását az 1996 -os USENIX Conference Proceedings című cikkükben írták le. Az NRL nyílt forráskódú IPsec implementációját az MIT online elérhetővé tette, és a legtöbb kezdeti kereskedelmi megvalósítás alapjává vált.

Az Internet Engineering Task Force (IETF) 1992 -ben létrehozta az IP biztonsági munkacsoportot, hogy szabványosítsa az IPsec nevű nyíltan meghatározott biztonsági kiterjesztéseket . 1995 -ben a munkacsoport szervezett néhány műhelyt az öt vállalat (TIS, CISCO, FTP, Checkpoint stb.) Tagjaival. Az IPSec műhelymunkák során az NRL szabványait, valamint a Cisco és a TIS szoftvereit szabványosítják nyilvános hivatkozásokként, amelyeket RFC-1825 és RFC-1827 között publikálnak.

Biztonsági architektúra

Az IPsec egy nyílt szabvány az IPv4 csomag részeként. Az IPsec a következő protokollokat használja különböző funkciók végrehajtásához:

Hitelesítési fejléc

IPsec hitelesítési fejléc formátum használata alagút és szállítási módokban

A biztonsági hitelesítési fejlécet ( AH ) az Egyesült Államok Haditengerészeti Kutatólaboratóriumában fejlesztették ki a kilencvenes évek elején, és részben az IETF korábbi szabványainak az egyszerű hálózatkezelési protokoll (SNMP) 2. verziójának hitelesítésére irányuló munkájából származik. az IPsec protokollcsomag tagja. Az AH biztosítja a kapcsolat nélküli integritást a hash függvény és a titkos megosztott kulcs használatával az AH algoritmusban. Az AH az IP -csomagok hitelesítésével is garantálja az adatok eredetét . Opcionálisan egy sorszám megvédheti az IPsec csomag tartalmát az újrajátszási támadások ellen , a csúszóablak technikával és a régi csomagok elvetésével.

  • A IPv4 , AH megakadályozza opció-inszerciós támadások. Az IPv6 -ban az AH védi a fejlécbeillesztési támadásokat és az opcióbeillesztési támadásokat.
  • Az IPv4 -ben az AH védi az IP -hasznos terhelést és az IP -datagram minden fejlécmezőjét, kivéve a módosítható mezőket (azaz azokat, amelyek átvitel közben módosulhatnak), valamint az IP -beállításokat, például az IP -biztonsági opciót (RFC 1108). A megváltoztatható (és ezért nem hitelesített) IPv4 fejlécmezők a DSCP / ToS , ECN , Flags, Fragment Offset , TTL és Header Checksum .
  • Az IPv6- ban az AH védi az IPv6 alapfejlécének nagy részét, magát az AH-t, az AH után nem módosítható kiterjesztési fejléceket és az IP hasznos terhet. Az IPv6 fejléc védelme kizárja a módosítható mezőket: DSCP , ECN , Flow Label és Hop Limit.

Az AH közvetlenül az IP tetején működik, az 51 -es IP protokoll használatával .

A következő AH csomagdiagram bemutatja, hogyan épül fel és értelmezhető az AH csomag:

Hitelesítési fejléc formátum
Eltolások 16. oktett 0 1 2 3
16. oktett 10. bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Következő fejléc Hasznos teher Len Fenntartott
4 32 Biztonsági paraméterek indexe (SPI)
8 64 Sorszám
C 96 Integrity Check Value (ICV)
...
... ...
Következő fejléc (8 bit)
A következő fejléc típusa, amely jelzi, hogy milyen felső rétegű protokoll védett. Az érték az IP protokoll számok listájából származik .
Hasznos teher Len (8 bit)
Ennek a hitelesítési fejlécnek a hossza 4 oktettes egységekben, mínusz 2. Például a 4-es AH-érték egyenlő 3 × (32 bites rögzített hosszúságú AH mezők) + 3 × (32 bites ICV mezők)-2 és így AH 4 értéke 24 oktettet jelent. Bár a méretet 4 oktettes egységekben mérik, ennek a fejlécnek 8 oktett többszörösének kell lennie, ha IPv6 csomagban szállítják. Ez a korlátozás nem vonatkozik az IPv4 csomagban lévő hitelesítési fejlécekre .
Fenntartva (16 bit)
Fenntartva a későbbi használatra (addig minden nulla).
Biztonsági paraméterek indexe (32 bit)
Önkényes érték, amelyet (a cél IP -címmel együtt) a fogadó fél biztonsági társításának azonosítására használnak .
Sorozatszám (32 bit)
A monoton szigorúan növekvő sorszámmal (lépteti 1 minden elküldött csomag), hogy megakadályozzák az ismétléses támadásokat . Ha az újrajátszás észlelése engedélyezve van, a sorszámok soha nem kerülnek újra felhasználásra, mert új biztonsági társítást kell újratárgyalni, mielőtt a sorozatszámot a maximális érték fölé kívánják növelni.
Integrity Check Value (32 bit többszöröse)
Változó hosszúságú ellenőrző érték. Tartalmazhat padding, hogy összehangolja a területen, hogy egy 8-oktett határt IPv6 , vagy egy 4-oktett határát IPv4 .

Magával ragadó biztonsági hasznos teher

IPsec Encapsulating Security Payload (ESP) használata alagút- és szállítási módokban

Az IP Encapsulating Security Payload (ESP) a Tengerészeti Kutatólaboratóriumban , 1992 -ben, a DARPA által támogatott kutatási projekt részeként került kifejlesztésre , és az IETF SIPP munkacsoportja nyíltan tette közzé 1993 decemberében, a SIPP biztonsági kiterjesztéseként. Ez az ESP eredetileg az amerikai védelmi minisztérium SP3D protokolljából származik, nem pedig az ISO hálózati réteg biztonsági protokollból (NLSP). Az SP3D protokoll specifikációt a NIST az 1980 -as évek végén tette közzé , de az amerikai védelmi minisztérium Secure Data Network System projektje tervezte. Az Encapsulating Security Payload (ESP) az IPsec protokollcsomag tagja. Ez biztosítja eredetű hitelesség révén forrás hitelesítés , az adatok integritását keresztül hash függvények és titoktartási keresztül titkosítás védelem IP csomagokat . Az ESP támogatja a csak titkosítást és csak a hitelesítést is , de a hitelesítés nélküli titkosítást erősen nem ajánlott használni, mert nem biztonságos.

A hitelesítési fejléccel (AH) ellentétben az ESP szállítási módban nem biztosítja a teljes IP -csomag integritását és hitelesítését . Azonban, Alagút üzemmód , ahol a teljes eredeti IP csomag tokozott egy új csomag fejlécet hozzá, ESP védelmét a az egész belső IP-csomag (beleértve a belső fejléc), míg a külső header (beleértve a külső IPv4 beállítások vagy IPv6 meghosszabbítása fejlécek) védtelen marad. Az ESP közvetlenül az IP -n működik, az 50 -es IP protokoll használatával.

Az alábbi ESP csomagdiagram az ESP csomag felépítését és értelmezését mutatja be:

Lekötő biztonsági hasznos terhelési formátum
Eltolások 16. oktett 0 1 2 3
16. oktett 10. bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Biztonsági paraméterek indexe (SPI)
4 32 Sorszám
8 64 Hasznos adatok
... ...
... ...    
... ...   Párnázás (0-255 oktett)  
... ...   Pad hossza Következő fejléc
... ... Integrity Check Value (ICV)
...
... ...
Biztonsági paraméterek indexe (32 bit)
Önkényes érték (a cél IP -címmel együtt) a fogadó fél biztonsági társításának azonosítására .
Sorozatszám (32 bit)
A monoton növekvő sorszámmal (lépteti 1 minden elküldött csomag) elleni ismétléses támadásokat . Minden biztonsági egyesülethez külön számláló tartozik.
Hasznos adatok (változó)
Az eredeti IP -csomag védett tartalma, beleértve a tartalom védelmére használt adatokat (pl. Inicializációs vektor a kriptográfiai algoritmushoz). A védett tartalom típusát a Következő fejléc mező jelzi .
Párnázás (0-255 oktett)
Párnázás a titkosításhoz, a hasznos adatok terjesztése a titkosítás titkosítási blokkméretének megfelelő méretre, és a következő mező igazítása.
Pad hossza (8 bit)
A párna mérete (oktettben).
Következő fejléc (8 bit)
A következő fejléc típusa. Az érték az IP protokoll számok listájából származik .
Integrity Check Value (32 bit többszöröse)
Változó hosszúságú ellenőrző érték. Tartalmazhat padding, hogy összehangolja a területen, hogy egy 8-oktett határt IPv6 , vagy egy 4-oktett határát IPv4 .

Biztonsági egyesület

Fő cikk: Biztonsági szövetség

Az IPsec protokollok biztonsági társítást használnak , ahol a kommunikáló felek közös biztonsági attribútumokat, például algoritmusokat és kulcsokat hoznak létre . Mint ilyen, az IPsec számos lehetőséget kínál, miután megállapították, hogy AH vagy ESP kerül alkalmazásra. Adatcsere előtt a két gazda megegyezik, hogy melyik algoritmust használják az IP -csomag titkosítására, például DES vagy IDEA , és melyik kivonatfüggvényt használják az adatok integritásának biztosítására, például MD5 vagy SHA . Ezeket a paramétereket az adott munkamenetre vonatkozóan állapították meg, amelyhez egy élettartamot kell egyeztetni és egy munkamenetkulcsot .

A hitelesítés algoritmusáról is megállapodnak az adatátvitel előtt, és az IPsec számos módszert támogat. A hitelesítés előre megosztott kulccsal lehetséges , ahol egy szimmetrikus kulcs már mindkét gazda birtokában van, és a gazdagépek elküldik egymásnak a megosztott kulcs kivonatait annak igazolására, hogy ugyanazzal a kulccsal rendelkeznek. Az IPsec támogatja a nyilvános kulcsú titkosítást is , ahol minden gazdagép rendelkezik nyilvános és privát kulccsal, kicserélik nyilvános kulcsaikat, és minden gazdagép elküldi a másiknak a másik gazda nyilvános kulcsa által titkosított nonce -t . Alternatív megoldásként, ha mindkét gazdagép rendelkezik nyilvános kulcsú tanúsítvánnyal egy tanúsító hatóságtól , akkor ez használható az IPsec hitelesítéshez.

Az IPsec biztonsági egyesületei az Internet Security Association és a Key Management Protocol (ISAKMP) segítségével jönnek létre . Az ISAKMP-t manuális konfiguráció valósítja meg előre megosztott titkokkal, Internet Key Exchange (IKE és IKEv2), Kerberized Internet Negotiation of Keys (KINK) és az IPSECKEY DNS rekordok használata . Az RFC 5386 definiálja a semminél jobb biztonságot (BTNS) a hitelesített IPsec módként, kiterjesztett IKE protokoll használatával. C. Meadows, C. Cremers és mások formális módszerekkel azonosították az IKEv1 és az IKEv2 különböző anomáliáit.

Annak eldöntéséhez, hogy milyen védelmet kell biztosítani a kimenő csomag számára, az IPsec a biztonsági paraméterek indexét (SPI) használja, amely a biztonsági társítási adatbázis (SADB) indexe, valamint a csomagfejlécben található célcím, amely együttesen egyedileg azonosítja biztonsági egyesület az adott csomaghoz. Hasonló eljárást hajtanak végre egy bejövő csomag esetében is, ahol az IPsec visszafejtési és ellenőrzési kulcsokat gyűjt a biztonsági társítási adatbázisból.

Mert IP multicast biztonsági kapcsolódás biztosítja a csoport számára, és megkettőződik minden engedélyezett vevők a csoport. Egy csoporthoz több biztonsági társítás is tartozhat, különböző SPI -ket használva, ezáltal lehetővé téve egy csoporton belüli több szintű biztonságot. Valójában minden feladónak több biztonsági társítása is lehet, amelyek lehetővé teszik a hitelesítést, mivel a címzett csak azt tudja, hogy valaki, aki ismeri a kulcsokat, küldte az adatokat. Ne feledje, hogy a vonatkozó szabvány nem írja le a társítás kiválasztását és másolását a csoporton belül; feltételezzük, hogy egy felelős fél döntött.

Működési módok

Az AH és ESP IPsec protokollok gazdagép-szállítási módban, valamint hálózati alagút üzemmódban is megvalósíthatók.

IPsec módok

Szállítási mód

Szállítási módban általában csak az IP -csomag hasznos terhelése van titkosítva vagy hitelesítve. Az útválasztás sértetlen, mivel az IP fejléc nincs módosítva és nem titkosítva; Azonban, ha a hitelesítési fejlécet használ, az IP-címek nem módosítható a hálózati címfordítás , mivel ez mindig érvényteleníti a hash értéket . A szállítási és az alkalmazási rétegeket mindig egy kivonat védi, így semmilyen módon nem módosíthatók, például a portszámok lefordításával .

A NAT-T mechanizmust leíró RFC dokumentumok meghatározták az IPsec-üzenetek NAT-bejáráshoz való beágyazásának eszközét .

Alagút mód

Fő cikk: Alagút -protokoll

Alagút módban a teljes IP csomag titkosítva és hitelesítve van. Ezt követően egy új IP -csomagba zárják, új IP -fejléccel. Az alagút mód virtuális magánhálózatok létrehozására szolgál a hálózatok közötti kommunikációhoz (pl. Útválasztók és linkoldalak között), a gazdagépek közötti kommunikációhoz (pl. Távoli felhasználói hozzáférés) és a gazdagépek közötti kommunikációhoz (pl. Privát csevegés).

Az alagút mód támogatja a NAT bejárást.

Algoritmusok

Szimmetrikus titkosítási algoritmusok

Az IPsec -hez használható kriptográfiai algoritmusok a következők:

Részletek az RFC 8221 -ben.

Kulcscsere algoritmusok

Hitelesítési algoritmusok

Megvalósítások

Az IPsec egy operációs rendszer IP -veremében valósítható meg , amely a forráskód módosítását igényli. Ez a megvalósítási módszer a gazdagépek és a biztonsági átjárók esetében történik. Különféle IPsec -kompatibilis IP -kötegek állnak rendelkezésre vállalatoktól, például a HP -tól vagy az IBM -től. Egy alternatíva az úgynevezett bump-in-the-stack (BITS) megvalósítás, ahol az operációs rendszer forráskódját nem kell módosítani. Itt az IPsec telepítve van az IP verem és a hálózati illesztőprogramok között . Ily módon az operációs rendszerek utólag is felszerelhetők IPsec -el. Ezt a megvalósítási módszert használják mind a gazdagépek, mind az átjárók esetében. Az IPsec utólagos felszerelésekor azonban az IP -csomagok beágyazása problémákat okozhat az MTU automatikus útvonal -felderítésében , ahol a maximális átviteli egység (MTU) mérete a két IP -gazdagép közötti hálózati útvonalon meg van határozva. Ha egy állomásnak vagy átjárónak külön titkosítási processzora van , ami a hadseregben gyakori, és kereskedelmi rendszerekben is megtalálható, akkor lehetséges az IPsec úgynevezett bump-in-the-wire (BITW) megvalósítása.

Amikor az IPsec megvalósul a kernelben , a kulcskezelés és az ISAKMP / IKE egyeztetés felhasználói térből történik. Az NRL által kifejlesztett és nyíltan meghatározott "PF_KEY Key Management API, 2-es verzió" gyakran használható annak lehetővé tételére, hogy az alkalmazásterület-kulcskezelő alkalmazás frissítse a kernel-tér IPsec implementációban tárolt IPsec biztonsági társításokat. A meglévő IPsec implementációk általában ESP, AH és IKE 2. verziót tartalmaznak. A UNIX-szerű operációs rendszereken, például Solaris vagy Linux rendszeren, létező IPsec implementációk általában a PF_KEY 2. verziót tartalmazzák.

A beágyazott IPsec segítségével biztosítható a biztonságos kommunikáció korlátozott erőforrásrendszereken futó alkalmazások között, kis költséggel.

Szabványok állapota

Az IPsec-t az IPv6- al együtt fejlesztették ki, és eredetileg az összes szabványnak megfelelő IPv6 -implementációnak támogatnia kellett, mielőtt az RFC 6434 csak ajánlást tett. Az IPsec opcionális az IPv4 implementációkhoz is. Az IPsec -t leggyakrabban az IPv4 forgalom védelmére használják.

Az IPsec protokollokat eredetileg az RFC 1825 és az RFC 1829 között határozták meg, amelyeket 1995 -ben tettek közzé. 1998 -ban ezeket a dokumentumokat felváltotta az RFC 2401 és az RFC 2412, néhány összeegyeztethetetlen műszaki részlettel, bár fogalmilag megegyeztek. Ezenkívül kölcsönös hitelesítési és kulcscsere -protokoll Internet Key Exchange (IKE) került meghatározásra a biztonsági társítások létrehozásához és kezeléséhez. 2005 decemberében új szabványokat határoztak meg az RFC 4301 és az RFC 4309 szabványokban, amelyek jórészt a korábbi kiadások szuperkészlete, az IKEv2 Internet Key Exchange szabvány második verziójával . Ezek a harmadik generációs dokumentumok az IPsec rövidítését nagybetűsre „IP” és kis „sec” -re szabványosították. Az „ESP” általában az RFC 4303 -ra utal, amely a specifikáció legújabb verziója.

2008 közepe óta az IETF-en aktív az IPsec karbantartása és bővítései (ipsecme) munkacsoport.

Állítólagos NSA interferencia

2013 -ban, a Snowden -szivárgások részeként kiderült, hogy az Egyesült Államok Nemzetbiztonsági Ügynöksége a Bullrun program részeként aktívan dolgozott azon, hogy "sérülékenységeket illesszenek be a kereskedelmi titkosítási rendszerekbe, informatikai rendszerekbe, hálózatokba és célpontok által használt végpontkommunikációs eszközökbe". . Állítólag az IPsec célzott titkosítási rendszer volt.

Az OpenBSD IPsec verem később jött, és széles körben másolták is. Egy levélben, amelyet Theo de Raadt, az OpenBSD vezető fejlesztője kapott 2010. december 11 -én Gregory Perry -től, azt állítják, hogy Jason Wright és mások, az FBI -nak dolgozva, "számos hátsó ajtót és oldalsó csatorna kulcsszivárgási mechanizmust" illesztettek be az OpenBSD titkosításba kód. A 2010 -ben továbbított e -mailben Theo de Raadt először nem nyilvánított hivatalos álláspontot a követelések érvényességével kapcsolatban, eltekintve az e -mail továbbításából származó hallgatólagos jóváhagyástól. Jason Wright válasza az állításokra: "Minden városi legendát valóságosabbá tesz a valódi nevek, dátumok és idők felvétele. Gregory Perry e -mailje ebbe a kategóriába tartozik.… Világosan kijelentem, hogy nem adtam hozzá hátsó ajtókat az OpenBSD működéséhez rendszer vagy az OpenBSD titkosítási keretrendszer (OCF). " Néhány nappal később de Raadt megjegyezte, hogy "úgy gondolom, hogy a NETSEC valószínűleg szerződést kötött a hátsó ajtók írására, állítólag.… Ha ezeket írták, nem hiszem, hogy bejutottak a fánkba." Ezt a Snowden kiszivárogtatása előtt tették közzé.

A Logjam támadás szerzői által javasolt alternatív magyarázat azt sugallja, hogy az NSA veszélyeztette az IPsec VPN-eket, aláásva a kulcscserében használt Diffie-Hellman algoritmust. Dokumentumukban azt állítják, hogy az NSA kifejezetten számítástechnikai klasztert épített fel a multiplikatív alcsoportok előzetes kiszámításához bizonyos prímekhez és generátorokhoz, például az RFC 2409 -ben meghatározott második Oakley -csoporthoz. 2015 májusától a címezhető IPsec VPN -ek 90% -a támogatta a második Oakley -csoportot az IKE részeként. Ha egy szervezet előzetesen kiszámítaná ezt a csoportot, levezethetné a kicserélt kulcsokat, és dekódolhatná a forgalmat, anélkül, hogy bármilyen szoftveres hátsó ajtót beszúrna.

Egy másik alternatív magyarázat, amelyet előterjesztettek, az volt, hogy az Equation Group nulla napos kihasználást használt több gyártó VPN-berendezése ellen, amelyeket a Kaspersky Lab validált az Equation Grouphoz kötve, és ezek a gyártók valódi kihasználtságként hitelesítettek. expozíciójuk idején nulla napos kizsákmányolás volt. A Cisco PIX és ASA tűzfalak biztonsági réseket tartalmaztak, amelyeket az NSA lehallgatásra használt.

Továbbá az "Agresszív mód" beállításokat használó IPsec VPN -ek a PSK hash -jét egyértelműen küldik. Ezt az NSA megcélozhatja és nyilvánvalóan megcélozza offline szótártámadások segítségével.

IETF dokumentáció

Szabványok pálya

  • RFC  1829 : Az ESP DES-CBC átalakítása
  • RFC  2403 : A HMAC-MD5-96 használata ESP és AH környezetben
  • RFC  2404 : A HMAC-SHA-1-96 használata ESP és AH környezetben
  • RFC  2405 : Az ESP DES-CBC titkosítási algoritmus explicit IV
  • RFC  2410 : A NULL titkosítási algoritmus és használata IPsec -vel
  • RFC  2451 : Az ESP CBC módú titkosítási algoritmusok
  • RFC  2857 : A HMAC-RIPEMD-160-96 használata ESP és AH környezetben
  • RFC  3526 : Modulárisabb exponenciális (MODP) Diffie-Hellman csoportok az Internet Key Exchange (IKE) számára
  • RFC  3602 : Az AES-CBC titkosítási algoritmus és használata IPsec-vel
  • RFC  3686 : Fejlett titkosítási szabvány (AES) számláló mód használata IPsec Encapsulating Security Payload (ESP) használatával
  • RFC  3947 : A NAT-Traversal tárgyalása az IKE-ben
  • RFC  3948 : IPsec ESP csomagok UDP -beágyazása
  • RFC  4106 : A Galois/Counter Mode (GCM) használata IPsec Encapsulating Security Payload (ESP) rendszerben
  • RFC  4301 : Az Internet Protokoll biztonsági architektúrája
  • RFC  4302 : IP hitelesítési fejléc
  • RFC  4303 : IP -védő biztonsági hasznos teher
  • RFC  4304 : Kiterjesztett sorszám (ESN) kiegészítés az IPsec értelmezési tartományhoz (DOI) az Internet Security Association és a Key Management Protocol (ISAKMP) számára
  • RFC  4307 : Kriptográfiai algoritmusok az Internet Key Exchange 2. verziójában ( IKEv2 )
  • RFC  4308 : Kriptográfiai csomagok IPsec -hez
  • RFC  4309 : Speciális titkosítási szabvány (AES) CCM mód használata IPsec Encapsulating Security Payload (ESP) használatával
  • RFC  4543 : A Galois Message Authentication Code (GMAC) használata IPsec ESP és AH rendszerben
  • RFC  4555 : IKEv2 mobilitási és multihoming protokoll (MOBIKE)
  • RFC  4806 : Online Certificate Status Protocol (OCSP) kiterjesztések az IKEv2 -hez
  • RFC  4868 : HMAC-SHA-256, HMAC-SHA-384 és HMAC-SHA-512 használata IPsec-vel
  • RFC  4945 : Az IKEv1/ISAKMP, IKEv2 és PKIX internetes IP -biztonsági PKI -profilja
  • RFC  5280 : Internet X.509 nyilvános kulcsú infrastruktúra tanúsítvány és tanúsítvány visszavonási lista (CRL) profil
  • RFC  5282 : Hitelesített titkosítási algoritmusok használata az Internet Key Exchange 2 (IKEv2) protokoll titkosított hasznos terhelésével
  • RFC  5386 : A semminél jobb biztonság: IPsec nem hitelesített mód
  • RFC  5529 : A Camellia működési módjai az IPsec -vel való használatra
  • RFC  5685 : Átirányítási mechanizmus az Internet Key Exchange Protocol 2 verziójához (IKEv2)
  • RFC  5723 : Internet Key Exchange Protocol 2. verzió (IKEv2) Munkamenet folytatása
  • RFC  5857 : IKEv2 bővítmények a fejléc tömörítésének támogatására IPsec -en keresztül
  • RFC  5858 : IPsec bővítmények az IPsec feletti robosztus fejléc -tömörítés támogatásához
  • RFC  7296 : Internet Key Exchange Protocol 2. verzió (IKEv2)
  • RFC  7321 : Kriptográfiai algoritmus megvalósítási követelményei és használati útmutatója a biztonsági hasznos terhelés (ESP) és a hitelesítési fejléc (AH) beágyazásához
  • RFC  7383 : Internet Key Exchange Protocol 2. verzió (IKEv2) üzenettöredezettség
  • RFC  7427 : Aláírás -hitelesítés az Internet Key Exchange 2. verziójában (IKEv2)
  • RFC  7634 : ChaCha20, Poly1305 és használatuk az Internet Key Exchange Protocol (IKE) és az IPsec protokollokban

Kísérleti RFC -k

  • RFC  4478 : Ismételt hitelesítés az Internet Key Exchange (IKEv2) protokollban

Információs RFC -k

  • RFC  2367 : PF_KEY interfész
  • RFC  2412 : Az OAKLEY Key Determination Protocol
  • RFC  3706 : Forgalom-alapú módszer a halott internetes kulcscsere (IKE) társainak észlelésére
  • RFC  3715 : IPsec-hálózati címfordítás (NAT) kompatibilitási követelmények
  • RFC  4621 : Az IKEv2 Mobility and Multihoming (MOBIKE) protokoll kialakítása
  • RFC  4809 : Az IPsec tanúsítványkezelési profil követelményei
  • RFC  5387 : Probléma- és alkalmazhatósági nyilatkozat a semminél jobb biztonságért (BTNS)
  • RFC  5856 : Robusztus fejléc -tömörítés integrálása az IPsec biztonsági egyesületeken keresztül
  • RFC  5930 : Speciális titkosítási szabványos számláló mód (AES-CTR) használata az Internet Key Exchange 02 (IKEv2) protokollal
  • RFC  6027 : IPsec -fürt problémajelentése
  • RFC  6071 : IPsec és IKE Document Roadmap
  • RFC  6379 : B -csomag kriptográfiai lakosztályok IPsec -hez
  • RFC  6380 : B Suite -profil az Internet Protocol Security (IPsec) számára
  • RFC  6467 : Biztonságos jelszó keretrendszer az Internet Key Exchange 2 verziójához (IKEv2)

A jelenlegi legjobb gyakorlat RFC -k

  • RFC  5406 : Irányelvek az IPsec 2. verziójának használatának megadásához

Elavult/történelmi RFC -k

  • RFC  1825 : Internet architektúra biztonsági architektúrája (az RFC 2401 elavult)
  • RFC  1826 : IP hitelesítési fejléc (az RFC 2402 elavult)
  • RFC  1827 : IP Encapsulating Security Payload (ESP) (elavult az RFC 2406 segítségével)
  • RFC  1828 : IP -hitelesítés Kulcsos MD5 használatával (előzmény)
  • RFC  2401 : Internet architektúra biztonsági architektúrája (IPsec áttekintés) (az RFC 4301 elavult)
  • RFC  2406 : IP -burkoló biztonsági hasznos terhelés (ESP) (az RFC 4303 és az RFC 4305 elavult)
  • RFC  2407 : Az ISAKMP internetes IP biztonsági értelmezési tartománya (az RFC 4306 elavult)
  • RFC  2409 : Az internetes kulcscsere (az RFC 4306 elavult)
  • RFC  4305 : Kriptográfiai algoritmus megvalósítási követelmények a biztonsági hasznos terhelés (ESP) és a hitelesítési fejléc (AH) beágyazásához (az RFC 4835 elavult)
  • RFC  4306 : Internet Key Exchange (IKEv2) protokoll (az RFC 5996 elavult)
  • RFC  4718 : IKEv2 pontosítások és végrehajtási irányelvek (az RFC 7296 elavult)
  • RFC  4835 : Kriptográfiai algoritmus megvalósítási követelmények a biztonsági hasznos terhelés (ESP) és a hitelesítési fejléc (AH) beágyazásához (az RFC 7321 elavult)
  • RFC  5996 : Internet Key Exchange Protocol 2. verzió (IKEv2) (az RFC 7296 elavult)

Lásd még

Hivatkozások

Külső linkek