SSL TLS ve HSTS Başlığı Kontrolü: Kilit Neyi Garanti Eder

Adres çubuğundaki kilit simgesi tek bir şeyi söyler: tarayıcınız ile sunucu arasındaki trafik şifrelenmiştir. Aradaki ağda oturan biri, açtığınız sayfanın içeriğini, doldurduğunuz formu veya gönderdiğiniz parolayı okuyamaz, yolda değiştiremez.

Kilidin söylemediği şeylerin listesi ise çok daha uzundur. Sitenin arkasındaki şirketin gerçekten var olduğunu, siparişi göndereceğini, verinizi üçüncü taraflara satmayacağını veya sayfanın kötü amaçlı kod barındırmadığını göstermez. Alan adı doğrulamalı sertifikalar dakikalar içinde ve otomatik olarak alınabildiği için sahte mağazalar ve oltalama sayfaları da aynı kilidi rahatlıkla gösterir. Kilit "bu hat dinleniyor mu" sorusuna cevap verir, "bu site dürüst mü" sorusuna değil.

Bu ayrım teknik denetimin çıkış noktasıdır, çünkü HTTPS tarafındaki işlerin çoğu kilit göründüğü anda bitmiş sayılıyor. Oysa şifrelemenin hangi protokol sürümüyle kurulduğu, kuralın tarayıcıda kalıcı hale gelip gelmediği ve sayfanın içindeki kaynakların da aynı şifreli hattan geçip geçmediği ayrı ayrı bakılması gereken üç ayrı konudur.

SSL ile TLS aynı şey mi?

SSL (Secure Sockets Layer) ve TLS (Transport Layer Security), tarayıcı ile sunucu arasındaki bağlantıyı şifreleyen protokollerdir. Aynı soyun iki kuşağıdır: SSL önce geldi, TLS onun yerini aldı. Bugün "SSL sertifikası" diye satılan ve konuşulan her şey teknik olarak TLS üzerinde çalışır. İsim ticari alışkanlıkla yerleşmiş durumda, protokolün kendisi yıllar önce el değiştirdi.

Bu yalnızca kelime meselesi değil, çünkü eski sürümler artık kullanımda değil. IETF, SSL 3.0'ı "yeterince güvenli değil" gerekçesiyle resmen kullanımdan kaldırdı ve fallback yoluyla bu sürüme geri düşülmesini de yasakladı. Aynı kurum daha sonra TLS 1.0 ve TLS 1.1 sürümlerini de resmen kullanımdan kaldırdı. Geriye üretimde iki sürüm kalıyor: TLS 1.2 ve TLS 1.3.

Buradan çıkan ve sahada en sık atlanan sonuç şu: sertifika ile protokol sürümü ayrı şeylerdir. Daha pahalı bir sertifika almak sunucunuzun TLS sürümünü yükseltmez. Sertifika kimliği kanıtlar, protokol sürümünü ise sunucu yapılandırması belirler. Sertifikasını yenileyip "güvenlik güncellendi" diyen bir sitede TLS 1.0 hâlâ açık olabilir; bu ikisi birbirinden tamamen bağımsız iki ayardır.

HTTPS'in SEO'daki gerçek yeri

Google, HTTPS'i sıralama sinyali olarak kullanmaya başladığını duyurduğunda bunun ağırlığını kendi cümlesiyle tarif etti: çok hafif bir sinyal, küresel sorguların yüzde birinden azını etkiliyor ve yüksek kaliteli içerik gibi diğer sinyallerden daha az ağırlık taşıyor. Aynı duyuruda zamanla bu sinyali güçlendirmeye karar verebileceklerini de yazdılar, ancak bugüne kadar sinyalin ağırlığının artırıldığına dair bir açıklama yapılmadı.

Pratikte bunun anlamı şudur: HTTPS bir kaldıraç değil, bir eşiktir. Rakiplerinizin tamamı zaten HTTPS kullanıyorsa, sertifika kurmak size hiçbir görece avantaj vermez. Sıralamada fark üretmesini beklemek yanlış bir beklentidir.

Asıl etki arama motorunda değil tarayıcıda ortaya çıkar. Şifresiz bir sayfada tarayıcı kullanıcıya "güvenli değil" uyarısı gösterir; form varsa uyarı sertleşir. Bu uyarıyı gören kullanıcının davranışı, sıralamadaki milimetrik farktan çok daha belirleyicidir. HTTPS'i savunurken "Google seviyor" argümanı zayıftır, "kullanıcı formu doldurmadan çıkıyor" argümanı gerçektir.

Üçüncü bir sonuç daha var: HTTPS artık modern web protokollerinin ön koşulu. Tarayıcılar HTTP/2 ve HTTP/3 ile QUIC bağlantılarını şifresiz kurmaz. Yani şifresiz kalan bir site yalnızca güvenlik değil, hız tarafındaki bütün kazanımları da masada bırakır.

Sertifika türleri ve ücretsiz sertifikalar

Sertifikalar doğrulama seviyesine göre üçe ayrılır. Aralarındaki fark, sertifika otoritesinin sizin adınıza neyi taahhüt ettiğidir.

Tablodaki son sütun en çok yanlış bilinen kısımdır. Üç tür arasında şifreleme açısından hiçbir fark yoktur. DV sertifikayla kurulan bağlantı, EV sertifikayla kurulan bağlantı kadar güçlü şifrelenir. Fark, kilidin arkasında kimin kimliğinin kanıtlandığındadır, hattın ne kadar sağlam olduğunda değil.

Ücretsiz sertifikalar bu tabloda DV kutusuna girer ve şifreleme açısından ücretli bir DV sertifikadan farkları yoktur. Gerçek farklar başka yerdedir: ücretsiz sertifikalar genellikle daha kısa geçerlilik süresiyle verilir ve otomatik yenileme kurulumunu zorunlu kılar, kuruluş kimliği taahhüdü içermez, kurumsal destek ve garanti kapsamı sunmaz. Bir blog, kurumsal tanıtım sitesi veya küçük ölçekli e-ticaret için ücretsiz bir DV sertifika teknik olarak yeterlidir. Kart verisi işleyen, kurumsal satın alma süreçlerine giren veya sözleşmesel bir kimlik taahhüdü aranan yapılarda OV ya da EV tercih edilmesinin nedeni şifreleme değil, kimliğin belgelenmesidir.

Google'ın HTTPS geçişi için verdiği temel tavsiyelerde doğrulama seviyesi hiç geçmez. Orada anlatılan şey sertifikanın kapsamıdır: tek alan adı mı, çoklu alan adı mı yoksa joker sertifika mı gerektiğine karar edilmesi ve yeterli anahtar uzunluğunun kullanılması. Yani seçim yaparken sorulacak asıl soru "hangi seviye" değil, "hangi alan adlarını ve alt alan adlarını kapsaması gerekiyor" sorusudur.

HSTS nedir ve hangi açığı kapatır?

Sertifika kurulduktan sonraki standart adım, HTTP üzerinden gelen tüm istekleri kalıcı yönlendirmeyle HTTPS karşılığına göndermektir. Bu doğru bir adımdır ama bir boşluk bırakır: yönlendirmenin çalışabilmesi için önce şifresiz bir istek ağa çıkmak zorundadır. Kullanıcı adres çubuğuna alan adını protokol yazmadan girdiğinde ilk temas hâlâ HTTP üzerindedir ve o ilk istek dinlenmeye ya da yönlendirilmeye açıktır.

HSTS (HTTP Strict Transport Security), tarayıcıya "bu adrese bundan sonra yalnızca HTTPS üzerinden bağlan" talimatını veren bir HTTP yanıt başlığıdır. Tarayıcı bu talimatı bir süreliğine hatırlar. Kullanıcı bir daha http:// yazsa bile tarayıcı isteği ağa hiç çıkarmadan kendi içinde HTTPS'e çevirir. Böylece hem şifresiz ilk temas hem de yönlendirme adımı ortadan kalkar.

Mekanizmanın kendi zayıflığı, tam da bu hatırlama mantığından doğar. HSTS ancak tarayıcı en az bir kez güvenli bağlantı kurup başlığı aldıktan sonra devreye girer. Tarayıcı siteyi ilk kez ziyaret ediyorsa ve o sırada şifresiz bir adres yüklüyorsa, o ilk istek hâlâ ağ saldırılarına açıktır. Buna ilk istek problemi denir ve HSTS'in tek başına çözemediği tek konudur.

Uygulamada en sık atlanan teknik ayrıntı ise şudur: HSTS başlığı HTTP üzerinden gelen isteğe verilen yönlendirme yanıtına konulmaz. Başlık yalnızca HTTPS üzerinden gönderilir. Şifresiz gelen bir isteğe verilen yanıt zaten güvenilmez bir kanaldan geçtiği için oraya konan başlığın bir anlamı yoktur. Doğru sıra şudur: şifresiz istek kalıcı yönlendirmeyle HTTPS'e gönderilir, tarayıcı yeni isteği HTTPS üzerinden yapar ve HSTS başlığı işte o yanıtta yer alır.

HSTS başlığının direktifleri

Başlık üç parçadan oluşur ve üçü de farklı bir işi yapar.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age, tarayıcının bu kuralı saniye cinsinden ne kadar süre hatırlayacağını belirler. Sayaç her HTTPS yanıtıyla yeniden başlar, yani düzenli ziyaret edilen bir sitede süre pratikte hiç dolmaz. Buradaki risk tek yönlüdür: yanlış bir değer verip sonra vazgeçmek istediğinizde, kuralı zaten almış olan tarayıcılarda o süre dolana kadar geri dönemezsiniz. Bu yüzden HSTS'i ilk kez açarken doğrudan bir yıl yazmak yerine kısa bir süreyle başlayıp yapılandırmanın sorunsuz çalıştığını doğruladıktan sonra süreyi kademeli olarak uzatmak yerleşik bir uygulamadır.

includeSubDomains, kuralı ana alan adının tüm alt alan adlarına yayar. Alt alan adı ele geçirme girişimlerine karşı gerçek bir koruma sağlar, ancak açmadan önce tüm alt alan adlarının HTTPS üzerinden çalıştığının doğrulanması gerekir. Henüz şifresiz duran bir test, panel veya API alt alan adı varsa bu direktif açıldığı anda o adres tarayıcı tarafında tamamen erişilemez hale gelir.

preload, siteyi tarayıcıların içine gömülü listeye eklenmek üzere aday gösterdiğinizi bildirir. Bu direktif kullanıldığında max-age değerinin en az 31536000 saniye (bir yıl) olması ve includeSubDomains direktifinin bulunması zorunludur.

Preload listesi ve geri dönüşün maliyeti

Preload listesi, ilk istek problemini kökten çözmek için kurulmuş bir mekanizmadır. Chrome, güçlü bir HSTS politikası olan ve tamamen HTTPS üzerinden çalışan alan adlarının listesini kendi kaynak koduna gömer. Listedeki bir alan adına yapılan istekler ilk ziyarette bile şifresiz olarak ağa çıkmaz. Diğer büyük tarayıcılar da Chrome'un listesini temel alan kendi listelerini kullanır.

Listeye kabul şartları nettir: geçerli bir sertifika sunmak, port 80 dinleniyorsa aynı makine adı üzerinde HTTP'den HTTPS'e yönlendirmek, tüm alt alan adlarını HTTPS üzerinden sunmak (DNS kaydı varsa www dahil) ve ana alan adının HTTPS yanıtlarında en az bir yıllık max-age ile birlikte includeSubDomains ve preload direktiflerini taşıyan bir HSTS başlığı göndermek.

Kararın asıl ağırlığı şartlarda değil geri dönüşte. Listenin kendi dokümantasyonu bu konuda açık bir uyarı taşır: listeye dahil olmak kolayca geri alınamaz. Alan adları çıkarılabilir, ancak değişikliğin kullanıcılara bir tarayıcı güncellemesiyle ulaşması aylar alır ve diğer tarayıcılar için garanti verilemez. Aynı kaynak, tüm site ve tüm alt alan adları için HTTPS'i uzun vadede sürdüreceğinizden emin değilseniz başvuru yapmamanızı söyler. Listeleme tüm alt alan adlarını kapsar, herkese açık olmayan iç alt alan adları dahil.

Kararı bugün daha da dikkatli vermeyi gerektiren bir gelişme daha var. Chrome ve Safari gibi tarayıcılar artık alan adının HSTS politikası ne olursa olsun şifresiz gezinmeleri otomatik olarak HTTPS'e yükseltiyor. Listenin kendi açıklamasına göre preload, tam olarak bu otomatik yükseltmelerin aktif bir saldırgan varlığında başarısız olduğu durumda değer üretiyor. Yani mekanizmanın kattığı marjinal koruma daraldı, geri dönüşün maliyeti ise aynı kaldı. Bankacılık, kimlik doğrulama veya ödeme altyapısı gibi hedef değeri yüksek yapılarda preload hâlâ savunulabilir bir tercih. Sıradan bir kurumsal site veya blog için ise kazanç ile risk arasındaki denge çoğu zaman başvuru yapmamaktan yana.

Bir uyarı daha: HSTS etkin bir alan adında sertifika hatası oluştuğunda tarayıcı kullanıcıya "yine de devam et" seçeneği sunmaz. Normal koşullarda tıklanıp geçilebilen bir uyarı, HSTS altında sert bir erişim engeline dönüşür. Sertifikanın süresinin dolması ya da yenilemenin aksaması bu yüzden HSTS kullanan sitelerde doğrudan erişim kesintisi demektir.

Karma içerik sorunu

Karma içerik (mixed content), HTTPS üzerinden sunulan bir sayfanın içinde şifresiz kaynak çağrılmasıdır. Sayfanın kendisi şifreli gelir ama içindeki bir görsel, komut dosyası veya stil dosyası HTTP adresinden istenir. Sonuç, şifrelemenin sayfa bütünü için kırılmasıdır.

Türkçe kaynakların çoğu bu konuyu hâlâ "aktif" ve "pasif" karma içerik ayrımıyla anlatır. O terminoloji şartnamenin eski sürümüne aittir. Güncel sınıflandırma ikiye ayrılır: yükseltilebilir içerik ve engellenebilir içerik. Tarayıcılar yükseltilebilir içerik isteklerini otomatik olarak HTTP'den HTTPS'e çevirir, engellenebilir içerik isteklerini ise doğrudan engeller. Eski çerçevede "isteğe bağlı engellenebilir" sayılan görsel, video ve ses gibi kaynaklar yükseltilebilir kümenin çekirdeğini oluşturdu; yeni eklenen dosya türlerinin ise engellenebilir kabul edilmesi bekleniyor.

Bu değişimin pratik sonucu, eski varsayımın artık geçerli olmamasıdır. "Görseller nasılsa gösteriliyor, karma içerik uyarısı önemli değil" yaklaşımı yanlıştır: tarayıcı o isteği HTTPS'e yükseltmeye çalışır ve yükseltme başarısız olursa kaynak hiç yüklenmez. Yani şifresiz kalmış bir görsel yolu, bugün eksik görsel demektir. Komut dosyası veya stil dosyası tarafında ise engelleme doğrudan sayfanın çalışmamasına yol açar.

Tespit için ayrı bir araca ihtiyaç yok. Tarayıcının geliştirici konsolu hem yükseltilen hem engellenen karma içerik için uyarı basar. Sayfayı açıp konsolu izlemek, sorunun hangi kaynaklarda olduğunu doğrudan gösterir. Yaygın kaynaklar şablon dosyalarına gömülü mutlak HTTP adresleri, veritabanına yazılmış eski içerik bağlantıları ve üçüncü taraf gömülü içeriklerdir.

Kontrolü nasıl yaparsınız?

Denetim, kilide bakmakla değil katmanları sırayla ayırmakla yapılır. Sıra önemlidir, çünkü alttaki katman bozuksa üsttekini düzeltmenin anlamı kalmaz.

1. Sertifikanın kendisi. Tarayıcıda kilide tıklayıp sertifika detayını açın. Üç şeye bakılır: sertifika bu alan adını kapsıyor mu, geçerlilik süresi ne zaman doluyor ve zincir eksiksiz mi. Kilit görünüyor diye bu üçünün doğru olduğu varsayılamaz, çünkü tarayıcılar bazı eksiklikleri kendi önbelleklerinden tamamlayabilir.
2. Protokol sürümü. Sunucuda hangi TLS sürümlerinin açık olduğunu kontrol edin. Hedef, TLS 1.2 ve TLS 1.3'ün açık, daha eski sürümlerin kapalı olmasıdır. Bu ayar sertifikadan bağımsızdır ve sunucu yapılandırmasında durur.
3. Yönlendirme. Alan adını http:// ile açtığınızda tek adımda HTTPS karşılığına gitmeli. Araya giren her ek adım hem gecikme ekler hem de şifresiz kalan süreyi uzatır. Hem www'lu hem www'suz sürümü ayrı ayrı deneyin.
4. Başlık kontrolü. HSTS başlığı yalnızca HTTPS yanıtında aranır. Şifresiz adrese verilen yönlendirme yanıtında başlığın bulunmaması bir hata değil, doğru davranıştır. Yanıt başlıklarını görmek için basit bir istek yeterlidir:

   curl -I https://example.com

   Dönen yanıtta strict-transport-security satırını ve içindeki direktifleri kontrol edin.
5. Karma içerik. Ana şablonları, form sayfalarını ve gömülü içerik barındıran sayfaları geliştirici konsolu açıkken gezin. Uyarı çıkan her kaynağın adresini HTTPS karşılığıyla değiştirin.
6. Katman sahipliği. Önde bir CDN katmanı varsa başlığı kimin eklediğini netleştirin. Şifreleme CDN ile sunucu arasında ayrıca kurulur ve buradaki mod yanlış seçilirse ziyaretçi kilidi görürken CDN ile sunucu arasındaki bacak şifresiz kalabilir. Ayrıca başlığın hem kaynak sunucuda hem CDN tarafında eklenmesi durumunda yanıtta çift başlık oluşur.

Tarayıcı bir uyarı gösteriyorsa, uyarının kodu sorunun nerede olduğunu doğrudan söyler.

Üçüncü satır özellikle sinsi bir hatadır. Ara sertifika eksikliği masaüstü tarayıcılarda çoğu zaman fark edilmez, çünkü tarayıcı eksik halkayı önceki ziyaretlerden tamamlayabilir. Aynı sitenin mobil tarayıcılarda, uygulama içi tarayıcılarda ve arama motoru botlarında hata vermesi bu yüzden mümkündür. "Bende açılıyor" cümlesi bu hatada hiçbir şeyi kanıtlamaz.

Sık yapılan yapılandırma hataları

• Başlığı yanlış yanıta koymak. HSTS başlığını şifresiz yanıta ya da yönlendirme yanıtına eklemek işe yaramaz. Başlık HTTPS yanıtında olmalıdır.
• Hata sayfalarında başlığın düşmesi. Bazı sunucu yazılımlarında başlık ekleme direktifi varsayılan olarak yalnızca belirli yanıt kodlarına uygulanır. Bu durumda 404 ve 500 gibi hata yanıtlarında HSTS başlığı kaybolur. Sunucu yapılandırmasında başlığın tüm yanıtlara uygulanmasını sağlayan seçeneğin açık olması gerekir.
• Alt alan adlarını saymadan kapsamı genişletmek. includeSubDomains açılmadan önce tüm alt alan adlarının listelenmesi ve her birinin HTTPS durumunun tek tek doğrulanması gerekir.
• Preload'ı deneme amaçlı açmak. Preload direktifi bir talep bildirimidir ve listeye alınma süreci başladığında geri dönüş süresi sizin kontrolünüzden çıkar.
• Sertifika yenilemesini otomatikleştirmemek. Kısa ömürlü sertifikalarda elle yenileme er ya da geç unutulur. HSTS etkinken bu unutkanlığın bedeli uyarı değil, doğrudan erişim kesintisidir.

HTTPS'in çözmediği şey

Baştaki ayrımı burada tamamlamak gerekiyor. HTTPS taşımayı korur, içeriği korumaz. Şifreleme, veriyi A noktasından B noktasına giderken okunmaktan ve değiştirilmekten korur. Sunucunun kendisinde ne olduğuyla ilgilenmez.

Bunun somut karşılığı şudur: sitenize yetkisiz erişim sağlayan biri sayfalarınıza gizli bağlantılar veya yönlendirmeler yerleştirdiğinde, bunların hepsi geçerli sertifikanız üzerinden ve kusursuz bir kilit simgesiyle ziyaretçiye ulaşır. Hacklink enjeksiyonu gibi saldırılarda tarayıcı hiçbir uyarı vermez, çünkü teknik olarak ortada bir şifreleme sorunu yoktur. Zararlı içerik, sizin kendi güvenli hattınızdan taşınır.

Kilit, sertifika, TLS sürümü ve HSTS başlığı bu yüzden güvenliğin tamamı değil taşıma katmanının denetimidir. Bu katmanı doğru kurmak gereklidir ama sunucu erişim denetimi, yazılım güncellemeleri ve dosya bütünlüğü takibi olmadan yeterli değildir. Adres çubuğundaki kilit yalnızca yolun güvenli olduğunu söyler, yolun sonundaki evin kapısının kilitli olduğunu değil.