Dacă aveți un server web securizat, utilizatorii care sunt îngrijorați de securitatea datelor lor pot fi siguri că cererile sunt criptate, astfel încât datele lor sunt sigure. Cel mai bun mod de a face acest lucru este să utilizați Apache 2, cel mai important server web pentru Linux și Secure Sockets Layer, un protocol securizat de transfer de date. Transport Layer Security (TLS) este o evoluție a SSL, dar funcționează aproape identic. Mă voi referi doar la SSL.
SSL este un protocol pentru transferul securizat de date criptate între un browser web și un server web. În majoritatea cazurilor, serverul este autentificat, ceea ce permite clientului să se asigure că serverul este solicitat de acesta și nu invers. Cu toate acestea, atunci când conexiunea este stabilită, ambele părți sunt sigure, deoarece numai clientul și serverul au acces la cheie. Acest lucru funcționează pentru mai multe interogări, serverul nu are grijă ce este clientul atâta timp cât acesta rămâne același client pe durata cererii. Dacă sunteți îngrijorat de autentificarea clientului, puteți utiliza certificatele client SSL (sau htaccess, Kerberos sau alte metode apropiate acestora), dar acest lucru nu va fi luat în considerare în acest articol.
Fiind pe partea clientului, vă pasă dacă persoana (serverul) pe care o trimiteți orice date personale pe care doriți să le criptați. Prin urmare, serverul, nu clientul, este autentificat. De asemenea, sunteți preocupat de participarea unei terțe părți la accesarea datelor dvs. în forma pe care le trimiteți. SSL oferă ambele tipuri de securitate.
Protocolul SSL funcționează după cum urmează:
1. Clientul se conectează la serverul web și oferă o listă cu codurile disponibile.
2. Serverul alege cel mai puternic cifrul pe care îl susține, și client, și trimite un certificat cu numele și criptare cheie, semnat de o încredere autoritate de certificare (autoritate de certificare, denumită în continuare - CA), cum ar fi Verisign.
3. Clientul verifică certificatul utilizând CA. În practică, setul CA este stocat local, astfel încât acesta poate fi realizat fără un contact în timp real cu CA și, prin urmare, mai rapid.
4. Clientul trimite un număr aleatoriu criptat cu cheia publică a serverului. Numai clientul cunoaște acest număr, iar numai serverul îl poate decripta (folosind o cheie privată); în acest caz securitatea provine de la terți.
5. Serverul și clientul utilizează un număr aleator pentru a genera conținutul cheie care este utilizat în întregul transfer de date.
Vrem să facem acest lucru pe partea clientului cât mai transparent posibil pentru a face transferul de date cât mai ușor posibil.
Primul pas este crearea unui certificat. Puteți crea un certificat cu sau fără o parolă. Principalul inconvenient al utilizării unei parole este faptul că trebuie introdus de fiecare dată când serverul pornește. Prin urmare, nu poate fi pornit nesupravegheat sau automat la pornire, de exemplu, după oprirea alimentării cu energie electrică. În funcție de setările dvs., acest lucru poate fi un fapt important pentru dvs. sau nu.
Teoretic, avantajul utilizării unei parole este de a crește protecția. Deși, în practică, parolele nu oferă o protecție atât de mare. Dacă cineva poate citi sau copia o cheie privată, atunci are deja acces la sistem și posibilitatea de a obține o parolă, de exemplu, folosind un program, cum ar fi un keylogger. Parola va fi protejată de script-kiddi, dar nu de o crăpătură serioasă. Poate pentru majoritatea oamenilor nu are rost să-l folosești.
În scopuri de testare sau pentru o rețea locală mică, puteți crea un certificat pe care l-ați semnat. Puteți face acest lucru executând comanda:
Problema cu utilizarea unui certificat semnat independent pentru un server care rulează în timp real este că orice browser care lucrează cu site-ul nu va recunoaște certificatul ca valabil. Aceasta înseamnă că utilizatorul va cere confirmarea certificatului. Evident, în cele mai multe cazuri aceasta nu este o soluție optimă. Deși acest lucru este normal în scopuri de testare, iar pentru rețele locale mici ar fi o opțiune proastă de a plăti un certificat de la CA.
Cu toate acestea, cu siguranță este mai bine să folosiți un certificat semnat de o autoritate de certificare de încredere, cum ar fi Verisign (care are cea mai mare acoperire pe piață) sau o organizație mai mică. Majoritatea browserelor au deja un set de certificate pre-instalate certificate de CA care verifică certificatul serverului dvs. Web atunci când clientul se conectează. Acest lucru reduce numărul de dificultăți pentru utilizatorul final și certifică legitimitatea site-ului dvs.
Pentru a obține un certificat semnat de CA, trebuie mai întâi să creați o pereche criptografică și să solicitați un certificat:
Cheia server (fișier server.key, care, din nou, ar trebui să fie citit numai pentru root) rămâne pe serverul dvs. web; Solicitarea (fișierul www.example.com.csr) este trimisă la CA. Puteți numi fișierul de solicitare așa cum doriți, dar numind-o în funcție de numele domeniului, simplificați sarcina pentru CA.
Următorul pas este să trimiteți acest fișier la www.example.com.csr în CA, cu plata dvs. Ar trebui să-l returneze destul de repede dacă ați furnizat toate informațiile necesare în cererea dumneavoastră. CA-ul pe care îl alegeți îți va explica acțiunile pe site-ul tău. Este posibil să fie necesar să modificați formatul de fișier la PEM, dar, în cazul Verisign, nu trebuie să faceți acest lucru.
Când primiți fișierul înapoi în format PEM, redenumiți-l la server.crt (aceasta nu este o necesitate strictă, dar corespunde condițiilor Apache) și verificați-l:
Apoi, verificați dacă rezultatul acestor două comenzi este același, adică că certificatul corespunde unei chei private:
Acum, instalați cheia (generată mai sus ca server.key) și certificatul (server.crt) în / etc / apache2 / ssl sau în directorul de setări preferat, dacă este diferit. După cum sa menționat mai sus, este foarte important să vă asigurați că server.key este citit numai pentru root, în timp ce certificatul de server poate fi citit pentru lume, dar trebuie să fie deținut și scris numai pentru root.
Compilarea Apache cu SSL.
Deci, certificatul dvs. este generat. Acum trebuie să configurați serverul să îl folosească.
Pentru marea majoritate a persoanelor, cea mai bună modalitate de a instala și de a administra Apache2 este prin intermediul managerului de pachete al distribuției. Apache2 din Debian vine cu modulul SSL, dar nu este activat în mod implicit. Pentru ao activa, trebuie să executați comanda: a2enmod ssl și reporniți serverul web.
Pentru aceasta, adăugați o linie
în /etc/apache2/apache2.conf (acest fișier poate fi, de asemenea, numit httpd.conf). Trebuie să remediați acest lucru specificând locația corespunzătoare a fișierului mod_ssl.conf. Apoi, reporniți serverul web.
Dacă doriți să compilați Apache2 de la codul sursă, în funcție de ce opțiuni pe care le-au utilizat anterior, este posibil să aveți deja sau să nu aibă suport SSL. Verificați acest lucru cu comanda apache2 -l. Dacă trebuie să recompilați, rulați ./configure cu toate opțiunile pe care le-ați utilizat înainte, adăugând la ea enable-ssl și --enable-setenvif (acesta din urmă este necesară pentru compatibilitatea cu capriciile de Internet Explorer). Apoi, instalați-l ca de obicei, cu make, faceți instalarea și verificați dacă permisiunile sunt corecte.
Configurarea Apache cu SSL.
Următorul pas este să configurați Apache2. Următoarele instrucțiuni vor conduce la lansarea serverului ca securizat (port 443), și ca un server web obișnuit (portul 80). Mai întâi, trebuie să configurați serverul să accepte cererile pentru ambele porturi. Sau edita /etc/apache2/ports.conf (în Debian, intră apache2.conf), sau edita /etc/apache2/apache2.conf, inclusiv linii:
Apoi, modificați / etc / apache2 / sites-enabled / site-ul dvs. pentru a utiliza setările SSL. Separarea setărilor unui server normal și securizat folosind VirtualHost este cea mai ușoară cale din motive de utilizare. Orice setări în afara secțiunilor VirtualHost (de exemplu, instalarea ServerAdmin) vor fi aplicate atât (cât și oricăror altor) VirtualHost. Adăugați următorul text în fișierul de configurare:
Câteva note despre această configurație:
- SSLEngine trebuie să fie activat, indicând faptul că serverul utilizează SSL.
- DocumentRoot stabilește directorul rădăcină al gazdei virtuale. Aceasta înseamnă că puteți separa conținutul sigur de cel obișnuit.
- SSLRequireSSL solicită utilizarea SSL (pe acest server virtual), adică utilizatorul nu se poate conecta la această gazdă virtuală utilizând o solicitare HTTP normală. De aceea am împărtășit conținut sigur și normal.
- SSLProtocol dezactivează toate protocoalele, altele decât TLS v1.0 și SSL v3.0. Pentru browserele moderne, totul va funcționa bine.
- SSLCipherSuite stabilește numai cifrele HIGH și MEDIUM. SHA1 este considerat mai sigur decât MD5, deci este selectat.
- SSLCertificateFile și SSLCertificateKeyFile specifică locația certificatului și a fișierelor cheie.
- SSLVerifyClient trebuie setat la "none" dacă nu utilizați autentificarea prin eșantion.
Pentru a rula un server normal pe portul 80, adăugați următorul text în fișierul de configurare:
După salvarea fișierului de configurare editat, reporniți serverul. Dacă ați utilizat o parolă la generarea unui certificat, va trebui să o introduceți când vi se solicită.
Creați o pagină de bază index.html în directorul rădăcină al serverului dvs., dacă nu aveți deja conținut acolo.
Dacă aceasta nu funcționează așa cum era de așteptat, mai întâi, verificați dacă serverul dvs. a început în general să folosească comanda ps -a | grep apache. Dacă nu returnează rezultatul, încercați să reporniți serverul și să verificați mesajele de eroare din consola.
De asemenea, verificați dacă drepturile de acces la certificat și fișiere cheie sunt setate corect (vezi mai sus), precum și drepturile la fișierul HTML de test și la directorul în care este localizat.
Apoi, verificați jurnalele. Ar trebui să verificați atât jurnalele de server și jurnalele SSL pe care le-ați configurat în fișierul de configurare de mai sus. Dacă nu ați găsit nimic util acolo, încercați să modificați valoarea LogLevel din fișierul de configurare Apache2 pentru a "debuga", reporniți Apache2 și testați din nou. Acest lucru ar trebui să dea mai multe date în jurnalele.
Dacă problema este într-o conexiune SSL, s_client este instrumentul convenabil, care este un utilitar de diagnosticare pentru rezolvarea problemelor în conexiunile TLS / SSL. Utilizarea obișnuită este: / usr / bin / openssl s_client -connect localhost: 443. Există, de asemenea, multe alte opțiuni pe care le puteți învăța din documentație. Dacă primiți mesaje de eroare, acest lucru vă va ajuta să determinați problema.
Felicitări! Acum aveți un server de lucru sigur, cu un certificat care este verificat automat de majoritatea browserelor moderne.
Trimiteți-le prietenilor: