Il web fin dal giorno della sua nascita è risultato carente di qualcosa che oggi in molti cercano e pretendono dai servizi che vengono offerti nella rete: la sicurezza dei dati trasmessi. Non si sa se sia una leggenda metropolitana alimentata da un’autorevole testata giornalistica, o se sia la verità, ma internet è l’evoluzione di ARPANET, una rete creata dal dipartimento delle difesa degli Stati Uniti, il cui scopo era interconnettere computer sparsi sul territorio e permettere che continuasse a farlo anche a fronte di un attacco nucleare. Al tempo quindi non si pensava tanto che il pacchetto sulla rete viaggiasse cifrato, ma più che altro che arrivasse sempre e comunque a destinazione. D’altro canto anche i protocolli di comunicazione internet, la suite TCP/IP, erano nati principalmente per lo scambio di dati tra ricercatori nella comunità scientifica e non erano richieste forme si sicurezza nella loro implementazione.
Oggi le cose sono cambiate e il web “in chiaro” è spesso inaccettabile.
La lettura della propria mail, lo scambio di dati personali, le transazioni bancarie e con carta di credito, sono solo alcuni esempi di servizi con informazioni riservate che “viaggiano” nel web e che hanno contribuito a rendere più sempice la vita di tutti i giorni. Purtroppo però è anche diventato altrettanto semplice per un malintenzionato riuscire a carpire dati che dovrebbero invece restare privati.
Quando internet è diventata di dominio pubblico, il problema della sicurezza si è fatto sentire quasi subito. Una tecnica molto nota per carpire informazioni dal traffico generato tra due punti su internet è quella detta “man in the middle“, in sostanza qualcuno ascolta il traffico in chiaro sulla connessione e può leggere senza sforzo informazioni che dovrebbero invece essere riservate. Per questo motivo sono rapidamente nate forme per la cifratura dell’informazione contenuta nei pacchetti trasportati dal protocollo TCP/IP. L’SSL è stato il primo, ma col tempo e col potenziamento dei computer, si è scoperto che il suo grado di sicurezza non era sufficiente. Nascono diverse evoluzioni prima l’SSL V2 e l’anno successivo l’SSL V3 rialsciati da Netscape, ma col tempo entrambi si sono verificati inaffidabili. Viene quindi alla luce il TLS, tutt’ora utilizzato, che diventa il nuovo standard per la cifratura delle comunicazioni di rete basate su TCP/IP.
Oggi un sito web che raccoglie informazioni sensibili DEVE essere dotato di sistemi di comunicazione cifrata e questo è fattibile grazie all’installazione nel proprio server web di quello che viene comunemente chiamato “certificato SSL“.
Il certificato digitale SSL
Come dice il nome, il certificato digtale SSL non è altro che un file digitale che dobbiamo posizionare da qualche parte nel nostro server web e che ci da la possibilità di essere certificati, e quindi attendibili, di fronte ai visitatori del nostro sito web. Il certificato però non fa solo questo, si occupa soprattutto di cifrare la comunicazione che avviene tra il nostro sito internet e il browser dell’utente che ci sta visitando vanificando gli attacchi di tipo “man in the middle“.
Il certificato SSL cifra lo scambio dati e ci rende attendibili.
Nel mondo esistono alcuni enti certificatori chiamati “certification authority” o CA che sono riconosciuti come essere “affidabili de facto” e che sono già noti anche ai nostri browser. In essi infatti è già preinstallata la “chiave pubblica” delle varie CA, necessaria a verificare la firma del certificato digitale che il nostro sito invia al browser e che serve sia per farci riconoscere come attendibili (se il browser riesce a verificare la firma della CA), sia per cifrare tutti i successivi scambi di dati.
Se il browser non riesce a verificare il certificato come attendibile (in sostanza non riconosce la firma come appartenente a nessuna delle CA a lui note) ci avvisa con un messaggio di pericolo (a volte anche un po’ troppo terroristico) la cui sostanza recita più o meno così: “Il certificato che questo sito mi ha mandato non è stato firmato da nessuna delle CA che io riconosco come attendibili. Puoi allontanarti dal sito oppure accettare il certificato e proseguire a tuo rischio la navigazione“. Se stiamo facendo esperimenti con un server e abbiamo autogenerato un certificato per il nostro sito possiamo naturalmente ritenerlo affidabile, accettare il certificato e continuare la navigazione sul sito stesso e lo scambio dati avverrà pure in forma cifrata. Si tratta in sostanza di un caso nel quale sappiamo da dove viene il certificato e che quindi non ci fa correre rischi, ma naturalmente è una situazione che non può essere accettata in un ambiente di produzione. In tutti gli altri casi invece dobbiamo sospettare la presenza di un attacco “man in the middle” e quindi allontanarci da quel sito perché nessuno ci sta davvero garantendo che quel sito sia davvero chi dice di essere. Solo le CA possono farlo e anzi, possono pure garantire che un certo sito web appartenga ad una specifica azienda.
I vari tipi di certificato SSL
I certificati SSL vanno acquistati ed hanno una durata limitata nel tempo, dopodiché vanno rinnovati e rimangono validi fino a che continuiamo a farlo. Per comprarli ci dobbiamo rivolgere ad una qualsiasi delle CA sul web, oppure, se abbiamo un dominio in hosting, al nostro fornitore del servizio. Normalmente questo secondo caso è piuttosto semplice, tipicamente si tratta di fare richiesta del certificato per il nostro sito cliccando un pulsante nel pannello di gestione dell’hosting, pagare la cifra richiesta e come per magia ci troviamo tutto attivato nel giro di qualche ora. Se invece abbiamo un nostro server dobbiamo fare da soli e contattare una CA.
Esistono sostanzialmente 3 macro distinzioni tra i certificati SSL:
Certificati autofirmati o firmati dalla CA
I certificati autofirmati li abbiamo visti nell’esempio di prima, si tratta di certificati che facciamo generare dal nostro server, ci permettono di cifrare i traffico, ma non essendo firmati da una CA fanno uscire l’avviso di “sito non attendibile” sui browser. È chiaro che questo tipo di certificato essendo gratuito è perfetto per fare test, ma non va certamente bene per un ambiente di produzione.
Certificati single domain o wildcard
Normalmente per ogni sito web è necessario un certificato: ne serve uno per www.esempio.it, un altro per shop.esempio.it un altro ancora per docs.esempio.it anche se tutti questi siti condividono lo stesso dominio esempio.it. Questo certificato si chiama single domain o SD e normalmente ha anche un costo più contenuto. Quando invece voglio la libertà di certificare quanti sotto domini voglio, quindi con un solo certificato coprire tutti i siti del tipo <qualunque_cosa>.esempio.it dovrò acquistare un certificato wildcard.
In entrambi questi casi la CA emette il certificato eseguendo una verifica in forma breve e spesso automatica che consiste nel controllare il nome a dominio, i dati del proprietario e a volte una casella di posta. Il costo di questi certificati varia a seconda del tipo, se SD oppure wildcard, ma anche dalla copertura assicurativa e dal risarcimento che viene dato nel caso in cui il certificato venga manomesso e la CA non riesca a garantire la sicurezza attesa.
Certificati extended validated
Si tratta della massima validazione applicabile al certificato che prende il nome di extended validated o EV, ma è noto anche come domain validated o DV oppure come organization validated o OD . In sostanza non si convalida solo che il dominio esista, ma la CA raccoglie anche informazioni sull’azienda che lo richiede e sul suo titolare. Dati e firme sono necessarie alla CA per l’emissione del certificato e quindi la procedura non può essere automatizzata. Naturalmente per avere il massimo della validazione i costi di questo certificato saranno proporzionali.