Chris Palmer ve Yan Zhu tarafından yazılmıştır

Makale 15 Kasım 2010 tarihinde yayımlanmıştır. 12 Aralık 2013 tarihinde revize edilmiştir.

İnternet teknologları, HTTP'nin güvensiz olduğunun ve kullanıcılara karşı birçok risk oluşturduğunun uzun süredir farkındaydı. HTTP üzerinden gönderilen trafik şifresiz olduğu için, HTTP üzerinden gönderilen her veri ağa erişimi olan herhangi biri tarafından okunabilir ya da modifiye edilebilir. Snowden'ın sağladığı NSA dökümanlarında da görüldüğü gibi, HTTP trafiği devlet ajansları tarafından kullanıcı ya da webmasterlar uyarılmadan toplanabiliyor. Bu riskler göz önüne alındığında, EFF tüm sitelerin bir an önce HTTPS kullanması gerektiğine inanıyor.

HTTPS, temel web güvenliği için uzun bir süredir varolmasına karşın, bazı siteler HTTPS'i desteklemekte yavaş kaldılar. Düzgün ve komple olarak bir uygulamayı HTTPS üzerinden sunmanın gerektirdiği ilgi, bunun sebeplerinden biri.

Bu makale, HTTPS desteğini uygulamak ve geliştirmek isteyen site operatörlerini cesaretlendirmek ve onlara yardımcı olmak için tasarlanmıştır. Hiçbir önlem sizi bütün tehditlere karşı koruyamaz, ancak HTTPS'i desteklemek kullanıcılarınızı yaygınlaşmış saldırılara karşı koruyacaktır.

Arkaplan

HTTPS üç farklı güvenlik garantisi verir:

  1. Sunucu kimliğinin doğrulanması, kullanıcılara doğru uygulama sunucusuyla konuştukları güvencesini az da olsa sağlar. Bu garanti olmadan, gizliliğin ya da bütünlüğün (integrity) garantisi mümkün değildir.
  2. Veri gizliliği, veri şifreli olduğu için, kullanıcının tarayıcısı ve web sunucusu arasındaki iletişimin içeriğinin başkaları tarafından dinlenemeyeceği anlamına gelir.
  3. Veri bütünlüğü, veriler kriptografik mesaj doğrulama koduyla doğrulandığı için, kullanıcının tarayıcısı ve web sunucusu arasındaki iletişimin içeriğinin, ağa saldıran biri tarafından hasar göremeyeceği ya da içeriğinin değiştirilemeyeceği anlamına gelir.

HTTP ve bunu kullanan uygulamalar kullanıcılarına herhangi bir güvenli garantisi sağlayamaz. HTTP tarafından sunulan bir uygulama kullanıldığında, insanların doğru uygulama sunucusuyla konuştuklarını ya da saldırganların kullanıcının bilgisayarı ve sunucusu arasındaki iletişimi okumadığını ya da modifiye etmediğini anlamanın bir yolu yoktur.

Saldırı ve Savunma Yöntemleri

Kullanıcılar internete nasıl bağlanırsa bağlansın, insanların onlara saldırmasının farklı yolları vardır (kullanıcıları izlemek, taklit etmek, iletişimine müdahale etmek ya da bunların tümü gibi). WiFi ağ operatörleri, kullanıcı ve sunucu arasında olan herhangi bir ISS, bir WiFi router'ını ya da başka bir router'ı yeniden ayarlayabilecek biri, ve sıkça, aynı ağı kullanan biri bu saldırıları gerçekleştirebilir.

Firesheep, pasif ağ saldırısının örneklerinden biridir: tarayıcı ve sunucu arasındaki ağ iletişiminin içeriğini dinler, ancak bu iletişimi yeniden yönlendirmez ya da modifiye etmez. XKeyscore gibi devlet gözetim programları, HTTP trafiğine yapılan pasif ataklar sayesinde devasa boyuttaki online iletişim verilerini toplarlar.

Bununla birlikte, halihazırda mevcut olan diğer araçlar aktif ağ saldırılarını gerçekleştirir. Bu saldırılarda saldırgan iletişimin içeriğini modifiye eder ve/veya iletişimi yeniden yönlendirir. Bu araçların sslstrip gibi ciddi olanları olduğu kadar, Upside-Down-Ternet gibi aptalca olanları da vardır. Upside-Down-Ternet komik bir şakadan ibaret olsa da, zararlı bir kod ya da web sitelerine yanlış bilgiler ekleyen ve hasar verme potansiyeli olan diğer saldırılara teknik olarak benzerlik gösterir. Aynı zamanda bu tarz saldırıların şaka olabilecek kadar kolay olduğunu gözler önüne serer. Ücretsiz WiFi noktalarının, ağ saldırılarını geçerli bir iş modeli gibi görürcesine, kullanıcılarının okuduğu web sayfalarına reklam eklediği bilinen bir şeydir. Cain and Abel gibi araçlar, yerel ağ trafiğini saldırganın sistemine yeniden yönlendirmek gibi farklı saldırı aralıklarına olanak sağlar. (Aynı zamanda Arpspoof ve dsniff'e de göz atın.)

Yalnızca (en azından) doğrulama, gizlilik ve bütünlük sağlayan bir mekanizma saldırı aralıklarına karşı savunma sağlayabilir. Web uygulamaları için şu anki en iyi seçenek HTTPS'dir.

Ancak, site operatörlerinin HTTPS'i güvenli bir şekilde uygularken dikkat etmesi gereken birkaç potansiyel tuzak vardır.

Karışık İçerik

Bir uygulamayı HTTPS üzerinden sunuyorsanız, karışık içerik kullanmamalısınız. Bunun için sayfadaki içeriğin hepsi HTTPS aracılığıyla yakalanmalıdır. Kısmi HTTPS desteğini sitelerde görmek oldukça sık rastlanan bir durumdur. Ana sayfalar HTTPS aracılığıyla yakalanır, ancak sayfa üzerindeki medya elementleri, stylesheet'ler ve JavaScript HTTP üzerinden yakalanır.

Bu güvensizdir çünkü ana sayfa her ne kadar aktif ve pasif ağ saldırılarına karşı korunuyor olsa da, sayfa üzerindeki diğer kaynaklar korunaksızdır. Eğer bir sayfa HTTP üzerinden JavaScript veya CSS yüklüyorsa, bir saldırgan yanlış, zararlı bir kodu sayfaya enjekte edebilir ve sayfanın DOM'unun kontrolünü yüklendikten sonra ele geçirebilir. Bunun sonucunda kullanıcı herhangi bir güvenliği olmadığı eski duruma geri döner. Bu yüzden yaygın olan tarayıcıların hepsi, kullanıcılarını karışık içerik yükleyen sayfalara karşı uyarır. HTTP üzerinden görüntülere referans vermek de güvenli değildir: ya bir saldırgan bir webmail uygulamasındaki "Mesajı Kaydet" ve "Mesajı Sil" ikonlarının yerini değiştirirse?

Uygulama alanının tamamını HTTPS üzerinden vermelisiniz. HTTP isteklerini HTTP 301 ve 302 cevaplarıyla birlikte eşdeğer HTTPS kaynağına yönlendirin.

Bazı site operatörleri, sadece kullanıcının şifresinin hassas bir bilgi olduğu düşüncesinden hareketle, sitelerinin yalnızca giriş (sign in) sayfalarını HTTPS üzerinden verirler. Bu siteler kullanıcılarını pasif ve aktif saldırılara karşı savunmasız bırakır.

Bugün birçok site maalesef HTTPS'i desteklemeyen harici sitelerden ve CDN'lerden (Content Delivery Network) içerik yüklemektedir. Bu içerikleri kendi sunucunuzdan ya da HTTPS destekleyen başka bir sunucudan vermeniz mümkün değilse, içeriğini sunduğunuz diğer siteleri HTTPS desteklemeye teşvik etmelisiniz.

Güvenlik ve Çerezler

Chris Palmer'ın web uygulamaları için güvenli seans yönetimiyle ilgili makalesinde de anlattığı gibi, site operatörleri hassas çerezlerin (kullanıcı doğrulaması için kullanılan çerezler gibi) faaliyet alanını güvenli kaynağa genişletmelidir. Eğer bir çerezin faaliyet alanı genişse (Set-Cookie: header'daki Domain özniteliğiyle birlikte), çerez potansiyel olarak daha az güvenli olan aynı domain'deki başka bir sisteme ya da uygulamaya "sızabilir".

Benzer olarak, uygulama kurulum sırasında Secure özniteliğini (attribute) çereze tayin etmelidir. Bu öznitelik, tarayıcıya çerezin yalnızca güvenli (HTTPS) taşıma üzerinden gönderilmesi bilgisini verir.

HTTP Strict Transport Security'i Kullanın

HTTP Strict Transport Security (HSTS), site operatörlerinin tarayıcılara sitenin HTTPS kullanmasını beklemeleri bilgisini veren bir HTTP protokol eklentisidir.

HSTS şu an için tüm tarayıcılar tarafından desteklenmese de, EFF olarak HSTS desteği sağlamayan firmaların (özellikle size söylüyoruz, Apple ve Microsoft) bu kullanışlı güvenlik mekanizmasını uygulamaya koyan Google, Opera ve Mozilla gibi firmaların izinden gitmesini arzuluyoruz. HTTPS'in (ve SPDY ya da QUIC gibi daha yeni protokollerin) eninde sonunda, tıpkı SSH'in Telnet ve rsh'in yerine geçtiği gibi, HTTP'nin yerine geçmesini bekliyoruz.

Ek bir önlem olarak, siteniz HSTS önyüklemesini desteklemelidir. HSTS önyüklemesi, eğer tarayıcınız sunucudan geçerli bir HSTS üstbilgisi almadıysa, bir HTTP isteğinin dinlenmesini engeller. HSTS önyüklemesi Chromium, Google Chrome ve Firefox'ta yer alan dahili bir domain listesi aracılığıyla eklenmiştir. Sitenizi bu listeye eklemek için takip etmeniz gereken adımları öğrenmek için Chromium'un sayfasına göz atın. Firefox'un HSTS önyükleme listesine dahil olmak için, max-age değeri 18 haftadan büyük olan bir HSTS üstbilgisi yollamanız gerektiğini unutmayın.

HSTS ve HSTS önyüklemesini eff.org için yakın bir zaman önce aktif hale getirdik. Kurulum bir saat kadar sürdü ve bunu kullanıcıları zorla HTTPS'e yönlendirmeden yapmanın bir yöntemini bulduk. Bunu yapmamızın sebebi, HTTPS erişimini net bir şekilde belirtirken, siteyi aynı zamanda HTTP olarak da sunabilmekti. Bu yöntem sorunsuz bir şekilde çalıştı ve kullanıcılarımızın büyük çoğunluğu, belki de bilinçsizce, sitemizi artık otomatik olarak HTTPS kullanarak ziyaret ediyor.

Güçlü Protokolleri ve Cipher Suite'leri Seçin

SSL uygularken seçeceğiniz güçlü protokoller ve cipher suite'leriyle ilgili kısa bir tavsiye listesi şöyledir:

  • SSLv2, SSLv3 ve TLS 1.0 için desteği devre dışı bırakın.
  • TLS 1.1 ve 1.2'yi destekleyin.
  • Şifreleme ve doğrulama desteği vermeyen NULL, aNULL ve eNULL cipher suite'lerini devre dışı bırakın.
  • En az 2048-bit RSA anahtarı kadar güvenli olan bir gizli anahtar kullanın.
  • Kısa ömürlü Diffie-Hellman anahtar değişimini içeren cipher suite'lerini tercih edin. Bunlar Perfect Forward Secrecy isminde önemli bir özellik sunar ve bu özellik gizli SSL anahtarınızın güvenliği gelecekte ihlal edilmiş olsa bile geçmişteki web trafiğinizin şifresinin çözülmesini engeller.
  • Şifreleme için anahtar boyutu 128 bit'ten küçük olan cipher suite'leri devre dışı bırakın.
  • Hashing için MD5 kullanan cipher suite'leri devre dışı bırakın. SHA-1'i kullanmanızı tavsiye etmiyoruz ancak SHA-1, TLS 1.0 ve SSLv3 uyumluluğu için gerekli olabilir.
  • RC4 şifrelemesini kullanan cipher suite'leri devre dışı bırakın. RC4 yerine AES-CBC tercih edilebilir ancak AES-CBC BEAST isimli saldırıya karşı korunmasızdır. Bu yüzden genellikle AES-GCM tavsiye edilir.
  • CRIME saldırısını önlemek için TLS sıkıştırmasını (compression) devre dışı bırakın.
  • Yalnızca RFC 5746 uyumlu güvenli TLS yeniden anlaşmalarını (renegotiation) destekleyin ya da TLS yeniden anlaşmalarını tamamen devre dışı bırakın.

Varolan HTTPS uygulamasındaki zayıflıkları test etmek için Qualys'in meşhur SSL Server Test'ini kullanın.

Performans Endişeleri

Birçok site operatörü, HTTPS'e performans sebeplerinden ötürü geçmediğini belirtir. Ancak bunu söyleyen insanlar gerçekte herhangi bir performans kaybı ölçmemiştir (hatta hiç performans ölçümü yapmamış bile olabilirler) ve sitelerinin davranışının profilini çıkarmamış ve performansını optimize etmemişlerdir. Siteler genellikle HTTP üzerinden sunum yaptığında, gerekli olandan çok daha yüksek gecikme süresine ve/veya düşük veri hacmine (throughput) sahiptirler, bu da problemin HTTPS'te olmadığını gösterir.

Performans probleminin kaynağı içerik katmanı ve genellikle veritabanı katmanıdır. Ne de olsa web uygulamaları temelde girdi-çıktıya (I/O) bağlıdır. Gmail geliştiricilerinin verdiği şu tavsiyeye dikkat edin:

İlk önce, "Sign in" (Giriş) butonuna basılmasıyla başlayan web tarayıcısı ve Google sunucuları arasında gerçekleşen her işlemin listesini çıkardık. Bunu yapmak için Httpwatch, WireShark ve Fiddler gibi birçok web geliştirme aracını ve kendi geliştirdiğimiz performans ölçme sistemlerini kullandık. [...]

Sign-in işlemi sırasında Gmail ve tarayıcı arasında neler gerçekleştiğini görebilmek için saatlerce topladığımız bu izlere dikkat ettik ve bir gelen kutusunun yüklenmesi ve görüntülenmesi için 14-24 arası HTTP isteğinin gerektiğini tespit ettik. Bu sayıları bir perspektife yerleştirmek gerekirse, popüler bir ağ haberleri sitesinin ana sayfasının tamamen yüklenmesi için dün tıkladığımda 180 tane istek gerekiyordu. Bu probleme birkaç yönden aynı anda saldırmaya karar verdik: istek sayısını azalt, isteklerin daha fazlasının tarayıcı tarafından önbelleğe atılmasını sağla ve her isteğin overhead'ini azalt.

Üç alanda da iyi gelişmeler kaydettik. Her isteğin ağırlığını bazı çerezlerimizin faaliyet alanını daraltarak ya da elimine ederek azalttık. Her görüntünün tarayıcı tarafından önbelleğe atıldığından emin olduk ve spriting olarak da bilinen küçük ikon görüntülerini tek bir meta-görüntüyle birleştirdik. Birkaç isteği birleştirerek, bunları tek bir birleştirilmiş isteğe ve cevaba dönüştürdük. Bunun sonucunda artık "Sign in" butonuna tıklayıp gelen kutunuza ulaşmak için yalnızca 4 istek gerekiyor.

Google çalışanı Adam Langley ek bilgiler sağlıyor:

Bunu yapabilmek için ek bir makine ya da özel bir donanım kullanmadık. SSL/TLS, frontend üretim makinelerimizde CPU yükünün %1'inden, network overhead'in %2'sinden ve bağlantı başına belleğin 10KB'ından sorumlu. Birçok insan SSL'in CPU'yu çok kullandığını düşünüyor ve biz ilk defa halka açıkladığımız bu sayıların bu düşünceyi yok edeceğini umuyoruz.

Yalnızca HTTPS kullandığında bile Gmail'in iyi çalıştığı şaşılacak bir şey mi? Site operatörleri web uygulamalarını yavaş yavaş ayarlayarak kademeli gelişimin farkına varabilir. Chris bu konuyla ilgili Web 2.0 Expo 2009'da bir sunum yapmıştı.

Sonuç

HTTPS, web uygulaması kullanıcıları için güvenliğin temelini sağlar ve HTTP kullanmaya devam etmenin performans ya da maliyet temelli bir sebebi yoktur. Web uygulaması sağlayıcıları, HTTP kullanmaya devam ederek kendi iş modellerini baltalarlar ve internetin herhangi bir yerinde geniş saldırı aralıklarına izin vererek kullanıcıların bilgilerini tehlikeye atarlar.