Non sono un crittografo. Forse è per questo che non vedo i problemi con l'integrazione di PGP in SMTP.
Nella mia testa: Lea richiede al server del dominio di Luke jedi.com di dirle la chiave pubblica di [email protected] (La richiesta include forse un metodo di crittografia). Riceve la chiave PUBLIC . Quindi crittografa il messaggio e Luke può decodificarlo facilmente.
Non è così difficile, perché non è standard per anni?
It's not that hard, why isn't it standard for years?
Perché ciò non avrebbe risolto il problema che PGP sta cercando di risolvere.
PGP è una crittografia end-to-end, quindi se c'è un modo per il server SMTP di sovvertire la crittografia, allora lo schema fallisce.
Nel caso dello schema che hai proposto, supponi che Alice ([email protected]) voglia inviare un messaggio privato a Bob ([email protected]). Usando lo schema che hai proposto, il client di posta di Alice o il server SMTP di Alice recupera la chiave pubblica di Bob effettuando la connessione TLS a dave.com. Questo va bene fintanto che dave.com è onesto e in effetti restituisce la chiave pubblica di Bob. Ma dave.com avrebbe potuto essere configurato dall'operatore di dave.com per restituire una chiave pubblica falsificata creata da Eve, oppure Eve potrebbe hackerare su dave.com e configurarlo. Ora il client di posta / server di posta di Alice accetterebbe felicemente il certificato di Eve, pensando che la chiave pubblica sia quella di Bob. In questo modello, l'operatore di dave.com può intercettare qualsiasi e-mail di Bob.
Ora, finché dave.com è onesto, questo protegge ancora contro lo spoofing di terze parti. Perché non lo facciamo comunque se questo protegge almeno contro lo snooping di terze parti? Soprattutto perché SMTPS offre anche lo stesso livello di protezione, pur essendo molto più semplice. Se MITM dall'operatore del server di posta non è il tuo problema, puoi già proteggere molto bene le tue e-mail assicurandoti che entrambi utilizzino SMTPS.
Si noti che la difficoltà della crittografia end-to-end non riguarda il recupero delle chiavi pubbliche. La maggior parte del client di posta elettronica che supporta PGP supporta anche il recupero automatico delle chiavi pubbliche da LDAP o HPKP. La difficoltà della crittografia end-to-end è la verifica delle chiavi pubbliche.
Non esiste un metodo noto di verifica delle chiavi pubbliche che sia completamente trasparente per gli utenti e completamente sicuro. Il modello Web of Trust o Certificate Authority si avvicina di più, ma Web of Trust viene fornito con molti avvertimenti e il modello di autorità di certificazione si basa su una terza parte per effettuare la verifica.
integrating PGP into SMTP.
PGP è un formato contenitore per dati (come mail ma non limitato a mail), che aggiunge crittografia e / o firma ai dati. SMTP è un protocollo di trasporto.
Non si integrano i formati contenitore nei protocolli di trasporto. Questo equivarrebbe a dire che dovresti integrare Office (contenitore per testo, immagini ...) con SMTP (trasporto) per inviare un documento di Office a qualcuno.
PGP viene anche usato al di fuori di SMTP, perché è solo un contenitore. E SMTP viene anche utilizzato per trasportare cose diverse dai contenitori PGP, perché è solo un protocollo di trasporto.
Se invece chiedi informazioni sull'integrazione della crittografia end-to-end come PGP o S / MIME in SMTP, non funzionerà, perché SMTP è hop-by-hop delivery e non end-to-end. A parte questo, SMTP non copre nemmeno l'ultimo hop, cioè la consegna dall'ultimo server di posta al client. Questo viene fatto con protocolli come POP o IMAP.
Lea requests the server of Luke's domain jedi.com to tell her the public key of [email protected] ...
Questo è ciò che hai per te server chiave o altri tipi di directory centrali. Ma come fa Lea a sapere che questa è in realtà la chiave di Luke e non la chiave di qualcuno che afferma di essere Luke? Quindi è necessario avere una certa propagazione della fiducia, ad esempio sotto forma di una rete di fiducia (PGP) o una struttura più centralizzata (S / MIME) o affidandosi a tutto in una specifica directory centrale.
Pertanto, l'attività non consiste nell'integrazione di PGP con SMTP ma di un miglior supporto per PGP nei client di posta, in modo che recuperino automaticamente le chiavi PGP dei destinatari. Ma ovviamente ci deve essere prima una chiave PGP verificabile per il destinatario da qualche parte su un server delle chiavi o altra directory, quindi l'altra operazione è rendere più semplice la creazione, la pubblicazione e la gestione delle chiavi (rinnovo, revoca ...). Queste sono tutte cose al di fuori dello stesso mail delivery (SMTP).
Scrivere uno standard è facile. Ho pensato a questo problema circa dieci anni fa. Si riduce al fattore umano / costo. Come convincere un miliardo di persone tecnologicamente analfabete ad aggiornare il proprio software senza alcun beneficio percepito e convincere le migliaia di sviluppatori su una manciata di piattaforme per implementare questo protocollo e milioni di organizzazioni a passare a un nuovo protocollo, anche se darlo via . Abbiamo esaurito i nostri indirizzi IPv4 in alcune parti del mondo già nel 2011, eppure Internet non usa ancora IPv6 a livello globale. Non possiamo nemmeno convincere la gente a passare a IPv6 nonostante il fatto che stiamo letteralmente soffocando la crescita di Internet. Anche se oggi potessi estrarre uno standard e inviarlo a IETF per essere formalizzato e distribuito, sarebbe 2030 prima che fosse abbastanza diffuso per arrestare gli innumerevoli server di posta "classici" attualmente in esecuzione.
La crittografia è già attiva durante il transito della posta ( STARTTLS in SMTP), ma non abbastanza sofisticata da proteggere contro MITM.
Credo che PGP sia più un'esperienza dell'utente finale tra i client di posta, il che è utile se non si ha piena fiducia dei server coinvolti.
(PGP è a volte sensibile al MITM per l'utente meno che attento, tuttavia, come in SSH, se si controlla la firma della chiave corretta, allora quel problema è risolto)
Tuttavia, nel caso di servizi di posta elettronica basati su cloud come Gmail, dovrebbero comunque essere disponibili per il server per una buona esperienza utente, quindi PGP potrebbe semplicemente intromettersi.
Speriamo che un giorno otterremo una crittografia MITM proof in SMTP, ma è meno un problema lì perché i server di posta sono su reti controllate.
Bene, come puoi leggere sopra puoi usare SMTPS e STARTTLS per rafforzare la sicurezza dei server SMTP durante l'invio di e-mail. MITM può essere mitigato con DKIM.
DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit. The organization is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for further handling, such as delivery. Technically DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication.
In breve, DKIM ti consente di identificare se le e-mail provengono dall'origine che l'intestazione della mail dice che proviene. Dove il server può quindi decidere in modo affidabile se il messaggio può essere considerato attendibile (se l'autenticazione DKIM fallisce, è possibile eliminare la posta e non preoccuparsi se un messaggio falsificato ottiene il server SMTP in un elenco di spam).
E quel tipo di round il cerchio. Con l'autenticazione protetta STARTTLS è possibile connettersi in modo affidabile a un server SMTP e inviare la posta a un server di posta. DKIM può identificare se un determinato server SMTP è autorizzato a inviare messaggi da un determinato indirizzo. TLS per il recapito della posta dalla serveria SMTP al server di posta per crittografare la connessione. STARTTLS tra client di posta e server di posta (a meno che non sia un client webmail, quindi una connessione socket sicura tramite POP o IMAP può essere sufficiente)