Per un utente finale, https è pericolosamente simile al cugino http.

In realtà molto di più accade in modo nascosto e capire meglio la differenza aiuterà molto in situazioni in cui sia richiesto di usare https come trasporto sicuro.

Https o http su SSL nacque negli anni '90 come una prima applicazione di SSL per la tramissione sicura di dati. E' visto come uno degli architravi della nascita dell'e-commerce.

Il principio fondamentale su cui SSL si basa è semplice: un client e un server verificano il proprio "pedigree" e si scambiano una chiave di sessione con la quale criptare il traffico tra loro.

Il "pedigree" in questione è costituito da una serie di messaggi criptati e firmati con una coppia di chiavi pubblica/privata contenuti in un certificato.

Smitizziamo un po' il gergo dell'https e dell'SSL

Una chiave è un dato utilizzato come parametro da un algoritmo di crittazione o decrittazione per cifrare o decifrare un insieme di dati. Una chiave può essere parte di una coppia, in cui ciò che è cifrato con una delle chiavi può essere solo decifrato dall'altra, o una chiave a sé stante. Nel primo caso, una delle chiavi della coppia può essere distribuita liberamente (chiave pubblica) e solo chi possiede l'altra (chiave privata) potrà accedere all'informazione cifrata. Nel secondo caso, la chiave deve essere conosciuta da entrambe le parti della conversazione a priori perché ci possa essere una conversazione cifrata.

E' da notare come gli algoritmi di crittazione/decrittazione a chiave pubblica (per esempio RSA) siano ordini di grandezza più lenti degli algoritmi a singola chiave privata (per esempio AES o Blowfish)

Un certificato è l'unione di un'identità (per esempio un nome o l'url di un server) e una coppia di chiavi. Un certificato può essere firmato usando la chiave di un altro certificato.

Una firma digitale è definita come lo hash di un insieme di dati e il nome del principal di un certificato. Una volta che un insieme di dati ha una firma digitale, modificare i dati in qualunque modo rende lo hash diverso da quello contenuto nella firma e quindi rende evidente che i dati sono stati alterati.

A questo punto è ovvio che se uso la mia chiave privata di una coppia di chiavi contenute in un certificato a mio nome per generare lo hash di una firma digitale, questo ha due effetti:

1. Chi riceve quei dati può verificare la firma con la mia chiave pubblica e certificare che quei dati vengono veramente da me
2. Chi riceve quei dati può verificare che quei dati non sono stati modificati da nessuno e che sono esattamente gli stessi identici dati che sono stati da me inviati.

a questo punto abbiamo il primo ingrediente per stabilire una connessione sicura.

L'inghippo a questo punto diventa come fare a sapere se la chiave pubblica che ho trovato nel certificato pubblico che mi hai dato è davvero la tua.

Qui entra in gioco il concetto di Public Key Infrastructure (PKI) e di Certification Authority (CA).

Non tutti i certificati sono uguali. Alcuni certificati sono firmati da altri certificati, che sono firmati da altri certificati e così via.

Nel mondo esiste un gruppo di certificati speciali. Sono i cosiddetti Trusted Root (la migliore traduzione che mi viene in mente è le "fonti di fiducia").

Questi certificati sono stati verificati con una procedura rigorosa al di fuori delle normali trasmissioni e i loro possessori si sono impegnati a seguire procedure altrettanto rigorose per emettere e firmare certificati.

La lista di questi trusted root universali si può trovare lanciando MMC e inserendo lo snap-in dei certificati. Nell'albero a sinistra c'è un nodo "Trusted Root Certification Authorities".

Tornando ad un certificato, si chiama catena della fiducia (chain of trust) il fatto che l'atto di firmare un certificato implica certificare il legame tra il nome della risorsa e le chiavi crittografiche. Iterando questo, un certificato che è stato firmato da un root, può essere usato per firmare altri certificati, così trasferendo la verifica implicita che anche questi certificati di secondo o n-esimo livello sono verificati.

Tornando al nostro problema con SSL e HTTPS, per verificare che un client è davvero chi dice di essere e che il server è davvero chi dice di essere la conversazione che avviene è la seguente:

Client "Ciao Server. Sono Pino della Ragioneria. Questo è il mio certificato.° (nota - questo è facoltativo e succede solo se il client usa il certificato per autenticarsi. Talvolta questo si fa per avere connessioni ad alta sicurezza, per esempio quando la chiave privata è registrata su una smartcard)

Server: "Ciao Pino della Ragioneria, il tuo certificato è valido e firmato da qualcuno di cui mi fido, quindi sei davvero tu. Questo è il mio di certificato"

Client: "Server, il tuo certificato è firmato dalla chiave di un certificato di cui mi fido. usando la tua chiave pubblica ho criptato una chiave privata che vorrei usare per questa sessione°

Server: "Pino, ho ricevuto la tua chiave di sessione e ti manderò i dati criptati con essa. Mostra il famigerato lucchetto chiuso nel browser."

Capire come funziona questo handshake è la chiave per tutti i problemi che ho trovato nei forum di ASPItalia attorno a configurare https e i certificati.

In particolare, dove le cose possono andare storte è nella fase in cui il client verifica l'identità del server. Questa fase richiede che il certificato che il server usa per identificarsi si possa ricollegare ad una Trusted Root Certification Authority.

Perché ciò avvenga è necessaria una delle seguenti condizioni:

1. avete comprato un certificato SSL da una Certification Authority riconosciuta
2. avete reso la vostra CA fidata presso i client che si collegheranno

Il caso 2 diventa interessante nello scenario in cui si voglia usare https come il trasporto per un web service aziendale che si voglia aprire soltanto a clienti interni. Per fare questo si deve settare IIS con un certificato https generato dalla propria CA e si installa il certificato root della propria CA sui client tra i Trusted Root CA.

Questo ultimo passaggio eviterà che il browser segnali che il certificato usato dal server non è fidato con il famigerato messaggio di warning.

Si può andare oltre, e richiedere che i client si identifichino con un certificato rilasciato dalla stessa CA. Questo consente di integrare un'autenticazione a user-password (qualcosa che sai) con un autenticazione a token (qualcosa che hai).

E' da notare che per installare una nuova Trusted Root CA è necessario essere amministratori della macchina client (ovviamente)

Questo è il mio primo post ospitato dagli amici di ASPItalia. Grazie a Daniele, Stefano, Ricky, Ricciolo e tutti quelli che mi sto dimenticando in questa lista per la cortese ospitalità.