HTTPS e Wikipedia:Pagine da cancellare/Conta/2019 giugno 23: differenze tra le pagine

(Differenze fra le pagine)
Contenuto cancellato Contenuto aggiunto
 
BotCancellazioni (discussione | contributi)
Bot: aggiornamento pagina di servizio giornaliera per i conteggi del 23 giugno 2019
 
Riga 1:
{{Conteggio cancellazioni}}
[[File:HTTPS icon.png|alt=Icona del lucchetto, che nei browser contraddistingue l'uso di HTTPS.|thumb|Icona del lucchetto di HTTPS.]]
{{Conteggio cancellazioni/In corso/Start|07:56, 26 giu 2019 (CEST)}}
 
{{Conteggio cancellazioni/In corso/Voce|i = 1 |voce = Wagner Lamounier |turno = |tipo = consensuale |data = 2019 giugno 23 |multipla = |argomenti = musica |temperatura = 53 }}
L''''HyperText Transfer Protocol over Secure Socket Layer''' ('''HTTPS'''), (anche noto come '''HTTP over [[Transport Layer Security|TLS]]''',<ref name="HTTP Over TLS">{{Cita web|url=https://tools.ietf.org/html/rfc2818 |titolo=HTTP Over TLS |editore=The Internet Engineering Task Force |data=May 2000 |accesso=27 febbraio 2015 |autore=Network Working Group}}</ref><ref name="HTTPS-ranking-signal">{{Cita web|url=http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html |titolo=HTTPS as a ranking signal |editore=Google Inc. |sito=Google Webmaster Central Blog |data=6 agosto 2014 |accesso=27 febbraio 2015 |citazione= You can make your site secure with HTTPS (Hypertext Transfer Protocol Secure) [...]}}</ref> '''HTTP over [[Secure Sockets Layer|SSL]]'''<ref name="Enabling HTTP Over SSL">{{Cita web|url=https://docs.adobe.com/docs/en/cq/5-6-1/deploying/config-ssl.html |titolo=Enabling HTTP Over SSL |editore=Adobe Systems Incorporated |accesso=27 febbraio 2015}}</ref> e '''HTTP Secure'''<ref name="Secure your site with HTTPS">{{Cita web|url=https://support.google.com/webmasters/answer/6073543?hl=en |titolo=Secure your site with HTTPS |editore=Google, Inc. |sito=Google Support |accesso=27 febbraio 2015}}</ref><ref name="What is HTTPS?">{{Cita web|url=https://www.instantssl.com/ssl-certificate-products/https.html |titolo=What is HTTPS? |editore=[[Comodo Group|Comodo CA Limited]] |accesso=27 febbraio 2015 |citazione= Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP [...]}}</ref>) è un protocollo per la comunicazione sicura attraverso una rete di computer, il quale è largamente utilizzato su [[Internet]]. HTTPS consiste nella comunicazione tramite il protocollo [[Hypertext Transfer Protocol|HTTP]] ('''''H'''yper'''T'''ext '''T'''ransfer '''P'''rotocol'') all'interno di una connessione criptata dal [[Transport Layer Security]] (''TLS'') o dal suo predecessore, [[Secure Sockets Layer]] (''SSL''). Il principio che sta alla base di HTTPS è quello di avere:
{{Conteggio cancellazioni/In corso/Voce|i = 2 |voce = Sambamenta |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = bevande alcoliche, Veneto |temperatura = 3 }}
# un'autenticazione del [[sito Internet|sito web]] visitato
{{Conteggio cancellazioni/In corso/Voce|i = 3 |voce = Francesco Antonio Caporale |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = biografie |temperatura = 18 }}
# protezione della [[privacy]]
{{Conteggio cancellazioni/In corso/Voce|i = 4 |voce = Owen Knight |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = Televisione |temperatura = 18 }}
# integrità dei dati scambiati tra le parti comunicanti.
{{Conteggio cancellazioni/In corso/Voce|i = 5 |voce = Giorgio Albiani |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = musica classica |temperatura = 5 }}
 
{{Conteggio cancellazioni/In corso/Voce|i = 6 |voce = Sariola |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = musica |temperatura = 9 }}
In [[telecomunicazioni]] e [[informatica]] è il risultato dell'applicazione di un [[protocollo (informatica)|protocollo]] di [[crittografia asimmetrica]] al protocollo di trasferimento di [[ipertesto|ipertesti]] HTTP. Viene utilizzato per garantire trasferimenti [[confidenzialità|riservati]] di dati nel [[web]], in modo da impedire intercettazioni dei contenuti.
{{Conteggio cancellazioni/In corso/Voce|i = 7 |voce = Macy Alexander Sharpe |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = Televisione |temperatura = 17 }}
 
{{Conteggio cancellazioni/In corso/Voce|i = 8 |voce = Petra Jansen |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = televisione |temperatura = 8 }}
Nel suo popolare funzionamento su internet, HTTPS fornisce l'autenticazione del sito web e del [[server web]] associato con cui una delle parti sta comunicando, proteggendo la comunicazione dagli attacchi noti tramite la tecnica del [[man in the middle]]. Inoltre, HTTPS fornisce una cifratura bidirezionale delle comunicazioni tra un client e un server, che protegge la stessa contro le possibili operazioni di [[eavesdropping]], (''azione mediante il quale viene ascoltata segretamente la conversazione privata tra le parti senza il loro consenso'') e [[tampering (sicurezza informatica)|tampering]] (''letteralmente manomissione o alterazione della comunicazione'') falsificandone i contenuti.<ref name=httpse>{{Cita web|url=https://www.eff.org/https-everywhere/faq |titolo=HTTPS Everywhere FAQ |accesso=3 maggio 2012}}</ref> In pratica, tale meccanismo fornisce una garanzia soddisfacente del fatto che si sta comunicando esattamente con il sito web voluto (al contrario di un sito falso), oltre a garantire che i contenuti delle comunicazioni tra l'utente e il sito web non possano essere intercettate o alterate da terzi.
{{Conteggio cancellazioni/In corso/Voce|i = 9 |voce = Thomas Jansen |turno = |tipo = semplificata |data = 2019 giugno 23 |multipla = |argomenti = televisione |temperatura = 17 }}
 
{{Conteggio cancellazioni/In corso/Stop}}
Storicamente, le connessioni HTTPS erano usate soprattutto per i pagamenti nelle transazioni sul [[World Wide Web]], [[Posta elettronica|e-mail]] e per le transazioni sensibili all'interno dei [[sistema informativo|sistemi informativi]] aziendali. Nel tardo 2000 e nei primi anni del 2010, HTTPS ha iniziato ad avere una larga diffusione e ampio utilizzo per proteggere l'autenticità delle [[pagina web|pagine web]], la sicurezza degli account utente e per mantenere le comunicazioni, l'identità e la navigazione web dell'utente private.
 
== Descrizione generale ==
Nei [[browser]] web, la [[Uniform Resource Identifier|URI]] (''Uniform Resource Identifier'') che si riferisce a tale tecnologia ha nome di schema <tt>https</tt> ed è in tutto e per tutto analoga alle URI <tt>http</tt>. Tuttavia, HTTPS segnala al browser di usare il livello di cifratura aggiuntivo SSL/TLS per proteggere il traffico internet. SSL/TLS è particolarmente adatto al protocollo HTTP, dato che può fornire una qualche protezione, anche se tra le parti comunicanti solo una è autenticata. Questo è il caso di HTTP nelle transazioni su internet, dove tipicamente è il server l'unica parte ad essere autenticata, mentre il client esamina il certificato del server.
 
HTTPS si occupa di creare un canale di comunicazione sicuro attraverso una rete di computer non sicura. Ciò garantisce una protezione accettabile dagli [[eavesdropping|eavesdropper]] (''ascoltatori indiscreti'') e dagli attacchi [[man in the middle]], purché sia usata una cifratura adeguata della comunicazione e che il certificato del server sia verificato e fidato.
 
Alla base del funzionamento di HTTPS, sopra il ''Transport Layer Security'', risiede interamente il protocollo HTTP; per questo motivo quest'ultimo può essere criptato del tutto. La cifratura del protocollo HTTP include:
 
* la richiesta URL (''la pagina web che è stata richiesta'')
* i parametri di query
* le intestazioni della connessione (''headers'')
* i cookies (''i quali spesso contengono le informazioni sull'identità dell'utente'')
 
Tuttavia, poiché gli indirizzi IP degli host ([[siti web]]) e i numeri di porta fanno parte dei protocolli sottostanti del TCP/IP, HTTPS non può proteggere la loro divulgazione. In pratica, significa che anche se un [[server web|web server]] è correttamente configurato, gli eavesdropper possono dedurre l'indirizzo IP e il numero di porta (qualche volta anche il nome del dominio, ad esempio "www.example.org", ma non il resto dell'URL) del web server con cui si sta comunicando, oltre alla quantità dei dati trasferiti e la durata della comunicazione (lunghezza della sessione), ma non il contenuto della comunicazione.<ref name="httpse" />
 
I browser web sanno come fidarsi dei siti web HTTPS basati su [[Certificate authority|certificati di autorità]] che vengono preinstallati nel loro software. Le autorità di certificazione (come ''Symantec, Comodo, GoDaddy e GlobalSign'') sono fidate per i creatori di browser web, per fornire certificati validi ai fini della comunicazione. Pertanto, un utente dovrebbe fidarsi di una connessione HTTPS verso un sito web se e solo se tutti i punti seguenti sono verificati:
 
* L'utente si fida del fatto che il software del browser implementi correttamente il protocollo HTTPS con dei certificati di autorità correttamente preinstallati.
* L'utente si fida dell'autorità di certificazione che garantisce solo siti web legittimi.
* Il sito web fornisce un certificato valido, che significa che è stato firmato da un'autorità di fiducia.
* Il certificato identifica correttamente il sito web (ad esempio quando il browser visita "https://example.com", il certificato ricevuto è appropriatamente quello relativo a "example.com" e non di qualche altra entità).
* L'utente si fida del fatto che il livello di crittografia del protocollo (SSL/TLS) è sufficientemente sicuro contro le possibili operazioni degli eavesdropper.
 
HTTPS è particolarmente importante attraverso le reti insicure (come i punti di accesso WiFi pubblici), dato che chiunque sulla stessa rete locale può sniffare i pacchetti e scoprire informazioni sensibili e non protette da HTTPS. Oltre a ciò, molti vengono pagati per impegnarsi nel fare "[[Cracking di reti wireless|iniezione di pacchetti]]" all'interno di [[Wireless Local Area Network|reti wireless]] allo scopo di fornire un servizio per le pubblicità delle proprie pagine web, mentre altri lo fanno liberamente. Tuttavia, questa operazione può essere sfruttata malignamente in molti modi, come iniettare dei [[malware]] su pagine web e rubare informazioni private agli utenti.<ref>{{Cita web|titolo=Hotel Wifi JavaScript Injection|url=http://justinsomnia.org/2012/04/hotel-wifi-javascript-injection/|accesso=24 luglio 2012}}</ref>
 
HTTPS è anche molto importante con le connessioni sulla rete [[Tor (software)|Tor]] (acronimo di The Onion Router) per preservare l'anonimato su internet, siccome i nodi Tor maligni possono danneggiare o alterare i contenuti che li attraversano in maniera insicura e iniettano malware dentro la connessione. Per questa ragione l'[[Electronic Frontier Foundation]] (''EFF'') e il progetto Tor hanno avviato lo sviluppo del protocollo [[HTTPS Everywhere]]<ref name="httpse" />, il quale è incluso all'interno del pacchetto Tor Browser.<ref>{{Cita web|url=https://www.torproject.org/projects/torbrowser.html.en|titolo=Tor|autore=The Tor Project, Inc.|sito=torproject.org}}</ref>
 
Nonostante siano divulgate più informazioni riguardo la sorveglianza globale di massa e di informazioni personali rubate dagli [[hacker]], l'uso di HTTPS per la sicurezza su tutti i siti web sta diventando sempre più importante, a prescindere dal tipo di connessione ad internet usata.<ref name="NYT-Embracing-HTTPS">{{Cita web|url=http://open.blogs.nytimes.com/2014/11/13/embracing-https/ |titolo=Embracing HTTPS |editore=The New York Times |data=13 novembre 2014 |accesso=27 febbraio 2015 |autore=Konigsburg, Eitan |autore2=Pant, Rajiv |autore3=Kvochko, Elena}}</ref><ref name="HTTPS-Why-Not">{{Cita web|url=https://freedom.press/blog/2014/09/after-nsa-revelations-why-arent-more-news-organizations-using-https |titolo=Fifteen Months After the NSA Revelations, Why Aren’t More News Organizations Using HTTPS? |editore=Freedom of the Press Foundation |data=12 settembre 2014 |accesso=27 febbraio 2015 |autore=Gallagher, Kevin}}</ref> Mentre i metadati delle pagine individuali che un utente visita non sono informazioni sensibili, quando queste informazioni sono combinate insieme possono svelare molto sull'identità dell'utente e comprometterne la privacy stessa.<ref name="HTTPS-ranking-signal" /><ref name="Google-HTTPS-Everywhere">{{Cita web|url=https://www.youtube.com/watch?v=cBhZ6S0PFCY |titolo=Google I/O 2014 - HTTPS Everywhere |editore=Google Developers |data=26 giugno 2014 |accesso=27 febbraio 2015 |autore=Grigorik, Ilya |autore2=Far, Pierre}}</ref><ref name=deployhttpscorrectly/>
 
L'impiego di HTTPS inoltre consente l'utilizzo dei protocolli [[SPDY]]/[[HTTP/2]], che sono nuove generazioni del protocollo HTTP, progettate per ridurre i tempi di caricamento e la latenza delle pagine web.
 
È raccomandato usare [[HTTP Strict Transport Security]] (HSTS) con HTTPS per proteggere gli utenti dagli attacchi man in the middle, in particolare [[Moxie Marlinspike#SSL stripping|SSL stripping]].
<ref name=deployhttpscorrectly /><ref name="HSTSMDN">{{Cita web|url=https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security|titolo=HTTP Strict Transport Security|sito=Mozilla Developer Network}}</ref>
 
HTTPS non dovrebbe essere confuso con il protocollo poco utilizzato [[Secure Hypertext Transfer Protocol|Secure HTTP]] (S-HTTP) descritto nella specifica RFC 2660.
 
=== Utilizzo nei siti web ===
A partire dal 3 ottobre 2015, il 30% dei 143.99 maggiori siti web popolari hanno un'implementazione sicura del protocollo HTTPS.<ref name=sslpulse>{{Cita web|titolo=SSL Pulse|url=https://www.trustworthyinternet.org/ssl-pulse/|editore=Trustworthy Internet Movement|data=3 ottobre 2015|accesso=19 ottobre 2015}}</ref>
 
=== Integrazione nei browser ===
La maggior parte dei browser visualizza un messaggio di warning se riceve un certificato non valido dal server che funge come autorità di certificazione. I browser meno recenti, quando si connettevano ad un sito web con un certificato non valido, mostravano all'utente un messaggio di dialogo che chiedeva loro se volevano proseguire con la navigazione. I browser più recenti invece, visualizzano un messaggio di warning che copre l'intera finestra, mostrando per bene all'utente le informazioni di sicurezza del sito visitato sulla barra degli indirizzi del browser. Nei browser moderni la validazione estesa dei certificati mostra la barra degli indirizzi con un colore verde. Inoltre, la maggior parte dei browser visualizza un messaggio di warning all'utente quando esso sta visitando un sito che contiene un misto di contenuti criptati e non criptati.
 
[[Mozilla Firefox|Firefox]] usa il protocollo HTTPS per le ricerche Google dalla versione 14,<ref>{{Cita web|titolo=Firefox 14.0.1 Release Notes|url=https://www.mozilla.org/en-US/firefox/14.0.1/releasenotes/|accesso=24 luglio 2012}}</ref> con lo scopo di "proteggere i nostri utenti dall'infrastruttura di rete che può raccogliere dati dagli utenti o modificare/censurare i loro risultati di ricerca".<ref>{{Cita web|titolo=Firefox Rolling Out HTTPS Google search|url=https://blog.mozilla.org/futurereleases/2012/05/09/rolling-out-https-google-search/|accesso=24 luglio 2012}}</ref>
 
L'[[Electronic Frontier Foundation]], ha espresso l'opinione che: “''In un mondo ideale, ogni richiesta web potrebbe essere trasformata di default in una richiesta HTTPS''”. Per il browser [[Mozilla Firefox]] è fornito un [[Plugin (informatica)|add-on]] chiamato “''[[HTTPS Everywhere]]''” che abilita il protocollo HTTPS di default per centinaia di siti web esplorati di frequente. Una versione beta di questo [[Plugin (informatica)|plugin]] è anche disponibile per [[Google Chrome]] e [[Chromium]].<ref>Peter Eckersley: [https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension Encrypt the Web with the HTTPS Everywhere Firefox Extension] EFF blog, 17 June 2010</ref><ref>[https://www.eff.org/https-everywhere HTTPS Everywhere] EFF projects</ref>
 
== Sicurezza ==
{{main|:en:Transport Layer Security#Security}}
 
La sicurezza di HTTPS è garantita dal protocollo [[Transport Layer Security|TLS]] sottostante, che in pratica utilizza chiavi private e pubbliche a lungo termine per generare chiavi di sessione a breve termine. Queste chiavi sono utilizzate successivamente per cifrare il flusso dei dati scambiati tra client e server. I certificati definiti dallo standard '''[[X.509]]''' sono utilizzati per autenticare il server (a volte anche il client).
Di conseguenza, le [[Certificate authority|autorità certificative]] e i certificati a chiave pubblica sono necessari al fine di verificare il rapporto che sussiste tra il certificato e il suo proprietario, oltre a generare la firma e gestire la validità dei certificati.
Mentre questo può essere più vantaggioso rispetto a verificare le identità attraverso una rete di fiducia, le divulgazioni di massa sulla sorveglianza nel 2013 hanno richiamato all'attenzione le autorità certificative come potenziale punto debole per attacchi [[man in the middle]].<ref>[http://www.wired.com/threatlevel/2010/03/packet-forensics/ Law Enforcement Appliance Subverts SSL], Wired, 2010-04-03.</ref><ref>[https://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl New Research Suggests That Governments May Fake SSL Certificates], EFF, 2010-03-24.</ref>
Una proprietà importante in questo contesto è la '''[[forward secrecy]]''', che garantisce che le comunicazioni cifrate registrate nel passato non possano essere recuperate e decifrate e le chiavi di cifratura a lungo termine o le password non siano compromesse in futuro. Non tutti i web server forniscono la ''forward secrecy''.<ref name=ecdhe>[http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html SSL: Intercepted today, decrypted tomorrow], Netcraft, 2013-06-25.</ref>
 
Un [[sito web]] deve essere totalmente ospitato sul protocollo HTTPS, senza avere parte dei suoi contenuti su HTTP - per esempio, avere script caricati online in modo insicuro (in chiaro) - o l'utente sarà vulnerabile a certi attacchi e sottoposto a sorveglianza.
Avere anche solo una determinata pagina web di un sito che contiene informazioni sensibili (come una pagina di log-in) sotto protocollo HTTPS, ma avere il resto del sito web caricato su protocollo HTTP in chiaro, esporrà l'utente a possibili attacchi.
Su un sito web che ha informazioni sensibili da qualche parte su di esso, ogni volta che il sito è acceduto in HTTP invece che HTTPS, l'utente e la sessione saranno esposte sulla rete. Analogamente, i [[cookie]]s su un sito web attivo tramite protocollo HTTPS, devono avere l'attributo di protezione abilitato.<ref name=deployhttpscorrectly />
 
== Aspetti tecnici ==
 
=== Differenza da HTTP ===
Le URL del protocollo HTTPS iniziano con “https://” e utilizzano la [[porta (reti)|porta]] 443 di [[default (informatica)|default]], mentre le URL HTTP cominciano con “http://” e utilizzano la [[porta (reti)|porta]] 80.
 
HTTP non è criptato ed è vulnerabile ad attacchi man-in-the-middle e eavesdropping, che possono consentire agli attaccanti di ottenere l'accesso agli account di siti web con informazioni sensibili e modificare le pagine web per iniettare al loro interno dei [[malware]] o della pubblicità malevola. HTTPS è progettato per resistere a tali attacchi ed è considerato sicuro contro di essi (con eccezione delle versioni più obsolete e deprecate del protocollo [[Secure Sockets Layer|SSL]]).
 
=== Livelli di rete ===
HTTPS opera al livello più alto del modello TCP/IP, il livello di applicazione; come fa anche il protocollo di sicurezza [[Transport Layer Security|TLS]] (operando come un sotto-strato più basso dello stesso livello).
 
In pratica, tra il protocollo [[Transmission Control Protocol|TCP]] e [[Hypertext Transfer Protocol|HTTP]] si interpone (trasparentemente all'utente) un livello di [[crittografia]]/[[autenticazione]] come il [[Secure Sockets Layer]] (SSL) o il [[Transport Layer Security]] (TLS) il quale cripta il messaggio HTTP prima della trasmissione e decripta il messaggio una volta giunto a destinazione.
Sostanzialmente, viene creato un [[canale (telecomunicazioni)|canale]] di comunicazione criptato tra il [[client]] e il [[server]] attraverso uno scambio di [[certificato digitale|certificati]]; una volta stabilito questo canale, al suo interno viene utilizzato il protocollo HTTP per la comunicazione. Strettamente parlando, HTTPS non è effettivamente considerato come un protocollo separato da HTTP, ma si riferisce appunto all'uso di quest'ultimo attraverso una connessione criptata SSL/TLS.
Questo tipo di comunicazione garantisce che solamente il client e il server siano in grado di conoscere il contenuto della comunicazione.
 
Ogni cosa nel messaggio HTTPS è cifrata, inclusi gli header e il carico di richiesta/risposta del messaggio. Con l'eccezione del possibile attacco crittografico CCA descritto nella sezione “[[HTTPS#Limiti|Limiti]]” successiva, l'attaccante può solamente sapere che è avvenuta una connessione tra le due parti comunicanti e può conoscere i loro nomi di dominio e indirizzi IP.
 
==== Acquisizione dei certificati ====
I certificati firmati autorevolmente possono essere gratuiti<ref>{{Cita web|url=http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html
|titolo=Free SSL Certificates from a Free Certificate Authority
|editore=sslshopper.com
|accesso=24 ottobre 2009
}}</ref><ref>{{Cita web|url=http://www.techrepublic.com/blog/networking/secure-outlook-web-access-with-free-ssl-part-1/293
|titolo=Secure Outlook Web Access with (free) SSL: Part 1
|autore=Justin Fielding
|data=16 luglio 2006
|editore=[[TechRepublic]]
|accesso=24 ottobre 2009
}}</ref> oppure costare tra gli 8<ref>{{Cita web|url=https://www.namecheap.com/ssl-certificates/comodo/positivessl-certificate.aspx
|titolo=Namecheap.com SSL Services
|editore=namecheap
|accesso=30 gennaio 2012
}}</ref> e i 70<ref>{{Cita web|url=https://ssl.comodo.com/comodo-ssl-certificate.php
|titolo=Secure Site Pro with SSL Certificate |accesso=23 Aug 2014
}}</ref> [[United States dollar|USD]] all'anno. (2012-2014).
Le organizzazioni possono anche adottare le proprie autorità certificative, in particolare se esse sono responsabili per la configurazione dei browser per accedere ai propri siti (per esempio, siti su una [[intranet]] aziendale, o di importanti università).
Tali organizzazioni possono facilmente aggiungere copie della propria firma del certificato ai certificati fidati distribuiti con il browser web.
Inoltre, esistono autorità certificative [[peer-to-peer]], come [[CAcert.org|CACert]].
Tuttavia, quest’ultima non è inclusa nei certificati di origine fidati di molti browser web popolari
(e.g. [[Firefox]], [[Google Chrome|Chrome]], [[Internet Explorer]]), i quali possono visualizzare dei messaggi di warning agli utenti finali.
Un’autorità certificativa, “[[Let’s Encrypt]]” è stata lanciata verso la fine del 2015<ref>{{Cita web|titolo=Launch schedule|url=https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html|sito=Let's Encrypt|accesso=21 settembre 2015}}</ref> e fornisce certificati SSL/TLS automatici e gratuiti per siti web.<ref name="Lets-Encrypt-Aims-to-Improve-Security">{{Cita web|url=http://www.eweek.com/security/lets-encrypt-effort-aims-to-improve-internet-security.html |titolo=Let's Encrypt Effort Aims to Improve Internet Security |editore=Quinstreet Enterprise |sito=eWeek.com |data=18 novembre 2014 |accesso=27 febbraio 2015 |autore=Kerner, Sean Michael}}</ref>
In accordo con la [[Electronic Frontier Foundation]], “Let’s Encrypt” eseguirà il passaggio dal protocollo HTTP a HTTPS “così facilmente come lanciare un comando, o cliccare su un bottone.”<ref name="Launching-2015-CA-to-Encrypt-Entire-Web">{{Cita web|url=https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web |titolo=Launching in 2015: A Certificate Authority to Encrypt the Entire Web |editore=[[Electronic Frontier Foundation]] |data=18 novembre 2014 |accesso=27 febbraio 2015 |autore=Eckersley, Peter}}</ref>
 
==== Utilizzo come controllo dell'accesso ====
Il sistema può anche essere usato per l’autenticazione del client al fine di limitare l’accesso al server web ai soli utenti autorizzati. Per fare questo, l’amministratore del sito tipicamente crea un certificato per ciascun utente, che viene caricato all’interno del browser degli utenti. Normalmente, esso contiene il nome e indirizzo e-mail dell’utente autorizzato e viene verificato automaticamente dal server ad ogni riconnessione per verificare l’identità dell’utente, potenzialmente senza inserire anche la password.
 
==== In caso di chiave privata segreta compromessa ====
Un importante proprietà in questo contesto è la [[forward secrecy|perfect forward secrecy]] (''PFS'').
Possedere una chiave privata segreta asimmetrica a lungo termine usata per stabilire una sessione HTTPS non dovrebbe rendere più semplice derivare la chiave di sessione a breve termine per poi decifrare la conversazione, anche in un secondo momento.
Lo scambio di chiavi '''[[Scambio di chiavi Diffie-Hellman|Diffie-Hellman]]''' ('''''DHE''''') e '''[[Elliptic curve Diffie-Hellman]]''' ('''''ECDHE''''')
sono dal 2013 gli unici schemi noti per avere la proprietà perfet forward secrecy.
Solamente il 30% delle sessioni dei browser Firefox, Opera, e Chromium utilizzano tale proprietà
e quasi lo 0% delle sessioni dei browser Safari di Apple e Microsoft Internet Explorer.<ref name=ecdhe />
Tra i più grandi fornitori di internet, solo Google supporta la PFS dal 2011.
Un certificato può essere revocato prima che esso scada, per esempio perché la segretezza della chiave privata è stata compromessa.
Le versioni più moderne dei browser popolari come Firefox,<ref>{{Cita web|url=https://www.mozilla.com/en-US/legal/privacy/firefox-en.html
|titolo=Mozilla Firefox Privacy Policy
|editore=[[Mozilla Foundation]]
|data=27 aprile 2009
|accesso=13 maggio 2009
}}</ref> Opera,<ref>{{Cita news|url=http://news.softpedia.com/news/Opera-8-launched-on-FTP-1330.shtml
|titolo=Opera 8 launched on FTP
|editore=[[Softpedia]]
|data=19 aprile 2005
|accesso=13 maggio 2009
}}</ref> e Internet Explorer su [[Windows Vista]]<ref>{{Cita web|url=http://msdn.microsoft.com/en-us/library/bb250503.aspx
|titolo=HTTPS Security Improvements in Internet Explorer 7
|cognome=Lawrence
|nome=Eric
|editore=[[MSDN]]
|data=31 gennaio 2006
|accesso=13 maggio 2009
}}</ref> implementano il protocollo '''[[Online Certificate Status Protocol]]''' ('''''OCSP''''') e l’autorità risponde, indicando al browser se il certificato è ancora valido o meno.<ref>{{Cita web|url=https://tools.ietf.org/html/rfc2560
|titolo=Online Certificate Status Protocol – OCSP
|editore=[[Internet Engineering Task Force]]
|data=June 1999
|autore=Myers, M
|autore2=Ankney, R |autore3=Malpani, A |autore4=Galperin, S |autore5= Adams, C
|accesso=13 maggio 2009
}}</ref>
 
=== Funzionamento ===
HTTPS è un protocollo che integra l'interazione del protocollo HTTP attraverso un meccanismo di crittografia di tipo [[Transport Layer Security]] ([[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]].
 
Per un migliore grado di protezione delle connessioni HTTPS di fronte ad attacchi ''man-in-the-middle'', e in particolare per fronteggiare la tecnica di «''stripping SSL''», è raccomandabile utilizzare l'uso di [[HTTP Strict Transport Security]], un meccanismo addizionale di sicurezza che forza l'uso di HTTPS.<ref name=deployhttpscorrectly>{{Cita web|titolo=How to Deploy HTTPS Correctly|url=https://www.eff.org/https-everywhere/deploying-https|accesso=13 giugno 2012}}</ref><ref name="HSTSMDN" />
 
=== Limiti ===
Il protocollo SSL/TLS è disponibile con due opzioni, semplice e mutua. La versione mutua è più sicura, ma richiede all'utente di installare un certificato client personale all'interno del proprio browser al fine di autenticare sé stesso.
Qualunque strategia venga utilizzata (semplice o mutua), il livello di protezione dipende fortemente dalla correttezza dell'implementazione del browser web, del software del server e dagli effettivi algoritmi crittografici supportati.
SSL/TLS non impedisce all'intero sito di essere indicizzato usando un [[crawler|web crawler]], e in alcuni casi l'[[Uniform Resource Identifier|URI]] della risorsa cifrata può essere dedotta conoscendo solo la dimensione della richiesta/risposta intercettata.<ref>{{Cita web|url=http://sysd.org/stas/node/220
|titolo=The Pirate Bay un-SSL
|cognome=Pusep
|nome=Stanislaw
|data=31 luglio 2008
|accesso=6 marzo 2009
}}</ref>
Questo consente ad un attaccante di aver accesso al testo non formattato (il contenuto statico pubblicamente accessibile) e al testo cifrato (la versione cifrata del contenuto statico), permettendo un attacco crittografico.
 
Poiché TLS opera sotto il protocollo HTTP e non ha conoscenza dei protocolli di livello superiore, i server TLS possono strettamente presentare solo un certificato per una particolare combinazione di porta e indirizzo IP.<ref>{{Cita web|url=http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts|titolo=SSL/TLS Strong Encryption: FAQ|sito=apache.org}}</ref>
Questo significa che, nella maggior parte dei casi, non è possibile usare l'[[Virtual hosting#Name-based virtual hosting|hosting virtuale basato sui nomi]] con HTTPS. Esiste una soluzione chiamata [[Server Name Indication]] ('''''SNI''''') che invia il nome dell'host al server prima di cifrare la connessione, benché molti browser più vecchi non supportino tale estensione. Il supporto per SNI è disponibile a partire da:
Firefox 2, Opera 8, Safari 2.1, Google Chrome 6 e Internet Explorer 7 su Windows Vista.<ref>{{Cita web|url=http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
|titolo=Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2
|cognome=Lawrence
|nome=Eric
|editore=[[Microsoft]]
|data=22 ottobre 2005
|accesso=12 maggio 2009
}}</ref><ref>{{Cita web|url=http://blog.ebrahim.org/2006/02/21/server-name-indication-sni/|titolo=Server Name Indication (SNI)|sito=inside aebrahim's head}}</ref><ref>{{Cita web|url= https://bugzilla.mozilla.org/show_bug.cgi?id=116169 |titolo= Browser support for TLS server name indication |accesso= 15 dicembre 2010 |cognome= Pierre |nome= Julien |data= 19 dicembre 2001 |sito= Bugzilla |editore= Mozilla Foundation}}</ref>
 
Da un punto di vista architetturale:
 
# Una connessione SSL/TLS è gestita dalla prima macchina visibile che avvia la connessione TLS. Se, per qualche ragione, (routing, ottimizzazione del traffico, ecc.), questa macchina non è il [[application server|server applicativo]] e deve decifrare i dati, devono essere trovate soluzioni per propagare le informazioni di autenticazione dell'utente o il certificato del server applicativo, il quale deve essere a conoscenza di chi sta per collegarsi.
# Per la versione di SSL/TLS con mutua autenticazione, la sessione SSL/TLS è gestita dal primo server che avvia la connessione. In situazioni dove la cifratura deve essere propagata lungo una catena di server, la gestione del timeout della sessione diventa complicata da implementare.
# Con la versione mutua di SSL/TLS la sicurezza è massima, ma dal lato client non c'è modo per terminare correttamente la connessione SSL/TLS e disconnettere l'utente, eccetto attendere la scadenza della sessione lato del server o la chiusura di tutte le applicazioni client collegate.
 
Un tipo sofisticato di attacco man-in-the-middle chiamato [[SSL stripping]] è stato presentato alla conferenza Blackhat del 2009.
Questo tipo di attacco sconfigge la sicurezza fornita dal protocollo HTTPS cambiando il link https: in un link http: avvantaggiandosi del fatto che alcuni utenti di Internet digitano effettivamente “https” dall'interfaccia del loro browser: essi raggiungono un sito sicuro cliccando su un collegamento, e perciò sono ingannati a pensare di utilizzare HTTPS quando in effetti essi stanno usando HTTP.
L'attaccante comunica poi in chiaro con il client. Questo ha indotto lo sviluppo di una contromisura in HTTP chiamata [[HTTP Strict Transport Security]] ('''''HSTS''''').
 
Nel maggio 2010, un articolo scritto da ricercatori della [[Microsoft Research]] e dell'[[Università dell'Indiana]] ha rivelato che dati sensibili dettagliati dell'utente possono essere dedotti da canali laterali/marginali come la dimensione dei pacchetti.
Più nello specifico, i ricercatori hanno scoperto che un [[eavesdropping|eavesdropper]] può dedurre le malattie/i medicinali/gli interventi chirurgici dell'utente, il suo reddito familiare e i propri segreti di investimento, nonostante la protezione HTTPS presente nelle diverse
applicazioni web di alto profilo e migliori nel campo della sanità, della tassazione, negli investimenti e nella ricerca web.
 
Nel giugno 2014, un team di ricercatori dell’[[Università della California, Berkeley]] e [[Intel]] guidati da [http://bradmiller.io Brad Miller], hanno dimostrato un approccio generalizzato all’analisi del traffico HTTPS basato sull’[[apprendimento automatico]].<ref>{{Cita web|titolo=Statistical Tricks Extract Sensitive Data from Encrypted Communications|url=https://www.technologyreview.com/s/528336/statistical-tricks-extract-sensitive-data-from-encrypted-communications/|editore=MIT Technology Review|data=19 giugno 2014}}</ref><ref>{{Cita web|titolo=Researchers Use Big Data to Get Around Encryption|url=http://blogs.wsj.com/digits/2014/06/23/researchers-use-big-data-to-get-around-encryption/|editore=The Wall Street Journal|data=23 giugno 2014}}</ref>
I ricercatori hanno dimostrato tale attacco applicato ad un range di siti web, inclusi [[Mayo Clinic]], [[Planned Parenthood]] e [[YouTube]].<ref>{{Cita web|url=http://bradmiller.io/resources/pets2014.pdf|titolo=I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis|autore=Brad Miller, Ling Huang, Anthony D. Joseph, J.D. Tygar}}</ref>
L’attacco suppone che l’attaccante sia in grado di visitare le stesse pagine web della vittima per raccogliere informazioni sul traffico di rete che fungono da allenamento dati. L’attaccante successivamente è in grado di identificare somiglianze nelle dimensioni e ordinamenti del pacchetto tra il traffico della vittima e il traffico di allenamento dati che consente all’attaccante di dedurre frequentemente la pagina web esatta che la vittima sta visitando. Per esempio, questo attacco potrebbe essere usato per determinare se un utente che sta visitando il sito web Planned Parenthood sta cercando informazioni su uno screening sanitario preventivo oppure un aborto. Notare che l’attacco non può essere utilizzato per scoprire valori specifici dell’utente incorporati in una pagina web. Per esempio, molte banche offrono interfacce web che consentono agli utenti di prendere visione del proprio saldo di conto corrente. Mentre l’attaccante sarebbe in grado di scoprire che l’utente sta visionando una pagina di visualizzazione del saldo del conto corrente, non sarebbe però in grado di conoscere il valore esatto del saldo del conto corrente o il numero di conto degli utenti.
 
== Storia ==
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 informatica|sicurezza]] come per esempio il pagamento di transazioni online. In questo caso [[Secure Sockets Layer|SSL]] garantisce la [[Crittografia|cifratura]] dei dati inviati e ricevuti su [[internet]].
 
=== Implicazioni SEO ===
In data 8 agosto 2014 [http://googlewebmastercentral.blogspot.it/2014/08/https-as-ranking-signal.html 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.
 
== Vedi anche ==
* [[AAA protocol]]
* [[Bullrun]] — un programma anti-cifratura segreto eseguito dall'U.S. [[National Security Agency]]
* [[Computer security]]
* [[curl-loader]]
* [[HTTPsec]]
* [[Moxie Marlinspike]]
* [[Opportunistic encryption]]
* [[Stunnel]]
 
== Note ==
<references/>
 
== Voci correlate ==
* [[Hypertext Transfer Protocol]]
* [[HTTP Strict Transport Security]]
* [[Transport Layer Security]]
 
== Collegamenti esterni ==
 
=== Documenti ufficiali ===
* {{cita web|https://tools.ietf.org/html/rfc2818|RFC 2818: HTTP Over TLS}}
* [https://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 SSL 3.0 Specification] (IETF)
 
=== Estensioni per i browser ===
* [https://www.eff.org/https-everywhere/ HTTPS Everywhere] un'estensione per i maggiori browser creata da [[Electronic Frontier Foundation]] per forzare le connessioni HTTPS sui siti che la supportano.
* [https://github.com/kevinjacobs/HTTPS-Finder HTTPS Finder] un'estensione per Firefox che mantiene aggiornata la lista di HTTPS Everywhere.
 
{{IPstack}}
{{Portale|Sicurezza informatica|Telematica}}
 
[[Categoria:Protocolli livello applicazione]]
[[Categoria:Protocolli crittografici]]