Posta sunucuları arasındaki e-posta aktarımları neden genellikle şifrelenmiyor?


19

Kullanıcılar genellikle güvenli bir kanal (ör. HTTPS kullanarak ) kullanarak e-posta sağlayıcılarına (Gmail gibi) erişmek isteyip istemediklerini seçebilirler .

Ancak, bildiğim kadarıyla, posta-sunucu-posta-sunucu iletişimi söz konusu olduğunda, e-postaların çoğu hala düz metin olarak aktarılır ve şifrelenmez, bu da ağdaki herhangi birinin içeriğini okumasını mümkün kılar.

Kullanıcıya e-postalarının uçtan uca güvenli bir şekilde gönderilmesini garanti eden teknolojiler var mı? Neden şifrelemenin desteklenmediğini kullanıcıya bildirmiyor ve e-postasının hala teslim edilmesini isteyip istemediğini seçmiyor?

Yanıtlar:


19

Ancak, bildiğim kadarıyla, posta-sunucu-posta-sunucu iletişimi söz konusu olduğunda, e-postaların çoğu hala düz metin olarak aktarılır ve şifrelenmez, bu da ağdaki herhangi birinin içeriğini okumasını mümkün kılar.

Doğru. SMTP, HTTP gibi, varsayılan olarak düz metindir.

Bugünlerde birçok posta sunucusu SMTP için TLS'yi (daha önce SSL olarak biliniyordu) desteklemektedir . (Buna Gmail de dahildir.) Bununla birlikte, HTTP [S] ile aynı sorunlara sahiptir: iyi bilinen CA'lar tarafından verilen sertifikaların maliyeti yüksektir ve kendinden imzalı olanlar MitM saldırılarına karşı koruma için değersizdir 1 . Posta sunucunuz alıcının sertifikasını (web tarayıcılarının yaptığı gibi) katı bir şekilde doğrularsa, kendinden imzalı sertifikalar veya şirket içi CA'lar kullanan sunuculara ileti teslim edemeyebilir. O Eğer değil , o zaman bunun doğru sunucu ve değil konuşurken emin olamaz Sahtekar .

Ayrıca, TLS, SMTP için nispeten yeni bir eklentidir, bu nedenle alıcının posta sunucusu TLS'yi desteklese bile, gönderen gönderemeyebilir veya varsayılan olarak devre dışı bırakılmış olabilir.

1 (Gönderen sunucu DANE'yi (TLSA) desteklemiyorsa ve alıcı sunucunun yöneticisi TLSA kayıtlarını DNS'de yayınlamak istemiyorsa. Bu nadiren yapılır ve biraz sıkıcıdır.)

Kullanıcıya e-postalarının uçtan uca güvenli bir şekilde gönderilmesini garanti eden teknolojiler var mı?

En yaygın iki e-posta güvenlik standardı:

  • OpenPGP , güven ve kullanımı ücretsiz web tabanlı. Açık kaynak uygulamasıdır GnuPG ( Windows için , Thunderbird için ) ve orijinal PGP ticari dönüştü PGP Desktop .

    Web tabanlı e-posta istemcileri için FireGPG bir olasılıktır - lanet olsun

  • X.509 altyapısına dayalı S / MIME . Çoğu masaüstü istemcisi (Outlook, Thunderbird, Mail.app dahil) tarafından uygulanır. Bununla birlikte, TLS / SSL ile aynı otorite tabanlı yapı nedeniyle nispeten popüler olmayan: imzalı sertifikaların maliyeti yüksektir ve kendinden imzalı olanlar güvenilir bir şekilde doğrulanamaz.

Her iki durumda da şifreleme , alıcının sistemi zaten kullanıyor olması ve bir anahtar çifti oluşturmuş / elde etmiş olmasını gerektirir. ( İmza için gönderenin anahtar çifti kullanılır. Normal uygulama, mesajları hem imzalamak hem de şifrelemektir.)

Neden şifrelemenin desteklenmediğini kullanıcıya bildirmiyor ve e-postasının hala teslim edilmesini isteyip istemediğini seçmiyor?

Genellikle gönderilen mesajlar kuyruğa alınır ve ne kullanıcı ne de MTA, bir sonraki sekmenin TLS'yi destekleyip desteklemediğini bilemez - mesaj gönderilinceye kadar kullanıcıdan onay istemenin güvenilir bir yolu yoktur. (AFK, çevrimdışı, uykuda veya bir komut dosyası / program olabilirler. Mesajı gönderirsem en kısa zamanda teslim edilmesini istiyorum.)

Ayrıca, SMTP ile bir sonraki sekmenin nihai olup olmadığını veya postayı başka bir yere aktarıp aktarmayacağını asla bilemezsiniz. Yedek MX'in tamamen farklı bir ağda olması nadir değildir.

Bu nedenle. uçtan uca güvenlik ancak her iki taraf da OpenPGP veya S / MIME kullanıyorsa mümkündür.


2
Not: Hem soru hem de cevabım, 25 numaralı bağlantı noktası üzerinden iki SMTP sunucusu arasındaki posta alışverişiyle ilgilidir. 587 veya 465 numaralı bağlantı noktalarında TLS desteği olup olmadığı önemli değildir ; bunlar yalnızca [uzak] bir kullanıcının mesaj göndermesi içindir.
Kullanıcı1686

2
Anladığım kadarıyla SMTP bağlantısından daha sık şifrelenmedi. Ancak, ücretsiz e-posta sertifikalarını buradan alabilirsiniz (doğrulayan): instantssl.com/ssl-certificate-products/…
Andee

Güncelleme: Bir alıcının alanı ne zaman bugünlerde Gmail'in arayüzü sizi uyarır değil şifrelemeyi destekleyen ve talimatlar gizli bilgileri gönderirken dikkatli olmak öneririz.
Blaisorblade

4

Gerçek e-posta trafiği genellikle şifrelenir (TLS), ancak başka sorunlar da vardır:

  • HTML mesajları gösteren bazı web posta istemcileri HTTPS kullanmasına rağmen güvenli olmayabilir, örneğin HTML'deki kod ve veriler arasında sabit bir ayrım yoktur (görsel öğeler ve javascript -> enjeksiyon saldırıları)

    • webmail ayrıca e-postayı yerel bilgisayara indirmek ve depolamak yerine sunucuda tutar
  • Her adım arasında TLS / SSL kullanılıp kullanılmadığını bilmenin hiçbir yolu yoktur, çok küçük sunucular uygun sertifikalara sahip DEĞİLDİR

    • gönderenin en azından güvenli olmayan kanalı kullanarak e-postayı göndermeyi kabul edip etmemeyi belirleyebilmesi gerekir
  • E-postalar, sunucu tarafından şifrelenmemiş veya şifrelenmemiş sunucularda yatıyor

    • siz ve alıcı arasında HER sunucuya güvenmeniz gerekecek
  • E-postalar herhangi bir rota kullanılarak aktarılabilir, hangi sunuculara güvendiğinizi belirtemezsiniz (IP adresi aralıkları, AS'ler, ülkeler, alanlar ..)

  • Büyük e-posta sunucuları birden fazla farklı sertifika kullanmaz ve bunları yeterince sık değiştirmez (?)

    • Onları kaba kuvvetlendirmek belki de değer / olasıdır (ABD / İngiltere vb denedi mi?)
  • e-postanın ne zaman gönderildiğini ve alıcı hakkında bir şey (sunucuların birbirleriyle iletişim kurduğu) takip ederek trafiği izleyerek

    • darknets bu korelasyonları gizler
  • openssl uygulaması bir karışıklıktı

    • belki hatalar var
  • sertifikaları imzalayan sertifika yetkililerine güvenmelisiniz


2

Onlar. Ya da çok sık.

SSL veya TLS yoluyla .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Ya da gerçekten paranoyaksanız PGP veya GPG var.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.