HTTPS: dettagli sulla autenticazione del server

Ho ricevuto una domanda sui certificati, in vista della provetta di fine corso "Reti di Calcolatori". Domanda che coinvolge alcuni dei molti (molti, molti...) aspetti e problemi che purtroppo non è stato possibile approfondire nel corso e quindi non fanno parte del programma di esame. Aspetti e problemi che comunque sono, secondo me, interessanti...pertanto ho deciso di discuterli qui.

Sono proprietaria di un sito il cui nome è stato realizzato con il non custom domain, mi faccio certificare da una Certification Authority la quale mi da una chiave pubblica, una privata e il certificato in cui associa il mio DNS name a tale chiave pubblica.

Dopo qualche tempo decido di passare alla versione di webhosting che mi consente di scegliere il nome che desidero per il mio sito.

Se faccio ciò vuol dire che dovrò tornare dalla CA per farmi dare un nuovo certificato, cambierà anche la chiave pubblica associata a questo nuovo nome? Oppure posso comunque tenere quella precedente?

La risposta è intricata.

In generale, ogni volta che un SubjectFisico desidera un nuovo certificato occorre che acquisisca una nuova coppia di chiavi. Abbiamo visto a lezione: le chiavi sono costruite e rilasciate dalla CA, non dal SubjectFisico. Quindi se la domanda è "quando un sito cambia nome può usare le stesse chiavi di prima?" allora la risposta è "no".

Cosa accade con i non custom domain dipende dalla forma del nome.

In Google Sites con non custom domain il nome è lo stesso per tutti i siti del mondo:

sites.google.com/.....

Nella vecchia versione di Google Sites era disponibile solo http, in quella nuova è disponibile solo https. Se andate su un sito Google Sites nuova versione, trovate quindi lo stesso certificato per tutti i siti (non ho nessuno sottomano da indicarvi: il mio sito personale è su Google Sites nuova versione ma ha un custom domain; il sito del Machine Learning Lab è su Google Sites vecchia versione).

La gestione più comune dei non custom domain, comunque, è quella della forma usata, ad esempio, da Blogger, cioè da questo sito che state leggendo:

https://bartoli-alberto.blogspot.com/

La parte in blu è diversa per ogni sito ospitato da Blogger. E' un non custom domain perché la struttura è la stessa per tutti i siti ospitati da Blogger.

A questo punto la cosa si complica. Il sito è https ma io non sono andato da nessuna CA e non ho nessuna coppia chiave pubblica-chiave privata.

Quindi Blogger crea automaticamente una coppia di chiavi diversa per ogni sito che ospita? No. Blogger usa la stessa coppia di chiavi per tutti i siti che ospita.

Allora su Blogger ci sono tanti certificati diversi (uno per ogni sito ospitato) che hanno Subject diverso e stessa chiave pubblica? No. C'è un solo certificato valido per tutti i siti: il Subject di quel certificato ha una forma particolare:

*.blogspot.com.

dove '*' viene interpretato dal browser come "qualsiasi sequenza di caratteri" (ok, non chiediamoci "e se io volessi usare come nome proprio *?"). Pertanto, quando il browser riceve il certificato e verifica che il Subject contenga lo stesso DNS name che trova nell'URL, la verifica ha successo. Quindi quel certificato, e la corrispondente singola coppia di chiavi che è stata messa una volta per tutte sul web server di Blogger, vale per tutti i siti ospitati su Blogger.

Bello e semplice....solo che la cosa si complica ulteriormente.

Andando a vedere il certificato inviato dal web server , si scopre che il Subject non ha nulla a che vedere con blogspot.com:

E allora? I certificati ed il procedimento di verifica prevedono la presenza di un ulteriore campo che si chiama SubjectAltName ed il cui valore contiene altri nomi che possono essere associati a quel certificato (cioè nomi DNS che possono essere usati dai server che presentano quel certificato). In quel certificato si trovano molti nomi tra i quali, appunto, "*.blogspot.com".

Piccole riflessioni finali.

• Spero siate ancora più convinti del fatto che tra lo strumento "crittografia" e le sue applicazioni reali c'è una distanza enorme: "Whenever anyone says that a problem is easily solved by cryptography, it shows that he doesn’t understand it".
• Alla fine del corso, il significato del post "Come organizzo lo studio di Internet" acquista forse un nuovo significato.

Esperienza con la PEC: com'è andata a finire

Nel post precedente avevo descritto una "Esperienza (poco consolante) con la PEC". Concludevo in questo modo:

Vedo due possibili spiegazioni per questa vicenda:

1. Non è un tentativo di attacco. Al contrario di quanto mi è stato detto dall'assistenza, il rinnovo del mio abbonamento PEC ha provocato l'invio automatico di un allegato PDF (magari a causa dell'adeguamento di Aruba alla GDPR) e questo invio è stato catalogato erroneamente come mia richiesta di assistenza.
2. E' un tentativo di attacco.

Non ho elementi sufficienti per affermare con ragionevole certezza se siamo nel caso 1 o nel caso 2.

Posso però affermare con certezza che se siamo nel caso 1 allora l'assistenza clienti ed il processo di gestione di queste tematiche da parte di Aruba lascia molto a desiderare (eufemismo).

Successivamente alla pubblicazione del mio post ci sono state varie interazioni che hanno chiarito la vicenda.

In breve: eravamo nel caso 1: il mail sospetto non era un attacco. L'assistenza clienti si era sbagliata ripetutamente: era un email inviatomi veramente da Aruba (per un motivo che non c'entrava nulla con la PEC). Il chiarimento telefonico avvenuto il giorno successivo al mio post ha chiarito tutto, sottolineando che la loro assistenza clienti non aveva gestito la pratica in modo appropriato. Hanno anche suggerito, in maniera molto pacata ed educata, che io avrei potuto accorgermi della legittimità del messaggio email. Su questo non sono d'accordo (chi vuole legga più sotto), ma sono rimasto completamente soddisfatto dalla cortesia e dalla chiarezza della persona che mi ha contattato.

Ciò premesso, segue la descrizione dettagliata di cosa è accaduto per chi è interessato.

Il giorno 12 Novembre, dopo avere rinnovato la PEC con Aruba, ricevo un credito da spendere sul sito "pratiche.it". Ad un'occhiata superficiale mi è sembrato interessante quindi mi sono iscritto ed ho inserito i miei dati personali. Dopo un'occhiata più approfondita mi sono reso conto che il servizio non faceva per me. Invece di dimenticarmi semplicemente del sito, ho deciso di cancellare il mio account. Lasciare i miei dati personali in un sito che serve per chiedere certificati, visure etc ha senso se ho intenzione di usarlo; se non ho intenzione di usarlo è una cosa da non fare. Ho quindi deciso di cancellare il mio account seguendo le istruzioni indicate: cioè inviando un email a "info@pratiche.it".

Questi mi hanno risposto dicendo "deve inviare una mail a questi indirizzi: privacy@staff.aruba.it e dpo@staff.aruba.it". Al che mi sono un pò irritato ed ho risposto in questo modo:

C'è stato un breve ping-pong via email ("so che non dipende da lei, ma allora scrivete sul sito "inviate due email agli indirizzi X e Y", non "inviate un email all'indirizzo Z"".) ma mi sono arreso rapidamente perché non ci capivamo. Ho quindi inviato gli email richiesti:

Questo il 12 Novembre. Il mail sospetto è arrivato il 20 Novembre.

Ovviamente tra il 12 e il 20 ho fatto molte cose e "pratiche.it" (nota bene: pratiche.it, non Aruba) non era in cima ai miei pensieri. Ormai lo avevo rimosso dalla testa, per ovvi motivi. In quell'intervallo di tempo ho ricevuto circa 180 (centoottanta) email. Ovviamente non posso ricordare gli indirizzi email di tutti quelli che mi scrivono. Quando invio un email da cui attendo risposta ho un meccanismo per controllare periodicamente se la risposta è arrivata. Nel caso di pratiche.it non avevo attivato questo meccanismo. Non mi è sembrato indispensabile, lo ammetto. E, lo ammetto, non ricordavo che mi sarebbe dovuta arrivare una risposta da due indirizzi email di Aruba.

A questo punto il 19 Novembre c'è una intrusione massiva nella PEC di un provider non specificato (che comunque pare non essere il mio).

Il 20 Novembre ricevo un email dal mio provider PEC in cui, senza fare minimamente cenno a pratiche.it, mi viene detto "per verificare la sua richiesta relativa ad Informazioni commerciali su: Reclami / altro...deve riempire il file PDF in allegato". Non essendo dotato di capacità telepatiche (e non immaginando minimamente quanto fosse difficile togliere da pratiche.it dati che sono così semplici da inserire; per inserirli non mi hanno fatto riempire nessun modulo PDF) mi sono insospettito e mi sono comportato come ho descritto nel post precedente.

Alla fine tutto si è tradotto principalmente in una perdita di tempo.