Come può un utente non tecnico verificare che un messaggio sia stato inviato "in sicurezza"? ... o su TLS?

Naviga le tue risposte
5

Ho una situazione in cui le comunicazioni B2B e B2C devono essere inviate in modo sicuro e non visibili alla maggior parte dei dirottatori SMTP. Non mi interessano le teorie cospirative o gli attacchi in stile NSA, ma voglio fornire una ragionevole sicurezza per le persone che non vogliono che i loro dati PII vengano esposti ad aggressori meno capaci.

Questo requisito aziendale deriva dalle leggi sulla privacy dei dati del Massachusetts che richiedono informazioni personali per i residenti da inviare "crittografati" senza ulteriore elaborazione dei requisiti tecnici.

Il business dei nostri clienti dipende in gran parte dall'e-mail e dalla capacità di inviare informazioni personali per assicurazioni sulla vita, assicurazione sanitaria e altri prodotti finanziari.

A tal fine, intendo utilizzare TLS per fornire questa sicurezza a causa della sua ubiquità, facilità d'uso e che collabora bene con i requisiti di conformità finanziaria. Immagino di creare un tunnel TLS diretto tra l'MTA del partner e il nostro. (TLS forzato non opportunistico)

Il problema è che la "sicurezza" TLS è sepolta nelle intestazioni SMTP, difficile da capire, e i confini dell'amministrazione sono difficili da delineare. per es. 

  company1 ---->  MSFT Hosted Relay  -->  [TLS between providers] ----> Google Hosted --> Company 2

  company1 ---->  Proofpoint         -->  [TLS between providers] ----> Google Hosted --> Company 2

Domanda

Si supponga che una compagnia assicurativa debba inviare un SSN in un messaggio di posta elettronica (corpo o allegato). Il prossimo hop MTA è un Gmail, Yahoo o altro MTA privato di fiducia.

  • Come posso dare al destinatario la certezza che il messaggio è stato inviato in modo sicuro su TLS?

  • Quali soluzioni tecniche alternative o RFC potrebbero aiutare a darmi questa assicurazione? (Forse una variante di DMARC / DKIM + TLS?)

posta random65537 03.10.2013 - 17:22
fonte

7 risposte

7

Il tuo obiettivo è quello di guidare in una vite, e si desidera utilizzare un martello perché ne hai uno a portata di mano ed è facile da usare. Temo che il risultato più probabile sia un pollice dolente.

TLS riguarda fondamentalmente la sicurezza point-to-point. È solo collegato alla connessione, non ai dati. L'e-mail, d'altra parte, è fondamentalmente progettata per rimbalzare attraverso più hop. Mentre i luppoli lasciano un timbro tracciando le loro azioni, si dovrebbe dipendere dagli host per non essere maliziosi (ogni hop può simulare l'intero messaggio inclusi i timbri dei suoi predecessori), per non lasciarsi ingannare (ad esempio, nel misautentarsi del loro predecessore), e per lasciare i timbri che ti aspetti.

Puoi dare al destinatario la certezza che il messaggio è stato trasmesso in modo sicuro consegnando un messaggio crittografato firmato dal mittente. TLS non è utile per questo. RFC che può aiutarti a includere RFC 3156 , RFC 4880 (formato messaggio OpenPGP), RFC 5750 e RFC 5751 (S / MIME).

In altre parole: usa PGP o S / MIME.

    
risposta data 03.10.2013 - 23:59
fonte
6

In realtà non puoi davvero dare alcuna garanzia in ogni caso. Non puoi garantire in modo affidabile che una data email sarà protetta da TLS su ciascun hop, perché i server rilevanti lo fanno in modo opportunistico e l'elenco dei server rilevanti può cambiare senza preavviso ( il routing dinamico, anche a livello SMTP, è comune per i server più utilizzati). Anche per una e-mail che è stata inviata, puoi sapere se le connessioni erano protette da TLS solo nella misura in cui i server rilevanti erano abbastanza gentili da indicarlo (e quindi, solo nelle intestazioni Received: ), e, ancora una volta, solo se lo stesso server fosse abbastanza gentile da non lie a riguardo.

Il formato dei dati nelle intestazioni Received: è puramente tradizionale, non standard, e non tutti i server utilizzano lo stesso formato. Questa intestazione è pensata per essere leggibile dall'uomo, almeno per una nozione di "umano" che corrisponde all'ambiente sociale dei primi scrittori di RFC. Come hai notato, non tutti possono aspettarsi che ogni cliente sia "quel tipo di umano".

Un punto ancora più importante è che l'intestazione Received: può essere visualizzata solo nell'e-mail che è stata ricevuta . Immagina un individuo malvagio che vuole leggere alcune e-mail inviate da altre persone ad altre persone. Se quell'individuo malvagio è < inserisci qui la tua agenzia di spionaggio preferita > , allora deve solo corrompere uno stagista in uno dei luoghi che ospita un server SMTP. Ma supponiamo che il cattivo sia un libero professionista. Vorrebbe intercettare l'email mentre viene trasferita dal server SMTP G (come "Gahoo") al server SMTP Y (come "Ymail") (nomi fittizi, ovviamente). Quindi impiega il MitM del povero uomo, noto come avvelenamento del DNS : si pone come server SMTP Y agli occhi del server SMTP G.

G si connette, gli aggressori affermano di non supportare TLS (o di supportare TLS con un certificato errato, o qualsiasi altra cosa); G degrada con grazia a non TLS e invia l'e-mail "così com'è". Quindi, il malintenzionato non riconosce la ricezione dell'e-mail e interrompe bruscamente la connessione. Il server SMTP G considera tale evento come un errore casuale della rete, ci riprova, questa volta si connette al server Y reale (eventualmente trasmesso dall'attaccante, non importa), fa TLS, invia l'e-mail. Sulla parte ricevente, non vi sarà traccia del trasferimento non TLS interrotto che si è concluso nella macchina dell'attaccante. L'e-mail contiene un sacco di Received: di intestazioni che affermano che TLS è stato utilizzato in tutto - perché parlano solo della connessione di successo .

Sebbene non si possa garantire che l'e-mail sia ben protetta, si potrebbe riuscire a convincere un cliente non tecnico che è stato ben protetto. Per esempio non dicendogli qualcuna delle precedenti ...

La linea di fondo è che l'email non è sicura e non è mai stata . Per la sicurezza della posta elettronica, è necessaria una vera soluzione end-to-end, ovvero PGP o S / MIME (presupponendo che siano impiegati correttamente, il che non è un dato).

    
risposta data 03.10.2013 - 20:41
fonte
2

Nel caso specifico descritto sopra, dove stai inviando da un noto fornitore abilitato a TLS a un ricevitore noto con TLS (senza fastidiosi backup MX di terze parti), puoi fidarti del percorso, ma non c'è modo perché un destinatario lo confermi se non dividendo le intestazioni Received (o i log SMTP su ciascun hop) se TLS è stato utilizzato lungo il percorso.

Data la natura store-and-forward di SMTP, nel caso generale , tu (il mittente) non puoi sapere in anticipo che un messaggio specifico arriverà dopo aver usato solo connessioni TLS ad ogni hop.

In base alle mie conoscenze, non esiste un modo interoperabile 1 per indicare a un server SMTP su base per messaggio di utilizzare solo TLS; e nessun metodo comune per un MUA per indicarlo, come un indicatore visivo DKIM in alcuni client di posta elettronica. Dato che il formato dell'intestazione Received varia da MTA a MTA, è un problema più difficile che potrebbe sembrare.

Con una base di utenti non tecnici, un'alternativa potrebbe essere un PDF crittografato, ma con un requisito segreto condiviso ... anche questo potrebbe cadere in conflitto con le politiche di ispezione dei contenuti obbligatorie.

Un'altra alternativa comunemente utilizzata (che ha di nuovo un requisito di segretezza condivisa o di autenticazione) è l'invio tramite posta elettronica di un collegamento HTTPS al contenuto.

Suppongo che sia mostrato anche all'utente come tagliare e incollare le intestazioni, anche se mxtoolbox evita di analizzare i dettagli di TLS, sarebbe teoricamente possibile.

Una soluzione TLS non è ottimale: è il livello 5 (sessione), stai provando a fornire la sicurezza del livello 7 (applicazione) del livello (e senza inghiottire tutti e tre i riservatezza , integrità , autenticazione pillole amare ...)

1 La SalesForce X-SFDC-TLS-NoRelay header sembra essere un modo proprietario, anche se sto indovinando qui perché non riesco a trovare la sua documentazione intento.

    
risposta data 03.10.2013 - 19:38
fonte
2

La soluzione non è inviare le PII tramite e-mail. Invia tali informazioni tramite un sito Web in cui è possibile garantire che sia crittografato con TLS e sia facilmente accessibile per il consumatore e gli agenti assicurativi.

    
risposta data 03.10.2013 - 20:47
fonte
0

Benvenuto nel problema dell'email sicura. Vediamo le tue opzioni:

  1. SMTP

    A livello di protocollo, SMTP non ha alcun concetto di sicurezza. Come la maggior parte dei primi protocolli Internet (sto guardando il tuo DNS), è stato progettato senza assumere server malevoli. Assumi NULLA di cose inviate via SMTP per ragioni documentate nelle altre risposte qui

  2. PGP o S / MIME

    Entrambi sono overlay a livello di applicazione che proteggono strati inferiori fondamentalmente insicuri. È fantastico, ma entrambi richiedono che l'effetto di rete (degli utenti) funzioni, un problema ereditato dal loro inevitabile utilizzo della crittografia asimmetrica (il problema PKI). Considerando che l'e-mail (come applicazione) ha il maggior numero di utenti di Internet sul pianeta, non vedo che cambierà presto. In una situazione B2C (anche in molti B2C) sei decisamente sfortunato.

  3. Livello di riferimento indiretto (aka "Illusion of security")

    Questo non porta alcuna sicurezza MA, se stai cercando di rispettare le leggi MA sul non invio di PII, potresti essere in grado di inviare un link basato su GUID in email, che quando cliccato presenta le informazioni reali in un browser. O utilizzare e-mail HTML dove il testo PII è in realtà un'immagine caricata su SSL all'interno del client di posta elettronica. Tecnicamente non invii le informazioni personali personali su un trasporto non sicuro. Non ho bisogno di dirtelo ma devi consultare un avvocato se questo riguarda il tuo rischio commerciale.

  4. Modifica i requisiti aziendali ( < == consigliato )

    Personalmente, questo è quello che sceglierei. Eviterei di inviare qualsiasi informazione personale nell'email per cominciare. Se questo è l'e-mail marketing per i nuovi clienti (B2C), potresti effettivamente insinuarli inserendo le PII in una e-mail a freddo. Se hai già questi clienti (B2C), ti consiglio di creare un centro di messaggistica basato sul web dietro una schermata di accesso (supponendo che la tua azienda disponga di un portale di accesso per le altre cose). Onestamente, questo è l'approccio adottato dalla maggior parte delle banche e degli ospedali per il motivo esatto che stai riscontrando (a nessuno piace l'ennesimo portale di messaggistica ma sono obbligati a farlo). In questo modo è possibile utilizzare e-mail regolari senza PII per le e-mail di massa, inoltrarle al portale Web per i casi in cui sono necessarie informazioni personali. Budget il builtout del portale di messaggistica sicura (insieme all'integrazione SSO) e presentalo ai decisori che creano l'esigenza aziendale di "inviare email personali in e-mail" e lasciare che decidano se il prezzo vale la pena.

risposta data 08.10.2013 - 05:18
fonte
0

Ho avuto la stessa domanda e ho scoperto che mxtoolbox.com (ora) fornisce un'interfaccia per interrogare un server SMTP e segnalare se supporta TLS. Questa è l'unica prova che sembra essere in grado di presentare che TLS è a posto.

    
risposta data 09.02.2016 - 06:10
fonte
0

Non si dovrebbe mai inviare informazioni personali tramite un'e-mail in chiaro. Anche se gli hop di rete sono protetti da TLS, non puoi essere certo che i dati siano crittografati a riposo. In molti casi i dati sono disponibili per terze o quarte parti, ad es. In particolare, Google analizzerà le e-mail dei suoi utenti per capire quali pubblicità mostrare o per individuare i pattern nello spam-- e non è possibile confermare che tutti i vari sistemi coinvolti siano adeguatamente sicuri o conformi. E anche se lo sono, puoi ancora subire una significativa perdita di reputazione se, per esempio, "privatamente" scrivi a uno dei tuoi clienti sulla disfunzione erettile, poi improvvisamente inizia a vedere annunci per Viagra ovunque, perché Google ha diffuso una determinata parola chiave nella sua rete pubblicitaria .

Mi vengono in mente due alternative:

  1. Proteggi il contenuto dell'e-mail con uno schema di crittografia come PGP.

  2. Non inserire il contenuto nell'e-mail. Invece, fornire un collegamento a un sito in cui l'utente può accedere e visualizzare il contenuto. Ad esempio, funziona il servizio di busta sicura Citrix.

risposta data 09.06.2017 - 12:40
fonte

Leggi altre domande sui tag

Beneficiare di disabilitare TLS1.1 e TLS1.2? I test di penetrazione hanno segnalato vulnerabilità ZERO. Questo significa che la mia app web è sicura?