TLS/HTTPS Nasıl Çalışır? El Sıkışma, Sertifikalar ve Güvenli Bağlantı

73Mesaj · 10-18-2026, 04:11 PM

[center]

[/center]

Selam TurkTeam, BlueTornado yazıyor.

Tarayıcınızdaki kilit simgesinin arkasında TLS (Transport Layer Security) vardır. HTTPS, HTTP'nin TLS ile şifrelenmiş kanal üzerinden taşınmasıdır. Bu rehberde TLS'in üç temel vaadini (gizlilik, bütünlük, kimlik doğrulama), TLS 1.3 el sıkışmasını adım adım, sertifika zincirinin nasıl doğrulandığını ve bunların hepsini kendi bilgisayarınızda openssl, curl ve Wireshark ile nasıl gözlemleyeceğinizi anlatıyorum. Simetrik/asimetrik şifreleme temellerini (AES, RSA) ayrı konuda işlediğimiz için burada TLS'in bunları nasıl bir araya getirdiğine odaklanıyoruz. Sunucu sıkılaştırma (Nginx ayarları) bu konunun kapsamı dışında.

Konuda Anlatılacaklar

TLS nedir, HTTPS ile ilişkisi
TLS'in sağladığı güvenceler ve sağlamadıkları
TLS 1.3 el sıkışması adım adım
X.509 sertifikaları ve güven zinciri
Lab: openssl s_client ile el sıkışmayı izlemek
Lab: kendi sertifikanızı üretip yerel TLS sunucusu açmak
Wireshark ile kendi trafiğinizi çözmek (SSLKEYLOGFILE)
İleri seviye: forward secrecy, 0-RTT, Certificate Transparency, sertifika ömürleri
Kaynakça ve yasal uyarı

1) TLS Nedir?
TLS, iki uç arasında şifreli ve kimliği doğrulanmış bir kanal kuran protokoldür. Eski adı SSL'dir; SSL 2.0/3.0 ile TLS 1.0 ve 1.1 artık güvensiz kabul edilir (RFC 8996, TLS 1.0 ve 1.1'i resmen kullanımdan kaldırdı). Güncel sürümler TLS 1.2 (RFC 5246) ve TLS 1.3'tür (RFC 8446). HTTPS'te tarayıcı önce TCP (veya HTTP/3'te QUIC) bağlantısı kurar, ardından TLS el sıkışmasını yapar ve HTTP isteklerini bu şifreli kanaldan gönderir.

TLS'in sağladıkları:

Gizlilik: Aradaki biri (aynı Wi-Fi, ISS) içeriği okuyamaz
Bütünlük: Trafik yolda değiştirilirse alıcı bunu fark eder (AEAD şifreleri)
Kimlik doğrulama: Konuştuğunuz sunucunun gerçekten o alan adının sahibi olduğu sertifika ile kanıtlanır

Sağlamadıkları: Sitenin kendisinin güvenilir olduğunu garanti etmez. Oltalama siteleri de geçerli sertifika alabilir; kilit simgesi "bağlantı şifreli" demektir, "site masum" demek değildir. Ayrıca bağlanılan alan adı (SNI) ve IP adresi, ek önlem (ör. Encrypted Client Hello) yoksa ağ gözlemcisine görünür.

Alıntı:Kilit simgesi = doğru sunucuyla şifreli konuşuyorsunuz. Sunucunun niyeti ayrı bir sorudur.

2) TLS 1.3 El Sıkışması Adım Adım
TLS 1.3 tam el sıkışma için yalnızca bir gidiş-dönüş (1-RTT) kullanır; TLS 1.2'de bu iki gidiş-dönüştü.

Kod:
İstemci                                   Sunucu
ClientHello
 + supported_versions, key_share,
 + signature_algorithms, server_name (SNI)  -------->
                                            ServerHello + key_share
                                            {EncryptedExtensions}
                                            {Certificate}
                                            {CertificateVerify}
                                   <-------- {Finished}
{Finished}                         -------->
[Uygulama verisi]                  <------->  [Uygulama verisi]

{} = el sıkışma anahtarlarıyla şifreli   [] = uygulama anahtarlarıyla şifreli

ClientHello: İstemci desteklediği sürümleri, şifre takımlarını ve tahmin ettiği grup için geçici (ephemeral) bir Diffie-Hellman açık anahtarını (key_share) gönderir. SNI ile hangi alan adına bağlandığını belirtir.
ServerHello: Sunucu sürümü ve şifre takımını seçer, kendi key_share'ini gönderir. Bu noktada iki taraf ortak bir sır hesaplar; buradan HKDF ile el sıkışma anahtarları türetilir.
EncryptedExtensions: Ek parametreler (ör. ALPN ile h2 seçimi), artık şifreli.
Certificate: Sunucunun sertifika zinciri.
CertificateVerify: Sunucu, el sıkışma dökümünü özel anahtarıyla imzalar. Böylece sertifikadaki açık anahtarın sahibi olduğunu kanıtlar.
Finished: Her iki taraf tüm dökümün MAC'ini gönderir; araya giren biri mesajları değiştirdiyse burada yakalanır.

TLS 1.3'te yalnızca beş şifre takımı tanımlıdır ve yaygın kullanılanlar şunlardır:

Kod:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

RSA ile anahtar taşıma ve statik DH tamamen kaldırıldı; her bağlantı geçici anahtar kullanır.

[center][/center]

3) Sertifikalar ve Güven Zinciri
Sertifika, bir açık anahtarı bir kimliğe (alan adına) bağlayan ve bir Sertifika Otoritesi (CA) tarafından imzalanmış X.509 belgesidir (RFC 5280). Tarayıcı şunları kontrol eder:

Zincir: Yaprak (sunucu) sertifikası -> ara (intermediate) CA -> işletim sistemi/tarayıcı deposundaki kök (root) CA. Her halkanın imzası bir üstteki ile doğrulanır.
Alan adı: Bağlanılan ad, Subject Alternative Name (SAN) listesinde olmalı. Modern tarayıcılar yalnızca CN'ye bakmaz.
Geçerlilik tarihleri: notBefore / notAfter.
Anahtar kullanımı: Extended Key Usage içinde serverAuth.
İptal ve şeffaflık: Tarayıcıya göre CRL tabanlı mekanizmalar ve Certificate Transparency kayıtları.

[center][/center]

Sunucu ara sertifikayı göndermeyi unutursa bazı istemcilerde "unable to get local issuer certificate" hatası alınır; bu sık görülen bir yapılandırma hatasıdır.

4) Lab: openssl s_client ile Gözlem
Herhangi bir halka açık HTTPS sitesine normal bir bağlantı kurmak sıradan tarayıcı davranışıdır; aşağıdaki komutlar yalnızca bağlantı bilgisini okur.

Kod:
# TLS 1.3 ile bağlan, SNI belirt, el sıkışma özetini gör
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Çıktı yorumu: Çıktıda "Certificate chain" bölümü zinciri (s: subject, i: issuer) listeler; altta protokol ve seçilen şifre takımı ile "Verify return code: 0 (ok)" satırı görünür. 0 dışındaki kod, doğrulamanın başarısız olduğunu ve nedenini söyler.

Kod:
# Sunucu sertifikasının ayrıntıları
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Kod:
# Zincirin tamamını PEM olarak kaydet
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > zincir.txt

Kod:
# curl ile el sıkışmayı ayrıntılı izlemek
curl -sv -o /dev/null https://example.com 2>&1 | grep -E 'SSL connection|ALPN|subject:|issuer:|expire date'

Kod:
# Belirli bir sürümün reddedildiğini test et (kendi sunucunuzda)
openssl s_client -connect localhost:4443 -tls1_1 </dev/null

[center][/center]

5) Lab: Kendi Sertifikanız ve Yerel TLS Sunucusu
Kendi bilgisayarınızda, yalnızca test amacıyla kendinden imzalı (self-signed) sertifika üretelim:

Kod:
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
  -keyout lab.key -out lab.crt -days 30 \
  -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Kod:
# Sertifikayı incele
openssl x509 -in lab.crt -noout -text | grep -A1 -E 'Subject:|Not After|Subject Alternative Name'

Kod:
# Basit test sunucusu (yalnızca localhost)
openssl s_server -accept 4443 -cert lab.crt -key lab.key -www

Başka terminalden:

Kod:
curl -v https://localhost:4443/              # güven hatası beklenir
curl -v --cacert lab.crt https://localhost:4443/   # sertifikaya güvenince geçer

Çıktı yorumu: İlk komutta curl, sertifikayı tanıdığı bir CA imzalamadığı için bağlantıyı reddeder. Bu tam olarak istenen davranıştır: kimlik doğrulanamayan sunucuya veri gönderilmez. İkinci komutta güven çapasını kendiniz verdiğiniz için doğrulama geçer. Üretimde curl -k veya "sertifika doğrulamayı kapat" seçeneklerini asla kullanmayın; bu, TLS'in kimlik doğrulama güvencesini tamamen ortadan kaldırır.

Gerçek alan adınız için ücretsiz ve otomatik sertifika Let's Encrypt ve certbot ile alınabilir:

Kod:
sudo certbot certonly --webroot -w /var/www/html -d alanadiniz.ornek
sudo certbot renew --dry-run   # yenileme otomasyonunu test et

6) Wireshark ile Kendi Trafiğinizi Çözmek
TLS trafiği Wireshark'ta okunamaz; bu iyi bir şeydir. Kendi tarayıcınızın veya curl'ün oturum anahtarlarını bir dosyaya yazdırarak yalnızca kendi trafiğinizi çözebilirsiniz:

Kod:
export SSLKEYLOGFILE="$HOME/tls-keys.log"
curl -s -o /dev/null https://example.com
# Wireshark: Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename = tls-keys.log

Kod:
# Faydalı görüntü filtreleri
tls.handshake.type == 1      # ClientHello
tls.handshake.type == 2      # ServerHello
tls.handshake.extensions_server_name

Anahtar dosyası, o oturumların tüm içeriğini açar; işiniz bitince silin ve kimseyle paylaşmayın.

[center][/center]

7) İleri Seviye
Forward secrecy: Her bağlantı geçici (EC)DHE anahtarlarıyla kurulduğu için sunucunun uzun ömürlü özel anahtarı ileride çalınsa bile geçmiş kayıtlı trafik çözülemez. TLS 1.3'te bu zorunludur.

Oturum devamı ve 0-RTT: TLS 1.3, önceki oturumdan alınan PSK ile ilk pakette veri göndermeye (0-RTT / early data) izin verir. Bu veri tekrar oynatma (replay) saldırısına açıktır; RFC 8446 de bu riski belirtir. Yalnızca idempotent istekler (GET gibi) için kullanılmalıdır.

Certificate Transparency (RFC 6962): Halka açık CA'ların verdiği sertifikalar kamuya açık loglara yazılır. Alan adınız için beklemediğiniz bir sertifika çıkarılıp çıkarılmadığını crt.sh gibi CT arama araçlarıyla izleyebilirsiniz. Savunma açısından kendi alan adlarınızı düzenli kontrol etmek iyi bir alışkanlıktır.

Sertifika ömürleri kısalıyor: CA/Browser Forum'un SC-081v3 kararına göre halka açık TLS sertifikalarının azami geçerliliği 15 Mart 2026'dan itibaren 200 gün, 15 Mart 2027'de 100 gün, 15 Mart 2029'da 47 gündür. Pratik sonuç: yenilemeyi elle değil, ACME (certbot vb.) ile otomatik yapın.

Kendi sunucunuzu denetlemek:

Kod:
nmap --script ssl-enum-ciphers -p 443 alanadiniz.ornek
./testssl.sh https://alanadiniz.ornek

Bu araçları yalnızca sahibi olduğunuz veya yazılı izin aldığınız sistemlerde çalıştırın.

Kontrol Listesi

Yalnızca TLS 1.2 ve 1.3 açık; 1.0/1.1 ve SSL kapalı
Sertifika SAN listesi tüm alan adlarını kapsıyor, ara sertifika gönderiliyor
Yenileme otomatik ve izleniyor (bitiş tarihi alarmı)
Uygulama kodunda sertifika doğrulaması asla kapatılmıyor
Özel anahtar dosyası yalnızca servis kullanıcısı tarafından okunabilir

Sonuç
TLS; geçici anahtar değişimi, sertifika ile kimlik doğrulama ve AEAD şifreleme parçalarını tek bir el sıkışmada birleştirir. openssl s_client ve kendi lab sunucunuzla bu adımları gözünüzle görmek, "sertifika hatası" mesajlarını okumayı ve doğru yapılandırmayı çok kolaylaştırır.

Kaynakça

Yasal Uyarı
Bu rehber bağlantılarınızı ve sunucularınızı korumak içindir. Trafik çözme ve TLS taramalarını yalnızca kendi sistemlerinizde, kendi trafiğinizde veya yazılı yetkili kapsamda yapın. Başkalarının haberleşmesine müdahale, izinsiz dinleme veya sistemlere yetkisiz erişim TCK 243-245 ve ilgili kanunlar kapsamında suç olabilir. Eğitim amaçlıdır.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

TLS/HTTPS Nasıl Çalışır? El Sıkışma, Sertifikalar ve Güvenli Bağlantı

Forum

Topluluk

Yardım