SSL Sertifikası Neden Gerekli: HTTPS Olmadan Ne Olur?

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Birkaç yıl önce bir e-ticaret müşterimde çalışırken yaşadığım bir olay hala aklımda. Site HTTP üzerinden çalışıyordu, müşteri “neden SSL parası ödeyelim ki, zaten kimse dikkat etmiyor” diyordu. Ta ki Chrome’un adres çubuğunda “Güvenli Değil” yazısı belirginleşene kadar. O gün dönüşüm oranları yüzde otuz düştü, destek hattı çöktü. O günden beri SSL konusunu teknik bir zorunluluk olarak değil, iş sürekliliğinin temel taşı olarak anlatıyorum.

SSL ve TLS Arasındaki Farkı Önce Netleştirelim

Çoğu kişi “SSL sertifikası” der ama aslında bugün kullandığımız protokol TLS (Transport Layer Security). SSL (Secure Sockets Layer) 1.0, 2.0 ve 3.0 sürümleri güvenlik açıkları nedeniyle çoktan emekli edildi. TLS 1.2 ve TLS 1.3 günümüzde kullanılan versiyonlar. Ama sektör “SSL” demeye devam ediyor, alışkanlık işte.

Peki ne iş görüyor bu sertifika? Temel olarak üç şey yapıyor:

  • Şifreleme: Tarayıcı ile sunucu arasındaki veriyi şifreler, ortadaki biri dinlese bile anlamsız görür
  • Kimlik doğrulama: Bağlandığınız sunucunun gerçekten o domain’e ait olduğunu kanıtlar
  • Bütünlük: İletim sırasında verinin değiştirilmediğini garanti eder
# Bir sitenin hangi TLS versiyonunu kullandığını kontrol etmek
openssl s_client -connect example.com:443 -tls1_3

# Sertifika detaylarını görmek
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -text

# Sertifika son geçerlilik tarihini kontrol etmek
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

HTTP Trafiği Gerçekte Nasıl Görünüyor

“Ortadaki adam” saldırısını (Man-in-the-Middle) teorik bir kavram olarak anlatmak yerine somutlaştıralım. HTTP ile gönderilen bir login formu düşünün. Ağda bir paket yakalama aracı çalıştırdığınızda şunları görürsünüz:

# tcpdump ile HTTP trafiğini yakalamak (test ortamında yapın)
sudo tcpdump -i eth0 -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

# Wireshark komut satırı aracı tshark ile HTTP POST verilerini filtrelemek
sudo tshark -i eth0 -Y "http.request.method == POST" -T fields -e http.file_data

Bu komutları çalıştırdığınızda HTTP üzerinden gelen login formundaki kullanıcı adı ve parola düz metin olarak karşınıza çıkar. Şifreli hiçbir şey yok. Aynı Wi-Fi ağındaki herhangi biri, bir kafede oturan meraklı biri, ISP’nin herhangi bir çalışanı, yönlendirici üzerinde erişimi olan biri bu veriyi okuyabilir.

HTTPS’te ise aynı paketi yakaladığınızda gördüğünüz şey şöyle bir şeydir:

.............P...uVS..+.....}..X..0...S.r9..8..J,....K7......
.....D3....^..z.....4.P...n.&.b..7..M1...q..~..V.....`...P.

Anlamsız bir karmaşa. İşte bu, şifrelemenin sağladığı şey.

Tarayıcıların Verdiği Cezalar

Google Chrome, Mozilla Firefox ve diğer modern tarayıcılar HTTP siteleri ciddiye almıyor artık. Chrome 68’den itibaren tüm HTTP siteleri “Not Secure” yani “Güvenli Değil” olarak işaretleniyor. Bu sadece görsel bir uyarı değil, kullanıcı davranışlarını doğrudan etkileyen bir faktör.

# Sitenizin güvenlik başlıklarını kontrol etmek
curl -I http://example.com
curl -I https://example.com

# HSTS başlığının varlığını kontrol etmek
curl -sI https://example.com | grep -i "strict-transport"

# HTTP'den HTTPS'e yönlendirmenin çalışıp çalışmadığını test etmek
curl -v http://example.com 2>&1 | grep -E "Location|HTTP/"

Özellikle form içeren sayfalarda Chrome kırmızı bir kilit ikonu gösteriyor ve kullanıcıya “Bu sayfa güvenli değil, bilgilerinizi girmeyin” mesajı veriyor. Kullanıcı paniği ve hemen çıkış kaçınılmaz.

Firefox’un Mixed Content Politikası

Bir başka kritik konu: siteniz HTTPS’e geçtiniz diyelim ama sayfanızda HTTP üzerinden yüklenen bir resim, script veya CSS var. Bu durumda “mixed content” uyarısı alırsınız.

# Nginx yapılandırmasında mixed content'i önlemek için CSP başlığı eklemek
# /etc/nginx/sites-available/example.com dosyasına ekleyin:

server {
    listen 443 ssl;
    server_name example.com;
    
    add_header Content-Security-Policy "default-src https: 'unsafe-inline' 'unsafe-eval';" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options SAMEORIGIN;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    
    # SSL sertifika ayarları
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
}

SEO Üzerindeki Somut Etkileri

Google, 2014’ten bu yana HTTPS’i bir sıralama sinyali olarak kullanıyor. Bu teorik bir avantaj değil, ölçülebilir bir etki. Aynı içerik kalitesine sahip iki site arasında HTTPS olan bir pozisyon öne geçiyor. Büyük bir şey gibi görünmeyebilir ama yüksek rekabetli anahtar kelimelerde bu bir pozisyon farkı binlerce dolar değerinde trafik demek.

Daha da önemlisi, HTTP sitelerden HTTPS sitelere verilen referans linklerinde Referer başlığı boş geliyor. Yani HTTP bir siteden HTTPS sitenize link geldiğinde, analytics araçlarınızda bu trafik “direct” olarak görünüyor. Trafik kaynağı analiziniz mahvoluyor.

# Apache'de HTTP'den HTTPS'e kalıcı yönlendirme (301)
# /etc/apache2/sites-available/example.com.conf

# HTTP bölümü
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    
    # Tüm trafiği HTTPS'e yönlendir
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

Let’s Encrypt ile Ücretsiz SSL: Pratik Kurulum

“SSL sertifikası pahalı” argümanı artık geçerliliğini tamamen yitirdi. Let’s Encrypt, ücretsiz, otomatik yenilenebilir sertifikalar sunuyor. Tek eksisi wildcard sertifikalar için DNS doğrulaması gerektirmesi ama bu da çözülmez bir sorun değil.

# Certbot kurulumu (Ubuntu/Debian)
sudo apt update
sudo apt install certbot python3-certbot-nginx

# Nginx için sertifika al ve otomatik yapılandır
sudo certbot --nginx -d example.com -d www.example.com

# Wildcard sertifika almak için (DNS doğrulaması gerektirir)
sudo certbot certonly --manual --preferred-challenges dns 
  -d "*.example.com" -d "example.com"

# Sertifika yenileme testini çalıştır
sudo certbot renew --dry-run

# Otomatik yenileme için cron job ekle
echo "0 12 * * * /usr/bin/certbot renew --quiet" | sudo crontab -

Certbot yenilemeyi otomatik hallediyor ama buna körü körüne güvenmek tehlikeli. Ben her zaman bir monitoring scripti de eklerim:

#!/bin/bash
# ssl_check.sh - SSL sertifika son kullanma tarihi kontrolü

DOMAIN="example.com"
THRESHOLD=30  # 30 günden az kaldıysa uyar
ALERT_EMAIL="[email protected]"

EXPIRY=$(echo | openssl s_client -connect ${DOMAIN}:443 2>/dev/null 
  | openssl x509 -noout -enddate 2>/dev/null 
  | cut -d= -f2)

EXPIRY_TIMESTAMP=$(date -d "${EXPIRY}" +%s)
CURRENT_TIMESTAMP=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_TIMESTAMP - $CURRENT_TIMESTAMP) / 86400 ))

if [ $DAYS_LEFT -lt $THRESHOLD ]; then
    echo "UYARI: ${DOMAIN} sertifikasinin son kullanim tarihine ${DAYS_LEFT} gun kaldi!" 
    | mail -s "SSL Sertifika Uyarisi" $ALERT_EMAIL
    echo "KRITIK: Sertifika ${DAYS_LEFT} gun icinde sona eriyor"
else
    echo "OK: Sertifika gecerli, ${DAYS_LEFT} gun kaldi"
fi

Bu scripti cron’a ekleyip her sabah çalıştırıyorum. Bir sertifikanın sessiz sedasız expire olup sitenizi çökertmesini beklemek yerine 30 gün öncesinden mail almak hayat kurtarıcı.

HSTS: Tarayıcıyı Eğitmek

SSL kurulumu tek başına yetmez. HTTP Strict Transport Security (HSTS) başlığı olmadan, kullanıcılar hala HTTP üzerinden sitenize ulaşabilir ve o ilk istekte güvensiz bağlantı kurulmuş olur. HSTS, tarayıcıya “bu siteye her zaman HTTPS ile bağlan, HTTP denemesini daha tarayıcı seviyesinde engelle” der.

# HSTS başlığını test etmek
curl -sI https://example.com | grep -i strict

# Beklenen çıktı:
# Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# HSTS preload listesine başvuru için minimum gereksinim kontrolü
# hstspreload.org sitesini kontrol edin veya şu araçla test edin:
curl -sI https://hstspreload.org/api/v2/status?domain=example.com

preload direktifini eklerseniz sitenizi Google’ın HSTS preload listesine ekleyebilirsiniz. Bu listedeki sitelere tarayıcılar hiçbir zaman HTTP bağlantısı kurmaz, sertifika bilgisi önceden tarayıcıya gömülmüş gibi davranır. Ama dikkat: bu listeden çıkmak aylar sürebilir, alt domain’lerinizin tamamının HTTPS desteklediğinden emin olmadan bu adımı atmayın.

Sertifika Türleri Arasındaki Fark

Teknik olarak şifreleme kalitesi açısından DV (Domain Validated), OV (Organization Validated) ve EV (Extended Validation) sertifikaları arasında fark yok. Fark, doğrulama seviyesinde:

  • DV Sertifikası: Sadece domain sahipliği doğrulanır. Anında verilir, Let’s Encrypt bu kategoride. Kişisel bloglar, küçük projeler için ideal.
  • OV Sertifikası: Domain sahipliği + organizasyon bilgileri doğrulanır. Kurumsal siteler için daha güvenilir görünür.
  • EV Sertifikası: En kapsamlı doğrulama. Eskiden tarayıcılarda yeşil adres çubuğu ve şirket adı gösteriyordu. Chrome ve Firefox bu görsel ayrımı kaldırdı ama hukuki ve finans sektöründe hala tercih ediliyor.

Finans ve e-devlet projelerinde OV veya EV sertifika şart koşuluyor çoğu zaman. Ama teknik olarak bir fark arayanlar hayal kırıklığına uğrar; şifreleme gücü aynı.

Gerçek Dünya Senaryosu: Karma İçerik Tuzağı

Geçen yıl bir kurumun sitesini HTTP’den HTTPS’e taşırken yaşadığım klasik bir sorun: sertifika kuruldu, yönlendirmeler çalışıyor, her şey güzel görünüyor. Ama tarayıcı konsolunda mixed content hataları yağıyor. Neden? Database’den çekilen ürün resimleri http:// ile başlayan URL’lerle saklanmıştı.

# Veritabanındaki HTTP URL'lerini bulmak ve düzeltmek (MySQL örneği)
# Önce ne kadar URL var görelim
mysql -u root -p veritabani_adi -e 
  "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%http://example.com%';"

# Güvenli kopyadan sonra update çalıştır
mysql -u root -p veritabani_adi -e 
  "UPDATE wp_posts SET post_content = REPLACE(post_content, 
   'http://example.com', 'https://example.com');"

# wp_postmeta tablosunu da güncelle
mysql -u root -p veritabani_adi -e 
  "UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 
   'http://example.com', 'https://example.com');"

WordPress kullananlar için “Better Search Replace” eklentisi bu işi GUI üzerinden yapıyor ama production ortamında her zaman önce yedek alın, her zaman.

Performans Endişesi: HTTPS Yavaş Mı?

Eski bir argüman: “HTTPS şifreleme yükü nedeniyle siteyi yavaşlatır.” 2010’larda belki bir miktar doğruydu. Bugün TLS 1.3 ile handshake süresi dramatik biçimde azaldı. HTTP/2 protokolü ise sadece HTTPS üzerinden çalışıyor ve multiplexing özelliğiyle aslında HTTP/1.1’den çok daha hızlı.

# HTTP/2 desteğini kontrol etmek
curl -sI --http2 https://example.com | head -5

# TLS handshake süresini ölçmek
curl -w "TLS handshake: %{time_appconnect}snToplam sure: %{time_total}sn" 
  -o /dev/null -s https://example.com

# HTTP/2 ile HTTP/1.1 karşılaştırması
curl -w "%{time_total}n" --http2 -o /dev/null -s https://example.com
curl -w "%{time_total}n" --http1.1 -o /dev/null -s https://example.com

Pratikte iyi optimize edilmiş bir HTTPS/HTTP2 sitesi, HTTP/1.1 sitesinden hız açısından üstün çıkıyor. Argüman artık tersine döndü.

Cookie Güvenliği ve Session Hijacking

HTTPS olmadan cookie’leriniz ağda düz metin olarak taşınıyor. Bir kullanıcı oturum açtıktan sonra session cookie’si çalınırsa, saldırgan o kullanıcı hesabını ele geçirebilir. Buna session hijacking deniyor.

Uygulama kodunuzda session cookie’lerini Secure ve HttpOnly bayraklarıyla işaretlemeniz gerekiyor. Ama bu bayraklar HTTPS olmadan anlamsız, Secure bayraklı cookie zaten HTTP üzerinden gönderilmiyor.

# Nginx'te cookie güvenlik ayarları
# proxy_pass kullanıyorsanız upstream'den gelen Set-Cookie başlığını düzenleyin

location / {
    proxy_pass http://backend;
    proxy_cookie_flags ~ secure httponly samesite=strict;
    
    # Ya da header manipulation ile
    proxy_hide_header Set-Cookie;
    add_header Set-Cookie $upstream_http_set_cookie;
}

# Apache ile cookie bayraklarını zorlamak
Header always edit Set-Cookie ^(.*)$ $1;Secure;HttpOnly;SameSite=Strict

Sonuç

SSL sertifikası artık “güvenlik bilincini gösteren isteğe bağlı bir ek” değil. Tarayıcılar yaptırım uyguluyor, arama motorları sıralama veriyor, kullanıcılar “Güvenli Değil” yazısı görünce kaçıyor ve en önemlisi, kullanıcılarınızın verileri gerçekten risk altında. Let’s Encrypt sayesinde maliyet argümanı da ortadan kalktı.

Eğer hala HTTP üzerinde çalışan bir sunucunuz varsa, bugün certbot kurulumunu yapın. Nginx veya Apache için otomatik yapılandırma seçenekleri mevcut, çoğu zaman tek komutla halloluyor. Sertifikayı aldıktan sonra HSTS başlığını ekleyin, mixed content kontrolünü yapın, cookie bayraklarını gözden geçirin.

Teknik borç gibi görünen bu şeyi bir gün ödeyeceksiniz, ya kendi isteğinizle bugün, ya da bir güvenlik olayının ardından yarın. İkincisi çok daha pahalıya geliyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir