TurkTeam | Türk Siber Güvenlik Topluluğu - Kriptografi

eMudhra Sonrası: Tarayıcı Güvende, Ya Java ve CI Trust Store'ları?

Sat, 24 Oct 2026 11:31:09 +0300

Selamlar,

eMudhra ara CA özel anahtarlarının zayıf olduğu skandalında tarayıcılar hızla tepki verdi. Sonatype'ın 23 Ekim 2026 yazısı ise asıl soruyu soruyor: kurumunuzdaki diğer araçlar hâlâ etkilenen zincirlere güveniyor mu? Java cacerts, Node, Python, Go, Git ve sistem demetleri ayrı ayrı güncellenmeden "tarayıcı düzeldi" demek yetmez.

Konuda anlatılacaklar

Neden tek trust store yetmiyor?
Sonatype Audit and Fix betiği
Betiğin görmedikleri
Pratik yol haritası

1. Neden tek trust store yetmiyor?
Bir makinede tarayıcı işletim sistemi deposunu kullanırken JDK kendi cacerts dosyasını, bazı CLI araçları gömülü kökleri kullanır. Birini güncellemek diğerlerini güncellemez. Filippo Valsorda'nın deyişiyle bu, Heartbleed'den büyük bir temizlik işi; IoT, Docker ve unutulmuş Linux kutuları uzun kuyruk oluşturur.

2. Sonatype betiği
Paul Horton'un açık kaynak eMudhra Audit and Fix betiği Unix benzeri makinelerde Java, Node.js, Python, Go, Git ve sistem demetlerini tarar. Desteklenen yerlerde etkilenen ara CA'lara zincirlenen test sunucularına HTTPS isteği atar; kontrol için GitHub'a da bakar. Varsayılan olarak hiçbir şeyi değiştirmez. --no-network yalnızca sürüm kontrolü yapar; --dry-run / --fix isteğe bağlıdır.

3. Betiğin görmedikleri
Uzak sunucular, konteyner imajları, CI ajanları, üretim hostları ve proje bağımlılıkları taranmaz. Geliştirici dizüstü bilgisayar sonucu kurumsal durum demek değildir.

4. Pratik yol haritası

Önce OS ve tarayıcı güncellemelerini tamamlayın.
Geliştirici iş istasyonlarında betiği çalıştırıp çıktıyı envantere işleyin.
CI runner ve temel konteyner imajlarını ayrı süreçle yenileyin.
Java uygulamalarında cacerts / özel trust store yollarını bulun.
Tedarikçi yamasını tercihen kullanın; elle sertifika silmeyi test edin.

CI ajanlarınızın trust store durumunu kim izliyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

15-b05-emudhra-trust-store.png (Dosya Boyutu: 112.25 KB / İndirme Sayısı: 2)

eMudhra Skandalı: P-384 Özel Anahtarı 4 Çıktı, Sekiz Ara CA Sertifikası İptal Edildi

Thu, 22 Oct 2026 11:19:01 +0300

Selamlar,

Kriptografide "algoritma güçlü ama anahtar zayıf" senaryosunun bundan daha net bir örneğini görmek zor. Sertifika otoritesi eMudhra, sekiz ara (intermediate) sertifikasını iptal etti; çünkü bu sertifikaların özel anahtarları o kadar küçüktü ki herkes neredeyse anında kurtarabiliyordu. Bu anahtarlarla büyük tarayıcıların ve işletim sistemlerinin güvendiği, meşru siteler adına sahte sertifikalar üretmek mümkündü.

Konuda anlatılacaklar

Ne bulundu, nasıl bulundu?
"Değeri 256'dan küçük P-384 anahtarı" ne demek?
Tarayıcılar ve yazılım ekosistemi nasıl tepki verdi?
Kendi sistemlerinizde kontrol listesi

Ne bulundu?
BleepingComputer'ın aktardığına göre Wayne takma adlı bir araştırmacı 17 Ekim'de kamuya açık sertifika verilerini tararken zayıflığı fark etti. Mozilla'nın olay raporuna göre sekiz sertifikanın tamamı Nisan 2025'te üretilmiş P-384 özel anahtarları kullanıyordu ve bu anahtarların değerleri 256'dan küçüktü. Yani anahtarı bulmak için yalnızca 256 olasılığı denemek yeterliydi.

Araştırmacı Flüpke zayıflığı göstermek için ele geçen anahtarlardan birini GitHub'da yayınladı: eMudhra'nın "EM OV TLS CA - G3C" sertifikasının özel anahtar değeri sadece 4 idi. BleepingComputer yayınlanan anahtarın iptal edilen sertifikalardan biriyle eşleştiğini bağımsız olarak doğruladı.

Teknik açıdan: neden felaket?
Eliptik eğri kriptografisinde (ECDSA) özel anahtar, eğrinin mertebesinden küçük rastgele bir tam sayıdır; açık anahtar ise bu sayının eğri üzerindeki üreteç noktasıyla çarpımıdır. P-384 eğrisinde güvenlik, özel anahtarın yaklaşık 384 bitlik uzaydan rastgele seçilmesine dayanır. Anahtar 1 ile 255 arasında bir değerse, saldırganın yapması gereken tek şey bu değerleri sırayla deneyip açık anahtarla karşılaştırmaktır; bu, sıradan bir bilgisayarda anlık bir iştir.

Burada algoritma kırılmadı; anahtar üretim süreci bozuldu. eMudhra'nın Mozilla'ya açıklamasına göre Nisan 2025'te sertifikaları üreten bir betikteki hata ikinci bir zayıf anahtar seti üretti ve bu anahtarlar, düzgün üretilmiş anahtarlara benzer etiketler taşıdığı için yanlışlıkla imzalama için seçildi. Bazı sertifikalar Sectigo'ya çapraz imza için de gönderilmişti.

Kod:
# Mantığı anlamak için kavramsal örnek (lab, Python + cryptography)
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import serialization
hedef = ec.derive_private_key(4, ec.SECP384R1()).public_key()   # "zayıf" anahtar
hp = hedef.public_bytes(serialization.Encoding.X962, serialization.PublicFormat.UncompressedPoint)
for d in range(1, 256):
    k = ec.derive_private_key(d, ec.SECP384R1()).public_key()
    if k.public_bytes(serialization.Encoding.X962, serialization.PublicFormat.UncompressedPoint) == hp:
        print("ozel anahtar bulundu:", d); break

Bu örnek yalnızca kavramı gösterir: rastgelelik yoksa, en güçlü eğri bile hiçbir şey ifade etmez.

Ekosistem nasıl tepki verdi?

eMudhra: Sekiz sertifikayı iptal etti ve G3 kökü altında yeni sertifika vermeyi durdurdu. Şirket, etkilenen ara sertifikaların çoğunun üretimde kullanılmadığını ve son kullanıcılara sertifika verildiğine dair kanıt bulmadığını söylüyor. Ancak anahtarlar Nisan 2025'ten beri kurtarılabilir durumdaydı.
Mozilla: 17 Ekim'de OneCRL ile sertifikaları engelledi (güncelleme veya yeniden başlatma gerekmeden). 20 Ekim'de Firefox 158.0.1 ve ESR güncellemeleri yayınlandı.
Google Chrome: TLS sertifikası verme yetkisi olan altı ara sertifikayı aynı gün engelledi.
Apple: 19 Ekim'de koruma ekledi.
Go: 1.27.3 ve 1.26.10 sürümleri sorunu CVE-2026-111943 olarak ele alıyor.

Kendi sistemlerinizde kontrol listesi
Kendi sertifika deposunu kullanan veya iptal kontrolü yapmayan yazılımlar, güncellenene kadar bu ara sertifikalara güvenmeye devam edebilir. BleepingComputer'ın tablosundaki bazı yamalı sürümler:

Kod:
NSS                  3.131.1
Python certifi       2026.10.19
pip                  26.2.2
uv                   0.13.4
Go                   1.27.3 / 1.26.10
rustls-webpki        0.103.16
webpki-roots         1.0.10
Electron             44.9.1 / 43.8.1 / 42.11.16
Composer ca-bundle   1.4.16 / 1.6.0
Alpine ca-certificates 20261020-r0
curl CA bundle       2026-10-20
Debian, FreeBSD, Node.js, Bun: haber tarihinde "bekliyor"

Mozilla kriptografi mühendisi Dennis Jackson ayrıca macOS'teki yerleşik /usr/bin/curl aracının, sertifika paketinin iptal bilgisini kontrol etmemesi nedeniyle bu sertifikalara güvenmeye devam edebileceği uyarısında bulundu.

Kod:
# Linux/Python ortamında hızlı sürüm kontrolü
python3 -c "import certifi; print(certifi.__version__)"
pip --version
go version 2>/dev/null
dpkg -l ca-certificates 2>/dev/null | tail -1

Ders
Kriptografide en zayıf halka çoğu zaman matematik değil, operasyondur: anahtar üretimi, etiketleme, betik hataları ve denetim. HSM içinde üretilen, üretim sonrası istatistiksel kontrolden geçirilen ve sertifika şeffaflığı (CT) loglarıyla izlenen anahtarlar bu tür hataları erken yakalamanın yoludur.

Sizin kurumda sertifika deposu güncellemeleri nasıl yönetiliyor? Konteyner imajlarında ca-certificates paketini ne sıklıkla yeniliyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

https://www.bleepingcomputer.com/news/se...tificates/

05-t05-emudhra-zayif-anahtar.png (Dosya Boyutu: 121.69 KB / İndirme Sayısı: 4)

Sertifika Pinning Ne Zaman Mantıklı? Mobil ve API İçin Değerlendirme

Mon, 19 Oct 2026 02:21:08 +0300

Merhaba,

Sertifika pinning (certificate pinning) mobil uygulamada veya kalın istemcide "yalnızca şu genel anahtar / sertifika zincirine güven" demektir. MITM'i zorlaştırır ama operasyonel maliyeti vardır. Bu yazıda ne zaman mantıklı olduğunu ve alternatifleri konuşuyorum.

Ne işe yarar?
Kullanıcı cihazında özel CA ile traffic interception (kurumsal proxy, saldırgan proxy) yapıldığında uygulama bağlantıyı reddedebilir. Bankacılık / yüksek riskli uygulamalarda hâlâ tercih edilen bir kontroldür.

Ne zaman mantıklı?

Yüksek değerli oturum (finans, sağlık)
Kendi backend sertifika yaşam döngünüzü kontrol edebiliyorsanız
Pin'i güncelleyecek uygulama güncelleme kanalınız güvenilir ve hızlıysa

Ne zaman zararlı / gereksiz?

Sık değişen CDN sertifikaları + sabit pin = üretim kesintisi
Küçük ekip, pin rotasyon prosedürü yok
Yalnızca "güvenlik tiyatrosu" için; telemetri ve auth zayıfsa pin yetmez

HPKP notu
HTTP Public Key Pinning (HPKP) tarayıcılarda deprecated / kaldırıldı. Web için modern yol: doğru sertifika yönetimi, CAA, CT izleme, HSTS. Pinning konuşurken HPKP'yi "yapın" diye önermeyin.

Mobilde pratik
Android Network Security Config ile domain'e pin eklenebilir; iOS'ta URLSession / TrustKit benzeri yaklaşımlar. Pin'i leaf yerine intermediate / SPKI pinlemek rotasyonu kolaylaştırabilir. Yedek pin (backup pin) şart.

Operasyon kontrol listesi

Sertifika yenileme takvimi + pin güncelleme PR'ı
Acil "pin kill switch" (uzak config) — dikkatli tasarlanmalı
Break-glass: pin başarısızlığında telemetri
Pentest: pinning varken güvenlik testi için debug build süreci

Alternatif / tamamlayıcı

Certificate Transparency monitoring
Short-lived certificates
mTLS (istemci sertifikası) — farklı tehdit modeli
App Attest / Play Integrity (cihaz bütünlüğü; pinning yerine geçmez)

Kaynaklar

OWASP MASVS / MASTG - network security
Android Network Security Config docs
Mozilla / Chromium HPKP deprecation notları

Siz production'da SPKI pin mi, yoksa CA pin mi kullanıyorsunuz? Rotasyon kazası yaşayan var mı?

Debug ve pentest build
Pinning açıkken güvenlik testi için ayrı debug build (pin kapalı veya user CA'ya izin) şart. Production APK'da pin kapatma backdoor'u bırakmayın. Remote config ile pin kapatmak mümkünse o kanalın bütünlüğünü (imza) sağlayın.

API istemcileri
Mobil dışı kalın istemcilerde (masaüstü agent) pinning benzeri certificate binding kullanılabilir. Rotasyon runbook'u olmadan production'a pin eklemek, kendi kendine DoS'tur.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

100-n22-2bb0fb.png (Dosya Boyutu: 61.85 KB / İndirme Sayısı: 13)

n22-inner.png (Dosya Boyutu: 17.45 KB / İndirme Sayısı: 14)

Parolaları Güvenli Saklama: Salt, bcrypt ve Argon2 Rehberi

Sun, 18 Oct 2026 21:04:51 +0300

[center]

[/center]

Selam millet, BlueTornado yazıyor.

Veri sızıntılarında en acı senaryolardan biri, kullanıcı parolalarının düz metin veya hızlı hash ile saklanmış olmasıdır. Bu rehberde salt'ın rolünü, neden düz SHA-256 yetmediğini, bcrypt ve Argon2id kullanımını ve OWASP önerilerini lab örnekleriyle anlatıyoruz. Hashcat konusu ayrıca işlendiği için burada kırma değil, doğru saklama odaklıyız.

Konuda Anlatılacaklar

Parola saklama tehdit modeli
Salt, pepper, yavaşlık (key stretching)
bcrypt kullanımı
Argon2id (tercih edilen modern seçim)
Migrasyon ve doğrulama akışı
İleri seviye: parametre seçimi, MFA, passkey
Kaynakça ve yasal uyarı

1) Tehdit Modeli
Saldırgan veritabanı yedeğinizi ele geçirdiğinde ne olur?

Düz metin: tüm hesaplar anında açılır; parola reuse ile başka siteler risk altında
Hızlı hash (MD5/SHA-1/SHA-256, tuzsuz): GPU ile toplu kırma pratik
Yavaş KDF + unique salt: her parola için maliyetli deneme; iyi parolalar korunur

Alıntı:Hash'lemek "şifrelemek" değildir. Parolayı geri çözmeniz gerekmez; her girişte aynı KDF ile doğrularsınız.

OWASP Password Storage Cheat Sheet, modern uygulamalar için Argon2id'yi tercih edilen seçenek olarak listeler; bcrypt kabul edilebilir bir alternatiftir.

2) Salt ve Pepper
Salt: Her kullanıcı/parola için benzersiz rastgele değer. Aynı parola farklı hash üretir; rainbow table etkisizleşir. Salt gizlidir sanılmamalı; hash ile birlikte DB'de tutulur.

Pepper: Uygulama/sunucu tarafında tutulan ek gizli değer (KMS veya config). DB sızsa bile pepper olmadan doğrulama zorlaşır. Pepper'ı git'e yazmayın.

Kod:
# Kavramsal
stored = argon2id(password, salt, params, pepper?)
# Doğrulama: aynı params ile verify

[center][/center]

3) bcrypt Lab

Kod:
pip install bcrypt
python3 - <<'PY'
import bcrypt
password = b"LabParola!2026"
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))
print(hashed)
print(bcrypt.checkpw(password, hashed))
print(bcrypt.checkpw(b"yanlis", hashed))
PY

Kod:
# Çıktı örneği (her seferinde farklı salt -> farklı string)
# $2b$12$...

Dikkat: bcrypt bazı uygulamalarda 72 byte sınırına sahiptir; çok uzun parolalarda önce SHA-256 sonra bcrypt gibi sarmalamalar tartışılır — kütüphane dokümantasyonunu okuyun. Mümkünse Argon2id tercih edin.

4) Argon2id Lab
Argon2, Password Hashing Competition kazananıdır. Argon2id, side-channel ve GPU saldırılarına karşı dengeli bir varyanttır.

Kod:
pip install argon2-cffi
python3 - <<'PY'
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher(
    time_cost=3,
    memory_cost=65536,  # KiB cinsinden; donanımınıza göre ayarlayın
    parallelism=2,
)
h = ph.hash("LabParola!2026")
print(h)
print(ph.verify(h, "LabParola!2026"))
try:
    ph.verify(h, "yanlis")
except VerifyMismatchError:
    print("mismatch ok")
print("needs_rehash", ph.check_needs_rehash(h))
PY

[center][/center]

Parametreleri seçerken: giriş başına CPU/RAM maliyeti kabul edilebilir olmalı; brute-force ise pahalı olmalı. OWASP cheat sheet güncel parametre önerilerini kontrol edin (donanım yıllarına göre değişebilir).

5) Uygulama Akışı

Kod:
# Kayıt
hash = ph.hash(password)
db.save(user, password_hash=hash)

# Giriş
if ph.verify(user.password_hash, password):
    if ph.check_needs_rehash(user.password_hash):
        user.password_hash = ph.hash(password)
        db.save(user)
    login_success()
else:
    login_fail()  # sabit zamanlı mesaj; kullanıcı var/yok sızdırmayın

Kod:
# YANLIŞ
hashlib.sha256(password.encode()).hexdigest()
# YANLIŞ
base64.b64encode(password.encode())
# YANLIŞ
AES_encrypt(password, server_key)  # parola saklama için KDF tercih edilir

Migrasyon: Eski SHA-256 kullanıcıları giriş yaptığında yeni Argon2id'ye yükseltin (transparent rehash). Toplu "hepsini bir gecede dönüştür" için eski hash'leri bilemiyorsanız kullanıcı parola sıfırlama gerekebilir.

6) Ek Kontroller

Kayıt/şifre değişiminde uzunluk ve breached password kontrolü (Have I Been Pwned Pwned Passwords API, k-anonymity)
Rate limit + MFA
Password reset token'ları tek kullanımlık ve kısa ömürlü
Loglarda parola ve hash yazmayın
Yedekleri şifreleyin; DB erişimini least privilege yapın

Kod:
# Pwned Passwords k-anonymity fikri (kavramsal)
# SHA-1(parola)'nın ilk 5 karakterini API'ye gönder, sonek listesinde ara
# Parolanın tamamını göndermeyin

[center][/center]

7) İleri Seviye
Passkey / WebAuthn: Parola yerine phishing-resistant kimlik doğrulama. Parola yükünü azaltır.

Composition policy: NIST SP 800-63B, karmaşık zorunlu karakter setlerinden ziyade uzunluk + blacklist (yaygın/parola sızıntısı) vurgular. Kurum politikanızı güncel rehberlerle hizalayın.

HSM / KMS pepper: Pepper'ı uygulama belleğinden ayrı tutmak ihlal etkisini azaltır.

Kod:
# Rapor / mimari not dili
Parola saklama: Argon2id (argon2-cffi), time_cost=3, memory_cost=65536, parallelism=2
Salt: kütüphane tarafından unique
Pepper: yok/var (KMS)
Migrasyon: SHA-256 -> Argon2id on-login

8) Sonuç
Parolaları Base64 veya düz SHA ile saklamayın. Unique salt + Argon2id (veya bcrypt) + dengeli parametreler + MFA temel pakettir. Sızıntı olsa bile iyi parolaların toplu kırılmasını zorlaştırmak hedeflenir.

Ek: Operasyonel Senaryolar
Sızıntı sonrası: Tüm oturumları iptal edin, kullanıcıları bilgilendirin (KVKK süreçleri), zorla parola yenileme veya "girişte rehash + MFA zorunlu" uygulayın. Hash algoritmanız zayıfsa aciliyet artar.

Eski mobil uygulama: Eski istemci hâlâ SHA-1 hash gönderiyorsa sunucu tarafında kabul etmeyin; protokolü yükseltin.

Kod:
# Doğrulama maliyeti ölçümü (lab)
python3 - <<'PY'
import time
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=2)
t0=time.time(); ph.hash("x"*12); print("hash_s", round(time.time()-t0,3))
PY

Hedef: meşru girişte yüzlerce ms kabul edilebilir; kitle brute-force'ta ise pahalı. Aşırı yüksek maliyet DoS'a dönüşebilir; login rate limit ile birlikte düşünün.

[center][/center]

Unutmayın: Teknik KDF doğru olsa bile kullanıcı "123456" seçerse risk devam eder; breached password engeli ve passkey geçişi tamamlayıcıdır.

Ek Lab Komutları

Kod:
# bcrypt maliyeti karşılaştırması
python3 - <<'PY'
import bcrypt, time
for r in (10, 12, 14):
    t=time.time(); bcrypt.hashpw(b"x", bcrypt.gensalt(r)); print(r, round(time.time()-t,3),"s")
PY

Kod:
# Argon2 parametre dizesini okuma
python3 - <<'PY'
from argon2 import PasswordHasher
h=PasswordHasher().hash("demo")
print(h.split("$")[:5])
PY

Kod:
# Secrets ile salt üretimi (elle saklama senaryosu - genelde kütüphane yapar)
python3 -c "import secrets; print(secrets.token_bytes(16).hex())"

Kaynakça

Yasal Uyarı
Bu içerik savunma ve güvenli yazılım geliştirme içindir. Başkalarına ait parola hash'lerini izinsiz kırmaya çalışmak veya sistemlere yetkisiz girmek TCK 243-245 kapsamında suç olabilir. Lab parolalarını üretimde kullanmayın; sorumluluk uygulayana aittir.

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).

000-team-new-b261c5.png (Dosya Boyutu: 61.36 KB / İndirme Sayısı: 9)

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

Sun, 18 Oct 2026 19:11:25 +0300

[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 



Çı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 \
  | 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  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 


[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 ListesiYalnı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çaRFC 8446 - TLS 1.3


RFC 5246 - TLS 1.2


RFC 8996 - TLS 1.0 ve 1.1'in kullanımdan kaldırılması


RFC 5280 - X.509 Sertifika Profili


RFC 6962 - Certificate Transparency


MDN - Transport Layer Security


OWASP TLS Cheat Sheet


OpenSSL s_client dokümantasyonu


CA/Browser Forum Ballot SC-081v3


Let's Encrypt dokümantasyonu


Wireshark Wiki - TLS





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).




  000-team-new-3477f7.png (Dosya Boyutu: 61.97 KB / İndirme Sayısı: 8)



Simetrik ve Asimetrik Şifreleme Farkı: AES ve RSA Temelleri
Sun, 18 Oct 2026 18:20:51 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado ile.



"Veriyi şifreledik" cümlesi tek başına yetmez: hangi model, hangi algoritma, anahtar nerede? Bu rehberde simetrik (AES) ile asimetrik (RSA/ECC) şifrelemenin farkını, ne zaman hangisinin kullanıldığını ve OpenSSL ile zararsız lab örneklerini anlatıyoruz. Hash/encoding farkı ve parola KDF konuları forumda ayrıca işlenir.



Konuda Anlatılacaklar

Simetrik vs asimetrik: anahtar modeli


AES temelleri ve modlar


RSA/ECC: şifreleme ve imza


Hibrit şifreleme (TLS'in özü)


Lab: OpenSSL ile denemeler


İleri seviye: AEAD, anahtar ömrü, post-quantum notu


Kaynakça ve yasal uyarı





1) İki Model

Simetrik: Aynı gizli anahtar hem şifreler hem çözer. Hızlıdır; büyük veri için uygundur. Anahtar dağıtımı zordur (her iki taraf aynı sırrı güvenli paylaşmalı).



Asimetrik: Açık anahtar (public) ve özel anahtar (private). Public ile şifrelenen private ile açılır (şifreleme modeli). İmzada tersi: private imzalar, public doğrular. Yavaştır; genelde küçük veri / anahtar sarma / imza için kullanılır.



Kod:
# Kavramsal
Simetrik:  AES(key, plaintext) <-> AES(key, ciphertext)
Asimetrik: Encrypt(pub, msg)  <-> Decrypt(priv, ct)
İmza:      Sign(priv, msg)    <-> Verify(pub, sig, msg)


Alıntı:AES "daha iyi RSA" değildir; farklı işler yaparlar. Gerçek sistemler çoğunlukla ikisini birlikte kullanır (hibrit).


2) AES (Simetrik) Temelleri

AES blok şifresidir (128-bit blok). Anahtar uzunlukları: 128, 192, 256 bit. Güvenlik sadece "AES-256 seçtik" ile bitmez; mod ve IV/nonce yönetimi kritiktir.

ECB: Aynı blok aynı çıktı -> kalıp sızdırır; kullanmayın


CBC: IV gerekir; dolgu (padding) oracle tarihsel riskleri


GCM (AEAD): Gizlilik + bütünlük; modern varsayılan tercih


ChaCha20-Poly1305: AEAD alternatif (özellikle yazılımda hızlı)





Kod:
# OpenSSL enc lab (AES-256-CBC + PBKDF2) - sadece eğitim
openssl rand -out /tmp/aes.key 32
echo -n "turkteam lab notu" > /tmp/pt.txt
openssl enc -aes-256-cbc -pbkdf2 -in /tmp/pt.txt -out /tmp/ct.bin -pass file:/tmp/aes.key
openssl enc -d -aes-256-cbc -pbkdf2 -in /tmp/ct.bin -out /tmp/pt2.txt -pass file:/tmp/aes.key
cat /tmp/pt2.txt
rm -f /tmp/aes.key /tmp/pt.txt /tmp/ct.bin /tmp/pt2.txt


Üretimde kendi CBC sarmalayıcınızı yazmak yerine libsodium, OpenSSL EVP AEAD, dilin güvenilir kütüphanelerini kullanın.



[center][/center]



3) RSA ve ECC (Asimetrik)

RSA, büyük tamsayı çarpanlara ayırma zorluğuna dayanan klasik genel anahtar sistemidir. Günümüzde anahtar sarma ve dijital imza için hâlâ görülür; yeni tasarımlarda ECC (elliptik eğri) daha kısa anahtarlarla benzer güvenlik seviyesi sunar (ör. ECDSA P-256, Ed25519 imza).



Kod:
# RSA anahtar çifti lab
openssl genrsa -out /tmp/priv.pem 2048
openssl rsa -in /tmp/priv.pem -pubout -out /tmp/pub.pem
echo -n "kucuk mesaj" > /tmp/msg.txt
openssl pkeyutl -encrypt -pubin -inkey /tmp/pub.pem -in /tmp/msg.txt -out /tmp/msg.enc
openssl pkeyutl -decrypt -inkey /tmp/priv.pem -in /tmp/msg.enc -out /tmp/msg.dec
cat /tmp/msg.dec
rm -f /tmp/priv.pem /tmp/pub.pem /tmp/msg.txt /tmp/msg.enc /tmp/msg.dec


Kod:
# Ed25519 imza örneği
openssl genpkey -algorithm Ed25519 -out /tmp/ed.priv
openssl pkey -in /tmp/ed.priv -pubout -out /tmp/ed.pub
echo -n "rapor ozeti" > /tmp/r.txt
openssl pkeyutl -sign -inkey /tmp/ed.priv -in /tmp/r.txt -out /tmp/r.sig
openssl pkeyutl -verify -pubin -inkey /tmp/ed.pub -in /tmp/r.txt -sigfile /tmp/r.sig
rm -f /tmp/ed.priv /tmp/ed.pub /tmp/r.txt /tmp/r.sig


RSA ile büyük dosya şifrelemeyin; yavaştır ve pratikte hibrit kullanılır.



4) Hibrit Şifreleme (TLS'in Mantığı)

Alice rastgele bir simetrik oturum anahtarı üretir


Bu anahtarı Bob'un public key'i ile sarar (veya Diffie-Hellman ile ortak anahtar türetir)


Asıl veri AES-GCM ile şifrelenir


Bob private key / DH ile oturum anahtarını elde eder ve veriyi çözer





TLS el sıkışması bu fikrin standardize, sertifikalı ve çok daha ayrıntılı halidir.



Kod:
# Kendi sunucunuzun TLS bilgisini görün
echo | openssl s_client -connect turkteam.org:443 -servername turkteam.org 2>/dev/null | egrep "Protocol|Cipher"


[center][/center]



5) Ne Zaman Hangisi?Diskteki büyük yedek / dosya: simetrik (AES-GCM), anahtar KMS'te


Anahtar dağıtımı / ilk güven: asimetrik veya DH + sertifika


Yazılım güncellemesi doğrulama: dijital imza (asimetrik)


Parola saklama: şifreleme değil, Argon2id gibi KDF


API bütünlüğü: HMAC (simetrik) veya imza (asimetrik)





Kod:
# Karar özeti
Gizlilik + hız          -> AES-GCM
Kimlik / imza           -> Ed25519 / ECDSA / RSA-PSS
İnternet oturumu        -> TLS (hibrit)
Parola                  -> KDF (hash ailesi, şifreleme değil)


6) İleri Seviye NotlarNonce/IV yeniden kullanımı: GCM'de aynı anahtar+nonce felakettir


Padding oracle: Kendi CBC+PKCS7 protokolünüzü yazmayın


Anahtar ömrü: Rotate; sızan anahtar için olay planı


Side-channel: Sabit zamanlı karşılaştırma; amatör crypto implementasyonu riskli


Post-quantum: NIST PQC standartları (ML-KEM vb.) geçiş planlarında konuşuluyor; abartılı panik yerine envanter çıkarın





Kod:
python3 - <<'PY'
import secrets, hmac, hashlib
print("key", secrets.token_bytes(32).hex())
print("hmac", hmac.new(b"k", b"msg", hashlib.sha256).hexdigest())
PY


[center][/center]



7) Sonuç

Simetrik hız ve toplu gizlilik; asimetrik anahtar dağıtımı ve imza demektir. AES ve RSA rakip değil, tamamlayıcıdır. Labda OpenSSL ile deneyin; üretimde hazır, incelenmiş kütüphaneler ve KMS kullanın.







Ek: Geliştirici Anti-Pattern Listesi

Kod:
# 1) ECB ile "AES yaptık" demek
# 2) IV'yi sabit 0x00.. seçmek
# 3) RSA PKCS#1 v1.5 ile yeni protokol tasarlamak (mümkünse OAEP / modern KEM)
# 4) Private key'i uygulama imajına gömmek
# 5) "Gizlilik için" hash kullanmak
# 6) Kendi TLS'inizi yazmak
Kütüphane seçimi: bakımı yapılan, sabit zamanlı ilkel sunan


Protokol seçimi: TLS 1.2+ (tercihen 1.3), zayıf suite'leri kapatın


Anahtar: en az AES-128 güvenliğine denk; pratikte AES-256 ve 2048+ RSA veya ECC





[center][/center]



Şüphede kalırsanız: hazır yüksek seviye API (libsodium sealed box, age, Tink) kullanın; düşük seviye blok şifre modlarını kendiniz birleştirmeyin.







Ek Lab Komutları

Kod:
# Rastgele AES anahtarı ve nonce (GCM için nonce 12 byte tipik)
openssl rand -hex 32
openssl rand -hex 12


Kod:
# Public key parmak izi (kendi anahtarınız)
openssl pkey -pubin -in /tmp/ed.pub -outform DER 2>/dev/null | openssl dgst -sha256


Kod:
# TLS 1.3 cipher gözlemi (kendi host)
echo | openssl s_client -connect 127.0.0.1:443 -tls1_3 2>/dev/null | head


KaynakçaOWASP Cryptographic Storage Cheat Sheet


OpenSSL man sayfaları


NIST FIPS 197 - AES


RFC 8446 - TLS 1.3


NIST Post-Quantum Cryptography


OWASP A02 Cryptographic Failures





Yasal Uyarı

Kriptografi eğitimi sistemleri korumak içindir. İzinsiz şifre çözme, haberleşmeye müdahale veya sistemlere yetkisiz erişim TCK 243-245 ve ilgili kanunlar kapsamında suç olabilir. Lab anahtarlarını üretimde kullanmayın.



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).




  000-team-new-2bdbcf.png (Dosya Boyutu: 58.23 KB / İndirme Sayısı: 9)



Hash Şifreleme Encoding Farkı: Kriptografi Temelleri Rehberi
Fri, 16 Oct 2026 11:18:41 +0300



Hash, Şifreleme ve Encoding: Karıştırmayın



Merhaba,



Güvenlik tartışmalarında en çok karışan üç kavram: hash, şifreleme (encryption) ve encoding. Bu rehberde farklarını, ne zaman hangisinin kullanılacağını ve sık yapılan hataları anlatıyoruz.



Konuda Anlatılacaklar

Encoding nedir? (Base64, URL encoding)


Hash nedir? (SHA-256, Blake2)


Şifreleme nedir? (AES, RSA)


Parola saklama: Hash + salt + KDF


Pratik komutlar





1) Encoding

Amacı gizlilik değil, temsil değiştirmektir. Base64 çözen herkes orijinal veriyi görür.

Kod:
echo -n "turkteam" | base64
echo "dHVya3RlYW0=" | base64 -d


2) Hash

Tek yönlü özet. Aynı girdi -> aynı çıktı; girdiyi geri elde etmek tasarım gereği zor.

Kod:
echo -n "turkteam" | sha256sum
# Dosya bütünlüğü
sha256sum rapor.pdf
Hash şifreleme değildir; "hash'leyip sakladık, kimse okuyamaz" ifadesi yanlıştır (özellikle zayıf/tuzsuz parola hash'leri).



3) Şifreleme

Anahtarla geri dönüşümlü dönüşüm. Simetrik (AES) ve asimetrik (RSA/ECC) aileleri vardır.

Kod:
# OpenSSL ile örnek (lab)
openssl rand -hex 16 > key.bin
echo -n "gizli lab notu" | openssl enc -aes-256-cbc -pbkdf2 -pass file:key.bin -out not.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass file:key.bin -in not.enc


4) Parola SaklamaDüz metin veya Base64: asla


Tek başına SHA-256: yetersiz (GPU ile kırılır)


Doğru yaklaşım: Argon2id / bcrypt / scrypt gibi yavaş KDF + benzersiz salt





5) Hızlı Karar TablosuVeriyi geri okumam gerekiyor mu? -> Şifreleme


Bütünlük / parmak izi mi? -> Hash (HMAC ile daha iyisi)


Sadece taşıma formatı mı? -> Encoding


Kullanıcı parolası mı? -> KDF (Argon2id)





KaynakçaOWASP Password Storage Cheat Sheet


OpenSSL Documentation


OWASP Top 10 2025 - A04 Cryptographic Failures





Görsel: TurkTeam özgün kapak görseli.




  tonyukuk-16.jpg (Dosya Boyutu: 100.34 KB / İndirme Sayısı: 9)