Webmail davvero sicuro

Question

Webmail davvero sicuro

#1 da (1 voti)
#2 da (0 voti)

1

Se mi sento paranoico riguardo al CCDP (Regno Unito) - Richiede ISP intercettare le comunicazioni su Internet - quale sarebbe l'approccio più sicuro per un sistema di webmail?

Ovviamente, ci sono alcune cose legali / politiche (posso contare sulle persone che lo gestiscono, posso fare affidamento sulla giurisdizione legale in cui si trova, ecc.) ma a livello tecnico, quale sarebbe un approccio strong alla gestione di un servizio webmail che non può essere incrinato da un attacco MITM eseguito dagli ISP dei miei utenti?

Mi sembra che ci siano parecchie cose che faranno la differenza rispetto a un tipico servizio commerciale come Gmail:

HTTPS, utilizzando TLS v.1.2 con scelte cyphersuite ben selezionate (non sono sicuro di quale cyphersuites abbia ragione). Ora che OpenSSL 1.0.1 è disponibile, è necessario TLS 1.2, sebbene blocchi i browser dipendenti da NSS (Firefox e Chrome - che significa Opera solo su sistemi operativi non Windows, Safari / Win supporta TLS 1.2 ma non Safari / Mac).
Nessun JavaScript (e quindi nessun AJAX), con forse un piccolo frammento di JavaScript che impedisce l'accesso al sito se JS è attivato sul client.
Consegna contenuti tutti da un singolo nome di dominio / indirizzo IP (nessun dominio "statico", nessun annuncio, nessun Google Analytics, ecc.)

Non intendo realmente implementare un servizio del genere (non sono in una giurisdizione legale adatta, per cominciare) ma sono sicuro che ci sono altre cose che potrebbero essere fatte.

Qualche suggerimento, pensieri?

web-application tls

posta Richard Gadsden 07.04.2012 - 23:14

fonte

2 risposte

Leggi altre domande sui tag web-application tls

Strumenti dello scanner di vulnerabilità da utilizzare con Snort Affidabilità di DNSBL per l'interruzione dello spam del forum

score 1 · Answer 1

Le cose principali che puoi fare sono:

Usa SSL sul sito web . Disabilitare l'accesso HTTP (non SSL) o reindirizzare gli utenti alla versione SSL del sito Web.
Utilizza HSTS per dichiarare ai clienti che devono connettersi solo tramite SSL.
Assicurati che tutti i cookie abbiano il flag sicuro. Ciò garantirà che i browser dell'utente inviino tali cookie solo su connessioni protette da SSL e non li rivelino mai tramite alcun collegamento non SSL (HTTP).
Aggiungi il tuo sito all'elenco dei siti HSTS con hard-coded di Chrome (l' elenco precaricato HSTS ).
Aggiungi la chiave pubblica del tuo sito alla lista di blocco chiave pubblica di Chrome , se ti lasceranno.
Verifica che il server SSL sia configurato correttamente, utilizzando i correttori di configurazione SSL standard, ad esempio Labs SSL .
Assicurati che il tuo certificato sia valido.
Considera l'acquisto di un certificato Extended Validation (EV). Puoi anche menzionare da qualche parte nella sezione di supporto del tuo sito che incoraggi gli utenti a controllare la luce verde nella loro barra degli indirizzi ogni volta che visitano il tuo sito. (Probabilmente questo non sarà molto efficace, ma potrebbe aiutare un po '.)
Considera di fornire un link a Chrome e HTTPS ovunque sul tuo sito web da qualche parte.
Configura il tuo server web su difenditi contro l'attacco BEAST . Abilitare TLS 1.2 è una buona idea, ma puoi anche scegliere attentamente l'ordine delle preferenze degli algoritmi, per proteggere gli utenti i cui browser non supportano ancora TLS 1.2 (che saranno essenzialmente tutti in questo momento).
Se fornisci l'accesso tramite IMAP, assicurati di supportare solo IMAPS (la versione abilitata a SSL), non il testo IMAP trasparente.
Abilita STARTTLS sul server SMTP.
Evita l'uso di widget Javascript di terze parti (es. librerie, widget, pulsanti simili, ecc.). Non caricare contenuti esterni su http.

Non cercherò di evitare l'uso di Javascript. In particolare, non proverei a bloccare l'accesso agli utenti che hanno Javascript abilitato. Questo è un disastro dell'usabilità, per un guadagno di sicurezza minimo o nullo.

Vedi anche Guida per implementatori di siti solo HTTPS (lato server) .

score 0 · Answer 2

Poiché so che tutti i fornitori di DLP (Data Loss Prevention) eseguono il MITM su connessioni SSL in collaborazione con i fornitori Proxy, fuori dalla scatola non c'è davvero nulla che tu possa fare. La debolezza è nel protocollo e non nell'applicazione. Consiglierei di usare una soluzione a due fattori usando qualcosa come Yubikeys, ma non sono sicuro che ciò impedirebbe il dirottamento delle sessioni. Se i certificati possono essere compilati al volo che utilizzerebbero l'OTP che fornisce Yubkikey, potrebbe fare il trucco. SSL / TLS deve essere riscritto per rappresentare MITM.

link