Alfonso Maruccia

Email sicure, nuovo protocollo in arrivo

I colossi tecnologici accomunati da una proposta di "messa in sicurezza" della posta elettronica, un mezzo di comunicazione sempre popolare ma non al passo coi tempi quando si parla di protezione dei messaggi e del loro contenuto

Roma - Una insolita coalizione che include Google, Microsoft, Yahoo, Comcast, LinkedIn e alcuni ricercatori indipendenti ha proposto l'adozione di un nuovo standard di comunicazione sicuro per le email, un'estensione crittografica alla posta elettronica standard pensata per correggere i difetti delle soluzioni che hanno fin qui provato a contrastare la violazione della riservatezza delle comunicazioni personali e non.

La nuova proposta descrive un meccanismo chiamato SMTP Strict Transport Security (SMTP STS), un modo per permettere ai mail server di "dichiarare la loro capacità" di stabilire una connessione sicura (TLS), i tipi di verifica dei certificati crittografici e l'eventuale reazione di rigetto/conferma di invio del messaggio in caso di mancanza del supporto ai certificati TLS.

Obiettivo di SMPT STS è chiudere la "falla" di sicurezza che caratterizza le email sin dalla loro creazione (1982), quando i tempi tecnologici erano molto meno maturi e l'idea che l'intelligence americana (NSA) e non spiasse il mondo intero era ancora annoverabile tra le teorie dei complotti improbabili.
Un primo tentativo di rendere sicure le email era stato fatto con l'estensione STARTTLS, ma è risultata essere vulnerabile ad attacchi di spoofing per costringere il client a inviare i messaggi di posta in formato testuale senza protezione crittografica.

Ora SMPT STS prova ancora una volta a migliorare la sicurezza delle email facendo quello che HSTS già fa per HTTP, vale a dire mitigare le possibilità di attacco e impedire l'invio del testo "liscio" senza protezione crittografica. Il fatto che il nuovo protocollo sia promosso pesi massimi della Rete suggerisce il successo dell'iniziativa.

Alfonso Maruccia
Notizie collegate
  • AttualitàWikimedia: HTTPS per tuttiLe connessioni cifrate offrono ai cittadini della Rete garanzie contro il tecnocontrollo sui loro interessi e sulle loro attività online: per questo i siti della Fondazione, Wikipedia compresa, implementeranno a breve HTTPS di default
17 Commenti alla Notizia Email sicure, nuovo protocollo in arrivo
Ordina
  • Più che un protocollo mi sembra un protocolon.
    Le mail devono essere leggibili dai vari Yahoo, Google, Microsoft e compagnia cantante.
    Altrimenti addio ad una buona parte della profilazione del cliente e dei suoi contatti e quindi addio ad una parte degli introiti presenti e futuri (i database rimangono ai venditori che reincrociano continuamente i dati per aumentare la precisone di profilazione per scopi futuri, non necessariamente primariamente economici).
    non+autenticato
  • mi sembra come il registro automobilistico dell'aci..
    non+autenticato
  • Come proponi di fare? Un mercato borsistico dove il migliore offerente riceve le mail per quel determinato dominio?
    non+autenticato
  • Il 99% delle email viene violato via trojan o via imbecilli che si installano apps che transitano dalla russia o dal vietnam per scaricare le email .
    non+autenticato
  • "(1982), quando i tempi tecnologici erano molto meno maturi e l'idea che l'intelligence americana (NSA) e non spiasse il mondo intero era ancora annoverabile tra le teorie dei complotti improbabili"

    Proprio qui su PI é pieno di avventori ottimistoni ancorata alla mentalità degli anni ottanta.
    non+autenticato
  • io gia' ora posso configurare che il mio server di posta non invii email se l'altro server non supporta TLS quindi basta mettersi daccordo per forzare questa cosa
    non+autenticato
  • - Scritto da: Scumm78
    > io gia' ora posso configurare che il mio server
    > di posta non invii email se l'altro server non
    > supporta TLS quindi basta mettersi daccordo per
    > forzare questa cosa

    Il problema sono due: il primo è che spesso (come per altri protocolli diversi dall'HTTPS) non viene fatta una validazione della correttezza del certificato: io posso tranquillamente avere un certificato rilasciato dalla mia CA farlocca e presentarmi come smtp.google.com, ma questo non significa che io sia in realtà chi il mio certificato (magari self-signed) dice che io sia. In maniera analoga, non ci sono molti client FTPS che controllano che il certificato del chiamato corrisponda al nome effettivamente chiamato. Il secondo è che le connessioni STARTTLS sono vulnerabili a cosiddetti attacchi encryption downgrade, dove la codifica è semplicemente rimossa.
    non+autenticato
  • - Scritto da: Scumm78
    > io gia' ora posso configurare che il mio server
    > di posta non invii email se l'altro server non
    > supporta TLS quindi basta mettersi daccordo per
    > forzare questa
    > cosa

    Il mio server di posta non supporta TLS, ma in compenso puoi sempre criptare i messaggi che mi mandi: la mia chiave pubblica e' nota ai miei corrispondenti.
  • - Scritto da: panda rossa
    > - Scritto da: Scumm78
    > > io gia' ora posso configurare che il mio
    > server
    > > di posta non invii email se l'altro server
    > non
    > > supporta TLS quindi basta mettersi daccordo
    > per
    > > forzare questa
    > > cosa
    >
    > Il mio server di posta non supporta TLS, ma in
    > compenso puoi sempre criptare i messaggi che mi
    > mandi: la mia chiave pubblica e' nota ai miei
    > corrispondenti.

    e dove sarebbe pubblicata, codesta pubblica chiave?
    non+autenticato
  • - Scritto da: ...
    > - Scritto da: panda rossa
    > > - Scritto da: Scumm78
    > > > io gia' ora posso configurare che il mio
    > > server
    > > > di posta non invii email se l'altro server
    > > non
    > > > supporta TLS quindi basta mettersi daccordo
    > > per
    > > > forzare questa
    > > > cosa
    > >
    > > Il mio server di posta non supporta TLS, ma in
    > > compenso puoi sempre criptare i messaggi che mi
    > > mandi: la mia chiave pubblica e' nota ai miei
    > > corrispondenti.
    >
    > e dove sarebbe pubblicata, codesta pubblica
    > chiave?

    Nella firma dei miei messaggi di posta.
  • - Scritto da: panda rossa
    > - Scritto da: ...
    > > - Scritto da: panda rossa
    > > > - Scritto da: Scumm78
    > > > > io gia' ora posso configurare che
    > il
    > mio
    > > > server
    > > > > di posta non invii email se
    > l'altro
    > server
    > > > non
    > > > > supporta TLS quindi basta mettersi
    > daccordo
    > > > per
    > > > > forzare questa
    > > > > cosa
    > > >
    > > > Il mio server di posta non supporta
    > TLS, ma
    > in
    > > > compenso puoi sempre criptare i
    > messaggi che
    > mi
    > > > mandi: la mia chiave pubblica e' nota
    > ai
    > miei
    > > > corrispondenti.
    > >
    > > e dove sarebbe pubblicata, codesta pubblica
    > > chiave?
    >
    > Nella firma dei miei messaggi di posta.

    se e' nei TUOI messaggi di posta allora NON E' pubblicata, quindi non dire cose inesatte con E' PUBBLICATA.

    Questa la mettiamo insieme a quella della raspberry, eh?
    non+autenticato
  • - Scritto da: ...
    > - Scritto da: panda rossa
    > > > > Il mio server di posta non supporta
    > > TLS, ma
    > > in
    > > > > compenso puoi sempre criptare i
    > > messaggi che
    > > mi
    > > > > mandi: la mia chiave pubblica e' nota
    > > ai
    > > miei
    > > > > corrispondenti.
    > > - Scritto da: ...
    > > > e dove sarebbe pubblicata, codesta pubblica
    > > > chiave?
    > - Scritto da: panda rossa
    > > Nella firma dei miei messaggi di posta.
    > > - Scritto da: ...
    > se e' nei TUOI messaggi di posta allora NON E'
    > pubblicata, quindi non dire cose inesatte con E'
    > PUBBLICATA.

    prova a rileggere mi sembra che l'unico che ha detto PUBBLICATA sei tu

    ma c'è bisogno di tutto questo astio sempre?
    bho
    non+autenticato
  • Se una chiave è pubblica, come tu HAI SCRITTO, significa che chiunque può accedervi, se invece è solo nella firma delle tue mail (che ORRORE) significa che solo chi riceve le tue mail può accedervi, quindi non è PUBLLICA ma privata.
    non+autenticato
  • - Scritto da: bitbit
    > Se una chiave è pubblica, come tu HAI SCRITTO,
    > significa che chiunque può accedervi, se invece è
    > solo nella firma delle tue mail (che ORRORE)
    > significa che solo chi riceve le tue mail può
    > accedervi, quindi non è PUBLLICA ma
    > privata.

    https://it.wikipedia.org/wiki/Crittografia_asimmet...
    chiave pubblica e chiave privata
    no comment
    non+autenticato
  • - Scritto da: gin
    > - Scritto da: bitbit
    > > Se una chiave è pubblica, come tu HAI
    > SCRITTO,
    > > significa che chiunque può accedervi, se
    > invece
    > è
    > > solo nella firma delle tue mail (che ORRORE)
    > > significa che solo chi riceve le tue mail può
    > > accedervi, quindi non è PUBLLICA ma
    > > privata.
    >
    > https://it.wikipedia.org/wiki/Crittografia_asimmet
    > chiave pubblica e chiave privata
    > no comment

    Un informazione (chiave) che conosci solo tu e i tuoi corrispondenti non puoi considerarla pubblica (disponibile a TUTTI). Se poi per PUBBLICA intendi l'opposto di PRIVATA nella crittografia asimmetrica allora ok, no comment...
    non+autenticato
  • - Scritto da: panda rossa
    > - Scritto da: Scumm78
    > > io gia' ora posso configurare che il mio
    > server
    > > di posta non invii email se l'altro server
    > non
    > > supporta TLS quindi basta mettersi daccordo
    > per
    > > forzare questa
    > > cosa
    >
    > Il mio server di posta non supporta TLS, ma in
    > compenso puoi sempre criptare i messaggi che mi
    > mandi: la mia chiave pubblica e' nota ai miei
    > corrispondenti.
    e rimane l'undubbio vantaggio di poter "interrogare" i server a mano, invece di sclerare (come gia' avviene ora... port 465 smtp over ssl or port 587 smtp con startls e auth eencodata, e poi il cagone paranoico di risponde con https://support.google.com/mail/answer/78754 ... pfff)
    non+autenticato