POP3 ve IMAP Güvenliği: TLS, Portlar ve Kimlik Doğrulama
POP3 (Post Office Protocol version 3) ve IMAP (Internet Message Access Protocol), e-posta kutusundaki iletilere erişmek için kullanılan iki farklı standarttır. Güvenli bir yapılandırmada temel amaç, istemci ile e-posta sunucusu arasındaki bağlantıyı kullanıcı adı ve parola henüz gönderilmeden önce TLS ile şifrelemek, sunucu sertifikasını doğrulamak ve kimlik doğrulamayı korunan kanal içinde tamamlamaktır.
IMAP genellikle iletileri sunucuda tutup birden fazla cihaz arasında eşitler. POP3 ise iletileri istemciye indirir ve yapılandırmaya bağlı olarak sunucudaki kopyaları silebilir. Bu kullanım farkı verinin nerede saklandığını değiştirir; ancak her iki protokol de aynı TLS, sertifika doğrulaması ve hesap güvenliği ilkelerine ihtiyaç duyar.
TLS yalnız istemci ile e-posta erişim sunucusu arasındaki aktarımı korur; e-postayı uçtan uca veya depolama sırasında kendiliğinden şifrelemez. E-posta sunucusunda saklanan iletilerin, yerel cihazdaki dosyaların veya ele geçirilmiş bir hesabın güvenliği ayrıca ele alınmalıdır.
POP3 ve IMAP'te TLS ve Kimlik Doğrulama Koşulları
- IMAP erişiminde bağlantının başından itibaren TLS kullanan 993 numaralı port tercih edilir.
- POP3 erişiminde bağlantının başından itibaren TLS kullanan 995 numaralı port tercih edilir.
- İstemci sertifika zincirini, geçerlilik süresini ve sertifikadaki sunucu adını doğrulamalıdır.
- Kimlik bilgileri TLS kurulmadan gönderilmemeli, şifrelenmemiş bağlantıya geri dönüş kabul edilmemelidir.
- Hizmet destekliyorsa ana parolayı istemciye vermeden yetkilendirme belirteci kullanan OAuth tabanlı oturum açma ve çok faktörlü kimlik doğrulama tercih edilmelidir. Uygulama parolası, yalnız e-posta hizmeti sağlayıcısının eski istemciler için sunduğu bir seçenekse kullanılmalıdır.
POP3 ile IMAP Arasındaki Güvenlik Farkları
POP3 ile IMAP arasındaki temel fark şifreleme yöntemi değil, posta kutusunun kullanım modelidir. Doğru TLS ve kimlik doğrulama ayarları uygulandığında iki protokol de aktarım sırasında güvenli olabilir; riskin önemli bir bölümü iletilerin sunucuda mı, istemci cihazında mı tutulduğuna bağlıdır.
Aşağıdaki karşılaştırma, protokol seçiminin güvenlik ve veri yönetimi açısından neyi değiştirdiğini gösterir.
| Karşılaştırma Konusu | IMAP | POP3 |
|---|---|---|
| İleti saklama modeli | İletiler çoğunlukla sunucuda kalır ve klasör durumu eşitlenir. | İletiler istemciye indirilir; sunucudaki kopya ayara göre tutulabilir veya silinebilir. |
| Çoklu cihaz kullanımı | Okundu, silindi ve taşındı durumu cihazlar arasında daha kolay eşitlenir. | Birden fazla cihazda yinelenen indirme veya eksik ileti görünümü oluşabilir. |
| Başlıca veri riski | Sunucu hesabı ve merkezi posta kutusu daha uzun süre değerli hedef olarak kalır. | Yerel cihaz, posta dosyaları ve yedekler daha fazla veri taşıyabilir. |
| Önerilen TLS bağlantısı | 993 portunda örtük TLS ve geçerli sertifika doğrulaması kullanılmalıdır. | 995 portunda örtük TLS ve geçerli sertifika doğrulaması kullanılmalıdır. |
Bu nedenle IMAP otomatik olarak POP3'ten daha güvenli, POP3 de otomatik olarak IMAP'ten daha güvenli değildir. Sunucu hesabının korunması, istemci cihazının disk şifrelemesi, yedeklerin güvenliği ve iletilerin saklama süresi birlikte değerlendirilmelidir.
993 ve 995 Portları Ne Anlama Gelir?
IMAP için 993 ve POP3 için 995, TLS el sıkışmasının bağlantı kurulur kurulmaz başladığı örtük TLS portlarıdır. İstemci önce şifreli kanalı kurar, sertifikayı doğrular ve ancak bundan sonra IMAP veya POP3 komutları ile kimlik bilgilerini iletir.
“IMAPS” ve “POP3S” ifadeleri, uygulamalarda bu güvenli kullanım biçimini anlatmak için yaygın olarak kullanılır. Bunlar farklı posta kutusu protokolleri değildir; IMAP veya POP3'ün bağlantının başından itibaren TLS içinde çalıştırılmasıdır.
110 numaralı port POP3, 143 numaralı port ise IMAP için geleneksel açık bağlantı portlarıdır. Kurulmuş açık bağlantı, IMAP'te STARTTLS veya POP3'te STLS komutuyla sonradan TLS'e yükseltilebilir; ancak istemcinin bu yükseltmeyi zorunlu tutması, sertifikayı doğrulaması ve TLS kurulamazsa bağlantıyı tamamen kesmesi gerekir. IETF (Internet Engineering Task Force) standardı RFC 8314, e-posta istemci erişiminde açık metin kullanımını artık uygun kabul etmez ve örtük TLS kullanımını öne çıkarır.
Port numarası tek başına güvenlik kanıtı değildir. 993 veya 995 kullanılsa bile sertifika doğrulaması kapalıysa, eski TLS yapılandırmaları açıksa ya da istemci uyarıları yok sayıyorsa bağlantı beklenen korumayı sağlamaz.
TLS ve Sertifika Doğrulaması Nasıl Çalışır?
İlk tam TLS görüşmesinde sunucu sertifikasını ve gerekli sertifika zincirini sunar. İstemci, sertifikanın güvenilir bir sertifika otoritesine dayanıp dayanmadığını, süresinin geçerli olup olmadığını ve bağlanılan sunucu adının sertifikada yer alıp almadığını denetler.
TLS görüşmesi başarıyla tamamlandığında sonraki trafik, istemci ile sunucunun bu süreçte oluşturduğu ortak anahtarlarla şifrelenerek taşınır. E-posta erişim sunucuları TLS 1.2'yi desteklemeli, TLS 1.3'ü de destekleyip görüşmede öncelemelidir. SSL 2.0 ve 3.0 ile TLS 1.0 ve 1.1 sürümleri görüşülmemelidir. Bu sınırlar, güncel genel TLS güvenlik önerilerini içeren RFC 9325 ile uyumludur.
Yanlış sunucu adı, süresi dolmuş sertifika, eksik ara sertifika zinciri veya güvenilmeyen sertifika otoritesi bağlantı uyarısına yol açabilir. Sertifika uyarısı yok sayılmamalı; yanlış sertifika veya sunucu adı düzeltilmelidir. Kurum içi sertifika otoritesi kullanılıyorsa ilgili kök sertifika yalnız yönetilen cihazlara güvenli biçimde dağıtılmalıdır.
Posta sunucusuna IP adresiyle bağlanmak da ad eşleşmesi hatası oluşturabilir. Sertifikada ilgili IP adresi açıkça tanımlı değilse istemci doğrulamayı geçemez; bu nedenle e-posta hizmeti sağlayıcısının verdiği tam sunucu adı kullanılmalıdır.
POP3 ve IMAP Hesaplarında Kimlik Doğrulama
Kullanıcı adı ve parola, doğrulanmış bir TLS kanalı içinde gönderildiğinde ağ üzerinde okunabilir açık metin olarak taşınmaz. Bununla birlikte parolanın yeniden kullanılması, zayıf seçilmesi veya istemci cihazından çalınması TLS tarafından önlenmez.
E-posta hizmeti destekliyorsa OAuth tabanlı oturum açma, istemcinin ana parola yerine erişim belirteci kullanmasını sağlar. Çok faktörlü kimlik doğrulama etkin hesaplarda eski istemciler doğrudan çalışmayabilir; e-posta hizmeti sağlayıcısı bu amaçla uygulama parolası sunabilir veya yalnız modern kimlik doğrulamayı kabul edebilir. Uygulama parolası ikinci faktör sağlamaz; ana paroladan farklı, yalnız ilgili istemciye özgü ve gerektiğinde iptal edilebilir olmalıdır.
PLAIN veya LOGIN gibi mekanizma adları, bağlantının mutlaka şifresiz olduğu anlamına gelmez; ancak bu yöntemler kimlik bilgilerini kendileri şifrelemez. Base64 gibi metin kodlamaları da güvenlik sağlamaz. Bu nedenle kimlik bilgileri yalnız doğrulanmış TLS kanalı içinde kabul edilmeli; sunucu TLS kurulmadan kimlik doğrulamaya izin vermemelidir. İstemci de bağlantı hatasında şifresiz moda geri dönmemelidir.
Sunucu tarafında başarısız oturum açma denemeleri sınırlandırılmalı, olağan dışı kaynaklardan gelen girişler izlenmeli ve kullanılmayan hesaplar kapatılmalıdır. İstemci tarafında parolalar düz metin dosyalarda tutulmamalı; işletim sisteminin güvenli kimlik bilgisi deposu kullanılmalıdır.
Eski Açık Metin Yapılandırmalarının Riski
POP3'ün 110, IMAP'in 143 portunda TLS olmadan kullanılması kullanıcı adı, parola, ileti başlıkları ve e-posta içeriğinin ağ yolundaki bir saldırgan tarafından okunmasına veya değiştirilmesine neden olabilir. Risk yalnız halka açık Wi-Fi ağlarıyla sınırlı değildir; güvenilmeyen yerel ağlar, hatalı ara cihazlar veya ele geçirilmiş ağ bileşenleri de trafiğe erişebilir.
IMAP'te STARTTLS, POP3'te STLS ile yapılan TLS yükseltmesinin isteğe bağlı bırakılması ayrı bir düşürme riski oluşturur. İstemci, TLS'e geçemediğinde bağlantıyı sürdürürse saldırgan yükseltmeyi engelleyip oturumu açık metinde bırakabilir. Güvenli davranış, TLS kurulamıyorsa kimlik doğrulamayı başlatmamak ve bağlantıyı sonlandırmaktır.
Eski istemciler ayrıca güncel TLS sürümlerini, sertifika zincirlerini veya modern kimlik doğrulamayı desteklemeyebilir. Böyle bir durumda sunucunun güvenlik seviyesini düşürmek yerine istemciyi güncellemek veya desteklenen başka bir istemciye geçmek gerekir.
E-posta İstemcisinde POP3 ve IMAP Güvenlik Ayarları
- E-posta hizmeti sağlayıcısının verdiği tam sunucu adını kullanın; yalnız IP adresi veya rastgele bir takma ad girmeyin.
- IMAP için 993 ve POP3 için 995 portunu seçin; güvenlik türünü “SSL/TLS” veya uygulamadaki örtük TLS karşılığı olarak ayarlayın. Birçok uygulamada bu etiket örtük TLS anlamına gelir; eski SSL sürümlerinin kullanılmasına izin verilmemelidir.
- Sertifika doğrulamasını açık tutun; ad uyuşmazlığı, süresi dolmuş sertifika veya güvenilmeyen otorite uyarılarını görmezden gelmeyin.
- E-posta hizmeti sağlayıcısının istediği kullanıcı adı biçimini ve desteklenen kimlik doğrulama yöntemini kullanın.
- Çok faktörlü kimlik doğrulama etkinse önce OAuth gibi modern oturum açma yöntemini kullanın. İstemci bunu desteklemiyorsa ve e-posta hizmeti sağlayıcısı uygulama parolası sunuyorsa bu yöntemi yalnız gerekli istemci için kullanın.
- POP3 kullanılıyorsa sunucuda kopya bırakma ve indirdikten sonra silme ayarlarının veri kaybı oluşturmayacağını doğrulayın.
- Yerel posta dosyalarını, cihaz diskini ve yedekleri erişim kontrolüyle koruyun.
E-posta Sunucusunda POP3 ve IMAP Güvenlik Ayarları
- IMAP için 993 ve POP3 için 995 portunda örtük TLS hizmeti sunun.
- Sunucu adını kapsayan, süresi geçerli ve eksiksiz zincire sahip bir sertifika yapılandırın.
- TLS 1.2 desteğini etkinleştirin; TLS 1.3'ü de etkinleştirip görüşmede tercih edin. SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1 ile kullanımdan kaldırılmış şifreleme paketlerini kapatın.
- TLS kurulmadan parola tabanlı kimlik doğrulamayı reddedin ve şifresiz geri dönüşü engelleyin.
- Destekleniyorsa OAuth, çok faktörlü kimlik doğrulama ve uygulama parolası politikalarını hesap yaşam döngüsüyle birlikte yönetin.
- Belirli bir süredeki başarısız giriş denemelerinin sayısını sınırlayın; hesap ele geçirme belirtilerini ve sertifika yenileme durumunu izleyin.
- Günlüklerde TLS sürümü ve şifreleme paketi gibi tanı verilerini kaydedin; parola, belirteç veya gereksiz ileti içeriği tutmayın. Kayıt erişimini ve saklama süresini sınırlandırın.
POP3 ve IMAP Bağlantı Hataları Nasıl Ayırt Edilir?
993 veya 995 portunda uygulamadaki “STARTTLS” ya da “STLS” seçeneğini seçmek sık görülen bir uyumsuzluktur. Bu portlar ilk uygulama verisi olarak TLS el sıkışması beklediği için istemcide genellikle “SSL/TLS” ya da “bağlantı başlangıcında TLS” seçeneği kullanılmalıdır.
Sertifika adı uyuşmuyorsa istemcideki sunucu adını e-posta hizmeti sağlayıcısının belgelediği adla karşılaştırın. Zincir hatasında ara sertifikaların sunucudan doğru sırayla sunulduğunu denetleyin. Süre hatasında sunucu ve istemci saatlerini kontrol edin; sertifikanın süresi gerçekten dolmuşsa sunucu yöneticisinin sertifikayı yenilemesi gerekir.
TLS bağlantısı kuruluyor ancak oturum açılamıyorsa sorun çoğu durumda porttan değil, yanlış kullanıcı adı biçimi, devre dışı hesap, çok faktörlü kimlik doğrulama, uygulama parolası gereksinimi veya desteklenmeyen kimlik doğrulama yönteminden kaynaklanır. Sunucu günlükleri hata nedenini genel istemci uyarısından daha açık gösterebilir.
Bir erişim kuralı yalnız belirli genel IP adreslerine izin veriyorsa e-posta sunucusunun veya güvenlik duvarının günlüklerindeki bağlantı kaynağını izin verilen adreslerle karşılaştırın. VPN, uygulamaya özel yönlendirme veya IPv4 ve IPv6 seçimi nedeniyle posta istemcisinin bağlantı kaynağı, tarayıcıda görünen genel IP adresinden farklı olabilir.
Bağlantı kurulduğu halde iletiler kayboluyor veya cihazlar arasında farklı görünüyorsa POP3'te sunucudan silme ayarını, IMAP'te klasör aboneliklerini ve eşitleme kapsamını kontrol edin. Bu belirtiler genellikle TLS hatasından değil, posta kutusu kullanım modelinden kaynaklanır.
