Sicurezza dell'email [duplicato]

Ciò dipenderà dal modo in cui configurano i loro server di posta. Normalmente la connessione tra i server di posta può essere crittografata anche utilizzando TLS / SSL. Considerando che Gmail e Hotmail sono gestiti da MS e Google, normalmente dovrebbe essere abilitato. (solo in modo non completo Gmail lo fa e non lo impone se l'altro capo vuole parlare chiaro)

Se non sei sicuro, puoi sempre usare GPG / PGP

Modifica

Possibile altra risposta qui: Che passi fai Gmail, Yahoo! Mail e Hotmail per impedire l'intercettazione delle email?

I server SMTP di Hotmail non utilizzano la sicurezza TLS nel trasporto ... l'attività SMTP dietro le quinte che fa apparire il messaggio nel diverso ISP. È possibile convalidare questo guardando le intestazioni SMTP. In Gmail, devi fare clic su "visualizza originale" per vedere queste intestazioni.

Gmail, Yahoo e molti altri provider crittografano i messaggi durante il trasporto con la sicurezza TLS. Per qualche motivo Hotmail no.

Alcuni provider di posta utilizzano la crittografia TLS in modo opportunistico (quando sia il mittente che il destinatario sembrano supportarli, questo è descritto in RFC 3207 ). Si noti che tale rilevamento opportunistico non può garantire una sicurezza assoluta: i messaggi scambiati dal mittente e dal ricevente e che indicano se STARTTLS è supportato o meno, non sono protetti. Un utente malintenzionato che esegue un uomo nell'attacco intermedio può intercettare questi messaggi e costringere il mittente e il destinatario a non usa TLS. Per consentire la protezione da tali attacchi, i server SMTP non devono solo utilizzare TLS, ma anche rifiutarsi di parlare all'altro server a meno che non sia possibile utilizzare TLS.

In pratica, la crittografia opportunistica darà una certa protezione contro gli intercettatori passivi : persone dalle grandi orecchie piuttosto leggendarie che toccano i collegamenti di rete e ascoltano ma non interferiscono mai. Un punto importante è che mentre TLS protegge i dati mentre è in transito, non fa nulla per data at rest : i server coinvolti (i server SMTP attraverso i quali l'email va e i server IMAPS o HTTPS-Webmail che ospitare la cartella "Posta in arrivo" del destinatario e la cartella "Messaggi inviati" del mittente) vedere i dati non crittografati e scriverli su hard disk. I contenuti della posta elettronica sono vulnerabili in questi punti.

Se fossi una spia (impiegata da un'agenzia finanziata dallo Stato, o, come è più spesso al giorno d'oggi, ingaggiata dai concorrenti), non andrei ai problemi tecnici di localizzare i cavi di comunicazione e collegarli; Vorrei corrompere uno o due stagisti che lavorano presso il tuo ISP e fargli rubare vecchi nastri o dischi di backup (con l'uso diffuso di RAID , interi dischi possono essere rubati senza nemmeno interrompere il servizio, quindi discretamente ). La quantità di STARTTLS non ti proteggerà da questo.

Come dice @Lucas, se sei serio riguardo alla sicurezza della posta elettronica, hai bisogno di una protezione end-to-end: S / MIME o OpenPGP (ad es. GnuPG implementazione di quest'ultimo).

Potresti anche essere interessato a questa risposta

To answer your boiled-down question: How insecure is email? Practically speaking email is subject to attack by DNS spoofing, WIFI interception, and untrusted network administrators just to name a few.

To mitigate this you need to consider the different aspects that need security. It's likely most companies will fall short in security in at least one of the following areas, so anything you send could be in clear text and visible by someone other than your intended recipient.

Under each facet of security I listed relevant products grouped by how they are technically implemented. Ask yourself these questions based on the content you're sending over email:

Message Sender Verification

Does the recipient need proof that it was you who actually sent the message?

• SenderID/SPF Records (weak verification)
• Domain Keys / DKIM (strength depends on implementation)
• DMARC (Strong validation of the display from user... hybrid of SenderID and DomainKeys)
• PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
• Portal-based products (Voltage, Proofpoint, Zixmail)
• Microsoft RMS server + Outlook

Message Transport
Do I need to prevent unauthorized reading or modification of the email sender's MTA and my MTA?

• Enforced TLS, with certificate validation. Non-validated certs are subject to MITM attacks.
• Zix-based TLS is a private TLS network that doesn't require manual configuration
• PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
• Portal-based products (Voltage, Proofpoint, Zixmail)
• Microsoft RMS server + Outlook

Reading the message

Must I ensure that only the intended recipient is able to read the message content?

• PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
• Portal-based products (Voltage, Proofpoint, Zixmail)
• Microsoft RMS server

Must the client endpoint be secure? (applies if above 3 products aren't used)

• The target network administrator is delivering email using a secure transport (Encrypted MAPI, POP3 over TLS, etc)
• The target device is secure. This applies to workstations, and mobile devices.
• Microsoft UAG adds features to OWA where the endpoint is audited and will delete left-over attachments in %temp% and restrict or deny access to features as policy dictates
• An alternative to UAG is to block attachments from reaching the client (as Henri first mentioned)

gmail.smtp.com usa due pacchetti SASL e TLS. Quando si preme gmail.smtp.com sulla porta 587, verrà richiesto all'utente / pass che verrà fornito dal pacchetto SASL e la crittografia dell'utente / pass è raggiunta dal pacchetto TCP TLS. È possibile utilizzare lo script tcl con questi pacchetti per l'invio di una posta .

Se sei preoccupato per la sicurezza della tua e-mail, l'unico modo per avere una ragionevole sicurezza è gestire da soli la crittografia, usando qualcosa come PGP / GPG. Alcuni punti da notare

• Quando si utilizza un client Web, https crittografa solo la comunicazione al servizio di posta che si sta utilizzando. Non fornisce alcuna garanzia in merito al livello di crittografia che si verifica durante il processo di trasporto del messaggio che si verifica tra i server

• Alcuni server SMTP supportano TLS ecc. se viene richiesto di utilizzarlo. Tuttavia, non c'è nulla nelle specifiche del protocollo SMTP che richiede loro di farlo. Molti server SMTP non lo forniscono.

• Non hai alcuna garanzia per quanto riguarda i server di posta che un messaggio sarà trasmesso. Molte persone pensano che quando si invia un messaggio dal server a al server b che il messaggio venga sempre passato come una connessione diretta tra questi due server. Questo non è necessariamente vero. Il protocollo SMTP è stato progettato in un momento in cui le reti e gli utenti erano molto meno affidabili di quanto non lo siano ora e quando molti luoghi non avevano connessioni dirette alla rete principale. Per abilitare il recapito affidabile della posta, il protocollo supporta l'inoltro della posta. In termini semplicistici, il server di posta mittente può dire "Ehi, ho un messaggio per Gmail, ma non riesco a sollevarlo e devo andare ad aggiornare il mio kernel, qualcuno può farmi passare questo messaggio per me quando ritorna? Lo farei, ma devo aggiornare il mio kernel e non ci sarà da un po '". Un altro server, probabilmente sconosciuto in precedenza, potrebbe rispondere dicendo "Hey sicuro, sono un host MX per il dominio del destinatario, posso inoltrare il messaggio per te".

Sebbene tutto ciò significhi che l'e-mail è solitamente abbastanza robusta, nel senso che la posta inviata a un indirizzo legittimo viene solitamente recapitata con successo o rimbalzata e raramente svanisce, crea alcuni punti deboli nel protocollo che espone il sistema a un numero di exploit, come lo spoofing del DNS. Anche se ignori l'aspetto del trasporto della posta elettronica, c'è anche il problema che i messaggi vengono regolarmente salvati sui server non crittografati, come nel caso dei direttori di spool della posta, rendendoli prontamente accessibili a chiunque abbia sufficienti diritti di accesso sul server. Anche dimenticando che, quante delle persone che hai inviato la posta per archiviare o archiviare effettivamente quella posta in modo sicuro crittografato? Se ti ho inviato un messaggio con dati sensibili, lo crittografhi prima di archiviarlo nel tuo archivio di posta? No? Quindi cosa succede al mio messaggio di posta elettronica sensibile quando il tuo computer è stato infettato da virus o malware? Che controllo ho su queste informazioni sensibili una volta che le ho inviato?

L'infrastruttura di posta elettronica è stata progettata in un momento in cui la sicurezza non era una priorità elevata. L'enorme crescita e il desiderio di mantenere tutto funzionante e la necessità di mantenere la retrocompatibilità significa che molti dei miglioramenti introdotti, come la crittografia della comunicazione tra server, ecc. Sono facoltativi e quindi non possono essere garantiti e anche se ci sono stati molti miglioramenti , alla fine della giornata, devi considerare l'email come un canale di comunicazione intrinsecamente insicuro. A meno che il mittente e il destinatario non intraprendano azioni aggiuntive per aumentare la sicurezza delle comunicazioni e-mail, è necessario considerare il messaggio come non sicuro, anche se si ritiene che le società che gestiscono i server coinvolti siano affidabili e applichino le buone pratiche.

Dovremmo anche tenere le cose in prospettiva. Quanta parte della mail che spedisci ha delle informazioni che sono veramente sensibili? Di quale valore reale è questa informazione per qualcun altro? Con quale facilità qualcuno potrebbe ottenere queste informazioni e il costo di farlo è inferiore al valore ottenuto? Raramente la sicurezza dovrebbe essere considerata in termini di sicurezza o insicurezza. La domanda dovrebbe essere se è abbastanza sicura per lo scopo per cui la sto usando. L'email è abbastanza sicura per il mio saluto di Natale che invio a mia nonna? Quasi certamente. È abbastanza sicuro che la mia banca invii il mio codice di accesso all'account o il PIN? Sicuramente no. Ci sono modi per aumentare la sicurezza dei messaggi? Sì, ma vengono tutti con un costo di convenienza. Ad esempio, PGP / GPG e crittografia del messaggio. Forniscono ulteriore sicurezza, ma riducono la comodità della comunicazione via e-mail. Ora è necessario creare e gestire le chiavi di crittografia e il destinatario deve configurare il proprio client per utilizzare la chiave pubblica per decrittografare il messaggio prima che possa leggerlo. Se il contenuto è sensibile e abbastanza prezioso, questo maggiore disagio può essere utile. Molto spesso, non lo è.