HTTP Bağlantıların Tabutuna Son Çivi: Chrome 68 ve SSL/TLS İmplementasyonu Konusunda Bilinmesi Gerekenler

Google geçen hafta yayınladığı Chrome 68 versiyonu ile birlikte HTTP üzerinden yapılan bağlantıların tabutuna son çiviyi çaktı. Chrome, 68 versiyonu ile birlikte HTTP kullanan tüm siteleri güvensiz olarak işaretleyecek.

Scott Helme'in veciz ifadesi ile Google bu hamlesiyle kendisi dahil browser üreticileri için küçük, ama güvenli web için büyük bir adım atmış oldu.

Dahası 69 sürümü ile birlikte güvenli bağlantıları de-facto olarak kabul edecek olan Chrome, HTTPS siteleri o alıştığımız şirin yeşil asma kilitle de göstermeyecek.

Google'ın güvenli web konusundaki "proaktif" adımları bu kadarla da sınırlı değil. 2014 yılından itibaren HTTPS kullanımını arama sonuçları sıralamasında bir faktör olarak kullanması, Public Key Pinning Teknolojisini tarayıcılarına implemente etmesi, HSTS ve preload implementasyonu ve son olarak da Certificate Transparency ve Expect-CT atılımları ile bu işin lokomotifi durumunda. Let's Encrypt 'ın ücretsiz sertifika hizmetini de unutmamak gerekiyor!

Haftanın Hackleri yazılarında defaatle güvenli bağlantının unsurlarına değindik. En önemli ikazlarımızdan biri de salt HTTPS kullanmanın güvenli bağlantı tesis etmek demek olmadığını, dört başı mağrur bir güvenli bağlantı sağlamak için kolları sıvamak ve ince birkaç işe girişmek gerektiğini hep yazdık.

Gelin bu majör değişiklikle beraber bugüne kadar söylediklerimizin bir özetini çıkaralım.

Neden SSL/TLS Kullanmalıyım?

SSL/TLS, uçtan uca bir şifreleme sunarak, bütünlük, gizlilik ve yetkilendirme için elverişli bir yol sunar. İdeal bir SSL implementasyonunda, trafik boyunca transfer edilen verilerin, aktarım esnasında değişmediğinden, bir üçüncü kişi tarafından izlenemediğinden ve gerçekten de iletişim kurduğumuz kişinin bizim arzu ettiğimiz kişi olup olmadığından emin olabiliriz.

Özetle, ideal bir TLS/SSL implementasyonunda web trafiğiniz araya giren üçüncü herhangi bir kişi/kurum tarafından okunamaz, değiştirilemez.

Araya kimler girebilir?

Internet üzerindeki tüm veri alış verişimiz onlarca, belki yüzlerce ara nokta üzerinden hedefe aktarılmaktadır. HOP olarak isimlendirdiğimiz bu noktaların her birinde, şayet SSL vb. bir şifreleme kullanılmadı ise, bu paketlerin okunma ve değiştirilme riski mevcuttur. Paketin okunabileceği ya da değiştirilebileceği herhangi bir noktada bulunan tehdit aktörü ortadaki adam, yani Man in The Midle (MiTM) olarak anılmaktadır.

Bütünlük, gönderilen verinin arada olması muhtemelen hiçbir üçüncü taraf kişi / kurum eliyle değiştirilmediğini; gizlilik okunamadığı temin eden özelliklerdir.

Peki ya yetkilendirme ve kimlik doğrulama? SSL/TLS sadece aktarım trafiğinin şifreli olmasını temin etse idi büyük bir problem ile karşı karşıya kalacaktık: kimlik denetimi!

SSL/TLS trafiğin şifreli aktarımını temin eder. Araya giren kişi de şifreli trafiğin sürmesini sağlayabilir. Dolayısıyla biz aynı zamanda bize sunulan sertifikanın beklediğimiz kişiye ait olup olmadığını da kontrol etmek zorundayız.

Neyse ki modern tarayıcılar bütün bunları bizim için yapıyor. Web sitelerini güvenli hale getirmek isteyen kullanıcıların yapması gereken en önemli şey güvenli bağlantıyı implemente etmek, bunun için de ilk adım bir sertifika sahibi olmak.

Web Sitenizi SSL/TLS Üzerinden Sunmak İçin Bir Sertifikaya İhtiyacınız Var

TLS/SSL teknolojisi açık anahtarlı şifreleme (PKI) teknolojisini kullanmaktadır. Buna göre web siteniz bir anahtar çiftine sahip olmak zorunda. Sahip olduğunuz bu anahtar çiftinde bir gizli (private) bir de açık (public) anahtarınız olacak.

Public anahtarınızı sizinle şifreli halde iletişim kurmak isteyen kişiler ile paylaşabilirsiniz. Public anahtarınız ile şifrelenmiş bir mesajı ancak sizin private yani gizli anahtarınız decrypt ederek okunaklı hale getirebilir.

Peki sertifika bu işin neresinde?

Bunu anlamak için biraz daha geriye gitmek zorundayız.

Metnin şifrelenmesi ve şifrenin çözülmesi için ortak bir anahtarın kullanıldığı yöntem, Kriptoloji Bilimi terminolojisinde Simetrik Şifreleme olarak anılmaktadır. Simetrik Şifreleme'nin bu karakteristik özelliğinde, hem gönderici hem de alıcı aynı anahtarı kullanarak metni şifrelemekte ve şifrelenen metni orijinal metne dönüştürmektedir:

Simetrik Şifreleme, hızlı bir yöntem olsa da günümüz dünyasında, şifre anahtarının paylaşılması veya ele geçirilmesi durumunda risk arz etmektedir. Eğer tek bir kişi, kendi dosyalarını ve verilerini şifrelemek için kullanıyor ve aynı şifreleme anahtarının "güvensiz" kanallar ile paylaşılması söz konusu değilse, kullanışlı bir yöntem olabilir.

Public Key Infrastructure (PKI) teknolojisinin sunduğu en büyük imkânlardan biri simetrik şifrelemede ortak şifreleme anahtar kullanımının yarattığı riskin önüne geçmesidir. Burada sözü edilen risk, şifreli iletişime dahil olacak kişilerin aynı anahtarı kullanma zorunluluğu. İletişime dahil olan tüm unsurlar anahtara sahip olacağı ve bu anahtar hem şifreleme hem de şifre çözümünde kullanılacağı için, anahtar sahiplerinden birinin zayıf halka oluşu, yani anahtar güvenliğini sağlayamaması iletişimin tüm taraflarını tehlikeye atacaktır.

PKI sayesinde sizinle şifreli iletişim kurmak isteyen birinin sizin public anahtarınıza erişebilmesi kâfi.

Fakat web sitelerinden söz ediyorsak, binlerce belki de milyonlarca kullanıcıdan söz ediyoruz demek.

Ziyaretçiler için de aynı şey geçerli. Web gezinimleri esnasında yüzlerce siteye tesadüf edip bu sitelerde gezinti yapabilirler

Tüm web sitelerinin public anahtarına sahip olmak mümkün değil. Dolayısıyla şifreli iletişime başlamadan önce web sayfaları "İşte benim public anahtarım" diyerek açık anahtarını sunmak zorunda.

Peki şifreleme için public anahtarını sunan kişi, gerçekten de olduğunu iddia ettiği kişi mi? Keşke bu kişinin dürüstlüğüne kefil olacak, bizim de sözüne itimat ettiğimiz bir üçüncü kişi olsa. Evet var: Sertifika Otoriteleri. (Certificate Authority - CA)

Sertifika Otoriteleri browser üreticilerinin güvendiği, kefaletlerini kabul ettiği taraflardır. Browser üreticileri milyonlarca web sitesine ait public anahtarı tek tek saklamak yerine, yüz küsür sertifika otoritesiyle bu işi kökten halletmekte ve adeta "Bir problem olursa ben sizi tanırım arkadaş!" demektedir.

İşte SSL sertifikası dediğimiz de aslında public anahtarımızın sitemize ait olduğuna dair browserların tanıdığı bu sözüne itimat ettiği kurumlardan ıslak imzalı bir belge almak gibidir. Bu sertifikayı aldığımızda kullanıcı bizimle tarayıcılar vasıtası ile güvenli iletişim kurmak istediğinde bu sertifikalarımızı sunarız. Tarayıcılar sertifikalarımız üzerinde tanıdıkları, itimat ettikleri otoritelerin onaylarını gördüğünde sessiz sedasız işlerini yaparlar. Ama imzacıları tanımıyorlarsa, güven listelerin yer almıyorlarsa şartlara göre bunun güvenli bir bağlantı olmadığı konusunda sizi uyarmaktan, bağlantı sonlandırmaya dair, konfigürasyonlarla belirleyeceğiniz tepkiler verebilirler.

Peki Web Sitem İçin Sertifikayı Nereden Alabilirim?

Web sayfanız için SSL sertifikasını pek çok kurumdan alabilirsiniz. Biz ücretsiz sertifika imzalayan ve Netsparker olarak da sponsoru olduğumuz Let's Encrypt'ı öneriyoruz.

Sertifikamı Aldım, Bu Kadar mı?

Hayır değil! Sertifika sahipliği güvenli bir bağlantı tesis etmenin ilk adımı, katiyetle son adımı değil. Hâlâ atılması gereken birkaç adım daha var.

Güvenli Bir Bağlantı Kullanıcının Tercihine Bırakılmamalı: HTTP Strict Transport Security (HSTS)

Web uygulamalarınız için SSL'i layığıyla implemente etmek istediğinizde, siteye yönelen tüm HTTP isteklerini HTTPS olarak değiştirmeniz, bunun dışında web sayfalarınız içerisine yüklenen, imaj, script, stil dosyaları gibi pek çok dosyaların da yine güvenli bir protokol üzerinden yüklenmesini sağlamanız gerekiyor. Ayrıca, sertifika hatalarında da, güvenlik daha önemlidir diyerek, bu tarz durumlarda gerekirse kullanıcının site gezinimini dahi engellemeniz gerekmektedir.

Bütün bunları manual olarak yapabilmek çok zor. Özellikle de olası bir sertifika hatası durumunda kullanıcının sitenizdeki gezinimini engellemek.

Bu noktada imdadımıza HSTS yetişiyor. Kasım 2012 yılında geliştirilen HSTS özelliği sayesinde, web sayfamızın yanıtında bir güvenlik headerı (Strict-Transport-Security) set etmemiz yeterli. Ayrıntılar için lütfen tıklayınız.

HSTS'i Set Ettim Diye Güvenme, Siteni Sağlam Kazığa Bağla : preLoad

HSTS headerını ancak güvenli bir bağlantı üzerinden set edebiliyoruz. Güvenli iletişim ile ilgili diğer bir header olan Public Key Pinning gibi HSTS de Trust On First Use (TOFU) yöntemine dayanıyor. Yani ilk HTTP isteği web sitemize yapıldığında, biz bunu hardcoded olarak güvenli bağlantıya yönlendireceğiz. Bu güvenli bağlantının yanıtında da HSTS headerı olacak ve browserlar artık bu talimatı belleklerinde saklayıp bir dahaki güvensiz (HTTP) isteği doğrudan kendileri güvenli bağlantıya yönlendirecekler.

Peki bu ilk yapılan HTTP isteğinin MITM saldırıları ile engellenmesi söz konusu değil mi? Maalesef evet.

İşte bununla ilgili olarak da karşımıza preload özelliği çıkıyor.

preload özelliği sayesinde browserlarla birlikte deploy edilen HSTS listesine sitemizin de dahil edilip, bu ilk HTTP isteğine gerek kalmadan HSTS'in uygulanmasını sağlayabiliriz.

Ayrıntılar için tıklayınız.

HTTP Public Key Pinning (HPKP), Certificate Transparency, Expect-CT ve CAA

Güvenli bir bağlantı kurulurken, sitemizin istemciye ibraz edeceği sertifikanın browser tarafından bir kontrole tabi tutulacağından söz etmiştik. Bu kontrol sertifikanın browserın tanıdığı otoritelerden biri tarafından onaylanıp onaylanmadığının kontrolüdür.

Burada önemli bir teknik ayrıntı var. Sertifika otoriteleri teknik olarak bir sertifika imzalamadan önce site sahiplerini haberdar etmek zorunda değiller. Evet sertifika başvurusu yapıldığında bürokratik işleyiş gereği sizin site sahipliğini doğrulamanız çeşitli yollarla isteniyor ancak teknik olarak sizden hiçbir belge almadan, sizi hiç haberdar etmeden de bir sertifika otoritesi sizin adınıza sertifika imzalayabilir.

2011 yılında Hollandalı yetkili sertifika dağıtıcısı DigiNotar'ın hacklenerek, saldırganlar tarafından pek çok site için sertifika imzalanması bunun en somut örneği. Bu hack eylemi sonrasında, 500 'e yakın sertifika imzalanıyor. Bu sertifikalarla 300 bin İran'lının Gmail kullanımı da dahil olmak üzere pek çok Google servisi kullanımı izleniyor.

Yine benzer bir olay 2008 ve 2011 yıllarında yine bir sertifika otoritesi olan StartCom'un da başına geliyor. Bu saldırılarla birlikte, paypal.com ve verisign.com domainleri için sertifikalar üretiliyor. 2011'deki saldırıda StartCom'un rootkey'ine ulaşılıyor. Böylece sadece istedikleri site için sertifika üretebilmek değil, aynı zamanda üretilen sertifikaları geçersiz kılabilmek ya da tekrar imzalayabilmek şansına sahip oluyorlar.

Bu saydığımız tehditi izale etmek için HPKP, Certificate Transparency, Expect-CT ve CAA Entry yöntemlerinden birine müracaat edebilirsiniz.

Tüm Bağlantıları SSL/TLS 'e Dönüştürün. Güvensiz Bağlantılar Üzerinden CSS, Javascript gibi kaynakları yüklemeyin: Subresource Integrity (SRI) ve Content-Security-Policy (CSP)

HTTPS ile bir nebze olsun kendimizi güvende hissedebiliriz. Ama HTTPS teknolojisi yalnızca aktarımdaki güvenliği temin ediyor. Yani X bir hosttan aldığımız dosyalar eğer güvenli protokol ile aktarılıyorsa, bize ulaşana kadar bütünlüğü ve gizliliği korunmuş oluyor.

Peki ya bu kaynakları aldığımız sunucular bir saldırıya uğramış ve yığınla web sitesine servis edilen script ve style dosyaları değiştirilmiş ise?

HTTPS'in bu noktada güvenliğimizi sağlayamayacağı aşikar. Peki bu durumda ne yapabiliriz?

Bu durumda imdadımıza, SRI yani Subresource Integrity özelliği yetişiyor. SRI'nın ayrıntıları için lütfen tıklayınız.

2012 Kasım ayında ilk versiyonu hayatımıza giren CSP, başta XSS olmak üzere, Clickjacking, Protocol Downgrading, Frame Injection vb bir dizi zafiyete karşı istemci tarafında ekstra güvenlik katmanı sunmaktadır.

Konumuz ile en alakalı husus Protocol Downgrading, yani herhangi bir sebeple HTTPS bağlantı üzerinden HTTP'e yapılan geçişler. Örneğin tüm sistemi güvenli bağlantı üzerinden servis eden bir geliştirici, sayfa içerisinde HTTP linkleri unutrabilir. Yahut dinamik içeriklerin eklendiği sayfalarda, güvenli bağlantıya rağmen HTTP ile kaynak yüklemeleri ile ilgili istekler eklenmiş olabilir.

Relative Schema Kullanımı

Gerek kaynak yüklemelerinde, gerekse href attributelerinde Relative Schema kullanabilirsiniz. Bu sayede siteye erişimde kullanılan şema (artık SSL/TLS için ikna olduğunuzu varsayıyorum) ne ise, sitede bulunan tüm src ve href attributelerindeki URL'lere bu şemaya uygun olarak erişilecektir.

Örneğin sayfamızın adresi https://www.example.com olsun

<img src="//www.anotherdomain.com/dog.gif"/>

İmaj yüklemesi, siteye erişilen URL, HTTPS şemasına sahip olduğu için Relative Schema kullanılarak set edilmiş tüm domainler de HTTPS şemasına uygun dönüştürülecektir.

Sadece Ödeme ve Login Sayfalarına Değil, Tüm Sayfalara Erişimde SSL/TLS 'i Zorunlu Kılın

Yukarıda ayrıntılarına yer verdiğimiz HSTS, CSP ve Relative Schema sayesinde tüm bağlantıların SSL/TLS kullanmasını zorlayabilirsiniz.

Peki ama ödeme sayfaları, login sayfaları dışında buna ne gerek var?

http://www.example.com/js/jquery.js sayfasının HTTP üzerinden yani güvensiz bir bağlantı üzerinden yüklenmesinde bir beis görmüyorsunuz. Fakat https://www.example.com/checkout.php sizin için tam da olması gerektiği HTTPS ile servis edilmiş durumda.

Bağlantıda araya giren bir saldırgan, jquery.js'e aşağıdaki kodu ekleyip, checkout.php sayfasındaki tüm hareketleri izleyebilir, input değerlerini okuyabilir. Not, aşağıda paylaştığım kod, gerçek bir Javascript malware'in kaynak kodududur.

// Only run on pages with worthwhile info
if ((new RegExp("onepage|checkout|onestep", "gi")).test(window.location)) {
  Malware.send();
}

Yukarıdaki kod, sayfa checkout, onepage, onestep gibi isimler taşıyorsa enjekte edilecektir.

Static Bir Web Sitem Var, Yine de SSL/TLS Kullanmalı mıyım?

Evet kullanmalısınız. Zira son kullanıcı açısından enjekte edilen kod onun browserında çalışacak ve kötü sonuçlara yol açacaksa sizin sitenizin statik olup olmamasının bir önemi kalmıyor.

Sayfanız statik olsa da sayfanıza erişmek isteyen bir kullanıcı, sayfaya enjekte edilen sahte bir Flash Player Güncelleme ekranı ile karşılaşabilir ve sayfasına bir zararlı yazılım indirip çalıştırabilir.

Nitekim Troy Hunt, Twitter'daki bir kullanıcının bu konudaki "güvenlik" iddiasını çürütmek için 24 dakikalık bir video hazırladı. İzlemek için lütfen tıklayınız.

Sonuç

HTTPS, yani güvenli bağlantı giderek webin de-facto erişim protokolü haline geliyor. Güvenli bir bağlantı sağlıyor olmak arama motorlarındaki sıranızdan, işletmenizin itibarına kadar pek çok noktada etkili bir parametre. TLS/SSL 'in implementasyonu konusunda paylaştığımız ayrıntıların yol gösterici olacağını umuyoruz.