Această instrucțiune va arăta cum să configurați un nivel ridicat de securitate SSL pe serverul web Nginx. Vom face acest lucru prin actualizarea OpenSSL la cea mai recentă versiune, pentru a reduce riscul de atacuri, cum ar fi heartbleed, compresie și criptare SSL de export off pentru a atenua aceste tipuri de atacuri, ca FREAK, CRIMA și logjam, dezactivati SSLv3 și mai mici din cauza vulnerabilităților în protocol, va crea O cheie puternică criptică care vă permite să aplicați criptarea atunci când este posibil. Vom include, de asemenea, HSTS și HPKP. Astfel, vom obține o configurație puternică și profesională SSL, și să obțină cel mai mare rating A + in Qually Labs Test SSL.
Vom schimba în /etc/nginx/sited-enabled/yoursite.com fișier de configurare Nginx (pe Ubuntu / Debian) sau /etc/nginx/conf.d/nginx.conf (pe RHEL / CentOS).
Trebuie să modificați părțile dintre unitatea de server în configurația serverului pentru portul 443 (ssl config). La sfârșitul manualului veți găsi un exemplu de configurare completă.
Asigurați-vă că ați făcut copii de siguranță ale fișierelor înainte de a le edita!
BEAST Attack și RC4
Pe scurt, prin hacking algoritmul de criptare CBC în - unitatea de criptare în lanț - modurile, părți ale traficului criptat pot fi descifrate în secret.
Dezactivarea RC4 are o serie de consecințe
- În primul rând, utilizatorii cu browsere vechi, cum ar fi Internet Explorer pe Windows XP, vor folosi o alternativă - 3DES. Triple-DES este mai sigur decât RC4, dar este o operație extrem de costisitoare. Serverul dvs. va plăti timp pentru CPU pentru acești utilizatori.
- În al doilea rând, RC4 înmoaie BEAST. Astfel, dezactivarea RC4 face ca utilizatorii TLS 1.0 să fie susceptibili la acest atac prin mutarea AES-CBC ("corecția" obișnuită a BEAST de la partea serverului la prioritatea RC4 ridicată).
Există certitudinea că deficiențele din RC4 depășesc în mod semnificativ riscurile asociate cu BEAST. Într-adevăr, cu o scădere pe partea clientului (oferită de Chrome și Firefox), BEAST nu este o problemă. Dar riscul de la RC4 are doar un impuls: Cryptanaliza detaliată va apărea pe suprafață în viitorul apropiat.
Factoring Chei RSA-EXPORT [Chei de factoring RSA-EXPORT (FREAK)]
FREAK este o vulnerabilitate om-în-mijloc (MITM), descoperită de un grup de criptografiști INRIA, Microsoft Research și IMDEA. FREAK înseamnă "Factor de export cheie RSA"
Se pare că unii clienți TLS moderni - inclusiv SecureTransport de la Apple și OpenSSL - conțin o eroare. Această eroare le obligă să accepte chei de clasă de export RSA, chiar dacă clientul nu a solicitat o clasă de export RSA. Consecințele acestei erori pot fi destul de deplorabile: permit atacurile "om în mijloc", ca rezultat, un atacator activ poate face ca calitatea conexiunii să fie mai gravă, cu condiția ca clientul să fie vulnerabil și serverul să accepte exportul RSA.
Există două tipuri de atac, în care serverul trebuie să accepte și "clasa de export RSA".
Atacul MITM funcționează după cum urmează
- În mesajul Hello client, acesta solicită un set standard de "cipuri RSA".
- MITM, atacatorul schimbă acest mesaj pentru a solicita "Export RSA".
- Serverul răspunde cu o cheie de export RSA de 512 biți, semnată de cheia pe termen lung.
- Clientul acceptă această cheie slabă din cauza unei erori OpenSSL / SecureTransport.
- Factorul de atac al modulului RSA restabilește cheia de decriptare RSA corespunzătoare.
- Când clientul criptează "secretul pre-master" al serverului, atacatorul îl poate decripta acum pentru a recupera secretul master TLS.
- De acum încolo, un atacator vede un text deschis și poate intra orice vrea.
Setul de șifiere propus pe această pagină nu permite utilizarea de cipuri de clasă de export. Asigurați-vă că versiunea OpenSSL este actualizată la cea mai recentă versiune disponibilă și încurajați-i pe clienți să folosească de asemenea software-ul actualizat.
Blocaj (EXPORT EXPORT) [Logjam (DH EXPORT)]
Cercetătorii din mai multe universități și institute au efectuat un studiu care a arătat o problemă în protocolul TLS. În raport, cercetătorii indică două metode de atac.
Permițând Diffie-Hellman cheile de schimb care utilizează TLS să negocieze o cheie publică și să negocieze o conexiune securizată printr-o conexiune text simplu.
A doua amenințare este că multe servere utilizează aceleași numere simple Diffie-Hellman pentru schimbul de chei, în loc să creeze propriile parametri DH unici.
Grupul consideră că echipa academică poate rupe numerele primare de 768 de biți și că agențiile guvernamentale pot rupe un număr prime de 1024 de biți. Prin violarea unui număr prime de 1024 de biți, puteți auzi 18 la sută din un milion de domenii HTTPS de top. Hacking-ul celui de-al doilea număr va deschide 66% din rețelele virtuale private și 26% din serverele SSH.
Mai târziu, în acest ghid, vom crea propriii parametri DH unici și vom folosi o metodă de criptare care va interzice exportul clasei de cifre. Asigurați-vă că versiunea OpenSSL este actualizată la cea mai recentă versiune disponibilă și încurajați-i pe clienți să folosească, de asemenea, cel mai recent software. Browserele actualizate refuză să accepte parametrii DH de mai jos 768/1024 biți după această remediere.
Pe Cloudflare există un ghid detaliat al atacurilor, cum ar fi Zator (DH EXPORT) [Logjam (DH EXPORT)].
Frecventa de prelevare a probelor (Heartbleed)
Rezultatele intrării de verificare este corectă (din cauza lipsei limitelor de verificare) în punerea în aplicare a extensiei chastotootbora DTLS (RFC6520), așa-numitele „bug“ vine de la „chastotootbor“ ( „bătăile inimii“). Vulnerabilitatea este clasificată ca o tampon mai ușor de citit, situația posibilității de a citi mai multe date decât ar trebui să fie permisă.
Ce versiuni de OpenSSL suferă de Heartbleed?
Starea diferitelor versiuni:
- OpenSSL 1.0.1 până la 1.0.1f (inclusiv) sunt vulnerabile
- OpenSSL 1.0.1g NU este vulnerabil
- OpenSSL ramura 1.0.0 NU este vulnerabilă
- OpenSSL 0.9.8 ramura NU este vulnerabilă
Când faceți upgrade la OpenSSL, nu deveniți vulnerabil la această eroare.
Compresie SSL (atac CRIME)
Infracțiunea CRIME utilizează compresia SSL pentru a crea o afacere proprie. Compilarea SSL este dezactivată implicit în Nginx 1.1.6 + / 1.0.9 + (dacă se utilizează OpenSSL 1.0.0+) și Nginx 1.3.2 + / 1.2.2 + (dacă se utilizează versiuni mai vechi ale OpenSSL).
Dacă utilizați o versiune anterioară de Nginx sau OpenSSL și distribuția dvs. nu portează această opțiune, atunci trebuie să recompilați OpenSSL fără suport ZLIB. Acest lucru va dezactiva utilizarea metodei DEFLATE de compresie în OpenSSL. Dacă faceți acest lucru, puteți utiliza metoda obișnuită de comprimare HTML DEFLATE.
SSLv2 și SSLv3
SSL v2 nu este sigur, așa că trebuie să îl dezactivați. De asemenea, vom dezactiva SSLv3, cum ar fi TLS 1.0, care este afectat de atacurile asupra versiunilor vechi, ceea ce permite unui atacator să forțeze conexiunea să utilizeze SSLv3 și să dezactiveze conexiunea securizată prin aceasta.
Din nou, editați fișierul de configurare:
Falsificarea și TLS-FALLBACK-SCSV
SSLv3 vă permite să exploatați eroarea de falsificare (POODLE). Acesta este unul dintre principalele motive pentru dezactivarea acestei funcții.
Google a oferit o extensie SSL / TLS numită TLSFALLBACKSCSV, care încearcă să prevină deconectarea forțată SSL.
Activează automat când actualizați OpenSSL la următoarele versiuni:
- OpenSSL 1.0.1 are TLSFALLBACKSCSV în 1.0.1j și mai mare
- OpenSSL 1.0.0 are TLSFALLBACKSCSV în 1.0.0o și mai mare
- OpenSSL 0.9.8 are TLSFALLBACKSCSV în 0.9.8zc și mai mare
Pentru mai multe informații, consultați documentația NGINX.
Encryption Suite
Confidențialitatea asigură integritatea cheii de sesiune în cazul în care o cheie pe termen lung este compromisă. PFS rezolvă această problemă prin aplicarea ieșirii unei noi chei pentru fiecare sesiune.
Aceasta înseamnă că atunci când o cheie secretă este compromisă, aceasta nu poate fi utilizată pentru a decripta traficul SSL înregistrat.
Din cifrele care oferă Ideal încurajarea secreției sunt cele care folosesc forma efemeră a schimbului de chei Diffie-Hellman. Dezavantajul lor îl reprezintă cheltuielile aferente, care pot fi îmbunătățite prin utilizarea opțiunilor pentru curbe eliptice.
Următoarele două seturi de cipuri sunt recomandate, iar unele sunt de la Mozilla Foundation.
Metodă de criptare recomandată:
Metoda de criptare recomandată pentru compatibilitate înapoi (IE6 / WinXP):
Dacă versiunea dvs. de OpenSSL este depășită, cifrele inaccesibile vor fi aruncate automat. Utilizați întotdeauna setul complet de metode de criptare de mai sus și, lăsați OpenSSL să aleagă cele pe care le suportă.
Ordonarea metodelor de criptare este foarte importantă, deoarece decide ce algoritmi vor fi aleși în ordinea prioritară. Algoritmii recomandați mai sus sunt specificați cu prioritate, oferind un grad de siguranță ideal.
Versiunile mai vechi ale OpenSSL nu pot returna o listă completă de algoritmi. AES-GCM și unele ECDHE-uri au apărut relativ recent și nu se găsesc în majoritatea versiunilor OpenSSL furnizate împreună cu Ubuntu sau RHEL.
Prioritate logică
Sunt selectate mai întâi cipurile ECDHE + AESGCM. Sunt chei TLS 1.2. Nici unul dintre atacurile cunoscute nu vizează aceste cifre.
Sunt preferate criptosistemele PFS, mai întâi cu ECDHE, urmate de DHE.
AES 128 este de preferat față de AES 256. Au fost multe discuții despre costurile generale ale AES256 ale securității suplimentare, care sunt departe de a fi evidente. În prezent, AES128 este preferabil deoarece oferă o bună securitate, este foarte rapid și pare a fi mai rezistent la atacurile temporare.
Pentru a asigura compatibilitatea înapoi a criptării, AES este preferabilă 3DES. Atacurile pe AES sunt atenuate în TLS 1.1 și mai mult, ceea ce este dificil de realizat în TLS 1.0. Într-o metodă criptografică compatibilă non-backward, 3DES nu o face.
RC4 este îndepărtat complet. 3DES este folosit pentru a oferi compatibilitate înapoi. Vedeți discuția în # RC4_weaknesses.
Eliberări obligatorii
- aNULL conține chei de schimb non-autentificate Diffie-Hellman care fac obiectul atacurilor Man-In-The-Middle (MITM)
- eNULL conține cifre de criptare zero (în formă clară)
- EXPORT au moștenit cifrele slabe, care au fost marcate ca fiind exportate de legislația SUA
- RC4 conține cifre care utilizează algoritmul ARCFOUR depășit
- DES conține cipuri care utilizează un standard de criptare a datelor depășit
- SSLv2 conține toate cipurile definite în versiunea veche a standardului SSL, acum nu este recomandat
- MD5 conține toate cipurile care utilizează mesajul depășit 5 digest ca algoritm hash
Setări avansate
Asigurați-vă că adăugați și aceste linii:
Atunci când alegeți un cifru în timpul handshake-ului SSLv3 sau TLSv1, preferința clientului este de obicei utilizată. Dacă această directivă este activată, preferința serverului va fi utilizată mai întâi.
Forța de confidențialitate și parametrii efemerici ai lui Diffie Hellman
Conceptul de forțare a confidențialității este simplu: clientul și serverul sunt de acord asupra unei chei care nu intră niciodată în transfer și este distrusă la sfârșitul sesiunii. RSA privat de pe server este folosit pentru a semna schimbul de chei Diffie-Hellman între client și server. Cheia master preliminară obținută din strângerea de mână Diffie-Hellman (handshake) este apoi utilizată pentru criptare. Deoarece cheia preliminară master este specifică conexiunii dintre client și server și este utilizată doar pentru o perioadă limitată de timp, se numește Ephemeral.
Cu Forced Privacy, în cazul în care un atacator preia cheia privată a serverului, nu poate decripta conexiunile anterioare. Cheia privată (privată) este utilizată numai pentru semnarea strânsei mâini DH, care nu dezvăluie cheia master principal. Diffie-Hellman garantează că cheile preliminare master nu părăsesc niciodată clientul și serverul și nu pot fi interceptate de MITM.
Toate versiunile Nginx de la 1.4.4 se bazează pe OpenSSL pentru parametrii de intrare Diffie-Hellman (DH) [Diffie-Hellman (DH)]. Din păcate, aceasta înseamnă că Ephemeralitatea Diffie-Hellman (DHE) va folosi versiunea implicită OpenSSL, care include o cheie de 1024 de biți pentru schimbul de taste. Deci, pe măsură ce folosim un certificat de 2048 de biți, clienții DHE vor utiliza un schimb de taste mai slabi decât clienții non-efimeri DH.
Trebuie să formăm un parametru DHE mai stabil:
Și apoi să-l folosiți pe Nginx pentru schimbul de chei DHE:
Legarea OCSP [capsulare OCSP]
Când vă conectați la un server, clienții trebuie să verifice fiabilitatea certificatului serverului, folosind fie o listă de certificate revocate (CRL) [revocare a certificatului Lista (CRL)], sau statutul certificat de protocol de sprijin (OCSP) [Online Certificate Stare Protocol (OCSP)] de înregistrare. Problema este că listele CRL au crescut la dimensiuni uriașe și nu sunt întotdeauna disponibile pentru descărcare.
OCSP este mult mai ușoară, deoarece doar o singură înregistrare este extrasă la un moment dat. Dar efectul secundar este că cererile OCSP trebuie să fie făcute pe partea a treia a OCSP de către respondent când se conectează la server, la care se adaugă întârzieri și posibile defecțiuni. De fapt, respondenții OCSP folosiți de CA (CA) sunt adesea atât de incorecți încât browserul va eșua în timp, dacă răspunsul nu va fi primit în timp util. Acest lucru reduce securitatea, permițând unui atacator să utilizeze DoS la răspunsul OCSP pentru a opri scanarea.
Soluția este să permită serverului să trimită înregistrarea OCSP stocată în cache în timpul strângerii de mână a TLS, depășind astfel răspunsul OCSP. Acest mecanism vă permite să salvați cererile înainte și înapoi între client și respondentul OCSP și se numește OCSP Capsare [OCSP Capsare].
Serverul trimite un răspuns OCSP în memoria cache numai dacă clientul o solicită, declarând suportul pentru extensia TLS status_request în cererea CLIENT HELLO.
Majoritatea serverelor vor raporta răspunsul OCSP timp de până la 48 de ore. La intervale regulate, serverul se va conecta la CA (CA) Respondent OCSP pentru a primi o intrare nouă a OCSP. Locația OCSP a respondentului este luată din câmpul [Authority Information Access] (Acces la informații despre autoritate) al certificatului semnat.
HTTP Strict Transport Security
Ori de câte ori este posibil, ar trebui să activați HTTP Strict Transport Security (HSTS), care instruiește browserele să comunice cu site-ul dvs. numai prin HTTPS.
Extensia de conectare a cheii publice HTTP
De asemenea, trebuie să activați Extensia de conectare a cheii publice HTTP.
Legarea cu cheie publică înseamnă că lanțul certificatului trebuie să includă o cheie publică din lista albă. Acest lucru asigură faptul că numai lista albă a autorităților de certificare (AC) [Autoritățile de certificare în lista albă (CA)] poate semna certificate pentru * .example.com, și nu oricare dintre CA stocat de browser.
Dacă ați aplicat liniile de configurare de mai sus, trebuie să reporniți nginx:
# În primul rând, verificați configurația:
# Atunci reporniți:
Acum, folosiți testul SSL Labs pentru a vedea cum obțineți un grad A înalt. Și, desigur, încrederea în securitatea, durabilitatea și dovada configurării SSL profesionale!