HTTPS: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Fix wikilink Etichette: Modifica da mobile Modifica da applicazione mobile Modifica da applicazione Android |
Funzionalità collegamenti suggeriti: 2 collegamenti inseriti. |
||
| (85 versioni intermedie di 55 utenti non mostrate) | |||
Riga 1:
[[File:HTTPS icon.png|alt=Icona del lucchetto, che nei browser contraddistingue l'uso di HTTPS.|
In [[telecomunicazioni]] e [[informatica]] l{{'
# un'[[autenticazione]] del [[sito Internet|sito web]] visitato;
# protezione della [[privacy]] (riservatezza o [[confidenzialità]]);
# [[integrità dei dati]] scambiati tra le parti comunicanti.
== Generalità ==
Nel suo popolare funzionamento su Internet, HTTPS fornisce
Storicamente, le connessioni HTTPS erano usate soprattutto per i pagamenti nelle transazioni sul [[World Wide Web]] (in particolare per il [[commercio elettronico]]), [[Posta elettronica|e-mail]] e per le transazioni sensibili all'interno dei [[
==
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]].▼
== Descrizione ==
Nei [[browser]] web, la [[Uniform Resource Identifier|URI]] (''Uniform Resource Identifier'') che si riferisce a tale tecnologia ha nome di schema <code>https</code> ed è in tutto e per tutto analoga alle URI <code>http</code>. 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.
Riga 16 ⟶ 20:
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
Riga 25 ⟶ 28:
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.
Riga 32 ⟶ 34:
* 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ò effettuare uno [[sniffing]] di pacchetti e scoprire informazioni sensibili e non protette da HTTPS. Oltre a ciò, molti vengono pagati per impegnarsi nel fare [[packet injection]] ("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|urlarchivio=https://web.archive.org/web/20120724164025/http://justinsomnia.org/2012/04/hotel-wifi-javascript-injection/|dataarchivio=24 luglio 2012|urlmorto=no}}</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|accesso=12 maggio 2016|urlarchivio=https://archive.is/20130717222709/https://www.torproject.org/projects/torbrowser.html.en|dataarchivio=17 luglio 2013|urlmorto=no}}</ref>
Nonostante siano divulgate più informazioni riguardo alla sorveglianza globale di massa e al furto di informazioni personali da parte degli [[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=https://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 |urlarchivio=https://web.archive.org/web/20180422133515/https://open.blogs.nytimes.com/2014/11/13/embracing-https/ |dataarchivio=22 aprile 2018 |urlmorto=sì }}</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 |urlarchivio=https://web.archive.org/web/20161202161557/https://freedom.press/blog/2014/09/after-nsa-revelations-why-arent-more-news-organizations-using-https |dataarchivio=2 dicembre 2016 |urlmorto=sì }}</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 |urlarchivio=https://web.archive.org/web/20180315193159/https://www.youtube.com/watch?v=cBhZ6S0PFCY&feature=youtu.be |dataarchivio=15 marzo 2018 |urlmorto=no }}</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|accesso=14 ottobre 2015|urlarchivio=https://web.archive.org/web/20120515140602/https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security|dataarchivio=15 maggio 2012|urlmorto=sì}}</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 ===
Alla data del 3 maggio 2017, il 56,8% dei
=== 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|urlarchivio=https://web.archive.org/web/20120722232551/http://www.mozilla.org/en-US/firefox/14.0.1/releasenotes/|dataarchivio=22 luglio 2012|urlmorto=no}}</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|urlarchivio=https://web.archive.org/web/20120720204529/https://blog.mozilla.org/futurereleases/2012/05/09/rolling-out-https-google-search/|dataarchivio=20 luglio 2012|urlmorto=no}}</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 i
=== Sicurezza ===
La sicurezza di HTTPS è garantita dal protocollo [[Transport Layer Security|TLS]] sottostante, che
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>[https://www.wired.com/threatlevel/2010/03/packet-forensics/ Law Enforcement Appliance Subverts SSL] {{Webarchive|url=https://web.archive.org/web/20140315064727/http://www.wired.com/threatlevel/2010/03/packet-forensics |data=15 marzo 2014 }}, 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] {{Webarchive|url=https://web.archive.org/web/20160104234608/https://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl |data=4 gennaio 2016 }}, 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] {{Webarchive|url=https://web.archive.org/web/20130921053551/http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html |data=21 settembre 2013 }}, 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.
Riga 66 ⟶ 68:
== 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,
=== 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.
Riga 79 ⟶ 80:
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 “[[
==== Acquisizione dei certificati ====
I certificati firmati autorevolmente possono essere gratuiti<ref>{{Cita web
|url=https://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
|urlarchivio=https://web.archive.org/web/20100209035224/http://www.sslshopper.com/article-free-ssl-certificates-from-a-free-certificate-authority.html
}}</ref><ref>{{Cita web|url=https://www.techrepublic.com/blog/networking/secure-outlook-web-access-with-free-ssl-part-1/293▼
|dataarchivio=9 febbraio 2010
|urlmorto=no
}}</ref><ref>{{Cita web
▲
|titolo=Secure Outlook Web Access with (free) SSL: Part 1
|autore=Justin Fielding
Riga 92 ⟶ 98:
|editore=[[TechRepublic]]
|accesso=24 ottobre 2009
|urlarchivio=https://web.archive.org/web/20110324233903/http://www.techrepublic.com/blog/networking/secure-outlook-web-access-with-free-ssl-part-1/293
}}</ref> oppure costare tra gli 8<ref>{{Cita web|url=https://www.namecheap.com/ssl-certificates/comodo/positivessl-certificate.aspx▼
|dataarchivio=24 marzo 2011
|urlmorto=no
}}</ref> oppure costare tra gli 8<ref>{{Cita web
▲
|titolo=Namecheap.com SSL Services
|editore=namecheap
|accesso=30 gennaio 2012
|urlarchivio=https://web.archive.org/web/20120204093050/http://www.namecheap.com/ssl-certificates/comodo/positivessl-certificate.aspx
}}</ref> e i 70<ref>{{Cita web|url=https://ssl.comodo.com/comodo-ssl-certificate.php▼
|dataarchivio=4 febbraio 2012
|titolo=Secure Site Pro with SSL Certificate |accesso=23 Aug 2014▼
|urlmorto=no
}}</ref> e i 70<ref>{{Cita web
|accesso=23 Aug 2014
|urlarchivio=https://web.archive.org/web/20140826033455/http://ssl.comodo.com/comodo-ssl-certificate.php
|dataarchivio=26 agosto 2014
|urlmorto=no
}}</ref> [[Dollaro statunitense|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à).
Riga 104 ⟶ 122:
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|urlarchivio=https://web.archive.org/web/20150927173815/https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html|dataarchivio=27 settembre 2015|urlmorto=no}}</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 |autore=Kerner, Sean Michael |lingua = en |accesso =
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 |urlarchivio=https://web.archive.org/web/20180510222107/https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web |dataarchivio=10 maggio 2018 |urlmorto=no }}</ref>
==== Utilizzo come controllo dell'accesso ====
Riga 111 ⟶ 129:
==== In caso di chiave privata segreta compromessa ====
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]] [[Diffie-Hellman]] (DHE) e [[Elliptic curve Diffie-Hellman]] (ECDHE)
Riga 128 ⟶ 146:
|urlarchivio = https://web.archive.org/web/20090526233211/http://www.mozilla.com/en-US/legal/privacy/firefox-en.html
|dataarchivio = 26 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
|pubblicazione=
}}</ref> e Internet Explorer su [[Windows Vista]]<ref>{{Cita web|url=https://msdn.microsoft.com/en-us/library/bb250503.aspx▼
|urlarchivio=https://web.archive.org/web/20090712032745/http://news.softpedia.com/news/Opera-8-launched-on-FTP-1330.shtml
|dataarchivio=12 luglio 2009
|urlmorto=sì
▲}}</ref> e Internet Explorer su [[Windows Vista]]<ref>{{Cita web
|url=https://msdn.microsoft.com/en-us/library/bb250503.aspx
|titolo=HTTPS Security Improvements in Internet Explorer 7
|cognome=Lawrence
Riga 140 ⟶ 164:
|data=31 gennaio 2006
|accesso=13 maggio 2009
|urlarchivio=https://web.archive.org/web/20171001051314/https://msdn.microsoft.com/en-us/library/bb250503.aspx
}}</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▼
|dataarchivio=1 ottobre 2017
|urlmorto=no
▲}}</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= |accesso=13 maggio 2009
|urlarchivio=https://web.archive.org/web/20171125063121/https://tools.ietf.org/html/rfc2560
|dataarchivio=25 novembre 2017
|urlmorto=no
}}</ref>
Riga 161 ⟶ 195:
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 ''[[Attacco man in the middle|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|urlarchivio=https://web.archive.org/web/20180314095223/https://www.eff.org/https-everywhere/deploying-https|dataarchivio=14 marzo 2018|urlmorto=no}}</ref><ref name="HSTSMDN" />
=== Limiti ===
Riga 179 ⟶ 213:
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=https://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts|titolo=SSL/TLS Strong Encryption: FAQ|sito=apache.org|accesso=1 maggio 2019|urlarchivio=https://web.archive.org/web/20181019105423/http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts|dataarchivio=19 ottobre 2018|urlmorto=no}}</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=https://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx |titolo=Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2
|cognome=Lawrence
Riga 188 ⟶ 223:
|data=22 ottobre 2005
|accesso=12 maggio 2009
|urlarchivio=https://web.archive.org/web/20100126041019/http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
}}</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>▼
|dataarchivio=26 gennaio 2010
|urlmorto=no
▲}}</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|accesso=13 maggio 2016|urlarchivio=https://web.archive.org/web/20170630170605/http://blog.ebrahim.org/2006/02/21/server-name-indication-sni/|dataarchivio=30 giugno 2017|urlmorto=sì}}</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 |urlarchivio= https://web.archive.org/web/20181008070112/https://bugzilla.mozilla.org/show_bug.cgi?id=116169 |dataarchivio= 8 ottobre 2018 |urlmorto= sì }}</ref>
Da un punto di vista architetturale:
Riga 204 ⟶ 242:
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
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|accesso=13 maggio 2016|urlarchivio=https://web.archive.org/web/20160531223219/http://bradmiller.io/resources/pets2014.pdf|dataarchivio=31 maggio 2016|urlmorto=no}}</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.
▲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 ===
Riga 231 ⟶ 266:
== Altri progetti ==
{{interprogetto|preposizione=sull'}}
== Collegamenti esterni ==
* {{Collegamenti esterni}}
* {{FOLDOC}}
=== Documenti ufficiali ===
* {{cita web|https://tools.ietf.org/html/rfc2818|RFC 2818: HTTP Over TLS}}
Riga 243 ⟶ 280:
* [https://github.com/kevinjacobs/HTTPS-Finder HTTPS Finder] un'estensione per Firefox che mantiene aggiornata la lista di HTTPS Everywhere.
{{Browser Internet}}
{{IPstack}}
{{Portale|Sicurezza informatica|Telematica}}
[[Categoria:Protocolli crittografici]]
[[Categoria:Hypertext Transfer Protocol]]
| |||