Solutii de securitate pentru sistemele distribuite la nivel de sesiune SSL (Secure Sockets Layer) Martin Sergiu

Martin Sergiu Informatica aplicata in stiinte, tehnologie si economie Universitatea Aurel Vlaicu Arad

Abstract
Odata cu raspandirea sistemelor distribuite si a WEB-ului, necesitatea securizarii acestora a devenit tot mai mare. Protocolul SSL a aparut ca raspuns la aceasta cerinta. Lucrarea de fata are ca si scop prezentarea acestui protocol, modul sau de functionare, cat de performant este, riscurile asociate SSL-ului si nu in ultimul rand un scurt istoric si evolutia sa. Desi SSL-ul nu este singurul protocol de acest gen, este totusi unul din cele mai raspandite si des utilizate de site-urile care opereaza diverse tranzactii (financiare, bancare) care contin date secrete si/sau importante (parole, informatii personale, informatii financiare, etc).

1. Introducere

Sistemele distribuite au numeroase avantaje din care amintesc facilitatea schimbului de informatii, partajarea resurselor scumpe, fiabilitatea marita in functionare, cresterea performantei prin paralelizarea calcului, scalabilitatea. Totusi, aceste sisteme au si dezavantaje iar unul din cele mai mari dezavantaje e securitatea lor. Nu e de mirare deci, ca odata cu raspandirea acestor sisteme distribuite a existat o nevoie tot mai mare de imbunatatire a securitatii lor. Principalele solutii de securitate pentru informatiile din Internet sunt: la nivel de retea: s-a dezvoltat o arhitectura de securitate la nivel de IP si la nivel de protocolul TCP/IP (Transmision Control Protocol/ Internet Protocol); la nivel de sesiune: se foloseste deseori protocolul SSL (Secure Sockets Layer), care ofera servicii de securitate chiar deasupra nivelului TCP, folosind criptosisteme cu chei publice si secrete, astfel incat sa asigure confidentialitatea, integritatea si autenticitatea clientului sau serverului din sistem. In aceasta lucrare ma voi concentra pe securitatea la nivel de sesiune. Unul din cele mai folosite si raspandite protocoale este SSL (Secure Sockets Layer).

2. Ce este SSL?
SSL este un protocol de securitate care asigura comunicatii confidentiale prin Internet. El permite aplicatiilor client/server sa comunice, in asa fel incat sa fie evitata interceptarea, modificarea sau falsificarea mesajelor.
Altfel spus Secure Sockets Layer (SSL) si Transport Layer Security (TLS), succesorul sau, sunt protocoale criptografice care permit comunicatii sigure pe Internet. SSL (Secure Sockets Layer) este un acronim care reprezinta un protocol web dezvoltat de compania Netscape pentru a transmite fara risc documente private prin Internet. Pentru a cripta datele SSL utilizeaza un sistem criptografic cu doua chei: una publica, cunoscuta de oricine, si una privata, secreta, cunoscuta numai de destinatarul mesajului. Majoritatea browserelor web suporta SSL, si multe site-uri web utilizeaza protocolul de utilizator pentru a transmite informatii confidentiale, cum ar fi numerele de carduri de credit. Prin conventie, URL-ul care are nevoie de o conexiune SSL incepe cu https: (in loc de http:).

SSL asigura autentificarea endpoint-urilor si confidentialitatea comunicatiei prin Internet folosind criptografia. In utilizarile uzuale, numai serverul este autentificat (identitatea sa este certificata), in timp ce clientul ramane neautentificat; autentificarea mutuala presupune existenta unei mecanism de distributie a cheilor publice (PKI) catre clienti. Protocolul permite aplicatiilor de tip client-server sa comunice securizat pentru a impiedica falsificarea autentificarii prin metodele numite eavesdropping, tampering si message forgery. SSL implica mai multe faze intermediare: verificarea mutuala de suportare a protocolului schimbarea cheilor prin intermediul criptarii prin metoda cu chei publice si autenficare pe baza de certificate trasmiterea de trafic criptat prin sistemul cheilor asimetrice

In timpul primei faze a protocolului serverul si clientul negociaza asupra algoritmului de criptare ce va fi folosit. Implementarile curente permit urmatoarele posibilitati:

criptografia bazata pe chei publice: RSA, Diffie-Hellman, DSA sau Fortezza; pentru codari simetrice: RC2, RC4, IDEA, DES, Triple DES sau AES; pentru functii de hash unidirectional: MD5 sau SHA.

3. Mecanismul de functionare

SSL este un sistem de criptare sofisticat care nu cere clientului si serverului sa asigure o cheie secreta pentru a fi schimbata intre client si server inainte ca tranzactia sa fie pornita. SSL foloseste key publice/private pentru a oferi un sistem de criptare flexibil, care poate fi setat in momentul tranzactiei securizate. In sistemele de criptare tipice, clientul si serverul sunt nevoiti sa foloseasca o cheie secreta care a fost preconfigurata pe masinile lor. Intr-un astfel de sistem, clientul va utiliza cheia secreta pentru criptarea datelor. Serverul va folosi aceeasi cheie secreta pentru a decripta datele. Aceeasi logica se aplica pe server spre directia clientului. Acest tip de chei preconfigurate secrete nu sunt potrivite pentru servicii web securizate , ce implica milioane de utilizatori care nu au nici aranjament prealabil a cheielor secrete cu serverul securizat. Protocolul SSL rezolva aceasta problema prin utilizarea cheilor asimetrice. Aceste chei sunt definite in perechi de chei publice si private. Dupa cum sugereaza si numele, cheia publica este disponibila gratuit pentru oricine. Cheia privata este cunoscuta doar de server care are nevoie de un certificate digital si o cheie privata corespunzatoare. Cel mai mare distribuitor de

certificate pentru server este VeriSign. Obtinerea si instalarea unui certificat SSL de la VeriSign presupune un proces in mai multi pasi: generarea unei cereri, trimiterea unui Certificate Signing Request (CSR), completarea unui formular prin care se autentifica un utilizator sau o afacere, instalarea identificatorului de server si activarea SSL pentru serverul Web. Autentificarea prin VeriSign presupune si verificarea datelor trimise de organizatia care necesita un certificat. Inainte de stabilirea unei sesiuni SSL, clientul trebuie sa cunoasca de asemenea acest protocol. In

momentul existentei elementelor necesare, clientul si serverul pot stabili o conexiune securizata. Aceste chei de care am vorbit prezinta doua propietati importante: 1. Datele criptate de catre client folosind cheia publica, pot fi decriptate doar de cheia server-ului
privat. Datorita acestei proprietati a cheielor, clientul este capabil sa transmita date securizate, care pot fi intelese numai de catre server.

2. Datele criptate de catre cheia de pe serverul privat, pot fi decriptate folosind cheia publica.
Aceasta proprietate este utila la nivelul clientului in timpul autentificarii pe server. Daca serverul trimite un mesaj cunoscut (spune numele serverului), clientul poate fi sigur ca comunica cu serverul de autentificare si nu cu un impostor. Proprietatea (1) ne permite sa utilizam cheile secrete conventionale. O cheie secreta poate fi trimisa de catre client ca si datele care au fost criptate utilizand cheia publica. Aceasta cheie secreta poate fi decriptata doar de catre server. Dupa ce serverul primeste cheia, clientul si serverul sunt in masura sa comunice utilizand aceasta cheie. Criptarea bazata pe cheile publice/private, este folosita doar pentru handshaking si schimbul de chei secrete. Dupa ce cheile au fost schimbate, cheile simetrice sunt puse in functie. Acest lucru se face din doua motive:

1. Tehnica de criptare bazata pe cheile publice/private, este foarte scumpa, si prin urmare
utilizarea lor ar trebui redusa la minimum.

2. Mecanismul cu chei secrete, este necesar pentru a servi comunicarii serverului cu clientul. In continuare voi prenta pasii pe care ii contine o sesiune SSL. Voi lua un exemplu concret. Utilizatorul acceseaza URL https://www.ebanking.com. O conexiunea securizata este necesara pentru aceasta sesiune. Browser-ul stabileste o conexiune TCP pe portul 443 TCP HTTPS. In acest moment incepe realizarea legaturii SSL pe noua conexiune TCP prin urmatorii pasi: CLIENT_HELLO - clientul trimite un mesaj CLIENT_HELLO spre server. Mesajul include cea mai recenta versiune de SSL si TLS suportata de client, cifrul suportat de client (enumerat in regim preferential), identificatorul sesiunii, metoda de compresie suportata si datele generate aleator de catre client care stau la baza calculelor criptografice.

SERVER_HELLO - serverul raspunde cu un mesaj SERVER_HELLO. Acest mesaj contine numarul de versiune al protocolului, setarile cifrului, date generate aleator, metoda de compresie si identificatorul de sesiune.

SERVER_KEY_EXCHANGE imediat dupa trimiterea lui SERVER_HELLO, serverul trimite catre client un mesaj de tip SERVER_KEY_EXCHANGE care contine certificatul cu cheia publica. In cazul in care sunt necesare si certificate din partea clientilor este generata o cerere in acest sens.

SERVER_HELLO_DONE serverul trimite acest mesaj final prin care indica finalizarea negocierii initiale.

CLIENT_KEY_EXCHANGE clientul raspunde cu acest mesaj care consta in cheia simetrica a sesiunii, criptata cu cheia publica a serverului primita la pasul 3 (SERVER_KEY EXCHANGE). In acest moment atat clientul cat si serverul sunt in stare sa calculeze cifrul sesiunii SSL.

CHANGE_CIPHER_SPEC in acest pas clientul trimite catre server acest mesaj prin care specifica ce setari de securitate ar trebui utilizate, cifrul stabilit anterior. FINISHED acest mesaj este trimis de client precizand ca din partea sa protocolul de negociere s-a incheiat cu success si in acelasi timp valideaza ca nici una dintre comenzile trimise anterior nu au fost modificate in timpul tranzactiilor

CHANGE_CIPHER_SPEC serverul raspunde afirmativ cu un mesaj de acelasi tip CHANGE_CIPHER_SPEC, precizand ca se activeaza optiunile de securitate cerute de client

FINISHED serverul trimite si el un mesaj FINISHED, permitand clientului sa verifice optiunile de securitate activate. Dupa trimiterea acestui mesaj negocierea este finalizata, iar conexiunea este stabilita. In continuare toate comunicatiile sunt criptate, pana la terminarea sau finalizarea sesiunii.

Toate aceste operatiuni pot fi vizualizate (pentru o intelegere mai clara) in poza de mai jos:

Protocolul SSL/TLS suporta mai multi algoritmi de criptare cu cheie secreta, printre care DES, Triple-DES,IDEA, RC2 si RC4. Cel mai puternic dintre acestia foloseste triplu DES cu trei chei separate pentru criptare si SHA-1 pentru integritatea mesajului. Aceasta combinatie este relative lenta, asa ca de cele mai multe ori este folosita doar pentru operatii bancare si alte aplicatii in care este necesar cel mai mare nivel de securitate. Pentru aplicatii obisnuite de comert electronic este folosit RC4 cu o cheie pe 128 de biti pentru criptare si MD5 pentru autentificarea mesajului. RC4 foloseste cheia de 128 de biti ca punct de plecare si apoi o extinde la un numar mult mai mare pentru uzul intern. Algoritmii cunoscuti pentru schimbarea cheilor cuprind Diffie-Hllman si RSA.

4.Performantaa SSL

Daca SSL ofera o asemenea securitate, intrebarea care se ridica este de ce nu se cripteaza intregul trafic? Desi in esenta este o idee buna, trebuie prezicat ca in procesul de criptare si stabilire a unei conexiuni SSL este implicat si foarte mult trafic aditional, din cauza naturii protocolului HTTP care creeaza o noua sesiune pentru fiecare obiect cerut dintr-o pagina Web. De exemplu, intr-o simpla tranzactie in care browser-ul cere o singura pagina de text cu patru imagini, genereaza cinci cereri GET (una pentru pagina si patru pentru imagini). Prin utilizarea SSL, pentru fiecare din aceste sesiuni trebuie negociate chei separate de criptare. Pentru a inrautatii si mai mult lucrurile, utilizatorii frustrati de timpul de raspuns reincarca pagina in browser-ul Web (refresh), generand si mai multe conexiuni SSL. Pentru imbunatatirea performantelor SSL se pot aplica urmatoarele: utilizarea de acceleratoare de criptare hardware, proces care nu necesita rescrierea paginilor Web sau achizitionarea de servere aditionale; utilizarea de pagini SSL simple, cu cat mai putine imagini; utilizarea SSL numai pentru anumite pagini Web selectate, precum acelea prin care se trimit informatii privitoare la cartile de credit; cache-ingul conexiunilor SSL permite de asemenea imbunatatirea performantelor, deoarece stabilirea unei noi conexiuni necesita de cinci ori mai mult timp decat reconectarea la o sesiune pastrata in cache. Cutoate acestea, activarea sesiunilor SSL in cache este dificil de implementat - daca timpul de expirare este stabilit prea mare, serverul poate consuma prea multa memorie prin pastrarea conexiunilor neutilizate. De asemenea cache-ul conexiunilor nu ar putea fi dezirabil din punct de vedere al securitatii paginilor dintr-un site. De exemplu, o aplicatie bancara online ar trebuie sa favorizeze securitatea si nu sa activeze cache-ingul conexiunilor.

5.Riscuri de securitate in SSL

Exista totusi si riscuri de securitate chiar si atunci cand se foloseste SSL. Voi enumera cateva dintre ele: SSL nu ofera nici o protectie in afara sesiunilor, iar serverele Web care permit utilizarea SSL nu pot sa ofere protectie pentru date care sunt stocate in format text in server. SSL nu ofera protectie impotriva atacurilor bazate pe Web precum exploatarea diverselor puncte slabe prin scripturi CGI. SSL nu ofera nici un mecanism pentru controlarea drepturilor de securitate (ceea ce ii este permis unei persoane sa faca dupa autentificarea pe un server). SSL nu protejeaza impotriva atacurilor de tip Denial of Service si ramane vulnerabil la analiza traficului. Deci, desi SSL ofera un grad de siguranta in plus, nu este un sistem complet sigur. Pentru a arata acest lucru Moxie Marlinspike, specialist in securitate, a demonstrat cum pachetele pot fi
interceptate iar encriptia evitata. O solutie pentru aceasta procedura este SLLstrip, aplicatia sa, care intervine in comunicatiile dintre client si server, functionand pe aceleasi principii ca un atac MItM (Manin-the-middle). Aplicatia se pune intre requesturile facute de tine si server, comunicand cu serverul criptat iar cu tine in text lizibil. Realizatorul aplicatiei a facut o demonstratie intr-un nod de iesire

din Tor, ce rula SSLstrip. Acesta s-a comportat exemplar si a aflat datele de autentificare a numeroase conturi. Pentru a oferi un nivel de securitate adecvat, serverele care lucreaza cu SSL ar trebui sa suporte criptarea pe 128 biti si o cheie publica pe 1024 biti. Certificatele la nivel de server autosemnate pot oferi securitate, dar nu si autentificare. Un certificat auto-semnat nu este considerat sigur de catre masina client fara a executa anumiti pasi aditionali.

5. Istoria si evolutia SSL

Am prezentat ce inseamna si cum functioneaza protocolul SSL, dar cum si de ce a fost nevoie de acest protocol? Trebuie sa mentionez ca atunci cand WEB-ul a intrat in atentia publicului el era folosit pentru distributia de pagini statice. Nu dupa mult timp, cateva companii au avut ideea de a-l folosi pentru tranzactii financiare, cum ar fi de exemplu cumpararea de bunuri cu ajutorul cartilor de credit, operatiuni bancare online si schimburi electronice de actiuni. Aceste conexiuni au creat o cerere pentru conexiuni sigure. Astfel, in 1995 compania Netscape Communications, furnizorul principal de navigatoare de web din acel moment, a raspuns acestei cereri prin introducerea unui pachet de securitate numit SSL (Secure Sockets Layer). Voi prezenta in continuare cum a evoluat acest protocol de securitate. SSL 1.0, 2.0 si 3.0 Destul de interesant, versiunea 1.0 nu a fost de fapt niciodata data spre folosinta publicului. Versiunea 2.0 a fost facuta publica in Februarie 1995 dar continea o serie de brese de securitate care in cele din urma au dus la proiectarea si dezvoltarea versiunii 3.0. SSL versiunea 3.0, facut public in 1996, a fost complet o schimbare radicala a protocolui existent si a fost realizat de catre Paul Kocher ajutat de inginerii de la Netscape, Phil Karlton si Alan Freier. Versiunile mai noi de SSL/TLS sunt bazate pe aceasta versiune 3.0. Schita din 1996 a acestui protocol a fost publicat de catre IETF (Internet Engineering Task Force) ca document istoric in RFC 6101. TLS 1.0, 1.1 si 1.2 TLS 1.0 a fost prima oara definit in RFC 2246 in Ianuarie 1999, si a fost conceput ca o imbunatatire a versiunii SSL 3.0. Dupa cum spune si documentul RFC, diferentele dintre cele 2 protocoale nu sunt immense , dar totusi sunt indeajuns de semnificabile incat TLS 1.0 si SSL 3.0 sa nu poata interopera. Totusi TLS 1.0 continea o modalitate de a scadea nivelul de securitate astfel incat sa ruleze la nivelul SSL 3.0

TLS 1.1 a fost definit in RFC 4346 in Aprilie 2006. Este o versiune mai noua fata de TLS 1.0. Principalele diferente fata de versiunea precedent sunt: a adaugat protectie impotriva atacurilor CBC (Cypher Block Chaining) schimbarea modului de a trata anumite erori TLS 1.2 a fost definit in RFC 5246 in August 2008 si a fost bazat pe versiunea precedent TLS 1.1. Cele mai notabile modifcari sunt: combinatia MD5-SHA-1 din functia pseudorandom si din mesajul de terminare a fost inlocuita cu SHA-256. combinatia MD5-SHA-1 in elementul semnat digital a fost inlocuita cu un singur hash negociat in timpul protocolului handshake. Imbunatatiri atat pe partea de client cat si de server astfel incat sa ofere posibilitatea specificarii a algoritmului de semnare si hash-ului pe care ii accepta. marirea suportului pentru cifruri de autentificare encriptata.

6.Concluzii
Odata cu cu raspandirea tot mai mare a sistemele distribuite si a Internet-ului, securitatea informatiilor a devenit esentiala atat pentru simplii utilizatori cat si pentru companiile financiare si bancare. Protocolul SSL a fost unul dintre primele raspunsuri la aceasta nevoie de securitate, si incepand din anul 1996 si pana in prezent a fost optimizat in mod permanent. Astfel, in momentul de fata protocolul SSL (si/sau TLS) promite o confidentialitate a informatiilor. Integritatea comunicarii este asigurata prin faptul ca se folosesc mesaje de autentificare in fiecare mesaj, chiar de la inceputul procesului de stabilire a legaturii (handshake). De asemenea validarea este facut prin folosirea certificatelor ca un plus de securitate.

SSL si TLS sunt medode dovedite si efective de a securiza informatiile importante si pe masura ce tot mai multe informatii vor fi tot mai bine securizate, protocoalele de comunicare securizata vor pune la dispozitie programatorilor de sisteme distribuite tot mai multe instrumente si aplicatii de implementat.

Bibliografie
Andrew S. Tanenbaum Retele de calculatoare, editia a patra, Editura Byblos, Bucuresti, 2003 Ioan Dzitac, Grigor Moldovan Sisteme distribuite, Modele informatice, Editura Universitatii Agora, Oradea, 2006

Webografie
Popa Sorin Eugen Securitatea sistemelor informatice, disponibil la http://www.scribd.com/doc/55573866/Curs-SSI-Fara-parola Cum functioneaza SSL - disponibil la http://linuxinfo.md/?p=207 Securitata nivelului de transport disponibil la http://ro.wikipedia.org/wiki/Securitatea_nivelului_de_transport , http://en.wikipedia.org/wiki/Transport_Layer_Security