http
Differenza tra i protocolli http e https.
Mauri su nicofranca,17\08\2015, h. 21.43.

d.
 simbolo di maggiore  Che differenza c'è tra http e lo stesso prefisso con l'aggiunta di una
 simbolo di maggiore  esse alla fine? 
r.
HTTP e HTTPS sono due varianti dello stesso
protocollo utilizzato per il trasferimento delle pagine web in
internet. Essi vengono ampiamente utilizzati durante la navigazione in
rete attraverso i piu' comuni browser (Internet Explorer, Firefox,
Safari e simili), ma presentano una grande differenza.
Mentre nell'HTTP tutte le comunicazioni avvengono "in chiaro" senz'alcun
genere di sicurezza, nell'HTTPS viene creato un canale di comunicazione
criptato attraverso lo scambio di certificati in modo da garantire
l'identita' delle parti e la riservatezza dei dati. Mentre il primo e'
quello di utilizzo piu' comune, l'HTTPS viene di norma utilizzato in
tutte quelle situazioni in cui e' richiesto un certo grado di sicurezza
come transazioni elettroniche, acquisti online e lettura di messaggi di
posta elettronica. Un'altra differenza a livello tecnico consiste nelle
porte tcp che vengono utilizzate: HTTP si appoggia generalmente sulla
porta 80 mentre HTTPS sulla porta 443. In particolare prima sull'http:
La prima versione dell'HTTP, la 0.9, risale alla fine degli anni 1980 e
costituiva, insieme con il linguaggio HTML e gli URL, il nucleo base del
World Wide Web (WWW) global information initiative sviluppata da Tim
Berners-Lee al CERN di Ginevra per la condivisione delle informazioni
tra la comunità dei fisici delle alte energie. La prima versione
effettivamente disponibile del protocollo, la HTTP/1.0, venne
implementata dallo stesso Berners-Lee nel 1991 e proposta come RFC 1945
all'ente normatore IETF nel 1996.
Con la diffusione di NCSA Mosaic, un browser grafico di facile uso, il
WWW conobbe un successo crescente e divennero evidenti alcuni limiti
della versione 1.0 del protocollo, in particolare:
? l'impossibilità di ospitare più siti web sullo stesso server (virtual
host);
? il mancato riuso delle connessioni disponibili;
? l'insufficienza dei meccanismi di sicurezza.
Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato
come RFC 2068 nel 1997 e successivamente aggiornato nel 1999 come
descritto dal RFC 2616
Funzionamento[modifica | modifica wikitesto]
L'HTTP funziona su un meccanismo richiesta/risposta (client/server): il
client esegue una richiesta e il server restituisce la risposta.
Nell'uso comune il client corrisponde al browser ed il server al sito
web. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta e
messaggi risposta.
HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto
che le connessioni vengono generalmente chiuse una volta che una
particolare richiesta (o una serie di richieste correlate) è stata
soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il
World Wide Web, in cui le pagine molto spesso contengono dei
collegamenti (link) a pagine ospitate da altri server diminuendo così il
numero di connessioni attive limitandole a quelle effettivamente
necessarie con aumento quindi di efficienza (minor carico e occupazione)
sia sul client che sul server. Talvolta però pone problemi agli
sviluppatori di contenuti web, perché la natura senza stato (stateless)
della sessione di navigazione costringe ad utilizzare dei metodi
alternativi -tipicamente basati sui cookie- per conservare lo stato
dell'utente.

Il messaggio di richiesta è composto di tre parti:? riga di richiesta
(request line);? sezione header (informazioni aggiuntive);? body (corpo
del messaggio).Riga di richiesta[modifica | modifica wikitesto]La riga
di richiesta è composta da metodo, URI e versione del protocollo. Il
metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:?
GET? POST? HEAD? PUT? DELETE? TRACE? OPTIONS? CONNECTl'URI, uniform
resource identifier (identificatore univoco di risorsa), indica
l'oggetto della richiesta (ad esempio la pagina web che si intende
ottenere).I metodi HTTP più comuni sono GET, HEAD e POST. Il metodo GET
è usato per ottenere il contenuto della risorsa indicata come URI (come
può essere il contenuto di una pagina HTML). HEAD è analogo a GET, ma
restituisce solo i campi dell'header, ad esempio per verificare la data
di modifica del file. Una richiesta con metodo HEAD non prevede l'uso
del body.Il metodo POST è usato di norma per inviare informazioni al
server (ad esempio i dati di un form). In questo caso l'URI indica che
cosa si sta inviando e il body ne indica il contenuto.Gli header della
richiesta[modifica | modifica wikitesto]Gli header di richiesta più
comuni sono:Host: nome del server a cui si riferisce l'URL. È
obbligatorio nelle richieste conformi HTTP/1.1 perché permette l'uso dei
virtual host basati sui nomi.User-Agent: identificazione del tipo di
client: tipo browser, produttore, versione...Messaggio di
risposta[modifica | modifica wikitesto]Il messaggio di risposta è di
tipo testuale ed è composto da tre parti:? riga di stato (status-line);?
sezione header;? body (contenuto della risposta).Riga di stato[modifica
| modifica wikitesto]Exquisite-kfind.pngLo stesso argomento in
dettaglio: Codici di stato HTTP.La riga di stato riporta un codice a tre
cifre catalogato nel seguente modo:? 1xx: Informational (messaggi
informativi)? 2xx: Successful (la richiesta è stata soddisfatta)? 3xx:
Redirection (non c'è risposta immediata, ma la richiesta è sensata e
viene detto come ottenere la risposta)? 4xx: Client error (la richiesta
non può essere soddisfatta perché sbagliata)? 5xx: Server error (la
richiesta non può essere soddisfatta per un problema interno del
server)I codici di risposta più comuni sono:? 200 OK. Il server ha
fornito correttamente il contenuto nella sezione body.? 301 Moved
Permanently. La risorsa che abbiamo richiesto non è raggiungibile perché
è stata spostata in modo permanente.? 302 Found. La risorsa è
raggiungibile con un altro URI indicato nel header Location. Di norma i
browser eseguono la richiesta all'URI indicato in modo automatico senza
interazione dell'utente.? 400 Bad Request. La risorsa richiesta non è
comprensibile al server.? 404 Not Found. La risorsa richiesta non è
stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando
l'URI è stato indicato in modo incorretto, oppure è stato rimosso il
contenuto dal server.? 500 Internal Server Error. Il server non è in
grado di rispondere alla richiesta per un suo problema interno.? 505
HTTP Version Not Supported. La versione di http non è supportata.Gli
header della risposta[modifica | modifica wikitesto]Gli header della
risposta più comuni sono:? Server. Indica il tipo e la versione del
server. Può essere visto come l'equivalente dell'header di richiesta
User-Agent? Content-Type. Indica il tipo di contenuto restituito. La
codifica di tali tipi (detti Media type) è registrata presso lo IANA
(Internet Assigned Number Authority ); essi sono detti tipi MIME
(Multimedia Internet Mail Extensions), la cui codifica è descritta nel
documento RFC 1521. Alcuni tipi usuali di tipi MIME incontrati in una
risposta HTML sono: ? text/html Documento HTML? text/plain Documento di
testo non formattato? text/xml Documento XML? image/jpeg Immagine di
formato JPEGTipo di connessione[modifica | modifica wikitesto]Il client
può chiedere al server, nel messaggio di richiesta, di utilizzare due
tipi di comunicazione.Non persistentePer ogni richiesta e relativa
risposta, viene stabilita una connessione TCP dedicata.PersistenteOgni
richiesta e relativa risposta è trasferita utilizzando la stessa
connessione TCP. È il comportamento predefinito di HTTP 1.1.Da un lato,
le connessioni non persistenti introducono una latenza aggiuntiva
rispetto a quelle persistenti di almeno 3 Round Trip Time (RTT).
Infatti, al termine di ogni risposta da parte del server si rendono
necessari? 1.5 o 2 RTT per la chiusura della connessione corrente, con
la sua stretta di mano conclusiva a tre o quattro passaggi di FIN ed ACK
(three- o four-way handshake).? 1.5 RTT per l'apertura della nuova
connessione, per i tre passaggi di SYN e ACK.D'altro canto, le
connessioni persistenti precludono il parallelismo nelle comunicazioni,
giacché il client che abbia diverse richieste da inviare allo stesso
server è costretto ad evaderle sequenzialmente, una dopo l'altra. Per
queste ragioni, i browser solitamente sfruttano le complementarità
prestazionali delle due politiche di comunicazione per massimizzare la
loro efficienza: solitamente aprono con ogni server diverse connessioni
TCP in parallelo, su cui comunicano con strategia persistente.

Richiesta:GET /wiki.com/Pagina_principale HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like
Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: it.wikipedia.org
(la richiesta deve terminare con una riga vuota, cioè con due "a capo"
consecutivi)Risposta:HTTP/1.0 200 OK
Date: Mon, 28 Jun 2004 10:47:31 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: it
Content-Type: text/html; charset=utf-8
Age: 7673
X-Cache: HIT from wikipedia.org
Connection: close
seguita dai dati richiesti.

Dal momento che tutto il traffico HTTP è anonimo e in chiaro, sono state
sviluppate diverse alternative per garantire differenti livelli di
sicurezza, in termini di? cifratura del traffico;? verifica di integrità
del traffico;? autenticazione del server;? autenticazione dell'utente.La
prima proposta venne direttamente da NCSA, con le versioni server 1.1 e
client 2.2 che supportavano un meccanismo di autenticazione utente e
cifratura dati basati su messaggi formato PEM e chiavi PGP.In seguito,
sono state standardizzate due versioni sicure del protocollo HTTP
chiamate SHTTP e HTTPS. La prima, modellata sulla posta cifrata S/MIME,
è ormai caduta in disuso e prevede meccanismi crittografici a livello di
payload: le richieste e gli header vengono scambiati in chiaro mentre il
contenuto della pagina viene cifrato come una struttura MIME multipart.
Il meccanismo HTTPS, inventato da Netscape, usa invece il sottostante
canale cifrato a livello di trasporto mediante SSL o TLS per impedire
l'intercettazione di qualsiasi parte della transazione. Entrambi i
protocolli possono garantire l'identità del mittente, ma solo SHTTP è in
grado di garantire anche l'integrità del contenuto dopo averlo, ad
esempio, memorizzato su un disco.

La fruizione nelle pagine WEB di materiale multimediale, quale audio o
video viene gestito in modo del tutto analogo al download dei file,
tramite un caricamento progressivo o distribuzione progressiva, in cui
il file viene scaricato in modo progressivo dall'inizio alla fine
(tramite i protocolli Real Time Streaming Protocol e Real-time Transport
Protocol) e nel caso il bit-rate sia eccessivo per la rete che lo
trasporta può verificarsi un continuo ricaricamento del bufferPer
evitare questi inconvenienti esistono altri sistemi alternativi, che
permettono l'adattamento del file alla rete dell'utente finale, questi
sistemi sono caratterizzati dai protocolli:? Smooth Streaming, ideato da
Microsoft[1][2]? HTTP Dynamic Streaming soluzione ideata da Adobe? HTTP
Live Streaming soluzione ideata da Apple? Octoshape è una piattaforma
proprietaria di streaming multimediale, che utilizza la tecnologia per
offrire un throughput migliore e rompere la congestione nell'ultimo
miglio. Ha la possibilità di utilizzare una suite di tecnologie
multicast per ridurre al minimo la larghezza di banda per qualsiasi CDN,
ISP, emittente o del fornitore dell'ultimo miglio.Per contro queste
soluzioni sono notevolmente più complesse rispetto alle tradizionali
tecnologie di streaming. Alcune delle considerazioni documentate
riguardano lo stoccaggio, i costi aggiuntivi per la codifica e la
difficoltà nel mantenimento della qualità globale. Ci sono state anche
alcune dinamiche interessanti trovate intorno alle interazioni complesse
fra logica adattiva bit rate in competizione con complessa logica di
controllo del flusso TCP.[3][4] Ed ora sull'https: La prima versione
dell'HTTP, la 0.9, risale alla fine degli anni 1980 e costituiva,
insieme con il linguaggio HTML e gli URL, il nucleo base del World Wide
Web (WWW) global information initiative sviluppata da Tim Berners-Lee al
CERN di Ginevra per la condivisione delle informazioni tra la comunità
dei fisici delle alte energie. La prima versione effettivamente
disponibile del protocollo, la HTTP/1.0, venne implementata dallo stesso
Berners-Lee nel 1991 e proposta come RFC 1945 all'ente normatore IETF
nel 1996.
Con la diffusione di NCSA Mosaic, un browser grafico di facile uso, il
WWW conobbe un successo crescente e divennero evidenti alcuni limiti
della versione 1.0 del protocollo, in particolare:
? l'impossibilità di ospitare più siti web sullo stesso server (virtual
host);
? il mancato riuso delle connessioni disponibili;
? l'insufficienza dei meccanismi di sicurezza.
Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato
come RFC 2068 nel 1997 e successivamente aggiornato nel 1999 come
descritto dal RFC 2616
Funzionamento[modifica | modifica wikitesto]
L'HTTP funziona su un meccanismo richiesta/risposta (client/server): il
client esegue una richiesta e il server restituisce la risposta.
Nell'uso comune il client corrisponde al browser ed il server al sito
web. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta e
messaggi risposta.
HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto
che le connessioni vengono generalmente chiuse una volta che una
particolare richiesta (o una serie di richieste correlate) è stata
soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il
World Wide Web, in cui le pagine molto spesso contengono dei
collegamenti (link) a pagine ospitate da altri server diminuendo così il
numero di connessioni attive limitandole a quelle effettivamente
necessarie con aumento quindi di efficienza (minor carico e occupazione)
sia sul client che sul server. Talvolta però pone problemi agli
sviluppatori di contenuti web, perché la natura senza stato (stateless)
della sessione di navigazione costringe ad utilizzare dei metodi
alternativi -tipicamente basati sui cookie- per conservare lo stato
dell'utente.

Il messaggio di richiesta è composto di tre parti:? riga di richiesta
(request line);? sezione header (informazioni aggiuntive);? body (corpo
del messaggio).Riga di richiesta[modifica | modifica wikitesto]La riga
di richiesta è composta da metodo, URI e versione del protocollo. Il
metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:?
GET? POST? HEAD? PUT? DELETE? TRACE? OPTIONS? CONNECTl'URI, uniform
resource identifier (identificatore univoco di risorsa), indica
l'oggetto della richiesta (ad esempio la pagina web che si intende
ottenere).I metodi HTTP più comuni sono GET, HEAD e POST. Il metodo GET
è usato per ottenere il contenuto della risorsa indicata come URI (come
può essere il contenuto di una pagina HTML). HEAD è analogo a GET, ma
restituisce solo i campi dell'header, ad esempio per verificare la data
di modifica del file. Una richiesta con metodo HEAD non prevede l'uso
del body.Il metodo POST è usato di norma per inviare informazioni al
server (ad esempio i dati di un form). In questo caso l'URI indica che
cosa si sta inviando e il body ne indica il contenuto.Gli header della
richiesta[modifica | modifica wikitesto]Gli header di richiesta più
comuni sono:Host: nome del server a cui si riferisce l'URL. È
obbligatorio nelle richieste conformi HTTP/1.1 perché permette l'uso dei
virtual host basati sui nomi.User-Agent: identificazione del tipo di
client: tipo browser, produttore, versione...Messaggio di
risposta[modifica | modifica wikitesto]Il messaggio di risposta è di
tipo testuale ed è composto da tre parti:? riga di stato (status-line);?
sezione header;? body (contenuto della risposta).Riga di stato[modifica
| modifica wikitesto]Exquisite-kfind.pngLo stesso argomento in
dettaglio: Codici di stato HTTP.La riga di stato riporta un codice a tre
cifre catalogato nel seguente modo:? 1xx: Informational (messaggi
informativi)? 2xx: Successful (la richiesta è stata soddisfatta)? 3xx:
Redirection (non c'è risposta immediata, ma la richiesta è sensata e
viene detto come ottenere la risposta)? 4xx: Client error (la richiesta
non può essere soddisfatta perché sbagliata)? 5xx: Server error (la
richiesta non può essere soddisfatta per un problema interno del
server)I codici di risposta più comuni sono:? 200 OK. Il server ha
fornito correttamente il contenuto nella sezione body.? 301 Moved
Permanently. La risorsa che abbiamo richiesto non è raggiungibile perché
è stata spostata in modo permanente.? 302 Found. La risorsa è
raggiungibile con un altro URI indicato nel header Location. Di norma i
browser eseguono la richiesta all'URI indicato in modo automatico senza
interazione dell'utente.? 400 Bad Request. La risorsa richiesta non è
comprensibile al server.? 404 Not Found. La risorsa richiesta non è
stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando
l'URI è stato indicato in modo incorretto, oppure è stato rimosso il
contenuto dal server.? 500 Internal Server Error. Il server non è in
grado di rispondere alla richiesta per un suo problema interno.? 505
HTTP Version Not Supported. La versione di http non è supportata.Gli
header della risposta[modifica | modifica wikitesto]Gli header della
risposta più comuni sono:? Server. Indica il tipo e la versione del
server. Può essere visto come l'equivalente dell'header di richiesta
User-Agent? Content-Type. Indica il tipo di contenuto restituito. La
codifica di tali tipi (detti Media type) è registrata presso lo IANA
(Internet Assigned Number Authority ); essi sono detti tipi MIME
(Multimedia Internet Mail Extensions), la cui codifica è descritta nel
documento RFC 1521. Alcuni tipi usuali di tipi MIME incontrati in una
risposta HTML sono: ? text/html Documento HTML? text/plain Documento di
testo non formattato? text/xml Documento XML? image/jpeg Immagine di
formato JPEGTipo di connessione[modifica | modifica wikitesto]Il client
può chiedere al server, nel messaggio di richiesta, di utilizzare due
tipi di comunicazione.Non persistentePer ogni richiesta e relativa
risposta, viene stabilita una connessione TCP dedicata.PersistenteOgni
richiesta e relativa risposta è trasferita utilizzando la stessa
connessione TCP. È il comportamento predefinito di HTTP 1.1.Da un lato,
le connessioni non persistenti introducono una latenza aggiuntiva
rispetto a quelle persistenti di almeno 3 Round Trip Time (RTT).
Infatti, al termine di ogni risposta da parte del server si rendono
necessari? 1.5 o 2 RTT per la chiusura della connessione corrente, con
la sua stretta di mano conclusiva a tre o quattro passaggi di FIN ed ACK
(three- o four-way handshake).? 1.5 RTT per l'apertura della nuova
connessione, per i tre passaggi di SYN e ACK.D'altro canto, le
connessioni persistenti precludono il parallelismo nelle comunicazioni,
giacché il client che abbia diverse richieste da inviare allo stesso
server è costretto ad evaderle sequenzialmente, una dopo l'altra. Per
queste ragioni, i browser solitamente sfruttano le complementarità
prestazionali delle due politiche di comunicazione per massimizzare la
loro efficienza: solitamente aprono con ogni server diverse connessioni
TCP in parallelo, su cui comunicano con strategia persistente.

Richiesta:GET /wiki.com/Pagina_principale HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like
Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: it.wikipedia.org
(la richiesta deve terminare con una riga vuota, cioè con due "a capo"
consecutivi)Risposta:HTTP/1.0 200 OK
Date: Mon, 28 Jun 2004 10:47:31 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: it
Content-Type: text/html; charset=utf-8
Age: 7673
X-Cache: HIT from wikipedia.org
Connection: close
seguita dai dati richiesti.

Dal momento che tutto il traffico HTTP è anonimo e in chiaro, sono state
sviluppate diverse alternative per garantire differenti livelli di
sicurezza, in termini di? cifratura del traffico;? verifica di integrità
del traffico;? autenticazione del server;? autenticazione dell'utente.La
prima proposta venne direttamente da NCSA, con le versioni server 1.1 e
client 2.2 che supportavano un meccanismo di autenticazione utente e
cifratura dati basati su messaggi formato PEM e chiavi PGP.In seguito,
sono state standardizzate due versioni sicure del protocollo HTTP
chiamate SHTTP e HTTPS. La prima, modellata sulla posta cifrata S/MIME,
è ormai caduta in disuso e prevede meccanismi crittografici a livello di
payload: le richieste e gli header vengono scambiati in chiaro mentre il
contenuto della pagina viene cifrato come una struttura MIME multipart.
Il meccanismo HTTPS, inventato da Netscape, usa invece il sottostante
canale cifrato a livello di trasporto mediante SSL o TLS per impedire
l'intercettazione di qualsiasi parte della transazione. Entrambi i
protocolli possono garantire l'identità del mittente, ma solo SHTTP è in
grado di garantire anche l'integrità del contenuto dopo averlo, ad
esempio, memorizzato su un disco.

La fruizione nelle pagine WEB di materiale multimediale, quale audio o
video viene gestito in modo del tutto analogo al download dei file,
tramite un caricamento progressivo o distribuzione progressiva, in cui
il file viene scaricato in modo progressivo dall'inizio alla fine
(tramite i protocolli Real Time Streaming Protocol e Real-time Transport
Protocol) e nel caso il bit-rate sia eccessivo per la rete che lo
trasporta può verificarsi un continuo ricaricamento del bufferPer
evitare questi inconvenienti esistono altri sistemi alternativi, che
permettono l'adattamento del file alla rete dell'utente finale, questi
sistemi sono caratterizzati dai protocolli:? Smooth Streaming, ideato da
Microsoft[1][2]? HTTP Dynamic Streaming soluzione ideata da Adobe? HTTP
Live Streaming soluzione ideata da Apple? Octoshape è una piattaforma
proprietaria di streaming multimediale, che utilizza la tecnologia per
offrire un throughput migliore e rompere la congestione nell'ultimo
miglio. Ha la possibilità di utilizzare una suite di tecnologie
multicast per ridurre al minimo la larghezza di banda per qualsiasi CDN,
ISP, emittente o del fornitore dell'ultimo miglio.Per contro queste
soluzioni sono notevolmente più complesse rispetto alle tradizionali
tecnologie di streaming. Alcune delle considerazioni documentate
riguardano lo stoccaggio, i costi aggiuntivi per la codifica e la
difficoltà nel mantenimento della qualità globale. Ci sono state anche
alcune dinamiche interessanti trovate intorno alle interazioni complesse
fra logica adattiva bit rate in competizione con complessa logica di
controllo del flusso TCP.[3][4]

Nei browser web, la URI (Uniform Resource Identifier) che si riferisce a
tale tecnologia ha nome di schema https ed è in tutto e per tutto
analoga alle URI http. Tuttavia, la porta di default impiegata non è la
80 come in HTTP, ma la 443, mentre (trasparentemente all'utente) tra il
protocollo TCP e HTTP si interpone un livello di
crittografia/autenticazione come il Secure Sockets Layer (SSL) o il
Transport Layer Security (TLS).In pratica viene creato un canale di
comunicazione criptato tra il client e il server attraverso uno scambio
di certificati; una volta stabilito questo canale al suo interno viene
utilizzato il protocollo HTTP per la comunicazione.Questo tipo di
comunicazione garantisce che solamente il client e il server siano in
grado di conoscere il contenuto della comunicazione.Questo sistema fu
progettato dalla Netscape Communications Corporation che si occupa delle
autenticazioni e delle comunicazioni crittografate ed è largamente usato
nel World Wide Web per situazioni che richiedono particolari esigenze in
ambito di sicurezza come per esempio il pagamento di transazioni online.
In questo caso SSL garantisce la cifratura dei dati inviati e ricevuti
su internet.Funzionamento[modifica | modifica wikitesto]HTTPS è un
protocollo che integra l'interazione del protocollo HTTP attraverso un
meccanismo di crittografia di tipo Transport Layer Security (SSL/TLS).
Questa tecnica aumenta il livello di protezione contro attacchi del tipo
man in the middle.La porta di default per il protocollo HTTPS è la
numero 443 (mentre per il protocollo HTTP è la numero 80).Per impostare
un web server in modo che accetti connessioni di tipo HTTPS,
l'amministratore di rete deve creare un certificato digitale ovvero un
documento elettronico che associ l'identità di una persona ad una chiave
pubblica. Questi certificati possono essere creati dai server basati su
UNIX con l'ausilio di tools come ssl-ca di OpenSSL oppure usando
gensslcert di SuSE (TinyCA2, CA.pl, script Perl). Questi certificati
devono essere rilasciati da un certificate authority o comunque da un
sistema che accerta la validità dello stesso in modo da definire la vera
identità del possessore (i browser web sono creati in modo da poter
verificare la loro validità tramite una lista preimpostata).In
particolari situazioni (come per esempio nel caso di aziende con una
rete intranet privata) è possibile avere un proprio certificato digitale
che si può rilasciare ai propri utenti.Questa tecnologia quindi può
essere usata anche per permettere un accesso limitato ad un web server.
L'amministratore spesso crea dei certificati per ogni utente che vengono
caricati nei loro browser contenenti informazioni come il relativo nome
e indirizzo e-mail in modo tale da permettere al server di riconoscere
l'utente nel momento in cui quest'ultimo tenti di riconnettersi senza
immettere nome utente e/o password.Implicazioni SEO[modifica | modifica
wikitesto]In data 8 agosto 2014 Google annuncia che i siti ospitati
sotto protocollo HTTPS saranno ritenuti maggiormente affidabili agli
occhi del motore di ricerca. Il protocollo HTTPS viene annunciato
ufficialmente come fattore di ranking.