Perché i certificati di convalida estesi non sono utilizzati con la posta elettronica

Question

Perché i certificati di convalida estesi non sono utilizzati con la posta elettronica

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

1

I certificati di convalida estesi sono certificati di identità rilasciati a una persona giuridica. Ciò significa che qualsiasi cosa firmata da quel certificato è "garantita" che provenga dall'entità anziché solo dal nome del dominio.

Poiché le email di phishing sono un grosso problema e (almeno nella mia mente) sembrano essere in crescita in prevalenza, perché le aziende non firmano le email usando questi certificati (e includono la firma come allegato)?

L'infrastruttura di fiducia è già (principalmente) in atto e la verifica potrebbe essere gestita in modo abbastanza trasparente dai client di posta elettronica che utilizzano il sistema operativo o l'archivio dei certificati del browser.

Immagino che questo potrebbe rendere molti dei "ENTRAMBI CREDENZIALI BANCARIE IN 24 ORE ACCOUNT SARANNO CANCELLATI" e-mail e altre e-mail di phishing meglio predisposte, in gran parte inutili per i phisher.

email certificates phishing

posta 21.09.2017 - 17:09

fonte

2 risposte

Leggi altre domande sui tag email certificates phishing

È possibile scrivere un valore superiore a 64 bit utilizzando un attacco di stringa formato (% n)? Accesso diretto alle pagine di amministrazione, il server Web o il server delle applicazioni sono configurati in modo non sicuro

score 1 · Answer 1

Secondo le linee guida EV (SSL) dal 1.6.5 (luglio 2017) da cabforum (avviso: come altri hanno ora "ottimizzato" il loro sito web per mostrare il minor numero possibile di dati, in modo da trovare qualcosa di utile da frugare attraverso il pulldown) nella clausola 1:

This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet and for code signing. Similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions

Sebbene FWIW le linee guida EV non dica nulla su ExtendedKeyUsage, e nei requisiti baseline (incorporati per riferimento) 7.1.2.3f dice che DEVE contenere clientAuth e / o serverAuth e MAGGIO contenere emailProtection. Quindi penso che un membro potrebbe emettere un cert EV includendo e-mail senza violare le regole. OTOH Dubito che qualsiasi software di posta elettronica controlli attualmente EV anche quando supporta X.509 (S / MIME) poiché ciò non è previsto.

Ovviamente c'è il solito problema dell'uovo di gallina; i mittenti di posta elettronica legittimi non vorranno usarlo finché almeno una parte significativa dei destinatari utilizza software di posta elettronica o sistemi che la supportano, e almeno la maggior parte dei destinatari non cercherà nemmeno tale supporto fino a quando nessuno lo invierà. Probabilmente se alcuni grandi giocatori come Gmail lo spingono, potrebbe ottenere un po 'di trazione, nello stesso modo in cui alcuni browser hanno spinto a migliorare la crittografia web / HTTPS.

score 0 · Answer 2

Esistono già oggi metodi di verifica che possono stabilire una connessione sicura tra una e-mail e il suo nome di dominio di invio. Tre di questi sono SPF e DKIM, ma anche S / MIME.

Poiché il sito web e / o un server di posta, residenti nello stesso dominio, possono essere certificati EV, significa che una volta stabilita la connessione, puoi essere sicuro che l'organizzazione ha fatto la richiesta.

L'unica cosa che manca è che il client di posta elettronica debba mostrare il risultato della convalida SPF / DKIM e il nome di dominio associato, in qualche modo promettente all'utente.

L'implementazione di EV per le e-mail aggiungerebbe solo complessità e costi aggiuntivi per le aziende.