Thunderbird'de (ve diğer birçok müşteride de varsayalım) "SSL / TLS" ve "STARTTLS" arasında seçim yapma seçeneğim var.
Anladığım kadarıyla, "STARTTLS" basit kelimeler anlamına gelir "her ikisi de TLS'yi destekliyorsa şifreleyin, aksi halde aktarımı şifrelemeyin". Ve "SSL / TLS" basit kelimeler anlamına gelir "her zaman şifreleyin veya hiç bağlanmayın". Bu doğru mu?
Veya başka bir deyişle:
STARTTLS SSL / TLS'den daha az güvenli midir, çünkü bana haber vermeden düz metne geri dönebilir mi?
SMTP için STARTTLS RFC'ye dayanan cevap (RFC 3207):
STARTTLS TLS'den daha az güvenlidir.
Konuşmayı kendim yapmak yerine, RFC'nin kendi başına konuşmasına izin vereceğim; KALIN:
Ortadaki bir adam saldırısı "250" silerek başlatılabilir
STARTTLS "sunucudan yanıt. Bu, müşteriye neden olmaz
TLS oturumu başlatmaya çalışmak. Bir başka ortadaki adam saldırısı
sunucunun STARTTLS özelliğini duyurmasına izin vermek, ancak değiştirmek için
Müşterinin TLS ve sunucunun yanıtını başlatma talebi. İçinde
Bu tür saldırılara karşı savunmak için hem müşteriler hem de sunucular olmak
yapabilmek başarılı bir TLS müzakeresi gerektirecek şekilde yapılandırılmak
mesajlar önce seçilen ana bilgisayarlar için uygun şifre paketi olabilir
başarıyla aktarıldı. Ilave seçenek TLS kullanarak
olası da sağlanmalıdır. Bir uygulama MAYIS AYI sağlamak
Verilen TLS ile iletişim kurmada kullanabilme yeteneği
Daha sonraki bir oturumda kullanılmadığında eş aktarabilir ve uyarı üretebilir.
TLS anlaşması başarısız olursa veya müşteri bir 454 alırsa
Yanıt, müşterinin ne yapacağına karar vermesi gerekiyor. Üç vardır
ana seçenekler: SMTP oturumunun geri kalanı ile devam edin, [...]
Gördüğünüz gibi, RFC'nin kendisi (çok açık bir şekilde değil, açık bir şekilde), müşterilerin güvenli bir bağlantı kurmasını ve güvenli bir bağlantı kurulamadığında kullanıcıları bilgilendirmesini gerektiren bir durum olmadığını belirtir. O açıkça istemcilere sessizce kurma seçeneği sunar Düz metin bağlantıları.
İki seçenek arasındaki güvenlikte bir fark yoktur.
-
SSL / TLS önce bir SSL / TLS bağlantısı açar, ardından SMTP işlemini başlatır. Bu, halihazırda çalışan bir SSL / TLS SMTP sunucusuna sahip olmayan bir bağlantı noktasında gerçekleşmelidir; Protokollerin yapısı gereği hem düz metin hem de şifrelenmiş bağlantıları ele almak için tek bir port yapılandırmak mümkün değildir.
-
STARTTLS, SMTP işlemini başlatır ve EHLO'ya yanıt olarak TLS'nin diğer ucundan destek arar. İstemci desteklenen komut listesinde STARTTLS görürse, STARTTLS gönderir ve şifreleme için pazarlık yapmaya başlar. Tüm bunlar (ve genellikle) standart SMTP portunda (25), kısmen geriye dönük uyumluluk için olabilir, fakat aynı zamanda hem destekleyici hem de zorunlu olarak gerektirmeyen uç noktalar arasında fırsatçı şifrelemeye olanak sağlar.
Genellikle, SSL / TLS sadece son istemciler ve sunucular arasında kullanılır. STARTTLS, sunucu arası taşımayı güvenli hale getirmek için MTA'lar arasında daha sık kullanılır.
Bu iki uygulama göz önüne alındığında, STARTTLS, kullanıcının veya yöneticinin, bağlantının şifrelenmiş olduğunu varsayıyorsa, ancak şifreleme gerektirecek şekilde yapılandırılmamışsa, güvensiz olarak yorumlanabilir. Bununla birlikte, kullanılan şifreleme SSL / TLS ile tam olarak aynıdır ve bu nedenle bu tür yapılandırma hatasının ötesine geçen bir Man-in-the-Middle saldırısına karşı daha fazla veya daha az savunmasız değildir.
Özellikle e-posta için Ocak 2018'de RFC 8314 "Paylaşılan TLS" nin, IMAP, POP3 ve SMTP gönderimleri için STARTTLS mekanizmasının tercihinde kullanılmasını açıkça tavsiye eden bir sürüm yayınlandı.
Özetle, bu not şu anda şunları önermektedir:
- MUA'lar arasındaki tüm trafik için TLS sürüm 1.2 veya üstü kullanılır
Posta Gönderim Sunucuları ve ayrıca MUA'lar ve Mail Access arasında
Sunucular.
- MUA'lar ve Posta Servis Sağlayıcıları (MSPs) (a) kullanımından vazgeçirmek
posta erişimi ve posta gönderimi için cleartext protokolleri ve
(b) bu amaçlarla açık metin protokollerinin kullanımını reddetme
en kısa zamanda uygulanabilir.
- Posta Gönderim Sunucularına ve Posta Erişim Sunucularına Bağlantılar
"Örtülü TLS" kullanılarak yapılan (aşağıda tanımlandığı gibi), tercihe göre
"cleartext" bağlantı noktasına bağlanmak ve TLS'yi kullanarak
STARTTLS komutu veya benzer bir komut.
(vurgu eklenmiştir)
Cevap, "güvenli" ile ne demek istediğine bağlı.
İlk olarak, özetiniz SSL / TLS ve STARTTLS arasındaki farkı tam olarak yakalamıyor.
- SSL / TLS ile istemci, kullanmak istediği uygulama protokolüne atanan "SSL portu" na bir TCP bağlantısı açar ve TLS'yi hemen konuşmaya başlar.
- STARTTLS ile istemci, kullanmak istediği uygulama protokolüyle ilişkili "temiz metin bağlantı noktası" na bir TCP bağlantısı açar, ardından sunucudan "hangi protokol uzantılarını destekliyorsunuz?" Diye soruyor. Sunucu daha sonra bir uzantı listesiyle yanıt verir. Bu uzantılardan biri "STARTTLS" ise, müşteri "tamam, TLS kullanalım" ve iki TLS konuşmaya başlayabilir.
Eğer müşteri TLS gerektirecek şekilde konfigüre edilmişse, iki yaklaşım daha az veya eşit derecede güvenlidir. Ancak, STARTTLS'nin güvenli hale getirmek için nasıl kullanılması gerektiğine dair bazı incelemeler var ve bu ayrıntıların doğru bir şekilde elde edilmesi için STARTTLS uygulamasının uygulanması biraz daha zor.
Diğer taraftan, müşteri TLS kullanılabilir olduğunda TLS'yi kullanacak şekilde yapılandırılmışsa ve TLS kullanılamıyorsa cleartext kullanırsa, istemcinin yapacağı şey ilk olarak protokol tarafından kullanılan SSL portuna bağlanmayı dener. başarısız olur, ardından cleartext bağlantı noktasına bağlanın ve STARTTLS'yi kullanmaya çalışın ve her iki durumda da TLS'nin mevcut olmaması durumunda net metinlere geri dönün. Bir saldırganın SSL port bağlantısının başarısız olmasına neden olması oldukça kolaydır (tek yapmanız gereken bazı iyi zamanlanmış TCP RST paketleri veya SSL portunun bloke edilmesidir). Bir saldırganın STARTTLS görüşmesini yenmesi ve trafiğin net metin olarak kalmasına neden olması biraz daha zor - ama birazcık daha zor. Ve sonra saldırgan sadece e-postanızı okumakla kalmaz, aynı zamanda ileride kullanmak için kullanıcı adınızı / şifrenizi de yakalar.
Bu nedenle, basit cevabı, TLS'yi zaten bildiğiniz bir sunucuya bağlanıyorsanız (e-posta gönderdiğinizde veya e-posta gönderdiğinizde olduğu gibi), SSL / TLS kullanmalısınız. Bağlantıya saldırıya uğrarsanız, bağlantı girişimi başarısız olur, ancak şifreniz ve e-posta adresiniz ele geçirilmeyecektir.
Öte yandan, TLS'yi destekleyip desteklemediğini bilmediğiniz bir hizmete bağlanıyorsanız, STARTTLS marjinal olarak daha iyi olabilir.
STARTTLS icat edildiğinde, "pasif" yalnızca dinleme saldırıları çok yaygındı, saldırganın güvenliği azaltmak için trafiği enjekte ettiği "aktif" saldırılar daha az yaygındı. O zamandan beri 20 yıl içinde, aktif saldırılar daha uygulanabilir ve daha yaygın hale geldi.
Örneğin, bir havaalanında veya başka bir halka açık yerde bir dizüstü bilgisayar kullanmaya çalışıyorsanız ve postanızı orada sağlanan kablosuz bağlantı üzerinden okumaya çalışıyorsanız, bu kablosuz ağın trafiğinizle ne yaptığına dair hiçbir fikriniz yoktur. Wifi ağlarının, istemci uygulamalarınız ve konuşmaya çalıştıkları sunucular arasında kendilerini birbirine bağlayan "proxy'lere" belirli trafik türlerini yönlendirmek çok yaygındır. İstemcinin net metni geri almasını sağlamak için proxy'lerin hem STARTTLS'yi hem de "bir bağlantı noktasını daha sonra deneyin" özelliğini devre dışı bırakması önemsizdir. Evet, bu olur ve bu, trafiğinizin bir ağ tarafından nasıl gizlenebileceğinin sadece bir örneğidir. Ve bu saldırılar üç harfli devlet destekli kurumlarla sınırlı değil, bir yerde halka açık bir yerde saklanan 35 dolarlık bir bilgisayarla bir genç tarafından çekilebilir.
Evet, temel haklarınız var. Ve evet, STARTTLS kesinlikle daha az güvenli. Bildirimde bulunmadan sadece düz metin olarak yazılması için değil, aynı zamanda ortadaki saldırılara maruz kaldığı için. Bağlantı net olarak başladığından, bir MitM, STARTTLS komutunu çıkarabilir ve şifrelerin oluşmasını engelleyebilir. Ancak, mailservers'ın aktarımların sadece şifrelenmiş bir tünel kurulduktan sonra gerçekleştiğini belirtebileceğine inanıyorum. Böylece bu konuda çalışabilirsiniz.
Öyleyse neden böyle bir şey var? Uyumluluk nedeniyle. Her iki taraf da şifrelemeyi desteklemiyorsa, bağlantının düzgün bir şekilde tamamlanmasını isteyebilirsiniz.
@Greg ile katılıyorum. Bu saldırılar mümkün. Ancak MTA'lar, "fırsatçı TLS" yerine "zorunlu TLS" kullanmak için (MTA'ya bağlı olarak) yapılandırılabilir. Bunun anlamı, e-posta işlemleri için TLS ve sadece TLS'nin kullanılmasıdır (buna ayrıca STARTTLS dahildir). Uzak MTA STARTTLS'yi desteklemiyorsa, e-posta geri döndürülür.
Hayır o değil Uygulamanız doğru şekilde işlendiğinde daha az güvenlidir.
TLS işlemek için dört yol vardır ve birçok program seçmenize izin verir:
- TLS yok
- Özel limanda TLS (sadece TLS'yi dener)
- Varsa TLS kullanın (Denemeler
starttls, başarısız olduğunda şifresiz bir bağlantı kullanır.)
- Her zaman TLS kullanın (Kullanımlar
starttls çalışmazsa ve başarısız olursa)
TLS'nin özel bir bağlantı noktasındaki avantajı, henüz bilmediğiniz bir programı kullandığınızda veya ilk başlangıç sihirbazında hata işleme ayrıntı ayarlarını göstermediğinizde herhangi bir geri dönüş olmadığından emin olmanızdır.
Ancak genel olarak güvenlik, güvenlik hatalarının ele alınmasına bağlıdır. TLS Portundaki TLS de başarısız olduğunda bir program düz metin bağlantı noktasına geçmeye karar verebilir. Ne yapacağını bilmeli ve güvenli ayarları seçmelisin. Programlar güvenli varsayılanları kullanmalıdır.