Commenti a "Scrivere email riservate in tutta sicurezza: guida alla crittografia con PGP"

[CUB3]

Scrivere email riservate in tutta sicurezza: guida alla crittografia con PGP



Le e-mail (o posta elettronica) sono da sempre considerate come una "evoluzione" della classica corrispondenza, quella fatta di lettere e buste di tangibile carta. Ma questa idea, mediata dalla associazione di riferimenti terminologici e grafici, anche se non completamente falsa, non tiene conto di una grossa e sostanziale differenza: la riservatezza. [continua..]

Inserite di seguito i vostri commenti.

[hashcat]

Prima di tutto complimenti per l'articolo!



Segnalo un paio di refusi:

1. Per che questo avvenga
2. assicuriamoci che sia la chiave giusta, selezioniamola e confermiamo per importarla nel nostro porta chiavi

Un altro problema (che fortunatamente appartiene al passato!) è che le nostre mail viaggiavano su connessioni non cifrate dal nostro computer fino al server di destinazione, rendendole di fatto potenzialmente intercettabili da chiunque.

Purtroppo resta ancora attuale il problema del trasporto, spesso in chiaro, delle e-mail dal MTA del mittente a quello del destinatario. Esistono (e sono sempre più frequentemente adottate) estensioni come STARTTLS che offrono il supporto alla crittografia opportunistica: si tratta senza dubbio di migliorie rispetto agli scambi in chiaro ma non di una "soluzioni" (per definizione: si ritorna alla comunicazione in chiaro se non supportata da tutti i MTA coinvolti nel trasferimento oppure in caso di attacchi MITM inoltre, solitamente, mittente e destinatario non sono informati in merito all'effettiva trasmissione dell'e-mail in chiaro).

Per che questo avvenga, entrambi devono avere le loro chiavi private e pubbliche, devono scambiarsi, tramite un canale sicuro, la loro chiave pubblica e a questo punto possono cominciare la comunicazione privata.

Anche tenendo a mente le finalità e limitazioni chiaramente esposte nello stesso articolo (il quale non ha la pretesa di rappresentare una trattazione completa dell'argomento) credo che sia necessario spiegare ai lettori in cosa consiste questo "canale sicuro" (magari tramite una semplice descrizione
ed esempi di canali sicuri/insicuri).

Altre osservazioni/suggerimenti:

• Ritengo una mancanza il non accennare minimamente al problema delle collisioni [1] [2] [3] [4] (rendendomi conto che ciò potrebbe risultare forse un po' troppo avanzato per un pubblico alle prime armi).
• Un ulteriore suggerimento è quello di illustrare in maniera concisa cosa PGP non tutela (oggetto, metadati, etc.).
• Infine inviterei a verificare se quanto riportato QUI sia ancora applicabile e, di conseguenza, ad aggiornare l'articolo per tenerne conto.

[1] https://debian-administration.org/users/dkg/weblog/105
[2] https://security.stackexchange.com/ques ... 4010#74010
[3] https://evil32.com
[4] https://lkml.org/lkml/2016/8/15/445

[CUB3]

Grazie hashcat, per i complimenti ma soprattutto per la revisione dell'articolo!!

Articolo corretto e aggiornato:

• - [spero non dispiaccia] mi sono appropriato della parte dove spieghi come il trasporto delle mail in chiaro sia sempre un problema tra gli MTA;
  - ho aggiunto un paio di esempi di "canale sicuro";
  - ho inserito un paragrafo sulla verifica della chiave (che non avevo preso in considerazione prima, perché pensavo allo scambio chiavi tramite, appunto, "canale sicuro");
  - avevo accennato al fatto che "PGP in linea" (a differenza di PGP/MIME) non cripta oggetto e allegati ma non avevo preso in considerazione i metadati: aggiunto un trafiletto al riguardo;
  - Enigmail cripta automaticamente le bozze già dal 2015;
  - già che c'ero, ho corretto anche la formattazione dell'articolo.

[hashcat]

Grazie hashcat, per i complimenti ma soprattutto per la revisione dell'articolo!!

Di nulla!

Articolo corretto e aggiornato

Non ho avuto modo di rileggerlo daccapo, ho solo dato un'occhiata e l'unica cosa che non mi convince pienamente è quanto riportato di seguito:

Perché questo avvenga, entrambi devono avere le loro chiavi private e pubbliche, devono scambiarsi, tramite un canale sicuro (per esempio, incontrandosi di persona o tramite un'app di messaggistica criptata la cui sicurezza è già stata provata precedentemente), la loro chiave pubblica e a questo punto possono cominciare la comunicazione privata.

Per sicurezza intendi che Alice e Bob abbiano verificato, in maniera analoga a quanto necessario per il PGP, le relative "impronte digitali" visionabili tramite l'applicazione di messaggistica criptata?
Solitamente viene menzionata la possibilità di effettuare una verifica telefonica attiva (chiamata) per confermare che le impronte digitali corrispondano (malgrado non si tratti di una soluzione sempre praticabile* ed infallibile**).

* Non è detto che le persone in questione siano in stretto contatto: potrebbero non volersi/potersi scambiare i rispettivi numeri di telefono.
** Non è da escludersi la possibilità di essere vittima di attacchi MITM anche per quanto riguarda le chiamate telefoniche o, molto più semplicemente, ingannati tramite "tecniche" quali quella del caller ID spoofing.



P.S.: Quasi dimenticavo...

• - [spero non dispiaccia] mi sono appropriato della parte dove spieghi come il trasporto delle mail in chiaro sia sempre un problema tra gli MTA;

Figurati, sono contento che tu abbia deciso di includerla nell'articolo.

[CUB3]

Non ho avuto modo di rileggerlo daccapo, ho solo dato un'occhiata e l'unica cosa che non mi convince pienamente è quanto riportato di seguito:

Perché questo avvenga, entrambi devono avere le loro chiavi private e pubbliche, devono scambiarsi, tramite un canale sicuro (per esempio, incontrandosi di persona o tramite un'app di messaggistica criptata la cui sicurezza è già stata provata precedentemente), la loro chiave pubblica e a questo punto possono cominciare la comunicazione privata.

Per sicurezza intendi che Alice e Bob abbiano verificato, in maniera analoga a quanto necessario per il PGP, le relative "impronte digitali" visionabili tramite l'applicazione di messaggistica criptata?
Solitamente viene menzionata la possibilità di effettuare una verifica telefonica attiva (chiamata) per confermare che le impronte digitali corrispondano (malgrado non si tratti di una soluzione sempre praticabile* ed infallibile**).

* Non è detto che le persone in questione siano in stretto contatto: potrebbero non volersi/potersi scambiare i rispettivi numeri di telefono.
** Non è da escludersi la possibilità di essere vittima di attacchi MITM anche per quanto riguarda le chiamate telefoniche o, molto più semplicemente, ingannati tramite "tecniche" quali quella del caller ID spoofing.

Adesso che me lo fai notare non mi piace nemmeno a me quel punto

Ho aggiornato nuovamete, specificando meglio quello che intendevo: "un'app di messaggistica privata e non intercettabile".
Ho anche aggiunto, come esempio, la possibilità di verificare il fingerprint con una telefonata diretta.