Vai al contenuto

HTTPS

Da Wikipedia, l'enciclopedia libera.
(Reindirizzamento da Https)
Icona del lucchetto, che nei browser contraddistingue l'uso di HTTPS.
Icona del lucchetto di HTTPS

In telecomunicazioni e informatica l'HyperText Transfer Protocol over Secure Socket Layer (HTTPS), (anche noto come HTTP over TLS,[1][2] HTTP over SSL[3] e HTTP Secure[4][5]) è un protocollo per la comunicazione sicura attraverso una rete di computer utilizzato su Internet. La porta utilizzata generalmente (ma non necessariamente) è la 443. Consiste nella comunicazione tramite il protocollo HTTP (Hypertext Transfer Protocol) all'interno di una connessione criptata, tramite crittografia asimmetrica, dal Transport Layer Security (TLS) o dal suo predecessore, Secure Sockets Layer (SSL) fornendo come requisiti chiave:

  1. un'autenticazione del sito web visitato;
  2. protezione della privacy (riservatezza o confidenzialità);
  3. integrità dei dati scambiati tra le parti comunicanti.

Nel suo popolare funzionamento su Internet, HTTPS fornisce la sicurezza 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 la quale viene ascoltata segretamente la conversazione privata tra le parti senza il loro consenso) e tampering (letteralmente manomissione o alterazione della comunicazione) falsificandone i contenuti.[6] 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.

Storicamente, le connessioni HTTPS erano usate soprattutto per i pagamenti nelle transazioni sul World Wide Web (in particolare per il commercio elettronico), e-mail e per le transazioni sensibili all'interno dei 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 pagine web, la sicurezza degli account utente e per mantenere private le comunicazioni, l'identità e la navigazione web dell'utente.

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.

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, 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 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 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.[6]

I browser web sanno come fidarsi dei siti web HTTPS basati su 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ò 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 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.[7]

HTTPS è anche molto importante con le connessioni sulla rete 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[6], il quale è incluso all'interno del pacchetto Tor Browser.[8]

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.[9][10] 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.[2][11][12]

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 SSL stripping. [12][13]

HTTPS non dovrebbe essere confuso con il protocollo poco utilizzato Secure HTTP (S-HTTP) descritto nella specifica RFC 2660.

Utilizzo nei siti web

[modifica | modifica wikitesto]

Alla data del 3 maggio 2017, il 56,8% dei 139 032 maggiori siti web ha un'implementazione sicura del protocollo HTTPS.[14] HTTPS è utilizzato dal 5,24% del totale dei domini italiani registrati[15].

Integrazione nei browser

[modifica | modifica wikitesto]

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.

Firefox usa il protocollo HTTPS per le ricerche Google dalla versione 14,[16] 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".[17]

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 browser Google Chrome, Mozilla Firefox (anche su Android) e Opera è disponibile un add-on chiamato “HTTPS Everywhere” che abilita il protocollo HTTPS di default per centinaia di siti web.

La sicurezza di HTTPS è garantita dal protocollo 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 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.[18][19] 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.[20]

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 cookies su un sito web attivo tramite protocollo HTTPS, devono avere l'attributo di protezione abilitato.[12]

Aspetti tecnici

[modifica | modifica wikitesto]

Differenza da HTTP

[modifica | modifica wikitesto]

Le URL del protocollo HTTPS iniziano con https:// e utilizzano la porta 443 di default, mentre le URL HTTP cominciano con http:// e utilizzano la porta 80.

HTTP non è criptato, quindi è vulnerabile alle intercettazioni e ad attacchi man-in-the-middle: gli attaccanti possono ottenere l'accesso ad account di siti web con informazioni sensibili, o 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 SSL).

Livelli di rete

[modifica | modifica wikitesto]

HTTPS opera al livello più alto del modello TCP/IP, il livello di applicazione; come fa anche il protocollo di sicurezza TLS (operando come un sotto-strato più basso dello stesso livello).

In pratica, tra il protocollo TCP e 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 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. 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 “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

[modifica | modifica wikitesto]

I certificati firmati autorevolmente possono essere gratuiti[21][22] oppure costare tra gli 8[23] e i 70[24] 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. Tuttavia, quest'ultima non è inclusa nei certificati di origine fidati di molti browser web popolari (e.g. Firefox, 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[25] e fornisce certificati SSL/TLS automatici e gratuiti per siti web.[26] 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.”[27]

Utilizzo come controllo dell'accesso

[modifica | modifica wikitesto]

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

[modifica | modifica wikitesto]

Un’importante proprietà in questo contesto è la 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 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.[20] 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,[28] Opera,[29] e Internet Explorer su Windows Vista[30] implementano il protocollo Online Certificate Status Protocol (OCSP) e l'autorità risponde, indicando al browser se il certificato è ancora valido o meno.[31]

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.

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.[12][13]

Il protocollo SSL/TLS è disponibile con due opzioni, semplice e mutua. Nella versione semplice, solo il server si occupa di garantire la sicurezza della comunicazione. 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 web crawler, e in alcuni casi l'URI della risorsa cifrata può essere dedotta conoscendo solo la dimensione della richiesta/risposta intercettata.[32] 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.[33] Questo significa che, nella maggior parte dei casi, non è possibile usare l'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.[34][35][36]

Da un punto di vista architetturale:

  1. 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 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.
  2. 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.
  3. 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 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 Brad Miller, ha dimostrato un approccio generalizzato all'analisi del traffico HTTPS basato sull'apprendimento automatico.[37][38] I ricercatori hanno dimostrato tale attacco applicato ad un range di siti web, inclusi Mayo Clinic, Planned Parenthood e YouTube.[39] 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.

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.

  1. ^ Network Working Group, HTTP Over TLS, su tools.ietf.org, The Internet Engineering Task Force, May 2000. URL consultato il 27 febbraio 2015 (archiviato il 31 ottobre 2018).
  2. ^ a b HTTPS as a ranking signal, su Google Webmaster Central Blog, Google Inc., 6 agosto 2014. URL consultato il 27 febbraio 2015 (archiviato dall'url originale l'8 marzo 2016).
    «You can mae your site secure with HTTPS (Hypertext Transfer Protocol Secure) [...]»
  3. ^ Enabling HTTP Over SSL, su docs.adobe.com, Adobe Systems Incorporated. URL consultato il 27 febbraio 2015 (archiviato l'8 marzo 2015).
  4. ^ Secure your site with HTTPS, su Google Support, Google, Inc.. URL consultato il 27 febbraio 2015 (archiviato il 15 dicembre 2017).
  5. ^ What is HTTPS?, su instantssl.com, Comodo CA Limited. URL consultato il 27 febbraio 2015 (archiviato dall'url originale il 12 febbraio 2015).
    «Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP [...]»
  6. ^ a b c HTTPS Everywhere FAQ, su eff.org. URL consultato il 3 maggio 2012 (archiviato il 20 aprile 2018).
  7. ^ Hotel Wifi JavaScript Injection, su justinsomnia.org. URL consultato il 24 luglio 2012 (archiviato il 24 luglio 2012).
  8. ^ The Tor Project, Inc., Tor, su torproject.org. URL consultato il 12 maggio 2016 (archiviato il 17 luglio 2013).
  9. ^ Konigsburg, Eitan, Pant, Rajiv e Kvochko, Elena, Embracing HTTPS, su open.blogs.nytimes.com, The New York Times, 13 novembre 2014. URL consultato il 27 febbraio 2015 (archiviato dall'url originale il 22 aprile 2018).
  10. ^ Gallagher, Kevin, Fifteen Months After the NSA Revelations, Why Aren’t More News Organizations Using HTTPS?, su freedom.press, Freedom of the Press Foundation, 12 settembre 2014. URL consultato il 27 febbraio 2015 (archiviato dall'url originale il 2 dicembre 2016).
  11. ^ Grigorik, Ilya e Far, Pierre, Google I/O 2014 - HTTPS Everywhere, su youtube.com, Google Developers, 26 giugno 2014. URL consultato il 27 febbraio 2015 (archiviato il 15 marzo 2018).
  12. ^ a b c d How to Deploy HTTPS Correctly, su eff.org. URL consultato il 13 giugno 2012 (archiviato il 14 marzo 2018).
  13. ^ a b HTTP Strict Transport Security, su Mozilla Developer Network. URL consultato il 14 ottobre 2015 (archiviato dall'url originale il 15 maggio 2012).
  14. ^ SSL Pulse, su trustworthyinternet.org, Trustworthy Internet Movement, 3 ottobre 2015. URL consultato il 7 Maggio 2017 (archiviato dall'url originale il 15 maggio 2017).
  15. ^ Statistiche internet in italiano centroli.it, su centroli.it. URL consultato il 7 Maggio 2017 (archiviato dall'url originale il 16 febbraio 2017).
  16. ^ Firefox 14.0.1 Release Notes, su mozilla.org. URL consultato il 24 luglio 2012 (archiviato il 22 luglio 2012).
  17. ^ Firefox Rolling Out HTTPS Google search, su blog.mozilla.org. URL consultato il 24 luglio 2012 (archiviato il 20 luglio 2012).
  18. ^ Law Enforcement Appliance Subverts SSL Archiviato il 15 marzo 2014 in Internet Archive., Wired, 2010-04-03.
  19. ^ New Research Suggests That Governments May Fake SSL Certificates Archiviato il 4 gennaio 2016 in Internet Archive., EFF, 2010-03-24.
  20. ^ a b SSL: Intercepted today, decrypted tomorrow Archiviato il 21 settembre 2013 in Internet Archive., Netcraft, 2013-06-25.
  21. ^ Free SSL Certificates from a Free Certificate Authority, su sslshopper.com. URL consultato il 24 ottobre 2009 (archiviato il 9 febbraio 2010).
  22. ^ Justin Fielding, Secure Outlook Web Access with (free) SSL: Part 1, su techrepublic.com, TechRepublic, 16 luglio 2006. URL consultato il 24 ottobre 2009 (archiviato il 24 marzo 2011).
  23. ^ Namecheap.com SSL Services, su namecheap.com, namecheap. URL consultato il 30 gennaio 2012 (archiviato il 4 febbraio 2012).
  24. ^ Secure Site Pro with SSL Certificate, su ssl.comodo.com. URL consultato il 23 Aug 2014 (archiviato il 26 agosto 2014).
  25. ^ Launch schedule, su Let's Encrypt. URL consultato il 21 settembre 2015 (archiviato il 27 settembre 2015).
  26. ^ (EN) Kerner, Sean Michael, Let's Encrypt Effort Aims to Improve Internet Security, su eWeek.com, Quinstreet Enterprise, 18 novembre 2014. URL consultato il 18 novembre 2022 (archiviato dall'url originale il 19 novembre 2014).
  27. ^ Eckersley, Peter, Launching in 2015: A Certificate Authority to Encrypt the Entire Web, su eff.org, Electronic Frontier Foundation, 18 novembre 2014. URL consultato il 27 febbraio 2015 (archiviato il 10 maggio 2018).
  28. ^ Mozilla Firefox Privacy Policy, su mozilla.com, Mozilla Foundation, 27 aprile 2009. URL consultato il 13 maggio 2009 (archiviato dall'url originale il 26 maggio 2009).
  29. ^ Opera 8 launched on FTP, Softpedia, 19 aprile 2005. URL consultato il 13 maggio 2009 (archiviato dall'url originale il 12 luglio 2009).
  30. ^ Eric Lawrence, HTTPS Security Improvements in Internet Explorer 7, su msdn.microsoft.com, MSDN, 31 gennaio 2006. URL consultato il 13 maggio 2009 (archiviato il 1º ottobre 2017).
  31. ^ Myers, M, Ankney, R, Malpani, A, Galperin, S e Adams, C, Online Certificate Status Protocol – OCSP, su tools.ietf.org, Internet Engineering Task Force, June 1999. URL consultato il 13 maggio 2009 (archiviato il 25 novembre 2017).
  32. ^ Stanislaw Pusep, The Pirate Bay un-SSL, su sysd.org, 31 luglio 2008. URL consultato il 6 marzo 2009 (archiviato dall'url originale l'8 marzo 2009).
  33. ^ SSL/TLS Strong Encryption: FAQ, su apache.org. URL consultato il 1º maggio 2019 (archiviato il 19 ottobre 2018).
  34. ^ Eric Lawrence, Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2, su blogs.msdn.com, Microsoft, 22 ottobre 2005. URL consultato il 12 maggio 2009 (archiviato il 26 gennaio 2010).
  35. ^ Server Name Indication (SNI), su inside aebrahim's head. URL consultato il 13 maggio 2016 (archiviato dall'url originale il 30 giugno 2017).
  36. ^ Julien Pierre, Browser support for TLS server name indication, su Bugzilla, Mozilla Foundation, 19 dicembre 2001. URL consultato il 15 dicembre 2010 (archiviato dall'url originale l'8 ottobre 2018).
  37. ^ Statistical Tricks Extract Sensitive Data from Encrypted Communications, su technologyreview.com, MIT Technology Review, 19 giugno 2014.
  38. ^ Researchers Use Big Data to Get Around Encryption, su blogs.wsj.com, The Wall Street Journal, 23 giugno 2014. URL consultato il 13 maggio 2016 (archiviato il 18 marzo 2016).
  39. ^ Brad Miller, Ling Huang, Anthony D. Joseph, J.D. Tygar, I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis (PDF), su bradmiller.io. URL consultato il 13 maggio 2016 (archiviato il 31 maggio 2016).

Voci correlate

[modifica | modifica wikitesto]

Altri progetti

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]

Documenti ufficiali

[modifica | modifica wikitesto]

Estensioni per i browser

[modifica | modifica wikitesto]