SSL ve TLS Nedir: Şifreleme Protokollerinin Temelleri

yazar

Bir web sitesine bağlandığında tarayıcının adres çubuğunda gördüğün o küçük kilit simgesi, aslında arkasında oldukça derin bir güvenlik altyapısının varlığına işaret ediyor. Günde yüzlerce kez HTTPS üzerinden bir siteye giriyorsun, banka işlemi yapıyorsun, şifre giriyorsun. Peki bu veri nasıl korunuyor? SSL ve TLS işte tam bu noktada devreye giriyor. Sistem yöneticisi olarak bu protokolleri yüzeysel değil, gerçekten içselleştirmen gerekiyor. Çünkü sertifika yönetimi yaparken, Nginx veya Apache konfigüre ederken ya da bir güvenlik açığı raporunu okurken bu temellere ihtiyaç duyacaksın.

SSL ve TLS Arasındaki Fark

İnsanlar hala “SSL sertifikası” diye konuşuyor ama aslında bugün kullandığımız şey TLS. SSL (Secure Sockets Layer) Netscape tarafından geliştirilen orijinal protokoldü. SSL 1.0 hiç yayınlanmadı, SSL 2.0 ve 3.0 çeşitli güvenlik açıkları nedeniyle devre dışı bırakıldı. TLS (Transport Layer Security) ise SSL’in devamı niteliğinde, IETF tarafından standartlaştırılmış protokol.

Mevcut durum şu şekilde:

  • SSL 2.0: 2011’de resmi olarak deprecated edildi (RFC 6176)
  • SSL 3.0: POODLE saldırısı sonrası 2015’te deprecated edildi (RFC 7568)
  • TLS 1.0: 2021’de deprecated edildi (RFC 8996)
  • TLS 1.1: Aynı RFC ile 2021’de deprecated edildi
  • TLS 1.2: Hala aktif olarak kullanılıyor, geniş uyumluluk sağlıyor
  • TLS 1.3: Güncel standart, 2018’de yayınlandı (RFC 8446)

Peki neden hala “SSL sertifikası” diyoruz? Çünkü bu terim artık sanki ticari bir marka gibi yerleşmiş durumda. Let’s Encrypt bile sitesinde “SSL/TLS sertifikaları” ifadesini kullanıyor. Teknik yazışmalarında TLS demeni tavsiye ederim ama müşteriye anlatırken SSL dersen de kimse seni yanlış anlamaz.

TLS El Sıkışması Nasıl Çalışır

TLS’in özünü anlamak için el sıkışma (handshake) sürecini kavraman şart. Bir istemci sunucuya bağlandığında şu adımlar yaşanıyor:

TLS 1.2 el sıkışması:

  1. İstemci “ClientHello” mesajı gönderiyor. Bu mesajda desteklenen TLS sürümü, cipher suite listesi ve rastgele bir değer (client random) var.
  2. Sunucu “ServerHello” ile cevap veriyor. Seçilen cipher suite, sertifika ve kendi rastgele değeri (server random) geliyor.
  3. İstemci sertifikayı doğruluyor. CA zinciri kontrol ediliyor.
  4. İstemci “pre-master secret” üretiyor ve sunucunun public key’i ile şifreleyerek gönderiyor.
  5. Her iki taraf da client random + server random + pre-master secret’tan “master secret” türetiyor.
  6. Bu master secret’tan oturum anahtarları üretiliyor.
  7. Her iki taraf “Finished” mesajı göndererek el sıkışmayı tamamlıyor.

TLS 1.3 el sıkışması çok daha verimli. Eski yöntemlerdeki gereksiz round-trip’ler kaldırıldı. Sadece 1-RTT (Round Trip Time) ile bağlantı kurulabiliyor, hatta önceden bağlanılmış sunucularda 0-RTT bile mümkün.

Sunucunda aktif TLS bağlantısının el sıkışma detaylarını görmek için:

openssl s_client -connect example.com:443 -tls1_3 -showcerts

TLS 1.2 ile test etmek istersen:

openssl s_client -connect example.com:443 -tls1_2

Çıktıda “Protocol” satırında hangi sürümün müzakere edildiğini ve “Cipher” satırında seçilen algoritma paketini göreceksin.

Simetrik ve Asimetrik Şifreleme

TLS’i anlamak için bu iki şifreleme türünü kavramak gerekiyor.

Asimetrik şifreleme (public-key kriptografi): İki anahtar kullanılır. Public key ile şifrelenmiş veri yalnızca private key ile çözülür. RSA ve ECDSA bu kategoride. Sorun şu ki asimetrik şifreleme hesaplama açısından çok pahalı. Her byte’ı bu yöntemle şifrelemek sunucuyu ezer.

Simetrik şifreleme: Tek anahtar kullanılır, hem şifreler hem çözer. AES-256-GCM örneği. Çok daha hızlı ama anahtar değişimi problemi var. İki tarafın bu anahtarı nasıl güvenli paylaşacağı sorusu TLS’in çözdüğü temel problem.

TLS’in zekice çözümü: Asimetrik şifrelemeyi yalnızca oturum anahtarının güvenli biçimde değiş tokuşu için kullanır. Gerçek veri transferi ise hız açısından simetrik şifrelemeyle yapılır.

Cipher Suite Nedir

Cipher suite, bir TLS bağlantısında kullanılacak kriptografik algoritma kombinasyonunu tanımlayan bir isim. TLS 1.2 için tipik bir cipher suite şöyle görünür:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Bu ismi parçalara ayıralım:

  • TLS: Protokol
  • ECDHE: Anahtar değişim algoritması (Elliptic Curve Diffie-Hellman Ephemeral)
  • RSA: Kimlik doğrulama algoritması
  • AES_256_GCM: Simetrik şifreleme algoritması ve modu
  • SHA384: MAC/hash algoritması

TLS 1.3’te cipher suite’ler çok daha basitleşti. Key exchange ve authentication ayrı tutuldu, cipher suite sadece simetrik algoritmayı ve hash’i belirtiyor:

TLS_AES_256_GCM_SHA384

Sunucunda desteklenen cipher suite’leri listelemek için nmap kullanabilirsin:

nmap --script ssl-enum-ciphers -p 443 example.com

Zayıf cipher suite’leri tespit etmek için:

openssl s_client -connect example.com:443 -cipher RC4-SHA 2>/dev/null | grep "Cipher is"

Eğer “NONE” yerine bir cipher adı dönüyorsa sunucu zayıf algoritmayı kabul ediyor demek. Bu bir güvenlik açığı.

Sertifika Zinciri ve PKI

Public Key Infrastructure (PKI), dijital sertifikaların güven modelini tanımlıyor. Bir sertifikaya neden güveniyoruz? Çünkü onu imzalayan bir Certificate Authority (CA) var ve o CA’ya güveniyoruz.

Güven zinciri şöyle işliyor:

  • Root CA: İşletim sistemi veya tarayıcının güven deposuna önceden yüklenmiş. Self-signed. DigiCert, GlobalSign, Let’s Encrypt gibi.
  • Intermediate CA: Root CA tarafından imzalanmış. Sitenin sertifikasını imzalayan genellikle bu.
  • End-entity sertifikası: Senin alan adın için düzenlenmiş sertifika.

Root CA’nın private key’i o kadar kritik ki bu anahtarlar genellikle internet bağlantısı olmayan, fiziksel güvenlik önlemleriyle korunan makinelerde tutuluyor. Bu yüzden günlük sertifika imzalama işleri intermediate CA’lar üzerinden yapılıyor.

Bir sitenin sertifika zincirini incelemek için:

openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -A 5 "Issuer|Subject|Validity"

Daha okunabilir bir çıktı için:

openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Sertifika zincirinin tamamını almak istersen:

openssl s_client -connect example.com:443 -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/ { print }' > chain.pem

Perfect Forward Secrecy

PFS (Perfect Forward Secrecy) ya da yeni adıyla FS (Forward Secrecy), TLS’in çok kritik bir özelliği. Fikir şu: Her oturum için ayrı, geçici bir anahtar kullanıyorsan, birileri ileride sunucunun private key’ini ele geçirse bile geçmiş oturumları deşifre edemez.

Bu yüzden cipher suite listesinde DHE (Diffie-Hellman Ephemeral) veya ECDHE (Elliptic Curve DHE) görmek istiyorsun. “Ephemeral” kelimesi her oturum için yeni bir geçici anahtar üretildiğini söylüyor.

Buna karşılık RSA key exchange kullanan cipher suite’lerde PFS yok. Çünkü pre-master secret doğrudan sunucunun public key’i ile şifreleniyor. Birisi trafiği kayıt altına alıp sonra private key’e erişirse her şeyi çözebilir.

TLS 1.3’te güzel haber: RSA key exchange tamamen kaldırıldı. TLS 1.3 zorunlu olarak PFS kullanıyor.

Nginx’te PFS destekleyen cipher suite konfigürasyonu:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

ssl_session_tickets off satırı dikkatini çekmiş olabilir. Session ticket mekanizması PFS’i zayıflatabilir, bu yüzden kapatmak iyi bir pratik.

Sertifika Türleri

Güven seviyesi ve kapsam açısından farklı sertifika türleri var:

Alan adı doğrulama (DV – Domain Validation): Sadece alan adının kontrolü doğrulanıyor. Süreç tamamen otomatik, Let’s Encrypt bu kategoride. Hızlı ve ücretsiz.

Organizasyon doğrulama (OV – Organization Validation): Şirket bilgileri CA tarafından doğrulanıyor. Sertifikada organizasyon adı görünüyor. Birkaç gün sürebiliyor.

Genişletilmiş doğrulama (EV – Extended Validation): En yüksek doğrulama seviyesi. CA, şirketin yasal varlığını kapsamlı biçimde doğruluyor. Eski tarayıcılarda yeşil adres çubuğu gösterirdi. Günümüzde EV sertifikasının görsel faydası azaldı ama kurumsal tercih olmaya devam ediyor.

Wildcard sertifikası: *.example.com formatında, tüm alt alan adlarını kapsıyor. api.example.com, mail.example.com hepsi bu sertifika ile çalışıyor.

SAN (Subject Alternative Name) sertifikası: Birden fazla farklı alan adını tek sertifikada barındırıyor. example.com, example.net, example.org gibi.

Let’s Encrypt ile wildcard sertifika almak:

certbot certonly --manual --preferred-challenges dns 
  -d "*.example.com" 
  -d "example.com" 
  --email [email protected] 
  --agree-tos

Bu komut DNS TXT kaydı eklemenizi isteyecek. DNS üzerinden doğrulama zorunlu çünkü wildcard doğrulaması HTTP yöntemiyle yapılamıyor.

HTTPS Bağlantısını Hızlı Test Etme

Üretim ortamında sertifika ve TLS konfigürasyonunu test etmek için birkaç araç hayatını kolaylaştırır.

SSL Labs’ın komut satırı alternatifi olarak testssl.sh kullanabilirsin:

# testssl.sh indir ve çalıştır
wget https://testssl.sh/testssl.sh
chmod +x testssl.sh
./testssl.sh example.com

Sertifika son kullanma tarihini kontrol etmek:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -enddate

Bu komutu cron’a ekleyerek sertifika süresini izleyebilirsin:

#!/bin/bash
DOMAIN="example.com"
EXPIRY=$(echo | openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null 
  | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt 30 ]; then
  echo "UYARI: $DOMAIN sertifikasi $DAYS_LEFT gun sonra sona eriyor!"
  # Buraya mail bildirimi ekleyebilirsin
fi

HSTS ve Güvenlik Header’ları

TLS konfigürasyonu sertifika ve protokolden ibaret değil. HTTP Strict Transport Security (HSTS) tarayıcıya “bu siteye her zaman HTTPS ile bağlan” direktifini veriyor. Man-in-the-middle saldırılarına karşı kritik bir önlem.

Nginx’te HSTS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  • max-age=31536000: 1 yıl boyunca geçerli
  • includeSubDomains: Alt alan adlarına da uygulanıyor
  • preload: HSTS preload listesine girilebilmek için gerekli direktif

Apache’de eşdeğer konfigürasyon:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Dikkat: HSTS’yi ilk etkinleştirdiğinde max-age değerini düşük tut (örneğin 3600). Her şeyin düzgün çalıştığını doğruladıktan sonra artır. Çünkü HTTPS’e geçerken bir sorun yaşarsan ve tarayıcı sitenizi HSTS listesinde tutuyorsa HTTP üzerinden bağlanamaz hale gelirsin.

TLS 1.3’ün Getirdiği Yenilikler

TLS 1.3 sadece güvenli değil, aynı zamanda çok daha hızlı. Önemli değişiklikler:

0-RTT (Zero Round-Trip Time Resumption): Daha önce bağlanılan sunucuya yeniden bağlanırken ilk mesajla birlikte uygulama verisi gönderilebiliyor. Bu replay saldırılarına karşı dikkatli kullanılması gereken bir özellik, idempotent istekler için uygun.

Handshake şifrelemesi: TLS 1.3’te sertifika bile şifreli gönderiliyor. TLS 1.2’de sunucu sertifikası açık metin gidiyordu, network dinleyicileri hangi siteye bağlandığını görebiliyordu.

Eski zayıf algoritmalar kaldırıldı: RSA key exchange, SHA-1, MD5, RC4, DES, 3DES, AES-CBC modu tamamen dışarıda bırakıldı.

Daha az cipher suite: TLS 1.2’de yüzlerce cipher suite kombinasyonu mümkündü, TLS 1.3’te yalnızca 5 tanesi var.

Bir sunucunun TLS 1.3 destekleyip desteklemediğini kontrol et:

openssl s_client -connect example.com:443 -tls1_3 2>&1 | grep "Protocol|Cipher|Verify return"

“Handshake failure” dönüyorsa TLS 1.3 desteklenmiyor demek.

Sık Karşılaşılan TLS Sorunları

Sertifika zinciri eksikliği: En yaygın sorunlardan biri. Sunucu sadece end-entity sertifikayı servis ediyor, intermediate CA sertifikasını göndermiyor. Bazı istemciler bunu tolere etse de bazı eski istemciler bağlantıyı reddeder.

Kontrol için:

openssl s_client -connect example.com:443 2>/dev/null | grep "verify return"

verify return:1 görüyorsan zincir tamam. Farklı bir değer varsa sorun var.

Mixed content uyarısı: HTTPS sayfasında HTTP üzerinden yüklenen bir kaynak varsa tarayıcı uyarı veriyor. Bu TLS’in zayıflamasına yol açmaz ama görsel bir güvenlik işareti kaybı yaşanıyor.

SNI (Server Name Indication) sorunu: Tek IP’de birden fazla alan adı barındırıyorsan SNI şart. Eski istemciler (Windows XP üzerindeki IE gibi) SNI desteklemiyordu. 2024’te bu neredeyse sorun olmaktan çıktı ama embedded sistemlerle uğraşıyorsan aklında bulunsun.

Clock skew: Sertifika geçerlilik tarihlerinin doğru hesaplanması için sunucu saatinin doğru olması gerekiyor. NTP senkronizasyonu çalışmayan bir sunucuda notBefore veya notAfter hataları görebilirsin.

# NTP durumunu kontrol et
timedatectl status
# Veya
ntpq -p

Pratik Güvenlik Kontrol Listesi

Bir web sunucusu konfigüre ettiğinde TLS tarafında şunları mutlaka kontrol et:

  • SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1 devre dışı bırakılmış olmalı
  • Yalnızca TLS 1.2 ve TLS 1.3 aktif olmalı
  • Cipher suite listesi yalnızca ECDHE veya DHE key exchange içermeli (PFS zorunlu)
  • RC4, DES, 3DES, MD5 kullanan cipher suite’ler devre dışı olmalı
  • HSTS header’ı eklenmeli
  • Sertifika zinciri eksiksiz olmalı
  • Sertifika son kullanma tarihi izlenmeli
  • OCSP stapling aktif olmalı (sertifika iptal durumu için)
  • ssl_session_tickets kapalı veya dönüşümlü key ile kullanılmalı

Mozilla’nın SSL Configuration Generator aracı (ssl-config.mozilla.org) bu konfigürasyonları otomatik üretiyor. Nginx, Apache, HAProxy için hazır çıktı veriyor. Her yeni sunucu kurduğumda ilk bakacağım yer orası.

Sonuç

SSL ve TLS protokollerini anlamak, sistem yöneticiliğinin olmazsa olmaz parçası. Sertifika kuruyorsun, Nginx konfigürasyonu yazıyorsun, bir güvenlik taramasının çıktısını yorumluyorsun, bunların hepsinde bu temellere ihtiyaç duyacaksın.

Temel mesaj şu: Bugün TLS kullanıyoruz, SSL değil. TLS 1.2 hala geçerli ama TLS 1.3’e geçiş yapman gerekiyor. Perfect Forward Secrecy, modern TLS konfigürasyonunun vazgeçilmezi. Sertifika zinciri eksikliği ve sona eren sertifikalar üretim ortamında ciddi kesintilere yol açıyor, izleme sistemi kurman şart.

Güvenlik bu alanda durağan değil. Protokolün kendisi güncellenebilir ama kriptografinin matematiksel temelleri, cipher suite’lerin nasıl seçildiği, el sıkışma sürecinin nasıl işlediği gibi kavramları bir kez iyi anladıktan sonra yeni gelişmeleri takip etmek çok daha kolay oluyor. Bir sonraki yazıda Let’s Encrypt ile sertifika otomasyonunu, Certbot’un renewal hook’larını ve wildcard sertifika yönetimini ele alacağız.

Yorum yapın