Hogyan konfigurálhatjuk a high-end ssl biztonságát a nginx-en
Ez az utasítás megmutatja, hogyan állíthatja be az SSL biztonság magas szintjét a Nginx webszerveren. Mi ezt frissítésével OpenSSL a legújabb verzióra, hogy csökkentsék a kockázatot az ilyen támadások heartbleed, tömörítés és export SSL titkosítás ki, hogy enyhítse az ilyen típusú támadások, mint egy őrült, a bűnözés és a holtpont, tiltsa SSLv3 és alsó miatt sebezhető a protokoll, létrehoz Hatalmas titkos kulcs, amely lehetővé teszi a titkosítás alkalmazását, ha lehetséges. A HSTS és a HPKP is beletartozik. Így nagy teljesítményű és professzionális SSL konfigurációt kapunk, és a legmagasabb A + osztályt is kapjuk a Qually Labs SSL tesztben.
Mi fog változni /etc/nginx/sited-enabled/yoursite.com nginx konfigurációs fájl (Ubuntu / Debian) vagy /etc/nginx/conf.d/nginx.conf (RHEL / CentOS).
A 443-as port (kiszolgáló konfigurációja) kiszolgálói konfigurációjában a kiszolgáló egységet kell módosítania. A kézikönyv végén megtalálja a teljes konfiguráció példáját.
Győződjön meg róla, hogy biztonsági másolatot készít a fájlokról, mielőtt szerkesztené őket!
BEAST támadás és RC4
Röviden, ha a CBC titkosítási algoritmust - a lánc titkosítási egységet - beolvasztják, a titkosított forgalom egyes részeit titokban megfejtik.
Az RC4 letiltása számos következménnyel jár
- Először is, az ősi böngészőkkel rendelkező felhasználók, például az Internet Explorer a Windows XP rendszeren alternatív megoldást használnak - a 3DES-t. A Triple-DES biztonságosabb, mint az RC4, de ez egy rendkívül költséges művelet. A kiszolgáló fizetni fogja a felhasználóknak a CPU időt.
- Másodszor, az RC4 lágyítja a BEAST-ot. Így az RC4 tiltsa TLS 1.0 teszi a felhasználók sebezhető ez a támadás, mozgó őket az AES-CBC (normál „korrekció” fenevad a szerver oldalon, hogy a magasabb prioritású RC4).
Bizonyos, hogy az RC4 hiányosságai jelentősen meghaladják a BEAST-hoz kapcsolódó kockázatokat. Valóban, az ügyfelek számának csökkenésével (amelyet mind a Chrome, mind a Firefox biztosít), a BEAST nem jelent problémát. De az RC4 kockázata csak lendületet mutat: a közeljövőben felszínre kerül a részletes kriptanalízis.
Faktoring RSA-EXPORT billentyűk [Faktoring RSA-EXPORT Keys (FREAK)]
FREAK sérülékenység man-in-the-middle [man-in-the-middle (MITM)], detektálás csoport kriptográfusok INRIA, a Microsoft Research és IMDEA. A FREAK az "RSA Key Export Factor"
Kiderült, hogy néhány modern TLS ügyfelek - beleértve azokat is, az Apple és a SecureTransport az OpenSSL - hibát tartalmaz. Ez a hiba okozza, hogy fogadja el az RSA kulcsok export-osztály, még akkor is, ha az ügyfél nem kérte export minőségű RSA. Ennek a következményei hiba lehet elég katasztrofális: lehetővé teszi a támadás, a „man in the middle” eredményeként, egy aktív támadó erő annál kisebb a kapcsolat minőségét, feltéve, hogy az ügyfél kiszolgáltatott, és a szerver támogatja az RSA export.
Kétféle támadás létezik, amelyeken a szervernek el kell fogadnia az "export osztály RSA" -ot is.
A MITM támadás a következőképpen működik
- A Hello kliens üzenetben szabványos "RSA" titkosítást igényel.
- MITM, a támadó ezt az üzenetet megváltoztatja az "export RSA" kérésére.
- A kiszolgáló 512 bites RSA exportkulcssal válaszol, amelyet hosszú távú kulcsának aláír.
- Az ügyfél elfogadja ezt a gyenge kulcsot az OpenSSL / SecureTransport hiba miatt.
- Az RSA modul támadó tényezője visszaállítja a megfelelő RSA dekódoló kulcsot.
- Amikor az ügyfél titkosítja a kiszolgáló "mester előtti titkát", a támadó most visszafejtheti a TLS "mester titkát".
- Mostantól a támadó nyitott szöveget lát, és megadhatja, amit akar.
Az ezen az oldalon javasolt titkosítókészlet nem teszi lehetővé az exportosztályi titkosítók használatát. Győződjön meg róla, hogy az OpenSSL frissítve van a legfrissebb verzióra, és arra ösztönzi az ügyfeleket, hogy használják a frissített szoftvert is.
Jam (EXPORT EXPORT) [Logjam (DH EXPORT)]
Több egyetem és intézet kutatói tanulmányt készítettek, amely problémát jelentett a TLS protokollban. A jelentésben a kutatók a támadás két módjára mutatnak rá.
Azáltal, hogy a Diffie-Hellman olyan kulcsokat cserél, amelyek a TLS-t használják egy nyilvános kulcs tárgyalására és biztonságos kapcsolat létrehozására egy egyszerű szöveges kapcsolat révén.
A második fenyegetés az, hogy sok szerver ugyanazokat az egyszerű Diffie-Hellman számokat használja a kulcscseréhez, ahelyett, hogy saját egyedi DH paramétereket hoztak létre.
A csoport úgy véli, hogy az akadémiai csapat meg tudja szüntetni a 768 bites prímszámokat, és hogy a kormányzati szervek 1024 bites prímszámot törhetnek el. Egy 1024 bites prímszám megsértésével hallgathatja az egymillió felső HTTPS-domain 18% -át. A második szám hackolása megnyitja a virtuális magánhálózatok 66% -át és az SSH szerverek 26% -át.
Később ebben az útmutatóban saját egyedi DH paramétereket hozunk létre, és titkosítási módszert fogunk használni, amely tiltja a titkosítók osztályának exportálását. Győződjön meg arról, hogy az Ön OpenSSL-jét a legfrissebb verzióra frissíti, és arra ösztönzi az ügyfeleket, hogy a legfrissebb szoftvereket is használják. A frissített böngészők nem fogadják el a DH paramétereket 768/1024 bit alatt a javítás után.
A Cloudflare-on részletes útmutatás található a támadásokra, például Zator (DH EXPORT) [Logjam (DH EXPORT)].
Frekvencia mintavételezés (Heartbleed)
Az eredményeket az ellenőrzés bejegyzés helyes (hiánya miatt a határokat ellenőrzés) végrehajtásában chastotootbora DTLS kiterjesztés (RFC6520), az úgynevezett „hibának” származik „chastotootbor” ( „szívdobbanás”). A biztonsági rés besorolása olvasási puffer, a helyzet képes olvasni több adatot meg kellene engedni.
Milyen változata van az OpenSSL-nek a Heartbleed-ből?
A különböző verziók állapota:
- Az OpenSSL 1.0.1-től 1.0.1f-ig (befogadó) sérülékeny
- Az OpenSSL 1.0.1g NEM sebezhető
- Az OpenSSL 1.0.0 ág NEM sebezhető
- Az OpenSSL 0.9.8 ág NEM sebezhető
Az OpenSSL frissítésekor nem válik sebezhetővé a hiba.
SSL tömörítés (CRIME támadás)
A CRIME támadás SSL tömörítést használ a saját vállalkozás létrehozásához. SSL alapértelmezett tömörítési le van tiltva a nginx 1.1.6 + / 1.0.9 + (ha az OpenSSL 1.0.0+) és nginx 1.3.2 + / 1.2.2 + (ha régebbi verziói OpenSSL).
Ha a Nginx vagy az OpenSSL korábbi verzióját használja, és az elosztása nem adja ezt az opciót, akkor újra kell fordítania az OpenSSL-t ZLIB támogatás nélkül. Ez letiltja a DEFLATE tömörítési módszer használatát az OpenSSL-ben. Ha ezt megteszi, használhatja a szokásos HTML tömörítési módszert, DEFLATE.
SSLv2 és SSLv3
Az SSL v2 nem biztonságos, ezért ki kell kapcsolnunk. Azt is letilthatja SSLv3, valamint a TLS 1.0, szenved a leminősítés támadás, amely lehetővé teszi a támadó erőt a használni kívánt kapcsolatot SSLv3, és rajta keresztül tiltani biztonságos kapcsolatot.
Ismét módosítsa a konfigurációs fájlt:
Hamisítás és TLS-FALLBACK-SCSV
Az SSLv3 lehetővé teszi a hamisítási hiba kihasználását (POODLE). Ez az egyik fő oka a funkció kikapcsolásának.
A Google felajánlott egy TLSFALLBACKSCSV nevű SSL / TLS kiterjesztést, amelynek célja a kényszerített SSL-kapcsolat megszakadása.
Automatikusan engedélyezi az OpenSSL frissítését az alábbi verziókhoz:
- Az OpenSSL 1.0.1-nek TLSFALLBACKSCSV van 1.0.1j és újabb verziójában
- Az OpenSSL 1.0.0 1.0.0 és újabb TLSFALLBACKSCSV-t tartalmaz
- Az OpenSSL 0.9.8-nak TLSFALLBACKSCSV van 0.9.8zc és újabb verzióban
További információt a NGINX dokumentációjában talál.
Titkosítási csomag
A titkosság biztosítja a munkamenet kulcs integritását abban az esetben, ha egy hosszú távú kulcs veszélybe kerül. A PFS megoldja ezt a problémát, ha egy új kulcs kimenetét alkalmazza minden munkamenet számára.
Ez azt jelenti, hogy ha egy titkos kulcs sérült, nem használható a rögzített SSL-forgalom dekódolására.
A titkosság ösztönzését biztosító titkosszolgálók azok, akik a Diffie-Hellman kulcscsere effimero formáját használják. A hátránya a fejük, mely elliptikus görbe opciókkal javítható.
A következő két kódrészlet ajánlott, és néhány a Mozilla Foundation-tól.
Ajánlott titkosítási módszer:
A visszafelé kompatibilitásra ajánlott titkosítási módszer (IE6 / WinXP):
Ha az OpenSSL verziója elavult, a hozzáférhetetlen titkosítókat automatikusan el kell dobni. Mindig használja a fenti titkosítási módszerek teljes skáláját, és hagyja, hogy az OpenSSL válassza ki azokat, amelyeket támogat.
A titkosítási módszerek megrendelése nagyon fontos, mert eldönti, hogy mely algoritmusok kerülnek kiválasztásra prioritási sorrendben. A fentiekben javasolt algoritmusok prioritást élveznek, így biztosítva az ideális biztonsági szintet.
Az OpenSSL korábbi verziói nem tudják visszaadni az algoritmusok teljes listáját. Az AES-GCM és egyes ECDHE-k viszonylag korábban megjelentek, és nem találhatók az Ubuntu vagy az RHEL által szállított OpenSSL legtöbb verziójában.
Prioritási logika
Először az ECDHE + AESGCM titkosítókat választják ki. Ez TLS 1.2 titkosítás. A jelenleg ismert támadások egyike sem a titkosítókra irányul.
Előnyösek a PFS kriptoszisztémák, az ECDHE első, majd a DHE.
Az AES 128 előnyben részesíthető az AES 256-mal. Sok vita folyik arról, hogy az AES256 a kiegészítő biztonság általános költségei messze nem egyértelműek-e. Jelenleg az AES128 előnyös, mert jó biztonságot nyújt, nagyon gyors, és úgy tűnik, hogy ellenáll az átmeneti támadásoknak.
A titkosítás visszafele kompatibilitásának biztosítása érdekében az AES a 3DES-hez képest előnyösebb. Az AES-vel szembeni BEAST támadások a TLS 1.1 és újabb verzióban enyhültek, ami nehéz a TLS 1.0-ban. Nem visszafelé kompatibilis kriptográfiai módszerrel a 3DES nem.
Az RC4 teljesen eltávolításra kerül. A 3DES-et visszafelé kompatibilitás biztosítására használják. Lásd a vitát # RC4_weaknesses.
Kötelező kibocsátás
- Az aNULL nem hitelesített Diffie-Hellman csere kulcsokat tartalmaz, amelyek a Man-In-The-Middle támadások tárgyát képezik (MITM)
- Az eNULL zéró titkosítási titkosítókat tartalmaz (világos formában)
- EXPORT örökölte a gyenge titkosítókat, amelyeket az amerikai törvények szerint exportáltak
- Az RC4 olyan titkosítókat tartalmaz, amelyek az elavult ARCFOUR algoritmust használják
- A DES olyan kódolókat tartalmaz, amelyek egy elavult adat titkosítási szabványt használnak
- Az SSLv2 az SSL szabvány régi verziójában definiált összes titkosítást tartalmazza, most nem ajánlott
- Az MD5 minden olyan kódolást tartalmaz, amely az elavult 5-ös üzenetet, mint hash algoritmust használja
Haladó beállítások
Győződjön meg arról, hogy ezeket a sorokat is hozzáadja:
Amikor SSLv3 vagy TLSv1 kézfogás közben titkosítást választasz, általában az ügyfél preferenciáját használják. Ha ez az irányelv engedélyezve van, először a szerver preferenciáját fogja használni.
A Diffie Hellman kényszerített adatvédelmi és effektív paraméterei
A magánélet kényszerítésének koncepciója egyszerű: az ügyfél és a szerver egy olyan kulccsal állapodik meg, amely soha nem jut át az átvitelre, és megsemmisül az ülés végén. A kiszolgálón lévő magán-RSA-t a Diffie-Hellman kulcscserének az ügyfél és a kiszolgáló közötti cseréjével írják alá. A Diffie-Hellman kézfogásból (kézfogás) kapott előzetes mester kulcsot ezután titkosításra használják. Mivel az előzetes mester kulcs az ügyfél és a kiszolgáló közötti kapcsolathoz kötődik, és csak korlátozott ideig használható, az úgynevezett Ephemeral.
A kényszerített adatvédelem esetén, ha egy támadó átveszi a szerver privát kulcsát, akkor nem tudja visszafejteni a korábbi kapcsolatokat. A privát (private) kulcsot csak a DH kézfogás aláírására használják, amely nem jeleníti meg az előzetes mester kulcsot. A Diffie-Hellman garantálja, hogy az előzetes mester kulcsok soha nem hagyják el az ügyfelet és a kiszolgálót, és a MITM nem tudja lehallgatni.
Az 1.4.4-ből származó Nginx összes verziója az OpenSSL a Diffie-Hellman (DH) bemeneti paramétereihez [Diffie-Hellman (DH)] alapul. Sajnos ez azt jelenti, hogy a Diffie-Hellman Ephemerality (DHE) az alapértelmezett OpenSSL-t fogja használni, amely 1024 bites kulcsot tartalmaz a kulcscseréhez. Így, amikor 2048 bites tanúsítványt használunk, a ÉS kliensek gyengébb kulcscserét fognak használni, mint a nem efemer DH ügyfelek.
Stabilabb DHE paramétert kell létrehoznunk:
És akkor vegye fel a Nginxet a DHE kulcscsere használatához:
OCSP kötés [OCSP tűzés]
Amikor csatlakozik egy szerverhez, az ügyfelek ellenőriznie kell a megbízhatóság a szerver tanúsítvány, amely vagy egy tanúsítvány-visszavonási lista (CRL) [tanúsítvány-visszavonási lista (CRL)], vagy protokoll támogatása bizonyítvány státusza (OCSP) [Online Certificate Status Protocol (OCSP)] rekordot. A probléma az, hogy a CRL listák hatalmas méretekre nőttek és nem mindig elérhetőek letöltésre.
Az OCSP sokkal könnyebb, mivel egyszerre csak egy rekordot vesz ki. De a mellékhatás az, hogy az OCSP 3. részében az OCSP-kéréseket a válaszadónak a szerverhez való csatlakozáskor kell elvégeznie, amelyhez a késések és az esetleges hibák kerülnek hozzáadásra. Valójában a CA-k (CA) által használt OCSP-válaszadók gyakran annyira megbízhatatlanok, hogy a böngésző idővel meghiúsul, ha a válasz nem érkezik meg időben. Ez csökkenti a biztonságot azzal, hogy a támadó az OCSP-válaszadó DoS-ját használja a kikapcsoláshoz.
A megoldás az, hogy a kiszolgáló a TLS kézfogásakor elküldje a gyorsítótárazott OCSP rekordot, ezért megkerülje az OCSP válaszadót. Ez a mechanizmus lehetővé teszi, hogy mentse a kéréseket oda-vissza az ügyfél és az OCSP válaszadó között, és az OCSP tűzés [OCSP tűzés].
A kiszolgáló csak akkor küldi el a gyorsítótáras OCSP-választ, ha az ügyfél kéri, és a CLIENT HELLO kérésben a TLS kiterjesztés status_request támogatását deklarálja.
A legtöbb kiszolgáló 48 órán keresztül gyorsítja az OCSP válaszát. Rendszeres időközönként a kiszolgáló csatlakozik az OCSP válaszadó CA-hoz (CA), hogy friss OCSP bejegyzést kapjon. A válaszadó OCSP helyét az aláírt tanúsítvány Hatósági Információs Hatósága veszi át.
HTTP szigorú közlekedésbiztonság
Amikor csak lehetséges, engedélyeznie kell a HTTP Strict Transport Security (HSTS) használatát, amely arra utasítja a böngészőket, hogy csak a HTTPS segítségével kommunikáljanak webhelyével.
HTTP Nyilvános kulcs pinning kiterjesztés
Engedélyeznie kell a HTTP Nyilvános kulcs pinning kiterjesztését is.
A nyilvános kulcs rögzítése azt jelenti, hogy a tanúsítványláncnak tartalmaznia kell egy nyilvános kulcsot a fehérlistáról. Ez biztosítja, hogy csak a hitelesítő tanúsítvánnyal rendelkező hitelesítő hatóságok (white list) engedélyezett hitelesítő hatóságai (white list) aláírhatják a * .example.com tanúsítványokat, és nem a böngésző által tárolt CA-t.
Ha a fenti konfigurációs vonalakat alkalmazta, újra kell indítania a nginxet:
# Először ellenőrizze a konfigurációt:
# Ezután indítsa újra:
Most használja az SSL Labs tesztet, hogy lássa, hogyan kap magas A-fokozatot. Természetesen a biztonság, a tartósság és a professzionális SSL-konfiguráció bizalmának bizalma is!