Zbatimi i SSL Perfect Forward Secrecy në Web-Server NGINX

Kjo SI TË përshkruan procesin e zbatimit të Fshehtësisë së Përparuar të Përsosur me serverin e internetit NGINX në sistemet Debian dhe Ubuntu. Procesi mund të përshtatet lehtësisht me sistemet e tjera GNU/Linux.

Shkurtimisht, Perfect Forward Secrecy siguron: \...që kompromisi i një mesazhi nuk mund të çojë në kompromisin e të tjerëve, dhe gjithashtu se nuk ka asnjë vlerë të vetme sekrete që mund të çojë në kompromisin e mesazheve të shumta.\ Për më shumë informacion, shihni http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Kur dobësia Heartbleed në OpenSSL u zbulua në fillim të vitit 2014, u bë gjithnjë e më e qartë se PFS është një domosdoshmëri për çdo sistem që përdor SSL/TLS në një kapacitet serioz.

Nëse dëshironi të krahasoni rezultatet tuaja me të miat, zbatimi im i referencës mund të testohet në https://indietorrent.org.

Pa vonesë, le të konfigurojmë NGINX për të zbatuar PFS.

Le të kalojmë në drejtorinë e konfigurimit të NGINXs:

cd /etc/nginx/

Ne duhet të gjenerojmë parametra Diffie-Hellman që janë mjaftueshëm të fortë. Disa argumentojnë se 4096 bit është i tepërt dhe do të shkaktojë një barrë të panevojshme në CPU-në e sistemeve, por me fuqinë moderne kompjuterike, ky duket si një kompromis i vlefshëm. Për më shumë informacion, shihni seksionin Referencat, më poshtë.

openssl dhparam -out dh4096.pem 4096

Është i dobishëm që ky skedar konfigurimi, i cili është specifik për detyrën në fjalë, të ndahet në një skedar përfshirjeje; kjo e bën më të thjeshtë zbatimin e PFS në një numër të madh sistemesh.

vi /etc/nginx/perfect-forward-secrecy.conf

Ngjitni sa vijon në skedarin e mësipërm:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;

Modifikoni konfigurimin NGINX për të përfshirë skedarin e mësipërm, duke futur rreshtin e mëposhtëm në skedarin e konfigurimit primar NGINX (si parazgjedhje, /etc/nginx/nginx.conf), në fund të (dhe brenda) Blloku http {}:

# See: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# This MUST come AFTER the lines that includes .../sites-enabled/*, otherwise SSLv3 support may be re-enabled accidentally.
include perfect-forward-secrecy.conf;

Rinisni NGINX për t'i bërë ndryshimet efektive:

service nginx restart

Nëse testi në https://www.ssllabs.com/ssltest/analyze.html shfaq rifillimin e sesionit (caching) Jo (ID-të e caktuara por nuk pranohen) me të kuqe dhe serveri zbaton SNI, shtoni sa vijon në nivelin e lartë Blloku http {} (d.m.th., shtoni në nginx.conf, pak më poshtë ku kemi bërë shtesat e mëparshme):

# See: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

Përsëri, rinisni NGINX për t'i bërë ndryshimet efektive:

service nginx restart

Testi i mësipërm nuk duhet të raportojë më këtë problem (edhe pse problemi nuk e zvogëlon rezultatin e përgjithshëm të testit).

Duke e çuar më tej: Zbatimi i sigurisë së rreptë të transportit HTTP (HSTS) me kohëzgjatje të gjatë

Kjo është e lehtë dhe ia vlen të bëhet, me kusht që:

Dëshironi të detyroni SSL-në për të gjitha burimet për çdo host për të cilin është caktuar ky titull (d.m.th., çdo faqe në faqen e internetit në fjalë).
Ju mund të jetoni duke mos pasur aftësinë për të pranuar dhe injoruar paralajmërimet SSL për çdo burim të kërkuar nga çdo host për të cilin është caktuar ky titull, si p.sh. Mospërputhja e emrit të domenit etj. Vetë natyra e HSTS është se kushtet e paralajmërimit dhe gabimit në lidhje me certifikatën SSL nuk mund të anashkalohen.

Kërkova në internet për informacion në lidhje me nëse vendosja e këtij titulli mund të ketë apo jo pasoja të padëshiruara në shfletuesit që nuk mbështesin kokën dhe shkurtimin. Por, unë munda të qetësoja shqetësimet e mia duke testuar këtë zbatim në Internet Explorer 6, për shembull, dhe shfletuesit në të cilët HSTS nuk zbatohet thjesht injorojnë kokën. Perfekte!

Thjesht shtoni rreshtat e mëposhtëm në fund të /etc/nginx/perfect-forward-secrecy.conf dhe ruani ndryshimet:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# This will prevent certain click-jacking attacks, but will prevent
# other sites from framing your site, so delete or modify as necessary!
add_header X-Frame-Options SAMEORIGIN;

Një ringarkim (në vend të një rifillimi) do të mjaftojë për të detyruar NGINX të marrë këto ndryshime të veçanta:

service nginx reload

Është e mundur të konfirmohet se HSTS po funksionon siç synohet duke testuar zbatimin tuaj në https://www.ssllabs.com/ssltest/analyze.html. Nëse HSTS zbatohet në mënyrë korrekte, duhet të shihni një kuti jeshile pak poshtë rezultatit tuaj, duke deklaruar, \Ky server mbështet HTTP Strikt Transport Security me kohëzgjatje të gjatë. Nota është vendosur në A+.\

urime!

Tani keni një nga implementimet më të sigurta të SSL/TLS në internet.

Referencat:

https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy