AVVISO IMPORTANTE: Dato l'elevato numero di richieste, Eternal Curiosity non può accettare nuovi clienti, sia che si tratti di consulenze scritte che di ottimizzazione SEO diretta. Valutiamo solo casi eccezionali e ad alto budget. Per informazioni, vi invitiamo a scriverci a [email protected]

Questo articolo apparteneva al vecchio blog (blog.danilopetrozzi.it), per cui le informazioni potrebbero non essere più aggiornate ed attendibili.

Google rende l’HTTPS un fattore di ranking: ma che roba è?

Se hai capito la battuta nell’immagine in alto, condividi 😛

Il 7 agosto 2014, mentre scrollavo lo stream del mio Google+ mi accorgo che quel pacioccone di John Mueller pubblica questo:

 

Con un (anomalo) post ufficiale, Google annuncia al mondo intero che l’uso della tecnologia HTTPS è un fattore di ranking positivo.

La prima cosa che noto è che Google probabilmente subappalta il copywriting nel quarto mondo, altrimenti non si spiega perché nei post riciclano sempre le stesse introduzioni:

Messaggio riguardo l’HTTPS:  “Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default […]

Annuncio del Project Zero:  “Security is a top priority for Google. We’ve invested a lot in making our products secure, including strong SSL encryption by default for Search, […]

 

Ok, bene. Figo! Ma.. che diavolo è l’https? Come funziona?

Funzionamento dell’HTTPS spiegato a un bambino

Senza entrare nei dettagli tecnici di HTTPS/SSL (https = HTTP OVER SSL), proverò a spiegarne il funzionamento con termini comuni e concetti semplici.

Perché l’HTTPS? L’HTTP non bastava?

L’uso del protocollo HTTPS si è reso necessario per raggiungere due obiettivi distinti:

Criptazione: necessità di criptare i dati che vengono scambiati dal browser con un server, per evitare che una terza persona con cattive intenzioni possa leggere o manipolare il contenuto della comunicazione

Identificazione: necessità di accertare che il sito al quale mi connetto è effettivamente l’originale

Se io (Danilo) voglio comunicare in modo confidenziale con un secondo soggetto (chiamiamolo Alice) dovrò come prima cosa comporre il messaggio, proteggerlo con una password (criptazione) e poi dovrò spedirlo a Alice, che sarà in gado di decriptarlo con la stessa password. Durante questo processo, devo accertarmi che il mio messaggio è effettivamente ricevuto da Alice (identificazione) e non da un sosia di Alice, o da altri soggetti che si spacciano per lei.

L’HTTPS fa la stessa cosa che io ho fatto con Alice, ma lo scambio di informazioni avviene tra il tuo browser e il sito che stai visitando. Il tuo browser, infatti, grazie all’HTTPS cripta le informazioni che invia al sito e al tempo stesso si accerta che l’Amazon.it che stai visitando è effettivamente l’originale, e non una copia che potrebbe rubare i tuoi dati personali. (anche il sito, quando invia dei dati verso di te, cripta i dati, che poi possono essere decriptati solo dal tuo browser)

Come fa la tecnologia HTTPS a fare tutto questo?

La prima cosa che devi sapere, se già non ne eri a conoscenza, è che in crittografia ci sono due modi con cui un testo (plaintext) può essere criptato / decriptato: esistono algoritmi di crittazione simmetrica e asimmetrica.

La crittazione simmetrica è quella che sicuramente conosci: per proteggere un testo, lo cripti con la password K e lo invii al destinatario. Il destinatario riceve il messaggio e lo decripta con la stessa chiave K al fine di ottenere il testo in chiaro. Facile no?

Crittografia simmetrica

Si chiama crittazione simmetrica perché c’è simmetria tra la password usata per criptare e quella usata per decriptare un messaggio. (sarebbe meglio parlare di chiave al posto di password, ma fa lo stesso).

Approfondimento: Se ti interessano, gli algoritmi di crittazione simmetrica più famosi sono il DES (non più usato, è l’algoritmo storico per eccellenza), il 3DES (che sostituisce il DES) e AES, che è attualmente l’algoritmo simmetrico più usato al mondo. (di notevole importanza sono anche i finalisti del concorso AES, ad esempio Serpent e Twofish) Dubbi sulla sicurezza di AES? Ti basta sapere che Obama comunica con le ambasciate americane sparse nel mondo grazie a AES256? 🙂

Crittografia asimmetrica

Parliamo di crittazione asimmetrica quando la password utilizzata per criptare è DIVERSA da quella usata per decriptare. Questo è possibile perché esistono funzioni matematiche in grado di generare due chiavi differenti che possono criptare/decriptare un messaggio in modo alternativo. La crittazione asimmetrica è spesso chiamata crittazione a chiave pubblica. Scopriamo perché:

Grazie a un particolare meccanismo, io (Danilo) posso generare due password diverse A e B con le quali posso criptare i messaggi. Se cripto un messaggio con la chiave B, quel messaggio potrà essere decriptato solo e unicamente con la chiave A.

Criptando con la seconda chiave, il risultato è decriptabile sono con la prima e viceversa: capito il concetto?

Data questa proprietà molto interessante, io posso liberamente pubblicare la chiave B su internet, dato che qualsiasi cosa venga criptato con essa, è decriptabile solo da me (dato che segretamente io conosco A). Si chiama algoritmo a chiave pubblica, proprio perché una delle due chiavi può essere pubblicata senza alcun timore, dato che è l’altra chiave quella che decripta.

Approfondimento: I protocolli più famosi che sfruttano la crittazione asimmetrica sono lo scambio Diffie-Hellman e l’RSA Il programma più famoso che sfrutta l’asimmetria è PGP, che poi si è trasformato in varie versioni commerciali e open source. Hai dei dubbi sulla sicurezza del metodo a chiave pubblica? Beh, sappi che Edward Snowden, la talpa della NSA americana che ha dato origine al datagate, usava proprio PGP per scambiare email segrete con i giornalisti a cui spifferava le notizie!

Grazie al meccanismo della chiave publica io (Danilo) posso pubblicare sul web la mia chiave B e posso dire: chiunque voglia comunicare segretamente con me, deve criptare i messaggi con la chiave B e poi spedirmeli, così solo io sarò in grado di decriptarli (dato che ho la chiave A, che custodisco segretamente!).

Ora che hai capito la differenza tra i due sistemi. sappi che entrambi hanno vantaggi e svantaggi. A patto di utilizzare algoritmi moderni, entrambi i metodi sono super sicuri ma ci sono differenze di approccio da non sottovalutare: nel caso della crittazione simmetrica è ovvio che Danilo e Alice devono conoscere entrambi la stessa password, e quindi prima di poter parlare segretamente devono per forza di cose scambiarsi la password. Con il metodo a crittazione asimmetrica, Alice non deve conoscere la chiave A, dato che deve solo criptare con la mia B. Se io volessi rispondere a Alice userei LA SUA CHIAVE B (dato che lei ha una SUA CHIAVE A PRIVATA, che tiene nascosta).

Ripeto il concetto, perché è facile perdersi: se Alice vuole parlare con me, cripta il messaggio con la MIA chiave B, così solo io potrò decriptare grazie alla MIA chiave A. Viceversa se io devo scrivere a Alice, cripterò il messaggio con la SUA chiave B, e lei potrà leggere le mie letterine d’amore grazie alla SUA chiave A. Gotcha?

HTTPS usa entrambi gli algoritmi in modo intelligente

Ora che conosci il funzionamento dei due tipi di algoritmi, posso spiegarti in termini ultra-semplici, come funziona HTTPS. Supponiamo che io voglia collegarmi a Google.it . Che cosa accade?

Google.it, dato che usa la tecnologia HTTPS, dispone di una coppia di chiavi A e B con le quali può criptare / decriptare (suona familiare? E’ la crittazione asimmetrica di cui abbiamo parlato prima). La chiave B di Google.it è pubblica mentre ovviamente la chiave A è segreta.

Nota: noi parliamo di chiave A e chiave B come fossero delle semplici paroline. Quello che accade, in realtà, è che queste chiave sono molto complesse. Nella maggiorparte dei casi, lo standard di lunghezza della chiave privata (A) è di 2048 bit, che è decisamente lunga.

Questo è un esempio di chiave A:

1LAd6YQpCbsRx5ZU3iELHaR9zXg6JcbdCKmI6ucmhrXjFr96RSCkU31xzJQJVNpIqTYi8TkfLSBHSS4EaNYBPmGvyeziiK9O3r1LI712qUiBxwy1SHBql88AQjQFKmg3BChKlH3s74huLmlr4F5EyIA2UWpicOSBLVrf8KBcyhihPsejeDPdMTq557jgTU2Ec65wIMksHa2U7fP4iKX2ciYZ48VLagPfAXpYYHKPQAmBcKl9CsHbgluGWabxghLkLWOp2qxsUx7tUZpyEIuZPHSdy936sXxOdutaGRLPgjyETutiYpNNsGClTkKCqb16fSlDpFuxc34qPMmaul3jBhMwwaVScct739SbePt92B6y53eeEGIIipTkILE31mec78xHcBaWsKpMlqXvlUU7MHreIQaKaePjplPIgibwdM6kyLrkBWekr2H911uzK7j3A1iWSTDHmReYM11hMHs3zBczt161EjQuNlp3kDAsi9MtWKzkCPfWxlB2Im67tFnt2Apeq74T6iOPSBid6bGTyIwSIgeTPOgqDXvLMBvpKtlsT3RMKCtF1L3YLaZj4Fc1JDRAirbdmfyPfmgvIZCH1amPX79lZArMhfIY5xZZf1tuxhnJa6LC32S5yGcO4teGJW7VM8ghJBWjfilHSSxVe5iBK2GcfQBmLThrzd2wCmW58NZqp6pg5VvBRIQXDuXqHCD8pU6QbstTvYIOmRKyLb8TlPBd2C2mS2B7XmjqAqB2NvsqCdlQYjDX945ROun2UrdkJTpEpzgw9NYLPGfQRHzGpv5aYia6WPyjGTgYsXhh27LsWl99wUW6AOMUVSCnSygRkIGEkcG6gfzrxyDD8WiIP4EecxYNHk5QSfPU8skK1izFwtAM13QDPeHaYxNzmg2G6RV37l6NNWcLAPMqMEEEvkXK4bfHRRINXShq7h3far2pMqAZnyh5HtF37SiU1zmsdrhZKySgsjf5QtKh1hA7552MSdZVYgNgsGDm9xZglCXExMp8WeZG2IKPZUExYIpbMdvyCjLkQkQ2vgEsfwu7BOUR2XKGcRqHRAyyYDsSx3fOtTENIcF4ncJTAdKKBFcirDui8wzBgPYiVB4NZ4IslQE48cFHIS43NZADdcNG4N2JQPKHFFK1TRVCmy9P9mvY6hAHBXznq5JPJg5alXVx2RnemLxDhCFbP9B4Ye5WiM3eCLz2B6EjM2QZQtiqeRhKUtzkf5AYiDgLVjwFFcaaLnBXq6I6d3rE1HmNFFlyaS2BNGZ3quMM9xeJiJXksfESmwEusF7lVIYZOlLWeB8fcWzmutjXCSpuaba2OxcuHHtPrsgsIWniXGpDsGBhAFwQrNzkWlTj4kRQdUbJW9mJYJiLsAQppaOTlSxCt6hzffSSBH9NkLeY3z1rMWfw4cWRQ546Mpsc6jxtk1leb8Q821Y87k3xwuamKjs56Nbyg1QB6ZUaBxw4Cv1ltCiScx3UAhGYWRxNX8SZ5wSlPMcv9tnmdNt4NKjiUHgHxx7XfUQ9nSzFEcImOYXgZt9hHdgJXa15r7bkvTtb44mHSjJeYPKcEDin3My5pUI4BirufWpdUCeHf4wewPG6yQd4mdc3vfdU9YUUUGEf2OleABFpbJf5KVEqLBJIhQkHAaIOnlSyBYEj9t8NLrUK2WUKWJ3RyL991wPHQiXiubvEbSVpt8Wem7PVRjJUbz3w7L9xl12Rvx9WID9jzXr9WTKHcayP9HXbxjOzawMpCwMzqZUOrNgwRN67JCRuMJz2teLwgIFTfVjHsLEV9xMyN4eGBCHMmR9lWPzGDmP4SRnITEdZCzTRj3Cmv9tL1e7dDXcx6UdaPe6HZ4Pz78LrFKKu4N1RErgExLuixAHOOjRevbbGntGGeSBx6FeRfstEpuB1OEUFRd5vxBkiKHbg5hSsgIYYfj1aiHpjjsAs64GtGqDU5j1PNBCAqC8JIsBn8FbYaAlmOxu54hcrT4gwq7KIIdvMGTfUlp61Y69elbpuMKfq1ltMnZVp8gtRf1rRN7lQc3U29qtUzMiuSUB8ONOe

Non è il solito qwerty, direi!

Quando io tento di connettermi a Google.it, il mio browser preleva la chiave B del sito (che è pubblica, ricordiamolo) e con questa chiave cripta una nuova password inedita (casuale). Il mio browser, infatti, genera una password (master-key) di 128bit ( è la lunghezza più usata ) e la cripta con la chiave B di Google.it. Dopo aver fatto questo, invia il messaggio criptato al server di Google.it.

Dato che Google.it ha la chiave A, può decriptare il messaggio e entrare in possesso della master-key che il mio browser ha generato.

Adesso io e Google.it siamo a conoscenza di una password inedita che possiamo utilizzare per comunicare grazie a un algoritmo simmetrico.

La scelta di quale algoritmo simmetrico usare è libera, ad esempio Google.it usa AES128.

L’identificazione e lo scambio iniziale di chiavi tra i due soggetti (browser e server) si chiama tecnicamente handshake (stretta di mano).

Una volta che io e google conosciamo la stessa password K (che oltretutto è una password casuale, che quindi useremo solo durante la sessione e non verrà più usata ne custodita da qualche parte) possiamo comunicare in tutta libertà senza che nessuno possa leggere/interpretare/manipolare i nostri dati.

Questo, in sostanza, è il core del funzionamento di HTTPS/SSL!

Bello. Ma.. perché si paga l’HTTPS?

Se Google.it deve solo occuparsi di generare la coppia di chiavi A/B, e il mio browser deve solo generare la master-key che va comunicata a Google.it, perché l’HTTPS si paga?

Intanto c’è da precisare una cosa: l’HTTPS non si paga, nemmeno l’SSL ne altre sigle che hai sentito finora. Quello che si paga è un’altra cosa: sono le Certificate Authorities.

Per capire cosa sono, facciamo un passo indietro: ti ho detto all’inizio del post che l’intento di HTTPS, oltre alla criptazione era quello di soddisfare anche il criterio dell’identificazione.

Finora siamo riusciti a criptare un messaggio e a mandarlo a Google.it, ma come faccio io a sapere che il sito al quale mi sto collegando è effettivamente l’originale Google.it e non una copia creata per rubarmi la password di Gmail? Bhe, è abbastanza semplice: facciamo in modo che ci siano delle società esterne che certificano l’identità. 

In parole povere, funziona così: io (Google.it) mi reco da una CA (Certificate Authority)  e acquisto un certificato SSL. Questo certificato attesta che la mia chiave B (quella pubblica, di cui abbiamo parlato per l’intero post) è effettivamente associata al dominio Google.it

Quando il tuo browser, poi, vorrà collegarsi a Google.it, la prima cosa che farà è controllare il certificato: se l’autorità mi conferma che il certificato è originale e che appartiene a Google.it, allora significa che la chiave B è quella giusta, e quindi posso procedere a usarla per criptare la master-key. Chiaro?

Certificate Authorities

Le società che si occupano di vendere questi certificati sono tantissime e i prezzi variano da pochi euro all’anno fino anche a 2000 € / anno. Le differenze sono numerose (sicurezza della criptazione, lunghezza massima delle chiavi utilizzabili, presenza della barra verde in alto a sinistra del browser e così via). La principale caratteristica di un CA deve essere l’autorevolezza: se la CA è autorevole, io posso fidarmi dei suoi controlli sull’originalità dei certificati.

La più grande società in questo settore è Verisign di Symantec.

Ricapitoliamo: connessione HTTPS passo passo

Ricapitoliamo a grandi linee, e senza scendere nei vari dettagli, una connessione HTTPS:

1) Digito Google.it nella barra del mio browser

2) Io e Google.it ci scambiamo i certificati così io posso entrare in possesso della sua chiave pubblica B

3) Il mio browser genera una master key e la cripta con la chiave pubblica B di Google.it

4) Invio la master-key criptata a Google.it

5) Verifico che il certificato sia integro e che corrisponda effettivamente a Google.it

6) Se è tutto ok, procedo con la sessione

7) Google.it decripta la master-key grazie alla sua chiave A e ora è in possesso della mia stessa master-key: quindi possiamo comunicare liberamente

Perché L’HTTPS è diventato un fattore di ranking

Google è una società che è costantemete sotto la lente di ingrandimento quando si parla di privacy. La notizia di pochi giorni fa è che grazie alla scansione di messaggi in Gmail, Google ha smascherato un pedofilo e ha contribuito al suo arresto. La notizia genera opinioni contrastanti: da un lato è ovviamente un bene che ci sia un pedofilo in meno in giro, ma dall’altro è ovvio che nessuno vorrebbe che le proprie email siano lette da qualcuno, anche se non ci sono reati di mezzo.

Se parliamo strettamente di sicurezza informatica, però, Google ha dimostrato di avere “carattere” nello sfidare hacker e agenzie segrete di tutto il mondo. Con il Project Zero, ha annunciato di voler creare un team di hacker professionisti in grado di rilevare e correggere falle di sicurezza nei software commerciali. A parte l’ovvio scopo di marketing , questa è un’iniziativa da non sottovalutare in ambito informatico.

Il problema è che ogni volta che esce una notizia positiva di questo tipo, ne esce una uguale e contraria come quando sono trapelate indiscrezioni riguardo misteriosi meeting tra NSA, Google e altri CEO della Silicon Valley.

Il fatto che l’HTTPS venga favorito rispetto all’HTTP è un fattore positivo a prescindere. Anche se non fosse stato un fattore di ranking, sarebbe stato comunque un fattore di sicurezza per il proprio sito web, quindi Google non aggunge ne toglie nulla allo status quo.

Pubblicizzare l’HTTPS su larga scala con un post dedicato, è anch’essa un’operazione positiva: ha permesso a molte persone che non lo conoscevano di informarsi e documentarsi a riguardo. Tralaltro, a quanto pare, l’incisività di questo fattore di ranking è molto bassa per cui può essere largamente trascurato in ambito SEO.

La mia opinione finale sull’argomento è questa:

L’utilizzo di HTTPS al posto di HTTP deve essere scelto in base a esigenze di sicurezza/privacy e non per motivi legati all’ottimizzazione per i motori di ricerca.

Con questo concetto in testa, l’HTTPS mantiene il suo scopo primario, e si evita di spendere centinaia di euro inutili sui certificati sperando in magici “ranking boost” che non si verificheranno mai.

Danilo petrozzi

Ciao! Io sono Danilo Petrozzi, il fondatore di Eternal Curiosity. Oltre a essere un senior SEO Specialist e un Web Developer, è dall'età di 9 anni che mi appassiono a qualsiasi cosa ruoti intorno al web e all'informatica in generale.

Lascia un commento