venerdì 14 dicembre 2018

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.

giovedì 6 dicembre 2018

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.


lunedì 3 dicembre 2018

Esperienza (poco consolante) con la PEC

Il 20 Novembre ricevo un email da Aruba, il provider della mia PEC personale.

Caso da manuale di email da trattare con attenzione, perché:
  1. Non avevo inviato nessuna richiesta ad Aruba.
  2. Mi invitava ad aprire un allegato PDF.
Ovviamente mi sono comportato come dico sempre di fare nei corsi di sensibilizzazione sulla sicurezza informatica: non ho scaricato l'allegato e mi sono collegato alla mia area personale Aruba (senza seguire nessun link nell'email). Se il messaggio fosse stato autentico, infatti, nella mia area personale ci sarebbe stata una copia della richiesta.

Come mi aspettavo, nella mia area personale non c'era nessuna richiesta da parte mia. 

Visto che neanche 24 ore prima era stata resa pubblica una intrusione molto grave in un provider PEC, invece di archiviare l'email e segnalarlo come spam ho speso qualche minuto per approfondire. Ho analizzato gli header del messaggio email per verificare il cammino seguito dal messaggio (informazioni normalmente non visibili): da una analisi superficiale il messaggio email sembrava inviato effettivamente da Aruba. Il che ha fatto diventare la faccenda molto interessante (o molto preoccupante, dipende dai punti di vista). Abbiamo infatti un messaggio email che:
  • Invita ad aprire un allegato PDF per risolvere un problema inesistente.
  • Ha aspetto identico a quelli inviati da Aruba.
  • Non viene rilevato come spam da Gmail.
  • Appare inviato da Aruba.
Il tutto neanche 24 ore dopo che è stata resa pubblica una intrusione gravissima in un provider PEC. Ci sono elementi più che sufficienti per temere un tentativo di attacco.

L'unico dubbio che mi rimaneva era che pochi giorni prima avevo rinnovato l'abbonamento annuale per la mia casella PEC. Il messaggio avrebbe potuto forse essere stato inviato automaticamente dalla procedura di rinnovo e, per un qualche errore software, essere stato catalogato come un "Reclami - Altro" dai sistemi Aruba.

Ho fatto quindi il mio dovere di bravo cittadino: mi sono collegato al servizio di assistenza Aruba per segnalare il problema: "Ho ricevuto un email apparentemente inviato da voi in cui vengo invitato ad aprire un allegato PDF per la gestione di una mia richiesta. Richiesta che non ho mai fatto...Ho analizzato rapidamente gli header dell'email e gli header Received sembrano legittimi (cioè sembrano essere associati a voi). Cosa devo fare? Spero che questo email sia veramente un tentativo di attacco e non un email legittimo provocato dalla mia richiesta di rinnovo annuale PEC (questo secondo caso sarebbe, a mio parere, un pessimo modo di gestire queste pratiche).".

La risposta è stata, per me, sconsolante: "...a seguito di verifiche le comunico che la segnalazione di cui ci invia il numero non risulta esser presente sui nostri terminali e di conseguenza la invito a ritenerla nulla. Per ciò che concerne il rinnovo da lei richiesto risulta normalmente eseguito senza problemi di sorta...". In altre parole, non hanno neanche capito il problema.

Ho insistito, ancora con l'illusione di compiere un servizio: "OK, per me non ci sono problemi. Ma a mio parere non dovreste trascurare il fatto che si verifichino attacchi a vostri utenti (a questo punto è evidente che sono stato fatto oggetto di un tentativo di attacco) con email che sfuggono ai filtri antispam di Google ed i cui header indicano che sono stati inviati da voi. Specialmente se tali attacchi si verificano il giorno successivo ad un incidente molto grave ad un provider di PEC italiano. Il tentativo di attacco e la vostra gestione non mi tranquillizzano molto.".

Nessuna risposta. Insisto dopo 5 giorni. Ancora nessuna risposta, solo una notifica che "sono necessarie alcune verifiche ma cercheremo di risponderti nel più breve tempo possibile".

Sto ancora aspettando (3 Dicembre ore 12.35).

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).

Cosa interessante da notare: il "messaggio sospetto" è visualizzato da Gmail in modo leggermente diverso dai messaggi legittimi, cioè da quelli effettivamente provocati da mie interazioni con l'assistenza:

(interazione reale con l'assistenza)

(messaggio sospetto)