Tehnologii Web

Iulian ILIE-NÉMEDI
inemedi@ie.ase.ro
 Despre mine

bănățean
zodia leu
 Evaluare
• Seminar:
– Teme pe parcurs: 4 teme (1p);
– Proiect în echipă (3 membri): aplicație SPA (4p).
• Examen pe calculator:
– Implementarea unei aplicații acasă (5p);
– Înregistrarea unui filmuleț cu explicații.
• Condiții de cumulare a punctajelor la seminar și
examen:
– Minim 2p la seminar și 2p în examen;
– Minim 4.5p însumate.
Ce vom învăța?
Bibliografie
 Dezvoltarea aplicațiilor Web

• Inițial serverele Web livrau conținut static publicat pe

calculatorul server;
• Ulterior serverele Web au fost folosite ca platformă pentru
a găzdui medii de execuție care să genereze răspunsul în
mod dinamic;
• Legarea mediului de execuție de un server Web se poate
face în două moduri:
– Ca proces extern:
• Common Gateway Interface (CGI);
– Ca modul în procesul server:
• Server Application Programming Interface (SAPI).
 Generații de aplicații Web
Web 1.0 Web 2.0 Web 3.0 Web 4.0
• Aplicațiile constau • Aplicațiile constau • Aplicațiile constau • Aplicațiile expun
în mai multe pagini în mai multe pagini într-o singură API-uri REST care
care se încărcau pe care se încărcau pe pagină care își pot fi consunate de
rând; rând; încarcă pe rând clienți IoT și Cloud;
• Trebuia menținută • Clientul menținea resursele și datele; • Protocolul de
starea între pagini; starea aplicației și • Starea aplicației aplicație permite
• Logica aplicației era putea face cereri este gestionată în streaming-ul de
implementată pe asincrone de client dar și se date bidirecțional
server; resurse către server; între clienți de pe
• Nu exista o server; • Aplicația este platforme software
separația clară între • Modelul putea fi implementată cu o eterogene în timp
model, afișare și salvat fără să separație clară între real;
încărcare; trebuiască model-view- • Aplicațiile rulează în
• Pentru a salva o reîncărcată pagina; controller; Cloud în containere
mică modificare • Aplicația server mu • Navigarea se face cu și sunt scalate
trebuia apoi putea fi consumată routere client care automat;
reîncărcată toată decât de clientul ei; aduc view-uri și • Tehnologiile Web cu
pagina; • Comunicația era date din server; care sunt dezvoltate
• Comunicația era inițiată în • Comunicația poate nu mai rulează doar
inițiată doar de continuare doar de fi de acum inițiată și în browser, ci si pe
browser. browser. de server nu numai dispozitive mobile
de browser. în mod nativ.
1995 2000 2005 2015
 Construirea unei aplicații Web

• Server: NodeJS
– Acces la date cu ORM;
– API REST cu ExpressJS.
• Client: ReactJS
– Componente;
– Rutare pe client;
– Flux de date / evenimente;
– Validare formulare;
– Gestiunea erorilor;
– Internaționalizare.
Protocolul HTTP
 Descriere generală

• Protocol de nivel de aplicație;

• Protocol cerere-răspuns;
• Comunicare sincronă;
• Date transmise în mod mixt:
– Antete – text;
– Corp – binar.
• Inițierea comunicației se face doar de către client;
• Protocol în principiu fără starea conexiunii.
 Comunicare sincronă

• Sesiunea HTTP este formată din cererea clientului și

răspunsul serverului;
• Nu se menține stare între cereri succesive;
• Pentru menținerea stării unei aplicații se utilizează
header-ele (fie prin sesiuni sau prin cookies);
• După ce face cererea, clientul așteaptă un răspuns;
• La primirea răspunsului, clientul încarcă conținutul
primit;
• Alternativa este AJAX prin care se menține o conexiune
HTTP deschisă și se verifică starea conexiunii.
 Servere Web

• Livrează resurse Web;

• Execută cod prin intermediul unor containere;
• Suportă virtual hosting, securitate, etc.;
• Apache, NGINX, IIS, etc.
Analiza traficului
cu Wireshark
 Resurse Web

• Nu neapărat fișiere;
• Nu neapărat text (deși resursele binare sunt
encodate ca text);
• Tipul resursei este definit prin tipuri MIME;
• Două perspective asupra resursei:
– La distanță;
– Locală.
 Scheme de localizare
• URI (Uniform Resource Identifier)
– Identificatorul unic al unei resurse;
– Există două tipuri de URI: URL și URN.
• URL (Uniform Resource Locator):
– Locația unică unei resurse de forma:

• URN (Uniform Resource Name):

– Numele unic al unei resurse de forma:
 URL
• Forma generală:
– schema://server:port/cale?parametri#fragment
– schema de nume: identifică protocolul utilizat care determină și
forma URL-ului;
– server: numele sau adresa serverului, se pot obține unul din altul
prin intermediul DNS (Domain Name Service);
– port: identifică aplicație pe calculatorul destinație; browser-ul
presupune portul 80 (portul tipic), dar se poate utiliza orice port
neocupat;
– parametri: listă de perechi cheie-valoare separate de & de
exemplu: name=Iulian&age=42
– fragment: identifică în principiu poziția în interiorul documentului.
 Cererea HTTP
• O linie de cerere care specifică metoda și adresa
resursei;
• Un număr oarecare de antete;
• O linie goală;
• Opțional, un corp de request.
GET /website/template/photography/ HTTP/1.1
Accept:*/*              
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)
Host: www.httpwatch.com
Connection: Keep-Alive
 Metode HTTP
• GET: întoarce conținutul unei resurse identificată
printr-un URL;
• POST: se folosește pentru a trimite date către server;
• PUT: solicită salvarea entității trimise pe server la o
adresă URL;
• PATCH: aplică modificări parțiale asupra unei
resurse;
• DELETE: solicită ștergerea entității identificate printr-
un URL;
 Metode HTTP
• HEAD: verifică existența unei entități fără o
întoarce conținut;
• TRACE: permite clientului să verifice cum sunt
recepționate datele în scopul testării și
diagnosticării recepției;
• CONNECT: se folosește în combinație cu proxy
pentru a realiza în mod automat un tunel;
• OPTIONS: se utilizează pentru a obține informații
privind modul cum se va realiza comunicarea cu
resursa destinație.
 Antete HTTP

• Contextul cererii:
– Host: numele sau adresa mașinii căreia îi este adresată cererea;
– Referer: pagina anterioară care a declanșat navigarea la resursa
curent solicitată;
– User-Agent: descrie aplicația și mediul de execuție care a trimis
cererea;
• Autentificare:
– WWW-Authenticate: definește modul de autentificare pentru
accesul la resurse;
– Authorization: precizează credențialele de acces;
– Proxy-Autehnticate: definește modul de autentificare cerut de proxy;
– Proxy-Authorization: credențialele pentru acces prin proxy.
 Antete HTTP

• Negocierea conținutului:
– Accept: tipul de resursă acceptată ca răspuns;
– Accept-Charset: setul de caractere în care se așteaptă
conținutul răspunsului;
– Accept-Encoding: tipul de condificare a răspunsului;
– Accept-Language: limba răspunsului.
• Gestiunea conexiunii:
– Connection: permite păstrarea conexiunii după
încheierea transacției curente;
– Keep-Alive: controlează durata cât va rămane deschisă
conexiunea.
 Antete HTTP

• Informații despre corpul mesajului:

– Accept-Ranges: unitatea de măsură pentru dimensiunea
corpului mesajului;
– Content-Length: dimensiunea corpului mesajului;
– Content-Type: tipul resursei conform standardului MIME;
– Content-Encoding: codificarea corpului mesajului;
– Content-Language: limba în care este scris conținutul
mesajului;
– Content-Location: indica o adresă alternative a resursei
solicitate.
• Redirectare:
– Location: URL-ul la care este disponibilă resursa solicitată.
 Antete HTTP

• Gestiunea cache-ului și a cookie-urilor:

– Cache-Control: max-age=0, must-revalidate – cache-ul
client;
– Set-Cookie: _wixAB2=15361#2985#2014-08-05T13-30-
00.000-0500 – salvează un cookie pe client;
• Controlul accesului cross-domain:
– Access-Control-Allow-Origin: * - permite efectuarea de
cereri din client către alt domeniu decât cel de la care a
venit răspunsul;
• Antete proprii:
– X-Seen-By: sputnik3.aus_dsp – antet propriu.
 Răspunsul HTTP

• O linie de status, conținând codul de răspuns și

justificarea (corespunde codului);
• Un număr de headere de răspuns;
• O linie goală;
• Opțional, un corp de răspuns.
 Răspunsul HTTP
HTTP/1.1 200 OK
X-Seen-By: sputnik3.aus_dsp
X-Seen-By: s3.aus_pp
Date: Wed, 21 Aug 2013 09:02:49 GMT
Server: Apache
cache-control: max-age=604800
cache-control: no-cache
Pragma: no-cache
Set-Cookie: _wixAB2=5371#5567#2014-03-19T14-27-00.000-0500|15711#3472#2014-08-13T11-01-00.000;
Domain=.wix.com; Expires=Tue, 21-Aug-2018 14:06:39 GMT; Path=/
Vary: User-Agent,Accept-Encoding
Content-Language: en
Content-Encoding: gzip
Content-Length: 8162
Content-Type: text/html;charset=UTF-8
Expires: 0
Cache-Control: no-cache

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:og="http://ogp.me/ns#"
xmlns:fb="https://www.facebook.com/2008/fbml" >
<body></body>

• 1xx – Informare (serverul a
primit cererea însă nu a terminat
de procesat răspunsul):
– 100-continue.
• 2xx – Succes:
– 200-OK;
– 201-Created;
– 202-Accepted;
– 204-No Content.
• 3xx – Redirectare:
– 301-Moved Permanently;
– 302-Moved Temporarily;
– 304-Not Modified.
Coduri de răspuns
• 4xx – Erori client:
– 400-Bad Request;
– 401-Unauthorized;
– 403-Forbidden;
– 404-Not Found;
– 405-Method Not Allowed;
– 406-Not Acceptable.
• 5xx – Erori server:
– 500-Internal Server Error;
– 501-Not Implemented;
– 503-Service Unavailable;
– 504-Gateway Timeout.
 Redirectarea răspunsului
• Protocolul HTTP permite serverelor să redirecteze răspunsul
clientului către o altă locație.

301 Permanent redirect – Conținutul a fost mutat definitive la o nouă adresă astfel încât cererile
viitoare trebuiesc adresate către această locație.
302 Temporary Redirect – Cererile vor fi adresate în continuare către locația inițială.
303 See Other – Acest cod a fost introdus pentru a converti o cerere de tip POST la una de tip
GET, cu toate acestea multe browser-e tratează 302 ca 303.
304 Not Modified – Folosit ca răspuns la un antet If-Modified pentru a redirecta răspunsul către
cache-ul browser-ului.

HTTP/1.1 302 Found

Cache-Control: private,Public
Content-Length: 162
Content-Type: text/html; charset=utf-8
Location: /httpgallery/redirection/default.aspx#example
Set-Cookie: balance=990; path=/httpgallery/redirection/
 Conținut multimedia

• Acoperă text non-ASCII, imagini, video etc.;

• Definirea tipului de date se face prin tipuri MIME;
• Protocolul fiind fundamental un protocol text,
datele multimedia trebuie encodate text (Base64
encoding);
• Tipul se specifică prin header-ul Content-Type.
 Standardul MIME

• Standardul MIME (Multipurpose Internet Mail Extensions)

definește clase și subclase pentru tipurile resurselor livrate;
• Atât serverul cât și browserul folosesc aceste etichete pentru a
utiliza în mod corerspunzător resursele primite;
• Sintaxa: tip/subtip (* înseamnă orice tip sau subtip);
• Clase principale:
– text: text/plain;
– image: image/jpeg, image/png, image/gif;
– audio: audio/mpeg, audio/ogg, audio/*;
– video: video/mp4;
– application: application/json, application/xml.
• Se pot define subclase și clase propria prefixate cu x-nume.
 Trimiterea de
argumente în cererea HTTP

• GET: se folosește pentru a obține conținutul unei resurse după

URL fără a o modifica, fiind considerat sigur și idempotent:
– Trimite argumente sub forma parametrilor din Query String
sau ca și cookie-uri;
– Nu poate fi utilizat pentru a încărca fișiere sau pentru a
trimite un volum mare de date pe server.
• POST: se utilizează pentru a trimite un volum mare de date pe
server care modifică resursele, nefiind idempotentă:
– Argumentele sunt trimise în corpul cererii a cărui lungime
nu este limitată ci depinde doar de posibilitatea extragerii în
limita Connection-Timeout.
 Cerere de tip POST
POST /httpgallery/methods/default.aspx HTTP/1.1
Host: www.httpwatch.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://www.httpwatch.com/httpgallery/methods/
Cookie: __utma=1.1256977602.1377003403.1377082307.1377092487.5; __utmc=1;
__utmz=1.1377003403.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided);
__utmb=1.4.9.1377092850054
Proxy-Authorization: Basic b21lckB3aXguY29tOmg2M2ZycQ==
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
Set-Cookie: _wixUIDX=10647958|1a2c4034-469d-4f4d-bbd9-17deddaf67ec; Domain=.wix.com; Expires=Mon, 17-Feb-
2014 09:02:49 GMT; Path=/
Cache-Control: no-cache

Amount=10&B2=Submit
Trimiterea de cereri HTTP
utilizând Postman
 Cookie-uri
Serverul setează cookie-uri pe client
trimițând țn răspuns antetul set-cookie:
Set-Cookie: name=value

Name Numele cookie-ului

Value Valoarea text asociată numelui
Expires Data și ora la care cookie-ul va fi considerat expirat de către browser.
Dacă valoarea lipsește, browserul va considera cookie-ul expirat la
sfârșitul sesiunii curente. Acest câmp poate fi folosit pentru expirarea
cookie-ului dacă valoarea este un moment din trecut.
Path Calea resursei pentru care se va folosi cookie-ul.
Domain Adresa serverului pentru care se va folosi cookie-ul.
Încercarea de a aplica cookie-ul pentru alt domeniu decât cel curent
solicitat trebuie permisă explicit prin politici de securitate ale browser-
ului.
 Tipuri de cookie-uri

• Session cookie – identifică sesiunea curentă fiind șters la finalul

ei, acceptarea sa neputând fi blocată de browser;
• Persistent cookie – este valabil și după expirarea sesiunii
curente;
• Secure cookie – are setat atributul de Securitate fiind folosite
cu HTTPS;
• HttpOnly cookie – nu este accesibil aplicației client din
JavaScript;
• Third-party cookie – cookie-uri pentru alte domenii decât cel
current vizitat;
• Super-cookie – cookie-uri cu originea într-un domeniu din
rădăcina domeniilor Internet (.com).
 Cache-ul resurselor HTTP

• Cache-Control: no-cache (HTTP 1.1);

• Pragma: no-cache (HTTP 1.0).
• Last-Modified: Wed, 15 Sep 2004 12:00:00 GMT – se folosește de
către browser pentru actualizarea versiunii resursei în cache.
• Expires: Sun, 17 Jan 2038 19:14:07 GMT – browserul poate utiliza
conținutul resursei fără să-l mai solicite de pe server.
GET /images/logo.gif HTTP/1.1
Accept: */*
Referer: http://www.google.com/
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 23 Sep 2004 17:42:04 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1;)
HTTP/1.1 304 Not Modified
Host: www.google.com
Content-Type: text/html
Server: GWS/2.1
Content-Length: 0
Date: Thu, 04 Oct 2004 12:00:00 GMT
 Extensibilitatea HTTP

• Se pot defini propriile antete HTTP:

– Marcate în mod canonic prin prefixul X-nume;
– Se pot defini valori propria pentru antete existente;
– Unele antete pot să nu fie implementate.

• Se pot crea propriile metode HTTP:

– WebDAV (Web Distributing, Authoring and Versioning)
este o extensie HTTP care permite editarea resurselor
publicate pe un server Web cu un set nou de verbe;
– Unele metode pot să nu fie implementate.
 REST și JSON

• REST (REpresentational State Transfer):

– Acces la obiecte la distanță peste HTTP;
– Vocabular limitat;
– Identificarea semanticii prin URL.
• JSON (JavaScript Object Notation):
– Una dintre reprezentările native JavaScript
pentru obiecte;
– Simplă, nu necesită descrierea tipului.
 AJAX
Asynchronous JavaScript And XML

• AJAX este o tehnologie folosită de aplicațiile web interactive pentru

a face cereri HTTP către server fără a provoca tranziții de pagină;
• Cererile trebuie să meargă pe același domeniu ca și pagina.

<script type="text/javascript">
function GetShoppingList() 
{ 
    // Create an instance of the HTTP request object 
    var xmlHttp = new XMLHttpRequest(); 
    // Specify HTTP GET by default and supply the relative url 
    xmlHttp.open("GET", "getlist.aspx", false); 
     
   // Start a synchronous AJAX request and wait for the response 
    xmlHttp.send(null); 
    var targetNode = document.getElementById("divShoppingList"); 
    // Use the HTML returned from server to create list 
    targetNode.innerHTML = xmlHttp.responseText; 
}
</script> 
 CORS
Cross-origin Resource Sharing

• Permite aplicației JavaScript dintr-o pagină web să

facă apeluri XMLHttpRequests către alt domeniu;

• Clientul trimite mai întâi o cerere HTTP de tip

OPTIONS către resursa de pe celălalt domeniu, pentru
a determina dacă solicitarea este sigură de trimis;

• Dacă solicitările de domeniu încrucișat sunt făcute în

siguranță, atunci serverul va include în anteturile de
răspuns Allow-Control-*.
 CORS
Cross-origin Resource Sharing

OPTIONS /resources/post-here/ HTTP/1.1

Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre)
Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER
Access-Control-Max-Age: 1728000

POST /resources/post-here/ HTTP/1.1

Host: bar.other
…
 JSONP
JavaScript Object Notation with Padding
Pasul 1 - Se scrie funcție callback care
• Oferă o metodă așteaptă argumente de la server.
pentru a solicita date function w3r_callback(data){
de la un server dintr- console.log(data);
}
un domeniu diferit.Pasul 2 – Se include un script în pagina web care conține
funcția de apelare creată la pasul 1 ca parametru.
<script src="http://www.example.com?q=w3r_callback"><script>
• JSONP nu are nicio Pasul 3 – Răspunsul server- w3r_callback({
legătură cu Ajax, ului conține apelul funcției "FirstName" : "xyz",
cu argumentele așteptate "LastName" : "abc",
deoarece nu de la server. "Grade" : "A"
folosește }
XMLHttpRequest, ci );
include resurse
 Avantajele HTTP-ului

• Independent de platformă: permite portarea directă a

platformei.

• Nu are nevoie suport adițional pentru a rula pe orice

dispozitiv.

• Utilizabil pe firewall-uri: face posibile aplicații globale.

• Nu este orientat către conexiune: fără effort suplimentar

pentru a crea și menține starea și informațiile sesiunii.
 HTTP este fără stare

• Durata de viață a unei conexiuni corespunde unei secvențe de

cerere-răspuns unice:
– Un client HTTP deschide o conexiune TCP / IP la server printr-un
socket, transmite o solicitare pentru o resursă, apoi așteaptă un
răspuns de la server. După finalizarea secvenței cerere-răspuns,
conexiunea este închisă;
– Nu există „memorie” între conexiunile clientului;
– Implementarea pură a server-ului HTTP tratează orice solicitare
ca și cum ar fi fost nouă;
– Paginile HTTP sunt stocate pe cache-urile serverului și ale
clientului. Paginile se încarcă mai rapid, dar sunt stocate pe
sisteme pe care nu le controlăml, cum ar fi memoria cache a
proxy-ului de furnizorului conexiunii la Internet.
 Limitările HTTP-ului

• Probleme legate de securitate:

– Confidențialitate: oricine poate vedea conținut;
– Integritate: cineva poate modifica conținutul. HTTP nu este sigur,
deoarece nu sunt utilizate metode de criptare. Prin urmare, este
atacurilor de tip man-in-the-middle cu audierea informațiilor
sensibile;
– Autentificare: nu este clar cu cine vorbești. Autentificarea este
trimisă în clar, astfel încât oricine interceptează cererea poate
determina numele de utilizator și parola utilizate.

• Fără stare: necesită tehnici de gestionare a stării pentru a menține

informațiile pe mai multe cicluri de cerere-răspuns.
 Probleme cu HTTP-ul

CERERE GET index.html

RĂSPUNS

CERERE GET style.css

RĂSPUNS

CHI M BAT
NES
 Probleme cu HTTP-ul
• Timpul de răspuns devine mai lent atunci
când numărul resursele solicitate crește.

Și fiecare tranzacție are

anteturi suprapuse.
 HTTP 2.0

• Elimină elementele blocante ale versiunii 1.1;

• Se pot cere mai multe resurse pe o conexiune, pe
care serverul le poate livra în orice ordine;
• Resursele se livrează în stream-uri de resurse și
sunt prioritizabile;
• De asemenea serverul poate trimite și resurse care
nu au fost încă cerute de client.
 Evoluția modelului
de comunicare
1991 Prezent
http://www.ibarakiken.gr.jp/www/index.html http://www.ocn.ne.jp/ https://www.facebook.com/

Resurse multiple
Resursă unică +
Resurse multiple Bi-directional
 SPDY în HTTP 2.0

Abordare HTTP 1.1 • SPDY (HTTP 2.0)

• Multiplexarea cererilor pe aceeași conexiune TCP;

• Compresia antetelor;
• Server-ul poate iniția comunicația.
 Interogare periodică
vs. notificări

Interogare

Date

Server
Client
Interogare
Interogare
Date
Răspuns fără date
Interogare Server
Client

Conectare
Răspuns fără date
Interogare Date
Date

Server
Client
Răspuns conținând date Date
Date

Închiderea conexiunii
 Web Sockets

• Browser-ele Web includ obiectul

window.WebSocket fără a necesita un plugin;
• Cum funcționează:
– Se stabilește o conexiune pe socket pe care se
trimite o cerere HTTP;
– Se schimbă protocolul din HTTP într-unul la nivel de
socket;
– Se pot trimite mesaje în ambele direcții simultan.
 Handshake-ul Web Socket
Cerere
GET /mychat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key:
x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com
Răspuns
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept:
HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
 HTTPS

• HTTPS înseamnă Hypertext Transfer Protocol peste Secure Socket Layer

sau HTTP over SSL / TLS;
• SSL acționează ca un subnivel al HTTP-ului;
• HTTPS criptează un mesaj HTTP înainte de transmitere și decriptează
mesajul la sosire;
• În mod implicit, HTTPS utilizează portul 443 spre deosebire de portul
HTTP standard care este 80;
• URL-ul care începe cu HTTPS indică faptul că conexiunea dintre client și
browser este criptată folosind SSL sau TSL, de exemplu:
https://login.yahoo.com/config/login_verify2?&.src=ym
• Tranzacțiile SSL sunt negociate cu ajutorul unui algoritm de criptare bazat
pe cheie între client și server, această cheie are o lungime de 40 sau 128
de biți (cu cât numărul de biți este mai mare, cu atât criptarea este mai
sigură).
 Handshake-ul SSL / TLS

• O conexiune SSL peste HTTP este întotdeauna inițiată de client folosind o

adresă URL care începe cu https: // în loc de http: //;
• La începutul unei sesiuni SSL / TLS, se realizează un handshake SSL / TLS,
având ca rezultat stabilirea parametrilor criptografici ai sesiunii:
– Browser-ul emite o solicitare sigură;
– Server-ul trimite certificatul X.509 care conține cheie publică;
– Browser-ul autentifică certificatul cu lista CA-urilor cunoscute;
– Dacă un CA nu este cunoscut, browser-ul poate oferi utilizatorului
opțiunea de a accepta certificatul pe riscul său);
– Browser-ul generează cheie simetrică aleatorie și o criptează folosind
cheia publică a server-ului;
– Browser-ul și server-ul cunosc acum ambele chei simetrice și criptează
datele utilizatorului final folosind cheile simetrice pe durata sesiunii.
 Cum depășește SSL
problemele de securitate HTTP

• Tehnologia Secure Sockets Layer protejează site-urile

Web și permite vizitatorilor site-ului să aibă încredere în
trei moduri esențiale:
– Confidențialitate: un certificat SSL permite criptarea
informațiilor sensibile în timpul tranzacțiilor online;
– Integritate: autoritatea de certificare verifică
identitatea proprietarului certificatului atunci când
este emis;
– Autentificare: fiecare certificat SSL conține informații
unice, autentificate despre proprietarul certificatului.
 Limitările HTTPS

• Un server HTTPS poate implementa un singur virtual host per

socket, spre deosebire de mai multe din spatele unui socket folosit
cu HTTP:
– Acest lucru se datorează faptului că toate negocierile de
securitate au loc înainte de începerea protocolului HTTP și, prin
urmare, înainte ca serverul să știe ce adresă URL solicită clientul.
• HTTPS nu poate împiedica furtul informațiilor confidențiale din
paginile introduse în cache-ul browser-ului:
– Deoarece cu SSL / TLS datele sunt criptate numai în timpul
transmisiei, nu însă și în memoria browser-ului sau pe disc.
• HTTPS este ceva mai lent decât HTTP :
– HTTPS adaugă overhead de calcul, precum și overhead de rețea.
 Vă mulțumesc!
Ne vedem la cursul următor.