martedì 19 dicembre 2017

Catene di certificati HTTPS

Nella lezione di Reti di Calcolatori di oggi abbiamo accennato ad un argomento che non è parte del corso, cioè le catene di certificati.

Nel corso abbiamo detto che la chiave pubblica di un Subject viene ottenuta sempre attraverso un certificato emesso da un Issuer che deve già essere presente nel KeySet e nel TrustSet di chi utilizza quel certificato.

Nella realtà accade quasi sempre una cosa più complicata: invece di un certificato arriva una sequenza di certificati in cui:

  • Lo Issuer dell'ultimo certificato della sequenza è il Subject del penultimo certificato;
  • ...
  • Lo Issuer del k-esimo è il Subject del (k-1)-esimo;
  • ...
  • Il primo certificato della sequenza è self-signed.

Solo il Subject=Issuer del primo certificato è nel KeySet e nel TrustSet (il primo certificato della sequenza deve cioè essere già presente nel software di chi usa la catena).

Intuitivamente, la CA che ho già nel KeySet e TrustSet delega un'altra CA-1 a rilasciare certificati; il fatto che io mi fidi di CA implica (trascurando qualche dettaglio) che mi fidi anche di CA-1. Poi CA-1 delega un'altra CA-2 e così via, fino ad arrivare al Subject finale che è certificato da una CA-X che non c'entra nulla con quella nel KeySet e TrustSet. La mia fiducia (implicita) in CA-X è una conseguenza logica della mia fiducia in CA.

Durante la lezione ho cercato di visualizzare una di queste catene ma come mi accade spesso non ci sono riuscito. In realtà è semplicissimo. Il certificato visualizzato dal browser è l'ultimo della catena, ad esempio, nel caso di Gmail:


Il tab "percorso certificazione" mostra una sintesi della catena: 

Andando a scavare nel TrustSet / KeySet di Windows 10 si trova, con un pò di pazienza, il certificato autofirmato che costituisce la "anchor" della catena, cioè l'atto di fede su cui si basa tutto il resto.


A questo punto iniziano infinite domande "ma i certificati intermedi possono essere inseriti nel KeySet? e nel TrustSet? e se dopo mi arriva dall'esterno uno diverso? e se viene revocato un certificato nella catena? e se un Issuer nella catena è già nel mio KeySet ma con una chiave diversa?". E così via. 

La quantità di problemi insiti in questa faccenda è una ulteriore dimostrazione della verità di quella frase che ho mostrato a lezione ed attribuito al quasi-Sheva&Kakà, "chiunque affermi che un problema è risolto facilmente dalla crittografia, dimostra di non avere capito il problema".




giovedì 14 dicembre 2017

Link HTTPS in pagine HTTP: (quasi) completamente inutili

In una delle ultime lezioni del corso di "Reti di Calcolatori" abbiamo approfondito alcuni dettagli sottili, ma neanche troppo, di https, il protocollo per la navigazione cosiddetta-sicura sul web. E' quel protocollo che usiamo ogni volta che andiamo sul sito di una banca, di una compagnia aerea, di un sito di ecommerce e così via.

Tra le altre cose, avevamo evidenziato che se una pagina P è critica per la sicurezza (ad esempio una pagina contenente un form di autenticazione) allora è indispensabile mettere P su https.

Avevamo anche evidenziato che se facciamo un sito con una home page su http e mettiamo nella home page un link verso P, allora avere messo P su https è (quasi) completamente inutile.
  • Infatti, quando gli utenti arrivano sulla home page, ricevono contenuti su http, quindi senza garanzie di autenticazione ed integrità;
  • quindi, lo sforzo che deve fare un attaccante per modificare i link contenuti nella home page è determinato da http, non da https;
  • quindi, lo sforzo per modificare il link che dovrebbe puntare verso P e farlo invece puntare verso una pagina scelta dall'attaccante è determinato da http, non da https;
  • quindi, lo sforzo per mostrare agli utenti una pagina con un form di autenticazione dall'aspetto identico a quello di P ma localizzata su un server controllato dall'attaccante, è determinato da http, non da https.
Più chiaro di così non riesco ad esprimerlo.

Bene, proprio ieri si sono diffusi sui social molti tweet di scherno diretti ad una banca (australiana) che ha proprio questo problema:

https://www.troyhunt.com/im-sorry-you-feel-this-way-natwest-but-https-on-your-landing-page-is-important/

La persona che ha scritto il blog post è la stessa che ha inventato e sta mantenendo https://haveibeenpwned.com/ ed è uno dei pochi consulenti che pochi giorni fa è stato chiamato per dare un testimony sulla cybersecurity al parlamento americano. Ha quasi 90.000 follower su Twitter (https://twitter.com/troyhunt).

Se qualcuno pensa che io sono troppo pessimista o mi preoccupo solo di problemi di interesse solo teorico, spero che creda a a lui....