SMTP için şifrelemeyi zorlamak iyi bir fikir midir?

E-posta gönderip alırken, mümkünse TLS kullanmaya ayarlanmış bir e-posta sunucusu çalıştırıyorum.

Bununla ilgili belgeleri okuduğunuzda, TLS'yi zorlama ve e-postaların düz metin iletimini kabul etmeme seçeneği de vardır. Ayrıca, bazı posta sunucularının henüz şifrelemeyi desteklemeyebileceği ve şifrelemeyi zorlamanın bu sunucuları engelleyebileceği konusunda sizi uyarır.

Fakat bu hala bir sorun hakkında düşünmesi gereken bir sorun mu yoksa şifrelemeyi zorlamanın artık bir sorun olmayacağını söylemek güvenli midir?

Muhtemelen bunu yapan bir büyük sağlayıcı var mı, yoksa bugünlerde en iyi uygulamayı ne düşünüyorsunuz?

Pratik sorun, her SMTP uyumlu (RFC oldukça eski) sunucunun sunucunuzla TLS konuşamayacağından, bazı e-posta iletilerini almayı kaçırmanız olabilir.

Bununla ilgili felsefi sorun, e-postanın sunucunuza geldikten sonra (veya daha önce) nasıl iletildiğini söylemenin imkansız olmasıdır.

Bu, e-postanın zaten bir röle aracılığıyla düz metin olarak iletilmiş olabileceği anlamına gelir.

E-postalarının içeriğini korumak konusunda ciddi birileri cesedi şifrelemelidir. Şifrelemeyle yola çıkıldığında her zaman mantıklıdır, halihazırda düz metin olarak iletilmiştir.

Bu nedenle, SMTP katmanında şifrelemeyi zorlama sorunuzu yanıtlamak büyük olasılıkla anlamsızdır, e-posta alma şansınızı artırır ve garanti edilen yararlı bir kazanç yoktur.

Düzenleme: Bu , e-posta gönderimini değil , aktarma amacıyla SMTP zorunluluğunu ifade eder . Posta gönderimlerinde, SMTP konuşması (gerçek e-postayı değil) muhtemelen kimlik doğrulama bilgilerini içerdiğinden şifreleme uygulanmalıdır.

Yok hayır

RFC 821 33 yaşında. Sen olacak STARTTLS notsupporting programlar tarafından geçirilen e-postaları bulun. Bazen eski e-posta göndericileri (örneğin, dahili komut dosyaları), bazen eski olan tam teşekküllü sistemler TLS'yi devre dışı bırakılmış / derlememiş, yeterince entropisi olmayan sistemler olacaktır.

Çok uzun zaman önce giden e-postaların başarısız olduğuna tanıklık ettim çünkü alıcı son, TLS üzerinden SMTP’ye izin verecek şekilde yapılandırılmıştı. Göndericideki bir sorundu (bu yapılandırmayı kullanmamalıydı), ancak bunun olduğunu gösteriyor.

Sadece gelen mesajları sadece elle yapılandırılmış IP adreslerinden kısıtlarım. Kredi kartı işlemciniz STARTTLS başlatmayı başaramazsa, muhtemelen bağlantıyı kesmeyi (ve yerel yöneticiyi sayfa uyar, böylece onları uyarabilir!), Şifrelenmemiş olan (potansiyel olarak hassas) verileri almaktansa tercih edersiniz. Giden iletilerde, daha önce STARTTLS kullanarak bu ana bilgisayara bağlandıysanız, bunu tekrar güvenli bir şekilde yapmak istemeyebilir, bunun yerine potansiyel bir uzlaşma olarak kabul etmek isteyebilirsiniz. Ayrıca, gmail veya yahoo gibi her zaman bilinen bir STARTTLS ana bilgisayar listesine de sahip olabilirsiniz.

Orada https://www.eff.org/starttls-everywhere sen (? Olmalı) güvenle STARTTLS kullanımını zorunlu kılabilir hangi smtp sunucularının listesini temin projesi.

Şifreleme yapamayan akranlardan gelen e-postaları reddetmek tamamen anlamsız ve muhtemelen aktif bir şekilde zararlıdır.

Sunucunuz, sunan herhangi bir eşle fırsatçı şifreleme yapmak üzere ayarlandığı sürece, her iki dünyanın da en iyisini elde edersiniz: kullanılabilir olduğunda şifreleme ve olmadığı zaman düz metin üzerinden e-posta gönderebilirsiniz.

Şifrelemeyi desteklemeyen sunucular olduğu sürece, zorunlu kılmak, sizinle konuşamayacakları anlamına gelir; Bu kötü. Herkes desteklediğinde, fırsatçı ve zorunlu şifreleme arasında bir fark yoktur.

Diğerlerinin de belirttiği gibi, kablosuz şifreleme ve uçtan uca şifreleme, farklı tehdit modellerini ele alan tamamen farklı iki şeydir. İkisini karıştırmayın.

Bu bir politika meselesi.

Genel olarak, TLS gelen ve giden için zorlandığında, bir ihtiyacın karşılanması için taraflarca kararlaştırılan sınırlı bir alan kümesi için yapılır (örneğin, iş ortaklarının şirketleri arasındaki tüm postaları şifrelemek için bir anlaşması olabilir).

Böyle bir anlaşma yapılmadıkça, zorlama modunu açmayın.

Hayır, bu çok kötü bir fikir.

Aslında, ortaya çıktığı üzere, STARTTLS sunucularının / istemcilerinin çoğu, bir TLS bağlantısının anlaşamaması durumunda StartTLS olmadan herhangi bir yeniden deneme algoritması uygulamamaktadır.

Bu nedenle, bir seçenek olarak STARTTLS reklamını yapmak bile zaten e-posta alma (ve gönderme) şansınızı azaltmaktadır!

Tek yapmanız gereken, birçok kişinin * .protection.outlook.com kümesi tarafından işlenen Microsoft Outlook etki alanlarına herhangi bir e-posta gönderememesidir.

TLS kullanırken Microsoft tarafından gönderilen Sendmail mesajları

nedeni: 403 4.7.0 TLS anlaşması başarısız oldu

Yukarıdaki iki mesajda sunulan hususları özetlemek için:

• STARTTLS olsun veya olmasın, Outlook tarafından yönetilenler dışındaki herhangi bir ana bilgisayara herhangi bir posta gönderebilir,
• Outlook'a müşteri sertifikası olmadan ve STARTTLS olmadan posta gönderebilir,
• veya sıfır uzunluklu bir müşteri sertifikası ile,
• ancak Microsoft’un sevmediği bir sertifika ile değil ve başarısız olduklarında, alıcının sunucusu STARTTLS!

Benzer şekilde, ana sunucunuz bir sunucu olarak hareket ettiğinde, STARTTLS'yi etkinleştirmeye karar verirseniz, kontrolünüz dışında da benzer bir durum ortaya çıkabilir - bir istemci sunucusu, sunucu modundayken sunucunuzun STARTTLS'yi sunduğunu gördüğünde, görüşme başarısız olur; , sadece beklerler ve aynı adımları tekrar dener, mesajın gönderene geri gönderilmesi gerekene kadar başarısız olmaya devam edin!

Ve bu, STARTTLS ülkesinde çeşitli alanlarda çok sık gerçekleşir!

Ne yazık ki, geçmişte STARTTLS destekçisi olduğum sürece, fırsatçı şifreleme olduğunu düşündüğüm şeyin risksiz reklamı tarafından yanlış yönlendirildiğim için artık çok hakaret ettim.

Sadece STARTTLS'e gerek duymamanız gerekir, ancak birlikte çalışabilirliği sağlamak istiyorsanız tamamen devre dışı bırakmak bile akıllıca olabilir.

Fırsatçı TLS kullanma fikrine katılıyorum. Yine de, benim de fikre ekleyeceğim bir şeyler var Bazıları önerilerden rahatsız olacak, ancak buradaki önerilerim hafifçe ve dikkate alınmadığı için, karar vermeden önce, lütfen ekteki bağlantıdan tüm tartışmayı okumanızı rica ediyorum.

Fırsatçı TLS'yi kullanmak en iyi çözümdür. Buna karşı bir argüman olarak MITM açısı kırmızı bir ringa balığıdır. Ne de olsa MH'nin bir yorumunda belirtildiği gibi, TLS bağlantısına sahip "okunaklı" bir SMTP bile MITM'd olabilir ve son kullanıcı, posta istemcisinin büyük çoğunluğunun büyük çoğunluğa eşlik eden sertifikaları onaylama zahmetine girmediğinden dolayı akıllıca olamaz. MTA'ların TLS yaptığı, kendinden imzalı sertifikalar kullanıyor (en azından DNSSEC ve TLSA / DANE kullanmıyorsanız). Bu ve muhtemelen diğer faktörlerin bir sonucu olarak, hem sizin hem de dünyanın geri kalanına kadar tartışılabilir. DANE / TLSA ve DNSSEC’i uygulamaya koymuş, fırsatçı TLS’yi çalıştırırken, aynı zamanda isimsiz bir diffell-cehennem adamının (PFS’yi kullanırken) de etkin olmamasından daha iyidir. En azından kısmen, normal gözlemcilere karşı koruyan trafiği hala şifreleyeceği gerçeğinden dolayı. Bu yapılandırmaya daha fazla destek olarak (benimkinden çok daha ayrıntılı bir açıklama ile), lütfen bir posta forumunda bu yazıdaki Viktor Dukhovni'nin yorumlarını okuyun:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Viktor'un diğerlerinin önerilerini neden kabul edebileceğine ilişkin olarak, her iki DNSSEC'ye de IETF taslakları yazmış olmasının yanı sıra, Postfix MTA için DNSSEC, TLSA / DANE kodu yazdı. ve TLSA / DANE. Bu nedenle, konuyla ilgili sözlerinin, muhtemelen çoğundan daha fazla, çok fazla ağırlık taşıdığını söyleyebilirim.

Bu yardımcı olur umarım.

Bir e-posta pazarlaması perspektifinden bakıldığında, TLS kullanımı tüm teslimat zinciri boyunca uygulandığını bildiğiniz zaman iyi bir uygulamadır ve güvenlidir. Ancak, güvenlik en üst gereksiniminiz ise, göndermeden önce e-postayı şifrelemek en güvenli seçenektir (örneğin, PGP ile).