E-posta Şifreleme: PGP ve S/MIME

"Mailimiz TLS ile şifreli" cümlesi doğrudur ama çoğu kişinin sandığı şeyi anlatmaz. TLS, mesajın iki sunucu arasında yol alırken dinlenmesini engeller; sunucuya vardığında mesaj düz metin olarak diske yazılır ve o sunucuya erişimi olan herkes okuyabilir. E-posta şifreleme dediğimizde asıl kastedilen ise farklı bir şeydir: mesajın gönderenin bilgisayarında şifrelenip alıcının bilgisayarında çözülmesi, yani aradaki hiçbir sunucunun içeriği görememesi. Bunun iki yaygın standardı var — PGP ve S/MIME — ve ikisi birbiriyle uyumlu değildir.

Bu rehberde önce taşıma şifrelemesi ile uçtan uca şifreleme arasındaki farkı netleştireceğim, sonra PGP ve S/MIME'ın nasıl çalıştığını, aralarındaki güven modeli farkını ve hangi durumda hangisini seçmen gerektiğini anlatacağım. Ardından ikisinin de pratik kurulumunu göstereceğim ve en önemli bölüme geleceğiz: uçtan uca şifrelemenin ne yapmadığı. Bu kısmı atlayan kurulumlar, sağladığı korumayı abartıp gerçekte açık kalan yerleri gözden kaçırıyor.

Taşıma Şifrelemesi ile Uçtan Uca Şifrelemenin Farkı#

Bir e-postanın yolculuğunda şifrelemenin uygulanabileceği iki ayrı katman var ve bunları karıştırmak en yaygın kavram hatasıdır.

Taşıma şifrelemesi (TLS) iki sunucu arasındaki bağlantıyı korur. Gönderen sunucu alıcı sunucuya bağlanırken STARTTLS ile bağlantıyı şifreler; böylece ağ üzerinde dinleyen biri mesajı okuyamaz. Ama mesaj her durakta çözülür, işlenir ve tekrar şifrelenir. Sunucularda düz metin olarak durur.

Uçtan uca şifreleme (PGP / S/MIME) ise mesajın gövdesini gönderenin istemcisinde şifreler ve yalnızca alıcının özel anahtarıyla çözülebilir hale getirir. Arada kaç sunucu olursa olsun hiçbiri içeriği göremez; posta sağlayıcın bile göremez.

İki katman birbirinin alternatifi değil, tamamlayıcısıdır. TLS'i her durumda açık tutmalısın — hatta MTA-STS ile zorunlu kılmalısın, bunun DNS tarafını mail sunucusu DNS kayıtları yazısında anlattım. Uçtan uca şifrelemeyi ise gerçekten hassas yazışmalar için, seçici biçimde devreye alırsın.

PGP Nasıl Çalışır#

PGP (ve açık kaynak uygulaması GnuPG) asimetrik şifrelemeye dayanır: her kullanıcının bir açık anahtarı ve bir özel anahtarı vardır. Sana mesaj göndermek isteyen kişi senin açık anahtarınla şifreler; sen özel anahtarınla açarsın. Aynı çift imzalama için de kullanılır: sen kendi özel anahtarınla imzalarsın, karşı taraf senin açık anahtarınla doğrular.

PGP'nin ayırt edici yanı güven modelidir. Merkezî bir otorite yoktur; anahtarların kime ait olduğuna kullanıcılar kendi aralarında karar verir. Buna "güven ağı" (web of trust) denir: bir anahtarı doğruladığında onu imzalarsın, senin imzana güvenen başkaları da o anahtara güvenir. Pratikte bu model ölçeklenmedi ve çoğu kullanıcı anahtarları doğrudan karşı taraftan güvenli bir kanalla alarak doğruluyor.

Anahtar üretmek basittir:

# Etkileşimli anahtar üretimi (isim, e-posta, süre sorar)
gpg --full-generate-key

# Anahtarlarını listele
gpg --list-secret-keys --keyid-format=long
# sec   rsa4096/A1B2C3D4E5F6A7B8 2026-08-25 [SC] [expires: 2028-08-25]
#       uid  Ad Soyad <[email protected]>

# Açık anahtarını dışa aktar (karşı tarafa göndereceğin dosya)
gpg --armor --export [email protected] > acik-anahtar.asc

# Karşı tarafın açık anahtarını içe aktar
gpg --import karsi-taraf.asc

# Parmak izini doğrula - bu adım atlanırsa şifreleme anlamsızdır
gpg --fingerprint [email protected]

Son komut kritik. Bir açık anahtarı e-posta ile aldıysan, o e-postanın sahte olmadığını nereden biliyorsun? Parmak izini karşı tarafla başka bir kanaldan (telefon, yüz yüze) karşılaştırmadan o anahtara güvenmek, tüm sistemi anlamsızlaştırır. Ortadaki adam saldırısı tam olarak bu boşluktan girer.

Komut satırından bir dosyayı şifrelemek ve imzalamak:

# Hem şifrele hem imzala
gpg --encrypt --sign --armor -r [email protected] mesaj.txt
# Çıktı: mesaj.txt.asc

# Gelen şifreli mesajı çöz ve imzayı doğrula
gpg --decrypt mesaj.txt.asc

Günlük kullanımda bunu elle yapmazsın; istemci eklentisi (Thunderbird'de yerleşik OpenPGP desteği, Outlook için harici eklentiler) bu adımları arka planda yürütür.

S/MIME Nasıl Çalışır#

S/MIME de aynı asimetrik mantığı kullanır ama güven modeli tamamen farklıdır: burada anahtarlar bir sertifika otoritesi tarafından imzalanmış X.509 sertifikaları içinde gelir. Yani kimin kim olduğuna, tıpkı web sertifikalarında olduğu gibi, güvenilen bir üçüncü taraf karar verir.

Bu farkın pratik sonuçları önemli. S/MIME kurumsal ortamlarda çok daha kolay yönetilir: şirket kendi sertifika otoritesini kurar ya da ticari bir otoriteden sertifika alır, sertifikaları merkezi olarak dağıtır, ayrılan çalışanın sertifikasını iptal eder. Kullanıcı tarafında ise hiçbir "güven kararı" verilmesi gerekmez; istemci sertifikayı otomatik doğrular. Buna karşılık kurum dışındaki rastgele bir kişiyle şifreli yazışmak zordur, çünkü onun da bir sertifikası olması gerekir.

Test amaçlı kendi sertifikanı üretmek için:

# Özel anahtar üret
openssl genrsa -out ornek.key 4096

# Sertifika imzalama isteği oluştur (CN alanına e-posta adresini yaz)
openssl req -new -key ornek.key -out ornek.csr \
  -subj "/CN=Ad Soyad/[email protected]"

# İstemcilere yüklenecek PKCS#12 paketini üret
openssl pkcs12 -export -in ornek.crt -inkey ornek.key \
  -out ornek.p12 -name "Ornek S/MIME"

# Sertifikanın içeriğini ve süresini kontrol et
openssl x509 -in ornek.crt -noout -subject -dates

Üretilen .p12 dosyasını Outlook, Thunderbird ya da Apple Mail'e içe aktarırsın; istemci şifreleme ve imzalama seçeneklerini otomatik olarak açar. Gerçek kullanımda sertifikayı bir otoriteden almalısın, çünkü kendi imzaladığın bir sertifikayı karşı tarafın istemcisi güvenilmez olarak işaretler. İstemci kurulum adımlarının genel akışı için Outlook e-posta istemci kurulumu yazısına bakabilirsin.

PGP mi S/MIME mı: Hangisini Seçmelisin#

İkisi de aynı işi yapar ama farklı ortamlarda rahat eder. Karşılaştırma:

Kısaca: bir kurumun içinde ve dışında düzenli şifreli yazışma yapıyorsan S/MIME, teknik ekiplerle ya da bireysel olarak esnek kullanım istiyorsan PGP daha uygundur. Anahtar kurtarma satırını özellikle vurgulamak isterim: PGP'de özel anahtarını kaybedersen o anahtarla şifrelenmiş tüm geçmiş yazışman kalıcı olarak okunamaz hale gelir. Kurumsal ortamda bu kabul edilemez bir risktir ve S/MIME'ın merkezî yedekleme imkânı bu yüzden tercih sebebidir.

Uçtan Uca Şifrelemenin Yapmadıkları#

Bu bölüm, yazının en önemli kısmı. Şifrelemeyi kurup "artık güvendeyiz" demek, korumanın kapsamını ciddi biçimde abartmaktır. Şunlar şifrelenmez ya da korunmaz:

Başlıklar açıkta kalır. Kim kime, ne zaman yazdı bilgisi (gönderen, alıcı, tarih, mesaj yolu) şifrelenmez. Hem PGP hem S/MIME yalnızca gövdeyi ve ekleri korur. Bu üstveri, çoğu durumda içeriğin kendisi kadar bilgi verir.

Konu satırı da açıktır. Klasik PGP ve S/MIME kullanımında Subject başlığı şifrelenmez. "Ödeme planı revizyonu — Ornek AŞ" gibi bir konu satırı, içeriği okumadan çok şey anlatır. Bazı istemciler konuyu gizleyen bir yöntemi destekler ama yaygın değildir; alışkanlık olarak konu satırına anlamlı bilgi yazmamayı tercih et.

Uç noktalar korunmaz. Şifreleme, mesajı yolda korur; senin ya da alıcının bilgisayarında mesaj çözülmüş halde durur. Cihaz ele geçirilirse şifreleme hiçbir işe yaramaz. Özel anahtarın parolasız duruyorsa durum daha da kötüdür.

Sunucu tarafı tarama devre dışı kalır. Şifreli mesajın içeriğini spam filtresi ve antivirüs okuyamaz. Yani şifreli bir ek içinde gelen zararlı bir dosya sunucuda yakalanamaz; koruma tamamen uç noktadaki yazılıma kalır.

Arşivleme ve arama bozulur. Kurumsal arşiv sistemin şifreli mesajın içeriğini indeksleyemez; yıllar sonra o mesajı arayarak bulman mümkün olmaz. Arşivleme politikan varsa bunu göz önüne alman gerekir — e-posta arşivleme ve saklama yazısındaki kurgu, şifreli yazışmalar için ayrı bir plan gerektirir.

Kimlik doğrulama kayıtlarının yerini tutmaz. PGP/S/MIME imzası mesajın bütünlüğünü kanıtlar ama alan adı düzeyinde sahtecilik korumasının yerine geçmez. SPF, DKIM ve DMARC ayrı bir katmandır ve mutlaka kurulmalıdır; sahte gönderici saldırılarına karşı ne yapman gerektiğini e-posta spoofing önleme yazısında bulabilirsin.

Anahtar Yönetimi ve Pratik Öneriler#

Şifreleme sistemlerinde zayıf halka neredeyse her zaman anahtar yönetimidir. Birkaç somut kural:

1. Özel anahtarı mutlaka güçlü bir parola ile koru. Parolasız bir özel anahtar, dosyayı ele geçiren herkes için doğrudan kullanılabilir. Güçlü bir parola üretmek için şifre üretici aracımızı kullanabilirsin.
2. Anahtara son kullanma tarihi ver. Süresiz anahtar, kaybedildiğinde sonsuza kadar geçerli kalır. İki yıllık bir süre makuldür ve süreyi sonradan uzatabilirsin.
3. İptal sertifikanı önceden üret ve ayrı sakla. Anahtarını kaybedersen ya da ele geçirilirse, iptal sertifikası olmadan kimseye "bu anahtar artık geçersiz" diyemezsin.

# İptal sertifikasını şimdiden üret ve güvenli bir yerde sakla
gpg --output iptal-A1B2C3D4.asc --gen-revoke [email protected]
chmod 600 iptal-A1B2C3D4.asc

4. Anahtarı yedekle, ama yedeği şifreli tut. Özel anahtarın tek kopyası tek bir bilgisayarda duruyorsa, o bilgisayarın diski öldüğünde tüm şifreli arşivin okunamaz olur.
5. Parmak izini her zaman ikinci bir kanaldan doğrula. E-posta ile gelen bir açık anahtarı sorgusuz kabul etmek, saldırganın araya girmesine kapı açar.
6. Kurumsal kullanımda merkezî bir plan yap. Kim sertifika alacak, ayrılan çalışanın sertifikası nasıl iptal edilecek, anahtar kurtarma nasıl olacak — bunlar önceden kararlaştırılmazsa sistem birkaç ay içinde dağılır.

Sık Yapılan Hatalar#

En yaygın hata, TLS ile uçtan uca şifrelemeyi karıştırmaktır. "Sunucumuzda TLS var" demek mesajların sunucuda şifreli durduğu anlamına gelmez; ikisi farklı katmanlardır ve farklı tehditlere karşı korur.

İkinci hata, açık anahtarı doğrulamadan kullanmaktır. Parmak izini ikinci bir kanaldan karşılaştırmadan bir anahtara güvenirsen, saldırgan kendi anahtarını senin muhatabınınmış gibi gönderip tüm yazışmayı okuyabilir. Bu, şifrelemenin sağladığı korumayı tamamen ortadan kaldırır.

Üçüncü hata, özel anahtarı parolasız bırakmaktır; anahtar dosyasını ele geçiren herkes doğrudan kullanabilir hale gelir. Dördüncü hata, iptal sertifikası üretmemektir — anahtar kaybolduğunda geriye yapabileceğin hiçbir şey kalmaz.

Beşinci hata, konu satırına hassas bilgi yazmaktır; konu şifrelenmez ve mesaj içeriğinin ne olduğunu ele verir. Altıncı hata, tüm kuruma zorunlu şifreleme dayatmaktır: karşı tarafların çoğu şifreleme kullanmadığı için mesajlar ya gönderilemez ya da kullanıcılar sistemi kapatmanın bir yolunu bulur. Şifrelemeyi gerçekten hassas yazışmalar için seçici uygula. Son olarak, anahtarı yedeklememek de klasik bir kayıp sebebidir; disk arızası tüm şifreli arşivini okunamaz hale getirir.

Sıkça Sorulan Sorular#

PGP ve S/MIME birbirleriyle uyumlu mu#

Hayır, iki farklı standarttır ve birbirleriyle çalışmazlar. PGP ile şifrelenmiş bir mesajı S/MIME kullanan bir alıcı açamaz, tersi de geçerlidir. Bu yüzden karşı tarafın hangi sistemi kullandığını önceden bilmen gerekir. Bazı istemciler ikisini birden destekler, yani aynı programda hem PGP hem S/MIME kurabilirsin, ama tek bir mesaj yalnızca birini kullanır.

E-posta şifreleme ücretsiz mi#

PGP tarafı tamamen ücretsizdir; GnuPG açık kaynaktır ve anahtar üretmenin hiçbir maliyeti yoktur. S/MIME'da ise sertifikayı bir otoriteden alman gerekir ve bu genellikle ücretlidir; kurumlar kendi iç sertifika otoritelerini kurarak bu maliyeti ortadan kaldırabilir, ancak o sertifikalar kurum dışında güvenilir sayılmaz. Yani bireysel kullanımda PGP, kurumsal kullanımda maliyetli ama yönetilebilir S/MIME öne çıkar.

Şifreli e-posta gönderdiğimde alıcı da aynı sistemi kurmak zorunda mı#

Evet. Uçtan uca şifrelemenin doğası gereği alıcının bir anahtar çiftine ve uyumlu bir istemciye ihtiyacı vardır; sen tek başına şifreli mesaj gönderemezsin. Yalnızca imzalama tek taraflı çalışır: sen mesajı imzalarsan alıcı şifreleme kurmamış olsa bile mesajı okuyabilir, sadece imzayı doğrulayamaz. Bu yüzden pek çok kurum imzalamayı yaygın, şifrelemeyi seçici kullanır.

Şifreli mesajları spam filtresi tarayabilir mi#

Hayır. Şifreli gövdenin içeriğini sunucudaki hiçbir filtre okuyamaz, dolayısıyla spam skorlaması ve virüs taraması yapılamaz. Bu, uçtan uca şifrelemenin bilinçli olarak kabul edilen bir maliyetidir. Koruma tamamen alıcının cihazındaki güvenlik yazılımına kalır, o yüzden şifreli ekleri açarken uç nokta korumasının güncel olduğundan emin ol.

Anahtarımı kaybedersem eski mesajlarımı okuyabilir miyim#

PGP'de hayır; özel anahtar olmadan o anahtarla şifrelenmiş mesajlar kalıcı olarak okunamaz hale gelir ve bunu telafi etmenin bir yolu yoktur. Bu yüzden anahtarın şifreli bir yedeğini ayrı bir ortamda saklaman şart. S/MIME'da kurumsal bir anahtar kurtarma mekanizması kurulmuşsa sertifika otoritesi üzerinden kurtarma mümkün olabilir; bu, kurumsal ortamda S/MIME'ı tercih etmenin en güçlü gerekçelerinden biridir.

Konu satırı da şifreleniyor mu#

Klasik PGP ve S/MIME kullanımında hayır; yalnızca mesaj gövdesi ve ekleri şifrelenir. Gönderen, alıcı, tarih ve konu başlıkları açıkta kalır. Bazı istemciler konuyu gizleyip yerine genel bir metin koyan bir yöntem destekler ama bu yaygın ve garantili değildir. En pratik önlem, konu satırına hiçbir zaman anlamlı ya da hassas bilgi yazmamaktır.

Kapanış#

Uçtan uca e-posta şifreleme güçlü bir araç ama sihirli değil; ne yaptığını ve ne yapmadığını bilerek kurulduğunda değerli olur. Aklında kalması gereken dört alışkanlık: TLS ile uçtan uca şifrelemeyi ayrı katmanlar olarak düşün, ikisini birlikte kullan; bir açık anahtarı parmak izini ikinci kanaldan doğrulamadan asla kabul etme; özel anahtarını güçlü parolayla koru, yedekle ve iptal sertifikanı önceden üret; ve konu satırının şifrelenmediğini unutma. Şifrelemeyi kuruma zorla dayatmak yerine, gerçekten hassas yazışmalar için seçici uygula.

Posta altyapının taşıma güvenliğini sağlamlaştırmak istiyorsan Clou.TR tarafında birkaç seçenek var. Sertifika ihtiyacın için SSL sayfamıza, TLS yapılandırılmış kurumsal posta kutuları için e-posta paketlerimize bakabilirsin. Kendi mail sunucunu işletiyorsan VDS ve SMTP sunucu çözümlerimiz tam kontrol sağlar; kurulum ve sertifika yönetimini devretmek istersen sunucu yönetimi hizmetimiz bu işi üstlenir.