Sisupoika
28-02-2011, 21:01
Come qualcuno ricordera', in una recente discussione accennai all'intenzione di creare una serie di posts sul mio blog su vari metodi per rendere la navigazione Internet piu' sicura e privata. Sono un po' in ritardo con quella serie di posts, comunque oggi ho scritto un primo post sulla questione con l'obiettivo di far luce sul perche' c'e' la necessita' ancora oggi che noi, come utenti, sopperiamo a delle mancanze da parte di chi gestisce siti Internet di ogni tipo. Penso sia una buona base anche perche' aiutera' a capire, con i successivi post, perche' soluzioni dal lato utente sono comunque limitate e ci sara' sempre e bisogno di migliori soluzioni a monte.
Qui (http://vitobotta.com/why-isnt-ssl-on-by-default-for-all-websites/) trovate il post originale (in Inglese), mentre di sotto c'e' la traduzione.
Buona lettura :)
(p.s.. assurdo quante volte io abbia avuto bisogno di tradurre dal mio testo in Inglese all'Italiano... ormai sto perdendo pezzi di Italiano! Questo e' dunque una sorta di esercizio per me :D)
=========================================================
Perche' SSL non e' attivato by default su tutti i siti?
C'e' stato un gran bel parlare, negli ultimi mesi, a proposito di una estensione per Firefox chiamata Firesheep (http://codebutler.github.com/firesheep/) che, a dire del suo autore Eric Butler, dimostra attacchi di HTTP session hijacking (http://en.wikipedia.org/wiki/Session_hijacking).
Le discussioni su Internet sull'argomento sono state abbastanza intense, con molte persone che lo hanno ringraziato per aver contribuito a sollevare l'attenzione sui problemi in termini di sicurezza delle moderne applicazioni Internet, e molti altri che lo hanno accusato invece di aver reso fin troppo semplice per chiunque - anche persone che conoscono poco o niente di sicurezza - riuscire ad accedere ai profili di altre persone su social networks, webmails e altre applicazioni web, a patto che vi siano le condizioni richieste. In realta', questi problemi sono ormai ben noti da anni, pertanto c'e' molto poco di cui accusare Butler a mio avviso, mentre dovremmo prestare piu' attenzione al perche' la maggior parte dei siti e' ancora vulnerabile a questi problemi, ancora oggi. Dunque, se i problemi sollevati da Firesheep difficilmente costituiscono news, perche' ha catturato cosi' tanta attenzione nel corso degli ultimi mesi?
Un po' di contesto
Ogni qualvolta accedi ad un qualunque sito web che richieste autenticazione, tipicamente si verificano due eventi:
1- primo, di solito ti viene mostrata una pagina che ti chiede di inserire le tue credenziali di accesso (solitamente un nome utente ed una parola chiave - a meno che il servizio usi OpenID (http://en.wikipedia.org/wiki/OpenID) o qualunque altro sistema di single sign on (http://en.wikipedia.org/wiki/Single%20sign-on), il che e' tutt'altra faccenda), e in seguito all'invio di un form, se le tue credenziali corrispondono a quelle di un account valido nel sistema, vieni autenticato e rediretto ad una pagina o area del sito il cui accesso sarebbe altrimenti proibito.
2- per migliore usabilita', il sito potrebbe far uso di cookies (http://en.wikipedia.org/wiki/HTTP%20cookie) per rendere accessi persistenti tra una sessione e l'altra, cosi' che tu non abbia bisogno di fare login ogni volta che apri il browser e visiti le pagine protette - a meno che tu abbia fatto logout in precedenza o che questi cookies siano gia' scaduti.
Durante la prima fase, l'autenticazione richiede che le tue credenziali viaggino su Internet per raggiungere la loro destinazione, e -a causa di come Internet funziona- e' probabile che questi dati viaggino attraverso un certo numero di reti diverse tra il tuo browser e i server di destinazione; se questi dati sono trasmessi in chiaro per mezzo di una connessione non criptata, allora c'e' il rischio potenziale che qualcuno possa essere in grado di intercettare questo traffico, e pertanto di essi potrebbero appropriarsi delle tue credenziali ed essere in grado di accedere al sito impersonando te. Negli anni, sono state sperimentate diverse tecniche con diversi livelli di successo per proteggere credenziali di accesso, ma ad oggi l'unica che ha dimostrato di essere efficace -per la piu' parte- e' la crittografia completa dei dati.
Nella maggioranza dei casi, la crittografia dei dati trasferiti avanti e dietro tra i server che ospitano le applicazioni web e gli utenti, e' fatta attraverso l'uso di HTTPS (http://en.wikipedia.org/wiki/HTTPS). Cioe', il protocollo HTTP standard, ma con la comunicazione criptata con SSL (http://en.wikipedia.org/wiki/Secure%20Sockets%20Layer). SSL funziona molto bene per la piu' parte: oggi giorno e' economicamente e computalmente poco costosa, ed e' supportata da molti tipi di client. La crittografia SSL non e' comunque perfetta: ha alcuni svantaggi di carattere tecnico e al di la' di questi, spesso da' all'utente un falso senso di sicurezza se prendiamo in considerazione anche altri tipi di problemi in termini di sicurezza che affliggono le applicazioni web di oggi come -per esempio- il Cross-Site Scripting (http://en.wikipedia.org/wiki/Cross-site%20scripting): molta gente pensa che un sito sia "sicuro" fintantoche' esso utilizza SSL (e alcuni siti addirittura mostrano un banner che dice "questo sito e' sicuro" e porta al loro provider di certificati SSL... -buona ed economica pubblicita' per queste aziende), mentre in realta' la maggioranza dei siti potrebbe essere afflitta da altre vulnerabilita' a prescindere dal fatto che essi usino crittografia SSL oppure no. Tuttavia, se dimentichiamo per un attimo queste altre vulnerabilita', il problema principale con la crittografia SSL e', ironicamente, nel modo in cui essa e' utilizzata dalla maggioranza dei siti, piuttosto che nella crittografia SSL stessa.
Come anticipato sopra, le applicazioni web di solito fanno uso di cookies per rendere accessi persistenti tra una sessione e l'altra; questo e' dovuto al fatto che il web e' stateless (http://en.wikipedia.org/wiki/State%20%28computer%20science%29). Affinche' cio' funzioni, e' necessario che questi cookies viaggino tra client e server con ogni richiesta, cioe' per ciascuna pagina che visiti durante una sessione con lo stesso sito. In questo modo l'applicazione dall'altro lato puo' riconoscere ciascuna richiesta effettuata dal tuo client e mantenerti loggato finche' i cookies di autenticazione sono disponibili e ancora validi.
Il problema principale su cui Firesheep ha fatto luce e' che la maggioranza dei siti abilita o forza l'uso della crittografia SSL soltanto durante la fase di autenticazione, cosi' da proteggere le tue credenziali di accesso, ma poi torna ad usare i soliti, non crittografati, trasferimenti HTTP dal quel momento in poi. Cio' significa che se il sito rende accessi persistenti attraverso l'uso di cookies, poiche' questi cookies -come detto- devono viaggiare con ciascuna richiesta, a meno che i dati di autenticazioni contenuti in essi siano essi stessi crittografati o protetti in un modo o nell'altro (a tal proposito, consiglio di leggere questo (http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)), non appena l'utente e' stato autenticato questi cookies viaggeranno con le successive richieste HTTP in forma chiara (non criptata), cosi' il rischio originale che qualcuno possa essere in grado di intercettare ed utillizzare queste informazioni esiste ancora; l'unica differenza e' che in questo caso chi attacca dovrebbe molto piu' probabilmente appropriarsi della tua sessione riutilizzando i cookies rubati nel proprio browser, piuttosto che cercare di accedere essi stessi utilizzando le tue credenziali di accesso direttamente nel form di autenticazione (questo e' perche' questi cookies, di solito, contengono tokens di autenticazione (http://en.wikipedia.org/wiki/Security%20token) piuttosto che credenziali di accesso). Il risultato finale, comunque, e' praticamente lo stesso nel senso che chi attacca puo' impersonare te nel contesto della applicazione.
Dunque, perche' i siti semplicemente non usano SSL sempre?
Requisiti in CPU e memoria, latenza
A questo punto, se ti stai chiedendo perche tutte le aziende semplicemente non abilitano SSL come predefinito per tutti i loro servizi, sempre, forse la motivazione piu' comune e' che, tradizionalmente, e' risaputo che traffico HTTP criptato con SSL richiede piu' risorse (soprattutto CPU e memoria) sui server, in confronto a traffico HTTP non criptato. Mentre cio' e' vero, con l'hardware disponibile oggi questo davvero non costituisce piu' un problema significativamene di rilievo, come anche dimostrato da Google quando hanno deciso di consentire l'uso di crittografia SSL per tutte le richieste verso tutti i loro servizi (http://www.theregister.co.uk/2010/05/21/google_search_ssl_encryption/), persino per il loro popolare motore di ricerca. Ecco cio' che l'ingegnere Adam Langley di Google disse in proposito qualche mese fa:
" tutti i nostri utenti utilizzano HTTPS per rendere sicura la loro email tra i loro browser e Google, tutto il tempo. Per rendere cio' possibile noi non abbiamo avuto bisogno di utilizzare macchine aggiuntive e nessun hardware speciale. Sulle nostre macchine di produzione, SSL/TLS richiede meno dell'1% di carico sulle CPU, meno di 10KB di memoria per connessione e meno del 2% di traffico di rete. Molta gente crede che SSL richieda molta CPU e noi speriamo che i numeri di cui sopra (pubblici per la prima volta) aiutino a sfatare questo mito. "
Dunque, se SSL/TLS non richiede un quantitativo di risorse sui server significativamente piu' alto, e' praticamente come HTTP non criptato, soltanto piu' sicuro? Bene, piu' o meno. In realta', SSL introduce ancora della latenza soprattutto nella fase di handshake (http://support.microsoft.com/kb/257591) (fino a 3 o 4 volte piu' alta che senza SSL), e richiede ancora della memoria in piu'; tuttavia, una volta che l'handshake e' stato effettuato, la latenza e' ridotta un po', inoltre Google sta lavorando a metodi per migliorarla (http://www.imperialviolet.org/2010/09/05/blacklisting.html). Dunque le connessioni sono un po' piu' lente, vero, ma Google -vedi il post di Langley- ha parzialmente risolto questi problemi utilizzando parecchio il caching anche di richieste HTTPS. Google ha anche risolto il problema del piu' alto requisito in memoria modificando OpenSSL (http://en.wikipedia.org/wiki/OpenSSL) cosi' da ridurre fino al 90% la memoria allocata per ogni connessione.
Contenuti statici e CDN
A parte requisiti di CPU e memoria e maggiore latenza, vi sono altri problemi da tenere in conto quando si attiva SSL per tutto il tempo per un sito. Per esempio, molti siti (soprattutto siti grandi e popolari come Facebook e altri che sono stati presi di mira da Firesheep) utilizzano una distribuzione CDN (http://en.wikipedia.org/wiki/Content%20delivery%20network) per ridurre il carico sui propri server, ma anche per migliorare le prestazioni per i loro utenti a seconda della loro locazione geografica; le CDN sono ottime per questo scopo poiche' sono molto ottimizzate per service contenuti statici da locazioni piu' vicine agli utenti. Questo spesso riduce latenza e cosi' aiuta a migliorare le prestazioni generali del sito per quegli utenti. Nella maggioranza dei casi, utilizzare una CDN e' tanto semplice quanto il servire il contenuto statico da hostname canonici (http://en.wikipedia.org/wiki/CNAME%20record) che puntano direttamente ai server della CDN.
Ma cosa accade se un sito che fa uso di una CDN viene adattato per utilizzare SSL tutto il tempo? Prima, alcune considerazioni generali sull'uso di crittografia SSL con contenuto statico.
Per "contenuto statico", solitamente si intende immagini, stylesheet, JavaScript, file disponibili per il download e qualunque oggetto che non necessiti di processing sul lato server. Questo genere di contenuti non dovrebbe mai contenere informazioni private; pertanto, almeno in teoria, potremmo mischiare contenuto privato e criptato con SSL e servito con HTTPS, con contenuto statico non criptato, attraverso HTTP, per lo stesso sito, allo stesso tempo. In realta', a causa di come il supporto SSL e' implementato nei browser, se una pagina che usa SSL include anche immagini e altri contenuti statici che sono scaricati con normali trasferimenti HTTP, il browser mostrera' un avviso che potrebbe "spaventare" utenti che non sanno cosa SSL/HTTPS sia. Questo e' un esempio con Internet Explorer:
http://cdn.vitobotta.com/uploads/2011/02/mixed-http-https.png
A causa di cio', e' chiaro che affinche' una pagina facente uso di SSL funzioni correttamente nei browser, tutti i contenuti statici inclusi nella pagina devono anch'essi essere serviti con crittografia SSL. Ma cio' suona come uno spreco di risorse, vero? Davvero abbiamo bisogno di criptare immagini? Dunque potresti chiederti perche' i browser si comportano a quel modo mostrando quel genere di avvisi. A dire il vero, c'e' una ragione molto valida: ti ricordi dei cookies? Se una pagina e' criptata con SSL ma include anche contenuti statici che sono scaricati con trasferimenti HTTP normali e non criptati, finche' questi contenuti sono serviti da hostnames che possono accedere gli stessi cookies della pagina criptata questi quei cookies viaggeranno in chiaro attraverso HTTP assieme a quei contenuti (per le ragioni che ho gia' menzionato), rendendo di fatto la crittografia SSL della pagina stessa pressocche' inutile. Se i browser non mostrassero quel genere di avviso, sarebbe possibile evitare questo problema facendo in modo che i contenuti statici vengano serviti da hostnames che non possono accedere gli stessi cookies della pagina criptata (per esempio, con la pagina servita da dominio.com e i contenuti statici serviti da altrodominio.com, ma e' molto piu' semplice e sicuro abilitare e forzare la piena crittografia SSL per tutto quanto...
Suona strano, vero? Questo e' il web oggi... una collezione di tecnologie sviluppate per la maggior parte lungo tempo fa, quando non era possibile prevedere tutti i potenziali rischi che sono stati scoperti negli anni. E trovo divertente che nel corso degli ultimi anni abbiamo utilizzato buzzword come "web 2.0" non per riferirci ad un set di nuove tecnologie che risolvono questi problemi... ma per riferirci a nuovi modi di usare la vecchia roba (e forse neanche "nuovi"... se pensiamo ad AJAX (http://en.wikipedia.org/wiki/Ajax%20%28programming%29)) che hanno introdotto o fatto luce su piu' problemi di sicurezza che mai prima.
Tornando alle CDN....
SSL richiede un certificato (http://tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html) per ciascuno degli hostname usati per servire contenuti statici, oppure un certificato "wildcard" a patto che tutti gli hostname in uso siano semplicemente sotto domini di uno stesso nome a dominio (per esempio, static.dominio.com, immagini.dominio.com e www.dominio.com sarebbero tutti sotto domini del dominio dominio.com); se gli hostname per i contenuti statici che devono essere serviti da una CDN sono configurati come record CNAME che puntano direttamente ai server della CDN, richieste per quei contenuti statici ovviamente perverranno direttamente ai server della CDN piuttosto che ai server che ospitano il sito. Pertanto, nonostante i certificati SSL richiesti sarebbero gia' disponibili sui server del sito, quei certificati devono anche essere installati sui server della CDN affinche' la CDN possa servire contenuti statici da quegli hostname e crittografati con SSL; cosi' in teoria sarebbe necessario per il proprietario di un sito di fornire semplicemente all'azienda che opera la CDN i certificati richiesti; l'azienda della CDN poi dovra' installare quei certificati sui loro server. In realta', il supporto SSL disponibile con alcuni provider di CDN puo' essere seriamente costoso dal momento che richiede setup addizionale e infrastrutture adeguate a causa dei piu' alti requisiti di cui abbiamo gia' parlato; inoltre, la maggior parte dei servizi CDN non offre neanche questa possibilita' dal momento che tradizionalmnte sono sempre stati ottimizzati per traffico HTTP non criptato, almeno fino a questo momento.
Come puoi facilmente immaginare, i problemi con contenuto statici e CDN da soli possono gia' essere un qualcosa che potrebbe rendere la conversione di un sito come Facebook all'uso predefinito di SSL tutto il tempo, molto piu' impegnativo di quanto atteso.
Cookie "sicuri"
Dopo tutto cio' che ho gia' detto a proposito dei cookie, potresti pensare che finche' un sito usa SSL come condizione predefinita, tutto dovrebbe essere OK. Uhm... non esattamente. Se il sito usa come predefinito SSL ma ancora consente richieste ad una pagina con HTTP non criptato, sarebbe ancora possibile sottrarre cookie contenenti informazioni di autenticazione e id di sessione effettuando appunto una richiesta non criptata (http:// senza la s) verso il sito vittima.
Questo permettera' ancora una volta ai cookie di viaggiare non criptati, e pertanto essi potrebbero ancora essere usati da un malintenzionato per fare il replay della sessione di un utente vittima e impersonare la vittima nel contesto della applicazione web.
Ci sono due metodi per evitare che cio' avvenga. Il primo e' quello di attivare il flag secure dei cookie, che significa che i cookie possono essere scaricati soltanto con https://, pertanto essi saranno crittografati e il problema scompare. Il secondo consiste nel far si' che il web server che ospita l'applicazione applichi, forzandolo, SSL traducendo richieste http:// in richieste https://. Entrambi i metodi hanno praticamente lo stesso effetto riguardo ai cookie, comunque preferisco il secondo dal momento che esso aiuta anche a prevenire i problemi col contenuto misto criptato/non criptato di cui abbiamo parlato in precedenza e i connessi avvisi da parte dei browser.
Siti che usano SSL ma soltanto per l'azione di "submit" di un form di autenticazione
Ho visto SSL utilizzato in molti modi errati, ma questo e' il mio preferito. Ho accennato a come Firesheep abbia fatto luce sul fatto che la maggioranza dei siti utilizzi SSL soltanto per la pagina di login, and sul perche' questo e' un modo debole di proteggere le credenziali di accesso degli utenti. Purtroppo, vi sono anche siti che utilizzano SSL soltanto non per la pagina di login stessa, che contiene semplicemente il form di autenticazione, ma per la pagina alla quale le credenziali di accesso dell'utente vengono inviate dal form.
Ho trovato un esempio poco fa di un sito che una volta cliccato sul link di "Login", mi ha portato alla pagina http://domain.com/login.php - dunque senza SSL. Ma nel codice sorgente della pagina ho potuto vedere che la destinazione del form era invece impostata alla pagina https://domain.com/authenticate.php che invece usa SSL. Cio' potrebbe suonare come corretto, dal momento che le credenziali dell'utente verrebbero inviate al server in forma criptata con SSL. Ma c'e' un problema: poiche' la pagina di login stessa non e' criptata, chi puo' garantire che essa non venga modificata e che non invii forse le credenziali dell'utente ad un'altra pagina (una pagina su cui chi opera l'attacco ha controllo) piuttosto che la pagina authenticate.php attesa secondo quanto previsto dall'autore del sito?
Vedi adesso perche' questa non e' una buona idea?
Contenuto servito da terze parti
Le CDN sono soltanto una parte della storia quando si tratta di contenuti statici. L'altra parte della storia riguarda contenuti che potrebbero essere inclusi in una pagina ma in realta' provenire da sistemi di altri e tu non hai alcun controllo ne' sui contenuti stessi ne' sul modo in cui questi contenuti vengono serviti. Questo e' diventato un problema di crescente importanza con l'avvento di social network, aggregatori di contenuti e servizi che aggiungono nuove funzionalita' ad un sito, molto facilmente. Pensa a tutti i pulsanti per la condivisione di contenuti su social network che oggi giorno vediamo su quasi tutti i siti; e' estremamente semplice per il proprietario di un sito integrare questi pulsanti in modo da contribuire a dirigere traffico verso il sito: nella maggioranza dei casi, tutto cio' che si deve fare e' aggiungere un po' di codice JavaScript alle pagine e il gioco e' fatto.
Ma cosa accade se attivi SSL per le tue pagine, ed esse includono questo genere di contenuti esterni? Molti di questi servizi gia' supportano il protocollo HTTPS., ma non tutti, per le ragioni che abbiamo gia' visto a proposito di maggiori requisiti in risorse. Inoltre, per quelli che supportano SSL/HTTPS, tu come proprietario di un sito devi accertarti ti utilizzare il codice giusto che si occupera' automaticamente di cambiare tra HTTP e HTTPS per i contenuti esterni a seconda del protocollo utilizzato dalla tua pagina. Altrimenti, potresti aver bisogno di adattare le tue pagine per far si' che questo meccanismo venga realizzato dal tuo codice, a patto che i contenuti esterni supportino almeno SSL.
Per quanto riguarda quei servizi che rendono semlice l'aggiunta di funzionalita' al tuo sito, ho gia' menzionato Disqus, per esempio, a proposito di commenti gestiti da terze parti. Vi sono altri servizi che fanno la stessa cosa (IntenseDebate e' uno di questi), e vi sono molti altri servizi che aggiungono altri tipi di funzionalita' come per esempio la possibilita' di votare contenuti o addirittura quella di far si' che gli utenti del tuo sito possano autenticarsi con esso utilizzando le proprie credenziali Facebook, Google, ecc.
Tutte queste possibilita' rendono molto semplice oggi giorno la creazione di siti molto ricchi in funzionalita' in molto meno tempo, e rendono molt o semplice il far si' che applicazioni possano interagire tra di loro e scambiarsi dati. Tuttavia, se possiedi un sito e stai pianificando di attivare SSL per il tuo sito indefinitamente, hai bisogno di accertarti che tutti i servizi esterni utilizzati dal tuo sito supportino gia' SSL. Altrimenti, quegli avvisi da parte dei browser che abbiamo visto saranno di ritorno, e con essi alcuni potenziali problemi di sicurezza.
Problemi con certificati SSL
C'e' un paio di altri problemi, forse meno importanti, ma che vale comunque la pena di menzionare, a proposito di nomi di dominio e certificati SSL, a prescindere dal fatto che una CDN sia usata o meno. Il primo e' che, normalmente, e' possibile raggiungere un sito sia con www che senza. Cosi' per esempio sia vitobotta.com che www.vitobotta.com portano al mio sito. Al momento, poiche' i miei lettori non hanno bisogno di autenticarsi sul mio sito (perche' i commenti sono gestiti da Disqus (http://disqus.com/)) non c'e' alcuna ragione per cui io potrei volere far si' che il mio sito utilizzi SSL sempre, per ora. Ma se volessi far cio', dovrei tenere in considerazione anche che sia vitobotta.com che www.vitobotta.com portano entrambi al mio sito, nel momento in cui dovessi acquistare un certificato SSL. Il motivo e' che non tutti i certificati SSL proteggono sia i domini con www che quelli senza; persino certificati "wildcard" spesso proteggono tutti i sotto domini (incluso www) ma non la versione del dominio senza www; cio' vuol dire che se acquisti il certificato sbagliato per un sito col quale vuoi usare SSL sempre, potresti in realta' aver bisogno di acquistare un certificato separato per la versione del dominio senza www. Stavo cercando un esempio e ne ho trovato uno molto velocemente nel sito del mio provider VPS (http://en.wikipedia.org/wiki/Virtual%20private%20server) preferito Linode (https://www.linode.com/). Il sito usa un certificato wildcard che protegge tutti i sotto domini *.linode.com, ma non linode.com, quindi se provi ad aprire https://www.linode.com/ nel tuo browser vedrai un avviso simile a questo (in Firefox nell'esempio):
http://cdn.vitobotta.com/uploads/2011/02/wild-certificate-non-www-domain.png
Generalmente parlando, e' meglio acquistare un certificato che protegga sia domini www che non-www (e forse anche altri sotto domini a seconda del caso). Nel caso tu sia interessato, un esempio di certificato wildcard economico che fa questo e' il RapidSSL Wildcard certificate (https://www.rapidsslonline.com/rapidsslwildcard-certificates.aspx). Una alternativa potrebbe essere un certificato col campo subjectAltName, che ti consente ti specificare tutti gli hostname che vuoi proteggere con un singolo certificato (a patto di conoscerli tutti in anticipo).
L'altro problema con i certificati e' che spesso le aziende acquistano varie versioni dello stesso nome di dominio che differiscono soltanto per l'estensione, con lo scopo di proteggere il branding del sito. Cosi', per esempio, un'azienda potrebbe voler acquistare i domini company.com, company.info, company.net, company.org, company.mobi e cosi' via; altrimenti, se loro acquistassero soltanto per esempio company.com, altri sarebbero in grado di acquistatre gli altri domini e utilizzarli a proprio vantaggio, tecniche illegali di SEO (http://en.wikipedia.org/wiki/Search%20engine%20optimization), e altro. Buon SEO richiede che un sito utilizzi soltanto un nome di dominio, canonico, dunque e' una pratica raccomandata quella di redirezionare tutte le richieste verso i nomi di dominio alternativi al "piu' importante" che l'azienda vuole utilizzare come predefinito (per esempio company.com). Ma per quanto riguarda i certificati SSL, significa semplicemente che l'azienda dovra' spendere piu' denaro per acquistare certificati SSL.
Caching
Il caching e' una delle tecniche piu' comunemente usate da siti web per ridurre il carico sui server e migliorare le prestazioni sia sui server che sui client. Il problema col caching, nel contesto della crittografia SSL, consiste nel fatto che i browser si comportano in maniera diversa riguardo il modo in cui trattano il caching sul client di contenuti criptati con SSL. Alcuni consentono il caching di questi contenuti, altri no oppure soltanto temporaneamente in memoria ma non su disco, il che significa che la prossima volta l'utente visita gli stessi contenuti, questi contenuti dovranno essere nuovamente scaricati per intero, anche qualora essi non siano cambiati sin dall'ultima visita, pertanto impattando sulle prestazioni del sito.
E non riguarda soltanto i browser: Internet provider e aziende spesso usano proxy (http://en.wikipedia.org/wiki/Proxy%20server) server per fare caching di contenuti con lo scopo di rendere la navigazione web piu' veloce. La cosa divertente e' che molti proxy adibiti a caching, in condizioni predefinite, non effettuano il caching di contenuti criptati con SSL...
Allora... e' un web con SSL sempre attivo possibile oppure no?
E' bello vedere che Facebook adesso offre l'opzione di attivare SSL (http://www.theregister.co.uk/2011/01/26/facebook_https/). Tuttavia, cio' e' 1) deludente, in quanto e' soltanto una opzione, e la maggior parte degli utenti neanche sa cosa SSL sia; 2) sorprendente, che questo cambiamento sia arrivato non dopo tutto il rumore a causa di Firesheep, nonostante Facebook sia uno dei siti a piu' alto profilo presi di mira da Firesheep; il cambiamento, invece, giunse dopo che qualcuno era riuscito ad accedere al profilo Facebook di Mark Zuckerberg... Forse la privacy del CEO di Facebook e' piu' importante di quella degli altri utenti?
Per quanto riguarda gli altri diversi siti presi di mira da Firesheep, non ho ancora letto di altri che hanno cominciato ad usare SSL come predefinito.
Dunque, e' un processo lento.... ma penso definitivamente che sia possibile pensare ad un web interamente protetto da SSL in un futuro prossimo. Nonostante cambiare un sito perche' usi sempre SSL puo' essere tecnicamente piu' impegnativo di quanto non si possa immaginare, la realta' e' che tutte le difficolta' tecniche elencate qui sopra possono essere superate in un modo o nell'altro. Ho accennato a come Google abbia molto facilmente gia' adattato alcuni dei loro servizi affinche' essi usino SSL come predefinito. Pertanto cio' che Google ci mostra e' che altre aziende davvero non hanno alcuna scusa per non usare SSL per tutti i loro servizi, per tutto il tempo, dal momento che facendo questo potrebbero migliorare drammaticamente la sicurezza dei loro servizi (e, cosa piu' importante, la privacy dei loro utenti), se soltanto si interessassero di piu' a tutti i problemi menzionati.
L'unico reale problema che potrebbe essere un po' piu' difficile da superare a seconda della applicazione e del budget disponibile, e' di natura economica piuttosto che tecnica. E' vero che traffico criptato con SSL costa di piu' che il traffico non criptato, ma questo e' quanto. In particolare, mi riferisco al costo dei cambiamenti richiesti alla infrastruttura di un sito e della aggiuntiva gestione, piuttosto che al costo dei certificati SSL, che oggi giorno potrebbero non essere un problema persino per aziende piu' piccole.
E' improbabile che vedremo tecnologie completamente nuove e piu' sicure rimpiazzare il web come lo conosciamo oggi, nel prossimo futuro; ma e' probabile che con hardware e connessioni di reter sempre piu' veloci, prezzi di certificati SSL che vanno giu', e ulteriori miglioramenti alle tecnologie attuali, HTTPS sostituira' lo standard HTTP come il protocollo predefinito per Internet - prima o poi.
Nel frattempo, come utenti, possiamo aspettare che cio' avvenga, e pertanto esponendoci ai potenziali rischi, oppure possiamo invece risolvere almeno parzialmente il problema da parte nostra; nei prossimi post vedremo i metodi piu' semplici ed efficaci per rendere la navigazione Internet piu' sicura e privata con i piu' comuni sistemi operativi, e anche perche' ho usato il termine "parzialmente".
Dunque, come al solito, restate in ascolto!
Qui (http://vitobotta.com/why-isnt-ssl-on-by-default-for-all-websites/) trovate il post originale (in Inglese), mentre di sotto c'e' la traduzione.
Buona lettura :)
(p.s.. assurdo quante volte io abbia avuto bisogno di tradurre dal mio testo in Inglese all'Italiano... ormai sto perdendo pezzi di Italiano! Questo e' dunque una sorta di esercizio per me :D)
=========================================================
Perche' SSL non e' attivato by default su tutti i siti?
C'e' stato un gran bel parlare, negli ultimi mesi, a proposito di una estensione per Firefox chiamata Firesheep (http://codebutler.github.com/firesheep/) che, a dire del suo autore Eric Butler, dimostra attacchi di HTTP session hijacking (http://en.wikipedia.org/wiki/Session_hijacking).
Le discussioni su Internet sull'argomento sono state abbastanza intense, con molte persone che lo hanno ringraziato per aver contribuito a sollevare l'attenzione sui problemi in termini di sicurezza delle moderne applicazioni Internet, e molti altri che lo hanno accusato invece di aver reso fin troppo semplice per chiunque - anche persone che conoscono poco o niente di sicurezza - riuscire ad accedere ai profili di altre persone su social networks, webmails e altre applicazioni web, a patto che vi siano le condizioni richieste. In realta', questi problemi sono ormai ben noti da anni, pertanto c'e' molto poco di cui accusare Butler a mio avviso, mentre dovremmo prestare piu' attenzione al perche' la maggior parte dei siti e' ancora vulnerabile a questi problemi, ancora oggi. Dunque, se i problemi sollevati da Firesheep difficilmente costituiscono news, perche' ha catturato cosi' tanta attenzione nel corso degli ultimi mesi?
Un po' di contesto
Ogni qualvolta accedi ad un qualunque sito web che richieste autenticazione, tipicamente si verificano due eventi:
1- primo, di solito ti viene mostrata una pagina che ti chiede di inserire le tue credenziali di accesso (solitamente un nome utente ed una parola chiave - a meno che il servizio usi OpenID (http://en.wikipedia.org/wiki/OpenID) o qualunque altro sistema di single sign on (http://en.wikipedia.org/wiki/Single%20sign-on), il che e' tutt'altra faccenda), e in seguito all'invio di un form, se le tue credenziali corrispondono a quelle di un account valido nel sistema, vieni autenticato e rediretto ad una pagina o area del sito il cui accesso sarebbe altrimenti proibito.
2- per migliore usabilita', il sito potrebbe far uso di cookies (http://en.wikipedia.org/wiki/HTTP%20cookie) per rendere accessi persistenti tra una sessione e l'altra, cosi' che tu non abbia bisogno di fare login ogni volta che apri il browser e visiti le pagine protette - a meno che tu abbia fatto logout in precedenza o che questi cookies siano gia' scaduti.
Durante la prima fase, l'autenticazione richiede che le tue credenziali viaggino su Internet per raggiungere la loro destinazione, e -a causa di come Internet funziona- e' probabile che questi dati viaggino attraverso un certo numero di reti diverse tra il tuo browser e i server di destinazione; se questi dati sono trasmessi in chiaro per mezzo di una connessione non criptata, allora c'e' il rischio potenziale che qualcuno possa essere in grado di intercettare questo traffico, e pertanto di essi potrebbero appropriarsi delle tue credenziali ed essere in grado di accedere al sito impersonando te. Negli anni, sono state sperimentate diverse tecniche con diversi livelli di successo per proteggere credenziali di accesso, ma ad oggi l'unica che ha dimostrato di essere efficace -per la piu' parte- e' la crittografia completa dei dati.
Nella maggioranza dei casi, la crittografia dei dati trasferiti avanti e dietro tra i server che ospitano le applicazioni web e gli utenti, e' fatta attraverso l'uso di HTTPS (http://en.wikipedia.org/wiki/HTTPS). Cioe', il protocollo HTTP standard, ma con la comunicazione criptata con SSL (http://en.wikipedia.org/wiki/Secure%20Sockets%20Layer). SSL funziona molto bene per la piu' parte: oggi giorno e' economicamente e computalmente poco costosa, ed e' supportata da molti tipi di client. La crittografia SSL non e' comunque perfetta: ha alcuni svantaggi di carattere tecnico e al di la' di questi, spesso da' all'utente un falso senso di sicurezza se prendiamo in considerazione anche altri tipi di problemi in termini di sicurezza che affliggono le applicazioni web di oggi come -per esempio- il Cross-Site Scripting (http://en.wikipedia.org/wiki/Cross-site%20scripting): molta gente pensa che un sito sia "sicuro" fintantoche' esso utilizza SSL (e alcuni siti addirittura mostrano un banner che dice "questo sito e' sicuro" e porta al loro provider di certificati SSL... -buona ed economica pubblicita' per queste aziende), mentre in realta' la maggioranza dei siti potrebbe essere afflitta da altre vulnerabilita' a prescindere dal fatto che essi usino crittografia SSL oppure no. Tuttavia, se dimentichiamo per un attimo queste altre vulnerabilita', il problema principale con la crittografia SSL e', ironicamente, nel modo in cui essa e' utilizzata dalla maggioranza dei siti, piuttosto che nella crittografia SSL stessa.
Come anticipato sopra, le applicazioni web di solito fanno uso di cookies per rendere accessi persistenti tra una sessione e l'altra; questo e' dovuto al fatto che il web e' stateless (http://en.wikipedia.org/wiki/State%20%28computer%20science%29). Affinche' cio' funzioni, e' necessario che questi cookies viaggino tra client e server con ogni richiesta, cioe' per ciascuna pagina che visiti durante una sessione con lo stesso sito. In questo modo l'applicazione dall'altro lato puo' riconoscere ciascuna richiesta effettuata dal tuo client e mantenerti loggato finche' i cookies di autenticazione sono disponibili e ancora validi.
Il problema principale su cui Firesheep ha fatto luce e' che la maggioranza dei siti abilita o forza l'uso della crittografia SSL soltanto durante la fase di autenticazione, cosi' da proteggere le tue credenziali di accesso, ma poi torna ad usare i soliti, non crittografati, trasferimenti HTTP dal quel momento in poi. Cio' significa che se il sito rende accessi persistenti attraverso l'uso di cookies, poiche' questi cookies -come detto- devono viaggiare con ciascuna richiesta, a meno che i dati di autenticazioni contenuti in essi siano essi stessi crittografati o protetti in un modo o nell'altro (a tal proposito, consiglio di leggere questo (http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)), non appena l'utente e' stato autenticato questi cookies viaggeranno con le successive richieste HTTP in forma chiara (non criptata), cosi' il rischio originale che qualcuno possa essere in grado di intercettare ed utillizzare queste informazioni esiste ancora; l'unica differenza e' che in questo caso chi attacca dovrebbe molto piu' probabilmente appropriarsi della tua sessione riutilizzando i cookies rubati nel proprio browser, piuttosto che cercare di accedere essi stessi utilizzando le tue credenziali di accesso direttamente nel form di autenticazione (questo e' perche' questi cookies, di solito, contengono tokens di autenticazione (http://en.wikipedia.org/wiki/Security%20token) piuttosto che credenziali di accesso). Il risultato finale, comunque, e' praticamente lo stesso nel senso che chi attacca puo' impersonare te nel contesto della applicazione.
Dunque, perche' i siti semplicemente non usano SSL sempre?
Requisiti in CPU e memoria, latenza
A questo punto, se ti stai chiedendo perche tutte le aziende semplicemente non abilitano SSL come predefinito per tutti i loro servizi, sempre, forse la motivazione piu' comune e' che, tradizionalmente, e' risaputo che traffico HTTP criptato con SSL richiede piu' risorse (soprattutto CPU e memoria) sui server, in confronto a traffico HTTP non criptato. Mentre cio' e' vero, con l'hardware disponibile oggi questo davvero non costituisce piu' un problema significativamene di rilievo, come anche dimostrato da Google quando hanno deciso di consentire l'uso di crittografia SSL per tutte le richieste verso tutti i loro servizi (http://www.theregister.co.uk/2010/05/21/google_search_ssl_encryption/), persino per il loro popolare motore di ricerca. Ecco cio' che l'ingegnere Adam Langley di Google disse in proposito qualche mese fa:
" tutti i nostri utenti utilizzano HTTPS per rendere sicura la loro email tra i loro browser e Google, tutto il tempo. Per rendere cio' possibile noi non abbiamo avuto bisogno di utilizzare macchine aggiuntive e nessun hardware speciale. Sulle nostre macchine di produzione, SSL/TLS richiede meno dell'1% di carico sulle CPU, meno di 10KB di memoria per connessione e meno del 2% di traffico di rete. Molta gente crede che SSL richieda molta CPU e noi speriamo che i numeri di cui sopra (pubblici per la prima volta) aiutino a sfatare questo mito. "
Dunque, se SSL/TLS non richiede un quantitativo di risorse sui server significativamente piu' alto, e' praticamente come HTTP non criptato, soltanto piu' sicuro? Bene, piu' o meno. In realta', SSL introduce ancora della latenza soprattutto nella fase di handshake (http://support.microsoft.com/kb/257591) (fino a 3 o 4 volte piu' alta che senza SSL), e richiede ancora della memoria in piu'; tuttavia, una volta che l'handshake e' stato effettuato, la latenza e' ridotta un po', inoltre Google sta lavorando a metodi per migliorarla (http://www.imperialviolet.org/2010/09/05/blacklisting.html). Dunque le connessioni sono un po' piu' lente, vero, ma Google -vedi il post di Langley- ha parzialmente risolto questi problemi utilizzando parecchio il caching anche di richieste HTTPS. Google ha anche risolto il problema del piu' alto requisito in memoria modificando OpenSSL (http://en.wikipedia.org/wiki/OpenSSL) cosi' da ridurre fino al 90% la memoria allocata per ogni connessione.
Contenuti statici e CDN
A parte requisiti di CPU e memoria e maggiore latenza, vi sono altri problemi da tenere in conto quando si attiva SSL per tutto il tempo per un sito. Per esempio, molti siti (soprattutto siti grandi e popolari come Facebook e altri che sono stati presi di mira da Firesheep) utilizzano una distribuzione CDN (http://en.wikipedia.org/wiki/Content%20delivery%20network) per ridurre il carico sui propri server, ma anche per migliorare le prestazioni per i loro utenti a seconda della loro locazione geografica; le CDN sono ottime per questo scopo poiche' sono molto ottimizzate per service contenuti statici da locazioni piu' vicine agli utenti. Questo spesso riduce latenza e cosi' aiuta a migliorare le prestazioni generali del sito per quegli utenti. Nella maggioranza dei casi, utilizzare una CDN e' tanto semplice quanto il servire il contenuto statico da hostname canonici (http://en.wikipedia.org/wiki/CNAME%20record) che puntano direttamente ai server della CDN.
Ma cosa accade se un sito che fa uso di una CDN viene adattato per utilizzare SSL tutto il tempo? Prima, alcune considerazioni generali sull'uso di crittografia SSL con contenuto statico.
Per "contenuto statico", solitamente si intende immagini, stylesheet, JavaScript, file disponibili per il download e qualunque oggetto che non necessiti di processing sul lato server. Questo genere di contenuti non dovrebbe mai contenere informazioni private; pertanto, almeno in teoria, potremmo mischiare contenuto privato e criptato con SSL e servito con HTTPS, con contenuto statico non criptato, attraverso HTTP, per lo stesso sito, allo stesso tempo. In realta', a causa di come il supporto SSL e' implementato nei browser, se una pagina che usa SSL include anche immagini e altri contenuti statici che sono scaricati con normali trasferimenti HTTP, il browser mostrera' un avviso che potrebbe "spaventare" utenti che non sanno cosa SSL/HTTPS sia. Questo e' un esempio con Internet Explorer:
http://cdn.vitobotta.com/uploads/2011/02/mixed-http-https.png
A causa di cio', e' chiaro che affinche' una pagina facente uso di SSL funzioni correttamente nei browser, tutti i contenuti statici inclusi nella pagina devono anch'essi essere serviti con crittografia SSL. Ma cio' suona come uno spreco di risorse, vero? Davvero abbiamo bisogno di criptare immagini? Dunque potresti chiederti perche' i browser si comportano a quel modo mostrando quel genere di avvisi. A dire il vero, c'e' una ragione molto valida: ti ricordi dei cookies? Se una pagina e' criptata con SSL ma include anche contenuti statici che sono scaricati con trasferimenti HTTP normali e non criptati, finche' questi contenuti sono serviti da hostnames che possono accedere gli stessi cookies della pagina criptata questi quei cookies viaggeranno in chiaro attraverso HTTP assieme a quei contenuti (per le ragioni che ho gia' menzionato), rendendo di fatto la crittografia SSL della pagina stessa pressocche' inutile. Se i browser non mostrassero quel genere di avviso, sarebbe possibile evitare questo problema facendo in modo che i contenuti statici vengano serviti da hostnames che non possono accedere gli stessi cookies della pagina criptata (per esempio, con la pagina servita da dominio.com e i contenuti statici serviti da altrodominio.com, ma e' molto piu' semplice e sicuro abilitare e forzare la piena crittografia SSL per tutto quanto...
Suona strano, vero? Questo e' il web oggi... una collezione di tecnologie sviluppate per la maggior parte lungo tempo fa, quando non era possibile prevedere tutti i potenziali rischi che sono stati scoperti negli anni. E trovo divertente che nel corso degli ultimi anni abbiamo utilizzato buzzword come "web 2.0" non per riferirci ad un set di nuove tecnologie che risolvono questi problemi... ma per riferirci a nuovi modi di usare la vecchia roba (e forse neanche "nuovi"... se pensiamo ad AJAX (http://en.wikipedia.org/wiki/Ajax%20%28programming%29)) che hanno introdotto o fatto luce su piu' problemi di sicurezza che mai prima.
Tornando alle CDN....
SSL richiede un certificato (http://tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html) per ciascuno degli hostname usati per servire contenuti statici, oppure un certificato "wildcard" a patto che tutti gli hostname in uso siano semplicemente sotto domini di uno stesso nome a dominio (per esempio, static.dominio.com, immagini.dominio.com e www.dominio.com sarebbero tutti sotto domini del dominio dominio.com); se gli hostname per i contenuti statici che devono essere serviti da una CDN sono configurati come record CNAME che puntano direttamente ai server della CDN, richieste per quei contenuti statici ovviamente perverranno direttamente ai server della CDN piuttosto che ai server che ospitano il sito. Pertanto, nonostante i certificati SSL richiesti sarebbero gia' disponibili sui server del sito, quei certificati devono anche essere installati sui server della CDN affinche' la CDN possa servire contenuti statici da quegli hostname e crittografati con SSL; cosi' in teoria sarebbe necessario per il proprietario di un sito di fornire semplicemente all'azienda che opera la CDN i certificati richiesti; l'azienda della CDN poi dovra' installare quei certificati sui loro server. In realta', il supporto SSL disponibile con alcuni provider di CDN puo' essere seriamente costoso dal momento che richiede setup addizionale e infrastrutture adeguate a causa dei piu' alti requisiti di cui abbiamo gia' parlato; inoltre, la maggior parte dei servizi CDN non offre neanche questa possibilita' dal momento che tradizionalmnte sono sempre stati ottimizzati per traffico HTTP non criptato, almeno fino a questo momento.
Come puoi facilmente immaginare, i problemi con contenuto statici e CDN da soli possono gia' essere un qualcosa che potrebbe rendere la conversione di un sito come Facebook all'uso predefinito di SSL tutto il tempo, molto piu' impegnativo di quanto atteso.
Cookie "sicuri"
Dopo tutto cio' che ho gia' detto a proposito dei cookie, potresti pensare che finche' un sito usa SSL come condizione predefinita, tutto dovrebbe essere OK. Uhm... non esattamente. Se il sito usa come predefinito SSL ma ancora consente richieste ad una pagina con HTTP non criptato, sarebbe ancora possibile sottrarre cookie contenenti informazioni di autenticazione e id di sessione effettuando appunto una richiesta non criptata (http:// senza la s) verso il sito vittima.
Questo permettera' ancora una volta ai cookie di viaggiare non criptati, e pertanto essi potrebbero ancora essere usati da un malintenzionato per fare il replay della sessione di un utente vittima e impersonare la vittima nel contesto della applicazione web.
Ci sono due metodi per evitare che cio' avvenga. Il primo e' quello di attivare il flag secure dei cookie, che significa che i cookie possono essere scaricati soltanto con https://, pertanto essi saranno crittografati e il problema scompare. Il secondo consiste nel far si' che il web server che ospita l'applicazione applichi, forzandolo, SSL traducendo richieste http:// in richieste https://. Entrambi i metodi hanno praticamente lo stesso effetto riguardo ai cookie, comunque preferisco il secondo dal momento che esso aiuta anche a prevenire i problemi col contenuto misto criptato/non criptato di cui abbiamo parlato in precedenza e i connessi avvisi da parte dei browser.
Siti che usano SSL ma soltanto per l'azione di "submit" di un form di autenticazione
Ho visto SSL utilizzato in molti modi errati, ma questo e' il mio preferito. Ho accennato a come Firesheep abbia fatto luce sul fatto che la maggioranza dei siti utilizzi SSL soltanto per la pagina di login, and sul perche' questo e' un modo debole di proteggere le credenziali di accesso degli utenti. Purtroppo, vi sono anche siti che utilizzano SSL soltanto non per la pagina di login stessa, che contiene semplicemente il form di autenticazione, ma per la pagina alla quale le credenziali di accesso dell'utente vengono inviate dal form.
Ho trovato un esempio poco fa di un sito che una volta cliccato sul link di "Login", mi ha portato alla pagina http://domain.com/login.php - dunque senza SSL. Ma nel codice sorgente della pagina ho potuto vedere che la destinazione del form era invece impostata alla pagina https://domain.com/authenticate.php che invece usa SSL. Cio' potrebbe suonare come corretto, dal momento che le credenziali dell'utente verrebbero inviate al server in forma criptata con SSL. Ma c'e' un problema: poiche' la pagina di login stessa non e' criptata, chi puo' garantire che essa non venga modificata e che non invii forse le credenziali dell'utente ad un'altra pagina (una pagina su cui chi opera l'attacco ha controllo) piuttosto che la pagina authenticate.php attesa secondo quanto previsto dall'autore del sito?
Vedi adesso perche' questa non e' una buona idea?
Contenuto servito da terze parti
Le CDN sono soltanto una parte della storia quando si tratta di contenuti statici. L'altra parte della storia riguarda contenuti che potrebbero essere inclusi in una pagina ma in realta' provenire da sistemi di altri e tu non hai alcun controllo ne' sui contenuti stessi ne' sul modo in cui questi contenuti vengono serviti. Questo e' diventato un problema di crescente importanza con l'avvento di social network, aggregatori di contenuti e servizi che aggiungono nuove funzionalita' ad un sito, molto facilmente. Pensa a tutti i pulsanti per la condivisione di contenuti su social network che oggi giorno vediamo su quasi tutti i siti; e' estremamente semplice per il proprietario di un sito integrare questi pulsanti in modo da contribuire a dirigere traffico verso il sito: nella maggioranza dei casi, tutto cio' che si deve fare e' aggiungere un po' di codice JavaScript alle pagine e il gioco e' fatto.
Ma cosa accade se attivi SSL per le tue pagine, ed esse includono questo genere di contenuti esterni? Molti di questi servizi gia' supportano il protocollo HTTPS., ma non tutti, per le ragioni che abbiamo gia' visto a proposito di maggiori requisiti in risorse. Inoltre, per quelli che supportano SSL/HTTPS, tu come proprietario di un sito devi accertarti ti utilizzare il codice giusto che si occupera' automaticamente di cambiare tra HTTP e HTTPS per i contenuti esterni a seconda del protocollo utilizzato dalla tua pagina. Altrimenti, potresti aver bisogno di adattare le tue pagine per far si' che questo meccanismo venga realizzato dal tuo codice, a patto che i contenuti esterni supportino almeno SSL.
Per quanto riguarda quei servizi che rendono semlice l'aggiunta di funzionalita' al tuo sito, ho gia' menzionato Disqus, per esempio, a proposito di commenti gestiti da terze parti. Vi sono altri servizi che fanno la stessa cosa (IntenseDebate e' uno di questi), e vi sono molti altri servizi che aggiungono altri tipi di funzionalita' come per esempio la possibilita' di votare contenuti o addirittura quella di far si' che gli utenti del tuo sito possano autenticarsi con esso utilizzando le proprie credenziali Facebook, Google, ecc.
Tutte queste possibilita' rendono molto semplice oggi giorno la creazione di siti molto ricchi in funzionalita' in molto meno tempo, e rendono molt o semplice il far si' che applicazioni possano interagire tra di loro e scambiarsi dati. Tuttavia, se possiedi un sito e stai pianificando di attivare SSL per il tuo sito indefinitamente, hai bisogno di accertarti che tutti i servizi esterni utilizzati dal tuo sito supportino gia' SSL. Altrimenti, quegli avvisi da parte dei browser che abbiamo visto saranno di ritorno, e con essi alcuni potenziali problemi di sicurezza.
Problemi con certificati SSL
C'e' un paio di altri problemi, forse meno importanti, ma che vale comunque la pena di menzionare, a proposito di nomi di dominio e certificati SSL, a prescindere dal fatto che una CDN sia usata o meno. Il primo e' che, normalmente, e' possibile raggiungere un sito sia con www che senza. Cosi' per esempio sia vitobotta.com che www.vitobotta.com portano al mio sito. Al momento, poiche' i miei lettori non hanno bisogno di autenticarsi sul mio sito (perche' i commenti sono gestiti da Disqus (http://disqus.com/)) non c'e' alcuna ragione per cui io potrei volere far si' che il mio sito utilizzi SSL sempre, per ora. Ma se volessi far cio', dovrei tenere in considerazione anche che sia vitobotta.com che www.vitobotta.com portano entrambi al mio sito, nel momento in cui dovessi acquistare un certificato SSL. Il motivo e' che non tutti i certificati SSL proteggono sia i domini con www che quelli senza; persino certificati "wildcard" spesso proteggono tutti i sotto domini (incluso www) ma non la versione del dominio senza www; cio' vuol dire che se acquisti il certificato sbagliato per un sito col quale vuoi usare SSL sempre, potresti in realta' aver bisogno di acquistare un certificato separato per la versione del dominio senza www. Stavo cercando un esempio e ne ho trovato uno molto velocemente nel sito del mio provider VPS (http://en.wikipedia.org/wiki/Virtual%20private%20server) preferito Linode (https://www.linode.com/). Il sito usa un certificato wildcard che protegge tutti i sotto domini *.linode.com, ma non linode.com, quindi se provi ad aprire https://www.linode.com/ nel tuo browser vedrai un avviso simile a questo (in Firefox nell'esempio):
http://cdn.vitobotta.com/uploads/2011/02/wild-certificate-non-www-domain.png
Generalmente parlando, e' meglio acquistare un certificato che protegga sia domini www che non-www (e forse anche altri sotto domini a seconda del caso). Nel caso tu sia interessato, un esempio di certificato wildcard economico che fa questo e' il RapidSSL Wildcard certificate (https://www.rapidsslonline.com/rapidsslwildcard-certificates.aspx). Una alternativa potrebbe essere un certificato col campo subjectAltName, che ti consente ti specificare tutti gli hostname che vuoi proteggere con un singolo certificato (a patto di conoscerli tutti in anticipo).
L'altro problema con i certificati e' che spesso le aziende acquistano varie versioni dello stesso nome di dominio che differiscono soltanto per l'estensione, con lo scopo di proteggere il branding del sito. Cosi', per esempio, un'azienda potrebbe voler acquistare i domini company.com, company.info, company.net, company.org, company.mobi e cosi' via; altrimenti, se loro acquistassero soltanto per esempio company.com, altri sarebbero in grado di acquistatre gli altri domini e utilizzarli a proprio vantaggio, tecniche illegali di SEO (http://en.wikipedia.org/wiki/Search%20engine%20optimization), e altro. Buon SEO richiede che un sito utilizzi soltanto un nome di dominio, canonico, dunque e' una pratica raccomandata quella di redirezionare tutte le richieste verso i nomi di dominio alternativi al "piu' importante" che l'azienda vuole utilizzare come predefinito (per esempio company.com). Ma per quanto riguarda i certificati SSL, significa semplicemente che l'azienda dovra' spendere piu' denaro per acquistare certificati SSL.
Caching
Il caching e' una delle tecniche piu' comunemente usate da siti web per ridurre il carico sui server e migliorare le prestazioni sia sui server che sui client. Il problema col caching, nel contesto della crittografia SSL, consiste nel fatto che i browser si comportano in maniera diversa riguardo il modo in cui trattano il caching sul client di contenuti criptati con SSL. Alcuni consentono il caching di questi contenuti, altri no oppure soltanto temporaneamente in memoria ma non su disco, il che significa che la prossima volta l'utente visita gli stessi contenuti, questi contenuti dovranno essere nuovamente scaricati per intero, anche qualora essi non siano cambiati sin dall'ultima visita, pertanto impattando sulle prestazioni del sito.
E non riguarda soltanto i browser: Internet provider e aziende spesso usano proxy (http://en.wikipedia.org/wiki/Proxy%20server) server per fare caching di contenuti con lo scopo di rendere la navigazione web piu' veloce. La cosa divertente e' che molti proxy adibiti a caching, in condizioni predefinite, non effettuano il caching di contenuti criptati con SSL...
Allora... e' un web con SSL sempre attivo possibile oppure no?
E' bello vedere che Facebook adesso offre l'opzione di attivare SSL (http://www.theregister.co.uk/2011/01/26/facebook_https/). Tuttavia, cio' e' 1) deludente, in quanto e' soltanto una opzione, e la maggior parte degli utenti neanche sa cosa SSL sia; 2) sorprendente, che questo cambiamento sia arrivato non dopo tutto il rumore a causa di Firesheep, nonostante Facebook sia uno dei siti a piu' alto profilo presi di mira da Firesheep; il cambiamento, invece, giunse dopo che qualcuno era riuscito ad accedere al profilo Facebook di Mark Zuckerberg... Forse la privacy del CEO di Facebook e' piu' importante di quella degli altri utenti?
Per quanto riguarda gli altri diversi siti presi di mira da Firesheep, non ho ancora letto di altri che hanno cominciato ad usare SSL come predefinito.
Dunque, e' un processo lento.... ma penso definitivamente che sia possibile pensare ad un web interamente protetto da SSL in un futuro prossimo. Nonostante cambiare un sito perche' usi sempre SSL puo' essere tecnicamente piu' impegnativo di quanto non si possa immaginare, la realta' e' che tutte le difficolta' tecniche elencate qui sopra possono essere superate in un modo o nell'altro. Ho accennato a come Google abbia molto facilmente gia' adattato alcuni dei loro servizi affinche' essi usino SSL come predefinito. Pertanto cio' che Google ci mostra e' che altre aziende davvero non hanno alcuna scusa per non usare SSL per tutti i loro servizi, per tutto il tempo, dal momento che facendo questo potrebbero migliorare drammaticamente la sicurezza dei loro servizi (e, cosa piu' importante, la privacy dei loro utenti), se soltanto si interessassero di piu' a tutti i problemi menzionati.
L'unico reale problema che potrebbe essere un po' piu' difficile da superare a seconda della applicazione e del budget disponibile, e' di natura economica piuttosto che tecnica. E' vero che traffico criptato con SSL costa di piu' che il traffico non criptato, ma questo e' quanto. In particolare, mi riferisco al costo dei cambiamenti richiesti alla infrastruttura di un sito e della aggiuntiva gestione, piuttosto che al costo dei certificati SSL, che oggi giorno potrebbero non essere un problema persino per aziende piu' piccole.
E' improbabile che vedremo tecnologie completamente nuove e piu' sicure rimpiazzare il web come lo conosciamo oggi, nel prossimo futuro; ma e' probabile che con hardware e connessioni di reter sempre piu' veloci, prezzi di certificati SSL che vanno giu', e ulteriori miglioramenti alle tecnologie attuali, HTTPS sostituira' lo standard HTTP come il protocollo predefinito per Internet - prima o poi.
Nel frattempo, come utenti, possiamo aspettare che cio' avvenga, e pertanto esponendoci ai potenziali rischi, oppure possiamo invece risolvere almeno parzialmente il problema da parte nostra; nei prossimi post vedremo i metodi piu' semplici ed efficaci per rendere la navigazione Internet piu' sicura e privata con i piu' comuni sistemi operativi, e anche perche' ho usato il termine "parzialmente".
Dunque, come al solito, restate in ascolto!